The MPLS WG Archive

[Kireeti Kompella <kireeti@juniper.net>]

Hi David,

On Wed, 16 Oct 2002, David Allan wrote:

> 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.

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?

> 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.

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.

> 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)

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
> not welcome really dumb replay attacks at some point in the future) is that
> the sequence number always increments, and the receivers discard duplicates.

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.

> 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.

See reply to other email.

> 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?

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).

> I presume the use of internal loopback address range is to address ECMP, and
> anything periodically pinging should be monotonically increasing the
> address.

Yup.

> 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.

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
> be characterized or one can be sure that this will actually test everything.

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
> 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?

Will fix.

Thanks!

Kireeti.