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

[Kathleen Moriarty]

Kathleen Moriarty 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:
--

I'm reading the leaf to leaf prohibition as a routing optimization that isn't
intended for security purposes, but could help prevent routing loops and
leakage.  There is a little text early on in the document to describe the
purpose, but I agree the text should be made a bit more clear.


___
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

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

[Benoit Claise]

Benoit Claise 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:
--

MEF doesn't stand for Metro Ethernet Forum any longer.


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

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

[Ben Campbell]

Ben Campbell 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:
--

I share the questions about the prohibition of leaf-to-leaf communication.
There's a fair amount of text enforcing such a requirement, but very little if
any about why.


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

[bess] FW: Last Call: (YANG Data Model for L3VPN Service Delivery) to Proposed Standard

[Alvaro Retana (aretana)]

FYI…

Please take a look.  If anyone has comments, please reply to the thread in the 
i...@ietf.org list.

Thanks!

Alvaro.

On 9/13/17, 10:04 AM, "IETF-Announce on behalf of The IESG" 
 wrote:


The IESG has received a request from an individual submitter to consider the
following document: - 'YANG Data Model for L3VPN Service Delivery'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
i...@ietf.org mailing lists by 2017-10-11. Exceptionally, comments may be
sent to i...@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


   This document defines a YANG data model that can be used for
   communication between customers and network operators and to deliver
   a Layer 3 provider-provisioned VPN service.  This document is limited
   to BGP PE-based VPNs as described in RFCs 4026, 4110, and 4364.  This
   model is intended to be instantiated at the management system to
   deliver the overall service.  It is not a configuration model to be
   used directly on network elements.  This model provides an abstracted
   view of the Layer 3 IP VPN service configuration components.  It will
   be up to the management system to take this model as input and use
   specific configuration models to configure the different network
   elements to deliver the service.  How the configuration of network
   elements is done is out of scope for this document.

   If approved, this document obsoletes RFC 8049.  The changes are a
   series of small fixes to the YANG module, and some clarifications to
   the text.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-wu-l3sm-rfc8049bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-wu-l3sm-rfc8049bis/ballot/

No IPR declarations have been submitted directly on this I-D.

Working Group Summary
  RFC 8049 was the product of the L3SM working group, but that WG has been 
closed.
  No other WG covers this topic.
  However, the L3SM list remains open: changes and revisions were publicised 
and discussed there

The document contains these normative downward references.
See RFC 3967 for additional information: 
rfc3022: Traditional IP Network Address Translator (Traditional NAT) 
(Informational - IETF stream)





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