Subject: RE: RE: Latest MPLS Ping draft...

From: "David Allan" <[email-masked]>
Date: Wed, 16 Oct 2002 16:11:31 -0400

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

---

From: Kireeti Kompella <[email-masked]>
Date: Wed, 23 Oct 2002 12:44:20 -0700 (PDT)

Hi David,

On Wed, 16 Oct 2002, David Allan wrote:

> TTL exhausts and is not payload of the top label simply be discarded.

The most common instantiation of a non-compliant router is one whose
software hasn't been upgraded to know about LSP ping.  It doesn't seem
reasonable to make requests of such routers to know enough about LSP
ping to discard LSP ping packets whose TTL has expired.

On the other hand, for a router that knows about LSP ping but say doesn't
implement the traceroute mode, it may make sense to say what to do with
ping packets whose TTL expired.  But since senders have to deal with
TTL-expired ICMP anyway, it seems to somewhat redundant (IMO).

It would make sense to state that *compliant* routers that reply to
a LSP "traceroute" SHOULD NOT also send a TTL-expired ICMP.  That work
for you?

> proportion to network diameter.

What constitutes "reasonable time" depends entirely on the SP and
their customers.  I'd personally rather not go down that rathole.
If you have text, you can bounce it off the mailing list and we can
try to incorporate it.

> fives and 2 sevens)

Actually, "I got an answer to five and an answer to seven" is sufficient
(where "an" means at least one).

> Seems to me that a superior approach (and one that does

An unstated goal is that (as far as possible) the receiver keep as
little state as possible.  The sender needs to keep state, so the sender
can discard duplicates.  Note that the technique of sending multiple pings
with the same sequence number is not mandatory.

> map or some other format that allows multiple outcomes for a probe.

See reply to other email.

> or administered attribute of an LSP that should be verified?

Note that LDP FECs are not FECs, but names of FECs (reminiscent of
Alice's conversation with Tweedle-dee?  the Caterpillar? on names vs.
what things are called).

> address.

Yup.

> This is great if there is only one instance of ECMP downstream of
> the PING packet.

Actually, this works (to the extent it works at all) with any number
of ECMP points.  Do you have a counter-example?

> Currently ECMP is proprietary, so I am not sure if this can

I am sure this won't test everything.  I am equally certain that the
IETF is not the place to standardise ECMP (IMO) -- in fact, I don't
personally believe that ECMP should be standardized.

> Section 4.3: Some useful guidelines as to IP addresses NOT to respond to

?

> mentioned. Why the reference to using explicit NULL with ICMP here?

Will fix.

Thanks!

Kireeti.