Bfd Status PagesBidirectional Forwarding Detection (Active WG)
Rtg Area: Alvaro Retana, Deborah Brungard, Martin Vigoureux | 2004-Jun-02 —Chairs:
IETF-101 bfd minutes
Session 2018-03-21 1330-1500: Buckingham - Audio stream - bfd chatroom
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.