Re: [bess] draft-ietf-bess-evpn-prefix-advertisement-05 comments

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Thu, 19 October 2017 02:37 UTC

Return-Path: <zzhang@juniper.net>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5659D132076 for <bess@ietfa.amsl.com>; Wed, 18 Oct 2017 19:37:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.801
X-Spam-Level:
X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=juniper.net
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 RxloRtRq1qMz for <bess@ietfa.amsl.com>; Wed, 18 Oct 2017 19:37:54 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0111.outbound.protection.outlook.com [104.47.42.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37184133158 for <bess@ietf.org>; Wed, 18 Oct 2017 19:37:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=eilRpRfsSIQbpnRB6/7TPFoXLSKXPuKmNxl/UyiMOm4=; b=eS7eaKyXBKn2ZaFrn/Hu/kyNaeF4fHX0WRA3mOpGGxE0YwGDT2i/wFVBEhDEcjGX3nDjk5yO5UZOY3lpz7J8+bR3hs/3NW/ESeS395Y+Vxt3sMcD262O0ZoKgGXV/yBGM9ceA+YxD6xoSJIOD8vkrpUc7hbDq28iyERvOZ5OfD4=
Received: from DM5PR05MB3145.namprd05.prod.outlook.com (10.173.219.15) by DM5PR05MB3147.namprd05.prod.outlook.com (10.173.219.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.2; Thu, 19 Oct 2017 02:37:53 +0000
Received: from DM5PR05MB3145.namprd05.prod.outlook.com ([10.173.219.15]) by DM5PR05MB3145.namprd05.prod.outlook.com ([10.173.219.15]) with mapi id 15.20.0156.004; Thu, 19 Oct 2017 02:37:53 +0000
From: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>
To: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>, "draft-ietf-bess-evpn-prefix-advertisement@tools.ietf.org" <draft-ietf-bess-evpn-prefix-advertisement@tools.ietf.org>, BESS <bess@ietf.org>
Thread-Topic: draft-ietf-bess-evpn-prefix-advertisement-05 comments
Thread-Index: AdNDWJtgzjJlkeiVRDaWqq9GqYzXUwDOzhWAAAAsZZAAIt6NAAAIWNPwAASNRgAAS8BWAA==
Date: Thu, 19 Oct 2017 02:37:53 +0000
Message-ID: <DM5PR05MB3145E113CC2FF8A97E94D0A1D4420@DM5PR05MB3145.namprd05.prod.outlook.com>
References: <DM5PR05MB31455D67D3F259C157889ABBD4480@DM5PR05MB3145.namprd05.prod.outlook.com> <78B11C4B-F6FC-49CF-AB9D-909D6E1856AD@nokia.com> <DM5PR05MB31451CEE7EFAEC3617FCB719D44F0@DM5PR05MB3145.namprd05.prod.outlook.com> <3A7812CA-575A-4E0B-BCF1-D5CA4E80238D@nokia.com> <DM5PR05MB3145C401763F7BF6552730A8D44C0@DM5PR05MB3145.namprd05.prod.outlook.com> <416D7354-C259-4F42-B506-DCF7E2C39D65@nokia.com>
In-Reply-To: <416D7354-C259-4F42-B506-DCF7E2C39D65@nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB3147; 6:8Uwi4YuqMqV+6jyLaSQj/9J3WMVh60c6mWt8hnOTc+UmmLLQHwKQQkdadWHroWOJjn1y4O+DJXE8UaMN8vAqHCVV9n5ftnQ0u7AU7AbLb9I5E4UmD1uhPkLi85tkDB7ISq/Hk+gxg59Xgvge4P3lSfm7b3y1VXyLC/y1Et8t9FS01Eglln6dRrQsve9qlhW3LiWyLeWzGWIHkPHnI3PrpWu3J6SCo08Sazk2cs66iIGtCOVLBF41/NbRoqcvZMgD+4JUYPp3kxlPw7uwaS7cv81ubiGDea5Rh8uL4GCIW2f/H6dl6226skZy1MLB+Hk2+QmRkbXPksSzMg2ASSP9Sw==; 5:iZWea+AHSu2l+NIAGmYd7XAliA+yRp6VYmwtJq+SJO2NmJjET0mANsgBmjmzvoNXl3qRPfCxKJv5PnGgwFJz2Uxb4725bP6Uz9zgHIeHoyTKN9b9BQs08L/06pshUlsEFXEmMaRduz/jLLXGCsqugw==; 24:S9pMmqXs/dPq5j0dwDXh134AwFK/YbnndtfSYvToTQSgS5+4WdqQ1I+JQNqte4iEYm2u1QBBdnW06BuNfgDJS+wYBSBMpZH/8oteUls9/P0=; 7:l3s+hf6zSB7ohPPIs9Bt3JzTJ3sAi8jTUBvCp7j2xvsfbsDiY+d6wbdmHjDyNbdY6r4cDR3kzEWM2LXeKlCJTbVWlQj2oVt2O8gOIgwF/xjB43sjn+UgzdVIiug/M1493nb+CF9pkC/u7b43bQJKPPqDUVYEPWxZQvtQxPCR8+VA+VnLYaah0lQkcwNTKEctVOb4twP06nv7hYOPOyhjstDfRPAFO+ZlwENbbNk3Vlk=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: e629dce8-63df-4285-6176-08d5169a65e2
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254163)(48565401081)(4534011)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603229)(201703131423086); SRVR:DM5PR05MB3147;
x-ms-traffictypediagnostic: DM5PR05MB3147:
x-exchange-antispam-report-test: UriScan:(138986009662008)(82608151540597);
x-microsoft-antispam-prvs: <DM5PR05MB31477E21F731093AC9DE0029D4420@DM5PR05MB3147.namprd05.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR05MB3147; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR05MB3147;
x-forefront-prvs: 0465429B7F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(18374002)(199003)(13464003)(24454002)(377454003)(189002)(3846002)(3660700001)(50986999)(76176999)(8676002)(189998001)(81166006)(81156014)(54356999)(53546010)(6246003)(6436002)(6506006)(3280700002)(53936002)(8936002)(2950100002)(229853002)(7736002)(77096006)(2501003)(305945005)(97736004)(101416001)(74316002)(230783001)(106356001)(68736007)(2900100001)(5660300001)(55016002)(316002)(105586002)(478600001)(14454004)(7696004)(110136005)(66066001)(2906002)(99286003)(9686003)(102836003)(86362001)(8656005)(6116002)(25786009)(33656002)(8656005)(93886005); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3147; H:DM5PR05MB3145.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: e629dce8-63df-4285-6176-08d5169a65e2
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2017 02:37:53.2122 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3147
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/yzpkfK03QdZxDfgX8n5bpVEcj2s>
Subject: Re: [bess] draft-ietf-bess-evpn-prefix-advertisement-05 comments
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Oct 2017 02:37:56 -0000

