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

From: Sami Boutros <[email-masked]>
Date: Fri, 3 Feb 2017 21:41:42 +0000

Hi Alvaro,

Thanks for your review. Please have a look at attached draft w/ most of the comments addressed.

Please see comments inline Sami:

Thanks,

Sami
From: "Alvaro Retana (aretana)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, January 25, 2017 at 8:39 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Jeffrey Zhang <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: AD Review of draft-ietf-bess-evpn-vpws-07
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, Sami Boutros <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Resent-Date: Wednesday, January 25, 2017 at 8:39 PM

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.

Sami: I will change the text from “a valid value” —> “non zero value”.

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.

Sami: A valid value will be non-zero 24-bit, I will change the text to "non-zero 24-bit VPWS service instance identifier"

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

Sami: Will change the introduction to say MUST be

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

Sami: In the introduction we have this text "[MEF] defines Ethernet Virtual Private Line (EVPL) service as p2p service between a pair of ACs (designated by VLANs) and Ethernet Private Line (EPL) service …” So, isn’t that sufficient?

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

Sami: Please have a look at the attached draft to see if you are OK with the section now, we can consider removing the section too.

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?

Sami: Changed the text to "This document specifies 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 MUST be set to the 24-bit VPWS service instance identifier value."

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

Sami: changed the text to "MUST be set to 1 for multihoming all-active scenarios by  all active PE(s)."

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.

Sami: We are already describing how the other control flags be assigned in the doc, we have 2 other Flags B and C, not sure why do we need a new registry?

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?

Sami:  Added "In multihoming scenarios, both B and P flags MUST not be both set or both unset by a sender PE, and a receiving PE that receives an update with both B and P flags set or unset MUST not forward any traffic to the sender PE.”  Need to review this with other authors too.

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.

Sami: Added text "B flag SHOULD not be set in the multihoming all-active scenario and MUST be ignored by receiving PE(s)."

M6.5. What units is the MTU in?  How is it encoded?

Sami: Added "L2 MTU (Maximum Transmission Unit) is a 2-octet value indicating the MTU in octets”

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

Sami: Changed to MUST.

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…”

Sami: changed text to "If a network uses entropy labels per [RFC6790] then the C Bit MUST not be set to 1 and control word MUST NOT be used when sending EVPN-encapsulated packets over a P2P LSP.”

Minor:

P1. Please add a reference for VPWS.

Sami: You mean PWE3 reference?

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?

Sami: No clue here!

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.

Sami: Done for what happen before terminology.

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.

Sami: Please look at doc.

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.

Sami: Done.

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.

Sami: Done.

P8. S-VLAN, C-VLAN: expand and put a reference for them.

Sami: Done added to terminology.

P9. There is no Reference to any of the Extended Communities RFCs: 4360, 7153, etc…

Sami: Done.

P10. Please add Figure numbers/names.

Sami: Done.

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.

Sami: Please have a look.

P12. Section 4 (Operation): s/with Next Hop attribute set/with the NEXT_HOP attribute set   Also, include an Informative reference to RFC4271.

Sami: Done.

P13. Section 6 (Failure Scenarios): “…the PE must withdraw all the associated Ethernet AD routes…”  Should that be a “MUST”?

Sami: Done.
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.

Sami: I don’t get this.

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.

Sami: I prefer to leave it as is.

N3. s/Ethernet Segment on a PE refer to/Ethernet Segment on a PE refers to

Sami: Done

N4. s/multi home…single home/multi homed…single homed

Sami: Done

N5. The text in Section 9 is misaligned.

Sami: Done.

---

From: Sami Boutros <[email-masked]>
Date: Fri, 3 Feb 2017 22:01:44 +0000

Hi Iftekhar,

Please see comments inline.

From: Iftekhar Hussain <[email-masked]<mailto:[email-masked]>>
Date: Thursday, January 26, 2017 at 2:44 PM
To: "Alvaro Retana (aretana)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Jeffrey Zhang <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, Sami Boutros <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Resent-Date: Thursday, January 26, 2017 at 2:44 PM

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.

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

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

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<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dsajassi-2Dbess-2Devpn-2Dvpws-2Dfxc-2D01&d=DwMGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=IVzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98&m=HcUojq-BETlXVyoybL6fXvPLI8qFDvFHnbLsuHVNeew&s=S9UX7kIkRIvJs6_-bWMXPlhhP-3rSRpJYb8DSuaUdJo&e=> 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.

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:[email-masked]]
Sent: Wednesday, January 25, 2017 8:39 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Jeffrey Zhang; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Dear authors:

Hi!

Thanks!

Alvaro.

Major:

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.

Minor:

Nits:

---

From: Iftekhar Hussain <[email-masked]>
Date: Fri, 3 Feb 2017 23:15:41 +0000

Hi Sami,

Thanks for your response. Please see in-line.

From: Sami Boutros [mailto:[email-masked]]
Sent: Friday, February 03, 2017 2:02 PM
To: Iftekhar Hussain; Alvaro Retana (aretana); [email-masked]
Cc: Jeffrey Zhang; [email-masked]; [email-masked]
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Iftekhar,

Hi Authors,

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?

Iftekhar: Okay.

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.

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

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?

Thanks,
Iftekhar

Thanks,

Sami

Thanks,
Iftekhar

Dear authors:

Hi!

Thanks!

Alvaro.

Major:

Minor:

Nits:

---

From: Sami Boutros <[email-masked]>
Date: Fri, 3 Feb 2017 17:48:48 -0800

Hi Iftekhar,

Please see inline
> 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 construct…

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.

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

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.

> ·         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?

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 suc…

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
> To: [email-masked]
> 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
>  
>  
> _______________________________________________
> BESS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bess

---

