Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-segment-routing-ext-11
"Ketan Talaulikar (ketant)" <ketant@cisco.com> Sat, 09 March 2019 03:42 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 75C2C128B01; Fri, 8 Mar 2019 19:42:03 -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=khOF6d0R; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=a1UY2zYD
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 m_rFpVDnJBsD; Fri, 8 Mar 2019 19:41:58 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2959B124B0C; Fri, 8 Mar 2019 19:41:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=61986; q=dns/txt; s=iport; t=1552102918; x=1553312518; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Myjp7Fz81xvk4Ai5CTYtKLHTgQTv4qIohfNQAjuXM8A=; b=khOF6d0Rvhg0sI8+XIW1mVDsXddPoDG8lik+32nh3agVGkUe52AdDfBq Y/NV39ow/M1bmBQTCZDbODAbINocg8Sdr2isCV/vZTQu62hCQpEvkG3pG CMy41S3wGnbrbhHyywDtUwCgt3nMFiCdYwo6R5+kiB0zOJY61YD5zu0py k=;
IronPort-PHdr: 9a23:OtPuSBF+wu6eMMohwr272p1GYnJ96bzpIg4Y7IYmgLtSc6Oluo7vJ1Hb+e4w3Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNVcejNkO2QkpAcqLE0r+ef3ncyU8AOxJVURu+DewNk0GUMs=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AEAAC0NYNc/5NdJa1aChoBAQEBAQIBAQEBBwIBAQEBgVEFAQEBAQsBgTwkLANodAQLJ4QJg0cDhFCKZYJXfIg1jnUUgRADVAsBASUHhEACF4QeIjQJDQEBAwEBBwEDAm0cDIVKAQEBBBoBCAQNDAEBJQsCBQELBAIBCA4DBAEBAwIRFQICAh8RFQgIAgQOBQgTgwiBXQMVAQIMA6ImAooUcXwzgngBAQWBMAEDAg5Bgn4NC4ILAwWBCyQBiysXgUA/gRABRoFOSTWCV0cBAQIBAYEYAQwNBA8CGBUPBhOCSzGCJoocgi+EJocMi0YqMwkCh02De4QBg1eBeIVmih+BO4o5gVGEU4ExiAuDJAIEAgQFAg0BAQWBRziBVnAVGiGCbIIKDBeDS4UUhT9yAQEBgSWNEIJNAQE
X-IronPort-AV: E=Sophos;i="5.58,458,1544486400"; d="scan'208";a="532363962"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Mar 2019 03:41:27 +0000
Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x293fR9C017251 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 9 Mar 2019 03:41:27 GMT
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 8 Mar 2019 21:41:26 -0600
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 8 Mar 2019 21:41:25 -0600
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 8 Mar 2019 21:41:25 -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=Myjp7Fz81xvk4Ai5CTYtKLHTgQTv4qIohfNQAjuXM8A=; b=a1UY2zYDdg9E5K6m0jTcAo2HIKYeKYlncZekFQR3jqdbr3sxdGxyTeZGOTJ4EYB4LBlIue76iPN+HgfnJ2+6mi5510qLuh437WXi6PJAqWDXdJrk+UI6yt5GxbDcRGM+JoKnj2biCCxHTFmpPjmcuI9fsLqGqQIT5Yr/TTRVmgg=
Received: from SN6PR11MB2845.namprd11.prod.outlook.com (52.135.93.24) by SN6PR11MB3472.namprd11.prod.outlook.com (52.135.112.222) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.19; Sat, 9 Mar 2019 03:41:23 +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; Sat, 9 Mar 2019 03:41:23 +0000
From: "Ketan Talaulikar (ketant)" <ketant@cisco.com>
To: Alvaro Retana <aretana.ietf@gmail.com>
CC: "draft-ietf-idr-bgp-ls-segment-routing-ext@ietf.org" <draft-ietf-idr-bgp-ls-segment-routing-ext@ietf.org>, 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-bgp-ls-segment-routing-ext-11
Thread-Index: AQHUwxa4VuGTHvZuSEu7H9DbrilWbKX+lFOA
Date: Sat, 09 Mar 2019 03:41:23 +0000
Message-ID: <SN6PR11MB28457207A22678E2F5F35E9BC14E0@SN6PR11MB2845.namprd11.prod.outlook.com>
References: <CAMMESszrWsQZaki=aBQ_h-ZM72=qaKxFOkiw-Hj+m=giYgvyhQ@mail.gmail.com>
In-Reply-To: <CAMMESszrWsQZaki=aBQ_h-ZM72=qaKxFOkiw-Hj+m=giYgvyhQ@mail.gmail.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: 63272bad-c7b4-4ff1-3044-08d6a4411a06
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:SN6PR11MB3472;
x-ms-traffictypediagnostic: SN6PR11MB3472:
x-ms-exchange-purlcount: 9
x-microsoft-exchange-diagnostics: 1;SN6PR11MB3472;23:L9YKkqavYjULDEPb3mtMHLIywwOLgkLtkzCGHKUnuid0LJSvW/nyzGZKmBTRjFrwQ8aLi2aHk5XRb5i2LBIaYFAaIhSWTi4/5pWI9p3js7c59pvek7s2myMAz67d8EwJhjqGzvoeIKU4cj1RfGtZes0gFXyT6myqTKcrvz+nBid3vz7PR/V3/GdU5MKQqdTglNXvt1M2/y72MWLFVOLqAuB6DZvOpfThQ1Q7DEEwp2pIlnLP60KsJdqVVizv6skS80YCCe1+x5qi47GoF2z+c17j4vfetfcEeRXoqaAOxr5jkCVrT28hrZnZeibsbRZJIPbaczI4hbV3QLL81fjMIB+v3CqXfjF49b2IUEZ6+Bm9X9FRVGsxV+2XLBJs1VOYR3YhSFwDugeIQ9BuJona9v8GQHnFCluy9/kWfqxtou0FHWZgfHB7F2qaDF/wna3jTexnAJYoa4jOziTbYHmrBx+JKYO55ysk7UDXVR34D73USzdyq2tcSovCm6Yvxn5ELrcH6FtVO4n8eloqCL0i6Dd8uFQ8PvSp7M/vTnpnmFLqk+r+kQCh0j42K6hp26ugiM5Nv/aSXMcD/Su0WytUWsMblJ8G3K2vGOCTCJekNbPGcMWTzGo6gmD+4x7g3tzm14EcpA6IMtTxj6fFcnRksdLi1s8tCDWDtZXTQrbqVhMzo14chq2OylGzBeciFCMXRxi9LOZXCU+muGs+6+xHRq4dO8ii0J0CfwDpkuVlsiaE6QfNhmbSI2oPOsIKmq5oF3vSrXU0jncRsGnG2J4G8m3SOtyuwoEu234q17cnjHgTfsEoLCNBUqffURO/fgrxcokoM3waWFO2z6EZyvdndAYwSt2ch7vYwoDL11PH8n8WjQsXVzfee+GYgn4LiFtOXbaTTG/HCOppRBcvuuwoStHt+ok/dC6R/iMMztRB7hy3N7o6PxDqbxVEjJwhuDUM86u6w96mlgqO6mOJp8Q6eQaTljyohOVe2ymyDNgy/uodXOCPwKH1uSp+GPpWj6ROhrk2wXgwoaWuWZ/3KvTJLyXlLggLc8mBdFWmjZ66BMAecwBEK4iV906zhkAhcnH8Iyt3fnjScHztb9iSWZIa6BdFKhqn4jhH73e8pIjblp+6aFHmRfbVrvC7YUOVII14vYeYzZNonjYe0BXESN70WAO9YiH1DSh9yc6dbu9YhUCUNCqBo9rgXmTgsXk7upv/csGDJWdQs5CcihB+U00dgrfID8+U1lPeFjguZlhoKic3U4ONMizcm0lpUqgCo6yESenvKP2d6e+D32lCcVFZ1OHlTO3EUUB0ZUiSiTvyHqBgkNKDc21o9+p2uTlaQWsSmQl+Nv5pxF2eWfUk23TvuL0S7lX6TieZbmqe3e8e5XzTwJbs3+EDpVDC/knb89Sy
x-microsoft-antispam-prvs: <SN6PR11MB34724DC630602E8DAFAEC42EC14E0@SN6PR11MB3472.namprd11.prod.outlook.com>
x-forefront-prvs: 0971922F40
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(376002)(136003)(366004)(346002)(13464003)(51444003)(199004)(189003)(6246003)(53946003)(6306002)(966005)(9686003)(316002)(25786009)(105586002)(478600001)(229853002)(53936002)(68736007)(6116002)(305945005)(14454004)(7736002)(33656002)(6916009)(53546011)(52536013)(4326008)(74316002)(256004)(55016002)(81156014)(86362001)(102836004)(8676002)(81166006)(99286004)(76176011)(2906002)(46003)(6506007)(66574012)(97736004)(106356001)(71200400001)(446003)(54906003)(7696005)(30864003)(6436002)(186003)(476003)(8936002)(486006)(5660300002)(11346002)(14444005)(71190400001)(5024004)(579004)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR11MB3472; 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: wTYNdbtzT9vEWUpgXaDxh5pH4EMZYidqVOUFToRWNLApz4yaEgj527yLAiKUU64S5xZoBZ5prsoGz7BjLm0k+TBkOoAKSa+C5MMs7VJW2TFaJNx32Vfh5SxWx/PSc5OqWXzUHAaIClKYuhVi+X1HWlaaETWPL5wEwTipPtKlE5GsG09DRSzv1nux4nP+BAc/E+gY+74nPWecMmpag83n0wZeNgfGWv+KV55nfLNYeXRmD3fX53pECK1lE7C/QRMolcWYe9T17PHweGO7Vf/ozAqBNU4y7SMmarNZXpOQuDsUbgvpqMS71P8QRh7AgG18I/ozQ8xdO2YAtw7dM4FvfzxSMKMmCzndm5ExuDrJPpiBpnw8YtYBspTcRUTr0ndIrz24+AUf93jjtvfxqqhrsSJX3c1BUQ1kUNB1P8MlVX8=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 63272bad-c7b4-4ff1-3044-08d6a4411a06
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2019 03:41:23.3374 (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: SN6PR11MB3472
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/FeDoEuSVzvaocHvXTyo2ctH2XEE>
Subject: Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-segment-routing-ext-11
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: Sat, 09 Mar 2019 03:42:03 -0000
Hi Alvaro, Thanks for your detailed review and helping identify issues as well as improving the document. We've accepted and incorporated most of your feedback and addressed your comments. I've posted an updated version 12 of the document with these changes https://datatracker.ietf.org/doc/html/draft-ietf-idr-bgp-ls-segment-routing-ext-12 Please see inline below for more detailed responses. Thanks, Ketan -----Original Message----- From: Alvaro Retana <aretana.ietf@gmail.com> Sent: 13 February 2019 02:27 To: draft-ietf-idr-bgp-ls-segment-routing-ext@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-bgp-ls-segment-routing-ext-11 Dear authors: I just finished my review of this document -- please see inline comments/questions. In general, I think that there is more work needed in at least two fronts: (1) Consistency in the specification of the new TLVs. Most of the descriptions point at other documents, but they don't do so in a consistent manner: some at the start of the section, others when pointing at the values, etc. Please be consistent! Given that §2.4/2.5 already have a summary, I personally find the information in the individual sections redundant. Instead of a statement at the start of a section, I prefer you to be specific about the values -- see §2.1.2 for an example. [KT] I have made some changes to address this and will wait for some clarification from you on this point. Please check my responses on such points further below. Please note that most of my comments related to the specification of the TLVs apply to multiple sections, not just the one where I made them. I pointed this out in most cases, but may have missed some. (2) Error Handling. As has been discussed on the list (for example in [1], [2] and [3]), rfc7752 could use enhancements as it relates to considering error handling with applications such as SR, and in general. Those issues don't need to be fixed in this document, but I would like to see in this document some text about the potential effect: maybe in terms of the effect than an error might have from an operations or management point of view... See my comments below for specifics. Again, not looking for this document to "fix" BGP-LS, but to consider the effect on the expected function a controller might have, as described in the Introduction. [KT] Agree and I will add text which describes and acknowledges the effect of errors specific to the new SR information being introduced here and for SR based applications. [1] https://mailarchive.ietf.org/arch/msg/idr/Tm0vlu-ECSnIAyO1byj68AJm2XU [2] https://mailarchive.ietf.org/arch/msg/idr/0qsjuVaEhroKInHZMohP6HnsWd8 [3] https://mailarchive.ietf.org/arch/msg/idr/-CZGAiC8D3KogLnUs6ClW_KlU24 Thanks! Alvaro. [Line numbers come from idnits.] ... 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. [major] Please use the rfc8174 template. [KT] ack - fixed. ... 99 1. Introduction ... 110 Two types of IGP segments are defined, Prefix segments and Adjacency 111 segments. Prefix segments, by default, represent an ECMP-aware 112 shortest-path to a prefix, as per the state of the IGP topology. 113 Adjacency segments represent a hop over a specific adjacency between 114 two nodes in the IGP. A prefix segment is typically a multi-hop path 115 while an adjacency segment, in most of the cases, is a one-hop path. 116 [RFC8402]. [nit] rfc8402 defines more than 2 IGP segments. [KT] ack - fixed. [nit] s/one-hop path. [RFC8402]./one-hop path [RFC8402]. [KT] ack - fixed. 118 When Segment Routing is enabled in a IGP domain, segments are 119 advertised in the form of Segment Identifiers (SIDs). The IGP link- 120 state routing protocols have been extended to advertise SIDs and 121 other SR-related information. IGP extensions are described in: IS-IS 122 [I-D.ietf-isis-segment-routing-extensions], OSPFv2 123 [I-D.ietf-ospf-segment-routing-extensions] and OSPFv3 124 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. Using these 125 extensions, Segment Routing can be enabled within an IGP domain. [nit] s/a IGP domain/an IGP domain [KT] Ack - fixed. 127 +------------+ 128 | Consumer | 129 +------------+ 130 ^ 131 | 132 v 133 +-------------------+ 134 | BGP Speaker | +-----------+ 135 | (Route-Reflector) | | Consumer | 136 +-------------------+ +-----------+ 137 ^ ^ ^ ^ 138 | | | | 139 +---------------+ | +-------------------+ | 140 | | | | 141 v v v v 142 +-----------+ +-----------+ +-----------+ 143 | BGP | | BGP | | BGP | 144 | Speaker | | Speaker | . . . | Speaker | 145 +-----------+ +-----------+ +-----------+ 146 ^ ^ ^ 147 | | | 148 IGP IGP IGP 150 Figure 1: Link State info collection [nit] Maybe move this Figure so it is closer to where it is referenced. [KT] Ack - moved. ... 159 In order to address the need for applications that require 160 topological visibility across IGP areas, or even across Autonomous 161 Systems (AS), the BGP-LS address-family/sub-address-family have been 162 defined to allow BGP to carry Link-State information. The BGP 163 Network Layer Reachability Information (NLRI) encoding format for 164 BGP-LS and a new BGP Path Attribute called the BGP-LS attribute are 165 defined in [RFC7752]. The identifying key of each Link-State object, 166 namely a node, link, or prefix, is encoded in the NLRI and the 167 properties of the object are encoded in the BGP-LS attribute. 168 Figure 1 describes a typical deployment scenario. In each IGP area, 169 one or more nodes are configured with BGP-LS. These BGP speakers 170 form an IBGP mesh by connecting to one or more route-reflectors. 171 This way, all BGP speakers (specifically the route-reflectors) obtain 172 Link-State information from all IGP areas (and from other ASes from 173 EBGP peers). An external component connects to the route-reflector 174 to obtain this information (perhaps moderated by a policy regarding 175 what information is or isn't advertised to the external component). [minor] The way that the propagation of information can be controlled by policy is important. Please make sure that the text is clear in the fact that the discussion above is referencing rfc7752 (and that the reference to it is not just about the encodings). [KT] Ack - updated the text clearer with the reference. 177 This document describes extensions to BGP-LS to advertise the SR 178 information. An external component (e.g., a controller) then can 179 collect SR information from across an SR domain and construct the 180 end-to-end path (with its associated SIDs) that need to be applied to 181 an incoming packet to achieve the desired end-to-end forwarding. 182 Here the SR domain is defined as a single administrative domain that 183 may be comprised of a single AS or multiple ASes under consolidated 184 global SID administration. [nit] s/under consolidated/under a consolidated [KT] Ack - fixed. [major] Please don't redefine "SR domain". The definition above is not the same as what rfc8402 says (in §2). Easy fix: simply put a reference to rfc8402 next to the first mention of "SR domain", and delete that last sentence. [KT] Have put reference to RFC8402 for the SR domain definition. However, I would suggest to retain the sentence "The SR domain may be comprised of a single AS or multiple ASes." in there since RFC8402 does not talk in terms of AS and IMHO it would be helpful to clarify that aspect in this BGP document. 186 2. BGP-LS Extensions for Segment Routing 188 This document defines SR extensions to BGP-LS and specifies the TLVs 189 and sub-TLVs for advertising SR information within the BGP-LS 190 Attribute. Section 2.4 and Section 2.5 illustrates the equivalent 191 TLVs and sub-TLVs in IS-IS, OSPFv2 and OSPFv3 protocols. [nit] "illustrates" sounds like giving examples of equivalent TLVs. But I think that the tables don't show examples, they show/point to the corresponding TLVs. Perhaps use a different word... [KT] ack - changed to "lists". ... 200 Some of the TLVs defined in this document contain fields (e.g. flags) 201 whose semantics need to be interpreted accordingly to the respective 202 underlying IS-IS, OSPFv2 or OSPFv3 protocol. The receiver of the 203 BGP-LS update for any of the NLRIs MUST check the Protocol-ID of the 204 NLRI and refer to the underlying protocol specification in order to 205 parse such fields. The individual field descriptions in the sub- 206 sections below point to the relevant underlying protocol 207 specifications for such fields. [major] "The receiver of the BGP-LS update for any of the NLRIs MUST check the Protocol-ID of the NLRI and refer to the underlying protocol specification in order to parse such fields." This text is a general statement ("for any of the NLRIs") that seems to want to Update rfc7752, where Protocol-ID is defined...but I don't think that is the intent, right? Note that rfc7752 doesn't explicitly mandate that the "receiver...refer to the underlying protocol specification" -- it just implies it when talking about the Opaque TLVs. [KT] Actually in this case, the protocol needs to be used by the consumer of the information to interpret certain fields in the BGP-LS TLVs. E.g. Adjacency SID in sec 2.2.1, the flags field is different in OSPF and ISIS and based on the flags the SID/index/label field needs to be decoded. IOW, this seems like a significant change as related to other BGP-LS specs. [KT] I will agree that it is a deviation from other BGP-LS specs including the base where we have tried to define IGP agnostic flags. I think the placement of this sentence gives the wrong impression that it wants to update rfc7752. It may be better placed if this was move (and may be repeated) for only those TLV fields where this kind of protocol specific decoding is necessary. I have updated the draft for this. e.g. for sec 2.2.1, I would propose to add the following text at the end of the TLV fields description: "The Flags and, as an extension, the SID/Index/Label fields of this TLV need to be interpreted accordingly to the respective underlying IS-IS, OSPFv2 or OSPFv3 protocol. The consumer of the BGP-LS interested in this TLV information MUST check the Protocol-ID of the BGP-LS Link NLRI and refer to the underlying protocol specification in order to parse these fields." Note also that §5 (Manageability Considerations) has the following text, which I think is in contradiction of the one above: [KT] I think this section should be using the term "consumer of the BGP-LS information" and not "receiver". Fixed this. ... ... The semantic or content checking for the TLVs specified in this document and their association with the BGP-LS NLRI types or their BGP-LS Attribute is left to the consumer of the BGP-LS information (e.g. an application or a controller) and not the BGP protocol. ... The handling of semantic or content errors by the consumer would be dictated by the nature of its application usage and hence is beyond the scope of this document. 209 2.1. Node Attributes TLVs 211 The following Node Attribute TLVs are defined: 213 +-----------------+----------+---------------+ 214 | Description | Length | Section | 215 +-----------------+----------+---------------+ 216 | SID/Label | variable | Section 2.1.1 | 217 | SR Capabilities | variable | Section 2.1.2 | 218 | SR Algorithm | variable | Section 2.1.3 | 219 | SR Local Block | variable | Section 2.1.4 | 220 | SRMS Preference | variable | Section 2.1.5 | 221 +-----------------+----------+---------------+ 223 Table 1: Node Attribute TLVs [minor] It would be nice if the table also contained the TLV Type. This comment applies to other similar tables. [KT] Ack - fixed. [minor] §2.1.2/2.1.3 use a "-" in the name of the TLV. Please be consistent as both versions are used throughout the document. [KT] Ack - fixed. [nit] Yes, the length is variable, but in some cases the possible values are known. For example, the length of the SID/Label sub-TLV can only be 3 or 4. Consider indicating that. OTOH, I don't see why indicating the Length is significant at this point -- IOW, I would even suggest removing that column. [KT] Ack - removed this column. 225 These TLVs can ONLY be added to the BGP-LS Attribute associated with 226 the Node NLRI that originates the corresponding underlying IGP TLV/ 227 sub-TLV described below. [minor] "the Node NLRI that originates the corresponding underlying IGP..." The Node NLRI doesn't originate anything...it describes the IGP node that originates something... Please be specific. [KT] Ack - changed to " These TLVs should only be added to the BGP-LS Attribute associated with the Node NLRI describing the IGP node that is originating the corresponding IGP TLV/sub-TLV described below." [major] The text above sounds as if you want to mandate something... Writing "ONLY" in caps doesn't have a Normative effect. Should there be a "MUST" somewhere? Or perhaps soften a little: s/can ONLY/should only [KT] ack - changed to "should only" The next question is: what if they are added somewhere else? There doesn't seem to be a way for the receiver to know if the TLVs are associated with the correct Node NLRI... I'm guessing that all the receiver can do is assume that the TLV is referring to the right node... >From the text, I'm assuming that the use is intended to be limited to >the Node NLRI. Unfortunately, rfc7752 doesn't specify actions to be taken if that is not the case. This comment applies to other places where the "ONLY be added" phrase exists. [KT] Agree. IMHO this is applicable to base RFC7752. I will respond on this on the other thread about BGP-LS TLVs that you had started since this topic is not specific to this draft. 229 2.1.1. SID/Label Sub-TLV 231 The SID/Label TLV is used as sub-TLV by the SR-Capabilities 232 (Section 2.1.2) and SRLB (Section 2.1.4) TLVs and has the following 233 format: [nit] s/used as sub-TLV/used as a sub-TLV [KT] ack - fixed [minor] This is the first time that SRLB is used in this document, please use the extended version here: s/SRLB/SR Local Block (SRLB) [KT] ack - fixed ... 245 Type: TBD, see Section 4. [minor] The code points have already been assigned (early allocation). Please change "TBD" for the actual values. [KT] ack - updated. 247 Length: Variable, 3 or 4. [nit] The Length is really not variable...it's 3 or 4. [KT] Ack - updated. ... 254 The receiving router MUST ignore the SID/Label sub-TLV if the 255 length is other then 3 or 4. [major] If the sub-TLV is ignored, the information in the SR-Capabilities or SR Local Block TLVs will be incomplete (at best). What is the potential impact of that? Is the received information still useful? Should other actions be taken? [KT] I have removed this statement. Practically, without SRGB the node is almost unusable for almost all SR use-cases. 257 2.1.2. SR-Capabilities TLV 259 The SR-Capabilities TLV is used in order to advertise the node's SR 260 Capabilities including its Segment Routing Global Base (SRGB) 261 range(s). In the case of IS-IS, the capabilities also include the 262 IPv4 and IPv6 support for SR-MPLS forwarding plane. This information 263 is derived from the protocol specific advertisements. [nit] s/support for SR-MPLS forwarding plane/support for the SR-MPLS forwarding plane [KT] ack - updated. 265 o IS-IS, as defined by the SR-Capabilities sub-TLV in 266 [I-D.ietf-isis-segment-routing-extensions]. 268 o OSPFv2/OSPFv3, as defined by the SID/Label Range TLV in 269 [I-D.ietf-ospf-segment-routing-extensions] and 270 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [minor] The text above, pointing at the individual IGP specs is present in many of the descriptions for the TLVs, but not all. Sections 2.4/2.5 have tables that also point at the equivalent TLVs. I'm looking for consistency: either indicate in each section where the information is derived from, or not. Given that §2.4/2.5 already have a summary, I personally find the information (like the one above) in the individual sections redundant. [KT] I am open to suggestion here on how to improve the document readability. The thought process for the way it's been currently laid out is something as follows. For each TLV in that section we give the corresponding IGP TLV name. The summary table in sec 2.4 & 2.5 were meant to give the codepoint values (no names here) and the URL pointer to the respective IGP specification. Please also see my next response. Instead of the statement above, I prefer you to be specific about the values described below -- for example, when describing the Range Size field below, you could say something like this: OLD> Range Size: 3 octet value indicating the number of labels in the range. NEW> Range Size: 3 octet value indicating the number of labels in the range. The value and characteristics of this field are derived from the Range field in the SR-Capabilities sub-TLV in [I-D.ietf-isis-segment-routing-extensions], or from the Range Size field in the SID/Label Range TLV in [I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [KT] In most of the cases, the mapping of the fields from the IGP TLV to the BGP-LS TLV is fairly intuitive since we have the same name in most cases. In a few cases, where things are a bit different e.g. Range TLV in sec 2.3.4 we have tried to explain the mapping in more detail and specifics. My concern is that the readability of the document will be affected if we start putting text as you suggest for each TLV field. Note that doing it this way saves you the need to define the characteristics of each field (because even if the values are derived, the TLVs here are new). This comment obviously applies to all similar instances in the document. 272 The SR Capabilities TLV has following format: [nit] s/has following format/has the following format [KT] ack - fixed. ... 290 Length: Variable. [major] Yes, it's variable, but it has to be at least 12. What should a router do if the length is < 12? After that, there are only specific valid [KT] I have updated for the minimum length for the TLVs. However, it is not very helpful to try and list all other valid values (in some cases, cannot even say "in multiple of X"). lengths: 12, 13, 19, 21, etc. What if the length is not one of those values? I couldn't find guidance in rfc7752. The closest statement is from §6.2.2 (Fault Management), where one of the "checks for determining if a message is malformed...Does any fixed-length TLV correspond to the TLV Length field in this document?" This TLV is not fixed-length, but the possibilities are finite. Note that rfc7752 says that if the length is not the expected one, then the whole BGP-LS attribute is discarded. For this specific case, it means that the controller wouldn't have complete knowledge of the network, even if the information derived from the IGP is correct... [KT] I would take this in the generic RFC7752 context and not specific for this draft. This comment applies to other similar instances. 292 Flags: 1 octet of flags as defined in 293 [I-D.ietf-isis-segment-routing-extensions]. [major] When the BGP-LS information comes from OSPF, how should the flags be interpreted? There is no indication in the corresponding OSPF drafts of "IPv4 and IPv6 support for SR-MPLS" -- should the bits always be unset? [KT] I have updated that the flag are not defined for OSPF and are not to be set and ignored. ... 300 Range Size: 3 octet value indicating the number of labels in 301 the range. [nit] s/labels/labels or SIDs [KT] In this case, we are only talking about only labels since this is providing the first label of the SRGB block. Even though SID/Label TLV is used, the SID encoding is not valid for this TLV. I will clarify this in the text. [major] What numbers are valid in the Range Size field? Can it be 0? Take a look above at my comments about derived values. [KT] Ack - fixed to indicate that it should be a non-zero value. 303 SID/Label sub-TLV (as defined in Section 2.1.1) which encodes 304 the first label in the range. [nit] s/first label/first label or SID [KT] Please see previous response - only label is valid. ... 339 2.1.4. SR Local Block TLV ... 380 Flags: 1 octet of flags. None are defined at this stage. [major] Only the corresponding ISIS sub-TLV has Flags defined -- and I realize that the text above is the same as in draft-ietf-isis-segment-routing-extensions. I think you really don't want this field to evolve independently. IOW, please use a description like the you used for the Flags in the SR-Capabilities TLV. [KT] Actually, I would prefer the BGP-LS flags and encodings to evolve independent of the IGPs (but mapping and encompassing their encodings) so that consumers don't need to be exposed to IGP specifics (where possible) for decoding/interpretation of values that can be modelled in an IGP independent manner. We could not do this for some of the initial TLVs/fields since there wasn't a consensus on this within authors/contributors. I hope we can going forward unless the WG feels differently. ... 393 2.1.5. SRMS Preference TLV ... 427 The use of the SRMS Preference TLV is defined in 428 [I-D.ietf-isis-segment-routing-extensions], 429 [I-D.ietf-ospf-segment-routing-extensions] and 430 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [major] This document only defines how to carry information in BGP-LS, not what to do with it. IOW, I think that the last paragraph is not needed, it is out of scope of this document... [KT] This is true for almost everything in BGP-LS since it is only a carrier of information. This info is meant for the consumer of the BGP-LS info on how this is used. E.g. it helps pick mapping of one SRMS server over the other - this way the consumer application would be able to get the right label to prefix mapping as advertised by that server. 432 2.2. Link Attribute TLVs 434 The following Link Attribute TLVs are are defined: 436 +----------------------------------------+----------+---------------+ 437 | Description | Length | Section | 438 +----------------------------------------+----------+---------------+ 439 | Adjacency Segment Identifier (Adj-SID) | variable | Section 2.2.1 | 440 | TLV | | | 441 | LAN Adjacency Segment Identifier (Adj- | variable | Section 2.2.2 | 442 | SID) TLV | | | 443 | L2 Bundle Member TLV | variable | Section 2.2.3 | 444 +----------------------------------------+----------+---------------+ 446 Table 2: Link Attribute TLVs [minor] The names used above don't match the names used in the sections below. [KT] ack - fixed. ... 452 For a LAN, normally a node only announces its adjacency to the IS-IS 453 pseudo-node (or the equivalent OSPF Designated and Backup Designated 454 Routers)[I-D.ietf-isis-segment-routing-extensions]. The LAN 455 Adjacency Segment TLV allows a node to announce adjacencies to all 456 other nodes attached to the LAN in a single instance of the BGP-LS 457 Link NLRI. Without this TLV, the corresponding BGP-LS link NLRI 458 would need to be originated for each additional adjacency in order to 459 advertise the SR TLVs for these neighbor adjacencies. [minor] This paragraph maybe fits better in §2.2.2. [KT] ack - moved it there. 461 2.2.1. Adjacency SID TLV ... 482 Flags. 1 octet field of following flags as defined in 483 [I-D.ietf-isis-segment-routing-extensions], 484 [I-D.ietf-ospf-segment-routing-extensions] and 485 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. NEW> Flags: 1 octet field. The value corresponds to the Flags specified for the Adj-SID Sub-TLV in [I-D.ietf-isis-segment-routing-extensions], [I-D.ietf-ospf-segment-routing-extensions] or [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [KT] Ack - updated as done for Prefix SID 487 Weight: Weight used for load-balancing purposes. [minor] Similar to the above text... [KT] I would prefer to not do this for every field since there is direct mapping for field names in most cases. Need some generic guidance here on best way to describe these mappings between the IGP and BGP-LS TLVs and their fields. 489 Reserved: 2 octets that SHOULD be set to 0 and MUST be ignored on 490 receipt. 492 SID/Index/Label: Label or index value depending on the flags 493 setting as defined in [I-D.ietf-isis-segment-routing-extensions], 494 [I-D.ietf-ospf-segment-routing-extensions] and 495 [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. [minor] Similar text here too... [KT] Ack 497 2.2.2. LAN Adjacency SID TLV ... [major] The OSPF Neighbor ID / IS-IS System-ID field is not defined. [KT] Ack - fixed. 542 2.2.3. L2 Bundle Member [nit] s/L2 Bundle Member/L2 Bundle Member Attribute TLV [KT] Ack - fixed. 544 The L2 Bundle Member Attribute TLV identifies an L2 Bundle Member 545 link which in turn is associated with a parent L3 link. The L3 link 546 is described by the Link NLRI defined in [RFC7752] and the L2 Bundle 547 Member Attribute TLV is associated with the Link NLRI. The TLV MAY 548 include sub-TLVs which describe attributes associated with the bundle 549 member. The identified bundle member represents a unidirectional 550 path from the originating router to the neighbor specified in the 551 parent L3 Link. Multiple L2 Bundle Member Attribute TLVs MAY be 552 associated with a Link NLRI. [minor] "identifies an L2 Bundle Member link...The identified bundle member". Are we talking about a link or just the members? [KT] The link is described by the Link NLRI. This TLV describes the members. ... 574 L2 Bundle Member Descriptor: A Link Local Identifier as defined in 575 [RFC4202]. [major] From the text, it looks like this information is not something that is learned from the IGP, which is then just transported by BGP-LS (just like the rest of the TLVs in this document), but table 5 points at draft-ietf-isis-l2bundles. Why is draft-ietf-isis-l2bundles not used to describe this TLV? [KT] Ack - I have put the text and reference to ietf-isis-l2bundles. [major] rfc4202 is not IS-IS-specific. What about OSPF? I note that rfc4203 defines OSPF extensions that include the Link Local Identifier, so this concept is not foreign to it. [KT] Yes, the same concept also applies for OSPF but we have not yet defined the equivalent specification for it. I would assume that we would do that in LSR at some point down the line and then the same may be advertised using the same TLV in BGP-LS. 577 Link attributes for L2 Bundle Member Links are advertised as sub-TLVs 578 of the L2Bundle Member Attribute TLV. The sub-TLVs are identical to 579 existing BGP-LS TLVs as identified in the table below. [nit] s/L2Bundle/L2 Bundle [KT] Ack - fixed. ... 633 2.3.1. Prefix-SID TLV ... [major] draft-ietf-ospf-segment-routing-extensions also includes the MT-ID in the Prefix SID Sub-TLV. Is that not needed by a controller? [KT] The MT-ID TLV (263) is present in the Prefix Descriptor in the NLRI portion as per https://tools.ietf.org/html/rfc7752#section-3.2.3 and hence not required to be repeated in the TLVs within the BGP-LS Attribute. 691 2.3.2. Prefix Attribute Flags TLV ... 711 Length: variable. [minor] The length of the flags fields in rfc7794/rfc7684 are both one octet long. Can this length be made fixed? [KT] Flags are one octet for OSPF in RFC7684 but variable for ISIS in rfc7794. Please look at the "..." [major] I could not find a Flags field for OSPFv3 in rfc5340. [KT] It's in https://tools.ietf.org/html/rfc5340#appendix-A.4.1.1 [minor] From Table 7, it seems that the reference to rfc8362 points to the "Prefix Options Field", is that correct? [KT] Yes - rfc8362 introduces the N flag - https://tools.ietf.org/html/rfc8362#section-3.1 713 Flags: a variable length flag field (according to the length 714 field). Flags are routing protocol specific and are to be parsed 715 as below: 717 * IS-IS flags are defined in [RFC7794] 719 * OSPFv2 flags are defined in [RFC7684] 721 * OSPFv3 flags map to the Prefix Options field defined in 722 [RFC7794] and extended via [RFC8362] [nit] The text at the top of this section refers to rfc5340... [major] rfc7794 only talks about IS-IS, not OSPFv3. [KT] Fixed it - should be RFC5340 and RFC8362 for OSPFv3. 724 2.3.3. Source Router Identifier (Source Router-ID) TLV 726 The Source Router-ID TLV contains the IPv4 or IPv6 Router-ID of the 727 originator of the Prefix. For IS-IS protocol this is as defined in 728 [RFC7794]. The Source Router-ID TLV may be used to carry the OSPF 729 Router-ID of the prefix originator. [major] Reference for OSPF? Only "may"?? [KT] The equivalent OSPF extension was only recently adopted by the LSR WG. I have updated the reference to it. [major] rfc7752 defines the IGP Router-ID TLV to carry the same information. What is the relationship between these two TLVs? Since the IGP Router-ID TLV is mandatory, are there cases where this one may not be needed? [KT] The IGP Router-ID TLV is used as a Node Descriptor TLV for one. It contains either ISIS system-id 6 octets or OSPF router-id 4 octets. Its purpose is different. The Source Router-ID TLV goes into BGP-LS attribute for a Prefix NLRI and may be either an IPv4 or IPv6 Router ID for ISIS or OSPF Router-ID (32 bit). Consider an OSPF inter-area prefix which is advertised by the ABR node from area 1 into area 0 - for this prefix, the IGP Router-ID would be that of the ABR, while the Source Router-ID TLV would be the OSPF Router-ID of the router in area 1 which owns this prefix. ... 745 Length: 4 or 16. [major] OSPF always uses a 32-bit number. IOW, the length is fixed for OSPF. [KT] Yes. Clarified this. ... 749 2.3.4. Range TLV 751 The range TLV is used in order to advertise a range of prefix-to-SID 752 mappings as part of the Segment Routing Mapping Server functionality 753 [I-D.ietf-spring-segment-routing-ldp-interop], as defined in the 754 respective underlying IGP SR extensions 755 [I-D.ietf-ospf-segment-routing-extensions], 756 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] and 757 [I-D.ietf-isis-segment-routing-extensions]. The Prefix-NLRI to which 758 the Range TLV is attached MUST be advertised as a non-routing prefix 759 where no IGP metric TLV (TLV 1095) is attached. [major] What do you mean in the final sentence? It sounds as if the IGP metric TLV and the Range TLV are mutually exclusive and should never be advertised together. Is that it? If so, what should the receiver do if they are? [KT] I have rephrased this since they are not mutually exclusive. The point about the IGP Metric TLV was that a consumer of a Prefix NLRI originated on account of a SRMS mapping should not mistake this prefix to be like a normal prefix reachability - it can detect this by the absence of the IGP Metric TLV which is included for all "real" prefix reachability advertisements. 761 The format of the Range TLV is as follows: 763 0 1 2 3 764 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | Type | Length | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | Flags | Reserved | Range Size | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 // sub-TLVs // 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 where: [nit] That "where" should be after the Figure title. [KT] ack - fixed 775 Figure 2: Range TLV format ... [minor] As will all the other sections, please be consistent and fold the sub-sections below into the description above. [KT] Ack - updated. 804 2.3.4.1. Advertisement Procedure for OSPF 806 The OSPFv2/OSPFv3 Extended Prefix Range TLV is encoded in the Range 807 TLV. The flags of the Range TLV have the semantic mapped to the 808 definition in [I-D.ietf-ospf-segment-routing-extensions] section 4 or 809 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] section 4. 811 Then the prefix-to-SID mapping from the OSPF Prefix SID sub-TLV is 812 encoded using the BGP-LS Prefix-SID TLV as defined in Section 2.3.1 813 with the flags set according to the definition in 814 [I-D.ietf-ospf-segment-routing-extensions] section 5 or 815 [I-D.ietf-ospf-ospfv3-segment-routing-extensions] section 5. [major] The Extended Prefix Range TLV contains other fields not present here: AF, for instance. [KT] AF for OSPFv2 would be always 0 for IPv4 and it is actually conveyed by the Prefix NLRI type in BGP-LS and hence not necessary to include in this TLV. The last paragraph seems to indicate that the prefix information will be in the BGP-LS Prefix-SID TLV, but that information doesn't come from the Extended Prefix Range TLV (and it doesn't include the AF). What am I missing? [KT] In OSPF, the way this is advertised is Extend Prefix Range TLV -> Prefix-SID sub-TLV. This maps in BGP-LS to Range TLV -> Prefix SID TLV as its sub-TLV. AF is really not required here and IMHO was not required even in OSPF encoding. [major] The text above seems to imply that the Range TLV and the Prefix-SID TLV should always be included together. Is that true? If so, please make it more explicit. [KT] That is what the document says "Within the Range TLV, the prefix-to-SID mappings are advertised using sub-TLVs as below". 817 2.3.4.2. Advertisement Procedure for IS-IS 819 The IS-IS SID/Label Binding TLV, when used to signal mapping server 820 label bindings, is encoded in the Range TLV. The flags of the Range 821 TLV have the sematic mapped to the definition in 822 [I-D.ietf-isis-segment-routing-extensions] section 2.4.1. 824 Then the prefix-to-SID mappings from the IS-IS Prefix SID sub-TLV is 825 encoded using the BGP-LS Prefix-SID TLV as defined in Section 2.3.1 826 with the flags set according to the definition in 827 [I-D.ietf-isis-segment-routing-extensions] section 2.4.4.1. [major] Same questions (as above) related to the other fields in the SID/Label Binding TLV, and the relationship between the Range TLV and the Prefix-SID TLV. [KT] For ISIS, the SRMS ranges are advertised as SID/Label Binding TLV -> Prefix-SID sub-TLV. There is nothing like "AF" here which is missing and all fields map from ISIS to BGP-LS TLVs except that the TLV names are different. 829 2.4. Equivalent IS-IS Segment Routing TLVs/Sub-TLVs ... 837 +---------------------------------------+----------+----------------+ 838 | Description | Length | IS-IS TLV/sub- | 839 | | | TLV | 840 +---------------------------------------+----------+----------------+ 841 | SR Capabilities | variable | 2 [1] | 842 | SR Algorithm | variable | 19 [2] | 843 | SR Local Block | variable | 22 [3] | 844 | SRMS Preference | 1 | 19 [4] | 845 | Adjacency Segment Identifier (Adj- | variable | 31 [5] | 846 | SID) | | | 847 | LAN Adjacency Segment Identifier | variable | 32 [6] | 848 | (LAN-Adj-SID) | | | 849 | Prefix SID | variable | 3 [7] | 850 | Range | variable | 149 [8] | 851 | SID/Label TLV | variable | 1 [9] | 852 | Prefix Attribute Flags | variable | 4 [10] | 853 | Source Router ID | variable | 11/12 [11] | 854 | L2 Bundle Member TLV | variable | 25 [12] | 855 +---------------------------------------+----------+----------------+ [major] Instead of using URIs, please put an explicit pointer to the RFC/ID (and if desired, the section)...and make sure that there are corresponding References. If a document is referenced only in this table, then the Reference can be Informative. [KT] All references are covered and mostly are normative. I have updated the table to remove the "Length" column and instead add the IGP draft and section numbers. [nit] For Tables 5-7: No need to use "TLV" in the description. [KT] Ack - fixed. 857 Table 5: IS-IS Segment Routing Extensions TLVs/Sub-TLVs 859 2.5. Equivalent OSPFv2/OSPFv3 Segment Routing TLVs/Sub-TLVs ... 886 Table 6: OSPF Segment Routing Extensions TLVs/Sub-TLVs [nit] s/OSPF/OSPFv2 [KT] ack - fixed. [minor] The OSPF tables don't include the Source Router ID or the L2 Bundle Member TLVs. Is there a reason for that, or just an oversight? [KT] I've added Source Router ID since we have that draft now in the WG while same is not the case for L2 Bundle Member as yet. ... 908 3. Implementation Status [nit] This section says nothing. :-( At least a pointer to https://trac.ietf.org/trac/idr/wiki/draft-ietf-idr-bgp-ls-segment-routing-ext-implementations might be nice. OR, you can just remove it. [KT] I have removed this. ... 943 4. IANA Considerations 945 This document requests assigning code-points from the registry "BGP- 946 LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute 947 TLVs" based on table Table 8. The column "IS-IS TLV/Sub-TLV" defined 948 in the registry does not require any value and should be left empty. [major] The early allocation has already been done...so this document doesn't request assignment from IANA. Please update. [KT] Ack - updated ... 977 5. Manageability Considerations 979 This section is structured as recommended in [RFC5706]. 981 The new protocol extensions introduced in this document augment the 982 existing IGP topology information that was distributed via [RFC7752]. 983 Procedures and protocol extensions defined in this document do not 984 affect the BGP protocol operations and management other than as 985 discussed in the Manageability Considerations section of [RFC7752]. 986 Specifically, the malformed attribute tests for syntactic checks in 987 the Fault Management section of [RFC7752] now encompass the new BGP- 988 LS Attribute TLVs defined in this document. The semantic or content 989 checking for the TLVs specified in this document and their 990 association with the BGP-LS NLRI types or their BGP-LS Attribute is 991 left to the consumer of the BGP-LS information (e.g. an application 992 or a controller) and not the BGP protocol. [nit] s/that was distributed/that is distributed [KT] Ack - fixed 994 A consumer of the BGP-LS information is retrieving this information 995 from a BGP protocol component that is doing the signaling over a BGP- 996 LS session, via some APIs or a data model (refer Section 1 and 2 of 997 [RFC7752]). The handling of semantic or content errors by the 998 consumer would be dictated by the nature of its application usage and 999 hence is beyond the scope of this document. This document only 1000 introduces new Attribute TLVs and an error in them would result in 1001 only that specific attribute being discarded with an error log. [nit] s/is retrieving this/retrieves this [KT] ack - fixed [minor] "...retrieving this information...over a BGP-LS session, via some APIs or a data model (refer Section 1 and 2 of [RFC7752])." I think that even mentioning that an API or data model can be used instead of BGP-LS is a stretch -- that is not how I interpret the initial sections in rfc7752 (which are just background sections), and there are no formal API/data model definition. [KT] How else would Alto Server or a PCE component get access to the BGP-LS information? There would be some APIs or a model. It may not be formal but there needs to be one? [major] "...new Attribute TLVs and an error in them would result in only that specific attribute being discarded with an error log." According to rfc7752, this statement is true only for syntactic errors, not semantic ones. [KT] Ack - I will change "an error" to "any syntactic error" Semantic errors ("left to the consumer", as mentioned above) means that the BGP-LS session can be used to transport trash (trash-in-trash-out). Jeff Haas brought this up during the WGLC [4]. I agree (with the Chairs' conclusion) that this issue is bigger than this document -- but (because we don't have a current solution) I would like to see it mentioned somewhere as a potential issue (maybe in the Management or Security Considerations sections, your choice). [4] https://mailarchive.ietf.org/arch/msg/idr/Yfp6WyqnRtMAOeZvSvK7rYCUkHg [major] rfc7752 does mandate the use of "attribute discard" (rfc7606). I would really like to see a discussion (or at least a mention) around the fact that discarding an attribute may result in the receiver not having complete information. In the case of SR, this implies that the controller may not have complete information to calculate the paths. I think this is an issue bigger than this document, so I am not asking you to solve it...I'm just asking for the document to acknowledge that it exists and to mention what the potential impact may be. [KT] Ack - I agree and have updated the text in this document to acknowledge that. 1003 The extensions, specified in this document, do not introduce any new 1004 configuration or monitoring aspects in BGP or BGP-LS other than as 1005 discussed in [RFC7752]. The manageability aspects of the underlying 1006 SR features are covered by [I-D.ietf-spring-sr-yang], 1007 [I-D.ietf-isis-sr-yang] and [I-D.ietf-ospf-sr-yang]. [minor] While the Yang models have to do with management, there are no "manageability aspects of the underlying SR features" included there. [KT] This is about the management of the SR features in IGP which result in their advertisement via BGP-LS. [major] Following the recommendations from rfc5706, a Fault Management section would be appropriate to include considerations related to the use of BGP-LS as a transport for SR information (given this is the first draft to propose it), and the possible errors mentioned here... Again, not looking for solutions, just acknowledgement. [KT] Ack - have updated the text for the same. 1009 6. Security Considerations 1011 The new protocol extensions introduced in this document augment the 1012 existing IGP topology information that was distributed via [RFC7752]
- [Idr] AD Review of draft-ietf-idr-bgp-ls-segment-… Alvaro Retana
- Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-segm… Ketan Talaulikar (ketant)
- Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-segm… Ketan Talaulikar (ketant)
- Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-segm… Alvaro Retana
- Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-segm… Ketan Talaulikar (ketant)
- Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-segm… Alvaro Retana
- Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-segm… Ketan Talaulikar (ketant)
- Re: [Idr] AD Review of draft-ietf-idr-bgp-ls-segm… Alvaro Retana