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

["Rabadan, Jorge (Jorge)" <[e-mail]>]

Hey Ali,

Thank you. A couple more comments in-line.

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

>Hi Jorge,
>
>Thanks for your comments, please refer to my in-line reply below ...
>
>On 7/24/14 12:55 AM, "Rabadan, Jorge (Jorge)"
><[e-mail]> wrote:
>
>>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
>
>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."
>
>>
>>- 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.
>
>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.

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

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

Agreed.

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

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.

>
>>.- Section 4 should be clarified, specifying the handling failure
>>situations for all-active and single-active.
>
>Agreed.
>
>Cheers,
>Ali
>
>>
>>Thank you.
>>Jorge
>>
>>
>>
>>
>>From:  <Rabadan>, Jorge Rabadan <[e-mail]>
>>Date:  Friday, November 15, 2013 at 1:04 PM
>>To:  "Ali Sajassi (sajassi)" <[e-mail]>om>, "[e-mail]"
>><[e-mail]>
>>Cc:  "Henderickx, Wim (Wim)" <[e-mail]>
>>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
>>
>