Pekka,
Thanks again for these very thoughtful comments. It appears that we have
converged on a solution regarding syntax. However, the architectural
questions is still before us.
I think that the architectural question can be decomposed as follows:
a) What information should ICMP messages carry?
b) Is the MPLS label stack part of that information?
Although RFC 792 is not specific regarding the first question, I think
that we can assume the authors' intent. That is, they meant to restrict
ICMP to layer 3 information, excluding layers 1 and 2.
So, in order to answer part b of the architectural question, we must
determine whether MPLS belongs strictly to layer 2, strictly to layer 3,
or some intermediate layer that overlaps both layers 2 and 3.
If MPLS belongs strictly to layer 2 (like Ethernet), MPLS information
should be excluded from ICMP messages. However, if one were to argue
that MPLS belongs strictly to layer 2, one would also have to argue that
the relationship between IP and MPLS is already fraught with multiple
layer violations. For example:
- MPLS signaling protocols (LDP and RSVP) rely upon IP
- TTL values are copied between the IP and MPLS headers
- LSRs emit ICMP messages when the MPLS TTL expires
So, we might want to allow MPLS information in ICMP messages for no
reason other than to be internally consistent with the otherwise
intermingled relationship between IP and MPLS.
So, I would like to propose the following:
We split draft-ietf-mpls-icmp into two drafts. The first draft describes
a syntactic mechanism for extending ICMP messages. It talks about the
new length attribute, a common header and a common object header.
However, it doesn't define any objects. The Internet Area owns this
draft and it is intended for publication as PS.
The second draft references the first and will describes the MPLS Stack
Entry Object. The MPLS WG owns this draft and it is intended for
publication as INFORMATIONAL. It contains an architectural statement
explaining that layer 2 information is not included in ICMP messages,
but MPLS information is allowed in order to be internally consistent
with the otherwise intermingled relationship between MPLS and IP.
Ron
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
