Subject: [bess] WG Last Call (including implem status & shepherd) for draft-ietf-bess-evpn-vpws-03

From: Martin Vigoureux <[email-masked]>
Date: Thu, 5 May 2016 12:54:13 +0200

Hello Working Group,

Please read carefully, this e-mail contains new elements compared to 
other WG LCs.

This email starts a Working Group Last Call on 
draft-ietf-bess-evpn-vpws-03 [1].

¤ Please read the document if you haven't read the most recent
version yet, and send your comments to the list, no later than
*20th of May*.
Note that this is *not only* a call for comments on the document, but 
also a call for support (or not) publishing this document as a Proposed 
Standard RFC.

¤ We are also polling for knowledge of any undisclosed IPR that applies 
to draft-ietf-bess-evpn-vpws-03, to ensure that IPR has been disclosed 
in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 
for more details) prior to moving forward.
If you are listed as a document Author or 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.
Two IPR disclosures exist against previous revisions of this document [2].

¤ We are also polling for knowledge of implementations of part or all of 
what this document specifies. This information is expected as per [3]. 
Please inform the mailing list, the chairs, or only one of the chairs.

¤ Finally, if someone wishes to volunteer to be Document Shepherd for 
this document, please let us know.

Thank you
M&T

[1] https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpws/
[2] 
https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-bess-evpn-vpws
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

---

From: "Rabadan, Jorge (Nokia - US)" <[email-masked]>
Date: Thu, 5 May 2016 17:15:40 +0000

As a co-author, I fully support this document for publication as Proposed Standard RFC and I’m not aware of any undisclosed IPR related to it.

It is a fundamental technology that will allow Operators to keep deploying EVPN, now also for ELINE services.
The document is ready for publication, however I have two LC comments that are already agreed with the authors:

1) Section 2.4 "Flexible CrossConnect" Service has to be removed from the final text. The requirements of this special service type are not in-line with the ones explained in section 1.2 and must be tackled separately.     

11) IANA considerations: the authors have agreed to request the value ‘4’ for the Extended Community Sub-Type, since there are existing implementations using that value.

Once both comments are addressed, the text is ready for publication.

Thank you.
Jorge

On 5/5/16, 12:54 PM, "BESS on behalf of EXT Martin Vigoureux" <[email-masked] on behalf of [email-masked]> wrote:

>_______________________________________________
>BESS mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/bess

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Thu, 5 May 2016 17:16:37 +0000

+1 

Jim Uttaro

-----Original Message-----
From: BESS [mailto:[email-masked]] On Behalf Of Rabadan, Jorge (Nokia - US)
Sent: Thursday, May 05, 2016 1:16 PM
To: Vigoureux, Martin (Nokia - FR) <[email-masked]>; BESS <[email-masked]>
Subject: Re: [bess] WG Last Call (including implem status & shepherd) for draft-ietf-bess-evpn-vpws-03

Thank you.
Jorge

---

From: Nabeel Cocker <[email-masked]>
Date: Thu, 5 May 2016 13:21:16 -0400

Support. 

Regards,
Nabeel

> On May 5, 2016, at 6:54 AM, Martin Vigoureux <[email-masked]> wrote:
> 
> Hello Working Group,
> 
> Please read carefully, this e-mail contains new elements compared to other WG LCs.
> 
> This email starts a Working Group Last Call on draft-ietf-bess-evpn-vpws-03 [1].
> 
> Note that this is *not only* a call for comments on the document, but also a call for support (or not) publishing this document as a Proposed Standard RFC.
> 
> ¤ We are also polling for knowledge of any undisclosed IPR that applies to draft-ietf-bess-evpn-vpws-03, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details) prior to moving forward.
> 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.
> ¤ We are also polling for knowledge of implementations of part or all of what this document specifies. This information is expected as per [3]. Please inform the mailing list, the chairs, or only one of the chairs.
> 
> ¤ Finally, if someone wishes to volunteer to be Document Shepherd for this document, please let us know.
> 
> Thank you
> M&T
> 
> 
> [2] https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-bess-evpn-vpws

---

From: "Patrice Brissette (pbrisset)" <[email-masked]>
Date: Thu, 5 May 2016 19:36:55 +0000

As co-author, I support that draft. It is solid and ready to go.

Regards,

Patrice

   Patrice Brissette
TECHNICAL LEADER.ENGINEERING

[email-masked]
Phone: +1 613 254 3336

Cisco Systems Canada Co. / Les Systemes Cisco Canada CIE
Canada
Cisco.com <http://www.cisco.com/global/CA/>

 Think before you print.This
 email may contain confidential and privileged material for the sole use
 of the intended recipient. Any review, use, distribution or disclosure
by others is strictly prohibited. If you are not the intended recipient
(or authorized to receive for the recipient), please contact the sender
by reply email and delete all copies of this message.
Please click here 
<http://www.cisco.com/web/about/doing_business/legal/cri/index.html> for
Company Registration Information.

On 2016-05-05, 1:15 PM, "BESS on behalf of Rabadan, Jorge (Nokia - US)"
<[email-masked] on behalf of [email-masked]> wrote:

>As a co-author, I fully support this document for publication as Proposed
>Standard RFC and I’m not aware of any undisclosed IPR related to it.
>
>It is a fundamental technology that will allow Operators to keep
>deploying EVPN, now also for ELINE services.
>The document is ready for publication, however I have two LC comments
>that are already agreed with the authors:
>
>1) Section 2.4 "Flexible CrossConnect" Service has to be removed from the
>final text. The requirements of this special service type are not in-line
>with the ones explained in section 1.2 and must be tackled separately.
> 
>
>11) IANA considerations: the authors have agreed to request the value ‘4’
>for the Extended Community Sub-Type, since there are existing
>implementations using that value.
>
>On 5/5/16, 12:54 PM, "BESS on behalf of EXT Martin Vigoureux"
><[email-masked] on behalf of [email-masked]> wrote:
>
>>Hello Working Group,
>>
>>https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>>

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 5 May 2016 19:37:44 +0000

I support WG LC for this draft as a co-author and I am not aware of any
IPR that hasn’t already been disclosed. This draft is important  to
Service Providers who want to offer P2P services with additional
feature/functionality that EVPN provides. Cisco has implemented EVPN-VPWS
based on this draft and it has been available since H2/2015.

There are a few nits that need to be taken care before RFC publication and
they can be done as part of WG LC comment resolutions:

1) There has been an agreement among the co-authors to move section 2.4 to
another draft which is at works and covers the topic of Flexible Cross
Connect comprehensively.

2) Section 10 should be expanded to describe why there are no additional
security requirements.

3) Section 11 should be expanded to list the IANA allocation for the EC
defined in section 3.1.

Regards,
Ali

---

From: Thomas Morin <[email-masked]>
Date: Mon, 9 May 2016 09:31:58 +0200

Hi Jorge, all,

> 11) IANA considerations: the authors have agreed to request the value ‘4’ for the Extended Community Sub-Type, since there are existing implementations using that value.

Note that given the FCFS policy of this part of the registry [1], you 
could ask for this value now without waiting and risking the value to be 
assigned to something else.
The online form is: http://www.iana.org/form/protocol-assignment

Once this is done the text is the IANA section in the draft would become 
"IANA has allocated Type 0x06/Sub-Type 0x04 for the 'EVPN Layer 2 
attributes extended community' defined in section 3.1".

Best,

-Thomas

[1] 
http://www.iana.org/assignments/bgp-extended-communities/bgp-extended-communities.xhtml#evpn

---

From: <[email-masked]>
Date: Mon, 9 May 2016 15:39:41 +0200

Hi Jorge, all,

While looking at pending shepherd write-ups, I noticed that 
draft-ietf-bess-evpn-etree is also asking for the same sub-type (0x04) [1].

Hopefully there will be a nice way to sort this out, but the lesson is 
that we collectively fail to get the benefits that a First Come First 
Server policy offers.

Best,

-Thomas

