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

[Greg Mirsky <[e-mail]>]

Dear Mach,
I have to correct my previous assumption. Per #12 of RFC 5654 transit nodes
of bi-directional associated LSP SHOULD be aware of forward and backward
direction relationship.

Regards,
Greg

On Fri, Jun 25, 2010 at 12:06 AM, Mach Chen <[e-mail]> wrote:

> 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
>>>
>>>
>>