Re: [Idr] AD Review of draft-ietf-idr-bgpls-segment-routing-epe-17
"Ketan Talaulikar (ketant)" <ketant@cisco.com> Fri, 08 March 2019 16:05 UTC
Return-Path: <ketant@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7CD4126CFF; Fri, 8 Mar 2019 08:05:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=HOKPF2NZ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=BINTy0Iq
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 YxMPWb3PfAXC; Fri, 8 Mar 2019 08:05:26 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF39F124B91; Fri, 8 Mar 2019 08:05:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16390; q=dns/txt; s=iport; t=1552061126; x=1553270726; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=EJh10QcvEnRLbnCO7z1WQG2YfdwaUK6befhWUmNI8yo=; b=HOKPF2NZQjI83g+9l04EDM6nBnJKt12r5EqXHiFamjxl3aulGWtFsfBT KmO6Arbyib1SiZu5yciVpGZbTPV9jDdj3O8QVdnAvA7xt9+PjYW066v01 KLpJBLO1QbZjGokDpIYasokHMuYX5eFjNvkfHJuGH3F6YwwGTvXTNsvxh s=;
IronPort-PHdr: 9a23:mo6f9xONR+BEyDT5Cqol6mtXPHoupqn0MwgJ65Eul7NJdOG58o//OFDEuKQ/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETBoZkYMTlg0kDtSCDBj4IeLjaTASF8VZX1gj9Ha+YgBY
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AEAADgkYJc/4UNJK1kGgEBAQEBAgEBAQEHAgEBAQGBUQUBAQEBCwGBPCQsA4FcBAsnhAmDRwOEUIpkgld8iDWOdRSBEANUCwEBLIRAAheEHiI0CQ0BAQMBAQcBAwJtHAyFSgEBAQQOFREMAQEjFAELBAIBCA4DAQMBAQMCJgICAh8RFQIGCAIEAQ0FCBOEZQMVAQKfOAKKFHGBL4J4AQEFhQMNC4ILCIELJAGLKxeBQD+BEUaCFzWCV4FyBQELBwEhgwgxgiaJeBKCQYsyi3AzCQKLSIQBg1eBeIVnBYtUineHFIstAgQCBAUCDQEBBYFHOGVxcBU7gmyCCgwXg0uKUgFygSiMIw8XgicBAQ
X-IronPort-AV: E=Sophos;i="5.58,456,1544486400"; d="scan'208";a="447207879"
Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Mar 2019 16:05:24 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x28G5OGi020721 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Mar 2019 16:05:24 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 8 Mar 2019 10:05:23 -0600
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 8 Mar 2019 11:05:22 -0500
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 8 Mar 2019 10:05:22 -0600
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EJh10QcvEnRLbnCO7z1WQG2YfdwaUK6befhWUmNI8yo=; b=BINTy0IqQhSYucTjyktFeMuPa3tRgRoRMkBfLpNcAFFK+Z2no8Rk9DQ96hgRFwUYW8cwxOlxFsxmoy9Vy8kyL2IskTxJDXThs0m8aXor5JyLL4IjT8bvlU7DurZnfukjYNJYlTQE5LCA7MGjPRoFLiSUFnyUt45slC5ZSmGLa1E=
Received: from SN6PR11MB2845.namprd11.prod.outlook.com (52.135.93.24) by SN6PR11MB2910.namprd11.prod.outlook.com (52.135.123.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.19; Fri, 8 Mar 2019 16:05:20 +0000
Received: from SN6PR11MB2845.namprd11.prod.outlook.com ([fe80::117:6d33:4c0a:a1b3]) by SN6PR11MB2845.namprd11.prod.outlook.com ([fe80::117:6d33:4c0a:a1b3%3]) with mapi id 15.20.1686.018; Fri, 8 Mar 2019 16:05:19 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: Alvaro Retana <aretana.ietf@gmail.com>, "draft-ietf-idr-bgpls-segment-routing-epe@ietf.org" <draft-ietf-idr-bgpls-segment-routing-epe@ietf.org>
CC: Susan Hares <shares@ndzh.com>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf. org" <idr@ietf.org>
Thread-Topic: AD Review of draft-ietf-idr-bgpls-segment-routing-epe-17
Thread-Index: AQHU0Ha9/G2LBJn9e02rUnXHkkHljaX7BV+QgAbqlaA=
Date: Fri, 08 Mar 2019 16:05:19 +0000
Message-ID: <SN6PR11MB2845BD0B75C5EEEC9E53DEF6C14D0@SN6PR11MB2845.namprd11.prod.outlook.com>
References: <CAMMESsw-8R=+K7CH-rkZVWXXYTA_iNXLG2SVJexCUs7g795Jdw@mail.gmail.com> <SN6PR11MB28459C76158F5E7832107FCAC1710@SN6PR11MB2845.namprd11.prod.outlook.com>
In-Reply-To: <SN6PR11MB28459C76158F5E7832107FCAC1710@SN6PR11MB2845.namprd11.prod.outlook.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=ketant@cisco.com;
x-originating-ip: [2001:420:c0e0:1004::aa]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d733a186-c5e9-4758-49fb-08d6a3dfdcf4
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:SN6PR11MB2910;
x-ms-traffictypediagnostic: SN6PR11MB2910:
x-microsoft-exchange-diagnostics: 1;SN6PR11MB2910;23:djbSuAHGNOYyJEIKLi2ATVbQ7fpi3BGeRX2aX9hewj0sNSX4USE7Hv8nuKF6Nzf/0WX4VPiNFgGDYemg21K8KSrL81CH+loS8TaOk8JS+Ab+PmlwUmB7+VVp6HMnieVxDGgH7A9lvktROIV2xjr9b+9TkZA2k8WslsrSE7dridzNJ1T1P1k3bSVXhcsITo0gE1485DhiDwzaIEjqIJK1P24l/oY1lZCQ194RG6G0GhYFXzT6cm5x1QwC13PiVCWeWbYnc+isd4zEOrRlVJicaT7gBgAnLuEaInv8bv3g7sluc9uirdXvKgNgoDq1sIL/J8PgzkWZq16o1P1Qa7V+iJEftbQqF9TMIxRvk9dBOZv4F6sVns1V1EEf9D+XG6xny6KBEMsOzVlpZK7HlUAkebNwrSWrZY5g/au8PG8QP1musR18HEegohDLZcriX07RCLI84/7OrctjjIXl359qNZGQI92d2YN/P2k97Q6NIjhYQ/ACYJvV6l9D2ivngGHz/2jctXAi6i+XC6g3YjEp5LCVay9zpwA08EWZz9tuxNnhi3OPhBAibq4iX6jiLl7Gclhr16LBpMmbzqxkBFy0vHdkoD2Y8UwNNOjV48ODYaY0Z3IPDn36/4PkChxtKdKqhJP4cqZWzDyisKAXmQhuKsPvT61UrV2zmqThlpPwp6AhpZ1SMWWHGtcratp44vpDMW0GMT0SnSENysnp8/790ZlOGfwBH6J5bLIkk4+zitTMZaBGl6W42vlyx2JTT4oAOL6N9IDRFUiOd/XXtxUfVxbOO0Whz/VFrXdG2H46JtoUzwRqxYOgtj9sqkl441nRuLEJfNNs74FOl9H7P3sE8HfLbE/z1SRRpn5n15bp8BM2lByw2lITcycc6ayW7MLL2Pix1Cmdc1CbeI9M94Y947CVWaVocvYMJwt4xMlcJ85vjRkL5Vlk83lRvSJnjpDrikd+DRNpp0mimM/jkeeU5wEV0UeSdj5BlvJttSfyVcb1j/5kbcXLj2NO1MGXDdGmgmyi1EFyI6MDoPLbweFWXcmVYtZHhYc7D9vhod2KBLul1yJsf0HIEuJbg23oVPXirEyC0ZgQQ2JDDkX2mavSCGt9EZb3mJxUg2/sx5mYk7yE45/z6dQtPFN/HyeRjmOpYcPFs3cGmcS03xOOENLbjMVyWmCoknXxAS3CUUPxgj5HCCMiabAiNqjaq3tq/zbmvHaCSimDafdv+HaTPGYd3AN1X10QIp0PqXQVoObRBzdHpH/MVv9F1hPxBvTuEkE+XksVfhy2iZAbVKzVpxqmzMQNvZGO5P3ttG42QX4BOgyrDx78LQmhb+aFllyRJy7/
x-microsoft-antispam-prvs: <SN6PR11MB29100CA67AF8483A50622C78C14D0@SN6PR11MB2910.namprd11.prod.outlook.com>
x-forefront-prvs: 0970508454
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(396003)(376002)(346002)(366004)(199004)(189003)(51444003)(13464003)(14454004)(68736007)(33656002)(97736004)(6436002)(53936002)(7736002)(55016002)(9686003)(71190400001)(71200400001)(5660300002)(52536013)(105586002)(30864003)(106356001)(66574012)(4326008)(25786009)(6116002)(478600001)(305945005)(74316002)(6246003)(5024004)(14444005)(256004)(8936002)(2501003)(229853002)(54906003)(2906002)(476003)(86362001)(81156014)(81166006)(486006)(316002)(446003)(76176011)(186003)(7696005)(53546011)(6506007)(102836004)(8676002)(11346002)(99286004)(110136005)(46003); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR11MB2910; H:SN6PR11MB2845.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: Wdfu9ZpbYb+V93hlHHarmnJTieTJdbyApYDFk45Vm37XuaL2Y6RBnbpsHAwHYrEF8EjyBSeYSgJrdzpqN6tdnP6oKN3B9Jn0TGjkHErjiyx8YjICowFYqvPyTxlpwh0TWA2QYxnkXsCevzi4k7pkrOL+a4hOwv3rV0RhxYloKEt0oMpWxmO2nk2dANYXXjWAhGTJJGCae0SNy7ynROKaFWo5mQAtOEv0yKFciPl1H/0hXT1Fu6tsQ4J1Npby+0egve5ETQS6xliYnjOlEu4SvMp6reGKbVN/XtqhiTTYGGaS//Jl/OWhOAs3wqmSRwS9Fqkr61mZBWH6yAK987IsvPjaCbPu3etr7dNuw50FuYjEneGATbaIKCX3zeCtldAVG2vXYVBc+VayefV1tU5X3qtIagm6/wlOd2AojJBmFKk=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: d733a186-c5e9-4758-49fb-08d6a3dfdcf4
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2019 16:05:19.7514 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB2910
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com
X-Outbound-Node: alln-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/LBLl1mf8fyPcrUzLZNixCRq9ebQ>
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgpls-segment-routing-epe-17
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 08 Mar 2019 16:05:30 -0000
Hi Alvaro, I get the impression that your review and comments might have got truncated in the email that you sent below. It goes only till Sec 4.2 and you have referred to Sec 5 at the start of your email. Could you please check/confirm that you have sent your entire set of review comments? Thanks, Ketan -----Original Message----- From: Ketan Talaulikar (ketant) Sent: 04 March 2019 11:57 To: 'Alvaro Retana' <aretana.ietf@gmail.com>; draft-ietf-idr-bgpls-segment-routing-epe@ietf.org Cc: Susan Hares <shares@ndzh.com>; idr-chairs@ietf.org; idr@ietf. org <idr@ietf.org> Subject: RE: AD Review of draft-ietf-idr-bgpls-segment-routing-epe-17 Hi Alvaro, Thanks for your detail review and feedback/comments. I will work on them along with co-authors and get back with updates. Thanks, Ketan -----Original Message----- From: Alvaro Retana <aretana.ietf@gmail.com> Sent: 02 March 2019 03:05 To: draft-ietf-idr-bgpls-segment-routing-epe@ietf.org Cc: Susan Hares <shares@ndzh.com>; idr-chairs@ietf.org; idr@ietf. org <idr@ietf.org> Subject: AD Review of draft-ietf-idr-bgpls-segment-routing-epe-17 Dear authors: I just finished reviewing this document. Please take a look at in-line comments below. In general, I think that the document needs work in being consistent with terminology and its use. Also, more details are needed in the Management and Security sections. I have major concerns about the references to draft-ietf-spring-segment-routing-central-epe. In the current text, draft-ietf-spring-segment-routing-central-epe is not only referenced as an example of the use of the SIDs defined here, but in a Normative way to indicate how the TLVs should be treated. The obvious question is about the applicability of the extensions (see the text in §5 about "other use cases"). The importance given to I-D.ietf-spring-segment-routing-central-epe in this document, which should elevate it to a Normative reference, is probably more than it deserves since it just "illustrates the application of Segment Routing to solve the BGP Egress Peer Engineering (BGP-EPE) requirement" and it doesn’t contain a list of protocol requirements nor it mandates how the new TLVs should be used. Note also that draft-ietf-spring-segment-routing-central-epe refers normatively to this document to explain the use case, so pointing Normatively back to it creates a loop.... Please treat draft-ietf-spring-segment-routing-central-epe as what is should be: a good Informative reference — I put specific comments in Sections 3 and 5 below. I will wait for at least the major items to be addressed before starting the IETF Last Call. Thanks! Alvaro. [The line numbers come from idnits.] ... 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in RFC 2119 [RFC2119]. [major] Please use the rfc8174 template. ... 103 1. Introduction ... 113 The SR architecture [RFC8402] defines three types of BGP Peering 114 Segments that may be instantiated at a BGP node: 116 o Peer Node Segment (Peer-Node-SID) : instruction to steer to a 117 specific peer node 119 o Peer Adjacency Segment (Peer-Adj-SID) : instruction to steer over 120 a specific local interface towards a specific peer node 122 o Peer Set Segment (Peer-Set-SID) : instruction to load-balance to a 123 set of specific peer nodes [major] rfc8402 doesn't use the same names as above. Please be consistent with the language already defined there. Here, and across the rest of the document. ... 138 One use-case for these BGP Peering Segments is to enable computation 139 of SR paths that enable Central BGP-EPE as described in 140 [I-D.ietf-spring-segment-routing-central-epe]. This use-case 141 comprises of a centralized controller that learns the BGP Peering 142 SIDs via BGP-LS and then uses this information to program a SR policy 143 [I-D.ietf-spring-segment-routing-policy] at any node in the domain to 144 perform traffic steering via a specific BGP egress node to a specific 145 EBGP peer(s) optionally also over a specific interface. [minor] I-D.ietf-spring-segment-routing-central-epe doesn't mention I-D.ietf-spring-segment-routing-policy anywhere. 147 This document introduces a new BGP protocol type for BGP-LS NLRI and 148 defines new BGP-LS Node and Link description TLVs to facilitate 149 advertising BGP-LS Link NLRI that represent the BGP peering topology. 150 Further, it specifies the BGP-LS Attribute TLVs for advertisement of 151 the BGP Peering Segments (i.e. Peer Node SID, Peer Adjacency SID, 152 and Peer Set SID) to be advertised in the same BGP-LS Link NLRI. [major] s/introduces a new BGP protocol type for BGP-LS NLRI/introduces a new BGP-LS Protocol-ID [minor] s/Node and Link description TLVs/Node and Link Descriptor TLVs [minor] s/Link NLRI/Link-State NLRI/g 154 2. Segment Routing Documents 156 The main reference is the SR architecture defined in [RFC8402]. 158 The SR BGP-EPE architecture and use-case is described in 159 [I-D.ietf-spring-segment-routing-central-epe]. [nit] This section doesn't add anything that hasn't been already mentioned. Please consider removing it. 161 3. BGP Peering Segments 163 As described in [I-D.ietf-spring-segment-routing-central-epe], a BGP- 164 EPE enabled Egress PE node MAY advertise SIDs corresponding to its 165 attached peers. These SIDs are called BGP peering segments or BGP 166 Peering SIDs. In case of EBGP, they enable the expression of source- 167 routed inter-domain paths. [major] "As described in [I-D.ietf-spring-segment-routing-central-epe], a BGP-EPE enabled Egress PE node MAY advertise SIDs..." I-D.ietf-spring-segment-routing-central-epe is just an illustrative document; it uses Normative language just to describe the requirements for the solution, and not to specify behavior (as suggested above). In this case the "MAY" seems to be used to describe the use case: s/MAY/may 169 An ingress border router of an AS may compose a list of SIDs to steer 170 a flow along a selected path within the AS, towards a selected egress 171 border router C of the AS, and to a specific EBGP peer. At minimum, 172 a BGP-EPE policy applied at an ingress PE involves two SIDs: the Node 173 SID of the chosen egress PE and then the BGP Peering SID for the 174 chosen egress PE peer or peering interface. 176 Each BGP session MUST be described by a Peer Node SID. The 177 description of the BGP session MAY be augmented by additional Peer 178 Adjacency SIDs. Finally, multiple Peer Node SIDs or Peer Adjacency 179 SIDs MAY be part of the same group/set in order to group EPE 180 resources under a common Peer-Set SID. [minor] Please add forward references to the sections where more details are provided. 182 When the extensions defined in this document are applied to the EPE 183 use-case defined in [I-D.ietf-spring-segment-routing-central-epe], 184 then the following BGP Peering SIDs need to be instantiated on a BGP 185 router for each of its BGP peer sessions that are enabled for EPE [major] I-D.ietf-spring-segment-routing-central-epe is being used as Normative (below) justification for the definition of peering segments. If possible, please describe the specification in general terms... The text above and in §5 (where it talks about different behaviors for "other use cases") raises the question of whether this document applies in general to any (known) use of the segments defined here, or only to BGP-EPE. IOW, what are those "other use cases"? Where are they described to guarantee that the specification applies to them? 187 o One Peer-Node-SID MUST be instantiated to describe the BGP peer 188 session. 190 o One or more Peer-Adj-SID MAY be instantiated corresponding to the 191 underlying link(s) to the directly connected BGP peer session. 193 o A Peer-Set-SID MAY be instantiated and additionally associated and 194 shared between one or more Peer-Node-SIDs or Peer-Adj-SIDs. 196 While an egress point in a topology usually refers to EBGP sessions 197 between external peers, there's nothing in the extensions defined in 198 this document that would prevent the use of these extensions in the 199 context of IBGP sessions. However, unlike EBGP sessions which are 200 generally between directly connected BGP routers which are also along 201 the traffic forwarding path, IBGP peer sessions may be setup to BGP 202 routers which are not in the forwarding path. As such, when the IBGP 203 design includes sessions with route-reflectors, a BGP router SHOULD 204 NOT instantiate a BGP Peering SID for those sessions to peer nodes 205 which are not in the forwarding path since the purpose of BGP Peering 206 SID is to steer traffic to that specific peers. Thus, the 207 applicability for IBGP peering may be limited to only those 208 deployments where the IBGP peer is also along with forwarding data 209 path. Further details and the use-cases of BGP Peering SIDs and 210 their BGP-LS extensions to IBGP deployments are beyond the scope of 211 this document. [nit] s/along with forwarding data path/along the forwarding data path [major] "...details...of BGP Peering SIDs and their BGP-LS extensions to IBGP deployments are beyond the scope of this document." The text in the same paragraph says: "nothing...would prevent the use of these extensions in the context of IBGP sessions". I think that is a contradiction because there are already descriptions in this document. Solution: take out the last sentence. 213 The BGP Peering SIDs instantiated as described above are then 214 advertised via BGP-LS Link NLRI as described in the sections below. [minor] I think that what you meant is something like this: "Any instantiated BGP Peering SIDs are then advertised using BGP-LS, as described in the following sections." 216 4. BGP-LS NLRI for BGP [minor] Perhaps "BGP Protocol-ID", there's no new NLRI for BGP [minor] s/BGP-LS NLRI/BGP-LS Link-State NLRI/g The NLRI is called "Link-State", not "BGP-LS". 218 This section describes the BGP-LS NLRI encodings that describe the 219 BGP peering and link connectivity between BGP routers. 221 This document specifies the advertisement of BGP peering topology 222 information via BGP-LS NLRI which requires use of a new BGP protocol 223 identifier. [minor] s/BGP protocol identifier/BGP-LS Protocol-ID The new definition is for BGP-LS, not BGP. 225 Protocol-ID : BGP (codepoint 7 Early Allocation by IANA Section 8 226 from the registry "BGP-LS Protocol-IDs") [nit] Consider using a table. ... 271 Value: 4 octet unsigned non-zero integer representing the BGP 272 Identifier as defined in [RFC4271] and [RFC6286]. [minor] rfc6286 Updated rfc4271, so there's no need to include both. s/BGP Identifier as defined in [RFC4271] and [RFC6286]./BGP Identifier [RFC6286]. ... 282 Value: 4 octet unsigned non-zero integer representing the 283 Member ASN inside the Confederation [RFC5065]. [major] rfc5065 uses "Member-AS Number", please be consistent: s/Member ASN inside the Confederation [RFC5065]./Member-AS Number [RFC5065]. 285 4.2. Mandatory BGP Node Descriptors ... 293 o Autonomous System Number, which contains the ASN or confederation 294 identifier (ASN), if confederations are used, of the local BGP 295 node. [minor] Is this TLV new, or are you referring to TLV 512 [rfc7752]? Please include the TLV number (and a reference, if appropriate) to avoid confusion
- [Idr] AD Review of draft-ietf-idr-bgpls-segment-r… Alvaro Retana
- Re: [Idr] AD Review of draft-ietf-idr-bgpls-segme… Ketan Talaulikar (ketant)
- Re: [Idr] AD Review of draft-ietf-idr-bgpls-segme… Ketan Talaulikar (ketant)
- Re: [Idr] AD Review of draft-ietf-idr-bgpls-segme… Alvaro Retana
- Re: [Idr] AD Review of draft-ietf-idr-bgpls-segme… Ketan Talaulikar (ketant)
- Re: [Idr] AD Review of draft-ietf-idr-bgpls-segme… Alvaro Retana
- Re: [Idr] AD Review of draft-ietf-idr-bgpls-segme… Ketan Talaulikar (ketant)