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

[Jiangyuanlong <[e-mail]>]

Ali,

On the one hand, you said E-VPN solution doesn't have the limitation of data-plane forwarding and inherently support E-Tree, on the other hand, you agreed that 2 labels are introduced specially for E-Tree for these two cases. Furthermore, forwarding behaviors for these two labels are different (for root label, split horizon + forward to both root & leaf ports; for leaf label, split horizon + forward only to leaf ports) from the E-VPN itself (split horizon only).
But my main concern is whether OAM is needed for E-VPN, if yes, how it can be implemented in practical?

Regards,
Yuanlong



-----Original Message-----
From: Ali Sajassi (sajassi) [mailto:[e-mail]] 
Sent: Wednesday, September 26, 2012 2:15 PM
To: Jiangyuanlong; UTTARO, JAMES; 'Rogers, Josh'; Aldrin Isaac; Giles Heron
Cc: [e-mail]
Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt



Hi Yuanlong, 

If one understood the operation of SH filtering in E-VPN, he would have
seen that it exactly covers both of these cases that are mentioned below.

Also, E-VPN allows for policy-based forwarding on a per MAC basis without
scale issue. As I said previously, I won't be able to provide E-VPN
tutorial over the email.

Cheers,
Ali

On 9/25/12 12:02 AM, "Jiangyuanlong" <[e-mail]> wrote:

>Hi all,
>
>I don't think E-VPN control plane can solve all the problem of E-Tree.
>For the following two scenarios data plane indication of E-Tree is needed:
>1. Per EVI label is assigned, and there are multiple PEs with both Leaf
>AND Root sites;
>2. Per <ESI, Ethernet Tag> label is assigned, and there are multiple
>Ethernet segments with both Leaf AND Root sites;
>Using 2 labels (EVI MPLS label or ESI MPLS label respectively) is an
>option, but maybe OAM is a challenge.
>
>Assigning label per MAC for E-Tree will not need this indication, but at
>expense of scalability.
>
>Regards,
>Yuanlong
>
>
>-----Original Message-----
>From: Ali Sajassi (sajassi) [mailto:[e-mail]]
>Sent: Tuesday, September 25, 2012 7:42 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-2vla
>>>>>>n
>>>>>>-
>>>>>>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.
>