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

[Greg Mirsky <[e-mail]>]

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
>