From: Sami Boutros <[email-masked]>
Date: Sun, 5 Feb 2017 19:58:52 +0000

[Attached is the draft updated with the VPWS Service instance (control plane managed entity) definition in the terminology section and with the general VPWS reference to RFC4664]
Hi Iftekhar,

Please see inline

Hi Authors,

Sami: Please refer to https://tools.ietf.org/html/rfc4664<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_rfc4664&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=IVzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98&m=arr8Ec2cKeCgz5UeHU7m9StAzmZwpiDEjN_kojOLZro&s=SwLT4zos2yLfooM7WUvRf7cB2C3LYHoDtltS7alnmKs&e=> for the general VPWS definition. I will add a reference to it in the doc.

Iftekhar: Okay.

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

Thanks,

Sami

Thanks,
Iftekhar

Thanks,

Sami

Thanks,
Iftekhar

Dear authors:

Hi!

Thanks!

Alvaro.

Major:

Minor:

Nits:

N5. The text in Section 9 is misaligned.
_______________________________________________
BESS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/bess<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_bess&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=IVzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98&m=arr8Ec2cKeCgz5UeHU7m9StAzmZwpiDEjN_kojOLZro&s=KGkV-85RhWJnZPcuzM-GhaOfNb4s-XYBH5rHBnEDjEw&e=>

---

From: Sami Boutros <[email-masked]>
Date: Tue, 7 Feb 2017 19:06:09 +0000

Hi Iftekhar,

Are you ok with what I added to the doc? For presenting the entity for Management.

VPWS Service Instance: It is represented by a pair of EVPN service labels associated with a pair of endpoints. Each label is downstream assigned and advertised by the disposition PE through an Ethernet A-D per-EVI route. The downstream label identifies the endpoint on the disposition PE. A VPWS service instance can be associated with only one VPWS service identifier.

Thanks,

Sami

---

From: Iftekhar Hussain <[email-masked]>
Date: Tue, 7 Feb 2017 19:36:19 +0000

Hi Sami,

Please see in-line {iftekhar2]

From: Sami Boutros [mailto:[email-masked]]
Sent: Sunday, February 05, 2017 11:59 AM
To: Iftekhar Hussain
Cc: Alvaro Retana (aretana); Jeffrey Zhang; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Please see inline

Hi Authors,

[Iftekhar2] “….refer to AC as the VLAN like port”. My question is why a port is not an AC? In my understanding an AC can be a single VLAN, multiple (list or range of VLANs) including the entire port (all VLANs). My suggestion is even for the EPL (port-based service) – you should use the term AC (as opposed to ES). In addition, if you need the notion of ES to define the service that is okay. My earlier question was if you could provide an example of all the management entities involved for configuring a EVPL and a EPL service using the VPWS-EVPN solution that would be helpful.

Having said that I don’t want to hold your doc back, if other folks, are happy with the current state of the doc and want to proceed to the next step that is fine.

Iftekhar: Okay.

[Iftekhar2] Not sure, I agree with that. However, I will leave it up to you to decide. If you prefer not to summarize the deltas – fine.

[Iftekhar2] What I am asking is could you introduce a name for the equivalent entity for the VPWS-EVPN solution? My earlier suggestion is just call it a “service tunnel” or something of your choice. I don’t think it will change your control plane mechanism however it will make your model very clear. Note a LSP can carry multiple services. I am talking about per service statistic counters.
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?

[Iftekhar2] An issue pointed earlier that I see with the current solution is that there is no per service level entity for statistic counters on the PSN side. The LSP provides aggregate counters for all the services carried on that LSP. A LSP could be carrying multiple VPWS-EVPN services. My suggestion is that it would be better to sort this out. Again, if other folks are happy with the current state of the doc, I don’t want to hold your doc.

Thanks,
Iftekhar

Thanks,

Sami

Thanks,
Iftekhar

Thanks,

Sami

Thanks,
Iftekhar

Dear authors:

Hi!

Thanks!

Alvaro.

Major:

Minor:

Nits:

---

From: Sami Boutros <[email-masked]>
Date: Tue, 7 Feb 2017 19:54:51 +0000

Hi Iftekhar,

[Iftekhar2] An issue pointed earlier that I see with the current solution is that there is no per service level entity for statistic counters on the PSN side. The LSP provides aggregate counters for all the services carried on that LSP.

[Sami] The EVPN-VPWS LSP here carries only one service not multiple servcies. Here is what I added. I hope this will be good enough.

Thanks,

Sami

A LSP could be carrying multiple VPWS-EVPN services. My suggestion is that it would be better to sort this out. Again, if other folks are happy with the current state of the doc, I don’t want to hold your doc.

Thanks,
Iftekhar

Thanks,

Sami

---

From: "Shah, Himanshu" <[email-masked]>
Date: Tue, 7 Feb 2017 20:45:58 +0000

Hi Sami –

It seems to me that single-active multihoming case could use some more clarification text.

I think there should be an additional field in L2 extended community
as (for example) “election priority” so that each multi-homed member can definitely tell
to each other as well as to remote PE who/what primary election order would be.

Thus, when ESI link to primary fails, remote PE can quickly change the next hop
to next priority PE multi-home member.

The text in VPWS draft is not very clear.

It seems to suggest there could be multiple primaries and backups.
But if that is true how would remote PE can independently switchover to backup PE
(i.e. which backup PE?).

If there are multiple primary PEs, and if one of them fail, why not switchover to other
primary PE, so on and so forth..

So what is the intent?

One primary, one backup
Multiple primary, one backup
Or (one or) multiple primaries, multiple backups?

Also, there has to be corresponding understanding/configuration in CE as well.
So if the CE+multi-hommed-PEs configuration is consistent and if all the parties,
(CE, multi-homed PEs and remote PE) are aware of this, selection algorithm would work better?

