Re: [mpls-tp] Comments on draft-nitinb-mpls-tp-on-demand-cv-00

[Mach Chen <[e-mail]>]

Hi Nitin,

Thanks for your reply!

Please see inline...
--------------------------------------------------
From: "Nitin Bahadur" <[e-mail]>
Sent: Thursday, June 24, 2010 5:34 AM
To: "Mach Chen" <[e-mail]>om>; <[e-mail]>
Subject: Re: [mpls-tp] Comments on draft-nitinb-mpls-tp-on-demand-cv-00

> Hi Mach,
>
> On 6/21/10 8:47 PM, "Mach Chen" <[e-mail]> wrote:
>> Some comments or questions below:
>>
>> 1. Reverse path Connectivity verification(Section)
>> It says:"For bi-directional LSPs, when the egress sends the echo 
>> response,
>> the egress MAY attach the target FEC stack TLV [RFC4379] in the echo
>>    response.  The ingress (on receipt of the echo response) can use the 
>> FEC
>> stack TLV to perform reverse path connectivity verification..."
>> But in RFC 4379(Section 4.5), it says "...The FEC Stack TLV from the echo
>> request MAY be copied to the reply...", so based on the current LSP Ping
>> specification and the existing implementations, the ingress will 
>> interpret
>> the FEC Stack TLV is for the forward direction LSP.
>> For co-routed bidirectional LSP, since the FECs for both directions are 
>> the
>> same, this is OK to re-use the FEC stack TLV for reverse path CV. But for
>> associated bidirectional LSP, when the ingress received the echo reponse
>> with a FEC stack TLV, how does it determine whether the FEC is of the
>> forward direction or backward direction?  IMHO, it's better to use 
>> separate
>> FEC stack TLV for each direction, especially for associated bi-dir LSP.
>
> You are right that there might be some confusion. I'll look into this.

OK.

>
>> 2. MPLS-TP LSP trace
>> It seems that the current draft does not consider associated 
>> bi-directional
>> LSP scenarios where each direction may follow diverse paths and some MIP
>> nodes can not send echo reponse along the reverse lsp directly. So there 
>> may
>> be need some return path specified mechanisms to help associated
>> bidirectional LSP tracing.
>
> In non-error cases, I believe all MIPs should be able to send the response
> back on the reverse lsp path. In error cases, a MIP might be unable to 
> send
> the response (because of the fault). In such a case, the first MIP which 
> is
> unable to send the response back is the MIP where the fault is. The spec
> currently says that we must reply using application control channel. We 
> can
> make that a should, so that if one wants, one can ask that the reply be 
> sent
> via UDP....if there is another available path in the network.

IMHO, even if in non-error cases(for associated bidirectional LSP), the MIPs 
response may not be able to send the response, see the figure below:
A---B---C---D---E
 \             /
  F----G------H
A associated bidirectional LSP combined with two unidirectional LSPs( LSP1: 
A->B->C->D->E, and LSP2: E->H->G->F->A), when the trace request reach at B, 
how does node B send the response? there may not be direct return path from 
B to A (including IP or LSP path), the only way to send the response is 
continue to send the response along LSP1, and round back at E and then send 
along LSP2 back to A. In order to achieve this, IMHO, there need some 
information to direct node B and node E to send the response, including:
1. whether can send the response along the non-in-band path or not
2. how to send the response along the round-path; and if there exist both 
direct return path from a MIP to the ingress and round-path, how to 
determine which path should be used.

Best regards,
Mach