[1] https://tools.ietf.org/html/draft-ietf-bess-evpn-etree-04#section-8

Thomas Morin:
> Hi Jorge, all,
>
> Jorge:
>> 11) IANA considerations: the authors have agreed to request the value 
>> ‘4’ for the Extended Community Sub-Type, since there are existing 
> could ask for this value now without waiting and risking the value to 
> be assigned to something else.
> Once this is done the text is the IANA section in the draft would 
> become "IANA has allocated Type 0x06/Sub-Type 0x04 for the 'EVPN Layer 
> 2 attributes extended community' defined in section 3.1".
>
> Best,
>
> -Thomas
>
> [1] 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: John E Drake <[email-masked]>
Date: Mon, 9 May 2016 15:00:25 +0000

FYI

Yours Irrespectively,

John

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: Monday, May 09, 2016 9:54 AM
To: EXT - [email-masked]; Rabadan, Jorge (Nokia - US); [email-masked]; EXT Ali Sajassi (sajassi); EXT Sami Boutros
Cc: BESS Chairs
Subject: RE: [bess] WG Last Call (including implem status & shepherd) for draft-ietf-bess-evpn-vpws-03

Thomas,

Ali is planning to ask for the following code points:

0x04 (VPWS L2 Capabilities)
0x05 (E-Tree)
0x06 (DF Election)
0x07 (I-SID)

Yours Irrespectively,

John

> From: Thomas Morin [mailto:[email-masked]]
> Sent: Monday, May 09, 2016 9:42 AM
> To: Rabadan, Jorge (Nokia - US); [email-masked]; 
> EXT Ali Sajassi (sajassi); EXT Sami Boutros
> Cc: BESS Chairs
> Subject: Re: [bess] WG Last Call (including implem status & shepherd) 
> for draft-ietf-bess-
> evpn-vpws-03
> 
> Hi Jorge, all,
> 
> Follow-up my email on the list about the possible allocation conflict 
> with draft-ietf-bess- evpn-etree...
> 
> Please let us (Martin and me) know how you evaluate this issue, and if 
> the WG can help in a resolution if need be.
> 
> Best,
> 
> -Thomas
> 
> 
> 
> 2016-05-09, Rabadan, Jorge (Nokia - US):
> > Hi Thomas,
> >
> > Thank you.
> >
> > Ali, Sami, please let me know if you want me to fill out the form 
> > and apply for the sub-
> type, or you prefer to do it.
> > We also need to do it for Etree and DF Election.
> >
> > Thanks.
> > Jorge
> >
> >
> > On 5/9/16, 9:31 AM, "EXT Thomas Morin" <[email-masked]> wrote:
> >
> >> Hi Jorge, all,
> >>
> >> Jorge:
> >>> 11) IANA considerations: the authors have agreed to request the 
> >>> value ‘4’ for the
> Extended Community Sub-Type, since there are existing implementations using that value.
> >>
> >> Note that given the FCFS policy of this part of the registry [1], 
> >> you could ask for this value now without waiting and risking the 
> >> value to be assigned to something else.
> >> become "IANA has allocated Type 0x06/Sub-Type 0x04 for the 'EVPN 
> >> Layer 2 attributes extended community' defined in section 3.1".
> >>
> >> Best,
> >>
> >> -Thomas
> >>
> >> [1]
> >> http://www.iana.org/assignments/bgp-extended-communities/bgp-extend
> >> ed
> >> -communities.xhtml#evpn
> >

---

From: John E Drake <[email-masked]>
Date: Tue, 10 May 2016 15:45:18 +0000

Martin,

I support publishing this document as a Proposed Standard RFC and I'm not aware of any undisclosed IPR.

Juniper supports VPWS all-active and single-active redundancy modes with sub-second recovery on egress link failure.

Yours Irrespectively,

John

> From: BESS [mailto:[email-masked]] On Behalf Of Martin Vigoureux
> Sent: Thursday, May 05, 2016 6:54 AM
> To: BESS
> Subject: [bess] WG Last Call (including implem status & shepherd) for draft-ietf-bess-evpn-
> vpws-03
> 
> Hello Working Group,
> 
> ¤ Please read the document if you haven't read the most recent version yet, and send your
> comments to the list, no later than *20th of May*.
> Note that this is *not only* a call for comments on the document, but also a call for support
> (or not) publishing this document as a Proposed Standard RFC.
> 
> ¤ We are also polling for knowledge of any undisclosed IPR that applies to draft-ietf-bess-
> evpn-vpws-03, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see
> RFCs 3979, 4879, 3669 and 5378 for more details) prior to moving forward.
> If you are listed as a document Author or 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.
> ¤ We are also polling for knowledge of implementations of part or all of what this document
> specifies. This information is expected as per [3].

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 11 May 2016 18:13:19 +0000

Hi,

As the document shepherd, I have the following questions/comments. Some of which are just editorial nits.

   This document describes how EVPN can be used to support virtual
   private wire service (VPWS) in MPLS/IP networks.

Please capitalize "virtual private wire service". There are two other cases of this.

   ... eliminates the
   need for single-segment and multi-segment PW signaling,

This is not discussed in the draft later. It should either be discussed, or removed from the abstract & introduction.

   ... and provides
   fast protection using data-plane prefix independent convergence upon
   node or link failure.

This is not discussed in the draft either. Can you elaborate? Is it really enabled by EVPN or actually independent of EVPN?

It seems that the Ethernet Segment is not used consistently. From RFC 7432:

   Ethernet Segment (ES): When a customer site (device or network) is
      connected to one or more PEs via a set of Ethernet links, then
      that set of links is referred to as an 'Ethernet segment'.

My understanding is that ES is at link/port level and it refers to a set of links, while AC could be at vlan level. In the below paragraph,

   [EVPN] has the ability to forward customer traffic to/from a given
   customer Attachment Circuit (AC), aka Ethernet Segment in EVPN
   terminology, without any MAC lookup.

