Subject: Re: Solicit comments on BFD for Interface draft

From: Thomas Nadeau <[email-masked]>
Date: Mon, 1 Aug 2011 09:08:02 -0400

On Jul 31, 2011, at 10:43 AM, Shahram Davari wrote:

> Hi Shane,
> 
> Same for BFD. You need to know my discriminator, your discriminator, local IP address, remote IP address, Min Tx Interval, Min Rx Interval, Demand mode, Authentication, Active/Passive, Detection Interval, etc.

	While those parameters are required, that doesn't mean that clever implementations can choose reasonable defaults for you. I know such implementations from at least 3 major vendors. *)

> Believe me BFD requires more configuration than 802.1ag. So your argument of requiring a lot of info to configure 802.1ag applies even more to BFD. 

	On paper perhaps, but in reality that is not the case.  I do not know of any implementations where MIP/MEP configuration is done automatically such as is the case for links and routing protocols in the major implementations using BFD.

	--Tom

> 
> Regards
> Shahram   
> 
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Shane Amante
> Sent: Saturday, July 30, 2011 9:36 AM
> To: Bhatia, Manav (Manav)
> Cc: [email-masked]
> Subject: Re: Solicit comments on BFD for Interface draft
> 
> Manav, Sharam, Others,
> 
> On Jul 29, 2011, at 5:34 PM, Bhatia, Manav (Manav) wrote:
>> I think the diagnoses is correct, but the medicine isn't! :-)
>> 
>> I completely agree that LACP is not fast enough and that operators also want to detect individual component link breakdowns instead of the entire LAG. If that's the case then folks should use IEEE 802.1ag for individual component links and BFD for the entire LAG. Are we trying to position BFD as an IETF equivalent of 802.1ag? Or is it that we're trying to run BFD over component links since not all links may be ethernet?
> 
> The main reason (we) operators want to use BFD instead of 802.1ag/Y.1731 (or 802.3ah) for *fast* detection of component-link failures in a LAG is: operational simplicity, clear and simple.
> 
> The problem with 802.1ag/Y.1731 is the massive amount of, potentially error-prone, configuration required.  Take a moment and think about how many variables are *required* to properly set-up 802.1ag/Y.1731:
> a)  What MD "name" should you use?
> b)  What MD "name format" should you use, (ASCII, DNS, etc.)?
> c)  What MD "level" should you use, (probably 0 or 1)?
> d)  What MEP ID's do I assign to each side of the link?
> e)  Don't forget to configure the right direction, up or down, for the MEP?
> ... that is *ridiculous*!
> 
> Let's not forget that there are [potentially] 100's if not 1,000's of LAG's in each carrier's network, so this needs to get repeated over and over and over again.  Bottom-line: 802.1ag/Y.1731 is extremely complex to set-up *and* maintain.  
> 
> BFD is simple.  At a bare minimum you just need to configure an "{Tx|Rx} interval".  (The "multiplier" should default to 3, unless you want to configure it differently). That's it!  Done!
> 
> So, in short, let me throw my hat in the ring with other operators that I really, really, really want a standards-based way of running BFD over component-links in a LAG in order to quickly detect a component-link failure and take it out of the bundle.
> 
> Thanks,
> 
> -shane
> 
> 
> 
>> I think (and this is also what Shahram was alluding to) that BFD is meant to detect IP liveliness. This means that if I run BFD over an IP interface it should bring it down only when the IP connectivity goes down. Shouldn't BFD be oblivious to the number of links alive in a LAG as long as the LAG remains up and it can reach the other end. It is a simple implementation effort to note the status of each component link of a lag and to bring it down if the number goes below a certain threshold - You don't need to run BFD over each link!
>> 
>> Cheers, Manav
>> 
>>> -----Original Message-----
>>> From: Marc Binderberger [mailto:[email-masked]] 
>>> Sent: Saturday, July 30, 2011 3:34 AM
>>> To: Bhatia, Manav (Manav)
>>> Cc: Jeff Tantsura; [email-masked]
>>> Subject: Re: Solicit comments on BFD for Interface draft
>>> 
>>> Hello Manav,
>>> 
>>> others have already replied but the part "[...] has no 
>>> business" triggers now my reply. I deliberately 
>>> "mis"-understand it. Point is that this is about business. 
>>> Customers have pushed their vendors to implement BFD over LAG 
>>> component links. Reasons I know
>>> 
>>> - LACP is not fast enough
>>> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco 
>>> Designers and Operations, so they would like to use it everywhere
>>> - BFDs reputation for being fast and working
>>> 
>>> 
>>> So now we have 3-4 different implementation for 
>>> per-cmponent-link BFD that I know about. Potentially there 
>>> exists more. Probably not that much different but enough to 
>>> make interoperability impossible. It's again customers who 
>>> push now for standardization. Thus the draft to find an agreement :-)
>>> 
>>> Will there be only one solution for "BFD over LAG"? Not sure 
>>> as I see two fundamental setups: (a) run BFD on every 
>>> component link  and (b) run a single BFD session over the LAG 
>>> interface. They solve different network setups as far as I can see.
>>> 
>>> 
>>> Regards, Marc
>>> 
>>> 
>>> 
>>> On 2011-07-29, at 4:18 AM, Bhatia, Manav (Manav) wrote:
>>> 
>>>> Hi Jeff,
>>>> 
>>>> Let me understand this. If you have an IP interface over a 
>>> LAG with 5 component links, then you internally establish 5 
>>> BFD sessions with 30ms timeouts?
>>>> 
>>>> You don't need to do this. You could use LACP for lag and 
>>> BFD for IP connectivity - which means BFD should remain up as 
>>> long as there is reachability over the lag. IMO it has no 
>>> business to bother with each individual component links. 
>>>> 
>>>> Cheers, Manav
>>>> 
>>>> -----Original Message-----
>>>> From: Jeff Tantsura [mailto:[email-masked]]
>>>> Sent: Friday, July 29, 2011 7:15 AM
>>>> To: Bhatia, Manav (Manav)
>>>> Cc: Mach Chen; [email-masked]
>>>> Subject: Re: Solicit comments on BFD for Interface draft
>>>> 
>>>> Hi,
>>>> 
>>>> We have been supporting this mode of BFD over LAG 
>>> operations for last 5 years and our customers love it.
>>>> 
>>>> Manav - imagine you have lost 3 out of 8 links but didn't 
>>> hit min-links, do you really want to bring the LAG down?
>>>> 
>>>> Mach - be aware of patents :)
>>>> 
>>>> Regards,
>>>> Jeff
>>>> 
>>>> On Jul 28, 2011, at 21:25, "Bhatia, Manav (Manav)" 
>>> <[email-masked]> wrote:
>>>> 
>>>>> Hi Mach,
>>>>> 
>>>>> I am not sure I understand why you would want BFD to 
>>> ensure liveliness of each component link in a LAG. The draft 
>>> seems to suggest establishing separate BFD session for each 
>>> pair of component interfaces to detect the failures. Why 
>>> should BFD be concerned about each component link? I would 
>>> rather that BFD sprays packets over each component link in a 
>>> round robin fashion and brings down the IP interface over a 
>>> lag only if it misses 3 consecutive packets. Am I missing something?
>>>>> 
>>>>> Cheers, Manav
>>>>> 
>>>>> -----Original Message-----
>>>>> From: [email-masked] 
>>> [mailto:[email-masked]] On 
>>>>> Behalf Of Mach Chen
>>>>> Sent: Friday, July 29, 2011 4:05 AM
>>>>> To: [email-masked]
>>>>> Subject: Solicit comments on BFD for Interface draft
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> We uploaded a new 
>>> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00) 
>>> that is about BFD running over interface(e.g., LAG/Bundle 
>>> interface). You are very welcome to read the draft and give 
>>> your comments.
>>>>> 
>>>>> Many thanks,
>>>>> Mach
>>>> 
>>> 
>>> --
>>> Marc Binderberger           <[email-masked]>
>>> 
>>> 
> 
> 
> 
>

