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

[Mach Chen <[e-mail]>]

Hi Greg,

Thanks for your reply!

If we could restrict the application scenarios of associated bidirectional 
in MPLS-TP network, I agree with you! And IMHO, it's better to clarify this 
somewhere.

Best regards,
Mach

--------------------------------------------------
From: "Greg Mirsky" <[e-mail]>
Sent: Friday, June 25, 2010 10:21 AM
To: "Mach Chen" <[e-mail]>
Cc: "Nitin Bahadur" <[e-mail]>et>; <[e-mail]>
Subject: Re: [mpls-tp] Comments on draft-nitinb-mpls-tp-on-demand-cv-00

> Dear Mach and All,
> you've said "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."
> In my understanding that requires that MIPs of associated bi-directional 
> LSP
> must be aware of relationship and pairing between forward and reverse
> directions of the LSP. As I recall such understanding is only "MAY". I 
> don't
> see problem that some troubleshooting mechanism would not be able to work 
> in
> MPLS-TP network if there is no functional DCN.
>
> Regards,
> Greg
>
> On Thu, Jun 24, 2010 at 4:26 AM, Mach Chen <[e-mail]> wrote:
>
>> 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
>>
>>
>> _______________________________________________
>> mpls-tp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>
>