* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Bfd Status Pages

Bidirectional 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

Minutes

minutes-101-bfd-00 minutes



          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.
          
          



Generated from PyHt script /wg/bfd/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -