Subject: Solicit comments on BFD for Interface draft

From: Mach Chen <[email-masked]>
Date: Thu, 28 Jul 2011 22:34:53 +0000

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: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 29 Jul 2011 06:54:49 +0530

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,

Many thanks,
Mach

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 28 Jul 2011 21:45:17 -0400

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

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Fri, 29 Jul 2011 07:48:29 +0530

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,

Regards,
Jeff

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 28 Jul 2011 21:24:39 -0500

Also as section 4 of that draft mentions: when one LAG component link is
BFD down, the component link is removed from the LAG (I assume this
means in forwarding plane and not in control plane) so you can keep your
bundle up but you've removed the "bad" component links to avoid traffic
loss over that bad link.

Regards,
Reshad.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jeff Tantsura
Sent: Thursday, July 28, 2011 9:45 PM
To: Bhatia, Manav (Manav)
Cc: [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?

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

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 28 Jul 2011 21:25:28 -0500

Hi,

I don't think LACP supports sub-second intervals. Also there might be
failures which BFD could detect but which LACP doesn't?  A bit of a
layering violation but if the interface is L3 only...

Regards,
Reshad.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Bhatia, Manav (Manav)
Sent: Thursday, July 28, 2011 10:18 PM
To: Jeff Tantsura
Cc: [email-masked]
Subject: RE: Solicit comments on BFD for Interface draft

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,

Regards,
Jeff

> Behalf Of Mach Chen

---

From: "Ankush Arora (anarora)" <[email-masked]>
Date: Fri, 29 Jul 2011 08:14:12 +0530

Yes that's true. Since LACP doesn't support sub-second intervals, that is the primary reason, customers like the BFD over each member link feature. 

Consider a scenario where you have 4 links in a bundle and min links is not configured or configured for 2 links.
If the third link goes down, so the bundle stays up and will be used.
If you spray one packet over each link, then you will never have 3 consecutive packet failures and BFD will never detect this.
LACP would detect this, but you cant have sub-second failure detection to remove the 3rd link.
Even if you had min links = max for LACP, for the bundle to be brought down, you will have to depend on LACP timers.

Regards,
Ankush

This e-mail may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply e-mail and delete all copies of this message.   

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Reshad Rahman (rrahman)
Sent: Thursday, July 28, 2011 10:25 PM
To: Bhatia, Manav (Manav); Jeff Tantsura
Cc: [email-masked]
Subject: RE: Solicit comments on BFD for Interface draft

Hi,

Regards,
Reshad.

-----Original Message-----

Hi Jeff,

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,

Regards,
Jeff

---

From: Mach Chen <[email-masked]>
Date: Fri, 29 Jul 2011 10:53:10 +0000

Hi Ankush, Reshad, Manav, Jeff and all,

Thanks for your comments! Seems that Manav's concern is resloved:-)

Exactly, sub-second failure detection is the main purpose of this draft. 

Another method of round-robin is to send N consecutive packets over each link(where N is the BFD Multiplier), this may properly detect the failure link. But for the worst case, you may need to send N * (M + 1) - 1 (where M is the number of the component links) packets, then you could detect the falure. Even so, there may be cases (e.g., periodic loss) that the failure links still can not be correctly detected. 
 
Best regards,
Mach 
________________________________________
发件人: [email-masked] [[email-masked]] 代表 Ankush Arora (anarora) [[email-masked]]
发送时间: 2011年7月29日 10:44
到: Reshad Rahman (rrahman); Bhatia, Manav (Manav); Jeff Tantsura
Cc: [email-masked]
主题: RE: Solicit comments on BFD for Interface draft

Regards,
Ankush

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Reshad Rahman (rrahman)
Sent: Thursday, July 28, 2011 10:25 PM
To: Bhatia, Manav (Manav); Jeff Tantsura
Cc: [email-masked]
Subject: RE: Solicit comments on BFD for Interface draft

Hi,

Regards,
Reshad.

-----Original Message-----

Hi Jeff,

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,

Regards,
Jeff

---

From: Jagrati Shringi <[email-masked]>
Date: Fri, 29 Jul 2011 16:41:09 +0530

Long LACP timers are relevant for non-receipt of packet, But on seeing a LoS
LACP can notify the peer of a failure. It does not have to wait for Second
timers to do so. Per link BFD mkes more sense on media where getting LoS is
not guranteed. Also per link BFD should not be confused probably with BFD
over LAG. Mach, so I am assuming per link BFD session will continue to live
on forwardign plane. Will there will be a aggregation on control plane? As
link of the LAG can be spread across multiple forwarding planes.

Thanks
Jagrati

On Fri, Jul 29, 2011 at 8:14 AM, Ankush Arora (anarora)
<[email-masked]>wrote:

> Yes that's true. Since LACP doesn't support sub-second intervals, that is
> the primary reason, customers like the BFD over each member link feature.
>
> If you spray one packet over each link, then you will never have 3
> consecutive packet failures and BFD will never detect this.
> Even if you had min links = max for LACP, for the bundle to be brought
> down, you will have to depend on LACP timers.
>
>
> Regards,
> Ankush
>
>
> This e-mail may contain confidential and privileged material for the sole
> use of the intended recipient. Any review, use, distribution or disclosure
> by others is strictly prohibited. If you are not the intended recipient (or
> authorized to receive for the recipient), please contact the sender by reply
> e-mail and delete all copies of this message.
>

---

From: Marc Binderberger <[email-masked]>
Date: Sat, 30 Jul 2011 00:03:44 +0200

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

--
Marc Binderberger           <[email-masked]>

---

From: Marc Binderberger <[email-masked]>
Date: Sat, 30 Jul 2011 00:14:01 +0200

Hello Jagrati,

>  Per link BFD mkes more sense on media where getting LoS is not guranteed. 

but a LAG does not have to run on "dark fiber". Exactly the existence of active equipment - to extend the reach of the Ethernet link or to aggregate them - that is not "LoS transparent" is a problem in such a case.

Think about one core router in location "A" and the 2nd core router in location "B" of the same city and a LAG in between. Not uncommon to have 2 or more sites in larger cities.

Regards, Marc

On 2011-07-29, at 1:11 PM, Jagrati Shringi wrote:

>  
> Long LACP timers are relevant for non-receipt of packet, But on seeing a LoS LACP can notify the peer of a failure. It does not have to wait for Second timers to do so. Per link BFD mkes more sense on media where getting LoS is not guranteed. Also per link BFD should not be confused probably with BFD over LAG. Mach, so I am assuming per link BFD session will continue to live on forwardign plane. Will there will be a aggregation on control plane? As link of the LAG can be spread across multiple forwarding planes. 
>  
> Thanks
> Jagrati
> 
> On Fri, Jul 29, 2011 at 8:14 AM, Ankush Arora (anarora) <[email-masked]> wrote:

---

From: "Shahram Davari" <[email-masked]>
Date: Fri, 29 Jul 2011 15:21:06 -0700

BFD is a client if IP layer and IP is a client of Ethernet. Therefore BFD is technically above LAG and therefore can't be run for individual LAG links. Doing anything else is not only a layer violation but has consequences.

Thx
Shahram

----- Original Message -----
From: Marc Binderberger [mailto:[email-masked]]
Sent: Friday, July 29, 2011 03:03 PM
To: Bhatia, Manav (Manav) <[email-masked]>
Cc: [email-masked] <[email-masked]>
Subject: Re: Solicit comments on BFD for Interface draft

Hello Manav,

Regards, Marc

---

From: Marc Binderberger <[email-masked]>
Date: Sat, 30 Jul 2011 00:38:38 +0200

Hello Sharam,

sorry but could you please be more specific? "has consequences" means what exactly for you?

The layering has a consequence on the sequence of bringing up LAG links, BFD sessions etc. The draft is mentioning this.

Regards, Marc

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sat, 30 Jul 2011 05:04:01 +0530

Hi Marc,

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?

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

> Sent: Saturday, July 30, 2011 3:34 AM
> Cc: Jeff Tantsura; [email-masked]
> 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
> 
> - BFD in it's IP form (IP+UDP+BFD) is understood by Telco 
> Designers and Operations, so they would like to use it everywhere
> 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
> 
> 
> 
> > 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
> > 
> > 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?
> > 
> >> 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
> >> 
> 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: Nitin Bahadur <[email-masked]>
Date: Fri, 29 Jul 2011 17:13:08 -0700

I agree with all this in theory. But I think we need service provider reasoning as well.

Providers who want/use this feature should speak out as to why they want/use it....and why ethernet-oam is not sufficient/preferred.

Someone mentioned that there are multiple vendors supporting this feature, so I'm presuming there are multiple customers.

Thanks
Nitin

On 7/29/11 4:34 PM, "Bhatia, Manav (Manav)" <[email-masked]> wrote:

Hi Marc,

Cheers, Manav

---

From: "Shahram Davari" <[email-masked]>
Date: Fri, 29 Jul 2011 17:23:30 -0700

Hi

Each layer should have its own OAM. You should not run OAM on other layers as proxy for a different layer. This is architecturally wrong. 

Since LAG hashing is not standard then how can you force a BFD packet to follow a specific link? Should we now start terminating IP layer before LAG layer? Why not just use 802.3ah or 802.1ag?

Consequences of layer violations are known. They can range from security issues to standards that are not generic and run just under for a specific application.

Regards
Shahram

----- Original Message -----
From: Marc Binderberger [mailto:[email-masked]]
Sent: Friday, July 29, 2011 03:38 PM
To: Shahram Davari
Cc: [email-masked]' <[email-masked]>; [email-masked]' <[email-masked]>
Subject: Re: Solicit comments on BFD for Interface draft

Hello Sharam,

Regards, Marc

---

From: Jagrati Shringi <[email-masked]>
Date: Sat, 30 Jul 2011 08:01:27 +0530

Shahram,

This was my concern excatly. We can not force BFd packet to follow a
specific link, and it may happen that LAG receives and trasmits from
diffrent links. To make this matter even harder these links can live on
diffrerent card, if it is a cross-card LAG. If we want to use BFD for
link-oam then lets call it something else and that is 802.3 ah and 802.3 ag.
802.3 ag can support sub-second timers I believe. Even then if there is
motivation/use-case to have per-link BFD lets keep it saprate rom BFD as a
client of IP.

Thanks
Jagrati

On Sat, Jul 30, 2011 at 5:53 AM, Shahram Davari <[email-masked]> wrote:

> Hi
>
> Each layer should have its own OAM. You should not run OAM on other layers
> as proxy for a different layer. This is architecturally wrong.
>
> Since LAG hashing is not standard then how can you force a BFD packet to
> follow a specific link? Should we now start terminating IP layer before LAG
> layer? Why not just use 802.3ah or 802.1ag?
>
> Consequences of layer violations are known. They can range from security
> issues to standards that are not generic and run just under for a specific
> application.
>
> Regards
> Shahram
>
> The layering has a consequence on the sequence of bringing up LAG links,
> BFD sessions etc. The draft is mentioning this.
>
>
> Regards, Marc
>
>
> > BFD is a client if IP layer and IP is a client of Ethernet. Therefore BFD
> is technically above LAG and therefore can't be run for individual LAG
> links. Doing anything else is not only a layer violation but has
> consequences.
> >
> > Thx
> > Shahram
> >
> > 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
> >
> > - BFD in it's IP form (IP+UDP+BFD) is understood by Telco Designers and
> Operations, so they would like to use it everywhere
> > 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
> >
> >
> >
> >>> 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: Vishwas Manral <[email-masked]>
Date: Fri, 29 Jul 2011 19:39:55 -0700

Hi Shahram,

I agree with what you say. We should not run BFD with UDP encapsulation to
send particular packets over particular links.

However you have to remember that the BFD protocol byitself is agnostic to
the transport over which it works. I remember I had brought up the issue of
Ethernet encapsualtion of BFD, as we had customer requirements for the same.
If we run BFD directly over Layer-2 it can be used as the CC mechanims for
the same.

One interesting point here is by using the same OAM across layers, there are
fewer things to learn for operators, and cheaper to design for the product
developers. I am sure it is true for the ASIC companies too.

Thanks,
Vishwas

---

From: Marc Binderberger <[email-masked]>
Date: Sat, 30 Jul 2011 10:31:17 +0200

Hello Sharam,

second time you make generic statements but avoid concrete details. I'm sorry to say it but this is not the way to run a discussion.

I do appreciate your warning about layer violation. I fully respect your personal style of designing and am interested to learn from you. But establishing a dogma in a technical discussion doesn't make sense.

The last paragraphs of section 2 and 3 pick the topic of layer violation up, we only don't name it this way but focus on the result. If you think this needs more attention in the text - I'm open to constructive comments. That's why we are here on the list I think :-)

Thanks & Regards,
Marc

---

From: Marc Binderberger <[email-masked]>
Date: Sat, 30 Jul 2011 12:31:50 +0200

Hello Jagrati,

your first points seem to be more an implementation discussion, not a principal problem as at least 3 teams have managed to overcome the issues you mention.

We are not competing against LACP here. We are offering a different solution, thus we name it BFD and not 802.3-something and propose it on the IETF BFD list.
I admit using it instead/in parallel to LACP is what some implementations are doing and what the authors documented with section 4 as an example. But we are not restricted to this scenario. What is does is providing information from another layer into "BFD". Whatever you make out of the information (*).

Could it be done with BFD-over-Ethernet frames? Probably. I first thought into this direction myself. The relevant point is it turned out we don't have to and can stick to what we and customers know: BFD using IP/UDP.  

Regards, Marc

(*: maybe we have to define this "whatever" for interoperability. Discussion will show :-)

On 2011-07-30, at 4:31 AM, Jagrati Shringi wrote:

> Shahram,
>  
> This was my concern excatly. We can not force BFd packet to follow a specific link, and it may happen that LAG receives and trasmits from diffrent links. To make this matter even harder these links can live on diffrerent card, if it is a cross-card LAG. If we want to use BFD for link-oam then lets call it something else and that is 802.3 ah and 802.3 ag. 802.3 ag can support sub-second timers I believe. Even then if there is motivation/use-case to have per-link BFD lets keep it saprate rom BFD as a client of IP.
>  
> Thanks
> Jagrati 
>

---

From: Marc Binderberger <[email-masked]>
Date: Sat, 30 Jul 2011 14:02:29 +0200

Hello Manav!

> I think the diagnoses is correct, but the medicine isn't! :-)

well, it's a different medicine we propose, not necessarily a wrong one ;-)

> Are we trying to position BFD as an IETF equivalent of 802.1ag?

No

> Or is it that we're trying to run BFD over component links since not all links may be ethernet?

Actually we do have POS-based bundles (but not mixed POS/Ethernet) on our equipment. So IP is the natural common layer for both, POS and Ethernet. The draft is not talking about it but focuses on the more tricky one, which is Ethernet and it's MAC filter on the receiving side. 

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

Reaching the other end with BFD is not an achievement on it's own :-)
Lets look at the round-robin BFD. A single component link failure has not impact on BFD, unless the Multiplier is 1. But depending on your LAG load-balance either several flows have 100% loss (flow-based) or every flow has a loss of 1/M (round-robin, with M: number of component links).
So BFD is kind of useless in this case. And once the LAG is declared down by LACP you have this information already in your OS (and I guess we all have mechanism to react immediately to Intf downs).

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

I beg to differ :-)
Actually from the discussion above one can ask what _is_ the gain we have from single-BFD through a LAG?  For sure not a detection of a (local) LAG problem, it fails to provide a gain as showed above.

