Subject: More comments about draft-boutros-l2vpn-evpn-vpws-04

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Thu, 24 Jul 2014 04:55:12 +0000

Sami, as discussed:

I am personally glad to see the way this draft has evolved. I believe it
is now in the right direction after some issues, especially in the first 2
versions. I support this work for WG adoption.

Some comments though:

- Minor: all the references to “E-VPN” should be changed to “EVPN”
- Section 1.2 - extra missing requirements:
.- EP-LAN and EVP-LAN services could be supported on the same PE and on
the same ports
.- ESIs could be shared among VPWS and EVPN services

- Some differences with EVPN that should be clarified:

a) VPWS Service instance identifier encoded in the eth-tag: according to
EVPN either a 12-bit or a 24-bit identifier is encoded in this 4-byte
field.
.- How many bits does the VPWS identifier have? 12/24? if it is 32 it has
to be explicitly said (the slides infer you can use the 4 bytes).
.- Since the scope of the VPWS identifier is the EVI, 12-bits is enough,
right?. This allows us to use this in the same way as the EVPN VLAN-aware
bundle mode and use the VPWS identifier as a normalized VID that we can
include in the MPLS-encapsulated frames to carry the customer pbits
transparently. This can be equivalent to the vc-type VLAN in PWs.

b) single-active MH behavior:
.- all-active MH behavior should be equivalent to EVPN (except for
split-horizon which does not make sense in VPWS) hence there is no need to
document.
.- in single-active MH the behavior is “slightly" different and MUST be
documented: 
In EVPN, for single-active MH, the two MH PEs (PE1 and PE2 for ESI1) will
send both their per ESI AD routes and per EVI AD routes. When the DF (PE1)
sends MAC1/ESI1/next-hop=PE1, the remote PE3 will install MAC1 with
next-hop = PE1 and backup next-hop = PE2.
In VPWS the DF will obviously not send a MAC route, hence the question is:
how does PE3 know whether to send the traffic for the VPWS id to PE1 or
PE2? the non-DF for the VPWS id (PE2) should not - in this case - send a
per EVI AD route for ESI1. Only the per-ESI AD route.
.- Section 4 should be clarified, specifying the handling failure
situations for all-active and single-active.

Thank you.
Jorge

From:  <Rabadan>, Jorge Rabadan <[email-masked]>
Date:  Friday, November 15, 2013 at 1:04 PM
To:  "Ali Sajassi (sajassi)" <[email-masked]>, "[email-masked]"
<[email-masked]>
Cc:  "Henderickx, Wim (Wim)" <[email-masked]>
Subject:  The use of ESI in draft-boutros-l2vpn-evpn-vpws-02

>Hi Sami and Ali,
>
>As I mentioned during the IETF-88 I believe we have an issue with the
>definition of the ESI in this draft.
>There are not many details in the draft, but if I understand the
>document, the ESI of the A-D routes is encoded with the
>{system-MAC+AC-ID} value. While this “might” be interesting for packing
>many AC-IDs in the same update, it has many issues related
> to the current EVPN definition. This is my view:
>
>1. Service Providers will implement EVPN VPWS for two main reasons: a)
>they already have EVPN for ELAN services and want to use the same
>technology for VPWS and b) all-active multi-homing. With the current EVPN
>VPWS definition, procedures and operations are
> different from the ones defined for EVPN, so the motivation diminishes.
>2. SPs will deploy EVPN and EVPN-VPWS in the same network. It is then
>very important to have an homogeneous ESI definition that allows
>auto-derived and configured ESIs. The EVPN-VPWS definition of the ESI
>clashes with this concept, as you indicated in Vancouver.
>3. For all-active multihoming, I assume the ESI must be the same for a
>given CE in the multi-homed PEs. If so, the current ESI definition makes
>the ESI auto-derivation very complex.
>4. Why encoding the AC-ID in the ESI? is it the purpose to be able to
>pack up to 4k AC-Ids in the same NLRI with the same RT?? if so:
>
>* There is no longer an RT per VPWS hence you can’t take advantage of
>RT-constraint, etc.
>* I don’t see many benefits, unless all the AC-IDs are originated and
>terminated only in two PEs… which is a debatable use-case.
>
>
>
>My proposal would be:
>
>* Use an homogeneous ESI definition in both EVPN and EVPN-VPWS. This
>means ESI=0 for single-home CEs, non-zero for multi-homed CEs.
>* Auto-derive the RT from the EVI identifier, each VPWS will have a
>different one. Auto-derive the RD as well.
>* Define single-active MH and all-active MH in-line with EVPN
>* Allow the use of A-D routes per ESI for mass withdraw.
>
>* This can be also useful in the case of single-homed CEs.
>* Also, if regular EVPNs co-exist in the same ESI, the same A-D routes
>per ESI will be used for EVPN and VPWS. They will just use the RTs of all
>the services irrespective of being ELAN/LINE.
>
>
>* This would be a solid and basic implementation. From this point on, we
>can expand the technology, but to me the above points should be the
>foundation. 
>
>I believe this new proposal makes things easier, and has more advantages
>compared to the existing draft. Please let me know if I am missing
>something.
>
>If you agree with this, I am willing to work with you in the draft with
>sections or paragraph or whatever way you consider. I’m open to
>suggestions.
>
>Thank you.
>Jorge

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Thu, 24 Jul 2014 14:22:44 +0000

"Sami, as discussed:

I am personally glad to see the way this draft has evolved. I believe it
is now in the right direction after some issues, especially in the first 2
versions. I support this work for WG adoption."

+1

Jim Uttaro

