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