---

From: Warren Kumari <[email-masked]>
Date: Mon, 1 Aug 2011 11:39:19 -0400

> 	While those parameters are required, that doesn't mean that clever implementations can choose reasonable defaults for you. I know such implementations from at least 3 major vendors. *)

+1

Yes -- and a lot of operators already use BFD in their networks, they are already familiar with the protocol, their tools already understand generation of configlets (and auditing), etc. It already "just works" -- having it run on component link seems like a no brainer....

---

From: Warren Kumari <[email-masked]>
Date: Mon, 1 Aug 2011 11:40:46 -0400

> The main reason (we) operators want to use BFD instead of 802.1ag/Y.1731 (or 802.3ah) for *fast* detection of component-link failures in a LAG is: operational simplicity, clear and simple.

+1.

> So, in short, let me throw my hat in the ring with other operators that I really, really, really want a standards-based way of running BFD over component-links in a LAG in order to quickly detect a…

Here's my hat too....

W

---

From: "Shahram Davari" <[email-masked]>
Date: Mon, 1 Aug 2011 10:16:19 -0700

Let's do the math:

BFD Tx direction:

My Discr: Auto assignment by SW
Your Discr: default to 0
Remote IP add: need to configure
Min Tx interval: need to configure
Min Rx interval: need to configure

