Skip to main content

Support of Point-to-Multipoint Bidirectional Forwarding Detection (BFD) in Transparent Interconnection of Lots of Links (TRILL)
draft-ietf-trill-p2mp-bfd-09

Yes

(Alia Atlas)

No Objection

Warren Kumari
(Adam Roach)
(Alissa Cooper)
(Benoît Claise)
(Deborah Brungard)
(Mirja Kühlewind)
(Spencer Dawkins)
(Suresh Krishnan)
(Terry Manderson)

Note: This ballot was opened for revision 08 and is now closed.

Warren Kumari
No Objection
Alia Atlas Former IESG member
Yes
Yes (for -08) Unknown

                            
Adam Roach Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Alissa Cooper Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (2018-01-23 for -08) Unknown
(1) The first reference to I-D.ietf-bfd-multipoint appears in Section 5; please add one in the Introduction when Multipoint BFD is initially mentioned.

(2) I think that using Normative Language (without quotation marks) to mention what is specified somewhere else can result in confusion as to which is the authoritative document.  This seems to be the case in Section 4: "If the M bit of the TRILL Header of the RBridge channel packet containing a BFD Control packet is non-zero, the packet MUST be dropped [RFC7175]."  The sentence sounds as if the behavior is specified in rfc7175, but that document says (in Section 3.2 (BFD Control Frame Processing)): "The following tests SHOULD be performed...Is the M bit in the TRILL Header non-zero?  If so, discard the frame."  Note that the behavior specified in rfc7175 doesn't use a "MUST".  The text in this document seems to be used to explain why a new message is needed, and not in a Normative way -- please clarify the text so that there is no inconsistency with respect to rfc7175.

(3) Section 5 says that the "processing in Section 3.2 of [RFC7175] applies...If the M bit is zero, the packet is discarded."  Section 3.2 has that "SHOULD" that I mentioned above, and it also mentions potential security issues, which are not referenced in this document.  Are there reasons to keep the "SHOULD" and not use "MUST" instead (for the p2mp case)?  If the same semantics as in rfc7175 are kept, then the Security Considerations should include the concerns.
Ben Campbell Former IESG member
No Objection
No Objection (2018-01-23 for -08) Unknown
There are a number of lower case "should" instances. Please consider using the boilerplate from 8174.

(I am starting to sound like a broken record this week :-) )
Benoît Claise Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Deborah Brungard Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Eric Rescorla Former IESG member
No Objection
No Objection (2018-01-18 for -08) Unknown
I'm hoping this can be resolved quickly, as it's probably just a missing
cite. If it turns out that there's actually missing content, this
may turn into a DISCUSS.

   Multipoint BFD provides its own authentication but does not provide
   encryption (see Security Considerations in [I-D.ietf-bfd-
   multipoint]). As specified in this document, the point-to-multipoint

I skimmed the reference here, but wasn't able to figure out what the
authentication was. In particular, the document says:

      If the A bit is set, the packet MUST be authenticated under the
      rules of section 6.7, based on the authentication type in use
      (bfd.AuthType.)  This may cause the packet to be discarded.

But there is no 6.7. So, this makes me worry that I don't understand
any of this.
Kathleen Moriarty Former IESG member
No Objection
No Objection (2018-01-23 for -08) Unknown
Mirja Kühlewind Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Suresh Krishnan Former IESG member
No Objection
No Objection (for -08) Unknown

                            
Terry Manderson Former IESG member
No Objection
No Objection (for -08) Unknown