Re: [Idr] draft-ietf-l2vpn-evpn

Satya Mohanty <smohanty@juniper.net> Sat, 16 March 2013 00:10 UTC

Return-Path: <smohanty@juniper.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4261F0D0B; Fri, 15 Mar 2013 17:10:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.466
X-Spam-Level:
X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlYiRmT9YJMH; Fri, 15 Mar 2013 17:10:55 -0700 (PDT)
Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0C61F0D05; Fri, 15 Mar 2013 17:10:55 -0700 (PDT)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUUO4j1VcNNwF7RA1JpQ03LoYnLO2AaQw@postini.com; Fri, 15 Mar 2013 17:10:55 PDT
Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 15 Mar 2013 17:06:12 -0700
Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 15 Mar 2013 17:06:11 -0700
Received: from va3outboundpool.messaging.microsoft.com (216.32.180.12) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 15 Mar 2013 17:08:41 -0700
Received: from mail162-va3-R.bigfish.com (10.7.14.234) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Sat, 16 Mar 2013 00:06:10 +0000
Received: from mail162-va3 (localhost [127.0.0.1]) by mail162-va3-R.bigfish.com (Postfix) with ESMTP id 6B9CB1602A5; Sat, 16 Mar 2013 00:06:10 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:157.56.236.101; KIP:(null); UIP:(null); (null); H:BY2PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT
X-SpamScore: -22
X-BigFish: PS-22(zz9371Ic85fh4015Izz1f42h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dh18c673h8275bhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1155h)
Received: from mail162-va3 (localhost.localdomain [127.0.0.1]) by mail162-va3 (MessageSwitch) id 1363392310948040_20710; Sat, 16 Mar 2013 00:05:10 +0000 (UTC)
Received: from VA3EHSMHS018.bigfish.com (unknown [10.7.14.226]) by mail162-va3.bigfish.com (Postfix) with ESMTP id 5A3C110005D; Sat, 16 Mar 2013 00:04:52 +0000 (UTC)
Received: from BY2PRD0510HT003.namprd05.prod.outlook.com (157.56.236.101) by VA3EHSMHS018.bigfish.com (10.7.99.28) with Microsoft SMTP Server (TLS) id 14.1.225.23; Sat, 16 Mar 2013 00:04:49 +0000
Received: from BY2PRD0510MB377.namprd05.prod.outlook.com ([169.254.5.104]) by BY2PRD0510HT003.namprd05.prod.outlook.com ([10.255.84.38]) with mapi id 14.16.0275.006; Sat, 16 Mar 2013 00:04:49 +0000
From: Satya Mohanty <smohanty@juniper.net>
To: Jakob Heitz <jakob.heitz@ericsson.com>, "Ali Sajassi (sajassi)" <sajassi@cisco.com>, "idr@ietf.org" <idr@ietf.org>
Thread-Topic: draft-ietf-l2vpn-evpn
Thread-Index: AQHOHzFpw7wq2p0F306XvoGHyBm2OpinSauggAAcl9CAAAfLcA==
Date: Sat, 16 Mar 2013 00:04:48 +0000
Message-ID: <DBDBC40345866E4FA5701A2C8C2684222CC47591@BY2PRD0510MB377.namprd05.prod.outlook.com>
References: <69670F7146898C4583F56DA9AD32F77B1230F9D9@xmb-aln-x13.cisco.com> <DBDBC40345866E4FA5701A2C8C2684222CC47522@BY2PRD0510MB377.namprd05.prod.outlook.com> <2F3EBB88EC3A454AAB08915FBF0B8C7E1C8338@eusaamb109.ericsson.se>
In-Reply-To: <2F3EBB88EC3A454AAB08915FBF0B8C7E1C8338@eusaamb109.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.224.54]
Content-Type: multipart/alternative; boundary="_000_DBDBC40345866E4FA5701A2C8C2684222CC47591BY2PRD0510MB377_"
MIME-Version: 1.0
X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn%
X-FOPE-CONNECTOR: Id%12219$Dn%ERICSSON.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%CISCO.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net
Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>, "Giles Heron (giheron)" <giheron@cisco.com>
Subject: Re: [Idr] draft-ietf-l2vpn-evpn
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 16 Mar 2013 00:10:58 -0000

I am guessing you mean the 'alias label"  to be the label in the per EVI AD route ?

