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

"Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com> Thu, 19 October 2017 18:05 UTC

Return-Path: <jorge.rabadan@nokia.com>
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 C289B132320 for <bess@ietfa.amsl.com>; Thu, 19 Oct 2017 11:05:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.911
X-Spam-Level:
X-Spam-Status: No, score=-2.911 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_H5=-1, 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=nokia.onmicrosoft.com
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 WEMBhhJ5BGh3 for <bess@ietfa.amsl.com>; Thu, 19 Oct 2017 11:05:56 -0700 (PDT)
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50126.outbound.protection.outlook.com [40.107.5.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AF4E13234B for <bess@ietf.org>; Thu, 19 Oct 2017 11:05:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9Mn8Eic7S1icSnt/AAxT01Z5mTr761DlpM2lSWS/KjU=; b=cziZGh2IMvQO1ylSlRrQn2ZK2ArQTFpj27ZZqyr6f6cAu7HIQlNT1j0CpRPz9krVvbeqplwGV3uy3LiLoNZVxCJV2UYFvDincSG9YE1ZxUtZ6f3C8Jp9Cf/l5wjquQ4DEbHKTLPRv+kmurANERwOdNDuMHylAxzMfzKhxAOJb2M=
Received: from AM4PR07MB3409.eurprd07.prod.outlook.com (10.171.189.158) by AM4PR07MB3410.eurprd07.prod.outlook.com (10.171.189.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Thu, 19 Oct 2017 18:05:53 +0000
Received: from AM4PR07MB3409.eurprd07.prod.outlook.com ([fe80::402c:4354:3ac7:783f]) by AM4PR07MB3409.eurprd07.prod.outlook.com ([fe80::402c:4354:3ac7:783f%13]) with mapi id 15.20.0156.004; Thu, 19 Oct 2017 18:05:53 +0000
From: "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.rabadan@nokia.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, "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: AdNDWJtgzjJlkeiVRDaWqq9GqYzXUwDOzhWAAAAsZZAAIt6NAAAIWNPwAASNRgAAS8BWAAAHAdcAAAuEBFAADg14AA==
Date: Thu, 19 Oct 2017 18:05:53 +0000
Message-ID: <41973787-5A65-4C74-A617-E877761D1540@nokia.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> <DM5PR05MB314517B4A2E3CEBC5AE9A769D4420@DM5PR05MB3145.namprd05.prod.outlook.com>
In-Reply-To: <DM5PR05MB314517B4A2E3CEBC5AE9A769D4420@DM5PR05MB3145.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.27.0.171010
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jorge.rabadan@nokia.com;
x-originating-ip: [83.60.89.75]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM4PR07MB3410; 6:iKag3Q9cvoDnzFJlYjG4GRDL8gBLtZodRYwmZfPPMXwLpVaz960/IV6otMTygZR6QS+OeIzGzp6ZxujaWP/erwcM0b4EJ+tqDyR1Urfg86hEG4AY1a/x1ITJK1nwQdFfBDDzwuwstjHyL2pWUWt2rTGtfUkXCIaliUJuSdHGc221AYYDJ7+QpjkMTGQFzh0Ew0Ah2D5nR9kWaBhIBC739hRWYu81pzxqYIzGSyu6M1k/OWFeOEgr6W6LnR9TOmooPvD1ZEd641Nt39NhHTbSAzy1kRfxpD8Sirf9+ZYfXa1Yg968dc6Cb4SFBb+dkf0c7scLVdL3QVJDfoYx+2gd9A==; 5:l972sr3YipnmGOtKnZvrZjVLKM+ba3S8dYg/QTjmlQ+VsSd2X3hpQGkBcubBUe2m3D4x4B8/YTGEhJa7nPG3f0v+A4IptpCPJZcp8psJ80Z8or/bcFhr5boPUX49osVNRvQNTHVJNXho+kczby216g==; 24:Oi2ki9S6Nv34JnhYQ7cvFy6T2fhgScNMQIl+xiBa9Leyw343Yoih4acbPEdOrYbRNGmbTCZ0PGeFi8/FiQ43hpKSI3Lke+J7ow0PTrlbj0k=; 7:hXHsYK2JqzWALxsEWB7Sbvz4rarDOaE5WUiidstC9rt9PyXvkwIEB/5KnFMSXz9QkPYFKTSR/SqCOieBn6SjaIemYfvwZN3p/mCc00IwO4JwvBDIgYCwG+zqivD7eUj+OeLE1fNINBIYSyhaNdBXv7LGsdOg9eqK3Hw00NFm2A6qOGL9pEFX/hD4oQAI+cfqpX8V/n0qERmvnn5JS27YwQj9nnYP7gfJqXC0uFOWUks=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(189002)(18374002)(199003)(24454002)(13464003)(6486002)(2906002)(6512007)(58126008)(6436002)(53546010)(81156014)(93886005)(82746002)(83716003)(7736002)(6246003)(8936002)(81166006)(230783001)(53936002)(478600001)(316002)(97736004)(229853002)(86362001)(6506006)(83506002)(8676002)(110136005)(25786009)(5250100002)(1941001)(2501003)(36756003)(14454004)(66066001)(5660300001)(76176999)(3846002)(54356999)(50986999)(6116002)(68736007)(102836003)(101416001)(305945005)(8666007)(2900100001)(3660700001)(189998001)(3280700002)(2950100002)(99286003)(105586002)(106356001)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM4PR07MB3410; H:AM4PR07MB3409.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
x-ms-office365-filtering-correlation-id: 6014afdc-64bd-429d-7990-08d5171c09d5
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254172)(48565401081)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199)(201703131423095); SRVR:AM4PR07MB3410;
x-ms-traffictypediagnostic: AM4PR07MB3410:
x-exchange-antispam-report-test: UriScan:(138986009662008)(82608151540597);
x-microsoft-antispam-prvs: <AM4PR07MB34101F5DB815A8C227E8B1C7F7420@AM4PR07MB3410.eurprd07.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)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123555025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM4PR07MB3410; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM4PR07MB3410;
x-forefront-prvs: 0465429B7F
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <CCB2DC79F733FA428F734783B8037DD9@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6014afdc-64bd-429d-7990-08d5171c09d5
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2017 18:05:53.3989 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3410
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/ohQ85-S5VrLrdEYP1aNVSksEguc>
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 18:05:59 -0000

OK, just published rev 07 with the latest changes you suggested.
I guess it is ready from your perspective now?

Thank you, Jeffrey, for the detailed review!

Jorge

On 10/19/17, 1:25 PM, "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> wrote:

    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
    >     >
    > 
    >