Thanks,
Himanshu

From: BESS [mailto:[email-masked]] On Behalf Of Sami Boutros
Sent: Tuesday, February 07, 2017 2:06 PM
To: Sami Boutros <[email-masked]>; Iftekhar Hussain <[email-masked]>
Cc: Jeffrey Zhang <[email-masked]>; Alvaro Retana (aretana) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Iftekhar,

Thanks,

Sami

---

From: Sami Boutros <[email-masked]>
Date: Tue, 7 Feb 2017 23:06:17 +0000

Hi Himanshu,

From: "Shah, Himanshu" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, February 7, 2017 at 12:45 PM
To: Sami Boutros <[email-masked]<mailto:[email-masked]>>, Sami Boutros <[email-masked]<mailto:[email-masked]>>, Iftekhar Hussain <[email-masked]<mailto:[email-masked]>>
Cc: Jeffrey Zhang <[email-masked]<mailto:[email-masked]>>, "Alvaro Retana (aretana)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Sami –

[Sami] In single active, there would be only one primary as per definition below in this e-mail.

[Sami] Extending the DF election is not in scope for the draft and I doubt we will include it, however there are other drafts extending DF election like rabadan-evpn-pref-df.

[Sami] As per draft, "A remote PE receiving B=1 from more than one PE will select only one backup PE."

[Sami] In single active there should be only one primary, having more than one primary will be transit in this case.

So what is the intent?

[Sami] As per EVPN, the intent is to support A/A in which all will be primary, or A/S in which only one primary and one backup.

One primary, one backup

[Sami] We are not redefining what single active or all active mean, this is as per EVPN RFC7432

Single-Active Redundancy Mode: When only a single PE, among all the
      PEs attached to an Ethernet segment, is allowed to forward traffic
      to/from that Ethernet segment for a given VLAN, then the Ethernet
      segment is defined to be operating in Single-Active redundancy
      mode.

I.e. One primary and one/multiple backup.

   All-Active Redundancy Mode: When all PEs attached to an Ethernet
      segment are allowed to forward known unicast traffic to/from that
      Ethernet segment for a given VLAN, then the Ethernet segment is
      defined to be operating in All-Active redundancy mode.

 I.e. Multiple Primary

[Sami] Again, we are not redefining EVPN multihoming or DF election, those are following base EVPN.

Thanks,

Sami

Thanks,
Himanshu

From: BESS [mailto:[email-masked]] On Behalf Of Sami Boutros
Sent: Tuesday, February 07, 2017 2:06 PM
To: Sami Boutros <[email-masked]<mailto:[email-masked]>>; Iftekhar Hussain <[email-masked]<mailto:[email-masked]>>
Cc: Jeffrey Zhang <[email-masked]<mailto:[email-masked]>>; Alvaro Retana (aretana) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Iftekhar,

Thanks,

Sami

---

From: Iftekhar Hussain <[email-masked]>
Date: Wed, 8 Feb 2017 18:45:00 +0000

Hi Sami,

To make my comments clear (in case it didn’t come through earlier emails), I am summarizing my comments again.

1.       Clearly identify the role of AC and ES for point-to-point services

2.       Clearly identify and document the reference model for the point-to-point services. For example, here is what I believe the model should look like.

3.       Define an entity to toward PSN – see the picture above. Like I said earlier, if we don’t fix it now, it is only get worse/confusing as other extensions are added.

4.       I would reiterate again – please summarize the functionality of RFC7432 that applies to point-to-point services and which does not.  Users who are only interested in point-to-point services, could use this document to implement it without getting drowned information which is not relevant in such scenarios. Point-to-point services should be treated as services in their own wright – rather than after thought or extension of multipoint services.

Hope this makes it clear the type of updates I am looking for.

Thanks,
Iftekhar

From: Sami Boutros [mailto:[email-masked]]
Sent: Tuesday, February 07, 2017 11:55 AM
To: Iftekhar Hussain
Cc: Alvaro Retana (aretana); Jeffrey Zhang; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Iftekhar,

Thanks,

Sami

Thanks,
Iftekhar

Thanks,

Sami

---

From: Sami Boutros <[email-masked]>
Date: Wed, 8 Feb 2017 19:24:42 +0000

Hi Iftekhar,

We can have a phone call to go over this, if you like, I will send you my availability in contact in a private e-mail.
From: Iftekhar Hussain <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, February 8, 2017 at 10:45 AM
To: Sami Boutros <[email-masked]<mailto:[email-masked]>>
Cc: "Alvaro Retana (aretana)" <[email-masked]<mailto:[email-masked]>>, Jeffrey Zhang <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Sami,

Sami: We clearly say the following: "Ethernet Virtual Private Line (EVPL) service as p2p service between a pair of ACs (designated by VLANs) and Ethernet Private Line (EPL) service, in which all traffic flows are between a single pair of ports, that in EVPN terminology would mean a single pair of Ethernet Segments ES(es).”
But I think you don’t find that clear, so can you propose some text that will make it clear?

Sami: We have a already a reference model similar to PWE3 in the doc, in section 4. Not sure what the above will do, and does PWE3 have the above? If you need the above to define some YANG data model, I would recommend adding it to the YANG data model draft!

Sami: Can you propose some text for that? That will make it clear for you different than what we already added.
"VPWS Service Instance: It is represented by a pair of EVPN service labels associated with a pair of endpoints. Each label is downstream assigned and advertised by the disposition PE through an Ethernet A-D per-EVI route. The downstream label identifies the endpoint on the disposition PE. A VPWS service instance can be associated with only one VPWS service identifier.”

