Joe,
Now, taking a technical step back, the issues is pretty complicated since there are different uses of MPLS. In some cases MPLS is used more-or-less as a link layer protocol, and the argumentation that appeared here and that you continue holds pretty well. However, in other cases MPLS is used more as a source routing mechanism for IP. That is, instead of using the usual hop-by-hop IP routing based on routing tables created by a routing protocol, the MPLS ingress router (Label Edge Router) creates an MPLS "tunnel" (Label Switch Path) to the MPLS egress router, using the information from the very same routing tables.Note that in the latter usage the route that the IP packets take is exactly the same, using exactly the same routing information. Hence, there is no difference between plain IP routing and MPLS- based IP routing. The difference lies in the forwarding plane, where in plain IP case each box in the path examines the IP header and makes the forwarding decision based on it while in the MPLS case the forwarding decision is based on the MPLS label prepended to the IP packet. In other words, in the plain IP case the forwarding decision is done individually at each router (hop-by- hop forwarding decision) while in the MPLS case the forwarding decision is effectively done at the ingress router, in a sort-of source-routing fashion.In this case MPLS is equivalent to a tunneling mechanism; whereas it's OK to cache (i.e., bury) forwarding steps in a tunnel mechanism, it necessarily hides it from the IP layer.
Well, yes and no. There are a few things that complicate the situation: 1. MPLS header doesn't have the equivalent of a source address2. MPLS LSPs can be multipoint-to-point, meaning that later at the LSP it may be impossible to determine where the packet has entered the LSP. That is, the packet may have entered at any of a number of points.
3. In the cases we consider, the (multipoint-to-point) LSP has been created based on the IP routing table information.
4. The MPLS header may be a *stack*, i.e., contain an number of label headers stacked.
5. The current MPLS TTL mechanism effectively allows the *IP* TTL to be decremented at each LSR.
Considering 2, 3, and 5, the situation resembles more plain IP routing than tunnelling.
It is an interesting question whether that has been an architecturally sound approach, but that is where we *are* now.
So, while in some cases the approach where MPLS is seen as a link layer and we define new layer 2 specific ICMP messages (or even a different protocol) seems to be right, in the other cases it indeed appears to be the right thing to send an ICMP time exceeded, for example. The case really is that there is a routing loop.At best, it would be appropriate for the tunnel system to signal the error to the tunnel source (via its own mechanisms), which MAY use that error to trigger sending an appropriate L3 ICMP message back to the source, in the spirit of RFC2003 (IPIP tunneling).
AFAICT, that won't work because of 1 and 2 above. No source address, multiple entry points. No way.
IMO, anyone who cares enough about handling MPLS signals ought to extend the code to handle that case. Usurping exising code without changing the semantics means that you're MORE likely to end up with a silently- failing variant.
Please wait for the new draft. We are trying to address this, but maybe the text in the draft could be tightened up.
Agreed. But this document isn't described as a change to the specs; it's described as an extension with backward compatibility.
Note taken. Please see if the new draft addresses this better. --Pekka Nikander
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