Regards, Marc

---

From: "Bhatia, Manav (Manav)" <[email-masked]>
Date: Sat, 30 Jul 2011 18:40:36 +0530

Hi Marc,

> Reaching the other end with BFD is not an achievement on it's 
> own :-) Lets look at the round-robin BFD. A single component 
> link failure has not impact on BFD, unless the Multiplier is 
> 1. But depending on your LAG load-balance either several 
> flows have 100% loss (flow-based) or every flow has a loss of 
> 1/M (round-robin, with M: number of component links).
> So BFD is kind of useless in this case. And once the LAG is 
> declared down by LACP you have this information already in 
> your OS (and I guess we all have mechanism to react 
> immediately to Intf downs).

Why cant we use eth-cfm (or other OAM utilities) to detect the loss of component links in the LAG? Does BFD offer a benefit over other OAM protocols that are meant to monitor link liveliness?

Cheers, Manav

---

From: Shane Amante <[email-masked]>
Date: Sat, 30 Jul 2011 10:36:12 -0600

Manav, Sharam, Others,

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

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

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 31 Jul 2011 13:59:44 +0300

Jagrati and all,
Quoting from IEEE 802.3-2005 Part 5<file:///\\netstore2\tnd_cesr\Dev\Standards\IEEE\ieee802\ieee802.3\IEEE_802.3-2005.pdf>, Section 57.1.2:

