RE: document layout for singlehop, multihop and generic

[[e-mail]]

Peter,

I fail to see how using BFD to detect component link failures in a link-group will be useful, perhaps you can provide more details on your proposal? 

If an individual link fails then the traffic using the failed link should be switched over to one of the other links in the link-group, i.e. as long as at least one link in the link-group is up and has enough bandwidth available, no packets should be dropped (including BFD over UDP packets). For distributed BFD implementations where BFD packets are generated/processed on a per line card basis, it might be possible to check that a BFD packet for a particular session is received via the correct link. However, depending on the system architecture, checking which link a BFD packet is received on may be complex/costly if not impossible for implementations that use a centralised CPU for BFD packet generation/processing. This restricts the applicability of your proposal to either (i) using BFD to detect link failures as a backup measure in case the 802.3ad component link failure mechanism isn't working, or (ii) providing failure detection faster than the average/maximum 802.3ad link failure detection time.

Regarding (i), if 802.3ad link failure detection isn't working then there is obviously a problem so its quite likely that BFD will also be effected (especially as the BFD session setup and state maintenance will somehow need to be linked to the 802.3ad load balancing policy/algorithm). Regarding (ii), the 802.3ad implementations that I know of use some kind of polling to detect component link failures. Failure detection time is normally between 1-100ms, depending on when the next poll is due when the failure occurs. IMO an average link failure detection time of 50ms is more than fast enough for most if not all applications.

There are also other factors that need to be considered as well such binding both directions to the same component link (particularly when using systems with different 802.3ad load balancing policies/algorithms), and issues caused by intermediate hops between the BFD systems also running 802.3ad.

In general, IMO it is not sensible to use an IP/UDP based protocol to detect component link failures for a link aggregation mechanism that has been purposely designed to be transparent to IP/UDP.

Regards,
Richard

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]On
> Behalf Of Peter Arberg
> Sent: 25 October 2005 22:07
> To: 'David Ward'; 'Pekka Savola'; [e-mail]; 'Jeffrey Haas'
> Subject: RE: document layout for singlehop, multihop and generic
> 
> 
> Hi,
> 
> I have one suggestion which I would like to see in one of the
> documents, best fit would proabably be in the 1hop document,
> but could also be in the generic one.
> 
> The usage of BFD over 802.3ad ethernet link-groups, in an
> application to detect faults in the individual links inside
> the link-group.
> 
> (not BFD over ethernet, but using the BFD over UDP approach)
> 
> I could propose some text for this, and we can discuss it
> based on this, and then if you do not think it belongs in either 
> of these document, or it is to late in the game to propose
> changes,  then I could create a new internet-draft with a 
> suggestion for this functionality.
> 
> thanks,
> Peter
> 
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]] On Behalf Of David Ward
> > Sent: 25. oktober 2005 22:46
> > To: Pekka Savola; [e-mail]; David Ward; Jeffrey Haas
> > Subject: Re: document layout for singlehop, multihop and generic
> > 
> > We covered this at the last several WG meetings. The issue 
> > is: reorganizing
> > the docs w/o changing the content vs getting the docs to spec 
> > ... The WG
> > agreed to get the docs to full standard.
> > 
> > -DWard
> > 
> > 
> > On 10/25/05 5:22 AM, "Pekka Savola" <[e-mail]> wrote:
> > 
> > > Hi,
> > > 
> > > I'm still puzzled by the coverage of various documents:
> > > 
> > > 1) bfd-multihop-03: about 3 pages of very generic (non-protocol
> > > specific) guidance on multihop BFD sessions.
> > > 
> > > 2) bfd-v4v6-1hop-04: the first 4.5 pages are very generic 
> single-hop
> > > BGP guidance (applicable to any single hop BFD 
> > application), the next
> > > 4 pages detail a number of OSPF/IS-IS details for single-hop cases
> > > 
> > > 3) bfd-generic-01: about 5 pages of generic BFD guidance (not
> > > specific to either single or multihop).
> > > 
> > > This seems like patchwork.  IMHO, a more logical 
> separation might be
> > > having everything generic (either single or multihop) in 
> > one document
> > > and moving the protocol-specific details out of v2v6-1hop to a
> > > separate BFD+OSPF/ISIS document.
> > 
> 
> 
>