Re: [RTG-DIR] Rtgdir last call review of draft-ietf-bess-evpn-pref-df-09
"Rabadan, Jorge (Nokia - US/Sunnyvale)" <jorge.rabadan@nokia.com> Fri, 02 September 2022 18:21 UTC
Return-Path: <jorge.rabadan@nokia.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A364C14F738; Fri, 2 Sep 2022 11:21:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.479
X-Spam-Level:
X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.571, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TrYhB5hAK7ey; Fri, 2 Sep 2022 11:20:58 -0700 (PDT)
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (mail-co1nam11on2106.outbound.protection.outlook.com [40.107.220.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67B34C14F73A; Fri, 2 Sep 2022 11:20:54 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ocqaw0/sOTkhdpfssbvwa0QKcQ6EF68hJVOdB9bW7RvQwwJVe6gxxwg7WKS7ey8VSLE6mGpOs9fSQKm642vCRwY5XhdHbAYd5gBNLDHDXPtZlAtP2VBCuF+bNlMuBWnpa2a0rnsZ1W1gKA4KNQzkSJEqnNqUPl9y+afVnwS5dMTgpjbeordBLNEE/IVVn8rehKc83BhaspDozUptUyiStlEDKqWLms8acCZKrH9P8j3aKo64BcykohwimkqB2e48RAZsZaUYV+h8Wjqt/32cgbVd1Dw80epiU8b5dxxforSup3RJ+VfgmR39C+YigqmJrViy4w/Zy2I08sKccB7PZw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=wmyL6Apnipsf8M5LuAS6dfa2txzqkV51bVvDHceM2/w=; b=YyDeNPmpGMovPoAGzNqlqVR8XLnk43ligetlGdIIw10kOMczTLtu12C58z+aCIBWYJhWvb1jJV8tchhLScX31uPegmDAYwJt+sLtmkVygQ48oORmtuKQZSFr+0x3TqOHXj5LynwuaUqEBJMQTSFsFkQXgYU+rLwtx8j0sWlpJn8AZaM/FPCC+8PRMquKaPwsmlH1sWagkNfSjcj5ZSibApzFE09w6TDhHnN8m4RmH1kB1P7NJHnwVsLbg7kECLg0VZp+IfI1us5YFReNmgXzXn38EthNuv2doMworq1hxuNACmd99AkrLAixCe64V2tAHJbDWnB6RL2gYpxRX35FAg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nokia.com; dmarc=pass action=none header.from=nokia.com; dkim=pass header.d=nokia.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=wmyL6Apnipsf8M5LuAS6dfa2txzqkV51bVvDHceM2/w=; b=H3VtB5RyHFuX3tpP47d22LWbCsC+f2tJhC+tkewwX8/QRdgfuO75s9gNVArRiJbLCPIU060nbJrKDWHc7vWggzaDSKklQFaeEERggeKxGQUunvlD/e8vhXTo806dhXpC8/oB1F2aMH+PgwbkZIfJcc0kGgrY6M73VSGiJZh3QVM=
Received: from BY3PR08MB7060.namprd08.prod.outlook.com (2603:10b6:a03:36d::19) by DM6PR08MB6394.namprd08.prod.outlook.com (2603:10b6:5:1ee::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5588.10; Fri, 2 Sep 2022 18:20:50 +0000
Received: from BY3PR08MB7060.namprd08.prod.outlook.com ([fe80::3c57:d4d4:3c2f:354f]) by BY3PR08MB7060.namprd08.prod.outlook.com ([fe80::3c57:d4d4:3c2f:354f%4]) with mapi id 15.20.5588.016; Fri, 2 Sep 2022 18:20:50 +0000
From: "Rabadan, Jorge (Nokia - US/Sunnyvale)" <jorge.rabadan@nokia.com>
To: Stewart Bryant <stewart.bryant@gmail.com>, "rtg-dir@ietf.org" <rtg-dir@ietf.org>
CC: "bess@ietf.org" <bess@ietf.org>, "draft-ietf-bess-evpn-pref-df.all@ietf.org" <draft-ietf-bess-evpn-pref-df.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Thread-Topic: Rtgdir last call review of draft-ietf-bess-evpn-pref-df-09
Thread-Index: AQHYvF0EdnhPtmdF3EGqCw+6IUE+i63KpkkV
Date: Fri, 02 Sep 2022 18:20:50 +0000
Message-ID: <BY3PR08MB70606C9C9714A92B437CEB3DF77B9@BY3PR08MB7060.namprd08.prod.outlook.com>
References: <166185606372.44260.2038007862157405032@ietfa.amsl.com>
In-Reply-To: <166185606372.44260.2038007862157405032@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=nokia.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 70030413-412c-41ff-1ab9-08da8d0fdd2a
x-ms-traffictypediagnostic: DM6PR08MB6394:EE_
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: OanEx21IHB3YbnBEGpZaGlJX3HsW5Wvg3YC10ZpUFL1F6tHTxksCnO7CHNOgkhbG8rjLJBnu2IjcIRZzLoefc1Ac+zg+oSgz19pqvx2RtJIvjUioUD2DLKQPORd7kxP+9PWqWLon3l4No9XNB0+EmAmPsx1mFxFgC6IUHVOO9KXE7+9VpBPKcXZjsO5KQCrT6E9zYgeh1Xqy9RI221p7PFgguZqSzodF35HLYBKyT3f5idI11cv+TvBc+/MHfAkRFrk//4LlG5Kfjd/BtFZ2QhjNUmgnZWXYBFpGpNq55lP8LqwhOX64IHf3XP8DrT/SPxNhrBebx3Uz9x4LpQItswzft2k+FomGwQJCkZhrB7jXQ0U5/o20HgZH3Bz5r9yrCCX0cXR92CXRR+P5jhlSyX+XBCIjAxc0Z9qWYQGI7uOuRujdfS7+iyD3YFRn9U961dxA0TV13sll/3sZ5lpCDf26t5LrwOMrSImtwsr6kPibSvpzjn2OFDFCIA+fOkahpEfXinZwYK0IZQsGCKpkVLCWf1tqjuPQ20jOLt2egGV1rqJbJ3+pMRosyn/6YvEEassowLsTLftFD7WZndh6O2zKLjbD5+sRAqIexKsnKgN905pVfO4SqbuhJQdC6y8hzy8YiMMCE2eBZUh1Da6YOM5cJyJIINqayOT5hktpKRfY/nSEyunkRWIemT3SM+XPpxKrtqRV/4hmC+stU23S3Box4YbFmtk/EGV3onmvat6k5y0kaJ35ixSY4SgEsIfEGZWxRRTgwHL2QzJKwIYktQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY3PR08MB7060.namprd08.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230016)(4636009)(39860400002)(136003)(366004)(396003)(376002)(346002)(83380400001)(26005)(9686003)(186003)(82960400001)(86362001)(66574015)(38070700005)(38100700002)(122000001)(5660300002)(8936002)(110136005)(54906003)(52536014)(9326002)(2906002)(30864003)(55016003)(91956017)(8676002)(4326008)(66446008)(64756008)(76116006)(66946007)(66556008)(66476007)(316002)(41300700001)(7696005)(6506007)(53546011)(33656002)(71200400001)(478600001)(579004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: e+8RX310p9Tuo/jpDGmcXrNlct6T7O5zsupMfYOr+7kKWFVlifDfrMhUD6Fhmwpw4rwzJ6ubPZTZgBC8sgbs+Eb+julgkqWcy+tPeH0I0auf0YQsrieVVRJh/AED4RUt/c8PXssgfjwh9GlvJ7p8425/SDGpzRXNky8aGFf/mVenI3w/xA5RREUgl5FbfggCRRFMOKWDHHzT2hNkwVl2okNgEhiAEx24sRNm1j/EkUjLQhTBjpYyDR1mQArGLdJE9Hy41J9Is3Aj6FsjCOQA3qSoRMh6icd5BVISF09GdeBLKfHanmWiyYnCgZ4QzzRshikHVbAOxU/OG5xUM4ueZ3kAQx3+uEJ8+G4Ae/wh1nGLl4vqW6ECKGHCNK4Rs94cSdDpWpFi5yD1K6jAcNtaLKjlNJPVt11btTWMS5RfTXje67MGkKKckKYI06oiM8Uc09lVelTUGf4qvVF7OcjUPCDNH+c4kCIyl290eVE7/SPZJZXBAJrh2YL5K09oJBFJP/bJUOQPhI219ASMrT3o6/1HSHQLJeQkGTk6mcU3yLcCDNyZ9cHJKJGUUWKHCVRLJd+ktWBf7pzSIdiswNmYdKo7VVtB/JYALw+aaCsR3n6gzNcpiqqt8zLHubwMB9WQtaWUZHNlPW3S/+umcjE+Xe8rCyogj1/TSSk2GgXFd9vjOy3FQGmLaRMoUpSGHRSUxc3bf/Vnmdi5yXstDgF/syhdtB0ZUA2LrbNL+GkIFT/qMZ9LZOBu0DZqpBolL9am0AGjMiMRnZ7bvqv1FLHiKiJ2ARXAhQGU7k4PyU2daaIALlcObdDObfO7D6DVGdEKoP4ZJkfgZBJPYV7rfefpilDWoa1Ol0Ga0OEnocdqjkLzKkfi8qLJBr+/u6ae7tdzsj8YeczMzL/h38UcOimpCb8fAXZf01NAozyadGva0jrck0+me40lbkmEiGIc1hZG19MWp+1EjTTvDg/hxaZSdvzC7SmtRmCIJArkqz1fPGac8y4rseJjF1eXZykDy2TD/0I3X5YDntCsvposjkJ0S8FpyBbZIYw3NoJl//53npxsvAWgG853bz9S6xPq8QcBx/XgJt2V1Ruu85sx0pjvb+rfkjlGe3ow8xzIGXa1iaX0QMM+4+2p4H0Pu4cFh5xb65D+7j/JgDaIzOyzdsB1F22WO+VoRQw+dV6y3TZqKpRb/J6MQlg2zXoj1Q8OVW8xqymXQRVxV/p1H3HN8/mu1LQEZKIv6enfWFPwl7vCGPV4ejwXHMDVyKkRra1Q6zZ1SHrYYV6m8AUsdFFgFsDpMdB9ExRvoTTD8317UceQ+j/odyaYnZX1y7qCzVVkJ9rS7Izxs0wqsYDWc2nTYVbhePuMsBdZReXpjzyLaTRnLXVtEc4SMASKlV4CppdIlbtCCxp6PBcRK0GJGKcd1wBse96yzkKgjQvWxd5/ThGZbFwSwgoiFJpStcMC+/GPAKAHIoHJPJ0cjYrY3vLCbsr4/pIDL5ki/+opBlUjj418x+KGRZ+lVEv6TdsYjnegJlpYFV69i4qQZlw9UqW9QtuCIYLh2XmQ07AmzUrady/2RjqHOen8lCMlHU//oAPTmhsMdLjQQwfxwUXse3IZU4z79pC6+0JrYgna7BDqugoQafQ=
Content-Type: multipart/alternative; boundary="_000_BY3PR08MB70606C9C9714A92B437CEB3DF77B9BY3PR08MB7060namp_"
MIME-Version: 1.0
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY3PR08MB7060.namprd08.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 70030413-412c-41ff-1ab9-08da8d0fdd2a
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Sep 2022 18:20:50.0271 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: yQP7SbrqGKIaQPvwuJseGiGhxiaXnuGtCKJA6NPten4YtRS3H0kMzgkXgVomTwY44p1a35ur6WHN1JfOmqxLCA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR08MB6394
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/_3cjOioFWQuseOmIKyZPVVAV3sg>
Subject: Re: [RTG-DIR] Rtgdir last call review of draft-ietf-bess-evpn-pref-df-09
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Sep 2022 18:21:03 -0000
Hi Stewart, Thanks for reviewing. Changes are incorporated in version 10 that we just published. Please see my comments in-line with [jorge]. Thx Jorge From: Stewart Bryant via Datatracker <noreply@ietf.org> Date: Tuesday, August 30, 2022 at 12:41 PM To: rtg-dir@ietf.org <rtg-dir@ietf.org> Cc: bess@ietf.org <bess@ietf.org>, draft-ietf-bess-evpn-pref-df.all@ietf.org <draft-ietf-bess-evpn-pref-df.all@ietf.org>, last-call@ietf.org <last-call@ietf.org> Subject: Rtgdir last call review of draft-ietf-bess-evpn-pref-df-09 Reviewer: Stewart Bryant Review result: Has Issues I am entering these last call comments as part of the Routing Area review process. I regret that it isthis text is not yet ready to proceed to the next stage of the IETF Review Process. I think that editorial work is needed to clarify the document for the reader. One particular comment is that the authors tend to describe behaviour in terms of bit values and not in terms of bit semantics or bit name when describing the operation of the protocol. In general, people tend to think and code in terms of names rather than 1s and 0s. Detailed comments below ======= BESS Workgroup J. Rabadan, Ed. Internet-Draft S. Sathappan Intended status: Standards Track Nokia Expires: 7 January 2023 T. Przygienda W. Lin J. Drake Juniper Networks A. Sajassi S. Mohanty Cisco Systems 6 July 2022 SB> There are too many front page authors. [jorge] version 10 has moved two authors to the contributors section. ======== 1.1. Problem Statement <snip> While the Default DF Alg [RFC7432] or HRW [RFC8584] provide an efficient and automated way of selecting the DF across different Ethernet Tags in the ES, there are some use-cases where a more 'deterministic' and user-controlled method is required. At the same time, Service Providers require an easy way to force an on-demand DF switchover in order to carry out some maintenance tasks on the existing DF or control whether a new active PE can preempt the existing DF PE. This document proposes a new DF Alg and capability to address the above needs. SB> As far as I can see you propose two algorithms and I cannot see in the above how you map each algorithm to a particular set of sub-use-cases. [jorge] I replaced the last sentence with: “This document proposes two new DF Algs (Highest-Preference and Lowest-Preference) which provide the deterministic Designated Forwarder method required, as well as the "Don't Preempt" capability to address the need to control whether a PE can take over an existing Designated Forwarder PE.” ======= 1.2. Solution requirements <snip> d. The solution allows an option to NOT preempt the current DF, even if the former DF PE comes back up after a failure. This is also known as "non-revertive" behavior, as opposed to the [RFC7432] DF election procedures that are always revertive. SB> It is useful to say why. SB> Again in this section the two algorithms need to map to use cases. [jorge] the section has been changed accordingly. ========== 2. Requirements Language and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. SB> Nits does not like the above boilerplate. I would be helpful to other reviewers to address so they do not have to investigate the warning. [jorge] it is fixed now, thanks. ======= * DF Alg or simply Alg - refers to Designated Forwarder Election Algorithm. SB> “simply Alg” is confusing since it is not clear if simply is part of the name. How about * DF Alg - refers to Designated Forwarder Election Algorithm. This is sometimes shortened to “Alg” in this document. Alternatively consider always using the term DF Alg, or if you want to save space use something like DFA in the text. [jorge] I took your text, thx ========== 3. EVPN BGP Attributes Extensions This solution reuses and extends the DF Election Extended Community defined in [RFC8584] that is advertised along with the ES route: SB> I think you need some text of the form: by replacing the last two reserved octets of the DF EEC when the DF Alg is set to Alg TBD. [jorge] added SB> RFC8584 does not specify the value of the the reserved fields, and how they are to be processed. All the notation RSV/Reserved is unclear if this concerns just bits 16..18 or bits 16..18 and bits 40..63. Perhaps you need to use this text to update RFC 8584. [jorge] I added this: “When DF Alg is set to Highest-Preference or Lowest-Preference algorithm, the value of the RSV and Reserved fields (from bit 16 to bit 18, and from bit 40 to 47) are set to zero when advertising the Ethernet Segment route and they are ignored when receiving the Ethernet Segment route.” [jorge] In a nutshell, RFC8584 implicitly ignores the RSV/Reserved bits for the algorithms that defines, and says other Algs may repurpose them.. I don’t think we should update RFC8584, but happy to discuss with the WG. ========== 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D|A| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Bitmap field in the DF Election Extended Community SB> Where is the semantics of Bit 0 defined for Alg 2? [jorge] hmm.. not sure if I understand. I added this: “The procedures of the "Don't Preempt" capability for DF Alg 2 and TBD are described in section 4.4" * Bit 0 (corresponds to Bit 24 of the DF Election Extended Community and it is defined by this document): D bit or 'Don't Preempt' bit (DP hereafter), determines if the PE advertising the ES route requests the remote PEs in the ES not to preempt it as DF. The default value is DP=0, which is compatible with the 'preempt' or 'revertive' behavior in the Default DF Alg [RFC7432]. The DP capability is supported by Alg 2 and Alg TBD, and MAY be used with DF Alg 0 or 1. The procedures of the DP capability for DF Alg 0 or 1 are out of the scope of this document. SB>I am confused by the following text. SB> I think that you need to explain more clearly what behaviour is defined in RFC8584 and continues here, what behaviour has changed and what new behaviour is introduced. Also, where is Alg2 defined. [jorge] noted. I changed the entire section, let me know if addresses your concerns. * Bit 1: AC-DF or AC-Influenced DF Election, as explained in [RFC8584]. When set to 1, it indicates the desire to use AC- Influenced DF Election with the rest of the PEs in the ES. The AC-DF capability bit MAY be set along with the DP capability and DF Alg 2 or Alg TBD. - DF Preference (defined in this document): defines a 2-octet value that indicates the PE preference to become the DF in the ES. The allowed values are within the range 0-65535, and the default value MUST be 32767. This value is the midpoint in the allowed Preference range of values, which gives the operator the flexibility of choosing a significant number of values, above or below the default Preference. The DF Preference field is specific to DF Alg 2 and DF Alg TBD, and does not represent any Preference value for other Algs. If the DF Alg is different than Alg 2 or Alg TBD, these two octets can be encoded differently. SB> The last sentence is confusing and I think redundant. Those octets are defined for the case Alg2 and Alg TBD, but clearly the are not defined for anything that precedes this design and any future design is free to give them new semantics. SB> As far as I can see the text has not said whether 0 is more preferred than 65535 or the other way about. [jorge] the new text addressing your comments follow: * Designated Forwarder (DF) Preference (described in this document): defines a 2-octet value that indicates the PE preference to become the Designated Forwarder in the Ethernet Segment, as described in Section 4.1 and Section 4.2. The allowed values are within the range 0-65535, and the default value MUST be 32767. This value is the midpoint in the allowed Preference range of values, which gives the operator the flexibility of choosing a significant number of values, above or below the default Preference. A numerically higher or lower value of this field is more preferred for Designated Forwarder election depending on the DF Alg being used, as explained in Section 4.1 and Section 4.2. The Designated Forwarder Preference field is specific to DF Algs Highest-Preference and Lowest-Preference, and this document does not define any meaning for other algorithms. If the DF Alg is different from Highest-Preference or Lowest-Preference, these two octets can be encoded differently. ============ a. vES1 and vES2 are now configurable with three optional parameters that are signaled in the DF Election extended community. These parameters are the Preference, Preemption option (or "Don't Preempt Me" option) and DF Alg. We will represent these parameters as (Pref,DP,Alg). Let's assume vES1 is configured as (500,0,Highest-Pref) in PE1, and (255,0,Highest-Pref) in PE2. SB> Where does the 0 come from in your notation? [jorge] it is the DP capability bit. I added this to clarify: “Let's assume vES1 (Pref,DP,Alg) is configured as (500,0,Highest-Preference) in PE1,…” ======== c. According to [RFC8584], each PE will run the DF election algorithm upon expiration of the DF Wait timer. In this case, each PE runs the Highest-Preference DF Alg for each ES as follows: * The PE will check the DF Alg value in each ES route, and assuming all the ES routes are consistent in this DF Alg and the value is 2 (Highest-Preference), the PE will run the procedure in this section. Otherwise, the procedure will fall back to [RFC7432] Default Alg. SB> I think that it is confusing to use packet identifier values (2) rather than the name of the identifier value. [jorge] changed. =========== d. Assuming some maintenance tasks had to be executed on, E.g., PE3, the operator could set vES2's Preference to E.g., 50 so that PE2 is forced to take over as DF for vES2 (irrespective of the DP capability). Once the maintenance task on PE3 is over, the operator could decide to leave the existing preference or configure the old preference back. SB> On which PE does the advertisement change? [jorge] on PE3. I modified the text to clarify. e. In case of equal Preference in two or more PEs in the ES, the DP bit and the lowest IP of the candidate PEs are used as tie- breakers. SB> That is the lowest IP address I assume. That is easy on IPv4. Are there any issues with doing this in IPv6? [jorge] the only issue is in the case there are PEs with originating router’s ip addresses of different families. In this case I added this: “…The PE's IP address is the address used in the candidate list and it is derived from the Originating Router's IP address of the Ethernet Segment route. In case PEs use Originating Router's IP address of different families, an IPv4 address is always considered numerically lower than an IPv6 address…” After selecting the PEs with the highest Preference value, an implementation MUST first select the PE advertising the DP bit set, and then select the PE with the lowest IP address (if the DP bit selection does not yield a unique candidate). SB> Of perhaps more intuitively if more that one PE is advertising itself as the preferred forwarder. [jorge] added The PE's IP address is the address used in the candidate list and it is derived from the Originating Router's IP address of the ES route. Some examples of the use of the DP bit and IP address tie-breakers follow: * If vES1 parameters were (500,0,Highest-Pref) in PE1 and (500,1,Highest-Pref) in PE2, PE2 would be elected due to the DP bit. * If vES1 parameters were (500,0,Highest-Pref) in PE1 and (500,0,Highest-Pref) in PE2, PE1 would be elected, assuming SB> s/assuming/if/ SB> Although it might be better to describe both cases. PE1's IP address is lower than PE2's. [jorge] I took both suggestions. f. The Preference is an administrative option that MUST be configured on a per-ES basis from the management plane, but MAY also be dynamically changed based on the use of local policies. SB> It is confusing to jump from the global statement above direct to a number example without explaining first what is happening. [jorge] I modify the text to address this comment. Please let me know if it reads better. For instance, on PE1, ES1's Preference can be lowered from 500 to 100 in case the bandwidth on the ENNI port is decreased a 50% (that could happen if e.g. the 2-port LAG between PE1 and the Aggregation Network loses one port). Policies MAY also trigger dynamic Preference changes based on the PE's bandwidth availability in the core, specific ports going operationally down, etc. The definition of the actual local policies is out of scope of this document. The default Preference value is 32767. =========== 4.2. Use of the Lowest-Preference Algorithm In addition to the Highest-Preference Alg described in Section 4.1 this document defines the Lowest-Preference Alg. SB> I think that it would be clearer to describe the section algorithm as the generic selection algorithm rather than binding it to HP and then have this almost “dummy” section. [jorge] ok, done. In this case, and using the example of vES1 in Figure 3, if the Lowest-Preference Alg is configured in all the PEs in the ES, PE2 will be the DF due to its lower Preference. SB> I can see why you might have an HP choice, but you should explain use case for the lowest preference. Indeed since this text introduces both it would be useful to see text explaining why one is chosen over the other. [jorge] both can be used, it’s the operator’s choice. I added some text to reflect that. =========== * In addition, assuming VLAN-based service interfaces and that the PEs are attached to all Ethernet Tags in the range 1-4000, both PE1 and PE2 will be configured with (Ethernet Tag-range,low), E.g., (2001-4000, low). SB> I think that this needs to be described in general terms first and then the case study included. [jorge] done. Please let us know if it reads better. ========== 4.4. The Non-Revertive Capability As discussed in Section 1.2 (d), a capability to NOT preempt the existing DF (for all the Ethernet Tags in the ES) is required and therefore added to the DF Election extended community. This option will allow a non-revertive behavior in the DF election. Note that, when a given PE in an ES is taken down for maintenance operations, before bringing it back, the Preference may be changed in order to provide a non-revertive behavior. SB> Doesn’t this result in long term instability/inconsistency in the network configuration if you change the value each time you do maintenance? [jorge] from what I’ve seen, some people would change the preference on the PE under maintenance mode to give up the DF state, and then if that PE reboots, it won’t affect the CE in the Ethernet Segment. Some operators want to change back the preference so that the PE becomes DF again and if so, they usually do it in maintenance windows to avoid impact. ======== 1. A "Don't Preempt Me" capability is defined on a per-PE/per-ES basis, as described in Section 3. If "Don't Preempt Me" is disabled (default behavior), the advertised DP bit will be 0. SB> I feel that it is better to talk about bit states in terms of semantics rather than binary values like 0 and 1. [jorge] changed If "Don't Preempt Me" is enabled, the ES route will be advertised with DP=1 ("Don't Preempt Me"). All the PEs in an ES SHOULD be consistent in their configuration of the DP capability, however this document does not enforce the consistency across all the PEs. In case of inconsistency in the support of the DP capability in the PEs of the same ES, non-revertive behavior is not guaranteed. However, PEs supporting this capability will still attempt this procedure. =========== 5. Security Considerations This document describes a DF Election Algorithm that provides absolute control (by configuration) over what PE is the DF for a given Ethernet Tag. While this control is desired in many situations, a malicious user that gets access to the configuration of a PE in the ES may change the behavior of the network. In other DF Algs such as HRW, the DF Election is more automated and cannot be determined by configuration. The non-revertive capability described in this document may be seen as a security improvement over the regular EVPN revertive DF Election: an intentional link (or node) "flapping" on a PE will only cause service disruption once, when the PE goes to NDF state. SB> What is NDF? [jorge] non-Designated Forwarder. I expanded it. The document also describes how a local policy can override the Highest-Preference Alg for a range of Ethernet Tags in the ES. If the local policy is not consistent across all PEs in the ES and there is an Ethernet Tag that ends up with an inconsistent use of Highest- Preference or Lowest-Preference in different PEs, black-holing or packet duplication may occur for that Ethernet Tag. SB> There may be some security considerations that need to be taken into account when you manipulate parameters in the middle of mainatance as is proposed in the text. [jorge] Added: “With Highest-Preference or Lowest-Preference as DF Alg, an attacker may change the configuration of the Preference value on a PE and Ethernet Segment, and impact the traffic going through that PE and Ethernet Segment.” ====== 6. IANA Considerations SB> It helps everyone if you specify the namespace (Border Gateway Protocol (BGP) Extended Communities) and then the registry and then set out your request just like it would appear in the registry itself: Bit Name Ref 2 Highest Preference This RFC Etc [jorge] done This document solicits the allocation of the following values: * DF Alg = 2 in the [RFC8584] "DF Alg" registry, with name "Highest- Preference Algorithm". * DF Alg = TBD in the same "DF Alg" registry, with name "Lowest- Preference Algorithm". * Bit 0 in the [RFC8584] DF Election Capabilities registry, with name "D (Don't Preempt) Capability" for Non-revertive ES. ========
- [RTG-DIR] Rtgdir last call review of draft-ietf-b… Stewart Bryant via Datatracker
- Re: [RTG-DIR] Rtgdir last call review of draft-ie… Rabadan, Jorge (Nokia - US/Sunnyvale)