Here we're referring AC as ES - it does not seem to be stringent.
It's better to remove "aka Ethernet Segment in EVPN terminology" to avoid inconsistency.

   ... [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, in
   which all traffic flows are between a single pair of ESes.

Perhaps change "ESes" to "links or ESes"? The definition of ES in RFC7432 is "set of links". See below about generalization.

   ... EVPL can
   be considered as a VPWS with only two ACs.

Both EVPL and EPL can be considered as VPWS with only two ACs (I assume an AC is not necessarily at vlan level).

   ... In a VPWS service,  the traffic from an
   originating Ethernet Segment can be forwarded only to a single
   destination Ethernet Segment; hence, no MAC lookup is needed and the
   MPLS label associated with the per-EVI Ethernet AD route can be used
   in forwarding user traffic to the destination AC.

I can understand that ES here is generalized, but it's better to point out at the beginning.

   For a multi-homed CE, in an advertised Ethernet A-D per EVI route the
   ESI field is set to the CE's ESI and the Ethernet Tag field is set to
   the VPWS service instance identifier, which MUST have the same value
   on all PEs attached to that ES.

What if you receive a set of per EVI routes with the same Ethernet Tag field but different ESIs? The spec should define the behavior.

   In all cases traffic follows the transport paths, which
   may be asymmetric.

"follows the transport paths" is hard to understand. Perhaps this sentence could be deleted.

   The Ethernet Segment identifier encoded in the Ethernet A-D per EVI
   route is not used to identify the service, however it can be used for
   flow-based load-balancing and mass withdraw functions.

The first clause is a little strange in its reference to "identify the service". It seems to be just irrelevant? Also, it's not the ESI itself that is used for load-balancing? Perhaps the paragraph can be reworded as the following:

   The Ethernet A-D per ES route and corresponding Ethernet A-D per
   EVI routes can be correlated by the Ethernet Segment Identifier.
   This allows flow-based load-balancing and mass withdraw functions.

In the following paragraph:

   For EVPL
   service, the Ethernet frames transported over an MPLS/IP network MUST
   remain tagged with the originating VID and any VID translation is
   performed at the disposition PE. For EPL service, the Ethernet frames
   are transported as is and the tags are not altered.

"remain tagged" is a little unclear to me and RFC 7432 does not talk about it either. Is it that incoming tagging is not changed at all (e.g. double tagged) or is it single tagged with normalized VIDs? Is it that for both services, the frames are transported as is across the core, and the tag alteration is only happening at the disposition PE in case of EVPL?

   5. Also, multiple EVPL service VLANs on the same trunk could belong
   to the same EVPN instance (EVI), or they could belong to different
   EVIs. This should be purely an administrative choice of the network
   operator.

   6. A given access trunk could have hundreds of EVPL services, and a
   given PE could have thousands of EVPLs configured. It must be
   possible to configure multiple EVPL services within the same EVI.

Aren't the above two the same?

   8. EPL-LAN and EVP-LAN are possible on the same system and also ESIs
   can be shared between EVPL and EVP-LANs.

I guessed what EPL-LAN and EVP-LAN are. They should be listed in the terminology section.

   ... For this service interface, each VLAN is
   presented by a single VID which means no VLAN translation is allowed.

Perhaps change to "all VLANs are represented by ..."?

   This service interface is a special case of the VLAN bundle service
   interface, where all of the VLANs on the port are mapped to the same
   VPWS service instance identifier.  The procedures are identical to
   those described in Section 6.2.

s/6.2/2.2/

   Contrary to EVPN, in EVPN-VPWS this service interface maps to VLAN-
   based service interface (defined in section 6.1) and thus this
   service interface is not used in EVPN-VPWS.  In other words, if one
   tries to define data-plane and control plane behavior for this
   service interface, he would realize that it is the same as that of
   VLAN-based service.

s/6.1/2.1/

   This document proposes the use of the Ethernet A-D per EVI 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.

Is there any reason to restrict it to 24-bit? Why not make use of all 32 bits?

   ... Finally,
   EVPN may employ data plane local repair mechanisms not available in
   VPWS.

Can you elaboration on the above? What is different from non-EVPN VPWS wrt local repair?

     P      If set to 1 in multihoming single active scenarios, it 
            indicates that the advertising PE is the Primary PE.
            SHOULD be set to 1 for multihoming all active scenarios.

     B      If set to 1 in multihoming single active scenarios, it   
            indicates that the advertising PE is the Backup PE.

It seems that only a P bit is needed here for both single-active and all-active? In either case, local PE can load-balance to those advertising P=1, or setup backup PW towards one of those advertising P=0. The ESI label EC in the per-ES A-D route is not needed at all as the behavior could be purely determined by the P bit alone?

I understand that there is no need to change it at this time, but for my own educational benefit I'd like to confirm my understanding. At least, the following details should be added:

- What's the defined behavior when receiving B=1 for all-active or B=0 for single-active
- What's label value to be put into the ESI label EC (I assume no ESI label is needed)

If my understanding is correct, it may be easier to simply go with a single P bit. Of course, I'm just trying to understand it better, not to push for this change.

   The ESI Bandwidth will be encoded using the Link Bandwidth Extended
   community defined in [draft-ietf-idr-link-bandwidth] and associated
   with the Ethernet AD route used to realize the EVPL services.

Per EVI or per ES route? I assume it's per EVI - better make it clear.
Looks like that a PE includes the community for the other end to request the BW enforcement/accounting from the PSN. Should/could both ends include the community? Does it make sense for the two to signal different BW? I suppose so?

   In the case where PSN resources are not available, the PE receiving
   this attribute MUST re-send its local Ethernet AD routes for this
   EVPL service with the ESI Bandwidth = All FFs to declare that the
   "PSN Resources Unavailable".

Shouldn't we use a different indication that the requested BW is not granted (see comments above)?

   The scope of the ESI Bandwidth is limited to only one Autonomous
   System.

The BW request might be used in two ways:

- request the PSN to "guarantee" the requested BW
- request the other PE to shape/limit the traffic that it sends towards this PE

For the first case, the BW may not be guaranteed across ASes and I assume that's the reason for the limitation in the above quoted text (better to explain it). For the second case, it would be valid even if it's across ASes. In fact, draft-boutros-bess-evpn-vpws-service-edge-gateway has the following:

      - Auto-provision features such as QOS access lists (ACL), tunnel 
        preference, bandwidth, L3VPN on a per head-end interface basis

I assumed that the "auto-provision ... bandwidth" in that draft is more about traffic shaping/limiting by the PE than about bandwidth guarantee by the PSN. If that's the case, then it should be valid even if it's across ASes.

It would help a lot if the draft can elaborate on the use case of the bandwidth community.

7.1 Single-Homed CEs

   Unlike [EVPN],  EVPN-VPWS uses Ethernet AD route advertisements for
   single-homed Ethernet Segments. Therefore, upon a link/port failure
   of this single-homed Ethernet Segment, the PE MUST withdraw the
   associated Ethernet A-D routes.

Better make it clearer by saying "Ethernet AD per EVI route".

7.2 Multi-Homed CEs 

   For a faster convergence in multi-homed scenarios with either Single-
   Active Redundancy or All-active redundancy, mass withdraw technique
   as per [EVPN] baseline is used. A PE previously advertising an
   Ethernet A-D per ES route, can withdraw this route signaling to the
   remote PEs to switch all the VPWS service instances associated with
   this multi-homed ES to the backup PE

Does the PE also withdraw the individual per-EVI AD routes? I assume not; better make it clear.
If that's case, is it desirable to assign non-zero ESIs even for single-home case and advertise per ES AD routes so that mass withdraw can be done? That way when the link comes back up, there is no need to re-advertise those per-EVI routes.

8. VPWS with multiple sites

Might as well move this non-goal to the "requirements" section.

Jeffrey

---

From: "Rabadan, Jorge (Nokia - US)" <[email-masked]>
Date: Thu, 12 May 2016 11:44:16 +0000

Jeffrey,

I’m sure we will fix the editorial changes…
Just wanted to comment on a few questions you had on the VIDs, eth-tags, P/B bits and ES label. Please see in-line with [JORGE].
Thank you!
Jorge

>"remain tagged" is a little unclear to me and RFC 7432 does not talk about it either. Is it that incoming tagging is not changed at all (e.g. double tagged) or is it single tagged with normalized VI…

[JORGE] I think the above text is consistent with RFC7432 for VLAN-based service interfaces (section 6.1). The VLAN that is used for the 1:1 mapping to the service (MAC-VRF in RFC7432 or VPWS service instance here) has to be kept on the imposition PE and ‘possibly’ translated at the disposition PE. The only inconsistency that I see is a MUST here as opposed to a SHOULD in RFC7432. Other than that the text should be good.

>Is there any reason to restrict it to 24-bit? Why not make use of all 32 bits?

[JORGE] 24-bit is consistent with RFC7432 in which the eth-tag can be either a 12 or 24-bit identifier. Also I wouldn’t change it as this point given that we have a few implementations already using 24-bit ethernet tags…

>It seems that only a P bit is needed here for both single-active and all-active? In either case, local PE can load-balance to those advertising P=1, or setup backup PW towards one of those advertisi…

[JORGE] the main point here is that with the P/B bits the implementation at the remote PE doing aliasing or backup functions is greatly simplified:
- The remote PE does not even need to check the single-active bit in the AD per-ES route anymore and forwarding can be purely based on the P/B bits
- If multiple routes for eth-tag 1 are received with P=1, the PE will load-balance
- B bit is absolutely necessary for the backup function. Since there may be more than 2 PEs in the ES, a remote PE needs to know who the primary is and in case of failure on the primary who the backup is, since it will send the traffic right away to it. If there was no B=1, the remote PE wouldn’t know where to send the traffic in case of a failure.

>- What's label value to be put into the ESI label EC (I assume no ESI label is needed)

[JORGE] no ESI label is needed for EVPN VPWS, but remember that the ES may be shared with MAC-VRFs that NEED the ESI label. The ESI label should be as per RFC7432.

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 12 May 2016 13:43:55 +0000

Hi Jorge,

> From: Rabadan, Jorge (Nokia - US) [mailto:[email-masked]]
> Sent: Thursday, May 12, 2016 7:44 AM
> To: Jeffrey (Zhaohui) Zhang <[email-masked]>; BESS <[email-masked]>
> Subject: Re: [bess] FW: WG Last Call (including implem status & shepherd)
> for draft-ietf-bess-evpn-vpws-03
> 
> Jeffrey,
> 
> Just wanted to comment on a few questions you had on the VIDs, eth-tags,
> P/B bits and ES label. Please see in-line with [JORGE].
> Thank you!
> Jorge

I assume other non-editorial questions/comments will be followed up separately :-)