Are you saying that the presence of the Router's MAC EC alone is not enough to indicate the use of the mac address as the overlay index (since the EC was originally designed for other purpose), but the encoding of ESI and GW IP addr in the NLRI is enough to indicate that they will be used as overlay index?

That makes sense, but could you clarify that?

Thanks.
Jeffrey

> -----Original Message-----
> From: Rabadan, Jorge (Nokia - US/Mountain View)
> [mailto:jorge.rabadan@nokia.com]
> Sent: Tuesday, October 17, 2017 10:24 AM
> To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>et>; draft-ietf-bess-evpn-prefix-
> advertisement@tools.ietf.org; BESS <bess@ietf.org>
> Subject: Re: draft-ietf-bess-evpn-prefix-advertisement-05 comments
> 
> Hi Jeffrey,
> 
> Ah ok, I see what you mean. The label column is basically based on this text in
> section 3.1:
> 
>    o The MPLS Label field is encoded as 3 octets, where the high-order
>      20 bits contain the label value. When sending, the label value
>      SHOULD be zero if recursive resolution based on overlay index is
>      used. If the received MPLS Label value is zero, the route MUST
>      contain an Overlay Index and the ingress NVE/PE MUST do recursive
>      resolution to find the egress NVE/PE. If the received Label value
>      is non-zero, the route will not be used for recursive resolution
>      unless a local policy says so.
> 
> We do care about the label value since, if it is zero we know for sure, there
> must be an overlay index. In rows 1/2/3 we do not care, since the overlay
> index indication is based on fields contained in the NLRI.
> 
> Thanks.
> Jorge
> 
> 
> On 10/17/17, 2:18 PM, "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> wrote:
> 
>     Hi Jorge,
> 
>     >     >        +----------+----------+----------+------------+----------------+
>     >     >        | ESI      | GW-IP    | MAC*     | Label      | Overlay Index  |
>     >     >        |--------------------------------------------------------------|
>     >     >        | Non-Zero | Zero     | Zero     | Don't Care | ESI            |
>     >     >        | Non-Zero | Zero     | Non-Zero | Don't Care | ESI            |
>     >     >        | Zero     | Non-Zero | Zero     | Don't Care | GW-IP          |
>     >     >        | Zero     | Zero     | Non-Zero | Zero       | MAC            |
>     >     >        | Zero     | Zero     | Non-Zero | Non-Zero   | MAC or None**  |
>     >     >        | Zero     | Zero     | Zero     | Non-Zero   | None(IP NVO)***|
>     >     >        +----------+----------+----------+------------+----------------+
>     >     >
>     >     >     The fifth row is like a variation of the fourth row;  why isn't there a
>     >     > corresponding variation for each of the first three rows? The following
>     >     > paragraph mentioned earlier seems to apply to all situations.
>     >     > [JORGE] in rows 4 and 5, the label value 0 or non-0 has a meaning. In
> the
>     > first
>     >     > three rows, the label doesn’t have any meaning.
>     >
>     >     Can you elaborate on "the label does not have any meaning", especially
> for
>     > row #2?
>     > [JORGE] since an overlay index is used, a recursive resolution is needed.
> Hence
>     > the label is not used to forward packets. “Don’t Care” means a valid 0 or
> non-
>     > zero label value should be ignored.
>     >
> 
>     But Row 4/5 is the same - there is a MAC address as overlay index, so:
> 
>     - either we "don’t care" the label for row 4/5 and just use overlay index, or
>     - do the same with for rows 1/2/3 as with rows 4/5 and do label based
> forwarding based on local policy
> 
>     I'm just curious why there is a difference?
> 
>     Thanks.
>     Jeffrey
>