Hi Jeff, I have nothing to change/add in the candidate minutes. Thank you! Regards, Greg
On Thu, Jul 30, 2020 at 9:12 AM Jeffrey Haas <jh...@pfrc.org> wrote: > https://datatracker.ietf.org/doc/minutes-108-bfd/ > > The following are the candidate minutes for the IETF 108 BFD session. > Please provide feedback to the mailing list. > > -- Jeff and Reshad > > # BFD IETF 108 - July 30, 2020 - 13:00-13:50 UTC > Chairs: Jeffrey Haas, Reshad Rahman > > # Agenda: > > ## Chairs update: > 10 mins - Jeff Haas & Reshad Rahman > > **Greg Mirsky** asks about bfd 2.0. > **Jeff Haas** answers we're likely rechartering to tighten our charter to > the core continuity check (CC) case. We're likely to try to spin off the > other inter-system protocol machinery for other state to another WG or BoF > depending on interest. IESG was luke-warm about this option, at best. WG > would happily help in such a spin-off. > > > ---- > > ## BFD for VxLAN: > 5 minutes - Greg Mirsky > > **Matthew Bocci** asks about BFD in Geneve. Question about testing to > individual VNIs. Also questions about issues related to ECMP. > **Greg Mirsky** notes that we're focusing on management VNI case. > **Reshad Rahman** asks about MAC assignments for non-management cases. > **Jeff Haas** WG had discussed the more general case for testing to VNI. > Decided to leave it out of scope based on IESG discussions on security > issues. However, the packet format is likely general enough for the test > to the VNI case, but is out of scope for our document. These issues also > applies to BFD for Geneve > > Greg and Xiao are working on Geneve, so the Geneve document will pick up > the relevant changes from WGLC discussion for vxlan document. > > ---- > > > ## BFD padding alteration (draft-xiao-bfd-padding-alteration): > 10 minutes - Xiao Min > > **Santosh Pallagati**: How does poll and final interact with timers. How > long do we do poll/final sequence? > **Xiao Min**: Should be very quick. > **Santosh Pallagati**: This is just for negotiating large packets on. > **Reshad Rahman**: Followup - scheduled packet, large packet sent in next > interval, verify that you get f-bit back. Some implementations have > policers; 1 packet ever X ms, we may see more. We may see drops of BFD > packets? Having reviewed BFD instability draft, this may show up as > instability. > **Xiao Min**: Extra padding poll can be sent more than once. > **Jeff Haas**: Poll continues until the the poller decides it is done. > **Greg Mirsky**: Poll is one packet per second? > **Jeff Haas**: Poll actually for the rate that the session is currently > running. pps is limiting factor for most bfd implementations. bfd large > changes bps as well. That may interact poorly with policers? > **Reshad Rahman**: Have you considered instead of on top of small packet > doing poll on just large packet? > **Xiao Min**: Intent is to keep bfd running when trying to toggle mode. > **Reshad Rahman**: You could replace a regular packet with a padded > packet. Concern that it could cause a BFD session to fail? > **Jeff Haas** (speaking as BFD large packet author): Would you (Xiao) > consider merging into bfd large? > **Xiao Min**: Yes. > **Jeff Haas**: Need to discuss requirements for operators that need the > large packet feature always on vs. negotiated. > > ---- > > ## BFD unaffiliated echo (draft-cw-bfd-unaffiliated-echo): > 10 minutes - Weiqiang Cheng > > **Weiqiang Cheng**: Procedural text in BBF document is unclear. > **Rakesh Gandhi**: We are doing similar things with TWAMP for > responder/reflector. Does this means we'll update 5880? > **Weiqiang Cheng**: Is aware of TWAMP. Don't have to change BFD solution. > Don't need to change remote implementation. It's just configuration. > **Jeff Haas**: This is different from BBF in that we're talking about a > BFD implementation on the receiver. This would update 5880 if so. > **Greg Mirsky**: Clarify on multiplexing on sessions for sender/receiver. > System assigns discriminator to the session - and it goes into the packet. > **Jaganbabu Rajamanickam** (Cisco): Is this same as S-BFD? > **Greg Mirsky**: Reflector (learned via IGP, etc.) has an active role in > BFD. This proposal uses transport layer looping. > **Jaganbabu Rajamanickam**: Could be loopback in data path. > **Greg Mirsky**: And therefore it's echo mode. > **Xiao Min**: The BFD echo is actually a control packet. > **Greg Mirsky**: If you're running multiple sessions, you'll want to demux > them. The contents of the packet matters then. > > **Jeff Haas**: Hum for adoption. Hum was panissimo - will take this > further to the mailing list. > > ----- > > ## Actions for after IETF: > - Submit BFD for vxlan to IESG > - Submit BFD Unsolicited to IESG > - Try to get last updates on BFD Authentication documents to respond to > shepherd reviews. Submit to IESG. > - Update BFD Large Packets per WG discussion. Discuss whether we're > submitting or holding back for further work. > - Update working group about chartering discussion for bfd v2/extended. > - Start adoption conversation for BFD unaffiliated. >
