Minutes IETF101: bfd
minutes-101-bfd-00

BFD Minutes
IETF 101 - London
Wednesday, March 21 - 13:30 - 15:00.
Jeffrey Haas and Reshad Rahman Chairing.

[Chairs slides]

(re: Documents in other working groups related to BFD.)
Greg Mirsky: In rtgwg, there is another document for vrrp p2mp bfd. The
rtgwg chairs will start a wg adoption call.
Jeff Haas: One of the reasons this was split from the origianl p2p document
  was IPR considerations.  What's the status of that?
Greg Mirsky: It was updated and there are ways to avoid this IPR. (To best
  of Greg's understanding.)

Reshad Rahman: draft-ali bfd for spring. There's been discussion on the
  (not-bfd) mailing list.
Greg Mirsky: BFD Working Group experts are requested to look at this and
  whether it's necessary. RFC 7882 covers the uses cases for this?

---

Presentation: BFD Yang Status - Reshad Rahman

[slides]

No comments.

----

Presentation: BFD for vxlan - Greg Mirsky

[slides]

Greg Mirsky: No report on interoperability of the known implementations.
Reshad Rahman: Any report on how close to them being compliant?
Greg Mirsky: They are compliant
Jeff Haas: Who are the two implementations?
Greg Mirsky: I need to ask them if it's okay to make it public.

[slides]

Greg Mirsky: An open question to the Working Group about selection/use of
  IP encapsulation of addresses? There has been no input from the
  implementations. If there are no special considerations, we can remove the
  editor's note.  
Jeff Haas: With those open question, are we ready for last call?
Greg Mirksy: Suggest time is needed for the list to read.  Then wglc
Reshad Rahman: Who has read the document? 1 person.

---

Presentation: BFD Performance - Mahesh Jethandani

Reshad Rahman: Document makes forward looking reference to new BFD version?

[slides]

Greg Mirsky: Already had discussion with Mahesh to understand scope and
  mechanism used. Uses BFD echo?
Mahesh Jethandani: BFD echo - not necessarily supported. 
Greg Mirsky: Also, don't know what BFD echo packet format is. RFC 5880
  doesn't specify echo contents. May want to seek feedback from the few
  implementors that implement BFD echo mode. What you are measuring is packet
  delay over single-hop Layer 3 link. In that context, I wonder why it's
  important to use BFD packets? You're just looking for Layer 3 packet
  traversal time. The link can have Layer 2 or Layer 1 equipment.  Echo mode
  implies there is no layer 3?
Reshad Rahaman: Why would you think this is single hop?
Greg Mirsky: Echo implies single hop.
Mahesh: If you assume echo, yes. 
Greg Mirsky: Then you have complexity of collecting timestamps. Over async
  mode, how do you transport timestamps from ingress to egress?  TWAMP can be
  used to extrapolate measurement results. It works over UDP. Close to what
  BFD would experience.


Mahesh Jethandani: Trying to follow RFC 6374 for timestamps. As far as
  actual time stamp, sender will put in T1, T2 is receivers.

Ashesh Mishra (online): Are we in agreement that the issue proposed in BFD
  performance is real? If so, we are flexible on the mechanism. 

Greg Mirsky: I understand operational issue.  Questioning actually using
  BFD. We can use actual [existing] IP measurement tools.
Reshad Rahman: We can't quite do TWAMP. Not to ms rates.
Greg Mirsky: Why not? Are you talking about implementation deficiencies?
Reshad Rahman: If you're trying to figure out detection intervals of BFD,
  why measure something else? BFD has capability.
Greg Mirsky: Even in transit nodes, it doesn't matter if it's BFD or not.
  They just forward this traffic.  In measurement, ignore processing by host;
  transit delay is measured on this path.  Host processing of ingress and
  egress points should be measured.
Reshad Rahman: I'm trying to determine detection interval of BFD.

Ashesh Mishra (online): This is not link performance measurement. If the
  BFD engine incurs delays, then that needs to be accounted in the detect
  interval determination. This can be a significant issue in the software
  implementations. 
Ashesh Mishra (online): We'd like to invite collaborators to iron out the
  mechanism to self-tune. 

Jeff: Self tuning in BFD might be the thing to discuss first before
  discussing the mechanism.

Jeff Haas: BFD wants the Up/Down behaviors of BFD You're trying to tune it
  to have a reasonable lower threshold. Problem becomes, you have to be
  careful about tuning it down and not drop the session as part of that.  Use
  case is to try to allow some level of tuning.  Draft I did with Xiao Min
  about using BFD echo to use a higher detection interval to test this.  But
  this was using echo.  You could use echo as part of probe mechanism for
  single-hop BFD - or a separate channel.  But doing this in async mode may
  be tricky at best.
Mahesh Jethandani: If the interval is set high enough, you're not dropping
  packets. You're collecting enough samples to try to determine.
Jeff Haas: I understand, start with something higher, then adjust lower.
  But for many BFD applications is that you're supporting a given lower
  threshold. If you can't support that, why self tune?
Mashesh Jethandani: Largely latencies that vary over time. How do you come
  up with that time interval?  Need figure out what that interval _should_ be.
Reshad Rahman: ...
 
Reshad Rahman: How this came along is not something theoretical - it's
  problems that have been seen?

Ashesh Mishra (online): Yes. This is an issue we face in non-geostationary
  orbit satellites
Ashesh Mishra (online): @Jeff: Reason for auto-tuning is that we have 10s
  of thousands of terminals and each with different characteristics. They
  can't all be manually tuned to provide reasonable performance. 
 
Jeff Haas: Some level of variability. In such situations, detection
  interval might be periodic. Should tune for worst case.
Greg Mirsky: BFD for microwave links may also be interesting. Bandwidth
  availability gets tuned in external environment. Going to less aggressive
  intervals could ease conditions for interesting scenarios.  Very concerned
  about auto-adjusting algorithm and mechanism since they produce unexpected
  results.

----

[Note from Jeff: Audio stream stops here for some reason.  Notes may be incomplete.]

----

Presentation: BFD unsolicted - Jeff Haas presenting for authors who could not attend

[slides]

Les Ginsberg: Is there anything to be standardized?
Jeff Haas: Very minor changes, if any.
Les Ginsberg: There maybe be people already doing this.
Greg Mirsky: This document is informational. No protocol changes are
  needed. If anything, minor yang model update?
Jeff Haas: Yang model single hop has key that needs address? This is
  effectively wildcard.
Reshad Rahman: We should wait and not do so quickly.

----

Presentation: Clarify bfd session bootstrap - Greg Mirsky

[slides]

George Swallow: One has an optional behavior. Why not just say MAY IGNORE
  rather than MUST?
Greg Mirsky: MAY is already there in 8209.  If we want to make the process
  more definite, we have to say which mode is more preferable for boostrap.
George Swallow: You're saying may not send.  If you say SHOULD NOT, you
  still have to deal with when it does send it back. Hence MAY ignore rather
  than MUST.
Greg Mirsky: What does it do? Implementation specific? If we have two LERs,
  one which includes BFD discriminator TLV in reply and other which does
  something unspecified with it...
George Swallow: It's passed up to the thing that asked for it in the first place.
Greg Mirsky: The purpose of the ping is bootstrap rather than continuity.
George Swallow: That depends on the implementation - the level above BFD.
Jeff Haas: [...]
George Swallow: [...?]
Greg Mirsky: For the reply - it's underspecified whether BFD discriminator
  should be included, and what it should be set to [jh - and what to do if
  it's inconsistent]
Martin: What are you afraid will happen if you get the discriminator - what
  will it do wrong?
Greg Mirsky: Can't find this BFD session. It will not properly correlate.
  The authoritative information is the BFD data; LSP Ping is only for
  bootstrap. That's why I suggest no reply - it serves no purpose.
Reshad Rahmman: I agree that reply serves no purposes.  The egress node
  sends its discriminator.  That discriminator is useless. Like martin says,
  it's not bad.
Greg Mirsky: RFC 5884 does[n't ?] say what gets sent. The local or remote
  discriminator.  It doesnt even say if it should be included.
  Reshad Rahman: That was purpose of errata. The discriminator is in RFC 5884.
Greg Mirsky: Only in request? Not in reply.
Reshad Rahman: Can look at it after.
Greg Mirsky: When the reply gets sent back, how to de-multiplex?  
Reshad Rahman: Agree that discriminator is useless, but harmless.  To
  optimize, we don't need that.  It's not a big issue.
Martin: Concerned by the value. When you receive it, you have to decide
  what to do with it - good or not.
Jeff Haas: This has caused interoperability problems.
George Swallow: Should be OR a MUST. Should not AND a MAY [?] Responder
should not send this, if it does, the ...
Martin: Egress behavior, ingress behavior.
Jeff Haas: Greg, your document is not intended to be a -bis, but seed for
  -bis doc?
Greg Mirsky: Want some agreement on the behaviors. 
 
----
 
Presentation: draft-mirsky-bfd-mpls-demand - Greg Mirsky

[slides]

Greg Mirsky: In an offline exchange with Jeff, Jeff thinks that this is
  obvious? Is there any interest in this as a Working Group document?
Reshad Rahman: [Who has read the document?] Two people, including Jeff.

----

Presetnation: draft-mirsky-mpls-p2mp-bfd - Greg Mirsky

[slides]

Reshad Rahman: The document says BFD, but seems targeted for the MPLS
  Working Group? 
Greg Mirsky: I did present there. Jeff said also present here.
George Swallow: Agree that it should be mpls.  
Jeff Haas: We'll coordinate with mpls chairs.
Greg Mirsky: Requires change in a registry.

---

Presentation: draft-mirsky-bfd-p2mp-vrrp-use-case / pim - Greg Mirsky

[slides]

No comments.

---

Presentation: BFD encapsulated in large packets - Jeff Haas

[slides]

Jeff Haas: Major question is whether to negotiate or to do solely by
  configuration.  Negotiation will require BFD protocol changes;
  configuration may just work.

Ashesh Mishra (online): Negotiate or configure. Some hardware BFD
  implementations have specific sizes of packets that they can handle and
  they will fall flat when they get big packets. 

-----

Note for Secretariat: BFD meeting took full session time.