Re: [mpls-tp] Query on draft-chen-mpls-bfd-enhancement-01

[Mach Chen <[e-mail]>]

Dear Greg,

Thanks for your response!

Although co-routed bidirectional LSP may also has assymetric BW for each 
direction and be protected and swithed for each direction in theory, I 
basically agree with your analysis about co-routed bidirectional LSP, it 
does not seem practical, one direction of a co-routed bi-dir LSP broken, 
usually means the other direction of the LSP is broken too, and of cause the 
whole LSP is actually broken even if one direction may be OK. So requiring a 
co-routed bidirectional to be operated as a single entity is reasonable.

What I mean they should be treated as the same construt is from the view of 
protection switching, now that it is called and used as a bidirectioanl LSP, 
it is resonalbe to be protected and switched as single LSP. But since an 
associated bi-dir LSP is combined with two different LSPs and each LSP has 
its own fate, when one LSP is broken, usually the other LSP is OK, and from 
the view of the whole associated bi-dir LSP, it is non-workable now and 
should be switched to another protection associated bi-dir LSP(if not, why 
we need to combine the two unidirectional LSP into a bidirectional LSP?).

>From the view of fault localizaion and associated bi-dir LSP 
re-construction, we should better know which component LSP is broken, hence 
independent BFD session for each component LSP is necessary.

Best regards,
Mach
--------------------------------------------------
From: "Greg Mirsky" <[e-mail]>
Sent: Friday, June 04, 2010 1:47 AM
To: "Mach Chen" <[e-mail]>
Cc: "Mukund Mani" <[e-mail]>om>; <[e-mail]>rg>; 
<[e-mail]>rg>; <[e-mail]>
Subject: Re: [mpls-tp] Query on draft-chen-mpls-bfd-enhancement-01