BFD Rx direction:

Remote  Discr: Learn (remote Disc=0 redirected to CPU for learning)
Remote Tx interval: learn
Remote Rx interval: learn

CFM Tx direction:
MD name: Auto assign for all MDL=0 (such as LinkMD)
MDL: need to configure MDL=0
MEPID: Auto assign by SW
UP/Down: SW can automatically set to down for all MDL=0
Tx Rate: need to configure

CFM Rx direction:
MD name: Learn (unknown MDL redirected to CPU for learning)
MDL: Learn (unknown MDL redirected to CPU for learning)
MEPID: Learn (unknown MEPID redirected to CPU for learning)
UP/Down: SW sets to Down for all MDL=0 
Rx rate: need to configure

As you can see there isn't much difference in configuration of BFD and 802.1ag for Link OAM. For BFD one needs to configure the Remote IP address and the Tx/Rx rate and for OAM one needs to configure the MDL and the Tx/Rx rate.

So your argument is moot.

Regards
Shahram

-----Original Message-----
From: Warren Kumari [mailto:[email-masked]] 
Sent: Monday, August 01, 2011 8:39 AM
To: Thomas Nadeau
Cc: Shahram Davari; Shane Amante; [email-masked]
Subject: Re: Solicit comments on BFD for Interface draft

+1

---

From: Shane Amante <[email-masked]>
Date: Mon, 1 Aug 2011 12:53:34 -0600

Let's do the correct math ...

> My Discr: Auto assignment by SW

OK.  But, what you're saying is that I, as an operator, do not need to configure them.  The SW is automatically configuring them on my behalf.  So, these don't count against BFD.

> Remote IP add: need to configure

No.  This is automatically gleaned from the IGP routing protocol that is bootstrapping BFD.  And, note that with IGP routing protocols you /are not/ configuring a remote IP address.  You *auto-discover* the remote IP address by virtue of forming a IGP neighbor relationship.

> Min Rx interval: need to configure

Partially correct.  First, IMO, implementations MAY use the same value for the Tx & Rx interval, so you could compress this down to one variable that needs to be configured.  Second, I think this is a "wash", in that you would need to configure this value for *either* BFD or 802.1ag/Y.1731, since only an operator is either going to know what they want their detection interval to be and/or what their equipment is capable of, in terms of the frequency at which it can send/recv BFD or Ethernet CFM PDU's.

> Remote Rx interval: learn

Agreed.

So, based on the above, it appears that for most implementations there is only 1 variable (interval) that BFD requires to be configured on *each side* of the link.  Would you agree?

> MD name: Auto assign for all MDL=0 (such as LinkMD)

And, hope that either: a) that doesn't conflict with another MD that already exists on that device/LAN; or, b) if it does, that the SW balks at the operator loudly to manually fix the problem.  Sure, you can write this into documentation and try to train us operators not to use this auto-assigned or preconfigured name, but mistakes can/do happen ... 

Also, didn't you forget about Maintenance Association (MA)?  Are you proposing this is auto-magically assigned too?  Given that we'd probably want to have separate MA's assigned per LAG, (in order to have a separate "container" for the MEP ID's used for all component-links in a specific LAG), you'd need to either: a) manually configure a unique MA per LAG; or, b) find a way to auto-assign it that doesn't conflict with MA's already being used (either manually config'd or auto-generated).

> MDL: need to configure MDL=0

