RE: Time for a recharter

[Mach Chen <[e-mail]>]

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

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Shane Amante
> Sent: Wednesday, May 11, 2011 10:33 PM
> To: Jeffrey Haas
> Cc: [e-mail]
> Subject: Re: Time for a recharter
> 
> 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:
> > 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
> > <bfd-charter.txt>