The MPLS WG Archive

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

Apologies for the format of the last post....


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