Subject: Time for a recharter

From: Jeffrey Haas <[email-masked]>
Date: Sat, 7 May 2011 13:35:45 +0000

Working Group,

As our ADs have reminded us, we're in need of a re-charter for the
working group.  Based on the minutes from our last session and some items
the chairs have been approached about, please find a possible draft charter
for discussion.  Note that milestones have yet to be determined.

Commentary on the draft charter's work items:
- The MIB work is a lingering work item from our prior charter.  The current
  status is that it's ready for last call but we'd like to hold off on doing
  that until the MPLS-TP work with relation to draft-ietf-mpls-tp-cc-cv-rdi
  has converged to final nits.  IMO, we're very close on that.
  (This chair would be thrilled to have that work complete prior to the
  completion of our re-charter.)

- We continue to provide a stewardship role for the BFD core protocol.  As
  such, we'll be assisting other working groups with the use of BFD in their
  applications.  This covers several of the items in the draft charter
  including DHCP, MPLS-TP and TRILL.

- The cryptographic work was presented at our last session.  We had
  reasonable consensus about adopting this as a working group item even if
  there was some contention on the details.  As part of this re-chartering
  we would be formally be requesting this to be adopted as a WG item.

- The P2MP work was deferred from the original charter until the base BFD
  protocol was solidified.

Send your comments on the draft charter to the mailing list.  Please 
annotate your comments specifically with whether this is an edit to the
charter text or a suggested addition or deletion for working group items.

-- Jeff

---

From: Glen Kent <[email-masked]>
Date: Wed, 11 May 2011 09:54:59 +0530

The proposed charter looks good to me.

Glen

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 11 May 2011 00:26:00 -0400

Same here

Regards,
Jeff  
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Glen Kent
Sent: Tuesday, May 10, 2011 21:25
To: Jeffrey Haas
Cc: [email-masked]
Subject: Re: Time for a recharter

Glen

---

From: Shane Amante <[email-masked]>
Date: Wed, 11 May 2011 08:32:44 -0600

Jeff, All,

I'd like to see if there's interest among WG members to take a look at [more thoroughly] specifying how BFD may be used to detect availability of component-links that comprise a LAG or ECMP.

The problems I currently face are:
a)  "Standalone" BFD Asynchronous Mode, the most widely implemented form of BFD as far as I've seen, will establish a single Control session that has the same UDP/IP 5-tuple for the life of that particular BFD session.  Unfortunately, the packets from that BFD session will get forwarded down only a single component-link of the LAG and/or ECMP path, due to the nature of the stateless load-distribution hash algorithm employed at forwarding time of the BFD packet.  With a large number of component-links in a single LAG and/or ECMP, this results in not monitoring a significant number of potential forwarding paths.
b)  In theory, LACP is already used for this (if/when the component-links are Ethernet); however, the fast periodic timer for LACPDU's is 1 second with a 3-second timeout.  Hardly sub-second detection.
c)  While it may be possible to use IEEE 802.1ag or ITU Y.1731 CCM (Continuity Check Messages), which are specified to detect physical link failures sub-second, the configuration of either of these protocols is massively complex and onerous, (think: several lines of configuration and associated variables per physical, component-link interface and then multiply that by the number of component-link interfaces in a single LAG).  It's also worth noting that the 'learning curve' for either of those protocols is fairly steep, while most IP/MPLS shops are already familiar with and have been using BFD for several years already.

In the "nice to have" category:
d)  LACP is only designed to work over a set of component-links whose physical port speeds are identical, (e.g.: all 10 GbE in a single LAG).  It may be useful to have a monitoring protocol that was able to check availability if/when there are different physical link speeds inside the same LAG group, e.g.: N x 100 GbE + M x 10 GbE.

For now, I'll stop short of suggesting some potential ways that BFD might be extended to support monitoring of component-links in a LAG and/or ECMP to first see if there's interest by others in considering taking on this work.  Assuming there is I would be happy to suggest appropriate scope and milestones of that work.

Thanks,

-shane

On May 7, 2011, at 7:35 AM, Jeffrey Haas wrote:
> <bfd-charter.txt>

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 11 May 2011 10:12:37 -0700

Hi Shane,

In case of Single-HOP BFD one could use the 127/8 IP address and scan the address range to exercise the other component links similar to LSP-Ping. Wouldn't that solve the problem?

Thanks
Shahram

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shane Amante
Sent: Wednesday, May 11, 2011 7:33 AM
To: Jeffrey Haas
Cc: [email-masked]
Subject: Re: Time for a recharter

Jeff, All,

Thanks,

-shane

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 11 May 2011 10:37:34 -0700

Hi Shane,

You have mentioned things correctly. Also in the standalone mode it may be
hard to detect issues if one of the links is still up, we need to run BFD at
the layer it is monitoring.

I see an additional usecase. Think of SPB using IS-IS, but running over
Layer-2 (and probably no IP in the data plane). We need to have a mechanism
to encapsulate BFD in Ethernet packets by using an Ether Type.

