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

"Ali Sajassi (sajassi)" <sajassi@cisco.com> Wed, 26 September 2012 06:28 UTC

Return-Path: <sajassi@cisco.com>
X-Original-To: l2vpn@ietfa.amsl.com
Delivered-To: l2vpn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 813E321F853E for <l2vpn@ietfa.amsl.com>; Tue, 25 Sep 2012 23:28:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4wnQnt2D2Eo for <l2vpn@ietfa.amsl.com>; Tue, 25 Sep 2012 23:28:27 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 68EC421F846D for <l2vpn@ietf.org>; Tue, 25 Sep 2012 23:28:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9574; q=dns/txt; s=iport; t=1348640907; x=1349850507; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=1VlOownNn4vV6xZSosy8sLuCo6bNKiYZpfF0lVprt8M=; b=WKpyeg60mZiVPhefVKICSXD665B0/CoSpHg/HyzaoY0SlSkC8piaUa/V IquNBXMjbRjcVgl3iqbLjcdUgbzmWsW7fapJYgljtJzPXLo6kxHZCrXJ/ pZZkcWsmjg0XEkF3TFlLYKIjSi9DP1FmcLC0mObsrmaNK2/oFhdKfxhQn A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAFAH+fYlCtJXG//2dsb2JhbABFgm68coEIgiABAQEEEgEnMwUFAgwGAQgRBAEBAR4JKBEUCQgCBAENBQkSB4dRAw8BCplmlj8NiVSKOGIUBoVvA5QRgVWBFYoJgyGBaYJngVoJNA
X-IronPort-AV: E=Sophos;i="4.80,488,1344211200"; d="scan'208";a="125377197"
Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-7.cisco.com with ESMTP; 26 Sep 2012 06:28:26 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q8Q6SQIf006354 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Sep 2012 06:28:26 GMT
Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0298.004; Wed, 26 Sep 2012 01:28:26 -0500
From: "Ali Sajassi (sajassi)" <sajassi@cisco.com>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, "UTTARO, JAMES" <ju1738@att.com>, "'Rogers, Josh'" <josh.rogers@twcable.com>, Aldrin Isaac <aldrin.isaac@gmail.com>, Giles Heron <giles.heron@gmail.com>
Subject: Re: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt
Thread-Topic: New Version Notification for draft-jiang-l2vpn-evpn-etree-2vlan-00.txt
Thread-Index: AQHNm7AioQ4WAgO/Xk68/mrrDBiV/g==
Date: Wed, 26 Sep 2012 06:28:25 +0000
Message-ID: <CC87ECA1.1AFEB%sajassi@cisco.com>
In-Reply-To: <F9336571731ADE42A5397FC831CEAA020BA801F5@ILPTWPVEXMB03.ecitele.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.1.120420
x-originating-ip: [10.21.91.100]
x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-19210.004
x-tm-as-result: No--75.667100-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="us-ascii"
Content-ID: <73446E056E90CE48918867C4EEC58ACC@cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>, Jiangyuanlong <jiangyuanlong@huawei.com>
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>, <mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Sep 2012 06:28:28 -0000

Hi Alex,

E-VPN operation is very similar to IP-VPN and it can basically support the
modes that are in IP-VPN; however, for E-TREE we don't need to use such
modes and we don't need to assign label per prefix (MAC in here) since
E-VPN uses the notion of a label per site (per ESI) for its SH filtering.
And for E-TREE we simply color the site (ESI) with two labels (one to
indicate root and another to indicate leaf) and we basically use the same
SH filtering logic here.

Cheers,
Ali

On 9/25/12 1:08 AM, "Alexander Vainshtein"
<Alexander.Vainshtein@ecitele.com> wrote:

>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: l2vpn-bounces@ietf.org [l2vpn-bounces@ietf.org] on behalf of Ali
>Sajassi (sajassi) [sajassi@cisco.com]
>Sent: Tuesday, September 25, 2012 1:41 AM
>To: UTTARO, JAMES; 'Rogers, Josh'; Aldrin Isaac; Giles Heron
>Cc: l2vpn@ietf.org; 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" <ju1738@att.com> 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: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of
>>Rogers, Josh
>>Sent: Saturday, September 22, 2012 7:03 PM
>>To: UTTARO, JAMES; Aldrin Isaac; Giles Heron
>>Cc: l2vpn@ietf.org; 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" <ju1738@att.com> 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: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf
>>>Of
>>>Rogers, Josh
>>>Sent: Saturday, September 22, 2012 12:49 PM
>>>To: Aldrin Isaac; Giles Heron
>>>Cc: l2vpn@ietf.org; 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" <aldrin.isaac@gmail.com> 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 <jiangyuanlong@huawei.com>
>>>>>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: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
>>>>>> 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.
>