OK, so that's 1 variable.

> MEPID: Auto assign by SW

How?  (My question pertains to how do you avoid conflicting/overlapping MEP ID's both on the local & remote devices and/or auto-magically "fix" them when overlaps/conflicts do happen).

> UP/Down: SW can automatically set to down for all MDL=0

Agreed.

> Tx Rate: need to configure

Agreed, but as I said above this is a wash for BFD & Ethernet CFM: both need this.  But, this is (at a minimum) 2 variables so far on the Tx side.

> MEPID: Learn (unknown MEPID redirected to CPU for learning)

Interesting; however, to my knowledge, there exists nothing in IEEE 802.1ag/ITU Y.1731 to negotiate a 'master/slave' relationship, which you would need to resolve conflicts with the above naming/ID's.  Specifically, let's say you had:

DeviceA <---> DeviceB

If both DeviceA and DeviceB start off transmitting auto-assigned/auto-generated MD's, MA's, MEPID's, etc. then which one is supposed to back-off and accept the other's parameters?  Or, more worrisome, what happens when [somehow] DeviceA is identified as the "master" and DeviceB is supposed to automatically accept all of the recv'd parameters, but one (or more) of them conflicts?  For example, I can easily see a case where DeviceA is sending a MEPID #1 toward DeviceB, however DeviceB is already configured (or, has auto-assigned) to use MEPID #1 for some other purpose, (e.g.: perhaps it has auto-assigned this to another component-link in LAG toward a third device, DeviceC).

> Rx rate: need to configure

OK.  So, even if one accepts your theoretical proposal, that's still 2 variables required on the Tx side and 1 variable required on the Rx side.  But, I think there is still substantial work to do with your proposal in order to ensure that both devices are able to successful negotiate their "role", (e.g.: master/slave), and also to resolve potential conflicts with ID's/names that you propose are going to be "automagically negotiated".

> As you can see there isn't much difference in configuration of BFD and 802.1ag for Link OAM. For BFD one needs to configure the Remote IP address and the Tx/Rx rate and for OAM one needs to configu…

Umm, no.  One only needs to configure a 'interval' BFD and the rest is bootstrapped either by the IGP routing protocol or by sensible defaults within the implementation.  

Furthermore, I still think there's much more significant details that need to be sorted out before such a proposal could be considered "operationally feasible" to be deployed in a reliable & robust fashion.  From what I've seen, so far, IEEE 802.1ag/ITU Y.1731 were originally designed to operate on a principle of doing [exactly] what they're configured (i.e.: told) to do ... there is no "negotiation" of critical configuration parameters in those protocols.  So, what you're proposing seems like a very fundamental change to either, or both, of those protocols.  (This is unlike BFD, where automatic "negotiation" of various parameters was/is a fundamental foundation of the protocol from Day 1).

Finally, I would add that this is the BFD WG mailing list and working out those details is definitely not within scope of the IETF.  If you're excited about your proposal, then perhaps you could take it to the IETF and/or ITU and work in those organizations to make 802.1ag/Y.1731 more "palatable" for LAG's?

> So your argument is moot.

I'm afraid not, given the evidence that existing shipping implementations support a much more simplified configuration model for BFD compared to 802.1ag/Y.1731.

-shane

---

From: "Shahram Davari" <[email-masked]>
Date: Mon, 1 Aug 2011 12:35:53 -0700

Hi Shane,

Even if we assume that BFD has less parameters to configure, we must look at the big picture. You only need to configure this once for your routers physical ports and you are done. There is no need for dynamic configuration as is needed for LSP and PW.

Regards,
Shahram

-----Original Message-----
From: Shane Amante [mailto:[email-masked]]
Sent: Monday, August 01, 2011 11:54 AM
To: Shahram Davari
Cc: Warren Kumari; Thomas Nadeau; [email-masked]
Subject: Re: Solicit comments on BFD for Interface draft

Agreed.

Agreed.

DeviceA <---> DeviceB

-shane

---

From: Warren Kumari <[email-masked]>
Date: Mon, 1 Aug 2011 16:51:39 -0400

> So your argument is moot.

Which part?

You mean the "tools already understand generation of configlets (and auditing)" bit? Please point to the bit where my (or most) CM systems understands OAM config for major vendors...

You mean the "operators are already familiar with the protocol" bit? Hmmm, also no...  

Maybe you don't buy that "a lot of operators already use BFD in their networks"? Really?

But, it has become apparent that you are not actually listening, so I've lost interest....

W

---

From: Rajeev Nair <[email-masked]>
Date: Mon, 1 Aug 2011 14:16:43 -0700

Hi Mach,

Does this scheme (or a current per-link implementation) work with a port-channel that is not connected back-to-back ? 
i.e. L3 port-channels with L2 cloud in between ?

thanks
Rajeev

On Jul 28, 2011, at 3:34 PM, Mach Chen wrote:

> Hi,
> 
> We uploaded a new draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00) that is about BFD running over interface(e.g., LAG/Bundle interface). You are very welcome to read the draft and give your comments.
> 
> Many thanks,
> Mach

