Subject: RE: Last call on LSP Ping

From: [email-masked]
Date: Thu, 5 Dec 2002 15:34:45 -0000

2nd set of comments on sections 2 and 3:

1	In section 2, 1st sentence says:
"When an LSP fails to deliver user traffic, the failure cannot always be
detected by the MPLS control plane.  There is a need to provide a tool that
would enable users to detect such traffic "black holes" or misrouting within
a reasonable period of time; and a mechanism to isolate faults."

Agreed with initial sentence.  But can you please help me understand:
-	what is a 'reasonable time'?
-	if variable then I assume we can't have operator/vendor-wide defect
detection/handling standardised, nor (un)availability definitions
standardised, nor QoS time-bases (ie when in available state)
standardised.....is this a correct interpretation?....or is some default
value being considered to allow this?
-	what consequent actions are taken before detection (I assume none)
and after detection, eg:
	* is traffic suppressed if misrouting detected to protect possible
customer traffic integrity/security compromise?
	* how are higher layer networks (eg ATM in case of ATMoverMPLS), and
specifically the trail termination points therein, informed that they should
not raise defect alarms?
	* what happens to the collection of any QoS metrics (at the LSP
sink) that may be being collected when defects are detected?

2	Last para in section 2 says:
"One way these tools can be used is to periodically ping a FEC to ensure
connectivity.  If the ping fails, one can then initiate a traceroute to
determine where the fault lies.  One can also periodically traceroute FECs
to verify that forwarding matches the control plane; however, this places a
greater burden on transit LSRs and thus should be used with caution."

Ping test will detect simple breaks (either direction....this then needs the
direction resolving of course).  Ping won't detect
misrouting/mismerging.....this requires tracing.  Agree it places burden on
all transit routers so should used with caution, eg ad hoc diagnostic tool.
CV (TTSI) caters for this by requiring only LSP sink points to automatically
detect/handle the defect (on seeing an incoming unexpected TTSI value), so
intermediate nodes are transparent to the CV pkt and so just treat it as
normal traffic  I point this out to show that there is a major difference in
complexity between this approach and that of Y.1711....so for p2p LSPs at
least, Y.1711 gives a far simpler solution to this defect detection/handling
problem.

3	Section 3 1st sentence says:
"An MPLS echo request is a (possibly labelled) UDP packet....".

Why is it only 'possibly labelled'?  I thought the intent was to force the
Ping traffic down the same data-plane as labelled normal traffic....so it
seems it must be labelled.

4	I note in the 'Reply Mode' (top p5) that a 'Do not reply' option is
given.  Reading the subsequent explanation this seems as though it's a 1-way
off-line stats (delay mainly?) gathering exercise.  This is OK, but it seems
a shame that we can't also associate some proper sink-point real-time defect
detection/handling....seems like it mimics some aspects of CV but with none
of the defect detection/handling ability.
-	I assume you have to poll the sink point every so often to see how
its doing?
-	what happens if you change the source pinging rate....do you have to
tell the sink about this?

5	In the same section.....can you please explain in a little more
detail why there are 2 IPv4/UDP (and no v6??) reply modes, one without
router alert set and one with router alert set?  The text seems to indicate
the latter is more reliable than the former.

6	In the same section......why is there an option to reply by the RSVP
control-plane?  What scenario is this addressing that the above don't?
Further, some guidance on when to select which option would be useful.

7	In the same section....I assume if a missed sequence number event is
detected, there is no ability to determine if this was the outgoing or
return direction?  How long does one wait before declaring a lost sequence
number anyway?  And does this vary with the return mode selected?

8	In the same section.....does the responding node copy the 'sent'
time-stamp from the echo-request to the echo-response?

9	In the same section....its seems some of the Return Codes are
relevant only to the Ping mode and some only to Trace mode.  I think it
would be useful to separate them (and also indicate if any are common to
both modes).

10	In section 3.1....I'm a little unclear about multiple FEC stacks.  I
seem to get the message from the text that a *single* response is only
elicited from the very bottom of the label stack (ie the highest level/layer
LSP sink point).  This seems OK under the restriction that for the FEC stack
considered, the corresponding multiple LSP trail termination points reside
on the same node....and in the VPN example given this is true.  Is this
restriction on FEC stacking and hierarchical LSP termination points correct?
And am I also correct in assuming only a single response is ever expected in
a stacked FEC case? (I noted Shahram has raised a very similar issue in his
points No. 4 and (although a slightly different issue) No. 6).

11	In section 3.2......Can the Downstream Mapping optional TLV be used
with an RSVP 'Reply Mode'?

12	In the same section.....There is the TTL decrement anomaly which
both Shahram and Dave have pointed out.  However, I think you need to expand
on the bit which effectively says 'how to determine downstream nodes is out
of scope' since, if I understand what is going on here correctly, this is an
attempt to trace misbranching traffic.  However, please correct me (and
enlighten me) if I am interpreting this section incorrectly.

13	In the same section....what is the PAD TLV function for?

Thanks.....more later...regards, Neil

---

From: Eric Rosen <[email-masked]>
Date: Fri, 06 Dec 2002 10:53:04 -0500

Neil> Ping  test will  detect simple  breaks (either  direction....this then
Neil> needs  the   direction  resolving  of  course).    Ping  won't  detect
Neil> misrouting/mismerging. 

This  statement does  not  appear to  me to  be  correct.  In  the event  of
misrouting, the Echo Request packet will be processed by an LSP egress which
isn't the  proper egress for  the indicated FEC.   This results in  an error
code 4  response indicating that  misrouting has occurred.  It  doesn't tell
you where the fault lies, but it does tell you that a fault exists.