Hi Benjamin, thank you for the comments and suggestions. Please find my answers, notes in-line and tagged GIM>>. Would you agree I roll them in when working with the RFC Editor?
Happy New Year to All! Regards, Greg On Fri, Dec 21, 2018 at 7:59 PM Benjamin Kaduk <[email protected]> wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-bfd-multipoint-19: No Objection > > 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/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > 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? > GIM>> Will add the following in the Introduction: This document defines IP/UDP encapsulation of BFD Control message in multipoint networks. Use of other types of encapsulation of the BFD Control message are outside the scope of this document. > > 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>> Yes, agree. Would imagine that the head would stop sending BFD control messages if there's no, at least, one tail. Will update. > > 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>> Thank you. > > 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>> My Discriminator is not globally unique as it is allocated per MultipointHead. Thus, it is possible, that a tail that belongs to several multipoint paths, will receive BFD control packets from different heads but with the same My Discriminator value. > > [...] 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>> Thank you, agree to all three. > > 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>> The second paragraph is to explain the behavior of a MultipointTail if the MultipointHead acts as described in section 5.12.1. Perhaps we can leave the text as is? > > 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.) > GIM>> Would the following text be acceptable (with both RFCs as Informational reference): Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithm [RFC6151] and Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithm [RFC6194] refer to the recent escalating series of attacks on MD5 and SHA-1 as the reason to consider stronger algorithms. 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>> Merge sections 6 and 8? Section 7 will be removed in the final text and these sections become adjacent. Perhaps can leave them as is, would you agree?
