BFD for Multipoint Networks
Note: This ballot was opened for revision 18 and is now closed.
Martin Vigoureux Yes
Ignas Bagdonas No Objection
Deborah Brungard No Objection
Ben Campbell No Objection
Comment (2018-07-02 for -18)
Please mention the fact this updates 5880 in the abstract. Also, in the introduction where you do mention the update, please add a sentence or two that give a satellite view summary of what the update actually is.
Alissa Cooper No Objection
Spencer Dawkins No Objection
Benjamin Kaduk (was Discuss) No Objection
Thank you for addressing my Discuss points! The original Comment portion of my ballot is preserved below for posterity. I am told that the normal usage of the bare term "BFD" has the connotation of refering only to usages in an IP/UDP/MPLS encapsulation (exclusing pseudowires and other more "exotic" encapsulations), so I am not including this in my DISCUSS section. However, it seems unusual to limit the scope of a document in some "random" subsection (here, Section 5.8) with no mention in the general Introduction or Abstract. Is there an improvement to make here? Section 4 [...] If no BFD Control packets are received by a tail for a detection time, the tail declares the path to having failed. For some applications this is the only mechanism necessary; the head can remain ignorant of the tails. It sounds like this might be better said as "the head can remain ignorant of the status of connectivity to the tails"? (That is, the head needs to know at least something about the tails in order to send anything to them, so it is not fully ignorant.) The head of a multipoint BFD session may wish to be alerted to the tails' connectivity (or lack thereof). Details of how the head keeps track of tails and how tails alert their connectivity to the head are outside scope of this document and are discussed in [I-D.ietf-bfd-multipoint-active-tail]. nit: "outside the scope" Section 5.7 It's a little unclear to me why tails must demultiplex on the identity of the multipoint path; (that is, why My Discriminator isinsufficient). Presumably this is just a failing on my end, of course. [...] Bootstrapping BFD session to multipoint MPLS LSP in case of penultimate hop popping may use control plane, e.g., as described in [I-D.ietf-bess-mvpn-fast-failover], and is outside the scope of this document. nit: some articles are missing here; maybe "a BFD session", "in the case of", and "the control plane". Section 5.12.2 MultipointTail sessions MAY be destroyed immediately upon leaving Up state, since tail will transmit no packets. Otherwise, MultipointTail sessions SHOULD be maintained as long as BFD Control packets are being received by it (which by definition will indicate that the head is not Up). Would it be more clear to say "indicate that the head is not Up yet" to distinguish from the case in the first paragraph (where a non-Up state *transition* Section 8 It may be appropriate to make stronger statements about the weakness of MD5 than were valid at the time of 5880's publication. (SHA1 is also not doing so great, but I won't block this work on updating the hash function options.) It would be good to either refer to the bit about shared keys in Section 6 or just move it to this section entirely.
Suresh Krishnan No Objection
Warren Kumari No Objection
Comment (2018-07-04 for -18)
Firstly, thank you for writing this - I've never needed this functionality, but can see where it would be useful. I fully support Mirja's DISCUSS - there should to be more text not just around congesting links, but also not shooting yourself in the foot with too many / too frequent packets. Ben's DISCUSS is also needs to be addressed. Comments: 1: "All other information MAY be determined dynamically." I don't think that a 2119-style MAY works here - I'd suggest "All other information can be determined dynamically." (or even just a lowercase may) 2: Section 5.7: "Bootstrapping BFD session to multipoint MPLS LSP in case of penultimate hop popping may use control plane, e.g., as described in [I-D.ietf-bess-mvpn-fast-failover], and is outside the scope of this document." "may use control plane" doesn't parse for me. Perhaps "may use *the* control plane"? I'm actually not sure what you are trying to say here, so that might not fix it. I also have some nits: Section 1: O: Term "connectivity" in this document P: The term "connectivity" in this document
Mirja Kühlewind (was Discuss) No Objection
Thanks for addressing my discuss.
Terry Manderson No Objection
Alexey Melnikov No Objection
Comment (2018-06-30 for -18)
This is a very readable document, so thank you for that. One small nit: In Section 5.6, last sentence of the first paragraph says: All other information MAY be determined dynamically. This is not correct use of RFC 2119 MAY, because it doesn't look like an implementation choice. I suggest you change it to lowercase "may" or "can".
Eric Rescorla No Objection
Comment (2018-07-03 for -18)
Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3589 It's not entirely clear to me what the relationship is between this document and RFC5880. Can you clarify? How does this handle duplicate/reordered packets? If I am reading RFC 5880 correctly, you only get that if you have authentication? COMMENTS S 1. > > As multipoint transmissions are inherently unidirectional, this > mechanism purports only to verify this unidirectional connectivity. > Although this seems in conflict with the "Bidirectional" in BFD, the > protocol is capable of supporting this use case. Use of BFD in > Demand mode enables a tail monitor availability of a multipoint path enables a tail monitor -> allows a tail to monitor? If not, I am confused S 5.13.1. > If the Detect Mult field is zero, the packet MUST be discarded. > > If the My Discriminator field is zero, the packet MUST be > discarded. > > Demultiplex the packet to a session according to Section 5.13.2 This is a bit confusing because it applies to the section here and not in 5880. S 5.13.2. > PointToPoint MAY be created, or the packet MAY be discarded. > This choice MAY be controlled by a local policy and is > outside the scope of this specification. > > If the State field is Init and bfd.SessionType is not > PointToPoint, the packet MUST be discarded. Is this material just duplicative of 5880? S 6. > from the viewpoint of any other tail. For this reason, using shared > keys to authenticate BFD Control packets in multipoint scenarios is a > significant security exposure unless all tails can be trusted not to > spoof the head. Otherwise, asymmetric message authentication would > be needed, e.g., protocols that use Timed Efficient Stream Loss- > Tolerant Authentication (TESLA) as described in [RFC4082]. As Ben's review implies, digital signatures would be an appropriate thing to use here.
Alvaro Retana No Objection
Comment (2018-07-04 for -18)
(1) This document is marked as Updating rfc5880, buy §4.1 (in rfc5880), still has this text: Multipoint (M) This bit is reserved for future point-to-multipoint extensions to BFD. It MUST be zero on both transmit and receipt. ...which should also be addressed in this document. (2) §5.3. (Session Failure Semantics): "If a MultipointTail session fails...the tail should take appropriate action." What is an "appropriate action"? I'm guessing that this has to do with I-D.ietf-bfd-multipoint-active-tail, but that only applies if a return path exists. In the general case, should the tail take any action? Please clarify. (3) §5.7 and §5.13.2 talk about "the identity of the multipoint path" -- what is that? (4) §5.13.2: If a session is not found, a new session of type MultipointTail MAY be created, or the packet MAY be discarded. This choice MAY be controlled by the local policy, e.g. a maximum number of MultipointTail sessions and number of active MultipointTail sessions, and is outside the scope of this specification. I think the last "MAY" above is out of place (s/MAY/may): if local policy doesn't exist, what is the option? The text says that this topic is outside the scope...but I'm not sure if that means the local policy or the choice itself. §8 (Security Considerations) offers some more insight...but it doesn't explicitly specify a limit to the number of MultipointTail sessions -- should one exist? The text above also calls out the "number of active MultipointTail sessions" as if it were something different (from simply the number of MultipointTail sessions), but this difference is not explained or mentioned anywhere else. Is there a difference? Is there a need to call this out? (5) Nit: Please don't abbreviate to "My Discr" and "Your Discr".
Adam Roach No Objection
Comment (2018-07-02 for -18)
The text in §5.1 says that MultipointHead sessions send packets with the M bit set. It probably bears mention that this is an explicit update to the RFC 5880 requirement that "It MUST be zero on both transmit and receipt." --------------------------------------------------------------------------- Nit (from id-nits): -- The draft header indicates that this document updates RFC5880, but the abstract doesn't seem to mention this, which it should. --------------------------------------------------------------------------- §4: > If no > BFD Control packets are received by a tail for a detection time, the > tail declares the path to having failed. Nit: "...to have failed." --------------------------------------------------------------------------- §5.6: > A session of type MultipointHead is created for each multipoint path > over which the head wishes to run BFD. This session runs in the > Active role , per section 6.1 [RFC5880]. Except when Nit: extra space before comma