Sami: And, I will repeat again, through out the document we are only talking about only E-AD routes, which is used by EVPN-VPWS service, and when we talk about redundancy we refer to the EVPN base for single-active and active-active, not sure what else do you want us to say? As I said we don’t agree to list what we don’t support from EVPN, since the list can’t predict what future extensions will be added to EVPN.

Thanks,

Sami

Thanks,
Iftekhar

From: Sami Boutros [mailto:[email-masked]]
Sent: Tuesday, February 07, 2017 11:55 AM
To: Iftekhar Hussain
Cc: Alvaro Retana (aretana); Jeffrey Zhang; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Iftekhar,

Thanks,

Sami

Thanks,
Iftekhar

Thanks,

Sami

---

From: Iftekhar Hussain <[email-masked]>
Date: Wed, 8 Feb 2017 19:55:29 +0000

Hi Sami,

Certainly, if it helps, certainly we could chat  via phone sometime. PWE3 model is different than what your doc is proposing. No, I am not looking for Yang model – I am co-authoring one. I am looking for clarity and thoroughness.

Thanks,
Iftekhar

From: Sami Boutros [mailto:[email-masked]]
Sent: Wednesday, February 08, 2017 11:25 AM
To: Iftekhar Hussain
Cc: Alvaro Retana (aretana); Jeffrey Zhang; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Iftekhar,

Hi Sami,

Thanks,

Sami

Thanks,
Iftekhar

Hi Iftekhar,

Thanks,

Sami

Thanks,
Iftekhar

Thanks,

Sami

---

From: "Shah, Himanshu" <[email-masked]>
Date: Wed, 8 Feb 2017 23:04:45 +0000

Hi Sami –

Thanks for clarifications. The rabadan-evpn-pref-df has the right idea (did not know about it...)

Following text from the draft –

   In multihoming single-active scenario, the DF election will determine
   who the primary and the backup PEs are, and only those PEs will set
   the P bit and B bit respectively. A remote PE will forward the
   traffic to the primary PE and switch over to the backup PE as soon as
   it receives an Ethernet A-D route withdrawal from the primary PE in
   the Ethernet Segment.
----
[Himanshu] the highlighted text is somewhat confusing in the context of
multiple backups (in single-active redundancy). How would remote PE know
which backup to switch over to.
----
   In multihoming single-active scenario, during transient situations, a
   remote PE receiving P=1 from more than one PE will select the last
   advertising PE as the primary PE when forwarding traffic. A remote PE
  receiving B=1 from more than one PE will select only one backup PE. A
   remote PE MUST receive P=1 from at least one PE before forwarding
----
[Himanshu] the above highlighted text seems to suggest that only one backup
is supported, contrary to what you suggest below that one primary
and one or more backups are supported.
---

It would be better if the draft clearly states that it will only support
One primary and one backup in single-active redundancy and one primary
and multiple backups are NOT supported (unlike EVPN..)

Also, for single-active redundancy, DF election is relegated to selection of
the role of multi-homed PEs to be primary or backup. Is this role determined
in the context of VLANs (bundled VLAN case), I am guessing NOT.
Clarifying text in this area would also be helpful.

Thanks,
Himanshu

From: Sami Boutros [mailto:[email-masked]]
Sent: Tuesday, February 07, 2017 6:06 PM
To: Shah, Himanshu <[email-masked]>; Sami Boutros <[email-masked]>; Iftekhar Hussain <[email-masked]>
Cc: Jeffrey Zhang <[email-masked]>; Alvaro Retana (aretana) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Himanshu,

Hi Sami –

So what is the intent?

One primary, one backup

      mode.

 I.e. Multiple Primary

Thanks,

Sami

Thanks,
Himanshu

Hi Iftekhar,

Thanks,

Sami

---

From: Sami Boutros <[email-masked]>
Date: Wed, 8 Feb 2017 23:39:06 +0000

Hi Himanshu,

Date: Wednesday, February 8, 2017 at 3:04 PM

Hi Sami –

[Sami] But wouldn’t the text highlighted here clarify the text above, that only one Backup should be selected.

[Sami] Why the limitation? Any reason? For PW redundancy we do support too multiple backups, however for
a given PW only one backup will be selected, exactly the same as here.

[Sami] DF election is intentionally not in scope, not to redefine any mechanisms in Base 7432 or other drafts like
draft-ietf-bess-evpn-df-election.

Thanks,

Sami

Thanks,
Himanshu

To: Shah, Himanshu <[email-masked]<mailto:[email-masked]>>; Sami Boutros <[email-masked]<mailto:[email-masked]>>; Iftekhar Hussain <[email-masked]<mailto:[email-masked]>>

Hi Himanshu,

Hi Sami –

So what is the intent?

One primary, one backup

      mode.

 I.e. Multiple Primary

Thanks,

Sami

Thanks,
Himanshu

Hi Iftekhar,

Thanks,

Sami

---

From: "Rabadan, Jorge (Nokia - US)" <[email-masked]>
Date: Wed, 8 Feb 2017 23:47:08 +0000

Himanshu,

Just to reinforce what Sami is saying, I think the confusion comes between how many backup or redundant nodes can be in an ethernet-segment, and how many of them can signal B=1.

There is only one PE signaling B=1. There may be more than 2 PEs in the ES, in which case there are more than 1 redundant PEs, but only one PE should signal B=1 at the time. Since there may be transient windows where the remote PE gets 2 P=1s or 2 B=1s, we need to define what to do, but it doesn’t mean that is a normal steady state.

In a nutshell, Primary will send P=1,B=0. Backup will send P=0,B=1 and the rest of the redundant PEs in the ES will send P=0,B=0. If the primary PE/ES fails, the remote PEs will immediately send to the backup. In the meantime, there is a DF reelection, and there will be a new primary and new backup that will signal the bits as per the above. The remote PE will always send to the primary first and if not present to the backup.