a) Remote Failure Indication
1) A mechanism is provided to indicate to a peer that the receive path of the local DTE is nonoperational.
2) Physical layer devices using Clause 66 may support unidirectional operation that allows OAM
remote failure indication during fault conditions.
3) Subscriber access physical layer devices using Clause 65 support unidirectional operation in
the direction from OLT to ONU that allows OAM remote failure indication from OLT during
fault conditions.
4) Physical layer devices other than those listed above do not support unidirectional operation
allowing OAM remote failure indication during fault conditions. Some physical layer devices
have specific remote failure signaling mechanisms in the physical layer.

In other words, certain Ethernet media do not support unidirectional operation, i.e., if they co not receive a valid signal (as in the case of LOS) they cannot transmit an LACP packet to a peer.

And of course some dedia types do not propagate failures properly. E.g., conider a an Ethernet link that uses a repeater in the middle...

Regards,
     Sasha

From: [email-masked] [mailto:[email-masked]] On Behalf Of Jagrati Shringi
Sent: Friday, July 29, 2011 2:11 PM
To: Ankush Arora (anarora)
Cc: Reshad Rahman (rrahman); [email-masked]
Subject: Re: Solicit comments on BFD for Interface draft

Thanks
Jagrati
On Fri, Jul 29, 2011 at 8:14 AM, Ankush Arora (anarora) <[email-masked]<mailto:[email-masked]>> wrote:
Yes that's true. Since LACP doesn't support sub-second intervals, that is the primary reason, customers like the BFD over each member link feature.

