Re: [bess] Genart telechat review of draft-ietf-bess-evpn-etree-13

[Ali Sajassi (sajassi)]

Hi Dale,

Please refer to my replies inline marked with ³Ali>².

On 9/11/17, 4:51 AM, "Dale Worley"  wrote:

>Reviewer: Dale Worley
>Review result: Ready with Nits
>
>I am the assigned Gen-ART reviewer for this draft.  The General Area
>Review Team (Gen-ART) reviews all IETF documents being processed by
>the IESG for the IETF Chair.  Please wait for direction from your
>document shepherd or AD before posting a new version of the draft.
>
>For more information, please see the FAQ at
>.
>
>Document:  draft-ietf-bess-evpn-etree-13
>Reviewer:  Dale R. Worley
>Review Date:  2017-09-12
>IETF LC End Date:  2017-08-09
>IESG Telechat date:  2017-09-12
>
>Summary:
>
>This draft is basically ready for publication, but has nits that
>should be fixed before publication.
>
>There are a few matters that I would like to see amplified in the
>Introduction to improve the exposition for readers who aren't familiar
>with this area.
>
>1.  Relationship to RFC 7432.  The Introduction now states "Since this
>document specifies a solution based on [RFC7432], it requires the
>readers to have the knowledge of [RFC7432] as prerequisite."  This is
>a significant improvement, but I still find this unsatisfyingly vague
>regarding the relationship between the two documents.  Is RFC 7432
>only background knowledge, or is this document an
>extension/modification of RFC 7432, in which case, some parts of the
>technique described in this document are actually defined in RFC 7432?
>It seems a minor change of wording of this sentence could make this
>clear.

Ali> Modified the 1st sentence of the last paragraph in section 1 for
better clarity.
>
>2.  Management:  The document doesn't describe how the EVPN structure
>will be set up (e.g., how endpoints are added or deleted from the
>structure, what MPLS labels will be used), nor how choice of the many
>technology alternatives will be communicated (e.g., 2.1 vs. 2.2
>vs. 2.3; approach A vs. approach B).  I suspect that this is normal
>for documents defining VPN techniques, but it seems peculiar for me,
>as the areas I'm familiar with (SIP and data-center networking) try to
>minimize the amount of "configuration" that needs to be done.  It
>might help the reader to list in the Introduction what aspects of
>set-up are out of scope for the document, and conversely, what aspects
>you've arranged for the control plane to handle automatically (which
>are benefits of the technique).

Ali> Since this solution is an extension of EVPN (RFC7432 or RFC7623), the
PE configuration follow that of those RFCs. The configuration for the
scenarios 2.1 to 2.3 are implied in those paragraphs - i.e., 2.1 talks
about using (configuring) two Route Targets (which is well understood in
VPN community), section 2.2 recommends using a single RT and a given AC to
be colored (configured) by ³leaf² or ³root², and section 2.3 talks about
coloring specific MAC addresses.
>
>3.  Efficiency:  The Abstract and the final paragraph of the
>Introduction mention that this technique is more efficient than that
>of RFC 7796, and of course that is a major motivation for this work.
>But the nature of the improved efficiency is only detailed in section
>3.1.  It would help the reader, I think, to mention the nature of the
>improved efficiency in the Introduction, and perhaps to mention the
>specific traffic patterns where this improved efficiency is
>particularly effective.  This helps the reader know when reading the
>document will be particularly valuable.

Ali> Added the following sentence to the introduction section:
Ali> ³This efficiency is achieved by performing filtering of unicast
traffic on ingress PE nodes as opposed to egress filtering where the
traffic is sent through the network and gets filtered and discarded at the
egress PE nodes. The details of this ingress filtering is described in
section 3.1.²

>
>There are a few nits I noticed:
>
>Abstract
>
>   solution based on RFC7432, BGP MPLS Based Ethernet VPN (EVPN), with
>   some extensions and how such a solution can offer a more efficient
>   implementation of these functions than that of RFC7796, E-Tree
>   Support in Virtual Private LAN Service (VPLS). This document makes
>
>In the same way as you quote the title of RFC 76387, it would be more
>readable if you quoted the titles of the other two RFCs.

Ali> The text that comes right after the RFC number is the title of that
draft. 
>
>1  Introduction
>
>   Attachment Circuits (AC) (e.g., an Ethernet tag but may also be
>   represented by a MAC address) is labeled as either a Root or a Leaf
>
>I assume "tag" means 802.1q VLAN tag, but it would be helpful to spell
>that out.

Ali> Done.
>
>1.2  Terminology
>
>   Ethernet Segment Identifier (ESI): A unique non-zero identifier that
>   identifies an Ethernet segment is called an 'Ethernet Segment
>   Identifier'.
>
>What universe is the ESI is unique over?

Ali> Its structure and its uniqueness is described extensively in R

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

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

[Ali Sajassi (sajassi)]

