Minutes for Bidirectional Forwarding Detection IETF-92, Dallas 13:00-15:00 Monday Chairs: Nobo Akiya , Jeffrey Haas Agenda: http://www.IETF.org/proceedings/92/agenda/agenda-92-BFD ----- Presentation: Administrivia, BFD Chairs Presenting ----- Presentation: BFD Yang, Reshad Rahman Presenting [slides] -01 was published this morning. -02 will cover -IETF pyang option. Challenge: BFD using multiple key types for different session types. The BFD sessions have different keys in the protocol. Used separate containers to solve this problem. Would like feedback on ways to potentially do it better? Some implementations put BFD under application, some under core BFD session including centralized BFD. VRF centric, still waiting for this to resolve IETF-wide. [Note from Jeff post-meeting: The netmod working group seems to have some internal consensus to use VRF-centric model for netmod-rtg-cfg.] No consensus on what to do for configuration stanzas for BFD in other models. Shahram Davari: Keys are different for application. Why not use discriminator? Reshad: We discussed this in some Design Team sessions. Not all implementations allow configuring the discriminators. Also an issue for distributed system. Jeff Haas: We may want operational state queries keyed on discriminator, but how do we sub key for non-disjoint components in a system? Greg Mirsky: If discriminator is not a key. How do you provide for uniqueness for BFD over LSP? This is in the clarification 5884 document. Reshad: You think the configuraton for discriminator must be configurable? Greg: in 5884 - you must use LSP Ping bootstrap. How the discriminator is populated is outside the scope. It comes from system allocation. Reshad: If it's not part of config, it can't be part of key. Greg: You can't configure multiple BFD sessions if it isn't. We agree there is a gap. Mahesh: The issue is exactly that. The discriminator can be made unique. We're talking about a system level config where there might be a system-wide conflict on discriminator. Let's say it's made unique, it's an operational model - can't be used for a config. Greg: But then your model can't handle multiple sessions. If it's a deficiency in yang... Reshad: Can't say that it isn't in yang, but this may make sense in MPLS LSP container. Say we configure it, then we configure it on a FEc? on an LSP? you wouldn't do per path. Mahesh: We're talking about the key for BFD sessions. This has nothing to do with the stuff in the packet - it's for operational purposes. Shahram: It's just configuration. Nobo: Relationship with lime Design Team? Reshad: We decided to ignore until lime contacts us. Once something comes out, we can respond. Jeff: The BFD yang model is exposing a config element for other modules is new thing IETF-wide in yang. Let's figure out if this is a good idea and help support it across IETF if so. ----- Presentation: Trill support for BFD P2MP, Mingui Zhang presenting [slides] Jeff: This document depends on BFD multipoint active tail becoming a Proposed Standard. Please review and help it to advance. ----- Presentation: S-BFD alert discriminator, Nobo Akiya presenting [slides] Last piece of core functionality for S-BFD. already have IGP and BGP-LS extensions. things like inter-as, other things that can advertise discriminator. How could we do this discriminator discovery in the core protocol? Shahram This is how BFD was designed. What is new? Nobo: This is how BFD is designed. Seamless BFD didn't have this. Shahram: Same thing as BFD? Greg Mirsky: We're coming to 5880 from a different side. The advantage of S-BFD was to not have to negotiate discriminator. Now you've found a need to do dynamic discovery. This brings the whole BFD. This moves S-BFD to be BFD. Nobo: That's a fair comment. If we didn't do alert discriminator and want to use it for VCCV, DS-LITE, you have to extend each of them to learn discriminator. If you want to use protocol extensions, that's great, but only if you need to. Jeff: Real benefit to S-BFD is that it's stateless. Greg: If we want to do stateless on the reflector, keep it out of reflector. Jeff: Why is this state? Greg: What if they want to change it? BFD has a process to do this. Nobo: If the WG wants to do this for every protocol, and it's consensus we can do it. Nobo: If there's more than one, you have do demux on something's part of the packet. Santosh Pallagati: In MPLS we can use 127.... Here, since it's zero, you would have to demux on label? [Room was polled to gather the sense of the room. Slightly more interested in protocol only vs. this S-BFD alert discriminator feature.] Jeff: There's also corner cases even if we keep this as documented. Nobo will see what we can do to clarify. ------ Presentation: S-BFD for VCCV, Stewart Bryant presenting. [slides] Greg Mirsky: Motivation for S-BFD was that BFD echo couldn't be used for multihop. Jeff: That depends. Greg: That was one of the reasons for S-BFD. For PW it's not a requirement. Normal BFD could be used over PW. Why not use echo BFD? Stewart: Echo would require dataplane. Would this require number of dataplane changes instead of control plane change. Greg: For PW, it's single hop. Stewart: PW is single hop in PW, but not in LSP. Nobo: If you have the IP dest address as self. If there's a break in PW and the packet is exposed, it could come home. Eric Gray: You should drop in that case. Nobo: If the node pops the VC label, then Echo is routed. Greg: Echo BFD request does have discriminator. It has discriminator of the peer. Jeff: Where should this be adopted? PALS or BFD? Stewart: There are two drafts. Anything 5885 is PALS work. Vengada Prasad Govindam: Both. Shahram: Are you going to define new VCCV type or new channel type? Vengada Prasad Govindam: a. New G-ACH type is needed for S-BFD for encapsulations without IP/ UDP. b. New CV Types for SBFD are needed to signal the capabiltity. S: Natively. What do you do during bring-up? If you can support both BFD or S-BFD, which do you support? My concern as PALS chair leaving this as an open question is a bad idea. It impacts bring-up. Shahram: Which channels? Stewart: Haven't thought of it. Jeff: Adopt where? Stewart: The VCCV parts definitely in PALS. ----- Presentation: BFD authentication, presented Ashesh Mishra [slides] Shahram: In non-meticulous mode, only need this once. Just use that. Ashesh: Agreed. That's one good solution. But you still need to *check* Shahram: it's easy Ashesh: Agreed, we could do that. Greg Mirsky: Removes burden on stable case. When there's a change, auth kicks in. Does that defeat the whole purpose? Ashesh: From the perspective on non-auth system, yes. Greg: Make your worst case scenario. Why go through incremental case when worst case is worst. BFD is to detect failures. Ashesh: Good point - being efficient in worst case scenario. How do we definie that? Some systems, session maintenance is the hard case. Cheaper hardware, constrained resources, etc. Greg: From my experience, if system can't sustain non-auth and then auth kicks in, then not all state changes may be detected. We are scaling for good weather, will fail when it stops raining. Ashesh: Comparison against fully authentication instead of without authentication. Santosh Pallagati: Want to do auth every 10 seconds. Some implementations can't do aggressive at fast rates. If there's not negotiation, how do we know we can do that? Ashesh: That's one of our open issues. Would like more authentication. Shahram: No proposing new standard - can already do this. Just use auth bit. Ashesh: Ideally use existing types. Jeff: 5880 has cautionary text about transitioning in and out of auth. We'll have to work on that significantly in this draft. Mahesh: Session change causing load has already been pointed out. No worse than fully authenticated systems. When you don't authenticate every frame, you don't queue as many. Nobo: This all applies during polls. A: Yes, poll/final. Any operational state change. Mahesh: Constant frames are time sensitive. Auth adds more sensitivity in hardware. State frame changes are less time sensitive. Shahram: We have implemented BFD in sw, doing non-meticulous. Can run exactly same number of frames. You're just comparing two numbers. A digest. Jeff: Interest in adopting in WG? Ashesh: Next Working Group session. Jeff: Who is looking to advance this work? (only one) ----- Presentation: BFD stability, presented by Santosh Pallagati. [slides] Shahram: Proposing new auth type? Just usinge seq #? Santosh:: Yes. Manav we might be able to add this to bytes after packet. Nobo: Addition is a sequence number. If the seq#, it doesn't help you with delay. SPK: We can infer some of this from the sequence numbers. Nobo: Can help with drop. Can help with reorder. Can't really do delay? Santosh: There were some intenral discusssion about that internally. Greg: Your experiences are interesting. This is targeted as standards. Would you take it experimental? Jeff: (To Greg) What would it take to convince you to let this go forward as standards insead of experimental? Greg: Backward compatibility. Mahesh: If adding TLV is issue (from -00), we could just do drop measurement using standard BFD. Only change is auth had a no-auth option. Greg: We can discuss that. We have a large install base. Changing format is hard. Santosh: Backward compatibility is good point. Reshad: Could we use this for echo? Santosh: Sure, echo is not standardizd - up to the implementation for the content. Mahesh: When you talk about backward compatibility, if new TLV... ----- Presentation: BFD direfcted return path, presented by Greg Mirsky. Loa Andersson: What is the status of IP-SBFD? Nobo: Use case draft progressing. Greg has pen to finish. base draft follows, then ip dataplane draft. that will cover MPLS as well. Loa: Will this happen before the Prague IETF? Greg: Use case should be done in two weeks. Nobo: Will try to progress fast, but can't promise that it will be done by Prague.