Re: [bess] shepherd review of draft-ietf-bess-evpn-etree

2016-09-01 Thread Ali Sajassi (sajassi) 
Hi Thomas,

Thanks very much for your thorough review and valuable comments. I have 
resolved all of them and incorporated all the required modifications. Please 
refer to the comment resolutions below and let me know if there are any further 
comments. You can find the latest rev of the draft with the incorporated 
changes in:

https://www.ietf.org/id/draft-ietf-bess-evpn-etree-07.txt

Thanks,
Ali

From: Thomas Morin >
Organization: Orange
Date: Monday, August 29, 2016 at 7:49 AM
To: 
"draft-ietf-bess-evpn-et...@ietf.org"
 
>,
 Loa Andersson >, "George Swallow -X (swallow - 
CLEARPATH WORKFORCE MANAGEMENT INC at Cisco)" 
>, Eric Rosen 
>, BESS 
>
Cc: Martin Vigoureux 
>
Subject: shepherd review of draft-ietf-bess-evpn-etree
Resent-From: >
Resent-To: Cisco Employee >, 
>, 
>, 
>, 
>, 
>
Resent-Date: Monday, August 29, 2016 at 7:49 AM


Hi,

Here is the review I did while preparing the shepherd write-up for 
draft-ietf-bess-evpn-etree .

There is one thing that stands out: the document uses the most significant bit 
of the "PMSI Tunnel Attribute" Tunnel Type  field, which cant't be done I think 
without updating the structure of the corresponding registry (RFC7385).  I 
suggest how that can be done at the end of this review (a few people Cc'd for 
this reason).

Please find my comments below...

[...]

2  E-Tree Scenarios and EVPN / PBB-EVPN Support

   In this section, we will categorize support for E-Tree into three
   different scenarios, depending on the nature of the site association
   (Root/Leaf) per PE or per Ethernet Segment:

   - Leaf OR Root site(s) per PE

   - Leaf OR Root site(s) per AC

   - Leaf OR Root site(s) per MAC

2.1 Scenario 1: Leaf OR Root site(s) per PE

   In this scenario, a PE may receive traffic from either Root sites OR
   Leaf sites for a given MAC-VRF/bridge table, but not both
   concurrently. In other words, a given EVI on a PE is either
   associated with a root or leaf.

s/with a root or leaf/with roots or leaves/ ?

Done. Changed it to “root(s) or leaf(s)"

The PE may have both Root and Leaf

s/both Root and Leaf/both Roots and Leaves/ ?

In this sentence “Root” and “Leaf” are used as adjectives for sites, so AFAIK, 
they should remain singular.

   sites albeit for different EVIs.

   +-++-+
   |   PE1   ||   PE2   |
+---+  |  +---+  |  +--+  |  +---+  |+---+
|CE1+---ES1+--+   |  |  | MPLS |  |  |   +--+ES2-+CE2|
+---+  (Root)  |  |MAC|  |  |  /IP |  |  |MAC|  |   (Leaf)   +---+
   |  |VRF|  |  |  |  |  |VRF|  |
   |  |   |  |  |  |  |  |   |  |+---+
   |  |   |  |  |  |  |  |   +--+ES3-+CE3|
   |  +---+  |  +--+  |  +---+  |   (Leaf)   +---+
   +-++-+

   Figure 1: Scenario 1


   In such scenario, an EVPN PE implementation MAY provide E-TREE
   service using topology constraint among the PEs belonging to the same

"topology constraint" is a bit opaque as a term, perhaps "using tailored BGP RT 
import/export policies" would be more descriptive (assuming I understood your 
intent)

Done. Changed it to “topology constraint tailored by BGP Route Target (RT) 
import/export policies"

   EVI. The purpose of this topology constraint is to avoid having PEs
   with only  Leaf sites importing and processing BGP MAC routes from
   each other. To support such topology constrain in EVPN, two BGP
   Route-Targets (RTs) are used for every EVPN Instance (EVI): one RT is
   associated with the Root sites and the other is associated with the
   Leaf sites. On a per EVI basis, every PE exports the single RT
   associated with its type of site(s). Furthermore, a PE with Root
   site(s) imports both Root and Leaf RTs, whereas a PE with Leaf
   site(s) only imports the Root RT.

The text seems to imply that the above is sufficient to deliver the service, 
but I fail to see what would prevent Leaf-to-Leaf traffic between Leaves bound 
to the same MAC-VRF (ES2 and ES3 in firgure1).  Shouldn't the text mention the 
use of a split-horizon in Leaf MAC-VRFs ?

Agree, nice catch!. I changed the first sentence from:
"In

[bess] I-D Action: draft-ietf-bess-evpn-etree-07.txt

2016-09-01 Thread 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 of the IETF.

Title   : E-TREE Support in EVPN & PBB-EVPN
Authors : Ali Sajassi
  Samer Salam
  John Drake
  Jim Uttaro
  Sami Boutros
  Jorge Rabadan
Filename: draft-ietf-bess-evpn-etree-07.txt
Pages   : 18
Date: 2016-09-01

Abstract:
   The Metro Ethernet Forum (MEF) has defined a rooted-multipoint
   Ethernet service known as Ethernet Tree (E-Tree). A solution
   framework for supporting this service in MPLS networks is proposed in
   and RFC called "A Framework for E-Tree Service over MPLS Network".
   This document discusses how those functional requirements can be
   easily met with (PBB-)EVPN and how (PBB-)EVPN offers a more efficient
   implementation of these functions. This document makes use of the
   most significant bit of the scope governed by the IANA registry
   created by RFC7385, and hence updates that RFC accordingly.



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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-bess-evpn-etree-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-bess-evpn-etree-07


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] [mpls] [Idr] Fwd: Working Group adoption poll on draft-rosen-mpls-rfc3107bis

2016-09-01 Thread Robert Raszuk 
​Acee,​


> The current capability is specific to support of multiple labels - not
> your parochial view on the interaction between SAFIs.
>

​Since "bis" specification obsoletes the base document I was under the
assumption that new capability will also obsolete the current used.

It is no longer "3107bis" but just a new draft or at best errata -  to the
best of my understanding of IETF rules "bis" obsoletes the original spec.
Requiring implmentors to read and follow both specifications to correctly
implement the labeled BGP AF seems a bit odd ... don't you think ?

 Are you suggesting a second capability? All the more reason for a separate
> draft.
>

​No.​ See above.

In any event, the non-backward compatible behavior you are proposing would
> be better served in a separate draft than to burden RFC 3107 BIS.
>

​Section 5 already discusses that point - so my comment should be
considered as feedback towards that section . If there is WG consensus to
proceed with that it would be pure waist of time to write a separate draft
to argue against it.

It seems interesting that IETF WG feedback expressed on the list for
specific section of the draft in adoption call or during WG progress is
turned around and request is made to write a new draft instead.

Especially that document wise the feedback consideration may require
addition of two sentences within section 5 :).

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