Hi Kathleen,

Leaf to leaf communication prohibition is one of the main function of
E-TREE service per MEF definition and RFC 7387. The document describes how
to implement this E-TREE service for EVPN and how it can be done more
efficiently. 

Regards,
Ali


On 9/13/17, 7:28 PM, "Kathleen Moriarty"
 wrote:

>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

Re: [bess] Eric Rescorla's Discuss on draft-ietf-bess-evpn-etree-13: (with DISCUSS)

[Ali Sajassi (sajassi)]

Hi Eric,

The "leaf" or "root" designation of an Attachment Circuit (AC) is done by the 
operator / service provider on the PE device (and not on a CE). So, CE device 
has no control in changing a "leaf" designation to a "root". I added "the 
network operator / service provider" to the text. Furthermore, I added 
additional text to address your second concern (e.g., regarding how to avoid 
any exchange among leaf ACs):

"Furthermore, this document provides additional security check by allowing 
sites (or ACs) of an EVPN instance to be designated as "Root" or "Leaf" by the 
network operator/ service provider and thus preventing any traffic exchange 
among "Leaf" sites of that VPN through ingress filtering for known unicast 
traffic and egress filtering for BUM traffic. Since by default and for the 
purpose of backward compatibility, an AC that doesn't have a leaf designation 
is considered as a root AC, in order to avoid any  traffic exchange among leaf 
ACs, the operator SHOULD configure the AC with a proper role (leaf or root) 
before activating the AC."

Cheers,
Ali

From: "Alvaro Retana (aretana)" mailto:aret...@cisco.com>>
Date: Tuesday, September 26, 2017 at 6:03 AM
To: Eric Rescorla mailto:e...@rtfm.com>>, The IESG 
mailto:i...@ietf.org>>
Cc: "thomas.mo...@orange.com" 
mailto:thomas.mo...@orange.com>>, 
"bess-cha...@ietf.org" 
mailto:bess-cha...@ietf.org>>, 
"draft-ietf-bess-evpn-et...@ietf.org"
 
mailto:draft-ietf-bess-evpn-et...@ietf.org>>,
 "bess@ietf.org" mailto:bess@ietf.org>>
Subject: Re: Eric Rescorla's Discuss on draft-ietf-bess-evpn-etree-13: (with 
DISCUSS)
Resent-From: mailto:alias-boun...@ietf.org>>
Resent-To: Cisco Employee mailto:saja...@cisco.com>>, 
mailto:ssa...@cisco.com>>, 
mailto:jdr...@juniper.net>>, 
mailto:ju1...@att.com>>, 
mailto:sbout...@vmware.com>>, 
mailto:jorge.raba...@nokia.com>>
Resent-Date: Tuesday, September 26, 2017 at 6:03 AM

Hi!

I don't have anything in my archive either. :-(

I just poked the authors...

Alvaro.

On 9/26/17, 5:59 AM, "Eric Rescorla" mailto:e...@rtfm.com>> 
wrote:

I have some memory that someone responded that this wasn't a security 
requirement, but I can't find that now.

-Ekr


On Sat, Sep 9, 2017 at 11:35 AM, Eric Rescorla 
mailto:e...@rtfm.com>> wrote:
Eric Rescorla has entered the following ballot position for
draft-ietf-bess-evpn-etree-13: 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/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/



--
DISCUSS:
--

It's not clear to me if the prohibition on leaf-to-leaf communications is
intended to be a security requirement. If so, it seems like it needs to
explicitly state why it is not possible for ACs which are leaf to pretend to be
root. If not, then it should say so. Additionally, this solution appears to
rely very heavily on filtering, so I believe some text about what happens
during periods of filtering inconsistency (and what the impact on the security
is).




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

[bess] I-D Action: draft-ietf-bess-datacenter-gateway-00.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the BGP Enabled ServiceS WG of the IETF.

Title   : Gateway Auto-Discovery and Route Advertisement for 
Segment Routing Enabled Domain Interconnection
Authors : John Drake
  Adrian Farrel
  Eric Rosen
  Keyur Patel
  Luay Jalil
Filename: draft-ietf-bess-datacenter-gateway-00.txt
Pages   : 11
Date: 2017-10-27

Abstract:
   Data centers have become critical components of the infrastructure
   used by network operators to provide services to their customers.
   Data centers are attached to the Internet or a backbone network by
   gateway routers.  One data center typically has more than one gateway
   for commercial, load balancing, and resiliency reasons.

   Segment routing is a popular protocol mechanism for operating within
   a data center, but also for steering traffic that flows between two
   data center sites.  In order that one data center site may load
   balance the traffic it sends to another data center site it needs to
   know the complete set of gateway routers at the remote data center,
   the points of connection from those gateways to the backbone network,
   and the connectivity across the backbone network.

   Segment routing may also be operated in other domains, such as access
   networks.  Those domains also need to be connected across backbone
   networks through gateways.

   This document defines a mechanism using the BGP Tunnel Encapsulation
   attribute to allow each gateway router to advertise the routes to the
   prefixes in the segment routing domains to which it provides access,
   and also to advertise on behalf of each other gateway to the same
   segment routing domain.



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-bess-datacenter-gateway/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-bess-datacenter-gateway-00
https://datatracker.ietf.org/doc/html/draft-ietf-bess-datacenter-gateway-00


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [bess] Call for adoption: draft-drake-bess-datacenter-gateway