Regards,
Ankush

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Reshad Rahman (rrahman)
Sent: Thursday, July 28, 2011 10:25 PM
To: Bhatia, Manav (Manav); Jeff Tantsura
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: Solicit comments on BFD for Interface draft

Hi,

Regards,
Reshad.

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
Behalf Of Bhatia, Manav (Manav)
Sent: Thursday, July 28, 2011 10:18 PM
To: Jeff Tantsura
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: Solicit comments on BFD for Interface draft

Hi Jeff,

Cheers, Manav

-----Original Message-----
From: Jeff Tantsura [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, July 29, 2011 7:15 AM
To: Bhatia, Manav (Manav)
Cc: Mach Chen; [email-masked]<mailto:[email-masked]>
Subject: Re: Solicit comments on BFD for Interface draft

Hi,

Regards,
Jeff

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
> Behalf Of Mach Chen
> To: [email-masked]<mailto:[email-masked]>
> Mach

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: "Shahram Davari" <[email-masked]>
Date: Sun, 31 Jul 2011 07:43:45 -0700

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.

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. 

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,

Thanks,

-shane

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 31 Jul 2011 17:54:42 +0300

Shahram,
I disagree with you - please see some detailed comments inline below.

Regards,
     Sasha

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Shahram Davari
> Sent: Sunday, July 31, 2011 5:44 PM
> To: Shane Amante; Bhatia, Manav (Manav)
> Cc: [email-masked]
> Same for BFD. You need to know:
> my discriminator [[Sasha]] Automatically allocated, no need to configure
> your discriminator[[[Sasha]]] You learn it - please see RFC 5880 for the details
> local IP address, [[[Sasha]]] You usually configure it anyway in an IP world
> remote IP address[[[Sasha]]]  You learn it from IGP, or configure it in any case in the case of ISBR
> Min Tx Interval, Min Rx Interval, [[[Sasha]]] Yes you have to configure it - Shane has indicated that
> Demand mode [[Sasha]] You do not have to configure it
> Authentication [[Sasha]] You may configure it if you want to use it, the default presumably is none. With 802.1ag you simply do not have this functionality, so you cannot use it even if you wish
>Active/Passive, [[[Sasha]]]  Defaults to Active
> Detection Interval [[Sasha]] If you mean the detect multiplier, it defaults to 3.
> 
> 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.
> 
[[[Sasha]]] Sorry I do not believe you.

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

---

From: "Shahram Davari" <[email-masked]>
Date: Sun, 31 Jul 2011 08:06:17 -0700

Hi Marc,

I was pointing out a general rule of protocol design. I think we in the IETF or any standard organization should strive to follow such rules unless there is no other easy solution. In this case there is also already a solution which is 802.ag. 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.

Anyways I will try to provide some specific technical reasons why running BFD for Link is not a good idea;

1) From protocol layering, where should IP layer be? Do we need 1 IP layer or 2 IP layers now? Since we would need BFD termination before and after LAG termination?

