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

[Alexander Vainshtein <[e-mail]>]

Ali,
Sorry for a naive question - but your response seems to imply that E-VPN uses a separate application label per DMAC per VSI per remote PE (similar to the what BGP/MPLS VPN can do in one of its flavors where application label is allocated and distributed for each locally reachable prefix).

This would be indeed very different from VPLS where (regardless of the label distribution method) uses one application label per VSI per remote peer.

If this is the case, you indeed need any tagging to support E-Tree. 
But you can easily run into scalability problems (what if you need more than 1M of MACs?) not to mention OAM problems.



________________________________________
From: [e-mail] [[e-mail]] on behalf of Ali Sajassi (sajassi) [[e-mail]]
Sent: Tuesday, September 25, 2012 1:41 AM
To: UTTARO, JAMES; 'Rogers, Josh'; Aldrin Isaac; Giles Heron
Cc: [e-mail]; Jiangyuanlong
Subject: Re: New Version Notification for       draft-jiang-l2vpn-evpn-etree-2vlan-00.txt

Jim, Aldrin, Josh:

You guys are spot on. E-VPN solution doesn't have the limitation of
data-plane forwarding that VPLS has and as such it doesn't need addition
vlan-tag to solve root/leaf indication issue as it can be supported
inherently by the solution.

Cheers,
Ali

On 9/22/12 4:34 PM, "UTTARO, JAMES" <[e-mail]> wrote:

>Josh,
>
>       Yes.. I think that is the reality of it.. VPLS either the LDP or BGP
>variety uses data plane learning as the mechanism to "learn".. The fact
>that we extend the L2 footprint via these "tunnels" does not change that
>fact.. SO in VPLS the only hammer you have is the data plane, so one must
>manipulate bits on the wire to infer topology ( Limited set of topology
>)..
>
>Another challenge is when roots and leafs "land" on the same PE.
>
>EVPN is intended to use contexts and associated import/export to manage
>the topology.. So here there is a set of tools to create the desired
>topologies, along with that there other mechanisms realized i.e
>active/active...
>
>Jim Uttaro
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of
>Rogers, Josh
>Sent: Saturday, September 22, 2012 7:03 PM
>To: UTTARO, JAMES; Aldrin Isaac; Giles Heron
>Cc: [e-mail]; Jiangyuanlong
>Subject: Re: New Version Notification for
>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt
>
>I agree.
>
>Would it be safe to state that VPLS has a need for a 'etree solution', but
>EVPN does not, because it is inherently supported?
>
>The previously discussed effort of having a 'single etree solution' for
>both VPLS and EVPN may not really be valid due to this.
>
>In fact, I do not think it is valid to ask for a single solution, EVPN
>doesn't have a problem that needs to be fixed here, I don't believe it
>factors into this discussion.
>
>-Josh
>
>
>On 9/22/12 4:56 PM, "UTTARO, JAMES" <[e-mail]> wrote:
>
>>EVPN is intended to maximize the flexibility of multiple routing contexts
>>with arbitrary topologies.. As I have stated in the past, EVPN allows for
>>E-Tree to be constructed in the control plane, other solutions require
>>some method to interrogate data and infer topology. IMO this is not
>>desirable.
>>
>>Jim Uttaro
>>
>>-----Original Message-----
>>From: [e-mail] [mailto:[e-mail]] On Behalf Of
>>Rogers, Josh
>>Sent: Saturday, September 22, 2012 12:49 PM
>>To: Aldrin Isaac; Giles Heron
>>Cc: [e-mail]; Jiangyuanlong
>>Subject: Re: New Version Notification for
>>draft-jiang-l2vpn-evpn-etree-2vlan-00.txt
>>
>>So, this same sort of 'import/export' of targets is possible using
>>BGP-VPLS today, but it faces limitations outlined in
>>draft-ietf-l2vpn-etree-frwk, in section 2.  E-VPN would be able to
>>import/export by attachment circuit, and not by PE?  Meaning, AC1 one PE1
>>may import RTA, while AC2 on PE2 may import RTB?
>>
>>Its occurred to me that EVPN would be able to use other mechanisms that
>>have not yet been discussed yet due to sharing a mac table over BGP.
>>
>>Thanks for the response,
>>Josh
>>
>>
>>On 9/22/12 10:28 AM, "Aldrin Isaac" <[e-mail]> wrote:
>>
>>>In E-VPN an E-tree would be implemented as a hub-and-spoke VPN (like as
>>>in a hub-and-spoke IPVPN, i.e. import RTA export RTB at hubs, import RTB
>>>export RTA at spokes) with filtering to enforce downstream data flow if
>>>desired.  The tree could be built using PIM, mLDP, RSVP, etc.
>>>
>>>
>>>
>>>On Sep 21, 2012, at 9:09 AM, Giles Heron wrote:
>>>
>>>> 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
>>>>>-
>>>>>0
>>>>>0.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
>>>>>
>>>>
>>>
>>
>>
>>This E-mail and any of its attachments may contain Time Warner Cable
>>proprietary information, which is privileged, confidential, or subject to
>>copyright belonging to Time Warner Cable. This E-mail is intended solely
>>for the use of the individual or entity to which it is addressed. If you
>>are not the intended recipient of this E-mail, you are hereby notified
>>that any dissemination, distribution, copying, or action taken in
>>relation to the contents of and attachments to this E-mail is strictly
>>prohibited and may be unlawful. If you have received this E-mail in
>>error, please notify the sender immediately and permanently delete the
>>original and any copy of this E-mail and any printout.
>
>
>This E-mail and any of its attachments may contain Time Warner Cable
>proprietary information, which is privileged, confidential, or subject to
>copyright belonging to Time Warner Cable. This E-mail is intended solely
>for the use of the individual or entity to which it is addressed. If you
>are not the intended recipient of this E-mail, you are hereby notified
>that any dissemination, distribution, copying, or action taken in
>relation to the contents of and attachments to this E-mail is strictly
>prohibited and may be unlawful. If you have received this E-mail in
>error, please notify the sender immediately and permanently delete the
>original and any copy of this E-mail and any printout.

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.