Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E421A6FC7 for ; Tue, 25 Nov 2014 07:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EvH30xsKY0li for ; Tue, 25 Nov 2014 07:42:27 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0117.outbound.protection.outlook.com [207.46.100.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2C921A6F81 for ; Tue, 25 Nov 2014 07:42:27 -0800 (PST) Received: from BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) by BLUPR05MB562.namprd05.prod.outlook.com (10.141.202.141) with Microsoft SMTP Server (TLS) id 15.1.26.15; Tue, 25 Nov 2014 15:42:26 +0000 Received: from BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) by BLUPR05MB562.namprd05.prod.outlook.com ([10.141.202.141]) with mapi id 15.01.0026.003; Tue, 25 Nov 2014 15:42:26 +0000 From: John E Drake To: Haoweiguo , "Henderickx, Wim (Wim)" , "bess@ietf.org" , "sajassi@cisco.com" Thread-Topic: [bess] A comment and question for the draft "draft-ietf-bess-evpn-inter-subnet-forwarding-00" Thread-Index: AQHQCJ9L0ixxt+ZqHkGcmnxIjcOU3pxxSvP+gAAwNuA= Date: Tue, 25 Nov 2014 15:42:25 +0000 Message-ID: <0b3c5822c1a249a0b092d337ab4f92cd@BLUPR05MB562.namprd05.prod.outlook.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB562; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB562; x-forefront-prvs: 040655413E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(189002)(377454003)(50986999)(86362001)(95666004)(76176999)(54356999)(99286002)(2201001)(92566001)(16236675004)(66066001)(15202345003)(107886001)(107046002)(4396001)(2501002)(19625215002)(97736003)(76576001)(21056001)(101416001)(19580395003)(87936001)(230783001)(33646002)(15975445006)(19580405001)(19609705001)(62966003)(120916001)(77156002)(2656002)(99396003)(20776003)(106356001)(106116001)(74316001)(105586002)(19300405004)(64706001)(46102003)(108616004)(40100003)(122556002)(31966008)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB562; H:BLUPR05MB562.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_0b3c5822c1a249a0b092d337ab4f92cdBLUPR05MB562namprd05pro_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/bess/PiWI9Jntfx2LSlDHsrQ8fCKoMU4 Subject: Re: [bess] A comment and question for the draft "draft-ietf-bess-evpn-inter-subnet-forwarding-00" X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Nov 2014 15:42:31 -0000 --_000_0b3c5822c1a249a0b092d337ab4f92cdBLUPR05MB562namprd05pro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I think this suggestion is ill-considered. We don't want two alternative s= olutions. Yours Irrespectively, John From: BESS [mailto:bess-bounces@ietf.org] On Behalf Of Haoweiguo Sent: Tuesday, November 25, 2014 8:02 AM To: Henderickx, Wim (Wim); bess@ietf.org; sajassi@cisco.com Subject: Re: [bess] A comment and question for the draft "draft-ietf-bess-e= vpn-inter-subnet-forwarding-00" Hi Wim, Yes, the design has flexibility. But for most scenarios, we don't need this= flexibility, we want to more compact encoding method. If all MAC routes ad= vertised from a egress NVE share same NVE MAC and tunnel type, the two BGP = Extended Communities carried with each MAC route is redundant, egress NVE o= nly needs advertise its NVE MAC and tunnel type only once. I think we had better provide two alternative solutions, one is for flexibi= lity, another one is for compactness. Depending on different scenarios, the= vendors can choose one for implementation. Thanks weiguo ________________________________ From: Henderickx, Wim (Wim) [wim.henderickx@alcatel-lucent.com] Sent: Tuesday, November 25, 2014 19:02 To: Haoweiguo; bess@ietf.org; sajassi@cisco.com Subject: Re: [bess] A comment and question for the draft "draft-ietf-bess-e= vpn-inter-subnet-forwarding-00" The reason we did this is providing the most flexibility because depending = on the use case you need one and not the other. Hence we optimised for flex= ibility. From: Haoweiguo > Date: Tuesday 25 November 2014 10:21 To: "bess@ietf.org" >, sajassi > Subject: [bess] A comment and question for the draft "draft-ietf-bess-evpn-= inter-subnet-forwarding-00" Hi Ali and other Co-authors, In the EVPN IRB draft, Route Type-2 is used to advertise TS's MAC and IP. T= wo BGP Extended Communities are carried with each RT-2 route. The first com= munity carries tunnel type, the second community carries NVE MAC. In normal= case, all RT-2 routes from a remote NVE share same NVE MAC, so in this cas= e the Route information encoding isn't compact. So a new compact encoding method is introduced as follows: 1. Add tunnel type field in Route Type-2. 2. Introduce a new Route Type to exclusively advertise tunnel type,NVE MAC = and L3 VN ID. 3. Ingress NVEs correlate the new Type Route and RT-2 routes advertised fro= m egress NVE to get the NVO3 encapsulation information for inter-subnet IP = traffic forwarding. Maybe there are other more compact methods. I would like to hear your co-au= thors opinion on this point. Thanks weiguo --_000_0b3c5822c1a249a0b092d337ab4f92cdBLUPR05MB562namprd05pro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I think this suggestion is ill-consid= ered.  We don’t want two alternative solutions.

 

