Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

[Sami Boutros <[e-mail]>]

Hi Iftekhar,

Please see inline
> 
>  
> Hi Authors,
>  
> I support this work. However, I do have few comments that I would like to add to the list from the AD:
> ·         Section 1:  The terms ES and ACs are used interchangeably (e.g., see “….Ethernet Virtual Private Line (EVPL) service as p2p service between a pair of ACs” and “…Ethernet Private Line (EPL) service … a single pair of ESes” .  This is confusing. What is the reason for not considering a port as an AC?
> Suggestion: Please include a complete service entity reference mode in this draft. Clearly indicate what entities are involved to provision a VPWS (for example, ES-AC - LSP etc.). This will also be extremely useful for data modeling of the service.
> Sami: I am not sure I get this, we spend a lot of time on this on the list to conclude to the text in Place for ES and AC. I am not sure changing any of that will clarify or confuse.
>  
> Iftekhar:  I am not saying you didn’t spend enough time. What I am saying is at least to me the equivalence of AC and ES is not clear. Are you saying AC == ES?  As I understand, these two constructs are not equivalent. AC is a data plane construct while ES appears to be purely a control plane construct. Okay for the sake of argument, say ES and AC are equivalent. Then why do you need AC? Moreover, what will be the data plane entity representation of VPWS-EVPN  for EVPL and EPL look like? Would it be AC- (xconnect) label – LSP or ES- (xconnect) – LSP?

If you have a look at the terminology section it clarifies what exactly we mean by ES in the doc it refers to the link/port attached to the PE and we refer to AC as the VLAN like port. Like Pwe3 the evpn p2p lsp can be looked at as a Pw construct. By the way AC is both a data and control plane construct. We are not redefining what EVPL or EPL means but on a given PE we are cross connecting a port or a VLAN like service to an evpn signaled p2p bidir lsp using evpn-vpws.

>  
> ·         Section 1: “…whereas, for more general VPWS,…”  What is a more general VPWS?
>  
> Sami: Please refer to https://tools.ietf.org/html/rfc4664 for the general VPWS definition. I will add a reference to it in the doc.
>  
> Iftekhar: Okay.
>  
> ·         Section 1: It is hard to keep track of what enhancements are being proposed and what functionalities defined in RFC7432 applies or don’t apply to VPWS.
>  
> Sami: The only change is making the Ethernet tag ID setting to a non zero value a MUST, this is explicitly mentioned in section 1
>  
> "Unlike EVPN where Ethernet Tag ID in EVPN routes are set to zero for Port-based, vlan-based, and vlan-bundle interface mode and it is set to non-zero Ethernet tag ID for vlan-aware bundle mode, in EVPN-VPWS, for all the four interface modes, Ethernet tag ID in the Ethernet A-D route MUST be set to a non-zero value in all the service interface types."
>  
> Iftekhar: Let me give couple of examples. Does (a) MAC/IP route (type2) or Inclusive Multicast Ethernet Tag route (type 3) (b) MAC Mobility Extended Community or  Default Gateway Extended Community  defined in RFC7432 apply to EVPN-VPWS?  If not, it would be useful that this document clarifies it.


The document clearly mention that there is no Mac related routes, or bridge like service related routes not sure what more clarifications we need. Enumerating route types and extended communities not supported doesn't make sense given that EVPN is still adding more route types and more extended communities in several drafts not only the base.

>  
> Suggestion: Add a summary table which captures what Route Types apply (or don’t apply) to VPWS
>  
> Sami: The only route that applies is the ethernet A-D route and we need segment route for multihoming. None of the other routes apply!
>  
> ·         Section 5: What is equivalent of PW in EVPN-VPW case? In the service model, is there any entity that need to be modeled? I see that in the https://tools.ietf.org/html/draft-sajassi-bess-evpn-vpws-fxc-01 you are introducing a new entity on the PSN side called “VPWS Service Tunnel … a pair of EVPN service labels associated with a pair of endpoints”. What is difference between labels associated with a pair of VPWS endpoints in this draft vs vpws-fxc draft?
> Sami: I don;t think we can explain the fxc draft in this draft, however in the fxc the label is not sufficient to identify the service.
>  
> Iftekhar: Let me ask a very simple question. Suppose I am interested in statistic counters on packet received or transmitted toward PSN/from PSN for a VPWS-EVPN. In the VPWS (RFC4664) there is PW entity.  Could you kindly identify an entity against which such counters can be shown and retrieved? All  VPWS-EVPN draft has is a “label”.
>  

The PW entity is as well identified by 2 labels for imposition and disposition, the same way an evpn p2p lsp for vpws is identified.

> I understand fxc is a different draft. My point is folks are thinking of extending the architecture of VPWS-EVPN and they probably realized the need for an entity. I believe these is a need for such an entity – we have an opportunity to fix the VPWS-EVPN model right now before it becomes a standard. Why not fix it now?


The management entity you are looking for is the evpn p2p lsp, fxc can map more than one AC to this. I will add a definition in the doc to this evpn p2p lsp and mention that only one AC can be xconnected to it. Will that be ok?

Thanks,

Sami
>  
> Thanks,
> Iftekhar
>  
> Thanks,
>  
> Sami
> Suggestion: Clearly identify entity that needs to be modeled on the PSN side. If it is service tunnel, please indicate so. If this aspect is not addressed properly, IMHO, this will cause lot of confusion.
>  
> Thanks,
> Iftekhar
> From: Alvaro Retana (aretana) [mailto:[e-mail]] 
> Sent: Wednesday, January 25, 2017 8:39 PM
> To: [e-mail]
> Cc: Jeffrey Zhang; [e-mail]; [e-mail]
> Subject: [bess] AD Review of draft-ietf-bess-evpn-vpws-07
>  
> Dear authors:
>  
> Hi! 
>  
> I just finished reading this document.  Please take a look at my comments below – I think they should be easy to resolve.  I will start the IETF Last Call when the comments have been addressed and a new revision has been published.
>  
> Thanks!
>  
> Alvaro.
>  
>  
> Major:
>  
> M1. There are 8 authors listed on the front page.  Following the guidelines in the RFC Style Guide [RFC7322], we want the list to be at most 5.  Please work among yourselves to reduce the number of authors.  Alternatively, you can just list an Editor or two.
>  
>  
> M2. From the Introduction: “Unlike EVPN where Ethernet Tag ID in EVPN routes are set to zero…in EVPN-VPWS, Ethernet tag ID in the Ethernet A-D route MUST be set to a valid value in all the service interface types.”  Zero is a valid value for the Ethernet Tag ID.  Section 3. (BGP Extensions) says that “the Ethernet Tag ID 32-bit field is set to the 24-bit VPWS service instance identifier”, but I couldn’t find a place where the document told me what a valid value is.  IOW, how can the “MUST” be enforced if there’s no clear indication of what is valid?  OTOH, any specification wants the fields to contain valid values, obviously!  What happens if the value is not valid?    BTW, all this is to say that without a proper explanation (which probably doesn’t belong in the Introduction), the whole paragraph is superfluous.
>  
>  
> M3. The Introduction says that “For EVPL service, the Ethernet frames transported over an MPLS/IP network SHOULD remain tagged with the originating VID and any VID translation is performed at the disposition PE.”, later the same (or at least something similar) is mentioned in Section 2.1. (VLAN-Based Service Interface): “the Ethernet frames transported over an MPLS/IP network SHOULD remain tagged with the originating VID, and a VID translation MUST be supported in the data path and MUST be performed on the disposition PE.”  Please keep the normative language in one place – I am not fond of normative language in the Introduction; note that even though the result should be the same, the text is different (the “MUSTs” are used in 2.1).
>  
> M3.1. [minor] It is not clear in the text that EVPL service corresponds to VLAN-based service.  Please clarify that.  In fact, some of the flow of the document feel disjoint because slightly different terminology is used and no hint of how it all ties together is presented; mapping EPL/EVPL to the Service Interfaces, which are only mentioned in Section 2 (and very briefly in the Introduction – see M2).
>  
>  
> M4. Section 1.2 is titled Requirements.  However, the list seems to include a combination of statements of fact (“EPL service access circuit maps to the whole Ethernet port”: this is pretty much the definition of EPL), solution-sounding lines (“Each VLAN individually (or <S-VLAN,C-VLAN> combination) will be considered to be an endpoint for an EVPL service”: not only does it sound like what the solution will do, but it is also the definition of EVPL), and statements that talk to the configuration and not what the technical solution described later can do (“A given PE could have thousands of EVPLs configured. It must be possible to configure multiple EVPL services within the same EVI.”: is there an actual scalability requirement?).     I would have expected actual requirements (for example: “EPL service access circuits MUST map to the whole Ethernet port”; normative language is not required) that I can then check against the solution – but it all sounds like a rehash of what was explained before.  L
>  
>  
> M5. Section 3. (BGP Extensions) says that “This document proposes the use of the per EVI Ethernet A-D route to signal VPWS services. The Ethernet Segment Identifier field is set to the customer ES and the Ethernet Tag ID 32-bit field is set to the 24-bit VPWS service instance identifier.”  First of all [this is minor/a nit], if this document intends to be in the Standards Track then it is past the “proposing” phase, it is *specifying*.  As a specification, it is rather weak in some places; for example, RFC7432 says (as an example) that the “Ethernet Tag ID in all EVPN routes MUST be set to 0”: that is a strong statement of what is expected.  On the other hand, this document is modifying the behavior, but no Normative language is used.  [In general I don’t advocate for the use of Normative language everywhere, but in cases like this where the behavior is being changed from the base spec when using this extension, it seems necessary.]
>  
> M5.1. Section 3: “Ethernet Tag ID 32-bit field is set to the 24-bit VPWS service instance identifier” How should this be aligned into the larger field?
>  
>  
> M6. Section 3.1 (EVPN Layer 2 attributes extended community). 
>  
> M6.1. For the P flag – “SHOULD be set to 1 for multihoming all-active scenarios”: in a multihoming all-active scenario, when would this flag not be set?  IOW, why is the “SHOULD” not a “MUST”.  A couple of paragraphs later: “…the PEs in the ES that are active and ready to forward traffic to/from the CE will set the P bit to 1”.  In the all-active scenario, is there a case where a PE would not be “active and ready”?  What does that mean?  Clarifying may justify the “SHOULD”.
>  
> M6.2. How should the other flags in the Control Flags field be assigned?  Please define a new registry and include the details in the IANA Considerations section.
>  
> M6.3. What should a remote PE do if it receives both the P and B flags set (or both unset)?  I know that in a single-active scenario they should not be on at the same time…but what should the receiver do?
>  
> M6.4. What happens if the B flag is set in the all-active scenario?   I know there was some discussion about this on the list – the document needs to explicitly talk about it.
>  
> M6.5. What units is the MTU in?  How is it encoded?
>  
> M6.6. “non-zero MTU SHOULD be checked against local MTU”  When is it ok not to check?  I’m wondering why this “SHOULD” is not a “MUST”, specially because the result of that check is a “MUST NOT”.
>  
> M6.7. “As per [RFC6790]…the control word (C bit set) SHOULD NOT be used…”  Where in RFC6790 does it say that?  I searched for “control word”, but found nothing?  Also, this “SHOULD NOT” is in conflict with the definition of the C flag: “If set to 1, a Control word [RFC4448] MUST be present…” 
>  
>  
> Minor:
>  
> P1. Please add a reference for VPWS.
>  
> P2. The [MEF] reference didn’t work for me; on all tries the connection timed out.  Is it possible to find a more stable reference?
>  
> P3. There are several acronyms that won’t be familiar to the average reader and that need to be expanded on first use: ES, AD (A-D), EVI, VID, VNI, EP-LAN, EVP-LAN. I know that some of these are expanded in the Terminology Section, but in some cases that comes later in the text.
>  
> P4. The EVPN-VPWS term is introduced for the first time in the text at the bottom of page 3.  I take it that it refers to the solution presented in this document.  Please include a sentence at the top of the introduction to clarify – note that this tag could be useful in other places as well.
>  
> P5. “Ethernet tag field” (and not “Ethernet Tag ID”, which I’m assuming is the same thing) is used in several parts of the text.  Please be consistent.
>  
> P6. “VxLAN encap” is mentioned in the Introduction, and potential things about handling it…but there are no references and no additional mention anywhere else in the document.
>  
> P7. “mass withdraw” is mentioned in the Introduction (“…can be used for flow-based load-balancing and mass withdraw functions”),  in Section 4 (“…can be used for mass withdraw”), and finally Section 6.2 (the last section in the draft!) has a reference…  Please move it earlier in the document.
>  
> P8. S-VLAN, C-VLAN: expand and put a reference for them.
>  
> P9. There is no Reference to any of the Extended Communities RFCs: 4360, 7153, etc…
>  
> P10. Please add Figure numbers/names.
>  
> P11. Section 3.1 (EVPN Layer 2 attributes extended community) defines 3 control *flags*, but they are referred to later in the text as “bits”.  Please be consistent.
>  
> P12. Section 4 (Operation): s/with Next Hop attribute set/with the NEXT_HOP attribute set   Also, include an Informative reference to RFC4271.
>  
> P13. Section 6 (Failure Scenarios): “…the PE must withdraw all the associated Ethernet AD routes…”  Should that be a “MUST”?
>  
> P14. A reference to “[ietf-evpn-overlay]” appears in the Security Considerations, but there’s no Reference later on. 
>  
>  
> Nits:
>  
> N1. “Both services are supported by using…I.e., for both EPL and EVPL services…”  The second part of that explanation is a lot clearer, you might want to simplify by just leaving that part in.
>  
> N2. The introduction reads like a rushed summary of the solution, which results in potentially confusing text.  Suggestion: focus the Introduction on setting the stage/background – if you want to provide a summary of the solution (good idea!), then do it after the requirements.
>  
> N3. s/Ethernet Segment on a PE refer to/Ethernet Segment on a PE refers to
>  
> N4. s/multi home…single home/multi homed…single homed
>  
> N5. The text in Section 9 is misaligned.
> _______________________________________________
> BESS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bess