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

[Alexander Vainshtein <[e-mail]>]

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-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.
>

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.