Re:IETF 108 candidate minutes

[[e-mail]]

Hi Jeff,






I think the candidate minutes reflect the discussion during the BFD session very well, and I have no suggestion for revision on it.


Just a comment w.r.t BFD for Geneve to test non-management VNI, we have been attempting to address the issues found by IESG discussion on BFD for VXLAN.


The latest draft can be found with below link.


https://tools.ietf.org/html/draft-xiao-nvo3-bfd-geneve-03 


Let's discuss it in more detail on NVO3 mailing list :-)






Best Regards,


Xiao Min



原始邮件



发件人：JeffreyHaas <[e-mail]>
收件人：[e-mail] <[e-mail]>;
日 期 ：2020年07月31日 00:12
主 题 ：IETF 108 candidate minutes


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.