I think all this is in the draft though…

Thanks.
Jorge

On 2/9/17, 12:39 AM, "Sami Boutros" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Himanshu,

Hi Sami –

Thanks,

Sami

Thanks,
Himanshu

Hi Himanshu,

Hi Sami –

So what is the intent?

One primary, one backup

      mode.

 I.e. Multiple Primary

Thanks,

Sami

Thanks,
Himanshu

Hi Iftekhar,

Thanks,

Sami

---

From: "Shah, Himanshu" <[email-masked]>
Date: Wed, 8 Feb 2017 23:54:47 +0000

Ahh...This makes sense.

And NO it is not in the draft. Contrary, draft says that remote will accept only one as B=1 (may be to his liking..:-))

What you say below needs to be explicitly included in the draft. Please..

Thanks,
Himanshu

From: Rabadan, Jorge (Nokia - US) [mailto:[email-masked]]
Sent: Wednesday, February 08, 2017 6:47 PM
To: Sami Boutros <[email-masked]>; Shah, Himanshu <[email-masked]>; Sami Boutros <[email-masked]>; Iftekhar Hussain <[email-masked]>
Cc: Jeffrey Zhang <[email-masked]>; Alvaro Retana (aretana) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Himanshu,

Thanks.
Jorge

Hi Himanshu,

Hi Sami –

Thanks,

Sami

Thanks,
Himanshu

Hi Himanshu,

Hi Sami –

So what is the intent?

One primary, one backup

      mode.

 I.e. Multiple Primary

Thanks,

Sami

Thanks,
Himanshu

Hi Iftekhar,

Thanks,

Sami

---

From: Sami Boutros <[email-masked]>
Date: Thu, 9 Feb 2017 00:12:14 +0000

From: "Shah, Himanshu" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, February 8, 2017 at 3:54 PM
To: "Rabadan, Jorge (Nokia - US)" <[email-masked]<mailto:[email-masked]>>, Sami Boutros <[email-masked]<mailto:[email-masked]>>, Sami Boutros <[email-masked]<mailto:[email-masked]>>, Iftekhar Hussain <[email-masked]<mailto:[email-masked]>>
Cc: Jeffrey Zhang <[email-masked]<mailto:[email-masked]>>, "Alvaro Retana (aretana)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Ahh...This makes sense.

[Sami] This is correct,  we can receive more than one P=1 and on B=1 and the draft say this happen only in transit scenarios as in  the following text.. for a given EVPN-VPWS instance.

In multihoming single-active scenario, during transient situations, a remote PE receiving P=1 from more than one PE will select the last advertising PE as the primary PE when forwarding traffic. A remote PE receiving B=1 from more than one PE will select only one backup PE. A remote PE MUST receive P=1 from at least one PE before forwarding traffic.

Thanks,

Sami

Thanks,
Himanshu

To: Sami Boutros <[email-masked]<mailto:[email-masked]>>; Shah, Himanshu <[email-masked]<mailto:[email-masked]>>; Sami Boutros <[email-masked]<mailto:[email-masked]>>; Iftekhar Hussain <[email-masked]<mailto:[email-masked]>>

Himanshu,

Thanks.
Jorge

Hi Himanshu,

Hi Sami –

Thanks,

Sami

Thanks,
Himanshu

Hi Himanshu,

Hi Sami –

So what is the intent?

One primary, one backup

      mode.

 I.e. Multiple Primary

Thanks,

Sami

Thanks,
Himanshu

Hi Iftekhar,

Thanks,

Sami

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 9 Feb 2017 00:31:16 +0000

Hi Sami –

I strongly suggest that more clarifying text is added.
VPWS draft is introducing the Primary/backup extensions
and it is confusing what the exact behavior should be for
single-active multi-homing.

Even in case of transition, how multi-homed PEs behavior wrt
P/B when it would change from P to B and B to P and what remote
has accepted is not clear (what ‘last’ received at remote is
not assured at originating multi-homed PE members).

More I think about it, pref-def draft is increasingly playing
important role for this to be clean.

Thanks,
Himanshu

From: Sami Boutros [mailto:[email-masked]]
Sent: Wednesday, February 08, 2017 7:12 PM
To: Shah, Himanshu <[email-masked]>; Rabadan, Jorge (Nokia - US) <[email-masked]>; Sami Boutros <[email-masked]>; Iftekhar Hussain <[email-masked]>
Cc: Jeffrey Zhang <[email-masked]>; Alvaro Retana (aretana) <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Ahh...This makes sense.

Thanks,

Sami

Thanks,
Himanshu

Himanshu,

Thanks.
Jorge

Hi Himanshu,

Hi Sami –

Thanks,

Sami

Thanks,
Himanshu

Hi Himanshu,

Hi Sami –

So what is the intent?

One primary, one backup

      mode.

 I.e. Multiple Primary

Thanks,

Sami

Thanks,
Himanshu

Hi Iftekhar,

Thanks,

Sami

---

From: Sami Boutros <[email-masked]>
Date: Thu, 9 Feb 2017 00:45:45 +0000

Hi Himanshu,

Will changing the text as below make it clear ?

In multihoming single-active scenario, for a given VPWS service instance, in steady state, a remote PE SHOULD receive P=1 from only one PE and a B-1 from only one PE. However during transient situations, a remote PE receiving P=1 from more than one PE will select the last advertising PE as the primary PE when forwarding traffic. A remote PE receiving B=1 from more than one PE will select only one backup PE. A remote PE MUST receive P=1 from at least one PE before forwarding traffic.

Thanks,

Sami