Yours Irrespectively,

 

John

 

From: BESS [mailto:bess-bounces@ietf= .org] On Behalf Of Haoweiguo
Sent: Tuesday, November 25, 2014 8:02 AM
To: Henderickx, Wim (Wim); bess@ietf.org; sajassi@cisco.com
Subject: Re: [bess] A comment and question for the draft "draft= -ietf-bess-evpn-inter-subnet-forwarding-00"

 

Hi= Wim,

Ye= s, the design has flexibility. But for most scenarios, we don't need this f= lexibility, we want to more compact encoding method. If all MAC routes adve= rtised from a egress NVE share same NVE MAC and tunnel type, the two BGP Extended Communities carried with each MAC ro= ute is redundant, egress NVE only needs advertise its NVE MAC and tunnel ty= pe only once.

I = think we had better provide two alternative solutions, one is for flexibili= ty, another one is for compactness. Depending on different scenarios, the v= endors can choose one for implementation.

Th= anks

we= iguo

From:<= /span> Henderickx, Wim (Wim) [wim.henderickx@alcatel-lucent= .com]
Sent: Tuesday, November 25, 2014 19:02
To: Haoweiguo; bess@ietf.org; <= a href=3D"mailto:sajassi@cisco.com"> sajassi@cisco.com
Subject: Re: [bess] A comment and question for the draft "draft= -ietf-bess-evpn-inter-subnet-forwarding-00"

The reason we did this i= s providing the most flexibility because depending on the use case you need= one and not the other. Hence we optimised for flexibility.

 =

From: Haoweiguo <haoweiguo@huawei.com>
Date: Tuesday 25 November 2014 10:21
To: "bess@ie= tf.org" <bes= s@ietf.org>, sajassi <sajassi@cisco.com>
Subject: [bess] A comment and question for the draft "draft-iet= f-bess-evpn-inter-subnet-forwarding-00"

 =

H= i Ali and other Co-authors,

 

I= n the EVPN IRB draft, Route Type-2 is used to advertise TS's MAC and IP. Tw= o BGP Extended Communities are carried with each RT-2 route. The first comm= unity carries tunnel type, the second community carries NVE MAC. In normal case, all RT-2 routes from a remote NVE share s= ame NVE MAC, so in this case the Route information encoding isn't compact.<= br> So a new compact encoding method is introduced as follows:=

1= . Add tunnel type field in Route Type-2.
2. Introduce a new Route Type to exclusively advertise tunnel type,NVE MAC = and L3 VN ID.
3. Ingress NVEs correlate the new Type Route and RT-2 routes advertised fro= m egress NVE to get the NVO3 encapsulation information for inter-subne= t IP traffic forwarding.

 

M= aybe there are other more compact methods. I would like to hear your co-aut= hors opinion on this point.

<= br> Thanks

<= br> weiguo

--_000_0b3c5822c1a249a0b092d337ab4f92cdBLUPR05MB562namprd05pro_--