-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Pekka Nikander wrote: > Joe, > > There are two separate issues here: > > - creating a document for the current practise, with strong > enough disclaimers and at the same time trying to do it > as "right" as possible > > - doing the right thing for IPv6 > > AFAIK, Ron is working on a new version of the current draft to > include comments from the discussion here, and to add a field > to the reserved field to make the extension a little bit better > in syntactical terms. I've promised to review and help him once > he gets a reasonable version. > > I am not aware of anyone working on the IPv6 issues. I think > the MPLS WG should charter an item there is any real life > interest; otherwise it can wait, at least as far as I am > concerned. Before that we just must make sure that the > current IPv4 practise is NOT adopted for IPv6. > > 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. > 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). > Unfortunately my current understanding stops here. I still > don't know how to tell the difference between these two uses > of MPLS in practise, i.e., in the boxes in the running network. > And I still can't make my mind of what would really be the > right thing (for IPv6). > > Now, some more detailed comments: > >> I'm concerned about the issue of backward compatibility, >> notably the ways in which the use of the extensions >> proposed will cause existing ICMP processing to break, >> notably binding the length of the final field to 128 >> bytes, esp. considering RFC1812 recommends: > > IIRC, Ron provided us with some data indicating that in > *practise* not much is likely to fail. That's a statistical argument based on what subset of applications were examined; I don't care as much whether it DOES break as whether it CAN, and when it does, whether the error is detectable. That latter point is more critical; silently failing applications are a bad thing. > Hence, while I > fully agree with you that from the specs point of view, > the current MPLS practise a dubious one, it hasn't broken > that much in real life. > > What Ron and I are currently planning to do is to use the > reserved field (in those ICMP packets that have it) to > indicate the new syntax. The new syntax is not pretty > (and therefore should not be used for IPv6), but it is > compatible with the current usage. That sounds better - I did doublecheck RFC792, which does describe all reserved fields as set to zero by senders and must be ignored by receivers, which is a fine way to include new flags. Unfortunately, there is still the issue of silent failure of legacy systems in those cases. > >> Given that, it seems that this new variant of ICMP >> message (which includes headers before IP, rather than >> IP and thereafter - which is curious enough in itself) >> ought to demand a new message type, which necessitates >> use of the "Parameter Problem" code, or the definition of >> other new codes. Inside those, the new format that uses a >> list of pointers to include MPLS information might be >> appropriate. > > Yes, something like that should be done for IPv6. It would not > be that good to specify it for IPv4, as people are not likely > to do that large changes to their existing code. 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. >> Use of the "unused" area, as Ron suggested, seems >> inappropriate because those fields are not known to be >> 'cleared' by existing ICMP sources, so their value cannot >> be reliably used for flags IMO. > > I'll let someone with more information on this to answer > that. I have no real life data here. See above, and thus scratch that statement ;-) >> Individual informational drafts describing existing >> practice seem OK, but to do so within an IETF WG seems >> in appropriate when the practice is in violation of >> existing specs, as this is. > > If violating the existing specs has proven not to cause > any real life problems (which I believe is the case here), > it may be better to change the specs than to expect the > real life to change. Agreed. But this document isn't described as a change to the specs; it's described as an extension with backward compatibility. >> At the least, there needs to be much more strong and >> clear wording that this technique is in violation of >> those specs and will thus cause problems with compliant >> applications. > > Yes, we fully agree with that and AFAIK Ron is working > to address that. > >> That said, I'm still very unclear on why ICMP is the >> right protocol to usurp for this purpose > > I think I addressed this already above. > > What comes to your next message, I think they are good > starting points were we to start making a spec for > ICMPv6. AOK. Thanks, Joe > > --Pekka > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDIFk4E5f5cImnZrsRAjd+AKDhjhjZGi6h+Xcw73I33MNo4jJvTwCfW9hp 1MODrDDXqQm8Q7RLfLg0tTU= =CCyA -----END PGP SIGNATURE----- _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
