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

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

Hi Sami,

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

Jorge

-----Original Message-----
From: "Sami Boutros   (sboutros)" <[e-mail]>
Date: Friday, July 25, 2014 at 9:20 PM
To: Jorge Rabadan <[e-mail]>
Cc: "Ali Sajassi (sajassi)" <[e-mail]>om>, "[e-mail]"
<[e-mail]>
Subject: Re: More comments about draft-boutros-l2vpn-evpn-vpws-04

>Hi Jorge,
>
>Thanks for your comments.
>
>Couple of comments inline.
>On Jul 25, 2014, at 1:19 PM, Rabadan, Jorge (Jorge) wrote:
>
>> 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.
>
>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.
>
>>>>> 
>>>>>> .- 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.
>>>> 
>
>Sami: Let's discuss this more.
>
>Thanks,
>
>Sami
>