I had suggested this more then a few years back. I know they added it to the
odler charter as an exploratory item, but it never got looked at after that.
http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg00597.html

Thanks,
Vishwas

 The problems I currently face are:
> a)  "Standalone" BFD Asynchronous Mode, the most widely implemented form of
> BFD as far as I've seen, will establish a single Control session that has
> the same UDP/IP 5-tuple for the life of that particular BFD session.
>  Unfortunately, the packets from that BFD session will get forwarded down
> only a single component-link of the LAG and/or ECMP path, due to the nature
> of the stateless load-distribution hash algorithm employed at forwarding
> time of the BFD packet.  With a large number of component-links in a single
> LAG and/or ECMP, this results in not monitoring a significant number of
> potential forwarding paths.
>
b)  In theory, LACP is already used for this (if/when the component-links
> are Ethernet); however, the fast periodic timer for LACPDU's is 1 second
> with a 3-second timeout.  Hardly sub-second detection.
> c)  While it may be possible to use IEEE 802.1ag or ITU Y.1731 CCM
> (Continuity Check Messages), which are specified to detect physical link
> failures sub-second, the configuration of either of these protocols is
> massively complex and onerous, (think: several lines of configuration and
> associated variables per physical, component-link interface and then
> multiply that by the number of component-link interfaces in a single LAG).
>  It's also worth noting that the 'learning curve' for either of those
> protocols is fairly steep, while most IP/MPLS shops are already familiar
> with and have been using BFD for several years already.
>
> d)  LACP is only designed to work over a set of component-links whose
> physical port speeds are identical, (e.g.: all 10 GbE in a single LAG).  It
> may be useful to have a monitoring protocol that was able to check
> availability if/when there are different physical link speeds inside the
> same LAG group, e.g.: N x 100 GbE + M x 10 GbE.
>
> For now, I'll stop short of suggesting some potential ways that BFD might
> be extended to support monitoring of component-links in a LAG and/or ECMP to
> first see if there's interest by others in considering taking on this work.
>  Assuming there is I would be happy to suggest appropriate scope and
> milestones of that work.
>
> Thanks,
>
> -shane
>
>
>

---

From: Shane Amante <[email-masked]>
Date: Wed, 11 May 2011 11:48:04 -0600

Hi Shahram,

> In case of Single-HOP BFD one could use the 127/8 IP address and scan the address range to exercise the other component links similar to LSP-Ping. Wouldn't that solve the problem?

A similar suggestion was provided off-list to me by John Drake.

If there was MPLS encapsulation on the link that would work, (although I'm not sure the details of feeding the discovery of the component-links from something like LSP-ping to BFD are [adequately] specified, but perhaps I'm misinformed?).

However, that wouldn't work when the encapsulation is IP-only, i.e.: PE <-> CE (IPVPN) or ASBR <-> ASBR.

-shane

---

From: "Shahram Davari" <[email-masked]>
Date: Wed, 11 May 2011 10:54:18 -0700

Hi Shane,

-----Original Message-----
From: Shane Amante [mailto:[email-masked]] 
Sent: Wednesday, May 11, 2011 10:48 AM
To: Shahram Davari
Cc: Jeffrey Haas; [email-masked]
Subject: Re: Time for a recharter

Hi Shahram,

SD> This won't require any input from LSP-Ping. The procedure would be to change the Destination IP address for every BFD packet and scan through the 127/8 range. Almost all hashing algorithms use the IP-DA for hashing and therefore eventually all paths (component links) will be exercised.

Yes, that is correct since 127/8 is not a valid IP address on the link. However I am not sure why one would need to quickly detect a component link down in case of IP routing, since the router won't be able to reroute the packet anyway.

Thanks
Shahram 

-shane

---

From: Vishwas Manral <[email-masked]>
Date: Wed, 11 May 2011 11:05:03 -0700

Hi Shahram,

I see 2 issues:

1. As you mentioned "almost" all paths will be exercised (based on IP-DA).
2. We are running the OAM at a higher layer, which could mean that some
failures may be triggered even when there is no failure in LAG. Also note
not all LAG's are Layer-3 and may not be using IP in the data plane.

Thanks,
Vishwas

On Wed, May 11, 2011 at 10:54 AM, Shahram Davari <[email-masked]>wrote:

> > In case of Single-HOP BFD one could use the 127/8 IP address and scan the
> address range to exercise the other component links similar to LSP-Ping.
> Wouldn't that solve the problem?
>
> If there was MPLS encapsulation on the link that would work, (although I'm
> not sure the details of feeding the discovery of the component-links from
> something like LSP-ping to BFD are [adequately] specified, but perhaps I'm
> misinformed?).
>
> SD> This won't require any input from LSP-Ping. The procedure would be to
> change the Destination IP address for every BFD packet and scan through the
> 127/8 range. Almost all hashing algorithms use the IP-DA for hashing and
> therefore eventually all paths (component links) will be exercised.
>
> Yes, that is correct since 127/8 is not a valid IP address on the link.
> However I am not sure why one would need to quickly detect a component link
> down in case of IP routing, since the router won't be able to reroute the
> packet anyway.
>
> Thanks
> Shahram
>
> -shane
>
>
> > Thanks
> > Shahram
> >
> > I'd like to see if there's interest among WG members to take a look at
> [more thoroughly] specifying how BFD may be used to detect availability of
> component-links that comprise a LAG or ECMP.
> >
> > a)  "Standalone" BFD Asynchronous Mode, the most widely implemented form
> of BFD as far as I've seen, will establish a single Control session that has

