Subject: [bess] Adam Roach's No Objection on draft-ietf-bess-evpn-etree-13: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Wed, 13 Sep 2017 18:19:10 -0700

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.