---

From: "Shahram Davari" <[email-masked]>
Date: Mon, 1 Aug 2011 14:22:23 -0700

It doesn't matter if BFD is easier to configure since you need to configure link OAM only once for some limited number of links in each router.

Also the Argument that service providers are more familiar with BFD therefore lets use BFD for any required OAM is very dangerous. I am sure if this draft becomes and RFC then sooner or later drafts will pop up to use BFD for Ethernet, SONET, OTN, PON, MLPPP, etc.

I am sure IETF doesn't want to start a inter-operability nightmare.

Shahram

-----Original Message-----
From: Warren Kumari [mailto:[email-masked]] 
Sent: Monday, August 01, 2011 1:52 PM
To: Shahram Davari
Cc: Thomas Nadeau; Shane Amante; [email-masked]
Subject: Re: Solicit comments on BFD for Interface draft

Which part?

W

---

From: Mach Chen <[email-masked]>
Date: Tue, 02 Aug 2011 09:16:32 +0000

Hi Rajeev,

The solution does not consider the scenario you raised. It currently only works well for the links that are point-to-point, where packets sent from one side and will definitely come out from other side. 

Best regards,
Mach

> From: Rajeev Nair [mailto:[email-masked]]
> Sent: Tuesday, August 02, 2011 5:17 AM
> To: Mach Chen
> Cc: [email-masked]
> Does this scheme (or a current per-link implementation) work with a
> port-channel that is not connected back-to-back ?
> draft(http://tools.ietf.org/html/draft-chen-bfd-interface-00) that is about BFD
> running over interface(e.g., LAG/Bundle interface). You are very welcome to
> read the draft and give your comments.
> >
> > Many thanks,
> > Mach

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 2 Aug 2011 07:54:29 -0400

> It doesn't matter if BFD is easier to configure since you need to configure link OAM only once for some limited number of links in each router.

	Until you add another link (or interface), in which case BFD is automatically configured in most implementations (globally). But I guess links being added never happens in your operational world?

> Also the Argument that service providers are more familiar with BFD therefore lets use BFD for any required OAM is very dangerous. I am sure if this draft becomes and RFC then sooner or later draft…

	Why is it dangerous?  Please explain.  And to the effect of using BFD for ethernet/sonet/etc… that has already been tried and failed about 6 years ago, so let us please not go there.

> I am sure IETF doesn't want to start a inter-operability nightmare.

	It doesn't, and this is one of the reasons why many of us (myself included) advocated to not take that route.

	--Tom

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 2 Aug 2011 15:31:39 -0400

Hi Shahram,

Have you ever talked to a "live" customer?
You should be grateful for Shane's and Warren's comments providing their point of view.
At the end your salary is paid by them... 

Regards,
Jeff  
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Monday, August 01, 2011 14:22
To: Warren Kumari
Cc: [email-masked]; Shane Amante
Subject: RE: Solicit comments on BFD for Interface draft

Shahram

-----Original Message-----
From: Warren Kumari [mailto:[email-masked]] 
Sent: Monday, August 01, 2011 1:52 PM
To: Shahram Davari
Cc: Thomas Nadeau; Shane Amante; [email-masked]
Subject: Re: Solicit comments on BFD for Interface draft

Which part?

W

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 2 Aug 2011 12:36:19 -0700

Please see inline.

-Shahram

-----Original Message-----
From: Thomas Nadeau [mailto:[email-masked]] 
Sent: Tuesday, August 02, 2011 4:54 AM
To: Shahram Davari
Cc: Warren Kumari; Shane Amante; [email-masked]
Subject: Re: Solicit comments on BFD for Interface draft

[SD] Adding a link can happen and as I said you could configure Ethernet OAM in advance on all Links that need OAM and just enable or disable OAM as needed automatically. 

> Also the Argument that service providers are more familiar with BFD therefore lets use BFD for any required OAM is very dangerous. I am sure if this draft becomes and RFC then sooner or later draft…

	Why is it dangerous?  Please explain.  And to the effect of using BFD for ethernet/sonet/etc... that has already been tried and failed about 6 years ago, so let us please not go there.

[SD] using client layer OAM (IP BFD) to proxy for server layer (Ethernet Link) is not a good idea because of many reasons such as:

1) It only works if the client is IP. For example it won't work in MPLS-TP network
2) It may detect link level connectivity loss, but can't diagnose the problem. you still need Server Layer OAM for diagnosing and fixing the problem
3) It is not clear how to force BFD to take a specific Link. It is also not clear how one can run BFD on a link that is disabled so that one ensures that link is healthy before adding it to the bundle. These may require HW change. 

	--Tom

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 2 Aug 2011 12:45:37 -0700

