Subject: Comments on LSP-PING-03

From: "David Allan"<[email-masked]>
Date: Tue, 26 Mar 2002 16:40:01 -0500

Hi guys:

Comments on LSP-PING-03. 

I'm working through tracing an FEC. I am in agreement with the basic
diagnostic approach, but have a few concerns/nits/suggestions:

1) Use of uniform TTL model. TTL times out at a node where the labels are
more than one level deep, this is one I've consistently found messy as the
TTL exhausting LSR technically has no knowledge of the payload a few labels
away...
If you assume that I can pop all the labels, find an LSP-PING message, and
interpret it, you'd then need an error code of "not top label" as I
potentially have no relevant knowledge of the FEC, and nothing is wrong.

2) Similarly I am not sure the set of errors is sufficiently descriptive and
needs interpretation where more than one thing can be true (this could be
split into about three or four separate status indicators):
	- router is (egress/intermediate)
	- router is (downstream, not downstream)
	- FEC is (correct/incorrect/unknown) for incoming label
	- router is (same level/different level) (see #1 above)

It is not clear to me that anything extra is required for bi-directionality.
If it fails, and I traceroute it with normal v4 return, I'll either
sectionalize the problem via no return (it black holes past a certain
point), or stuff misbranching such that a LSP-level return path does not
exist but I get IP notification anyway (which should manifest itself as
incorrect FEC).

3) Target FEC stack types, presume #7 is VPN v6 prefix. Not sure as to the
applicability of the VPN prefixes, as a given layer does not know it is a
VPN. FECs SHOULD be inferrable by the level stuff arrives on. If we are
suspecting misbranching between levels, then adding an addressing authority
may be a simpler way to go than trying to mix application semantics with the
tool. I'm testing VPN, I'm testing transport. One persons transport is
another persons VPN.

4) Not sure why the FEC stack is copied from a request to a reply. The
message already has a sequence number that permits a request to be
associated with a reply. This would seem to be a redundant processing step
unless the goal is to imbed all the state in the message (trade bandwidth
for RAM).

5) Downstream LSR. Not clear to me if the draft is discussing liberal label
retention or inverse multiplexing. If this is liberal label retention, then
it would be useful to tag the currently preferred label, that way I know if
there are routing changes going on during the test. If it is inverse
multiplexing (my guess is that this is the case), then it needs an
additional TLV in the reply to identify the incoming label so that I have a
means of determining if I have exercised the set of downstream labels.
Merely telling me that it worked is not sufficient as I can have partial
failure and would want to isolate it further. This would be esp. true if the
muxing heuristic was pathological for LSP-PING messages and only tested one
label (one of those packet ordering hashes that for a given src-dest pair,
always selects the same LSP).

6) IMHO the security considerations needs a bit of re-work. But then i've
not recent read the RSVP stuff ;-)

7) Should be trivial to extend this into CR-LDP as well.(comment on sect
5.2)

cheers
Dave