I trimmed text below.

> >"remain tagged" is a little unclear to me and RFC 7432 does not talk
> about it either. Is it that incoming tagging is not changed at all (e.g.
> double tagged) or is it single tagged with normalized VIDs? Is it that for
> both services, the frames are transported as is across the core, and the
> tag alteration is only happening at the disposition PE in case of EVPL?
> 
> [JORGE] I think the above text is consistent with RFC7432 for VLAN-based
> service interfaces (section 6.1). The VLAN that is used for the 1:1
> mapping to the service (MAC-VRF in RFC7432 or VPWS service instance here)
> has to be kept on the imposition PE and ‘possibly’ translated at the
> disposition PE. The only inconsistency that I see is a MUST here as
> opposed to a SHOULD in RFC7432. Other than that the text should be good.

I understand that the text is consistent with RFC7432, but I need some help understanding it. For example, if the ACs are double-tagged, will the traffic be double-tagged as is across the core? If so, there is really no difference between EVPL and EPL wrt traffic across the core (and the only difference is the process on the disposition PE). The way it is written, it is kind of confusing to me.

> [JORGE] 24-bit is consistent with RFC7432 in which the eth-tag can be
> either a 12 or 24-bit identifier. Also I wouldn’t change it as this point
> given that we have a few implementations already using 24-bit ethernet
> tags…

I understand the consistency and the reason for not changing it; but since the tag field is actually no longer VID for EVPN-VPWS, in theory all 32-bit could be used? Just want to confirm my understanding for my own educational benefit.

> >It seems that only a P bit is needed here for both single-active and all-
> active? In either case, local PE can load-balance to those advertising P=1,
> or setup backup PW towards one of those advertising P=0. The ESI label EC
> in the per-ES A-D route is not needed at all as the behavior could be
> purely determined by the P bit alone?
> >
> 
> [JORGE] the main point here is that with the P/B bits the implementation
> at the remote PE doing aliasing or backup functions is greatly simplified:
> - The remote PE does not even need to check the single-active bit in the
> AD per-ES route anymore and forwarding can be purely based on the P/B bits

That's also one of my points, but then the following paragraph gets in the way:

   The usage of the Per ES Ethernet AD route is unchanged from its usage
   in [RFC7432], i.e. the "Single-Active" bit in the flags of the ESI
   Label extended community will indicate if single active or all active
   redundancy is used for this ES.

> - B bit is absolutely necessary for the backup function. Since there may
> be more than 2 PEs in the ES, a remote PE needs to know who the primary is
> and in case of failure on the primary who the backup is, since it will
> send the traffic right away to it. If there was no B=1, the remote PE
> wouldn’t know where to send the traffic in case of a failure.

If a PE sends a route w/o setting P-bit, wouldn't that indicate it is a backup? Why would it bother sending the route if it does not want to be the backup?

> 
> 
> >I understand that there is no need to change it at this time, but for my
> own educational benefit I'd like to confirm my understanding. At least,
> the following details should be added:
> >
> [JORGE] no ESI label is needed for EVPN VPWS, but remember that the ES may
> be shared with MAC-VRFs that NEED the ESI label. The ESI label should be
> as per RFC7432.

The text should make it clear; and I think we're agreeing that there is no need to involve the per-ES route for the purpose of determining single-active vs. all-active. If that is made clear, then my original question/comment becomes moot.

Thanks.
Jeffrey

---

From: "Rabadan, Jorge (Nokia - US)" <[email-masked]>
Date: Thu, 12 May 2016 17:50:45 +0000

Hi Jeffrey,

More in-line.
Thanks.

>I understand that the text is consistent with RFC7432, but I need some help understanding it. For example, if the ACs are double-tagged, will the traffic be double-tagged as is across the core? If s…

[JORGE] Well, EPL maps the entire port to a VPWS whereas EVPL maps a <port,vlan> (or <port,outer-vlan,inner-vlan>) to a VPWS. EPL can be implemented with port-based service interface and EVPL with VLAN-based. Hence the other difference is the ability to translate or not at the disposition PE. I guess we can discuss with the rest of the co-authors and how to clarify it. 

>I understand the consistency and the reason for not changing it; but since the tag field is actually no longer VID for EVPN-VPWS, in theory all 32-bit could be used? Just want to confirm my understa…

[JORGE] In theory yes, however for the practical reasons I said above, I would not change it in the current text.

>   redundancy is used for this ES.

[JORGE] ok, yes, we should clarify it.

>If a PE sends a route w/o setting P-bit, wouldn't that indicate it is a backup? Why would it bother sending the route if it does not want to be the backup?

[JORGE] Let’s assume you have 3 PEs in ES-1 (PE1/2/3) that is a single-active ES. PE4 is a remote PE doing backup function. 
- PE1 is the primary - the winner of the DF election. PE1 sends P=1
- PE2 is the backup - the winner of the DF election (without PE1). PE2 sends B=1.
- PE3 then sends P=B=0. This indicates that PE3 is neither primary nor backup, but the AC is active (if it was oper-down, it would withdraw the route).
- In case of a failure on PE1, PE2 will activate its AC on ES-1 since he wins the new DF election. At the same time, PE4 can immediately send traffic to PE2 as soon as PE1 withdraws the AD routes. PE4 does not even need to wait for the confirmation that PE2 is the new DF. This backup mechanism speeds up convergence big time.
- The mechanism above does not work if PE2 and PE3 send both the same P=B=0, since it case of PE1 failure, PE4 could not send any traffic (it does not know who is the active one in the ES) and would need to wait for PE2 to send P=1.

Hope the above helps a bit?

>The text should make it clear; and I think we're agreeing that there is no need to involve the per-ES route for the purpose of determining single-active vs. all-active. If that is made clear, then m…

[JORGE] There is no need to involve the per-ES route for determining SA/AA at the remote PE, but it is still good to check on the rest of the PEs in the ES. But, OK, I agree it could be clarified. Thanks for the feedback Jeffrey.

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 12 May 2016 18:13:46 +0000

Hi Jorge,

> >If a PE sends a route w/o setting P-bit, wouldn't that indicate it is a
> backup? Why would it bother sending the route if it does not want to be
> the backup?
> 
> [JORGE] Let’s assume you have 3 PEs in ES-1 (PE1/2/3) that is a single-
> active ES. PE4 is a remote PE doing backup function.

I assume PE4 is not "doing backup function" but is just one end of the PW. Or perhaps you mean it needs to decide which of PE1/2/3 is the primary/backup.

> - PE2 is the backup - the winner of the DF election (without PE1). PE2

Hmm ... DF election is for BUM in RFC 7432 and never mentioned in this draft. If it is used for VPWS, it needs to be specified.

The draft says multiple PEs could all set the P/B bits:

   In multihoming single active scenario, a remote PE receiving P=1 from
   more than one PE will select only one 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.

And the decision is based on the receiving PE, not on DF election?

> - PE3 then sends P=B=0. This indicates that PE3 is neither primary nor
> backup, but the AC is active (if it was oper-down, it would withdraw the
> route).

What purpose does the route from PE3 serve?

> - In case of a failure on PE1, PE2 will activate its AC on ES-1 since he
> wins the new DF election.

What does "activate" involve exactly? Just re-advertise the route with P-bit set and B-bit cleared?

