RE: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

[Jiangyuanlong <[e-mail]>]

Hi Ali,



I am not sure whether "pure MPLS forwarding at the egress PE" is something we are pursuing or something true enough, but it seems to me the forwarding of EVPN is not so different from VPLS/VPWS in the description of EVPN document:

"

   Per EVI label assignment requires the least number of E-VPN labels,

   but requires a MAC lookup in addition to an MPLS lookup on an egress

   PE for forwarding. On the other hand, a unique label per <ESI,

   Ethernet Tag> or a unique label per MAC allows an egress PE to

   forward a packet that it receives from another PE, to the connected

   CE, after looking up only the MPLS labels without having to perform a

   MAC lookup. This includes the capability to perform appropriate VLAN

   ID translation on egress to the CE.

"

That is, if label per EVI is allocated, forwarding is based on MAC lookup (like VPLS), otherwise, if label per Ethernet segment or per MAC is allocated, the forwarding is like in VPWS, and VLAN translation is allowed further. Why an extra VLAN translation operation breaks?



For the 2nd question, I could not find SH label in the etree-evpn draft, were you referring to ESI MPLS label?



Thanks,

Yuanlong





-----Original Message-----
From: Ali Sajassi (sajassi) [mailto:[e-mail]]
Sent: Tuesday, September 25, 2012 7:42 AM
To: Jiangyuanlong; Giles Heron
Cc: [e-mail]
Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt





Jiangyuanlong,





Your proposal of applying vlan-tags (as done for VPLS) to E-VPN solution

is broken and doesn't work properly for E-VPN for the following reasons:



1) It breaks MPLS forwarding for egress PE - E-VPN allows for pure MPLS

forwarding at the egress PE



2) Even in scenarios where MAC lookup is used on egress PE, it creates

unnecessary overhead that is absolutely NOT needed. E-VPN multicast

packets already carries SH label (which as describe in etree-evpn draft)

is also used for root/leaf indication.





EVPN is the next gen solution which doesn't have the limitation of

existing vpls solution. It is extreemly flexible as it allows for pure

MPLS forwarding to a given AC without any MAC lookup (in either

direction). It allows for asymmetric MAC lookup operation (lookup in the

ingress PE but no lookup on the egress PE). Or it allows for lookup in

both directions. We don't want to contamiate such solution with the kludge

that we used for VPLS.



Cheers,

Ali







On 9/21/12 7:31 PM, "Jiangyuanlong" <[e-mail]> wrote:



>Hi Giles,

>

>Perhaps the gauge of the consensus in the minutes was not so clear for me:

>"         Giles - are we agreed we want to get to one solution for VPLS

>and E-VPN.

>          Not many people.  But even fewer who want multiple.  Checked to

>see if

>          people want one solution only for E-VPN and VPLS - only a

>couple of hands."

>Nevertheless, E-VPN needs an E-Tree solution and it is the WG consensus

>to decide which way to take.

>

>Thanks,

>Yuanlong

>

>-----Original Message-----

>From: Giles Heron [mailto:[e-mail]]

>Sent: Friday, September 21, 2012 9:09 PM

>To: Jiangyuanlong

>Cc: [e-mail]

>Subject: Re: New Version Notification for

>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

>

>Thanks Yuanlong,

>

>however I must say that your memory of the IETF 84 L2VPN meeting differs

>from mine (and from what is noted in the minutes).  Whilst Himanshu said

>that it was better to have the same solution for VPLS and E-VPN, Ali

>stated that there was no benefit in the E-VPN case in using an additional

>tag (such as a VLAN).  No consensus was reached in the meeting.

>

>Giles

>

>On 21 Sep 2012, at 10:16, Jiangyuanlong <[e-mail]> wrote:

>

>> Hi all,

>>

>> During the 84th IETF meeting, the group discussed the issue of E-Tree

>>in E-VPN, and it was shown that a single solution was more preferred

>>than two different approaches for VPLS and E-VPN.

>> This I-D probes how the 2VLAN approach can be used to support E-Tree in

>>E-VPN and it seems not a big issue.

>> Any comments from you are greatly appreciated.

>>

>> Best regards,

>> Yuanlong

>>

>> -----Original Message-----

>> From: [e-mail] [mailto:[e-mail]]

>> Sent: Friday, September 21, 2012 4:55 PM

>> To: Jiangyuanlong

>> Subject: New Version Notification for

>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

>>

>>

>> A new version of I-D, draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

>> has been successfully submitted by Yuanlong Jiang and posted to the

>> IETF repository.

>>

>> Filename:    draft-jiang-l2vpn-evpn-etree-2vlan

>> Revision:     00

>> Title:             E-Tree Support with 2VLAN in E-VPN

>> Creation date:    2012-09-21

>> WG ID:                  Individual Submission

>> Number of pages: 6

>> URL:

>>http://www.ietf.org/internet-drafts/draft-jiang-l2vpn-evpn-etree-2vlan-00

>>.txt

>> Status:

>>http://datatracker.ietf.org/doc/draft-jiang-l2vpn-evpn-etree-2vlan

>> Htmlized:

>>http://tools.ietf.org/html/draft-jiang-l2vpn-evpn-etree-2vlan-00

>>

>>

>> Abstract:

>>   This document discusses how the Dual-VLAN approach as described in

>>   [Etree-vlan] can be used to support the transport of E-Tree service

>>   in E-VPN. Thus a single convergent solution is possible for both VPLS

>>   and E-VPN.

>>

>>

>>

>>

>> The IETF Secretariat

>>

>