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

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

Hi Jorge,


On 7/24/14 11:18 AM, "Rabadan, Jorge (Jorge)"
<[e-mail]> wrote:

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

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

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