Subject: Re: Query on draft-chen-mpls-bfd-enhancement-01

From: Mach Chen <[email-masked]>
Date: Tue, 01 Jun 2010 17:33:34 +0800

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" <[email-masked]>
Sent: Monday, May 31, 2010 3:04 AM
To: <[email-masked]>
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
>

---

From: Mukund Mani <[email-masked]>
Date: Thu, 3 Jun 2010 13:10:12 +0530

Hi Mach

Maybe "BFD session set-up in progress" ??

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?

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

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.

So why cant I use this inherent relationship to decide whether to have a
single or two BFD sessions for a bidirectional 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?

With Regards
Mukund

---

From: Mach Chen <[email-masked]>
Date: Thu, 03 Jun 2010 17:49:09 +0800

Hi Mukund,

Please see inline...

--------------------------------------------------
From: "Mukund Mani" <[email-masked]>
Sent: Thursday, June 03, 2010 3:40 PM
To: <[email-masked]>; <[email-masked]>
Subject: Re: Query on draft-chen-mpls-bfd-enhancement-01

> Maybe "BFD session set-up in progress" ??

Sounds better!

> mode, because enabling BFD would initiate the LSP Ping for BFD bootstrap.

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.

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

> reverse path of associated bi-directional LSP's in the LER's and the 
My understanding of co-routed bi-directional LSP is that it "associated" at 
all nodes(including LERs and LSRs) along the LSP.

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

> Session Control TLV might be useful but why do we need this for associated

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

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 3 Jun 2010 10:47:00 -0700

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 <[email-masked]> wrote:

> 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.
>
>
>
> 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
> 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
>>
>>  _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: Mukund Mani <[email-masked]>
Date: Fri, 4 Jun 2010 00:35:57 +0530

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 <[email-masked]> wrote:

>> 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...).
>>
>>
>>
>> My understanding of co-routed bi-directional LSP is that it "associated"
>> at all nodes(including LERs and LSRs) along the LSP.
>>
>>
>>

---

From: Mach Chen <[email-masked]>
Date: Fri, 04 Jun 2010 18:50:11 +0800

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" <[email-masked]>
Sent: Friday, June 04, 2010 1:47 AM
To: "Mach Chen" <[email-masked]>
Cc: "Mukund Mani" <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Subject: Re: [mpls-tp] Query on draft-chen-mpls-bfd-enhancement-01

>> normally
>> at

---

From: Mach Chen <[email-masked]>
Date: Fri, 04 Jun 2010 18:50:15 +0800

Hi Mukund,

Please see inline...

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

> bidirectional LSP is to be protected in a co-ordinated fashion.

Yes.

> it can still end up in one BFD session?? (based on the egress LSR's

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