The MPLS WG Archive

["David Allan" <dallan@nortelnetworks.com>]

Title: RE: RE: Latest MPLS Ping draft...

Hi:

There were a comment I raised previously that was not addressed...

section 4.5: Non-compliant routers. In general the topic of TTL came up earlier, as there is no explicit mention of that happens when testing a path that uses the uniform instead of the pipe model. Consistent with the expectation of non-compliant routers, shouldn't any LSP PING request that TTL exhausts and is not payload of the top label simply be discarded. If agreement breaks out, this should be documented.

And some new questions:

Section 2: Motivations: A bit more discussion of what consistutes a "reasonable time" and what factors affect this would be useful. In some applications such as LDP/ECMP etc. detection time would appear to be in proportion to network diameter.

Section 3: When discussing "no reply" processing, the suggestion is that the egress router may track sequence numbers etc. This looks rather optimistic and is not exactly consistent with the application of port rate limiting at the egress and how use of LSP ping with MP2P will work when deployed. Similarly, the ingress issuing multiple messages with the same sequence number in hope that the egress will respond to one of them seems rather perverse. Presumably the egress can similarly reply to all of them hoping the ingress will see one of them. How does one track this (lets see, I got 3 fives and 2 sevens) Seems to me that a superior approach (and one that does not welcome really dumb replay attacks at some point in the future) is that the sequence number always increments, and the receivers discard duplicates. Otherwise one end may actually implement only monitonic increase of sequence numbers while the other end resends multiples, seems to me there is an interoperability issue here if one expects to infer anything meaningful from sequence number tracking.

The reply codes still strike me as incomplete as an ENUM instead of a bit map or some other format that allows multiple outcomes for a probe.

Section 4.1: It seems to be a bit of a misnomer to call an RSVP Session ID object an FEC. Could we user another term if it is simply any configuration or administered attribute of an LSP that should be verified?

I presume the use of internal loopback address range is to address ECMP, and anything periodically pinging should be monotonically increasing the address. This is great if there is only one instance of ECMP downstream of the ping source. Any comments on when multiple ECMP points are traversed by the PING packet. Currently ECMP is proprietary, so I am not sure if this can be characterized or one can be sure that this will actually test everything.

I can't envision using traceroute mode with don't reply, but that appears to be a valid option.

Section 4.3: Some useful guidelines as to IP addresses NOT to respond to might be a good idea.

Section 5.3: Other than being modelled on ICMP, it has otherwise not been mentioned. Why the reference to using explicit NULL with ICMP here?

cheers
Dave