Hi Jeff,

Not only I have talked to a live customer but I have talked to live customer's customer as well. Also Shane and Warren are not paying my salary and my intention is not to please them.

Thx
Shahram

-----Original Message-----
From: Jeff Tantsura [mailto:[email-masked]] 
Sent: Tuesday, August 02, 2011 12:32 PM
To: Shahram Davari; Warren Kumari
Cc: [email-masked]; Shane Amante
Subject: RE: Solicit comments on BFD for Interface draft

Hi Shahram,

Regards,
Jeff  
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Monday, August 01, 2011 14:22
To: Warren Kumari
Cc: [email-masked]; Shane Amante
Subject: RE: Solicit comments on BFD for Interface draft

Shahram

-----Original Message-----
From: Warren Kumari [mailto:[email-masked]] 
Sent: Monday, August 01, 2011 1:52 PM
To: Shahram Davari
Cc: Thomas Nadeau; Shane Amante; [email-masked]
Subject: Re: Solicit comments on BFD for Interface draft

Which part?

W

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 2 Aug 2011 17:09:38 -0400

Hi Shahram,

Please don't tell me you are making your products for the sake of making them or trying to make the world a better place.

We did it because our customers asked us to, Cisco did it last year for exactly same reasons. Others didn't because either their customers didn't realize how good it could work/ couldn't properly do it, mostly due to ASIC's limitations.

Personally - I'm intimately familiar with at least 4 different vendors CLIs - BFD is MUCH easier to configure on all of them.

Another aspect of the story - historically BFD has been available on most platforms for at least 5 years while L2 OAM at sub 100ms just 2-3 years.

/drama mode on
"Dear vendor - we'd like to spend M $xxx on your products if you do per constituent BFD as we are familiar with it, like it and run it everywhere" -  
go away and don't come back - you bloody layer violator :)
/drama mode off

It would be great if we could interoperate with other vendors, our customers would greatly benefit!

Regards,
Jeff  

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]] 
Sent: Tuesday, August 02, 2011 12:46
To: Jeff Tantsura; Warren Kumari
Cc: [email-masked]; Shane Amante
Subject: RE: Solicit comments on BFD for Interface draft

Hi Jeff,

Thx
Shahram

-----Original Message-----
From: Jeff Tantsura [mailto:[email-masked]] 
Sent: Tuesday, August 02, 2011 12:32 PM
To: Shahram Davari; Warren Kumari
Cc: [email-masked]; Shane Amante
Subject: RE: Solicit comments on BFD for Interface draft

Hi Shahram,

Regards,
Jeff  
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Monday, August 01, 2011 14:22
To: Warren Kumari
Cc: [email-masked]; Shane Amante
Subject: RE: Solicit comments on BFD for Interface draft

Shahram

-----Original Message-----
From: Warren Kumari [mailto:[email-masked]] 
Sent: Monday, August 01, 2011 1:52 PM
To: Shahram Davari
Cc: Thomas Nadeau; Shane Amante; [email-masked]
Subject: Re: Solicit comments on BFD for Interface draft

