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

"Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> Thu, 19 October 2017 11:25 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 BC21313339A for <bess@ietfa.amsl.com>; Thu, 19 Oct 2017 04:25:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.021
X-Spam-Level:
X-Spam-Status: No, score=-2.021 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 d1nrsFmCVviP for <bess@ietfa.amsl.com>; Thu, 19 Oct 2017 04:25:08 -0700 (PDT)
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0120.outbound.protection.outlook.com [104.47.42.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D83F134927 for <bess@ietf.org>; Thu, 19 Oct 2017 04:25:07 -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=WLm9mp2LWHos2AkHnXAgOrXm9WstSs9SFGb4tyaWcEM=; b=AlNu79XbGY9e0GhqBv0gOB/THz69WhrRZxHVTl1BmnLL0bAb4g5m9A9Opi1nGGBL0DjCN61adQK9ptMWyg/HuTdLt0yaWRI09XcqSSvrBfDaw5iqzYWq6VUep98/L2+CexQSCtvE7XGxihL2ttV8zTHrlGWM8f+dg1vcj9Ds7oo=
Received: from DM5PR05MB3145.namprd05.prod.outlook.com (10.173.219.15) by DM5PR05MB3145.namprd05.prod.outlook.com (10.173.219.15) 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 11:25:06 +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 11:25:06 +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: AdNDWJtgzjJlkeiVRDaWqq9GqYzXUwDOzhWAAAAsZZAAIt6NAAAIWNPwAASNRgAAS8BWAAAHAdcAAAuEBFA=
Date: Thu, 19 Oct 2017 11:25:06 +0000
Message-ID: <DM5PR05MB314517B4A2E3CEBC5AE9A769D4420@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> <DM5PR05MB3145E113CC2FF8A97E94D0A1D4420@DM5PR05MB3145.namprd05.prod.outlook.com> <2A3AD609-1550-4E60-828A-77D75ADC7E9C@nokia.com>
In-Reply-To: <2A3AD609-1550-4E60-828A-77D75ADC7E9C@nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=zzhang@juniper.net;
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB3145; 6:rNejoXYG8fo+q054EHYJivZqSl1MaVr3ivoHntf5Da8aEYxYj/K/RUO+BpGL5Tq0jBd+nfgXfUQ5gEfZA0fP/GCERvAdTD6Jw5y5WGHg8AmHUxXjjLfvLDV/nvSoQFdXdKHXi7lFaOJH2c+AXe3FGDdMELF9/ZKb16Yki0mb+15x1c1kt5ZqHMWBCUNGLRdjtK77RYhT2BWPmgchSR231FcmBHev8JVcNGFS00JtzjgHex/I6gQkOTzn2XhTSMP3+mXHGnrP9VH1zIVKCKJ2flq7QhXUVf2g3bIs6TG9T87kA+O3PObZDzhihxLP5imBv4WGCxOGS5vgpwJq5joflQ==; 5:Q8L+HLQpY/7AGryecZc+eWeyAYd4DN0qs+/wJvrzTMvaJoR8DgT4k4vQvPojR0I0VQyL5IkECkyds0OYC5w9CPD8M3IB4E/8tTphqNMuzJYvs5eh9DMe0Kcr08MBih+mJPjndsej+1n2BVB5DhPuQQ==; 24:UjiWvShwjIMKonSDcN37Uk8mV7MqjdxQqf6KHNYy/jnaijfCD3spL7zDOicC+WZIFPytg/yUlv1jLIm6IrtFxfkyLf2i2BcEb7AOUbishCs=; 7:4CLQZx7wwdpONCuHCI2A8qgiOeGZbVdwum3rTsMdn/4+JwjMwSma6Aq7WZggiJhoUXHaSkgaq3L3cAsrU2iyXsQCA0mRT/3ZaUSqQA8fD7qEP5mnYOpuWRNAufKWymW8CrDicijaqyc0rpI+VrqzGXfIXq+R/iKfyMyqgcaaQYadIrVVxZFEQeEyuFxVQRKHmGj9rAh2oN52PRHE0NnJYLSxvMGZFNQY//wLdtK5+w0=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: d98e1996-990a-4d6c-f5dc-08d516e40cb6
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR05MB3145;
x-ms-traffictypediagnostic: DM5PR05MB3145:
x-exchange-antispam-report-test: UriScan:(138986009662008)(82608151540597);
x-microsoft-antispam-prvs: <DM5PR05MB3145FD2319609973A210275CD4420@DM5PR05MB3145.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)(93006095)(93001095)(3002001)(100000703101)(100105400095)(10201501046)(6055026)(6041248)(20161123555025)(20161123562025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR05MB3145; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR05MB3145;
x-forefront-prvs: 0465429B7F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(199003)(18374002)(24454002)(13464003)(377454003)(189002)(66066001)(68736007)(7736002)(9686003)(106356001)(76176999)(229853002)(99286003)(110136005)(50986999)(105586002)(6116002)(55016002)(102836003)(54356999)(6506006)(81156014)(33656002)(86362001)(81166006)(305945005)(8936002)(3280700002)(25786009)(74316002)(3660700001)(6436002)(8676002)(2501003)(316002)(8656005)(478600001)(8656005)(2906002)(6246003)(53936002)(7696004)(14454004)(3846002)(93886005)(230783001)(53546010)(2950100002)(97736004)(5660300001)(2900100001)(77096006)(189998001)(101416001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3145; 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)
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: d98e1996-990a-4d6c-f5dc-08d516e40cb6
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2017 11:25:06.3839 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3145
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/YMuWU60WmWFdTnwsEvmh5SJ_Wl8>
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 11:25:10 -0000

Yup - perhaps add "since the EC could be used for other purposes".

Thanks!
Jeffrey

> -----Original Message-----
> From: Rabadan, Jorge (Nokia - US/Mountain View)
> [mailto:jorge.rabadan@nokia.com]
> Sent: Thursday, October 19, 2017 1:54 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
> 
> Yes, also since the MAC is not part of the NLRI, some co-authors suggested
> that.
> Do you think we should add?:
> “The presence of the Router's MAC EC alone is not enough to indicate the use
> of the mac address as the overlay index”
> 
> Thx
> Jorge
> 
> On 10/19/17, 4:37 AM, "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> wrote:
> 
>     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
>     >
> 
>