> At the same time, PE4 can immediately send
> traffic to PE2 as soon as PE1 withdraws the AD routes. PE4 does not even
> need to wait for the confirmation that PE2 is the new DF. This backup
> mechanism speeds up convergence big time.
> - The mechanism above does not work if PE2 and PE3 send both the same
> P=B=0, since it case of PE1 failure, PE4 could not send any traffic (it
> does not know who is the active one in the ES) and would need to wait for
> PE2 to send P=1.

I don't see any use of the route from PE3. The draft seems to say that both PE1 and PE2 can set the P bit initially and PE4 will pick one to send traffic to. If it picks PE1 and then PE1 withdraws the route, PE4 will then pick PE2?

Jeffrey

---

From: "Rabadan, Jorge (Nokia - US)" <[email-masked]>
Date: Thu, 12 May 2016 18:27:42 +0000

HI Jeffrey,

>I assume PE4 is not "doing backup function" but is just one end of the PW. Or perhaps you mean it needs to decide which of PE1/2/3 is the primary/backup.

[JORGE2] by “doing backup function” I mean that PE4 sets up a destination to PE1 with a backup to PE2. Aliasing and Backup functions are effectively done by the remote PEs based on the information advertised by the PEs in the ES, right?

>Hmm ... DF election is for BUM in RFC 7432 and never mentioned in this draft. If it is used for VPWS, it needs to be specified.

[JORGE2] In VPWS DF election is needed for single-active. The NDF will block the AC for the service. For all-active there is no DF, of course, since there is no BUM ;-)

>And the decision is based on the receiving PE, not on DF election?

[JORGE] This is BGP, there are always transient situations, so it may happen that even in single active you get more than one P=1 or B=1, so you need to say what to do in that case, right? In a steady situation, in single-active MH, only the DF MUST send the P=1 since it is only the DF the one unblocking the AC in the ES.

>What purpose does the route from PE3 serve?

[JORGE] since the AC is oper-up on PE3, PE3 needs to send the route. At PE4 you know that PE3’s AC in the ES is good, but simply neither primary nor backup.

>What does "activate" involve exactly? Just re-advertise the route with P-bit set and B-bit cleared?

[JORGE] unblock Tx/Rx on the AC… and later readvertise the route with the new bits.

>I don't see any use of the route from PE3. The draft seems to say that both PE1 and PE2 can set the P bit initially and PE4 will pick one to send traffic to. If it picks PE1 and then PE1 withdraws t…

[JORGE] This is single active, so only one can transmit/receive to/from the CE. So only that one should send P=1.

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 12 May 2016 19:06:25 +0000

Hi Jeffrey,

This is a draft based on RF7432 and as such we are expecting tag
manipulation wrt vlan-based service to be consistent with RFC 7432.
Additional comments below Š

On 5/12/16, 11:27 AM, "BESS on behalf of Rabadan, Jorge (Nokia - US)"
<[email-masked] on behalf of [email-masked]> wrote:

>HI Jeffrey,
>
>
>On 5/12/16, 8:13 PM, "BESS on behalf of EXT Jeffrey (Zhaohui) Zhang"
><[email-masked] on behalf of [email-masked]> wrote:
>
>>Hi Jorge,
>>
>>> [JORGE] Let¹s assume you have 3 PEs in ES-1 (PE1/2/3) that is a single-
>>I assume PE4 is not "doing backup function" but is just one end of the
>>PW. Or perhaps you mean it needs to decide which of PE1/2/3 is the
>>primary/backup.
>
>[JORGE2] by ³doing backup function² I mean that PE4 sets up a destination
>to PE1 with a backup to PE2. Aliasing and Backup functions are
>effectively done by the remote PEs based on the information advertised by
>the PEs in the ES, right?

Just as in RFC7432, Eth A-D per ES indicates what kind of multi-homing is
associated with this ES (all-active versus single-active). The P/B bits in
Eth A-D per EVI, indicates active/backup role per instance and its usage
is recommended for multi-homing but not needed for dual-homing.

>>Hmm ... DF election is for BUM in RFC 7432 and never mentioned in this
>>draft. If it is used for VPWS, it needs to be specified.
>
>[JORGE2] In VPWS DF election is needed for single-active. The NDF will
>block the AC for the service. For all-active there is no DF, of course,
>since there is no BUM ;-)

Yes, forwarding decision is based on VLAN tag and not based on MAC
addressses, so there is no notion of known unicast versus BUM traffic here.

>[JORGE] This is BGP, there are always transient situations, so it may
>happen that even in single active you get more than one P=1 or B=1, so
>you need to say what to do in that case, right? In a steady situation, in
>single-active MH, only the DF MUST send the P=1 since it is only the DF
>the one unblocking the AC in the ES.

We should add some text to the draft to indicate ³reception of multiple
P=1² is for transient situation.

>[JORGE] since the AC is oper-up on PE3, PE3 needs to send the route. At
>PE4 you know that PE3¹s AC in the ES is good, but simply neither primary
>nor backup.

E.g., it can be considered as 2nd backup.

-Ali

>[JORGE] unblock Tx/Rx on the ACŠ and later readvertise the route with the
>new bits.
>
>>
>>I don't see any use of the route from PE3. The draft seems to say that
>>both PE1 and PE2 can set the P bit initially and PE4 will pick one to
>>send traffic to. If it picks PE1 and then PE1 withdraws the route, PE4
>>will then pick PE2?
>
>[JORGE] This is single active, so only one can transmit/receive to/from
>the CE. So only that one should send P=1.
>
>>
>>Jeffrey

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Thu, 12 May 2016 19:12:57 +0000

Hi Jorge, Ali,

> block the AC for the service.

> the CE. So only that one should send P=1.

If I understand it correctly, the draft should specify the following:

- Use of DF election to determine primary/backup (curious how it is done for plain old EVPN), including backup DF concept
- Only the current DF should set the P-bit
- Only the current BDF should set the B-bit
- P=B=1 is invalid
- There could be transient situations where multiple P=1 and/or multiple B=1 routes co-exist. Some heuristic should be used to pick which one to use to avoid traffic discard at the other end.

For the P=B=0 case - the receiving router can't use it anyway until its P/B is changed, right? If you want to use it as 2nd backup, the spec needs to point it out.

Thanks.

Jeffrey

> Sent: Thursday, May 12, 2016 2:28 PM
> >I assume PE4 is not "doing backup function" but is just one end of the PW.
> Or perhaps you mean it needs to decide which of PE1/2/3 is the
> primary/backup.
> 
> [JORGE2] by “doing backup function” I mean that PE4 sets up a destination
> to PE1 with a backup to PE2. Aliasing and Backup functions are effectively
> done by the remote PEs based on the information advertised by the PEs in
> the ES, right?
> 
> >
> happen that even in single active you get more than one P=1 or B=1, so you
> need to say what to do in that case, right? In a steady situation, in
> PE4 you know that PE3’s AC in the ES is good, but simply neither primary
> nor backup.
> 
> >
> both PE1 and PE2 can set the P bit initially and PE4 will pick one to send
> traffic to. If it picks PE1 and then PE1 withdraws the route, PE4 will
> then pick PE2?
>

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 12 May 2016 19:21:02 +0000

Hi Jeffrey,

On 5/12/16, 12:12 PM, "BESS on behalf of Jeffrey (Zhaohui) Zhang"
<[email-masked] on behalf of [email-masked]> wrote:

>- Use of DF election to determine primary/backup (curious how it is done
>for plain old EVPN), including backup DF concept

In EVPN, there is no explicit primary/backup, we just tell the remote PE
that this ES operate in all-active or single-active. In case of
single-active, when a remote PE receives a MAC from one of the PE in the
redundancy group, it know that this PE is the primary PE. The back-up PE
is the other PE if the ES is dual-homed. If the ES is multi-homed, there
RFC7432 would need this EC as well.

>- Only the current BDF should set the B-bit

Correct. And these can be explicitly spelled out.