-----Original Message-----
From: L2vpn [mailto:[email-masked]] On Behalf Of Rabadan, Jorge (Jorge)
Sent: Thursday, July 24, 2014 12:55 AM
To: Sami Boutros (sboutros); [email-masked]
Subject: More comments about draft-boutros-l2vpn-evpn-vpws-04

Sami, as discussed:

Some comments though:

Thank you.
Jorge

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 24 Jul 2014 14:58:04 +0000

Hi Jorge,

Thanks for your comments, please refer to my in-line reply below ...

On 7/24/14 12:55 AM, "Rabadan, Jorge (Jorge)"
<[email-masked]> wrote:

>- Minor: all the references to ³E-VPN² should be changed to ³EVPN²

Agreed.

>.- ESIs could be shared among VPWS and EVPN services

Yes, the wording should be "ESI can be shared among EVPL and EVP-LAN
services."

>transparently. This can be equivalent to the vc-type VLAN in PWs.

It should be 24-bit. We don't want to unnecessarily create EVIs because we
4K scale limit. It should be noted that you may have a single EVI for the
whole network. 

>split-horizon which does not make sense in VPWS) hence there is no need to

Since the concept of all-active multi-homing is new in P2P services, I
think a short description is in order but it should be mentioned that it
is per baseline-EVPN procedure. Besides, the text is brief.

>.- in single-active MH the behavior is ³slightly" different and MUST be
>documented: 

Or we can follow the same procedure as baseline EVPN and send a MAC route
with Ether-tag set to the service-id (as before) and with MAC set to NULL.
Let's discuss it further.

>situations for all-active and single-active.

Agreed.

Cheers,
Ali

>>{system-MAC+AC-ID} value. While this ³might² be interesting for packing
>>* There is no longer an RT per VPWS hence you can¹t take advantage of
>>RT-constraint, etc.
>>* I don¹t see many benefits, unless all the AC-IDs are originated and
>>terminated only in two PEsŠ which is a debatable use-case.
>>
>>
>>
>>My proposal would be:
>>
>>sections or paragraph or whatever way you consider. I¹m open to
>>suggestions.
>>
>>Thank you.
>>Jorge
>

---

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Thu, 24 Jul 2014 15:18:31 +0000

Hey Ali,

Thank you. A couple more comments in-line.

-----Original Message-----
From: "Ali Sajassi   (sajassi)" <[email-masked]>
Date: Thursday, July 24, 2014 at 7:58 AM
To: Jorge Rabadan <[email-masked]>, "Sami Boutros
(sboutros)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: More comments about draft-boutros-l2vpn-evpn-vpws-04

>4K scale limit. It should be noted that you may have a single EVI for the

OK, that’s a fair point. But then we should define a way to include a
normalized ethernet tag in the data plane for the case where you define
several VPWS identifiers within the same EVI and VID translation is
required (as well as carry pbits transparently between ACs). In VLAN-aware
bundle interfaces we use the 12-bit VID in the eth-tag as the normalized
tag... 

Agreed.

>Let's discuss it further.

Sounds like a good idea. I would suggest the use of mac route with MAC =
0/48 (reusing the unknown mac route of the evpn-overlay-dci draft.

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 24 Jul 2014 17:11:03 +0000

Hi Jorge,

>bundle interfaces we use the 12-bit VID in the eth-tag as the normalized

Since there is no BD, I don't think we need to have a normalized Ether-tag
similar to VLAN-aware bundling in EVPN. We do the VID translation at the
egress PE using MPLS label alone.

Cheers,
Ali

---

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Fri, 25 Jul 2014 20:19:45 +0000

Hi Ali,

Thank you.
About the following:

"Since there is no BD, I don't think we need to have a normalized Ether-tag
similar to VLAN-aware bundling in EVPN. We do the VID translation at the
egress PE using MPLS label alone."

If that is the case, the draft differs from the procedures defined in EVPN
(there is no normalized eth-tag in the data plane anymore even if the
eth-tag is not zero in the EVPN AD routes). Therefore the behavior has to
be detailed in the draft so that we avoid misinterpretations.
I’d be happy to contribute to the development of this draft.

Thank you.
Jorge

-----Original Message-----
From: "Ali Sajassi   (sajassi)" <[email-masked]>
Date: Thursday, July 24, 2014 at 10:11 AM
To: Jorge Rabadan <[email-masked]>, "Sami Boutros

>>>>is now in the right direction after some issues, especially in the
>>>>first
>>>>2

---

From: "Sami Boutros (sboutros)" <[email-masked]>
Date: Sat, 26 Jul 2014 04:20:02 +0000

Hi Jorge,

Thanks for your comments.

Couple of comments inline.

> be detailed in the draft so that we avoid misinterpretations.

Sami: 
The draft is explicit about the tag usage as a service instance for both EPL and EVPL 
services. Not sure what details more we can add, but please suggest something?

> I’d be happy to contribute to the development of this draft.

Sami: Sure this will be great.

>>> 0/48 (reusing the unknown mac route of the evpn-overlay-dci draft.

Sami: Let's discuss this more.

Thanks,

Sami

---

From: "Rabadan, Jorge (Jorge)" <[email-masked]>
Date: Sat, 26 Jul 2014 14:20:44 +0000

Hi Sami,

Thanks for your reply.
Sure, let’s discuss.

Jorge

-----Original Message-----
From: "Sami Boutros   (sboutros)" <[email-masked]>
Date: Friday, July 25, 2014 at 9:20 PM
To: Jorge Rabadan <[email-masked]>
Cc: "Ali Sajassi (sajassi)" <[email-masked]>, "[email-masked]"
<[email-masked]>

>>>>>> In VPWS the DF will obviously not send a MAC route, hence the
>>>>>>question
>>>>>> is:
>>>>>> PE2? the non-DF for the VPWS id (PE2) should not - in this case -
>>>>>>send
>>>>>> a