The MPLS WG Archive

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

Hi Kireeti:

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

yes, that works... however I wasn't clear in that I munged two thoughts
together. IMHO an LSP PING PDU that is not associated with the top label
should be discarded when TTL expires (and that can happen in uniform model),
unless folks think we are doing GTTP as well here. 

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

I'll think about it. IMHO, the combination of ECMP, rate of change of the
127. address, number of sources pinging away, amount of ECMP encountered,
rate limiting at receivers etc. manifests itself in an unbounded detection
time for some problems. You are right that text to describe it is a rat
hole, so is bounding the detection time (which fits my definition of
reasonable).

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

Understood ;-), but it still seems rather redundant, I can also just
increment and say I got answers to 6,7,8,12 and 15.
> 
> > 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.

And in no reply mode, the receiver presumably may track sequence numbers,
and without a history of how many duplicates the sender sent, cannot infer
anything meaningful. IMHO use of duplicates inherently loses useful
information.

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

OK, missed that.

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

You seem to be suggesting that in the LDP case the actual name of an LSP is
the specification of forwarding rules associated with it (or more directly,
the cumulative specification of forwarding rules that the sender chooses to
use), OK for LDP. So then what LSP-PING sends is not the FEC but the name of
the LSP, in the RSVP case it is sending the name. So the logic appears to be
reversed and the term should not be FEC but "name".

Shakespeare's rose is a rose is fine by me, if we are consistent. If we want
to call names FECs fine by me, but lets pin down one immutable definition
for this document at the beginning that identifies the current
interpretation of the term FEC at the time of writing. 

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

The example that came to mind, is that I have multiple ECMP points I
traverse in sequence, and they have the same fan out, then what hashes to
choice "two" after the first, will pathologically hash to choice "two" at
all subsequent ECMP points. Mind you, if they all implement unique
algorithms or use additional local information to ensure a unique result,
this problem doesn't exist, but proving you actually can exercise all
potential paths from a single upstream point is a bit tricky.

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

I think some degree of specification (at least with respect to behavioural
properties) that vendors may choose to support or not support is useful for
providers. In particular when it impacts the testability of their network.
Thats the goal of the load balancing guidelines draft I posted not that long
ago. Folks who want certain testability may wish to cap the open endedness
of ECMP behavior, some may not.

> 
> > Section 4.3: Some useful guidelines as to IP addresses NOT 
> to respond to
> > might be a good idea.
> 
> ?
There are no representations as to source addresses that should be
inadmissable, while we have lots of experience with ICMP on things that are
currently filtered (such as smurf attacks and the like). Current security
concerns seem to simply focus on DOS attacks associated with volume of
messaging and not attacks that get the network to actually generate that
volume....

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

thanks
Dave