Which part?

W

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 2 Aug 2011 14:28:37 -0700

I made my objection to this draft based on technical grounds and sound engineering practices. I leave it to the rest of the group member to endorse or object to this hack.

Thx
Shahram

-----Original Message-----
From: Jeff Tantsura [mailto:[email-masked]]
Sent: Tuesday, August 02, 2011 2:10 PM
To: Shahram Davari; Warren Kumari
Cc: [email-masked]; Shane Amante
Subject: RE: Solicit comments on BFD for Interface draft

Hi Shahram,

/drama mode on

Regards,
Jeff

-----Original Message-----
From: Shahram Davari [mailto:[email-masked]]
Sent: Tuesday, August 02, 2011 12:46
To: Jeff Tantsura; Warren Kumari
Cc: [email-masked]; Shane Amante
Subject: RE: Solicit comments on BFD for Interface draft

Hi Jeff,

Thx
Shahram

-----Original Message-----
From: Jeff Tantsura [mailto:[email-masked]]
Sent: Tuesday, August 02, 2011 12:32 PM
To: Shahram Davari; Warren Kumari
Cc: [email-masked]; Shane Amante
Subject: RE: Solicit comments on BFD for Interface draft

Hi Shahram,

Regards,
Jeff
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shahram Davari
Sent: Monday, August 01, 2011 14:22
To: Warren Kumari
Cc: [email-masked]; Shane Amante
Subject: RE: Solicit comments on BFD for Interface draft

Shahram

-----Original Message-----
From: Warren Kumari [mailto:[email-masked]]
Sent: Monday, August 01, 2011 1:52 PM
To: Shahram Davari
Cc: Thomas Nadeau; Shane Amante; [email-masked]
Subject: Re: Solicit comments on BFD for Interface draft

Which part?

W

---

From: Marc Binderberger <[email-masked]>
Date: Wed, 3 Aug 2011 00:53:20 +0200

Shahram,

making comments like "hack" (but without the quotes) is not professional and simply inappropriate in my book. You repeatedly made incorrect statements about what we try to achieve and then argue against it (e.g. [1][2]). Interesting technique for a technical discussion ... .

Regarding the layer violation, as this is a central point of your criticism: layers are not a value on their own. It's a tool to modularize a problem. It's a good tool but nothing is absolute. The draft is mentioning what problem can happen because we know some implementation have done it, so for the sake of interoperability it should be mentioned. I think we used the correct phrases like MAY etc. to ensure such behaviour is not a mandatory part of the proposal.

Anyway, we will pick up some of the detailed questions you asked in former emails in an updated draft and I appreciate this constructive input. I say "some" as for some others the answer will be that it's an "implementation detail", like how to send out on a specific component link or how to handle this on a central CPU.

Regards, Marc

[1]: "Also the Argument that service providers are more familiar with BFD therefore lets use BFD for any required OAM is very dangerous. I am sure if this draft becomes and RFC then sooner or later drafts will pop up to use BFD for Ethernet, SONET, OTN, PON, MLPPP, etc."

[2]: "Your argument is not valid that we need a single protocol to do Link as well as IP layer OAM, since if you continue this path sooner or later one could ask why not run BFD for Ethernet and why not run BFD for OTN and why not run BFD for GPON."

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 2 Aug 2011 16:20:45 -0700

Dear Marc,
it is strange to see argument that properly layered architecture
doesn't add value to a solution when discussing networking.
I think that detailed scope and extended applicability of proposed
mechanism will address some of arguments that been expressed in this
discussion.

Regards,
Greg

---

From: Marc Binderberger <[email-masked]>
Date: Wed, 3 Aug 2011 01:43:03 +0200

Hi Greg,

my answer is: an implication is not an equivalence :-)
Translated from boolean algebra into real words:

properly layered architecture -> added value: I would agree, in general terms

for added value -> needs properly layered architecture: I disagree

The problem I have is with the attitude that "layer violation" is a reason to condemn a proposal right away. Not to mention that the "layer violation" wording is exaggerated. 

> mechanism will address some of arguments that been expressed in this

fair enough, looking forward!

Regards, Marc

---

From: Marc Binderberger <[email-masked]>
Date: Wed, 3 Aug 2011 02:05:37 +0200

