Subject: Re: 答复: 答复: Solicit comments on BFD for Interface draft

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

Hi Mac,

This is exactly the point that i am trying to make - one pays a price by
sending BFD on each component link - so we must only do it if there is
no way out. Thus your comment in the earlier mail "From the view of
implementation, there is no difference between runing single BFD over a
LAG and runing per-link BFD." isnt entirely correct.

Cheers, Manav

On 8/1/2011 12:16 PM, Mach Chen wrote:
> 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
> number of IP interfaces that can support BFD goes down.
> 
> 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,
> 
>> 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.
>>
>> [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.
> 
> [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: Thomas Nadeau <[email-masked]>
Date: Mon, 1 Aug 2011 09:03:06 -0400

On Jul 31, 2011, at 10:31 PM, Shane Amante wrote:

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

	I totally agree. Having implemented the .ah/.ag stuff in a past life and worked with operators who were trying to deploy it, as well as worked at one who was trying to deploy it, Shane's analysis of the operational complexity is right on. BFD is as its name implies: dead simple to deploy as there is nearly 0 configuration - actually most implementations will have 0 configuration for routing protocols and links other than globally enabling it if it isn't already by default.  He is also correct when he stated that there are several potentially complicated steps to configure MIPs and MEPs within a network, most of which much be performed on EVERY box in the network where MIPs/MEPs exist, not to mention potentially when other configurations around the network change.

	--Tom

>> 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
> 
> 
>> 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
>> 
>> 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,
>> 
>> On Jul 31, 2011, at 8: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.
>> 
>> 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
>> 
>> 
>> 
>>> 
>>> 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]>
>>>>> 
>>>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> 
>> 
> 
>