2) What happens if the other end is not configured to terminate the Multicast address that you want? Then it will be sent to the network?

3) how do you force a BFD packet to take a specific link?

4) How do I differentiate between BFD packets if they are sent to a central processor for processing?

Thx
Shahram

-----Original Message-----
From: Marc Binderberger [mailto:[email-masked]] 
Sent: Saturday, July 30, 2011 1:31 AM
To: Shahram Davari
Cc: [email-masked]'; [email-masked]'
Subject: Re: Solicit comments on BFD for Interface draft

Hello Sharam,

Thanks & Regards,
Marc

---

From: Alexander Vainshtein <[email-masked]>
Date: Sun, 31 Jul 2011 19:17:54 +0300

Shahram, and all,
When I said (in the previous email) that I do not believe you, I only had in mind your statement about the BFD configuration burden. I apologize if this has been misunderstood.

IMHO and FWIW, the difference between BFD and 802.1ag when it comes to configuration is that with BFD the user has only to configure the things that are needed anyway (with or without BFD) and a few parameters of the BFD session. To the best of my understanding this is not the case in 802.1ag.

Regards,
     Sasha

________________________________________
From: Alexander Vainshtein
Sent: Sunday, July 31, 2011 5:54 PM
To: Shahram Davari; Shane Amante; Bhatia, Manav (Manav)
Cc: [email-masked]
Subject: RE: Solicit comments on BFD for Interface draft

Shahram,

Regards,
     Sasha

> Shane Amante

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 31 Jul 2011 14:33:28 -0700

Dear Sasha,
if to compare proposed BFD solution to any IEEE OAM, I'd look at
802.3ah, not 801.3ag. I think that such comparison might be valid.
Then we'll find that there are fewer parameters required configuration
for 802.3ah and not much more complex if compared with proposed
solution.

Regards,
Greg

---

From: Shane Amante <[email-masked]>
Date: Sun, 31 Jul 2011 17:16:58 -0600

Hi Sharam,

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

As an _operator_ of BFD, I am not /required/ to configure every single variable you named above, on every single link of every router in my network.  Good try though.  

Not to pick on any one implementation, but here's proof that the only required **configuration elements** necessary to bring up BFD was the 'minimum-interval', (specifying a period of 100 msecs):
---snip---
interface fe-0/0/6.0 {
    point-to-point;
    bfd-liveness-detection {
        minimum-interval 100;
    }
}
[...]
> show bfd session 
                                                  Detect   Transmit
Address                  State     Interface      Time     Interval  Multiplier
10.200.2.0               Up        fe-0/0/6.0     0.300     0.100        3   

1 sessions, 1 clients
Cumulative transmit rate 10.0 pps, cumulative receive rate 10.0 pps
---snip---

As with most IETF protocols, and particularly with smart & clever implementers designing & coding them, very sensible defaults are chosen so as to reduce the configuration burden on behalf of operators.  This is another way of saying, yes, as a [BFD] protocol implementer you need to worry that you've implemented all of variables required by the RFC, either by forcing the operator to give you input for them or, better yet, by speaking to operators and choosing to implement sensible defaults.

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