I understand that "PE can allocate MAC labels anyway it likes as long as it can deliver the frame when it arrives
with that label." In the case I am mentioning, the frame is not coming with "that" label, PE2 did not advertise the mac route p1, at all to PE3, so PE3 does not know  the per prefix label allocated by PE2. So, it will only have to use the per EVI AD label from PE2. At the egress (PE2), yes, this will defaults to a mac/vlan lookup, but this is like a per vrf or per CE (per esi per evi) behavior.

Also, I was not aware that one can use different allocation scheme for MAC labels and "alias" labels.
So, what I infer is you are suggesting that label allocation mode could be also per NLRI type?

Thanks
--Satya







From: Jakob Heitz [mailto:jakob.heitz@ericsson.com]
Sent: Friday, March 15, 2013 4:17 PM
To: Satya Mohanty; Ali Sajassi (sajassi); idr@ietf.org
Cc: l2vpn@ietf.org; Giles Heron (giheron)
Subject: RE: draft-ietf-l2vpn-evpn

The egress PE can allocate MAC labels anyway it likes
as long as it can deliver the frame when it arrives
with that label. It is not necessarily the same
as the alias label. A frame arriving with the alias
label will most likely undergo a MAC/VLAN lookup.
This does not prevent it from using a different
label allocation scheme for MAC labels than for
alias labels.

--
Jakob Heitz. x25475. 510-566-2901


________________________________
From: l2vpn-bounces@ietf.org<mailto:l2vpn-bounces@ietf.org> [mailto:l2vpn-bounces@ietf.org] On Behalf Of Satya Mohanty
Sent: Friday, March 15, 2013 3:16 PM
To: Ali Sajassi (sajassi); idr@ietf.org<mailto:idr@ietf.org>
Cc: l2vpn@ietf.org<mailto:l2vpn@ietf.org>; Giles Heron (giheron)
Subject: RE: draft-ietf-l2vpn-evpn
Few comments,

1. Sec 8.3: Please consider putting in a line stating that the per ESI Route (type 4) carries a label with all 0s (like the Type 1 mandatory route) in the MP-Reach NLRI.

2. This is not explicitly sec 8 but I think there may be a discrepancy in the draft.  Page 27, top paragraph

   An PE may advertise the same single E-VPN label for all MAC addresses
   in a given EVI. This label assignment methodology is referred to as a
   per EVI label assignment. Alternatively, an PE may advertise a unique
   E-VPN label per <ESI, Ethernet Tag> combination. This label
   assignment methodology is referred to as a per <ESI, Ethernet Tag>
   label assignment. As a third option, an PE may advertise a unique E-
   VPN label per MAC address. All of these methodologies have their
   tradeoffs.

I see a problem with the third option (per-prefix allocation mode), related to aliasing in the Active/Active case.
In such a label allocation mode, what label will be associated with the per EVI AD route ?

Let's say PE1 and PE2 share the same ESI, PE1 and PE1 uses per prefix label  allocation mode, and PE2 uses either per EVI or per <ESI, Ethernet-tag> label allocation mode. As per the aliasing behavior, a mac route (say p1 with label l1) advertised from PE1, should be reachable from PE3 via PE2, irrespective of whether PE2 advertised p1 or not.  If PE2 did not advertise p1, but PE3 sends traffic to PE2, what label does PE3 slap on frames? As per the draft, it will slap the label what was received in the per EVI AD route. Moot question is what does it correspond to here ?

Should per-prefix label allocation be allowed? If it is, I think then the concept of aliasing will be lost, and all macs with the same EVI, ESI need to be advertised from each of the PEs configured to the same ES.

       PE1 -- --- --|
    /                       |_______
CE                         ________ RR-------PE3
   \                        |
      PE2 ---------|

Thanks,
--Satya

From: l2vpn-bounces@ietf.org<mailto:l2vpn-bounces@ietf.org> [mailto:l2vpn-bounces@ietf.org] On Behalf Of Ali Sajassi (sajassi)
Sent: Tuesday, March 12, 2013 7:54 AM
To: idr@ietf.org<mailto:idr@ietf.org>
Cc: l2vpn@ietf.org<mailto:l2vpn@ietf.org>; Giles Heron (giheron)
Subject: draft-ietf-l2vpn-evpn



In preparation for WG last call of this draft, our L2VPN chairs have asked us to solicit comments on the BGP section of this document (section 8).

http://www.ietf.org/id/draft-ietf-l2vpn-evpn-03.txt

Please kindly review this draft and post your comments by Friday March/29.

Thanks,
Ali