> Dear Mach,
> I very much agree with your view that "It depends on how you want each
> direction of a bidirectional LSP to be operated [GIM>> perhaps "protected"
> is closer] (independent or coordinated). If you want each direction of the
> bidirectional LSP to be protected and switched independently, there should
> be separate BFD session for each direction, or only one BFD session is
> needed."
> But I'd differ that associated and co-routed bidirectional LSP should be
> viewed as the same construct. They certainly may be viewed this way but I
> wouldn't see that as "should". If, for example, associated bidirectional 
> LSP
> has assymetric BW for each direction, it would might be reasonable to have
> two independent BFD sessions and protect each direction independently. At
> the same time, bidirectional linear LSP will always be co-routed and using
> independent BFD session for each direction and independent protection
> doesn't seem practical.
> And I agree that BFD control mechanism is needed. I think it can be part 
> of
> overall OAM control mechanism that is being worked on by CCAMP WG (I've
> added the CCAMP to the discussion).
>
> Best regards,
> Greg
>
> On Thu, Jun 3, 2010 at 2:49 AM, Mach Chen <[e-mail]> wrote:
>
>> Hi Mukund,
>>
>> Please see inline...
>>
>>
>> --------------------------------------------------
>> From: "Mukund Mani" <[e-mail]>
>> Sent: Thursday, June 03, 2010 3:40 PM
>> To: <[e-mail]>om>; <[e-mail]>
>> Subject: Re: Query on draft-chen-mpls-bfd-enhancement-01
>>
>>
>>  Hi Mach
>>>
>>> Maybe "BFD session set-up in progress" ??
>>>
>>
>> Sounds better!
>>
>>
>>
>>> Also you mention:  "The case you described *maybe* occur"
>>> As for me this will *always* occur if I configure both the ends in 
>>> Active
>>> mode, because enabling BFD would initiate the LSP Ping for BFD 
>>> bootstrap.
>>> Am I correct on this?
>>>
>>
>> A node (with smart implementation) with lower IP address should not
>> initiate the LSP Ping for BFD bootstrap for the LSP(s) if it has already
>> received an LSP Ping. So it depends on which end will firstly initiate 
>> the
>> LSP Ping.
>>
>>
>>
>>> On the whole I have had another question for quite some time which I 
>>> have
>>> been asking in the MPLS-TP group also.
>>> My question was w.r.t the draft-asm-mpls-tp-bfd-cc-cv-04 which defines
>>> CC/CV
>>> and RDI mechanism using BFD and relates the number of sessions to
>>> protection
>>> switching architectures. But I would like to co-relate the details here 
>>> to
>>> have a clear understanding on the BFD operation itself...
>>>
>> I totally agree with you on this. Although protection switching is 
>> normally
>> based on BFD detection results, but, IMHO, the number of BFD sessions 
>> should
>> not closely coupled with the protection switching types(e.g., 
>> 1:1,1+1...).
>>
>>
>>
>>> For co-routed bi-directional LSP the forward and reverse path will be
>>> associated at the LER's. Also the same relationship exists for forward 
>>> and
>>> reverse path of associated bi-directional LSP's in the LER's and the
>>> common
>>> LSR's.
>>>
>> My understanding of co-routed bi-directional LSP is that it "associated" 
>> at
>> all nodes(including LERs and LSRs) along the LSP.
>>
>>
>>
>>> So why cant I use this inherent relationship to decide whether to have a
>>> single or two BFD sessions for a bidirectional LSP?
>>>
>> I am not sure what's your meaning about the inherent relationship. Do you
>> suggest: one BFD session for co-routed bi-dir LSP and two BFD sessions 
>> for
>> associated bi-dir LSP, or just one BFD session for bi-dir LSP (no matter
>> what co-routed or associated)?
>>
>> For co-routed and associated bidirectional LSP, IMHO, they should be
>> treated as the same construct. From the view of their clients, there is 
>> no
>> difference between the co-routed and associated bidirection LSP. Why 
>> there
>> requires associated bidirectional LSP, that is becase there is no 
>> co-routed
>> bidirectional LSP(e.g., the devices do support yet) and bidirectional 
>> LSPs
>> are desired. Now that we have associated two unidirectional LSPs into one
>> associated bidirectional LSP, it is logically to treat it as a real
>> bidirectional LSP. That means, there should be no difference in 
>> protection
>> switching between co-routed and associated bidrectional LSP.
>>
>>
>>  Basically trying to figure out the need for the explicit mechanism
>>> using Return Path TLV and Session Control TLV mentioned in the draft
>>> "draft-chen-mpls-bfd-enhancement-01".
>>> I agree that for a pair of Uni-directional LSP's, using Return Path and
>>> Session Control TLV might be useful but why do we need this for 
>>> associated
>>> and co-routed LSP?
>>>
>>
>> It depends on how you want each direction of a bidirectional LSP to be
>> operated (independent or coordinated). If you want each direction of the
>> bidirectional LSP to be protected and switched independently, there 
>> should
>> be separate BFD session for each direction, or only one BFD session is
>> needed.
>>
>> In our draft, if the LSP is bidirectional(co-routed or associated), there
>> is no need to carry the Return Path TLV, only Session Control TLV is
>> required, which is used to control how many BFD sessions should be setup
>> over the LSP. IMHO, if we want the LSP could be operated either as
>> independent or coodinated, a BFD session control mechanism(using Session
>> Control TLV or other means(e.g., in MPLS-TP scenario, using a bit of GACh
>> flag field)) is needed.
>>
>> Best regards,
>> Mach
>>
>>
>>
>>> With Regards
>>> Mukund
>>>
>>> On Tue, Jun 1, 2010 at 3:03 PM, Mach Chen <[e-mail]> wrote:
>>>
>>>  Hi Mukund,
>>>>
>>>> Sorry for the delay response!
>>>>
>>>> The case you described maybe occur, and strictly speaking, it is not 
>>>> very
>>>> accurate to mention that the "Backward direction BFD session exists" as
>>>> return code, how about "BFD session collision"? or do you have any 
>>>> other
>>>> suggestions?
>>>>
>>>> Best regards,
>>>> Mach
>>>> --------------------------------------------------
>>>> From: "Mukund Mani" <[e-mail]>
>>>> Sent: Monday, May 31, 2010 3:04 AM
>>>> To: <[e-mail]>
>>>> Subject: Query on draft-chen-mpls-bfd-enhancement-01
>>>>
>>>>
>>>> Hi
>>>>
>>>>>
>>>>> Have a query w.r.t "draft-chen-mpls-bfd-enhancement-01". Could the 
>>>>> draft
>>>>> authors kindly clarify the same:
>>>>>
>>>>> Section 4 on session establishment mentions the following:
>>>>>
>>>>> If node with the larger IP receives LSP ping
>>>>> message signaling BFD session with Session Control TLV, LSP ping
>>>>> reply must be transmitted with "Backward direction BFD session
>>>>> exists" to the ingress LSR.
>>>>>
>>>>>
>>>>>
>>>>> In the case of BFD session provisioned on both nodes in the Active
>>>>> mode, the LSP Ping for the backward direction BFD session could be
>>>>> received even when the forward direction session is not yet
>>>>> established. In that case is it correct to mention that the "Backward
>>>>> direction BFD session exists" as return code?
>>>>>
>>>>>
>>>>> Kindly let me know if I am missing something here...
>>>>>
>>>>>
>>>>> With Regards
>>>>>
>>>>> Mukund
>>>>>
>>>>>
>>>>>
>>>  _______________________________________________
>> mpls-tp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mpls-tp
>>
>