From: "Shah, Himanshu" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, February 8, 2017 at 4:31 PM
To: Sami Boutros <[email-masked]<mailto:[email-masked]>>, "Rabadan, Jorge (Nokia - US)" <[email-masked]<mailto:[email-masked]>>, Sami Boutros <[email-masked]<mailto:[email-masked]>>, Iftekhar Hussain <[email-masked]<mailto:[email-masked]>>
Cc: Jeffrey Zhang <[email-masked]<mailto:[email-masked]>>, "Alvaro Retana (aretana)" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

Hi Sami –

Thanks,
Himanshu

To: Shah, Himanshu <[email-masked]<mailto:[email-masked]>>; Rabadan, Jorge (Nokia - US) <[email-masked]<mailto:[email-masked]>>; Sami Boutros <[email-masked]<mailto:[email-masked]>>; Iftekhar Hussain <[email-masked]<mailto:[email-masked]>>

Ahh...This makes sense.

Thanks,

Sami

Thanks,
Himanshu

Himanshu,

Thanks.
Jorge

Hi Himanshu,

Hi Sami –

Thanks,

Sami

Thanks,
Himanshu

Hi Himanshu,

Hi Sami –

So what is the intent?

One primary, one backup

      mode.

 I.e. Multiple Primary

Thanks,

Sami

Thanks,
Himanshu

Hi Iftekhar,

Thanks,

Sami

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 9 Feb 2017 00:53:07 +0000

Hi Sami –

I recommend using Jorge’s text. That says, what originating multi-homed PEs should behave in single-active case.
That along with the text below (on how remote should behave) will help.

Thanks,
Himanshu

Sent: Wednesday, February 08, 2017 7:46 PM

Hi Himanshu,

Thanks,

Sami

Hi Sami –

Thanks,
Himanshu

Ahh...This makes sense.

Thanks,

Sami

Thanks,
Himanshu

Himanshu,

Thanks.
Jorge

Hi Himanshu,

Hi Sami –

Thanks,

Sami

Thanks,
Himanshu

Hi Himanshu,

Hi Sami –

So what is the intent?

One primary, one backup

      mode.

 I.e. Multiple Primary

Thanks,

Sami

Thanks,
Himanshu

Hi Iftekhar,

Thanks,

Sami

---

From: Sami Boutros <[email-masked]>
Date: Thu, 9 Feb 2017 01:42:10 +0000

How about this?

In multihoming single-active scenario, for a given VPWS service instance, in steady state, as result of DF election, the Primary elected PE for the VPWS service instance should signal P=1,B=0, the Backup elected PE should signal P=0,B=1, and the rest of the PEs in the same ES should signal P=0,B=0. When the primary PE/ES fails, the primary PE will withdraw the associated Ethernet A-D routes for the VPWS service instance from the remote PE, the remote PEs should then send traffic associated with the VPWS instance to the backup PE.

DF re-election will happen between the PE(s) in the same ES, and there will be a new elected primary PE and new elected backup PE that will signal the P and B bits as described. A remote PE SHOULD receive P=1 from only one Primary PE and a B-1 from only one Backup PE. However during transient situations, a remote PE receiving P=1 from more than one PE will select the last advertising PE as the primary PE when forwarding traffic. A remote PE receiving B=1 from more than one PE will select only one backup PE. A remote PE MUST receive P=1 from at least one PE before forwarding traffic.

Thanks,

Sami

Date: Wednesday, February 8, 2017 at 4:53 PM

Hi Sami –

Thanks,
Himanshu

Hi Himanshu,

Thanks,

Sami

Hi Sami –

Thanks,
Himanshu

Ahh...This makes sense.

Thanks,

Sami

Thanks,
Himanshu

Himanshu,

Thanks.
Jorge

Hi Himanshu,

Hi Sami –

Thanks,

Sami

Thanks,
Himanshu

Hi Himanshu,

Hi Sami –

So what is the intent?

One primary, one backup

      mode.

 I.e. Multiple Primary

Thanks,

Sami

Thanks,
Himanshu

Hi Iftekhar,

Thanks,

Sami

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 9 Feb 2017 01:47:07 +0000

Works!!

Himanshu using iPad (so excuse the auto-corrects...)
________________________________
From: Sami Boutros <[email-masked]>
Sent: Wednesday, February 8, 2017 8:42:10 PM
To: Shah, Himanshu; Rabadan, Jorge (Nokia - US); Sami Boutros; Iftekhar Hussain
Cc: Jeffrey Zhang; Alvaro Retana (aretana); [email-masked]; [email-masked]; [email-masked]
Subject: Re: [bess] AD Review of draft-ietf-bess-evpn-vpws-07

How about this?

Thanks,

Sami

Hi Sami –

Thanks,
Himanshu

Hi Himanshu,

Thanks,

Sami

Hi Sami –

Thanks,
Himanshu

Ahh...This makes sense.

Thanks,

Sami

Thanks,
Himanshu

Himanshu,

Thanks.
Jorge

Hi Himanshu,

Hi Sami –

Thanks,

Sami

Thanks,
Himanshu

Hi Himanshu,

Hi Sami –

So what is the intent?

One primary, one backup

      mode.

 I.e. Multiple Primary

Thanks,

Sami

Thanks,
Himanshu

Hi Iftekhar,

Thanks,

Sami

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 16 Feb 2017 20:57:44 +0000

On 2/3/17, 4:41 PM, "Sami Boutros" <[email-masked]> wrote:

> Thanks for your review. Please have a look at attached draft w/ most of the comments

> addressed.

Looking at the published version -08.

I have some answers to your answers below.  I also see that there may be other changes as a result of the discussion on this thread.  I’ll wait for an update before starting the IETF Last Call.

Thanks!

Alvaro.

…

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

[a] the new text is not necessarily better – the normative language added doesn’t always do what it should, for example: “A given PE MAY have thousands of EVPLs configured.”  That is really still a statement, not an option (“MAY”) given as part of the solution.

