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

Hi Greg and Mach

Although associated bidrectional LSP is defined in MPLS-TP network, there 
is no reason it can not be used by traditional MPLS networks. In order to 
do this, it just need to send Path refresh message carring the Association 
object, and the procedure is descirbed in 
draft-zhang-mpls-tp-rsvpte-ext-associated-lsp. Furthermore, Other possible 
solutions, like as GMPLS Calls and LSP_TUNNEL_INTERFACE_ID object have 
been mentioned in draft-ietf-ccamp-mpls-tp-cp-framework.

Requirements said the transit node SHOULD be aware the relationship, and 
it can be done by the methods mentioned above. 

So in my opinion, the scheme described by Mach is workable, but the 
operation is a little complicated....

B.R.

Fei

Mach Chen <mach@huawei.com> 
发件人:  mpls-tp-bounces@ietf.org
2010-06-25 12:06

收件人
Greg Mirsky <gregimirsky@gmail.com>
抄送
mpls-tp@ietf.org
主题
Re: [mpls-tp] Comments on draft-nitinb-mpls-tp-on-demand-cv-00

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" <gregimirsky@gmail.com>
Sent: Friday, June 25, 2010 10:21 AM
To: "Mach Chen" <mach@huawei.com>
Cc: "Nitin Bahadur" <nitinb@juniper.net>et>; <mpls-tp@ietf.org>
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 <mach@huawei.com> wrote:
>
>> Hi Nitin,
>>
>> Thanks for your reply!
>>
>> Please see inline...
>> --------------------------------------------------
>> From: "Nitin Bahadur" <nitinb@juniper.net>
>> Sent: Thursday, June 24, 2010 5:34 AM
>> To: "Mach Chen" <mach@huawei.com>om>; <mpls-tp@ietf.org>
>> 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" <mach@huawei.com> 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
>> mpls-tp@ietf.org
>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>
> 
_______________________________________________
mpls-tp mailing list
mpls-tp@ietf.org
https://www.ietf.org/mailman/listinfo/mpls-tp