>- There could be transient situations where multiple P=1 and/or multiple
>B=1 routes co-exist. Some heuristic should be used to pick which one to
>use to avoid traffic discard at the other end.

Agreed we need some additional text here to explain what is expected.

>
>For the P=B=0 case - the receiving router can't use it anyway until its
>P/B is changed, right? If you want to use it as 2nd backup, the spec
>needs to point it out.

That¹s was the plan initially but we simplified it. Still there should be
no issue with P=B=0.

Cheers,
Ali

>> >> >If a PE sends a route w/o setting P-bit, wouldn't that indicate it
>>is
>> a
>>PW.
>>effectively
>> >> - PE2 is the backup - the winner of the DF election (without PE1).
>>PE2
>> >> sends B=1.
>> >
>>you
>> >What does "activate" involve exactly? Just re-advertise the route with
>>P-
>> bit set and B-bit cleared?
>> 
>>send

---

From: Sami Boutros <[email-masked]>
Date: Sat, 14 May 2016 19:22:25 +0000

Hi Jeffrey,

Thanks for your comments, Please see responses inline.

Hi,

   ... eliminates the

[Sami]
We do have a section 5 on comparison between PW signaling and EVPN, Actually, the draft is proposing a mechanism that eliminates PW signaling for P2P service using EVPN, so not sure how can we remove this?

[Sami]

   ... and provides

[Sami]
Please have a look at section 5.
[Sami]

[Sami]

There is no inconsistency, the text you refer to in [7432] is part of the explanation of the ESI or ethernet segment identifier.
in [7432] Page 31, it mentions exactly what we are referring to above. "On the other hand, a unique label per <ESI, Ethernet tag> allows an egress PE to forward a packet that it receives from another PE, to the connected CE, after looking up only the MPLS labels without having to perform a MAC lookup.”

[Sami]

[Sami]

From one PE point of view an ES is a single link.[7432] is not denying this.

[Sami]

   ... EVPL can

[Sami]
Those will be different routes as per [7432]. We are not defining any new behavior.

[Sami]

[Sami]
Transport paths carry the service traffic over the MPLS transport network, we are simply mentioning this, those paths can for sure be asymetric as the per the nature of MPLS LSPs. I am not really sure if we should delete this.
[Sami]

[Sami]
Ok, will change this.
[Sami]

   For EVPL

[Sami]

We will change the MUST to a SHOULD to be consistent with [7432] Vlan based services section 6.1.

[Sami]

Aren't the above two the same?
[Sami]
They are not the same, [5] talks about multiple EVPL on the same trunk interface belonging to different EVI(s), and [6] talks about EVPL on a multiple access interfaces belonging to the same EVI.
[Sami]

[Sami]
Sure will do.
[Sami]

[Sami]

Not sure I get that, you mean all VLANs are presented by different VIDs?

[Sami]

s/6.2/2.2/

[Sami]
This is section 6.2 in [7432], will fix that.
[Sami]

s/6.1/2.1/

[Sami]
Same as above.
[Sami]

[Sami]
To be consistent with [7432] and current implementations.
[Sami]

   ... Finally,

[Sami]
In EVPN, on failure we can direct traffic to the backup PE using a backup label signaled, PW redundancy doesn’t have that.
[Sami]

[Sami]
There is not PW getting setup here.
[Sami]

[Sami]
The draft already explicitly mention that in single active, traffic will not start flowing until the remote PE, receives from at least one of the PE(s) in the single active redundancy an Ethernet-AD route with the P bit set. Identifying the backup PE will help to failover quicker at the remote PE. We have spent weeks as co-authors on this section before, and to be quite honest, I am not sure if any new text on this will clarify!
[Sami]

[Sami]
Will do.
[Sami]

[Sami]
This BW will be symmetric, we can make that explicit in the doc.
[Sami]

Shouldn't we use a different indication that the requested BW is not granted (see comments above)?
[Sami]
Not sure, I get this, if it can’t be granted BW in one direction, are you saying may be the other direction will get it?
[Sami]

[Sami]
We are not proposing any Shaping, or filters for traffic entering the EVPN-VPWS service, it is a simple BW negotiation, that can be provisioned single sided.
[Sami]

7.1 Single-Homed CEs

[Sami]
Sure will do.
[Sami]

7.2 Multi-Homed CEs

Does the PE also withdraw the individual per-EVI AD routes? I assume not; better make it clear.
[Sami]
It will withdraw as per [7432], we are not defining any new behavior.
[Sami]

If that's case, is it desirable to assign non-zero ESIs even for single-home case and advertise per ES AD routes so that mass withdraw can be done?

[Sami]
Correct, an operator may chose that. We are not precluding this.
[Sami]

That way when the link comes back up, there is no need to re-advertise those per-EVI routes.

[Sami]
Will remove this section, and finally, thanks for all your comments.

Sami

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 16 May 2016 21:18:36 +0000

Hi Sami,

Please see zzh> below. I trimmed some text.

   ... eliminates the

Zzh> It’s the mentioning of “single-segment and multi-segment” that led to my comments. If that were not there, it would not have been an issue. For example, I had expected some text on how multi-segment PW is realized in EVPN-VPWS. If you don’t plan to talk about that, then just don’t bring it up. For example, simply say “eliminates the need for traditional way of PW signaling”.

   ... and provides

[Sami]

Zzh> When it comes to PIC, the closed thing I can find in section 5 is the following:

   Upon link or node failure, EVPN can trigger failover with the
   withdrawal of a single BGP route per EVPL service or multiple EVPL
   services, whereas with VPWS PW redundancy, the failover sequence
   requires exchange of two control plane messages: one message to
   deactivate the group of primary PWs and a second message to activate
   the group of backup PWs associated with the access link. Finally,
   EVPN may employ data plane local repair mechanisms not available in
   VPWS.

The first part (before “Finally”) talks about the two control plane message – so that’s not “data-plane” (the text I had question about talks about “data-plane prefix independent convergence). The second part talks about “data plane local repair” but has no details that I was looking for.

[Sami]

Zzh> My point is about the relationship between ES and AC/link/port (see below) and not about whether mac lookup is done or not.

[Sami]

[Sami]

Zzh> My original point was that, RFC 7432 defines a ES as “set of links” for multi-homing case so “between a single pair of ESes” here may be a little misleading. I am not going to split hair on this – but please see more below on this to understand my intention and a simple fix (again it’s up to you and I am not insisting).

[Sami]

   ... EVPL can

Zzh> So ES here is loosened to refer both multi-homing case and single-homing case (again this has nothing to do with mac lookup or not). Doing a search in RFC 7432 reveals that 7432 also uses it in a somewhat loose manner (e.g. section 6.1). I am not going to split hair, but given that you have a terminology section for terms like MPLS/MAC/EVI, you might as well add ES there and point out that it may be used for single-homing case as well. BTW – it would be better to have the terminology section before (or right at the beginning of) the introduction (currently it’s after the introduction paragraphs).

[Sami]

Zzh> Since the Ethernet Tag field identifies service instance and the two ends of the same PW could use different values, we cannot correlate routes using [7432] criteria. However, I will withdraw my original question, since “MUST have the same value” in the above text could refer to both the ESI and TAG fields (I originally I thought that it referred to the Tag field only).

[Sami]

[Sami]

Zzh> In all cases (way beyond EVPN) all traffic will always follow transport path ☺ That’s what was causing trouble for me. My personal habit is to remove text that only adds confusion (I did not see other purpose of that text in this case) so I said “perhaps delete it”, but I am not going to split hair here – consider my comment addressed/withdrawn.

[Sami]

   For EVPL

[Sami]

Zzh> It’s not the MUST that I am having trouble with. It’s the “remain tagged” that is not clear to me (7432 is not clear to me either). As I mentioned in the other exchange with Jorge on this – is it that in both cases the Ethernet frames are transported in the core as is?

If both cases are “transported as is” (in the core – I understand that in EVPL case translation may be done on the egress PE), then it is confusing to me to say “remain tagged” for EVPL but “as is” for EPL. Better use consistent wording.

