So, publish the current draft as Informational with a suitable
note saying that this is the currently deployed practise, stating
that there are architectural problems in the way it is done, and
that the practise should not be extended? And at the same time,
try to do the right thing for IPv6, and possible future IPv4
extensions?
On one hand, I would be happy to do this because it solves the problem
for MPLS. Let's keep this in mind in case we don't reach a more
satisfying solution.
Good.
One the other hand, the solution is not altogether satisfying
because it
leaves ICMP inextensible.
I see your motivation.
[Skipping the very good and sensible introduction for the sake of
brevity.]
In order to make [four ICMPv4 messages] extensible, allocate 8 bits
of the UNUSED field to indicate the length of the final field. If
these 8 bits are clear, we can assume that we are looking at an
older version of ICMP. So, the application is on its own to
determine whether the ICMP message contains any extensions.
From the syntactic and practical point of view this seems to work
fine.
What I am worried about is whether this is the right thing to do
from an architectural point of view. As I said, I don't see any
problems with new informational messages; for traceroute purposes
the right thing to me seems to define a new informational message
that carries the MPLS related information.
My current rough approximation is that we should try to keep ICMP
error messages for IP-related errors. Hence, the question seems
to boil down to what to do if the protocol beneath IP, such as
MPLS, generates an IP-related error.
Now I must admit that I do not properly understand the
interactions between MPLS and IP, but based on my casual
reading of 2.4 of RFC3032 it seems to be that if MPLS TTL=0
and IP TTL!=0, the right thing to do is NOT to send ICMP Time
Exceeded but a new *informational* ICMP message stating that
the MPLS TTL exceeded. In my perhaps seriously flawed
understanding, the case is equal to e.g. bridged Ethernet
dropping a packet due a link layer error, and the right
thing to me seems to handle it at the IP layer as a silently
dropped packet.
Section 2.4.3 of RFC3032 (copying back TTL from MPLS to IP)
certainly complicates the situation, and I must admit that I
don't understand it. To me seems like a layer violation. I
am sure you discussed it to death when writing RFC 3032; I'd
appreciate a pointer to the relevant discussion in the ML
archive.
If the general perception is that the TTL copyback is indeed a
layer violation (with good reasons, no doubt), then I think my
previous argumentation holds:
- document the current practise as information with caveats
- recommend using new informational messages for reporting
back link layer errors, when possible and appropriate
On the other hand, if the general perception is that it is a
common case for the layer beneath to generate IP-related error
conditions, then it makes more sense to make (some of) the
current ICMP error messages extensible, as you suggested.
Does this make any sense to you or am I just muddling the waters?
--Pekka
_______________________________________________
Int-area mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/int-area