---

From: Shane Amante <[email-masked]>
Date: Wed, 11 May 2011 12:19:35 -0600

Hi Shahram,

> SD> This won't require any input from LSP-Ping. The procedure would be to change the Destination IP address for every BFD packet and scan through the 127/8 range. Almost all hashing algorithms use…

OK.  There are likely other approaches to solving the aforementioned use case, as well, but presumably we'd get to those if/when the WG agreed there was sufficient interest to add this to the charter ... which is what I'm trying to focus on, for now.  :)  Are you supportive of adding this to the new charter?

> Yes, that is correct since 127/8 is not a valid IP address on the link. However I am not sure why one would need to quickly detect a component link down in case of IP routing, since the router won'…

A few things to keep in mind:
1)  IPFRR could be used to [quickly] reroute the packet; and,
2)  One may want to use BFD to quickly detect failure on a [single] "bad" component-link and remove it from the LAG group, while still keeping the LAG operational and still forwarding packets across the remaining "good" component-links.  This is similar to how 'minimum-links' works in various LAG implementations today, (where an operator may set minimum-links to N-1, N-2, etc. to achieve this behavior).  In theory, this same mechanism could also be used to trigger a CSPF to recalculate a new best path for MPLS LSP's that ride over this LAG, because there is insufficient BW to adequately carry all the traffic on the LAG.  In summary, BFD would be used for detection of a forwarding fault on one or more component-links, but the resulting 'action' could be one of either:
   a)  Tearing down the whole LAG or removing a 'path' from the ECMP group; or,
   b)  Leave the LAG and/or ECMP up/operational, in a 'degraded' state, and continue IP or MPLS forwarding across it, i.e.: no re-route would occur.

Thanks,

-shane

---

From: Mach Chen <[email-masked]>
Date: Thu, 12 May 2011 01:31:28 +0000

Hi Shane,

Thanks for pointed out this!

I agree with you that we may need to extend BFD to detect the failure of one/some/all links belonging to a LAG/bundle interface, and I also have seen similar requirements from some service providers. 

The requirements/scenarios are that BFD is required to run directly on the interfaces and associating the BFD session status with the status of the interfaces, thus consequently taking down or bringing up the interfaces rapidly by BFD One example of this is LAG/Bundle interface which is consisted of multiple component interfaces, it requires to detect the status of each component interface hence to block the fault interfaces when forwarding packets, or take down the trunk/bundle interface when the number/bandwidth of fault component interfaces reaches a preconfigured threshold. And actually we have a rough draft (interface BFD) about this which was written several months ago. 

Best regards,
Mach

> Sent: Wednesday, May 11, 2011 10:33 PM
> To: Jeffrey Haas
> Cc: [email-masked]
> I'd like to see if there's interest among WG members to take a look at [more
> thoroughly] specifying how BFD may be used to detect availability of
> of BFD as far as I've seen, will establish a single Control session that has the
> same UDP/IP 5-tuple for the life of that particular BFD session.  Unfortunately,
> the packets from that BFD session will get forwarded down only a single
> component-link of the LAG and/or ECMP path, due to the nature of the
> stateless load-distribution hash algorithm employed at forwarding time of the
> BFD packet.  With a large number of component-links in a single LAG and/or
> ECMP, this results in not monitoring a significant number of potential
> forwarding paths.
> b)  In theory, LACP is already used for this (if/when the component-links are
> Ethernet); however, the fast periodic timer for LACPDU's is 1 second with a
> 3-second timeout.  Hardly sub-second detection.
> c)  While it may be possible to use IEEE 802.1ag or ITU Y.1731 CCM (Continuity
> Check Messages), which are specified to detect physical link failures
> sub-second, the configuration of either of these protocols is massively complex
> and onerous, (think: several lines of configuration and associated variables per
> physical, component-link interface and then multiply that by the number of
> component-link interfaces in a single LAG).  It's also worth noting that the
> 'learning curve' for either of those protocols is fairly steep, while most IP/MPLS
> shops are already familiar with and have been using BFD for several years
> already.
> 
> d)  LACP is only designed to work over a set of component-links whose physical
> port speeds are identical, (e.g.: all 10 GbE in a single LAG).  It may be useful to
> have a monitoring protocol that was able to check availability if/when there are
> different physical link speeds inside the same LAG group, e.g.: N x 100 GbE + M
> x 10 GbE.
> 
> For now, I'll stop short of suggesting some potential ways that BFD might be
> extended to support monitoring of component-links in a LAG and/or ECMP to