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

[Adam Roach]

On 10/27/17 6:06 PM, Ali Sajassi (sajassi) wrote:

Ali> updated the section to make it more clear - please refer to rev14 of
this draft.



Thanks -- I'll take a look. When do you expect to upload the -14 version 
to the i-d repository?


/a

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Ali Sajassi (sajassi)]

Hi Adam,

Please refer to my replies inline.

On 9/13/17, 6:19 PM, "Adam Roach"  wrote:

>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.

Ali> Added the following sentence:
Ali> "In such scenarios, the small amount of unicast traffic (if any) is
sent as part of BUM traffic."
>
>
>
>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.

Ali> changed the second ³SHOULD² to ³MUST²:
Ali > "The reserved bits SHOULD be set to zero by the transmitter and MUST
be ignored by the receiver."
>
>
>
>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.

Ali> updated the section to make it more clear - please refer to rev14 of
this draft. The only changes for this document is for the range of
0x7B-0xFA which was previously unassigned. The decomposition of this range
is explained in the IANA section.
>
>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.

Ali> There shouldn¹t be any impact. The current tunnel types are in the
range of 0x00-0x07 [RFC7385]. The max range for the future will be in the
range of 0x00-0x7A. The mirror image of this range with the composite
tunnel type would be in the range of 0x80-FA. There is complete backward
compatibility with existing experimental values.
>
>

___
BESS mailing list
BESS@ietf.org
https://www.ietf.org/mailman/listinfo/bess

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

[Adam Roach]

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