The above would seem to indicate that's false.  But, if you still don't believe me, here's a short configuration snippet showing all of the required configuration parameters to make IEEE 802.1ag work, on just a single link:
---snip---
ethernet {
    connectivity-fault-management {
        maintenance-domain myOrg {
            level 1;
            name-format character-string;
            maintenance-association link-MA {
                short-name-format character-string;
                continuity-check {
                    interval 100ms;
                }
                mep 2 {
                    interface ge-3/0/1;
                    direction down;
                    remote-mep 5;
                }
            }
        }
    }
}
---snip---

For starters, as an operator, good luck on trying to keep all your MEP ID's straight for every component-link inside every LAG!  And, again, I'm not picking on any one vendor's configuration syntax ... the above is no different, and sometimes worse, on any other vendor I've configured 802.1ag/Y.1731.

In summary, as I've studied IEEE 802.1ag/ITU Y.1731, I've come to the conclusion that the designers of those protocols were likely operating under the assumption, at that time, that a OSS and/or NMS would be used as the [sole] means to *configure* and *maintain* all of the configuration elements required to bootstrap them and, when something goes wrong, figure out what information is being reported by those protocols.  Unfortunately, this is completely *untrue* of how we run IP/MPLS networks -- namely, we don't use NMS systems, particularly to configure our networks!, and thus we need something simple, that just works, i.e.: BFD.

-shane

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 31 Jul 2011 16:59:57 -0700

Dear Mach and All,
please find my comments to the document below:
•	Introduction “…consequently taking down or bringing up the
interfaces rapidly by BFD” I think that we don’t want to react to
every state change of a flapping interface. BFD should not be taking
any actions but only report state change. Whether monitored object is
activated or de-activated immediately or with dampened delay is
outside of BFD scope.
•	Section 2 “…when the interface is itself the client of the BFD
session, then the status of the interfaces will be associated with the
status of the BFD session.” I’d change the text to “the status of the
interface might be associated with the status of the BFD session”.
•	Section 2 “To avoid the deadlock BFD packets SHOULD NOT be blocked
by the layer N protocol status of the interface when the application
depends on the BFD status to enable layer N of the interface.”
Wouldn’t it be clearer to associate BFD session with Layer N-1 thus
making it independent of state of Layer N?
•	Section 3. I think that when it will benefit the document to mention
that the TTL MUST be set to 1. It might be obvious but would not hurt
to make it explicit.
•	Section 4. From an implementation perspective it is usually better
to react immediately to a Down event and delay or dampen Up to avoid
flapping effect.
•	Section 5 I disagree that this document does not introduce any
changes to RFC 5880 in regard to security. Making interface
promiscuous to the new multicast address and allowing source address
to be 0.0.0.0 clearly opens a new door for the DoS attacks.
•	I see as a limitation that the proposal depends on IP addressing,
ability to process new multicast address. Thus the scope of the
document, its applicability is limited to LAG interconnections between
IP capable nodes. MPLS-TP, for example, doesn’t have such limitation
with use of G-ACh encapsulation.

Kind regards,
Greg

---

From: "Shahram Davari" <[email-masked]>
Date: Sun, 31 Jul 2011 18:00:21 -0700

Hi shane

Same can be said about ethernet oam. Basically everything can be automatically assigned by software except MDL.

As someone who has implemented OAM and BFD, I can certainly say BFD requires more variables and parameters.

Regards
Shahram 

Regards
Shahram

----- Original Message -----
From: Shane Amante [mailto:[email-masked]]
Sent: Sunday, July 31, 2011 04:16 PM
To: Shahram Davari
Cc: Bhatia, Manav (Manav) <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: Solicit comments on BFD for Interface draft

Hi Sharam,

---snip---
interface fe-0/0/6.0 {
    point-to-point;
    bfd-liveness-detection {
        minimum-interval 100;
    }
}
[...]
                                                  Detect   Transmit

1 sessions, 1 clients

