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

["UTTARO, JAMES" <[e-mail]>]

"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:[e-mail]] On Behalf Of Rabadan, Jorge (Jorge)
Sent: Thursday, July 24, 2014 12:55 AM
To: Sami Boutros (sboutros); [e-mail]
Subject: More comments about draft-boutros-l2vpn-evpn-vpws-04

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