The MPLS WG Archive

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

Title: Comments on LSP-PING-03

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