[Keyur Patel]

I am unaware of any undisclosed IPR that applies to this draft.

Regards,
Keyur

On 10/27/17, 6:47 AM, "Eric C Rosen"  wrote:

I am unaware of any undisclosed IPR that applies to this draft.


On 9/25/2017 5:42 AM, Martin Vigoureux wrote:
> Hello working group,
>
> This email starts a two-week call for adoption on 
> draft-drake-bess-datacenter-gateway-05 [1] as a BESS Working Group 
> Document.
>
> Please state on the list if you support the adoption or not (in both 
> cases, please also state the reasons).
>
> This poll runs until *the 2nd of October*.
>
> We are also polling for knowledge of any undisclosed IPR that applies
> to this Document, to ensure that IPR has been disclosed in compliance
> with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more
> details).
> If you are listed as an Author or a Contributor of this Document please
> respond to this email and indicate whether or not you are aware of any
> relevant undisclosed IPR. The Document won't progress without answers
> from all the Authors and Contributors.
>
> Currently no IPR has been disclosed against this Document.
>
> If you are not listed as an Author or a Contributor, then please 
> explicitly respond only if you are aware of any IPR that has not yet 
> been disclosed in conformance with IETF rules.
>
> Thank you
>
> Martin & Thomas
> bess chairs
>
> [1] 
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Ddrake-2Dbess-2Ddatacenter-2Dgateway_&d=DwIC-g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=PH0tABqMXcA-TgEvraUZC2HrDAmgmPxVx36tE1gUWSw&s=GSHLcpm8n5C1KatiovmQUcLTxxzJS2YOrLtZMCuFrLY&e=
 




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

Re: [bess] Call for adoption: draft-drake-bess-datacenter-gateway

[Martin Vigoureux]

WG,

we have a new WG Document.

Authors could you republish as draft-ietf-bess-datacenter-gateway-00

thank you

Le 25/09/2017 à 11:42, Martin Vigoureux a écrit :

Hello working group,

This email starts a two-week call for adoption on
draft-drake-bess-datacenter-gateway-05 [1] as a BESS Working Group
Document.

Please state on the list if you support the adoption or not (in both
cases, please also state the reasons).

This poll runs until *the 2nd of October*.

We are also polling for knowledge of any undisclosed IPR that applies
to this Document, to ensure that IPR has been disclosed in compliance
with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more
details).
If you are listed as an Author or a Contributor of this Document please
respond to this email and indicate whether or not you are aware of any
relevant undisclosed IPR. The Document won't progress without answers
from all the Authors and Contributors.

Currently no IPR has been disclosed against this Document.

If you are not listed as an Author or a Contributor, then please
explicitly respond only if you are aware of any IPR that has not yet
been disclosed in conformance with IETF rules.

Thank you

Martin & Thomas
bess chairs

[1] https://datatracker.ietf.org/doc/draft-drake-bess-datacenter-gateway/

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



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

Re: [bess] Call for adoption: draft-drake-bess-datacenter-gateway

[Eric C Rosen]

I am unaware of any undisclosed IPR that applies to this draft.


On 9/25/2017 5:42 AM, Martin Vigoureux wrote:

Hello working group,

This email starts a two-week call for adoption on 
draft-drake-bess-datacenter-gateway-05 [1] as a BESS Working Group 
Document.


Please state on the list if you support the adoption or not (in both 
cases, please also state the reasons).


This poll runs until *the 2nd of October*.

We are also polling for knowledge of any undisclosed IPR that applies
to this Document, to ensure that IPR has been disclosed in compliance
with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more
details).
If you are listed as an Author or a Contributor of this Document please
respond to this email and indicate whether or not you are aware of any
relevant undisclosed IPR. The Document won't progress without answers
from all the Authors and Contributors.

Currently no IPR has been disclosed against this Document.

If you are not listed as an Author or a Contributor, then please 
explicitly respond only if you are aware of any IPR that has not yet 
been disclosed in conformance with IETF rules.


Thank you

Martin & Thomas
bess chairs

[1] 
https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Ddrake-2Dbess-2Ddatacenter-2Dgateway_&d=DwIC-g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=PH0tABqMXcA-TgEvraUZC2HrDAmgmPxVx36tE1gUWSw&s=GSHLcpm8n5C1KatiovmQUcLTxxzJS2YOrLtZMCuFrLY&e= 



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