Re: [bess] WG Last Call for draft-ietf-bess-evpn-inter-subnet-forwarding-03

"Jeffrey (Zhaohui) Zhang" <> Wed, 22 February 2017 14:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 273871299B2 for <>; Wed, 22 Feb 2017 06:44:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.789
X-Spam-Status: No, score=-3.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kgdT2RaUtlzB for <>; Wed, 22 Feb 2017 06:44:13 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4F76D1299B6 for <>; Wed, 22 Feb 2017 06:44:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qd8NimyFbA5f4Kl0QOWbzeEAUzm93e1ZtY3D98tqmIk=; b=TcZbe52MV/4tfbQnKNsBg7UXIckk8oLrJDTZSzaAAcnE6VIhesVkccSJKw2VmtXwQYyDePvniaIN+avwahmGR57/2vCWijjK0YOlybgjXLvipSqqm3ayVc0e97pTiAdZkWwIMhZSts9rARMpQtdfjEJFRApEOx3nUEI3216LxUo=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.7; Wed, 22 Feb 2017 14:44:02 +0000
Received: from ([]) by ([]) with mapi id 15.01.0933.011; Wed, 22 Feb 2017 14:44:02 +0000
From: "Jeffrey (Zhaohui) Zhang" <>
To: Martin Vigoureux <>, BESS <>
Thread-Topic: [bess] WG Last Call for draft-ietf-bess-evpn-inter-subnet-forwarding-03
Thread-Index: AQHShkWa59vApEY6fkGMs0oECnFJv6Ftutzg
Date: Wed, 22 Feb 2017 14:44:02 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-office365-filtering-correlation-id: fdc01120-ce2b-4d2c-ca39-08d45b313e4a
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:DM5PR05MB3148;
x-microsoft-exchange-diagnostics: 1; DM5PR05MB3148; 7:WkgYn7MpK9SRj8G5h2EhY9D6bos+B8oVPs1KZxgPkZmpuutaPAXflEJjN3MeSzKLD3Ej61tjSMZ1M7Pz1Ljsuzj7W70EK2svyOFgmO1+LCO1SO6Kc9HoVNe6wBEZ2mqIBKU8KrkmlXGl2CyWNCGR28RYmMWK+M9xe8iPDHVgW7mmr7Mwkv+r7JZV5tcz+q4ctgfwA3wrsL5e792BK9vjuJJsGK2kc1285+B7H+dvFpMD2lj8VCzaynepVGHvQa+06tb/w2JFWjvp7eVizv2rNcwlwqJWBDojumoTWi5/gSXn8aPMTaDCCACJZxB1631lQC837fAW5q+ovgPXGqasHQ==
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(120809045254105);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123558025)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(6072148); SRVR:DM5PR05MB3148; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3148;
x-forefront-prvs: 022649CC2C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39840400002)(39850400002)(39450400003)(39860400002)(13464003)(377454003)(199003)(189002)(2906002)(81166006)(33656002)(230783001)(3280700002)(81156014)(8936002)(77096006)(229853002)(6506006)(189998001)(3660700001)(2950100002)(102836003)(7696004)(5660300001)(6116002)(3846002)(106356001)(122556002)(68736007)(7736002)(53546006)(53936002)(6246003)(38730400002)(101416001)(6436002)(6306002)(92566002)(105586002)(25786008)(97736004)(55016002)(9686003)(99286003)(106116001)(74316002)(54356999)(76176999)(66066001)(2900100001)(305945005)(50986999)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3148;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2017 14:44:02.0454 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3148
Archived-At: <>
Subject: Re: [bess] WG Last Call for draft-ietf-bess-evpn-inter-subnet-forwarding-03
X-Mailman-Version: 2.1.17
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: Wed, 22 Feb 2017 14:44:15 -0000

Questions/comments for the symmetric  model:

  Each NVE advertises an RT-2 route with two Route Targets (one
   corresponding to its MAC-VRF and the other corresponding to its IP-
   VRF. Furthermore, the RT-2 is advertised with two BGP Extended
   Communities. The first BGP Extended Community identifies the tunnel
   type per section 4.5 of [TUNNEL-ENCAP] and the second BGP Extended
   Community includes the MAC address of the NVE (e.g., MACx for NVE1 or
   MACy for NVE2) as defined in section 6.1.

Is the first EC needed for MPLS encapsulation? For intra-subnet forwarding using MPLS, there is no need for such EC; inter-subnet should not be different in that regard?

   In this symmetric IRB scenario, inter-subnet traffic between NVEs
   will always use the IP-VRF VNID/MPLS label. For instance, traffic
   from TS2 to TS4 will be encapsulated by NVE1 using NVE2's IP-VRF
   VNID/MPLS label, as long as TS4's host IP is present in NVE1's IP-

Because IP-VRF VNID/MPLS label is always used and IP lookup is done after removing the Ethernet header, the Ethernet header is really not useful? while with vxlan the ether header is always present, do we really need to signal the egress NVE's system mac address and put it in the ether header (since the header is not used to identify the IP VRF anywaty)? If this is because of certain hardware property (i.e., with vxlan certain chips always look up dst mac first no matter what), then it should be made clear. If the egress NVE does require a valid system mac address of its own is required, it can signal that via the EC; otherwise it does not have to and the ingress NVE should be free to put anything in the ether header?

5.2 IRB forwarding on NVEs for Subnets behind Tenant Systems

Should this section be moved to the prefix-advertisement draft?


> -----Original Message-----
> From: BESS [] On Behalf Of Martin Vigoureux
> Sent: Monday, February 13, 2017 5:07 PM
> To: BESS <>
> Subject: [bess] WG Last Call for draft-ietf-bess-evpn-inter-subnet-forwarding-03
> Hello Working Group,
> This email starts a Working Group Last Call on
> draft-ietf-bess-evpn-inter-subnet-forwarding-03 [1] which is considered
> mature and ready for a final working group review.
> Note that this call is longer than usual because we are pushing two
> correlated documents together.
> Please read this document if you haven't read the most recent
> version yet, and send your comments to the list, no later than
> *5th of March*.
> Note that this is *not only* a call for comments on the document; it is
> also a call for support (or not) to publish this document as a Proposed
> Standard RFC.
> *Coincidentally*, we are also polling for knowledge of any IPR that
> applies to draft-ietf-bess-evpn-inter-subnet-forwarding, to ensure that
> IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979,
> 4879, 3669 and 5378 for more details).
> *If* you are listed as a document author or contributor of
> draft-ietf-bess-evpn-inter-subnet-forwarding-03 please respond to this
> email and indicate whether or not you are aware of any relevant IPR.
> Note that, as of today, no IPR has been disclosed against this document
> or its earlier versions.
> We are also polling for knowledge of implementations of part or all of
> what this document specifies. This information is expected as per [2].
> Please inform the mailing list, or the chairs, or only one of the chairs.
> Thank you,
> M&T
> [1]
> [2]
> _______________________________________________
> BESS mailing list