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

["UTTARO, JAMES" <[e-mail]>]

That is another benefit of E-VPN that is overlooked.. The fact that the transport across the core is the same as in L3VPN is very desirable from a consistency point of view across all of our services..

Jim Uttaro

-----Original Message-----
From: Ali Sajassi (sajassi) [mailto:[e-mail]] 
Sent: Thursday, September 27, 2012 2:46 PM
To: Alexander Vainshtein; 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


Sasha,

There is no notion of PWs E-VPN. E-VPN operation is analogous to IP-VPN.
Regarding the OAM aspects, the work has already started and it will be
covered separately. Since E-VPN covers many applications such as VPLS,
VPWS, E-TREE/VPMS, DCI, DCN/cloud, its corresponding OAM MUST cover all
these applications well.

Cheers,
Ali

On 9/26/12 7:45 AM, "Alexander Vainshtein"
<[e-mail]> wrote:

>Yuanlong, Ali, and all,
>
>I think that we have really 3 aspects of E-Tree that should be explicitly
>presented for each solution approach:
>
>1. Change of the PE Type:
>    - Root-only to Mixed and vice versa
>    - Leaf-only to Mixed and vice versa
>    - Root-only to Leaf-only and vice versa
>2. OAM - how it is supposed to work and how the defects it detects are
>handled.
>    This becomes non-trivial in the 2PW solution and its analogs if one
>of the two PWsfails IMHO
>3. Interworking with Ethernet-only E-Tree.
>
>My 2c,
>     Sasha
>
>
>________________________________________
>From: [e-mail] [[e-mail]] on behalf of
>Jiangyuanlong [[e-mail]]
>Sent: Wednesday, September 26, 2012 11:31 AM
>To: Ali Sajassi (sajassi); 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
>
>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-2vl
>>>>>>>a
>>>>>>>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.
>>
>
>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.
>