Hello Rajeev,

ah, wondered when this question comes :-)
I assume with L2 cloud you mean Ethernet switches/bridges and not Ethernet ports cross-connected through pseudo-wires ?

So this situation:

                            +-------+  +-------+
                            | Core1 |  | Core2 |
                            +-------+  +-------+
                                 |||    |||
                                 |||    |||
                                +----------+
                                | Ethernet |
                                |  Switch  |
                                +----------+
                                 ||      |
                                 ||      |
                         +---------+   +---------+
                         | Access1 |   | Access2 |
                         +---------+   +---------+

     Section of an example PoP network topology.  Double/triple lines
                            indicate LAG links.

Answer is: is not implemented for switches in between, only for back-to-back scenarios (to my best knowledge but I can confirm it only for one vendor).

The reason is simplicity and that is was/is sufficient for the customers (which may change, of course).

Regards, Marc

---

From: "Shahram Davari" <[email-masked]>
Date: Tue, 2 Aug 2011 17:20:33 -0700

Marc,

The reason we have layers is that they stay independent of each other so that you can stack them as you wish and still be able to provide a proper service.

Now (as you said) constructive comments (since I have to implement it):

1) I suggest using a Known Multicast MAC address such as the one used for 802.1ag (01-80-C2-00-00-30) so that these packets can be filtered before the LAG is terminated. This way you have terminated the MAC and can process the payload that is BFD. This can avoid a) layer violation b) can be used in networks without IP layer such as MPLS-TP, c) BFD can be run even when that link is disabled by LAG.

2) I suggest generating AIS for the higher level BFD flow in case of the failure detection on component links since the higher level BFD may trigger protection switching

3) I suggest restricting this draft to a single P2P Ethernet physical Link and explicitly say a non P2P link and switched Ethernet network between the routers is outside of the scope of this draft.

4) I suggest stating that both sides should be BFD Active by default to ensure it always works without configuration. Also explicitly stating that Demand mode is not require to be supported.

I will send more comments latee.

Thanks
Shahram

-----Original Message-----
From: Marc Binderberger [mailto:[email-masked]]
Sent: Tuesday, August 02, 2011 3:53 PM
To: Shahram Davari
Cc: Jeff Tantsura; Warren Kumari; Shane Amante; [email-masked]
Subject: Re: Solicit comments on BFD for Interface draft

Shahram,

Regards, Marc

---

From: Rajeev Nair <[email-masked]>
Date: Tue, 23 Aug 2011 14:31:09 -0700

Hi Marc,

 There isn't anything in the proposal that says it applies only to back-to-back L3 scenarios. 

 If this is pushed as a replacement for LACP it should address L2 in middle scenario as well.

 For achieving correct inter operability, packet format should also be captured in this same draft. 

thanks & regards
Rajeev

---

From: Marc Binderberger <[email-masked]>
Date: Wed, 24 Aug 2011 02:19:37 +0200

Hello Rajeev,

> There isn't anything in the proposal that says it applies only to back-to-back L3 scenarios. 

yes, the v01 draft needs a lot more of these clarifications. We start working on it.
Now the reason why the existing implementations - and thus the draft - "aren't for L2 switches" is that a 1:1 relation of the links are required. The LAG (L1) would not cross a switch, it would terminate on the switch and potentially another LAG (L2) on the other side would connect switch and peer router. Even when both L1 and L2 have the same number of component links there is no guarantee of a 1:1 relation for BFD packets.

There exists a vague idea of extending the per-component link BFD to run through a switch. Hasn't been discussed and thought-out yet to the extend that I want to share it. Also: the existing draft should IMHO be a kind of subset - and taking the amount of discussion we had I think it makes sense to do this first step first.

> If this is pushed as a replacement for LACP it should address L2 in middle scenario as well.

I think this is a misunderstanding and actually most customers I know run this together wit LACP. It is not a replacement (although you could use it that way) but a "booster" for detection. And as mentioned by others it is attractive to customers with an IP focus.

> For achieving correct inter operability, packet format should also be captured in this same draft. 

Okay. Well, the packet is RFC5880/RFC5881 but I agree we need to add more details; we got several comments in this direction, which we address in the v01 draft.

Thanks for the feedback!

Marc