John Scudder has entered the following ballot position for draft-ietf-nvo3-bfd-geneve-12: 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-nvo3-bfd-geneve/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for this valuable and easy-to-read spec. I have one concern that I'd like to have a discussion about; I hope this will be easy to resolve. There are several places where you use MUST in a way I think is unnecessary, you seem to be saying, in effect, "to do Geneve you MUST do Geneve". Most of these are harmless IMO (I put some examples in the COMMENT section just in case you're unclear what I'm talking about) but there are two that seem problematic to me, nearly-identical sentences from Sections 4.1 and 5.1: Then the Destination IP, the UDP destination port and the TTL or Hop Limit of the inner IP packet MUST be validated to determine whether the received packet can be processed by BFD. and Then the UDP destination port and the TTL or Hop Limit of the inner IP packet MUST be validated to determine whether the received packet can be processed by BFD. In both cases, it's unclear to me if you're just saying "Geneve has certain validation rules that have to be met before the packet can be passed to the upper layer", or if you're introducing a new requirement. In the former case, please be more transparent about that, possibly with a citation to the validation rules in the underlying spec. You could also consider dropping the RFC 2119 MUST. In the latter case, if you're truly introducing a new requirement, I think the validation rules need to be spelled out much more clearly. (I think it's probably the former case.) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- - Please consider expanding "FCS" where used, or glossing it elsewhere. - This sentence in Sections 4.1 and 5.1, The Destination MAC of the inner Ethernet frame matches the MAC address of a VAP which is mapped to the same as received VNI. has a grammatical problem that prevents me from making sense of it. I *think* you are missing a noun after "the same", so it should be something like "The Destination MAC _address_ of the inner Ethernet frame matches the MAC address of a VAP which is mapped to the same _???_ as _the_ received VNI." Or maybe some other rewrite is needed, but anyway, it's not clear as it stands. - Here are a few examples where I think you have MUSTs that may be unnecessary, as referenced in my DISCUSS. I don't insist on any changes related to these, I'm just providing them for your information. The Outer IP/UDP and Geneve headers MUST be encoded by the sender as defined in [RFC8926]. ("MUST be" could be "are"; occurs 2x in the doc) Opt Len field MUST be set consistent with the Geneve specification (This could be "The usage of the Opt Len field is specified in [RFC8926], and depends on whether or not", etc; occurs 2x in the doc) Once a packet is received, the NVE MUST validate the packet as described in [RFC8926]. (Could be "... the NVE validates..."; occurs 2x in the doc) _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
