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

[Mukund Mani <[e-mail]>]

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.

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)



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