Yes, please remove this section.

[a] Ok, but you still didn’t mention how the 24-bit value is to be aligned in the 32-bit field.  I’m guessing there will be some 0-padding, but will that the at the beginning or the end?

[a] The Control Flags field is 16 bits long, you’re only defining 3 bits.    If someone else in the future wants to use one of those other bits, what should be the criteria for assignment: first come first served, do you think they should at least have an RFC, should that be standards track??

As it is right now, IANA won’t know what to do if anyone else wants do use any of the other bits in the future.

Note that MBZ doesn’t preclude the bits being used in the future for something else.

[a] Not forwarding any traffic means that the route is ignored and not used, right?  Should it be discarded?  Maybe phrase the resulting action in terms of the route and not the forwarding of traffic…

[a] Yes, but what are the units?  0x0001 means what?  I would assume bytes, but please be specific.

Sami: Changed to MUST.

Minor:

[a] No, VPWS.  I think rfc4664 is called out at some point – please reference it when VPWS is first mentioned in the Introduction.

BTW, please move it to Informative to avoid a downref.

Sami: No clue here!

[a] How about this:  https://www.mef.net/Assets/Technical_Specifications/PDF/MEF_6.1.pdf  ??

Sami: Done.

Sami: Done.

Sami: Done.

[a] We still need a reference to rfc4360 – at least in Section 3.1 where the new community is defined.

You did add a reference to rfc7153, but it is not used in the text. ☹  There’s no point in having it if it isn’t used!

Sami: Done.

[a] Maybe it’s just me, but I don’t see them.  Note that the figures in 3.1 seem to run into each other w/out names/numbers.

[a] There are still several places where the P bit, B bit or C bit are used.

Sami: Done.

Sami: Done.

Nits:

Sami: I don’t get this.

[a]  Just a suggestion:

OLD>

   Both services are supported by using the per EVI Ethernet A-D route

   which contains an Ethernet Segment Identifier, in which the customer

   ES is encoded, and an Ethernet Tag, in which the VPWS service

   instance identifier is encoded.  I.e., for both EPL and EVPL

   services, a specific VPWS service instance is identified by a pair of

  per EVI Ethernet A-D routes which together identify the VPWS service

   instance endpoints and the VPWS service instance.

NEW>

   For both EPL and EVPL

   services, a specific VPWS service instance is identified by a pair of

   per EVI Ethernet A-D routes which together identify the VPWS service

   instance endpoints and the VPWS service instance.

Sami: Done

Sami: Done

Sami: Done.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 16 Feb 2017 20:58:23 +0000

On 2/16/17, 3:57 PM, "Alvaro Retana (aretana)" <[email-masked]<mailto:[email-masked]>> wrote:

Thanks!

Alvaro.

…

Sami: Changed to MUST.

Minor:

Sami: No clue here!

Sami: Done.

Sami: Done.

Sami: Done.

Sami: Done.

Sami: Done.

Sami: Done.

Nits:

Sami: I don’t get this.

[a]  Just a suggestion:

OLD>

NEW>

   For both EPL and EVPL

Sami: Done

Sami: Done

Sami: Done.

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Thu, 16 Feb 2017 21:09:01 +0000

[Oops…sent the last two too early… ☹ ]
 
Sami:

Hi

 
 
Thanks!
 
Alvaro.

…
 
> > 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.  ☹
> 
 
The new text is not necessarily better – the normative language added doesn’t always do what it should, for example: “A given PE MAY have thousands of EVPLs configured.”  That is really still a statement, not an option (“MAY”) given as part of the solution.

… 
> > 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?
> 
> Sami: Changed the text to "This document specifies 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 MUST be set to the 24-bit VPWS service instance identifier value."
 
Ok, but you still didn’t mention how the 24-bit value is to be aligned in the 32-bit field.  I’m guessing there will be some 0-padding, but will that the at the beginning or the end?

… 
> > 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.
> 
> Sami: We are already describing how the other control flags be assigned in the doc, we have 2 
> other Flags B and C, not sure why do we need a new registry?
 
The Control Flags field is 16 bits long, you’re only defining 3 bits.    If someone else in the future wants to use one of those other bits, what should be the criteria for assignment: first come first served, do you think they should at least have an RFC, should that be standards track??  

> > 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?
> 
> Sami:  Added "In multihoming scenarios, both B and P flags MUST not be both set or both unset by 
> a sender PE, and a receiving PE that receives an update with both B and P flags set or unset MUST 
> not forward any traffic to the sender PE.”  Need to review this with other authors too.
 
Not forwarding any traffic means that the route is ignored and not used, right?  Should it be discarded?  Maybe phrase the resulting action in terms of the route and not the forwarding of traffic…
 
… 
> Sami: Added "L2 MTU (Maximum Transmission Unit) is a 2-octet value indicating the MTU in octets”
 
Yes, but what are the units?  0x0001 means what?  I would assume bytes, but please be specific. 

… 
> Sami: You mean PWE3 reference?
 
No, VPWS.  I think rfc4664 is called out at some point – please reference it when VPWS is first mentioned in the Introduction.

> > 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?
> 
> Sami: No clue here!
 
How about this:  https://www.mef.net/Assets/Technical_Specifications/PDF/MEF_6.1.pdf  ??

…
> > P9. There is no Reference to any of the Extended Communities RFCs: 4360, 7153, etc…
 
We still need a reference to rfc4360 – at least in Section 3.1 where the new community is defined.

 
> > P10. Please add Figure numbers/names.
 
Maybe it’s just me, but I don’t see them.  Note that the figures in 3.1 seem to run into each other w/out names/numbers.

> > 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.
> 
 
