-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I had a question about the current state of draft-ietf-mpls-icmp-03:
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: Therefore, the ICMP datagram SHOULD contain as much of the original datagram as possible without the length of the ICMP datagram exceeding 576 bytes 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 necessatates 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. 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. Pekka wrote: > 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? 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. 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. That said, I'm still very unclear on why ICMP is the right protocol to usurp for this purpose, as Pekka suggests later: > 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. I agree completely ;-) Joe -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDH1KxE5f5cImnZrsRAqe+AKDKllFLESaMIakaSrxNfYxzeOCh/ACgiUEQ BByuBusXLSJIjV7e5jg6kg8= =Kj1s -----END PGP SIGNATURE----- _______________________________________________ Int-area mailing list [email protected] https://www1.ietf.org/mailman/listinfo/int-area