If “remain tagged” means that traffic in the core is using “normalized VID” (e.g., double tagged incoming packets become single tagged), then the word “remain” is not clear enough.

[Sami]

Zzh> The first sentence of [5] talks about “multiple EVPL service VLANs on the same trunk could belong  to the same EVPN instance (EVI)”. The second sentence talks about them belonging to different EVIs. Both cases (same of different EVIs) are covered.

Zzh>  The first sentene of [6] talks about “A given access trunk …”, i.e. the “same trunk interface” as covered in [5]. If the intention is to emphasize EVPLs on different access trunks, then perhaps delete the “A given access trunk …” text:

   6. A given PE could have thousands of EVPLs configured. It must be
   possible to configure multiple EVPL services within the same EVI,
   regardess whether they’re on the same or multiple access interfaces.

[Sami]

Zzh> I misunderstood the text earlier. All set on this one.

[Sami]

   ... Finally,

[Sami]

Zzh> If I understand it correctly, switching to a backup label (either single-active or all-active) is triggered by the withdraw of the per-ES route. It’s PIC for sure but that does not look like “data plane local repair” to me. Besides, that’s already talked about before the “finally” sentence, so the “finally” sentence would be redundant.

[Sami]

[Sami]

Zzh> The fact that we’re here again shows the need for some clarification. Being someone who does not have perfect understanding of every detail of EVPN (I assume this would be the profile of most people, especially for some developers who may implement this feature for another vendor in the future), my confusion came from the following, and I hope the document will clear that right off the bat:

1.  The fact that primary PE in case of single-active is determined by DF election is only casually mentioned in RFC 7432 in one place (I missed that before) and not in “8.5.  Designated Forwarder Election”:

14.1.1.  Single-Active Redundancy Mode

   …  It should be noted that the primary PE for a given <ES,

   VLAN> (or <ES, VLAN bundle>) is the DF for that <ES, VLAN> (or <ES,

   VLAN bundle>).

2.      It was not clear that the multiple P=1 is transient and it gave me the impression that the receiving router can pick anyone of them to send traffic to (there may be heuristics that can lead to a good choice).

3.      Current text does not explain how a P=B=0 route is used.

[Sami]

[Sami]

Zzh> I suppose there could be use cases where the BW is asymmetric. There is no need to restrict that.

[Sami]

Zzh> Right. RSVP-TE BW is one direction. It could be that a service only need 4M in one direction and 10M in the other, and the BW reservation in the network could be satisfied in one direction but not the other.

[Sami]

[Sami]

Zzh> Using the draft-boutros-bess-evpn-vpws-service-edge-gateway auto-provisioning example (at least that’s how I understand it) – it can be provisioned on the AN side so that the SN can shape/limit the traffic entering the EVPN-VPWS. In that case, is it necessary that “The scope of the ESI Bandwidth is limited to only one Autonomous  System”?

Zzh> Basically, my points about BW are:

- It seems that it does not have to be limited to BW reservation in the network; it could be simply traffic shaping/limiting on the PE into the network. Therefore it does not have to be limited to only one AS. For example, the nework could be using LDP and there is no way to reserve BW but shaping is still desired on the PEs.

- It seems that the BW signaling does not have to be symmetric, and even if it’s symmetric and it’s for BW reservation, failure in one direction should be independent of the other direction, so the failure indication should be done separately. For example, originally both ends signal 10M. PE1 fails the reservation but PE2 succeeds. Or it could be that initially both succeeds but later the TE tunnel from PE1 fails. Is it desirable for PE1 to signal BW=FF, which (I assume) would lead to PE2 to cancel its successful BW reservation? If a different failure indication is used, we won’t have this problem.

[Sami]

7.2 Multi-Homed CEs

Zzh> Now that you mention it, I did a search in RFC 7432 and the only place I can found about withdrawing per-EVI route is the following:

   When an Ethernet tag is decommissioned on an Ethernet segment, then

   the PE MUST withdraw the Ethernet A-D per EVI route(s) announced for

   the <ESI, Ethernet tags> that are impacted by the decommissioning.

All other mentioning of withdrawing are about mac/ip and per-ES AD route. I think it’s better to explicitly point out in this section that per-EVI routes are not withdrawn (so that when the link comes back only a single per-ES route is advertised) when the link goes down.

[Sami]

[Sami]

Zzh> The spec should allow it so that a vendor can implement it so that an operator can do it ☺

Thanks!
Jeffrey

[Sami]

---

From: Sami Boutros <[email-masked]>
Date: Wed, 18 May 2016 17:01:46 +0000

Hi Jeffrey,

Please see responses inline in green.

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]<mailto:[email-masked]>>
Date: Monday, May 16, 2016 at 2:18 PM
To: Sami Boutros <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [bess] FW: WG Last Call (including implem status & shepherd) for draft-ietf-bess-evpn-vpws-03

Hi Sami,

   ... eliminates the

   ... and provides

[Sami]

Sami:
The local repair here will be done by the primary PE o(on local AC down) using the label advertised in per EVI EAD route advertised by the backup PE will direct the traffic to backup PE, I will add this text to clarify this, is this ok?
Sami:

Sami: Sure will remove.

[Sami]

[Sami]

[Sami]

[Sami]

   ... EVPL can

Sami: Will add to the terminology section that an ES on a PE refer to the link attached to it, this link can be part of a set of links attached to different Pes in multi home cases, or could be a single link in single home cases. How does that sound?

[Sami]

Sami: It is the Ethernet tag field only identifies both ends of the PW (VPWS instance) if one side of the PW is multihomed then we set the ESI field on that side only.

[Sami]

[Sami]

Sami: Ok.

[Sami]

   For EVPL

[Sami]

Sami: Shall we say, for EVPL, at least one VID should be present on the packet, and the VID manipulation is a local matter.

[Sami]

Sami: Sure will update the text.

[Sami]

Sami: Cool.
[Sami]

   ... Finally,

[Sami]

Sami: As mentioned above, the primary PE detecting a local AC failure, can direct the traffic to the backup PE using the backup PE per EVI Ethernet-AD route label for the same VPWS instance, the primary PE will still send the withdraw for the per-ES route to the remote Pes.

[Sami]

[Sami]

   VLAN bundle>).

Sami: The authors are agreeing on some text to clarify the DF election usage here, and the P/B bits assignment, will update the draft with it shortly.
[Sami]

[Sami]

Sami: I will add text to allow that.

[Sami]

Sami: however if one side BW is not granted, we still bring the PW up.

[Sami]

[Sami]

Sami: The issue here is that we are using the BW idr draft, and there is no shaping defined there, and we don’t plan to define a new attribute for this, perhaps we can add that to a new draft?

Sami: Agreed the failure indication, shall be different, given that we are bringing up the PW even if the BW can’t be granted.

[Sami]

7.2 Multi-Homed CEs

Sami: Actually per EVI EAD routes must be withdrawn too

[Sami]

[Sami]

Sami: Will add to the terminology section that ESI can be set for single-home case too.

Thanks,

Sami

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 18 May 2016 18:58:32 +0000

Hi Sami,

Some text snipped … Please see zzh2> below.

Sami:

Zzh2> So you’re talking about “egress link protection” – in flight traffic from the other end arriving on the primary PE will be redirected to the backup PE if the AC is down on the primary PE. This definitely needs some clarifying text, and it’s better to say egress link protection instead of data plane local repair?

Zzh2> Yes that’s good.

   For EVPL

[Sami]

Zzh2> Because RFC7432 is not clear about “remain tagged” (for example, see my above questions), it would be good to spell out the details, not just “at least one VID should be present”?

[Sami]

Zzh2> Good point that BW is not equal to shaping parameters; however, existing PW specifications do not seem to have BW related stuff and one actual customer use case I am aware of with EVPN VPWS actually does involve shaping; so maybe it’s better to take care of this in the base spec? It’s just a new attribute anyway.

[Sami]

7.2 Multi-Homed CEs

