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

[Greg Mirsky <[e-mail]>]

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
>