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

[Mach Chen <[e-mail]>]

Hi Mukund,

Please see inline...

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

> Hi Mach
>
> Thanks for the response.. So in that case the BFD session initiator shall
> include the Session Control TLV in the Echo Request only when the
> bidirectional LSP is to be protected in a co-ordinated fashion.

Yes.

>
> You also mention in the draft that
>
> "If there is no Session Control TLV carried in the echo request, it's up 
> to
> the egress LSR to decide whether to initiate another BFD session for the
> backward direction LSP"
>
> Does this imply that when a Session Control TLV is not included by the 
> peer,
> it can still end up in one BFD session?? (based on the egress LSR's
> decision)

There is one more sentence you did not quote: "..this is the same as the 
definition in [BFD-MPLS]."
So, if there is no session Control TLV included, the procedure is same as 
current BFD for MPLS specification. The BFD session is only trigered by the 
configuration/policy at the egress, it does not relate to whether it 
received a LSP Ping bootstrap message.

Best regards,
Mach

>
>
>
> With Regards
> Mukund
>
> On Thu, Jun 3, 2010 at 11:17 PM, Greg Mirsky <[e-mail]> 
> wrote:
>
>> 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
>>>
>>
>>
>