---snip---
ethernet {
---snip---

-shane

---

From: "Shahram Davari" <[email-masked]>
Date: Sun, 31 Jul 2011 18:12:01 -0700

Hi Shane and all

Even if as you say BFD requires less configuration (which it doesn't) still it can't justify doing unnecessary  layer violation to proxy for Ethernet OAM that already exists. Why not use BFD for OTN and PON OAM next.

Thx
Shahram

Regards
Shahram

----- Original Message -----
From: Shahram Davari [mailto:[email-masked]]
Sent: Sunday, July 31, 2011 06:00 PM
To: [email-masked]' <[email-masked]>
Cc: [email-masked]' <[email-masked]>
Subject: Re: Solicit comments on BFD for Interface draft

Hi shane

Regards
Shahram 

Regards
Shahram

----- Original Message -----
From: Shane Amante [mailto:[email-masked]]
Sent: Sunday, July 31, 2011 04:16 PM
To: Shahram Davari
Cc: Bhatia, Manav (Manav) <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: Solicit comments on BFD for Interface draft

Hi Sharam,

---snip---
interface fe-0/0/6.0 {
    point-to-point;
    bfd-liveness-detection {
        minimum-interval 100;
    }
}
[...]
                                                  Detect   Transmit

1 sessions, 1 clients

---snip---
ethernet {
---snip---

-shane

---

From: Shane Amante <[email-masked]>
Date: Sun, 31 Jul 2011 20:31:53 -0600

Sharam,

On Jul 31, 2011, at 7:12 PM, Shahram Davari wrote:
> Hi Shane and all
> 
> Even if as you say BFD requires less configuration (which it doesn't)

I noticed you haven't pointed toward an existing standard or, better yet, implementation of said standard that would back your claim that today's implementations of 802.1ag/Y.1731 are "less configuration" than BFD ...

> still it can't justify doing unnecessary  layer violation to proxy for Ethernet OAM that already exists. Why not use BFD for OTN and PON OAM next.

Let's be perfectly clear here.  BFD is a fast, failure detection mechanism that is [already] directly integrated into and directly drives *routing* and *signaling* protocols for IP/MPLS networks.  That was why BFD was created and that is how it is being extensively used.  And, that's **how** we want to continue to use it, in this case on component-links of LAG's between /routed/ devices, as we need to /scale/ our networks beyond the capability of physical media.

Ethernet OAM has it's place and will continue to have it's place, but that's IMO [strictly] in L2 switched networks where one has no other choice (since those devices are strictly L2 switches), either on:
a)  Directly adjacent links: 802.3ah or 802.1ag/Y.1731; or,
b)  Multiple hops: 802.1ag/Y.1731
... but, Ethernet OAM is a huge pain-in-the-neck to configure and operate, as I demonstrated.

-shane

---

From: Greg Mirsky <[email-masked]>
Date: Sun, 31 Jul 2011 20:23:11 -0700

Dear Shane,
I took liberty to google for IEEE 802.3ah and copy configuration
example provided by one vendor:
protocols {

    oam {

        ethernet {

            link-fault-management {

                interface xe-0/0/0 {
                    link-discovery active;
                    pdu-interval 800;
                    pdu-threshold 4;
                    remote-loopback;

                    negotiation-options {
                        allow-remote-loopback;
                    }

                    event-thresholds {
                        frame-error 30;
                        frame-period 50;
                        frame-period summary 40;
                        symbol-period 20;
                    }

                }

            }

        }

    }

If one chooses default values the whole configuration will look as:
protocols {
    oam {
        ethernet {
            link-fault-management {
                interface xe-0/0/0 {
                    link-discovery active;
                    remote-loopback;
                    negotiation-options {
                        allow-remote-loopback;
                    }
                }
            }
        }
    }
}

It doesn't look too complex to me (and it can be simplified even further).

Regards,
Greg

---

From: Mach Chen <[email-masked]>
Date: Mon, 01 Aug 2011 03:40:13 +0000

Hi Shane, Shahram and others,

Just returned from the long travel and surpised to find the enthusiastic discussions on the list! Thanks for your discussion and comments!

Shane, I fully agree with here! I heard the same requirements from several SPs as what's you said. That's the main motivation for the draft. And bissically, as Marc and Jeff said, there are actually several implemetations and deployments in the field, it proved that it really works and fully satisfy the requreiments of the operators (Using Jeff's word, opertors love it:-) ).

I have to claim that the proposed solution does not intend to replace the existing ETH OAMs, it's complementary. It gives the chance to the operators who love to use BFD.

By the way, quoted from RFC 5880:
"This document describes a protocol intended to detect faults in the
   bidirectional path between two forwarding engines, including
   interfaces, data link(s), and to the extent possible the forwarding
   engines themselves, with potentially very low latency."

I intepret this as BFD can also apply to LAG and it compenent links for fault detecting. 

Best regards,
Mach

________________________________________
发件人: [email-masked] [[email-masked]] 代表 Shane Amante [[email-masked]]
发送时间: 2011年8月1日 10:31
到: Shahram Davari
Cc: [email-masked]'
主题: Re: Solicit comments on BFD for Interface draft

Sharam,

-shane

---

From: "Shahram Davari" <[email-masked]>
Date: Sun, 31 Jul 2011 21:44:20 -0700

Shane

Let's forget about the configuration complexity since we can't agree on it and stick to technical discussions on why I think this draft  is a bad idea.

First, Could you please explain your protocol layering model. Do we now need 2 IP layers, one before LAG termination and one after LAG termination, where the one before LAG termination only understands the well known Multicast IPDA.

Or implementing this draft assumes  bypassing LAG termination when IP-DA is the known multicast proposed in the draft. In other words now LAG termination is conditional on IP address.

Both are hacky implementation in my opinion.

Second, if I am generating BFD in a central processor, how do I send this Link BFD to the desired Link? LAG algorithm will distribute it according to its hash function. Doesn't it? Or do we now need to have per Link BFD generator?

Thanks
Shahram

----- Original Message -----
From: Shane Amante [mailto:[email-masked]]
Sent: Sunday, July 31, 2011 07:31 PM
To: Shahram Davari
Cc: [email-masked]' <[email-masked]>
Subject: Re: Solicit comments on BFD for Interface draft

Sharam,

-shane

---

From: Mach Chen <[email-masked]>
Date: Mon, 01 Aug 2011 06:02:39 +0000

Hi Greg,

Many thanks for your comments!

Please see my reply inline...
________________________________________
发件人: Greg Mirsky [[email-masked]]
发送时间: 2011年8月1日 7:59
到: Mach Chen
Cc: [email-masked]
主题: Re: Solicit comments on BFD for Interface draft

Dear Mach and All,

[Mach] This is a general description on how BFD is used for interface, it does not require the implementation has to react the state change immediately. You are right, BFD is used to detect the failure and report the change, and the reaction shoud be taken by the relevant modules (e.g., interface management module) if they track the related BFD session. 

[Mach] OK, will change it in next verion.

[Mach] Actually, the draft intends to associate BFD session with Layer N and also require that BFD packets transmition should be independent of the state of Layer N.  That is why there may be deadlock when using the normal mechanims as current defined. 

[Mach] Will consider this in next versio.

The status of an interface is normally related to many factors and it's more implementation specific,  BFD status is just one of them. An interface could aslo implement other mechanims (interface damping) to aviod/reduce flapping, and BFD status should not exclude them.  We may add some text to clarify this in next reversion.

Yes, you are right, the section needs some rewording.

The draft currently focuses on the IP capable nodes only. 

Thanks again for your detailed review and comments!

Best regards,
Mach

Kind regards,
Greg

---

From: Alexander Vainshtein <[email-masked]>
Date: Mon, 1 Aug 2011 09:09:57 +0300

Shahram,
Responding to just one of your questions, namely:
                   If I am generating BFD in a central processor, how do I send this Link BFD to the desired Link? 
The answer, IMHO, is "using the same technique that allows the central processor to send LACP packets via a specific link..."

Regards,
     Sasha
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Shahram Davari [[email-masked]]
Sent: Monday, August 01, 2011 7:44 AM
To: [email-masked]'
Cc: [email-masked]'
Subject: Re: Solicit comments on BFD for Interface draft

Shane

Thanks
Shahram

----- Original Message -----
From: Shane Amante [mailto:[email-masked]]
Sent: Sunday, July 31, 2011 07:31 PM
To: Shahram Davari
Cc: [email-masked]' <[email-masked]>
Subject: Re: Solicit comments on BFD for Interface draft

Sharam,

-shane

---

From: Mach Chen <[email-masked]>
Date: Mon, 01 Aug 2011 06:32:05 +0000

Hi Shahram,

Please see my reponse inline with [Mach]....
________________________________________
发件人: [email-masked] [[email-masked]] 代表 Shahram Davari [[email-masked]]
发送时间: 2011年8月1日 12:44
到: [email-masked]'
Cc: [email-masked]'
主题: Re: Solicit comments on BFD for Interface draft

Shane

[Mach] From the view of implementation, there is no difference between runing single BFD over a LAG and runing per-link BFD. The key point is how to identify a BFD packet, current as defined in RFC 5880, it uses the UDP port, now for per-link BFD, it uses both multicast IP DA and UDP port. You can do it before or after the LAG termination, it's implementation specific.

[]

[Mach] When the BFD sessions established, there should be mapping information of the links to the specific sessions in the system, you are free to use them. There are many ways to achieve this and per Link BFD generator is just one of them.

Thanks
Shahram

----- Original Message -----
From: Shane Amante [mailto:[email-masked]]
Sent: Sunday, July 31, 2011 07:31 PM
To: Shahram Davari
Cc: [email-masked]' <[email-masked]>
Subject: Re: Solicit comments on BFD for Interface draft

Sharam,

-shane

---

From: Manav Bhatia <[email-masked]>
Date: Mon, 1 Aug 2011 12:06:10 +0530

Hi Mach,

> [Mach] From the view of implementation, there is no difference between runing single BFD over a LAG and runing per-link BFD. The key point is how to identify a BFD packet, current as defined in RFC…

[Manav] I disagree. Practically, most routers are constrained by the 
number of BFD packets the system can send and receive per second. If we 
start sending BFD packets over each component link of the lag, then the 
number of IP interfaces that can support BFD goes down.

Cheers, Manav

---

From: Mach Chen <[email-masked]>
Date: Mon, 01 Aug 2011 06:46:48 +0000

Hi Manav,

>Practically, most routers are constrained by the number of BFD packets the system can send and receive per second. If we start sending BFD packets over each component link of the lag, then the

In the case of certain resources, this should be so. You have to pay this if you want to do per-link detection whatever techniques are used. 

Best regards,
Mach
________________________________________
发件人: [email-masked] [[email-masked]] 代表 Manav Bhatia [[email-masked]]
发送时间: 2011年8月1日 14:36
到: [email-masked]
主题: Re: 答复: Solicit comments on BFD for Interface draft

Hi Mach,

Cheers, Manav