Adam Roach has entered the following ballot position for draft-ietf-bess-evpn-etree-13: 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-bess-evpn-etree/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 3.3.2 says: The PEs implementing an E-Tree service need not perform MAC learning when the traffic flows between Root and Leaf sites are mainly multicast or broadcast. Does this mean to say "mainly"? I would have expected "only", as in section 4.3. In particular, if "mainly" is correct, I'm unsure how unicast traffic is supposed to be handled. Is it simply flooded out (modulo filters) in the same way as broadcast traffic? If that's the intention, I think some additional text here saying as much would be useful. ---- Section 5.1: The reserved bits SHOULD be set to zero by the transmitter and SHOULD be ignored by the receiver. The "SHOULD" here seems that it might make assigning meaning to these bits in the future problematic. If implementations decide to either assign local meaning to these bits, or decide that they don't need to be initialized, then future IETF specs that try to use them might be in for some pretty nasty deployment surprises. If these need to be "SHOULD" instead of "MUST," please add some motivating text to the document for the sake of people who might want to extend the protocol in the future. ---- The IANA handling of "Composite Tunnel" seems problematic: although several values in this "Reserved for Composite Tunnel" range have well-defined values (e.g., 0x81 means "RSVP-TE P2MP LSP with composite tunnel"), they look unallocated/reserved in the resulting table. I think what you really want to do here is update the introductory text for the table to make it clear that values now take the range 0x00 - 0x7F and modify 0x7B through 0x7F as you've proposed doing. On top of this, I have the same concerns as Warren does regarding the impact of this change on in-the-field use of experimental tunnel types. I think the only reasonable way to retrofit this mechanism onto the existing system would be to to say that the "Composite Tunnel" bit MUST be ignored for tunnel types 0x7B-0x7E, and possibly allocate some additional experimental codepoints (e.g., 0x77-0x7A) so that people can run experiments with tunnel types that also include composite tunnel behavior. _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
