On Mon, Jul 02, 2018 at 04:51:58PM -0700, Greg Mirsky wrote: > Hi Benjamin, > thank you for the thorough review and the most detailed analysis of the > specification. Please find my answers in-line tagged GIM>>. > > Regards, > Greg > > On Mon, Jul 2, 2018 at 8:38 AM, Benjamin Kaduk <[email protected]> wrote: > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-bfd-multipoint-18: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-bfd-multipoint/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Section 5.13('s subsections) of this document replace sections 6.8.6 and > > 6.8.7 of RFC 5880. I extracted the relevant text and performed a diff, and > > think some discussion is needed of some portions present in RFC 5880 that > > are not present in these new texts. (The separation of the demultiplexing > > procedure to a separate subsection is fine, though it does make the diff a > > little nosier to read.) > > > > In particular, from RFC 5880 Section 6.8.6, the paragraph: > > > > % If the Poll (P) bit is set, send a BFD Control packet to the > > % remote system with the Poll (P) bit clear, and the Final (F) bit > > % set (see section 6.8.7). > > > > Does not appear to have any corresponding text in this document. > > > GIM>> Thank you for catching this one! Without getting into the history, > here's the new paragraph to be the next to the last para in section 5.13.1: > > If the Poll (P) bit is set, and bfd.SessionType is PointToPoint, > send a BFD Control packet to the remote system with the Poll (P) > bit clear, and the Final (F) bit set (see Section 5.13.3).
A natural translation to the new world order. > > > > > >From RFC 5880 Section 6.8.7, the first four paragraphs (too long for me to > > include here) do not appear to have their substance covered in this > > document, either (largely discussion about the pacing of BFD Control > > packets and jitter in their scheduling). > > > > Section 5.13.3's text now only covers how to set Min Echo Rx Interval > > for MultipointHead and MultiplintTail sessions, which seems to remove > > guidance on how to set it for other session types. > > > > While it is permissible for a document that Updates another document to > > perform this sort of deprecation of behavior, it is potentially confusing > > for implementors to do so without mentioning the change in behavior. > > > > GIM>> Thank you for pointing to these absent paragraphs. Some of > information being provided in the section but some, I agree, is not part of > the section. That information helps to understand packet transmission > timing and how it affects defect detection interval. > > The forth paragraphs of section 6.8.7 RFC 5880: > > The transmit interval MUST be recalculated whenever > bfd.DesiredMinTxInterval changes, or whenever bfd.RemoteMinRxInterval > changes, and is equal to the greater of those two values. See > sections 6.8.2 and 6.8.3 for details on transmit timers. > > used in section 5.13.3 of mpBFD specification: > If bfd.SessionType is not MultipointHead, the transmit interval MUST > be recalculated whenever bfd.DesiredMinTxInterval changes, or > whenever bfd.RemoteMinRxInterval changes, and is equal to the greater > of those two values. See [RFC5880] sections 6.8.2 and 6.8.3 for > details on transmit timers. > > The first three paragraphs that are missing and I propose to use them as-is > in RFC 5880 to replace the second paragraph of mpBFD spec (new version and > diff attached). That works for me. > > > > > Separately, I wonder if it is appropriate to Update RFC 7880 as well as > > 5880, given (e.g.) Section 5.4.1. > > > GIM>> mpBFD specification adds new values to a variable defined in RFC 7880 > but does not change anything specified in RFC 7880. I'm not sure that this > relationship between the RFC 7880 and mpBFD can be characterized as the > latter updating the former. I'm not sure, either. The case for Updating would mostly just be that someone implementing 7880 would want to know if they see new/unexpected values on their peer (and I've forgotten if this one is even wire-visible). > > > > I also think that Section 6 should describe more clearly how asymmetric > > message authentication relates to this work (i.e., whether it is entirely > > incompatible with BFD or does it merely require additional specification). > > > GIM>> I believe it requires additional specification, i.e. outside the > scope and for future work. Okay. Do you want to add something like ", but integrating such authentication mechanisms with BFD is outside the scope of the present work"? [edit: I see you did add something; that works for me] > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > 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? > > > GIM>> I see the scope of this specification similar to RFC 5880, in which > there's no discussion of how BFD Control packet must be encapsulated. For > "classic" BFD, encapsulation addressed in RFC 5881, RFC 5883, RFC 5884, and > RFC 5885. Non-IP encapsulation for MPLS-TP defined in RFC 6428. My question is entirely about the current connotations of a term in a community where I am not active, so I really have to leave this question to be answered by the authors/WG. > > > > 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.) > > > GIM>> Thank you for text, accepted. > > > > > 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" > > > GIM>> Thanks, done. > > > > > 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. > > > GIM>> The value of My Discriminator is locally assigned, i.e., assigned by > the head. Unless some system manages discriminator ranges amond heads, it > is probable that more than one use the same My Discriminator value. I was probably assuming that the discriminators were random values; thanks for clarifying. > > > > [...] 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". > > > GIM>> More thanks, all accepted. > > > > > 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* > > > GIM>> I think that the two paragraphs correctly describe behavior options > for a MultipointTail session when it receives BFD Control packet with > Down/AdminDown state. The tail MAY close the session upon recieving packet > with Down/AdminDown state. The second para is related to section 5.12.1 > that the MultipointHead SHOULD continue transmitting BFD control packets > with the new state, i.e., Down/AdminDown state. I also agree that the paragraphs are correct behavior descriptions -- the combination just made me do a double-take when I first read it. But this is basically editorial, so use your judgment. > 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. > > > GIM>> Merged sections 6 and 8 under Security Considerations. That combination seems to work pretty well. (Full draft text trimmed.) Thanks! -Benjamin
