Comments below... Pekka Nikander wrote: > 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 address > > 2. 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.
IMO, it resembles tunneling. Tunnels MAY decrement the TTLs of IP packets, though most reasonable systems require the decrement (1 or more) to occur in IP processing at the tunnel entrypoint, to avoid exactly the kind of confusion that MPLS is causing here. Most of the issues above, notably 1, 2, and 5, are not IP nor ICMP's responsibility, but an inadequacy of MPLS. > It is an interesting question whether that has been an architecturally > sound approach, but that is where we *are* now. Agreed, but where we are now doesn't necessitate usurping ICMP's functionality in the IP space to support MPLS's inadequacies, IMO. >>> 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. AOK. Again, a failure of MPLS, though. >> 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. Will do - IMO, the approach suggested in my followup message is at least tolerable, by really supporting backward compatibility while still trying to retain new capabilities (the one that sends two ICMPs back). I would still prefer that MPLS fix its own mess (make its own signalling layer, and fix the source address issue) rather than (expletive deleted)-ing on our working protocols in ways that break current specs. Joe
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