There are still several places where the P bit, B bit or C bit are used.

…
> > 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.
> 
> Sami: I don’t get this.
 
Just a suggestion:
 
OLD>
 
NEW>
   For both EPL and EVPL

A couple more nits:

s/control flags SHOULD not be set in/control flags SHOULD NOT be set in

s/then the C Bit MUST not be set/then the C Flag MUST NOT be set

---

From: Sami Boutros <[email-masked]>
Date: Tue, 21 Feb 2017 17:39:13 +0000

Hi Alvaro,

Please see comments inline. I have submitted 09.

Thanks,

Sami

>> Sami: Please have a look at the attached draft to see if you are OK with the section now, we can 
>
>> consider removing the section too.
>
> 
>

I removed the section.

>Ok, but you still didn’t mention how the 24-bit value is to be aligned in the 32-bit field.  I’m guessing there will be some 0-padding, but will that the at the beginning or the end?

I made the VPWS service instance identifier a 32-bit value in the new draft.

>Note that MBZ doesn’t preclude the bits being used in the future for something else.

I added a registry in the IANA consideration.

This document creates a registry called "EVPN Layer 2 attributes
   Control Flags". New registrations will be made through the "RFC
   Required" procedure defined in [RFC5226].  

   Initial registrations are as follows:

     P      Advertising PE is the Primary PE.
     B      Advertising PE is the Backup PE.
     C      Control word [RFC4448] MUST be present 

>Not forwarding any traffic means that the route is ignored and not used, right?  Should it be discarded?  Maybe phrase the resulting action in terms of the route and not the forwarding of traffic…

Changed text to MUST discard the received route from the sender PE.

>Yes, but what are the units?  0x0001 means what?  I would assume bytes, but please be specific. 

Changed “in octets” —> “in bytes”

>No, VPWS.  I think rfc4664 is called out at some point – please reference it when VPWS is first mentioned in the Introduction.

This is what I did in the 08, I referenced it in the introduction.

>BTW, please move it to Informative to avoid a downref.

Done.

>How about this:  https://urldefense.proofpoint.com/v2/url?u=https-3A__www.mef.net_Assets_Technical-5FSpecifications_PDF_MEF-5F6.1.pdf&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=IVzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98&m=GH5FIfqtBUACPwx-LVV2v5zPrGcNzhCEjfj8-0-R2OI&s=5b19ceQDqdsz0TepqsV7daJoYm9uDMyco7BZ4NeICWU&e=   ??
>
> 

Thanks,
>You did add a reference to rfc7153, but it is not used in the text. ☹  There’s no point in having it if it isn’t used!
I changed the text as follow in 3.1 and added/removed the above references.

"This draft proposes a new extended community, defined below as per [RFC7432] in addition to the values specified in [RFC4360]"

>Maybe it’s just me, but I don’t see them.  Note that the figures in 3.1 seem to run into each other w/out names/numbers.
Sorry, fixed that too.
>There are still several places where the P bit, B bit or C bit are used.

Changed to Flag .

>   instance endpoints and the VPWS service instance.

Ok.

>s/then the C Bit MUST not be set/then the C Flag MUST NOT be set

Done.

Thanks,

Sami

---

From: John E Drake <[email-masked]>
Date: Tue, 21 Feb 2017 18:56:17 +0000

Sami,

Snipped, comment inline

Yours Irrespectively,

John

> >Ok, but you still didn’t mention how the 24-bit value is to be aligned in the 32-
> bit field.  I’m guessing there will be some 0-padding, but will that the at the
> beginning or the end?
> >
> 

[JD]   I don't think you can do this as there are multiple implementations that use 24 bits

---

From: Sami Boutros <[email-masked]>
Date: Tue, 21 Feb 2017 19:18:29 +0000

Hi John,

I can add that the value is from 0 to 0x00ffffff, will that work?

Thanks,

Sami

---

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Fri, 24 Feb 2017 15:15:30 +0000

On 2/21/17, 12:39 PM, "Sami Boutros" <[email-masked]> wrote:

Sami:

Hi!

> Please see comments inline. I have submitted 09.

I just have a couple of small things below, the biggest being the 24-bit alignment – which seems to be resolved on the list.

I’m going to start the IETF Last Call, but please update the draft when you get a chance.

Thanks,

Alvaro.

…
> > > Sami: Changed the text to "This document specifies 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 MUST be set to the 24-bit VPWS service instance identifier 
> > > value."
> >
> > Ok, but you still didn’t mention how the 24-bit value is to be aligned in the 32-bit field.  I’m 
> > guessing there will be some 0-padding, but will that the at the beginning or the end?
> >
>

I also like Patrice’s suggestion [1]

[1] https://mailarchive.ietf.org/arch/msg/bess/hYuoAvF4eeYVSRRrlVi8MQMOf3Y/?qid=50f2dee8ec109478be61f1e0aefd03a5 

…
> > > > 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?
> > > 
> > > Sami: No clue here!
> > How about this:  https://urldefense.proofpoint.com/v2/url?u=https-
3A__www.mef.net_Assets_Technical-5FSpecifications_PDF_MEF-5F6.1.pdf&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r=IVzcTRLQdpta08L0b_y2zDkqvwJhRKMCAbX-2K-LV98&m=GH5FIfqtBUACPwx-LVV2v5zPrGcNzhCEjfj8-0-R2OI&s=5b19ceQDqdsz0TepqsV7daJoYm9uDMyco7BZ4NeICWU&e=   ??
> Thanks,

Sorry, I don’t know why we ended up with that long thing, this is the short one: https://www.mef.net/Assets/Technical_Specifications/PDF/MEF_6.1.pdf

> the values specified in [RFC4360]"

This is enough: “This draft proposes a new extended community [RFC4360]…”.