Zzh2> RFC7432 only says it’s withdrawn when a tag is “decommissioned”; if the intention is to withdraw when the AC goes down, it should be explicitly spelled out (it’s not in RFC 7432 but should be added to this draft if that’s the right behavior). However, isn’t it better to keep those routes around so that they don’t need to be re-advertised when the link comes back up?

Thanks!
Jeffrey

---

From: Sami Boutros <[email-masked]>
Date: Wed, 18 May 2016 20:23:26 +0000

Hi Jeffrey,

Few comments inline next to Sami2:

Sami:

Sami2: Will do.

Zzh2> Yes that’s good.

   For EVPL

[Sami]

Sami2: Can you please suggest some text? Not sure what extra details needed?

[Sami]

Sami2: We can suggest to the authors of the idr BW draft adding the shaping aspect.

[Sami]

7.2 Multi-Homed CEs

Sami2: Sure, I will not need to add any text then, since we will not be changing any behavior, no?

Thanks,

Sami

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Mon, 23 May 2016 20:10:27 +0000

Sami,

Please see zzh3> below. I’ve trimmed some text.

From: Sami Boutros [mailto:[email-masked]]
Sent: Wednesday, May 18, 2016 4:23 PM
To: Jeffrey (Zhaohui) Zhang <[email-masked]>
Cc: [email-masked]
Subject: Re: [bess] FW: WG Last Call (including implem status & shepherd) for draft-ietf-bess-evpn-vpws-03

Hi Jeffrey,

Zzh3> Let me do more digging to confirm my understanding and see if I could come up with some text.

Zzh3> The use case in draft-ietf-idr-link-bandwidth seems to be unrelated to shaping at all, so it may be better to define it in this document to reduce the dependency?

Zzh3> Given the following two facts:

- I had to do a search to be sure that RFC 7432 did not require the withdraw when the ES goes down
- You for a moment thought that RFC 7432 required that

It would be better to explicitly call it out in this document. But this is just a suggestion and it does not block the progress.

Thanks!
Jeffrey

---

From: Martin Vigoureux <[email-masked]>
Date: Tue, 24 May 2016 10:05:59 +0200

WG, Authors,

we are past the deadline for this WG LC.
I am still waiting for statements from authors.
In the meantime could you update the draft to reflect the necessary 
changes which were identified as part of the WG LC.
In doing so, could you trim the list of authors to max 5 on the first 
page and make sure the e-mail addresses are all correct.

Beyond that we are ready to go as we have knowledge of implementations.

Thank you
-m

---

From: Jeff Tantsura <[email-masked]>
Date: Wed, 25 May 2016 11:23:24 -0700

Hi Martin,

I’m not aware of any relevant undisclosed IPR.

Thanks,
Jeff

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 27 May 2016 21:41:03 +0000

Hi Sami,

I thought about this BW topic further, and have the following question:

- Even for the originally stated purpose, i.e. for PE1 to request PE2 to request BW reservation in the network, why does it have to be signaled from PE1? Why can’t you provision PE2 to request that BW reservation? You need to provision service identifier on both PE1 and PE2 anyway, so you might as well add BW provisioning on PE2.

I understand that draft-boutros-bess-evpn-vpws-service-edge-gateway-02 does specify that the service node could skip the service identifier configuration and automatically signals the one that it receives from the access node. In that case, signaling qos/bw parameters from the access node makes sense (in that there is no need for configuration on the service node side).

So, perhaps the entire BW or shaping signaling stuff could be moved from the base EVPN-VPWS draft to draft-boutros-bess-evpn-vpws-service-edge-gateway?

Jeffrey

---

From: Sami Boutros <[email-masked]>
Date: Fri, 27 May 2016 16:07:02 -0700

I will be updating the draft with the necessary changes.

Thanks,

Sami
> On May 24, 2016, at 1:05 AM, Martin Vigoureux <[email-masked]> wrote:
> 
> WG, Authors,
> 
> In the meantime could you update the draft to reflect the necessary changes which were identified as part of the WG LC.
> In doing so, could you trim the list of authors to max 5 on the first page and make sure the e-mail addresses are all correct.
>

---

From: Sami Boutros <[email-masked]>
Date: Mon, 30 May 2016 01:35:15 +0000

Hi Jeff,

I am ok to remove the BW section, adding other authors for their I/p.

Thanks,

Sami
Date: Friday, May 27, 2016 at 2:41 PM

Hi Sami,

Jeffrey

---

From: "Rabadan, Jorge (Nokia - US)" <[email-masked]>
Date: Mon, 30 May 2016 03:44:36 +0000

Sami,

I'm ok to remove it too.
Thanks.
Jorge

On 5/29/16, 6:35 PM, "Sami Boutros" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jeff,

Thanks,

Sami

Hi Sami,

Jeffrey

---

From: Jeff Tantsura <[email-masked]>
Date: Sun, 29 May 2016 21:41:07 -0700

We have been talking about removing it since we started...

Regards,
Jeff

> On May 29, 2016, at 8:44 PM, Rabadan, Jorge (Nokia - US) <[email-masked]> wrote:
> 
> Sami,
>  
> I'm ok to remove it too.
> Thanks.
> Jorge
>  
> On 5/29/16, 6:35 PM, "Sami Boutros" <[email-masked]> wrote:
>  
> Hi Jeff,
>  
> From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
> To: Sami Boutros <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Tue, 31 May 2016 14:17:29 +0000

Sami,

                My two cents ;) These constraints will most likely be managed by the SP in an orthogonally from the creating of PWs.. At least that would be my approach.. So, goes something like, service requested, check available resources ( BW, Ports, latency, etc… ) select endpoints that meet the criteria.

Jim Uttaro

From: BESS [mailto:[email-masked]] On Behalf Of Jeffrey (Zhaohui) Zhang
Sent: Friday, May 27, 2016 5:41 PM
To: Sami Boutros <[email-masked]>
Cc: [email-masked]
Subject: Re: [bess] FW: WG Last Call (including implem status & shepherd) for draft-ietf-bess-evpn-vpws-03

Hi Sami,

Jeffrey

---

From: Sami Boutros <[email-masked]>
Date: Tue, 31 May 2016 16:02:24 +0000

Thanks Jim and Jeffrey for the comments,

We will move the BW section to the service-edge-gateway draft specially for the single side signaling and we will mention that the BW can be handled orthogonally too.

Thanks,

Sami
From: "UTTARO, JAMES" <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, May 31, 2016 at 7:17 AM
To: "Jeffrey (Zhaohui) Zhang" <[email-masked]<mailto:[email-masked]>>, Sami Boutros <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [bess] FW: WG Last Call (including implem status & shepherd) for draft-ietf-bess-evpn-vpws-03

Sami,

Jim Uttaro

Cc: [email-masked]<mailto:[email-masked]>

Hi Sami,

Jeffrey

---

From: <[email-masked]>
Date: Wed, 1 Jun 2016 08:55:04 +0200

Hi Martin,

I am not aware of any relevant undisclosed IPR.

Thomas

-----Ursprüngliche Nachricht-----
Von: BESS [mailto:[email-masked]] Im Auftrag von Martin Vigoureux
Gesendet: Donnerstag, 5. Mai 2016 12:54
An: BESS
Betreff: [bess] WG Last Call (including implem status & shepherd) for draft-ietf-bess-evpn-vpws-03

Hello Working Group,

¤ Please read the document if you haven't read the most recent version yet, and send your comments to the list, no later than *20th of May*.
Note that this is *not only* a call for comments on the document, but also a call for support (or not) publishing this document as a Proposed Standard RFC.

¤ We are also polling for knowledge of any undisclosed IPR that applies to draft-ietf-bess-evpn-vpws-03, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details) prior to moving forward.
If you are listed as a document Author or 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.
Two IPR disclosures exist against previous revisions of this document [2].

¤ We are also polling for knowledge of implementations of part or all of what this document specifies. This information is expected as per [3]. 
Please inform the mailing list, the chairs, or only one of the chairs.

Thank you
M&T