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

["Ali Sajassi (sajassi)" <[e-mail]>]

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. 

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

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

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