idnits 2.17.00 (12 Aug 2021) /tmp/idnits38389/draft-ietf-idr-bgp-ls-node-admin-tag-extension-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 18, 2018) is 1577 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 417 -- Looks like a reference, but probably isn't: '2' on line 419 -- Looks like a reference, but probably isn't: '3' on line 421 -- Looks like a reference, but probably isn't: '4' on line 423 -- Looks like a reference, but probably isn't: '5' on line 425 -- Looks like a reference, but probably isn't: '6' on line 427 -- Looks like a reference, but probably isn't: '7' on line 429 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing P. Sarkar, Ed. 3 Internet-Draft Arrcus, Inc. 4 Intended status: Standards Track H. Gredler 5 Expires: July 22, 2018 RtBrick, Inc. 6 S. Litkowski 7 Orange 8 January 18, 2018 10 Advertising Node Admin Tags in BGP Link-State Advertisements 11 draft-ietf-idr-bgp-ls-node-admin-tag-extension-03 13 Abstract 15 This document describes the protocol extensions to collect node 16 administrative tags adevertised in IGP Link State advertisements and 17 disseminate the same in BGP Link-State advertisement protocol, to 18 facilitate inter-AS TE applications that may need the same node 19 administrative tags to associate a subset of network devices spanning 20 across more than one AS with a specific functionality. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on July 22, 2018. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Per-Node Administrative Tag . . . . . . . . . . . . . . . . . 3 64 3. BGP-LS Extensions for Per-Node Administrative Tags . . . . . 4 65 3.1. Node Admin Tag TLV . . . . . . . . . . . . . . . . . . . 5 66 4. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 7 67 5. Applications . . . . . . . . . . . . . . . . . . . . . . . . 8 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 69 7. Manageability Considerations . . . . . . . . . . . . . . . . 9 70 7.1. Operational Considerations . . . . . . . . . . . . . . . 9 71 7.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 9 72 8. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 9 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 77 11.2. Informative References . . . . . . . . . . . . . . . . . 10 78 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 81 1. Introduction 83 Advertising Node Administrative Tags in Link State protocols like IS- 84 IS [RFC7917] and OSPF [RFC7777] defines an optional operational 85 capability, that allows tagging and grouping of the nodes in a IGP 86 domain. This, among other applications, allows simple management and 87 easy control over route and path selection, based on local configured 88 policies. However, node administrative tags advertised in IGP 89 advertisements let network operators associate nodes within a single 90 AS (if not a single area). This limits the use of such node 91 administrative tags and applications that need to associate a subset 92 of network devices spanning across multiple AS with a specific 93 functionality cannot use them. 95 To address the need for applications that require visibility into 96 Link State Databases (LSDBs) across IGP areas, or even across ASes, 97 the BGP-LS address-family/sub-address-family have been defined that 98 allows BGP to carry LSDB information. The BGP Network Layer 99 Reachability Information (NLRI) encoding format for BGP-LS and a new 100 BGP Path Attribute called BGP-LS attribute are defined in [RFC7752]. 101 Please refer to [RFC7752] for more details. 103 For the purpose of advertising node administrative tags within BGP 104 Link-State advertisements, a new Node Attribute TLV to be carried in 105 the corresponding BGP-LS Node NLRI is proposed. For more details on 106 the Node Attribute TLVs please refer to section 3.3.1 in [RFC7752] 108 2. Per-Node Administrative Tag 110 An administrative Tag is a 32-bit integer value that can be used to 111 identify a group of nodes in the entire routing domain. The new TLV 112 and sub-TLV proposed in IS-IS [RFC7917] and OSPF [RFC7777] 113 respectively, specifies one or more administrative tag values. A BGP 114 Link-State speaker that also participates in the IGP link state 115 advertisements exchange may learn one or more node administrative 116 tags advertised by another router in the same IGP domain. Such BGP- 117 LS speaker shall encode the same set of node administrative tags in 118 the corresponding Node Attribute TLV representing the network device 119 that originated the node administrative tags. 121 The node administrative tags advertised in IGP link state 122 advertisements will have either per-area(or per-level in IS-IS)scope 123 or 'global' scope. An operator may choose to advertise one set of 124 node administrative tags across areas (or levels in IS-IS) and 125 advertise another set of node administrative tags within a specific 126 area (or level). But evidently two areas within the same AS or two 127 different AS's may use the same node administrative tag for different 128 purposes. In such a case, applications will need to distinguish 129 between the per-area(or per-level) scoped administrative tags 130 originated from a specific node against those originated from the 131 same node with 'global' scope. 133 A BGP-LS router in a given AS while copying the node administrative 134 tags learnt from IGP link-state advertisements, MUST also copy the 135 scope associated with the node administrative tags. Refer to 136 Section 3.1 for how to encode the associated scope of a node 137 administrative tags as well. 139 To be able to distinguish between the significance of an 140 administrative tag learnt in one area, from that advertised in 141 another area, or another AS, any applications receiving such a BGP-LS 142 advertisement MUST consider the scope associated with each node 143 administrative tag along with the area(or level in IS-IS) and the AS 144 number of the originating node associated with corresponding IGP link 145 state advertisement. The area(or level) associated with the 146 corresponding IGP link state advertisement and the AS number 147 associated with the originating node can be derived from appropriate 148 node attributes (already defined in BGP-LS [RFC7752]) attached with 149 the corresponding Node NLRI. [RFC7752] specifies that ISIS level 150 information be encoded in Node NLRI [1] and OSPF Area Identifiers be 151 encoded in Node Descriptor Sub-TLVs [2]. 153 3. BGP-LS Extensions for Per-Node Administrative Tags 155 The BGP-LS NLRI can be a node NLRI, a link NLRI or a prefix NLRI. 156 The corresponding BGP-LS attribute is a node attribute, a link 157 attribute or a prefix attribute. BGP-LS [RFC7752] defines the TLVs 158 that map link-state information to BGP-LS NLRI and BGP-LS attribute. 159 This document adds an new Node Attribute TLV called 'Node Admin Tag 160 TLV' to encode node administrative tags information. 162 [RFC7917] defines the 'Node Admin Tag' sub-TLV in the Router 163 Capability TLV (type 242) in IS-IS Link State PDUs to encode node 164 administrative tags. Similarly [RFC7917] defines the 'Node 165 Administrative Tag' TLV in OSPF Router Information LSAs to encode 166 node administrative tags in OSPF Link State update packets. The node 167 administrative tags TLVs learnt from the IGP link state 168 advertisements of a specific node will all be inserted in a new Node 169 Admin Tag TLV and added to the corresponding Node are mapped to the 170 corresponding BGP-LS Node NLRI. Node administrative tags from IGP 171 advertisements are mapped to the corresponding Node Admin Tag TLV in 172 the following way. 174 +----------+----------------+----------+---------------+------------+ 175 | TLV Code | Description | Length | IS-IS TLV | OSPF | 176 | Point | | | /sub-TLV | LSA/TLV | 177 +----------+----------------+----------+---------------+------------+ 178 | TBD | Node Admin Tag | Variable | 242/21 [3] | RI-LSA/10 | 179 | | TLV | | | [4] | 180 +----------+----------------+----------+---------------+------------+ 182 Table 1: Node Admin Tag TLV Mapping from IGP 184 3.1. Node Admin Tag TLV 186 The new Node Administrative Tag TLV, like other BGP-LS Node Attribute 187 TLVs, is formatted as Type/Length/Value (TLV)triplets. Figure 1 188 below shows the format of the new TLV. 190 0 1 2 3 191 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 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Type | Length | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Flags | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Administrative Tag #1 | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Administrative Tag #2 | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 // // 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Administrative Tag #N | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 Type : A 2-octet field specifiying code-point of the new 207 TLV type. Code-point: TBA (suggested 1040) 209 Length: A 2-octet field that indicates the length of the value 210 portion in octets and will be a multiple of 4 octets 211 dependent on the number of tags advertised. 213 Value: A 2-octet 'Flags' field, followed by a sequence of multiple 214 4 octets defining the administrative tags. 216 Flags: A 2-octet field that carries flags associated with 217 all the administrative flags encoded in this TLV. 218 Following is the format of this field. 220 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 |L| Reserved | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 The following bit flags are defined: 227 L bit : If the L bit is set (1), it signifies that 228 all administrative flags encoded in this 229 TLV has per-area(or level in IS-IS) scope, 230 and should not be mixed with ones with same 231 value but with 'global' scope (L bit reset 232 to 0). 234 Figure 1: BGP Link-State Node Administrative Tag TLV 236 This new type of 'Node Admin Tag' TLVs can ONLY be added to the Node 237 Attribute associated with the Node NLRI that originates the 238 corresponding node administrative tags in an IGP domain. 240 All the node administrative tags with 'per-area' (or per-level) 241 scope, originated by a single node in an IGP domain SHALL be re- 242 originated in a single 'Node Admin Tag' TLV and inserted in the Node 243 NLRI generated for the same node. Similarly, all the node 244 administrative tags with 'global' scope originated by the same node 245 in IGP domain SHALL be re-originated in another 'Node Admin Tag' TLV 246 and inserted in the same Node NLRI generated for the originating 247 node. Multiple instances of a TLV may be generated by the BGP-LS 248 router for a given node in the IGP domain. This MAY happen if the 249 original node's link state advertisement carries more than 16383 node 250 administrative groups and a single TLV does not provide sufficient 251 space. As such multiple occurence of the 'Node Admin Tag' TLVs under 252 a single BGP LS NLRI is cumulative. 254 While copying node administrative tags from IGP link-state 255 advertisements to corresponding BGP-LS advertisements, the said BGP- 256 LS speaker MAY run all the node administrative flags through a 257 locally configured policy that selects which ones should be exported 258 and which ones not. And then the node administrative tag is copied 259 to the BGP-LS advertisement if it is permitted to do so by the said 260 policy. Definition of such a policy is outside the scope of this 261 document. 263 4. Elements of Procedure 265 Meaning of the Node administrative tags is generally opaque to the 266 BGP Link-State protocol. A router advertising the node 267 administrative tag (or tags) may be configured to do so without 268 knowing (or even explicitly supporting) functionality implied by the 269 tag. 271 Interpretation of tag values is specific to the administrative domain 272 of a particular network operator. The meaning of a node 273 administrative tag is defined by the network local policy. However 274 multiple administrative domain owners may agree on a common meaning 275 implied by an administrative tag for mutual benefit. 277 The semantics of the tag order has no meaning. There is no implied 278 meaning to the ordering of the tags that indicates a certain 279 operation or set of operations that need to be performed based on the 280 ordering. 282 Each tag SHOULD be treated as an independent identifier that MAY be 283 used in policy to perform a policy action. Node administrative tags 284 carried by the Node Admin Tag TLV SHOULD be used to indicate 285 independent characteristics of the node in the IGP domain that 286 originated it. The TLV SHOULD be considered as an unordered list. 287 Whilst policies may be implemented based on the presence of multiple 288 tags (e.g., if tag A AND tag B are present), they MUST NOT be reliant 289 upon the order of the tags (i.e., all policies should be considered 290 commutative operations, such that tag A preceding or following tag B 291 does not change their outcome). 293 For more details on guidance regarding usage of node administrative 294 tags please refer to section 4 [5] in [RFC7917] or section 2.2.1 [6] 295 in [RFC7777]. 297 5. Applications 299 [RFC7917] and [RFC7777] present some applications of node 300 administrative tags. 302 The Policy-based Explicit routing use case can be extended to inter- 303 area or inter-AS scenarios where an end to end path needs to avoid or 304 include nodes that have particular properties. Following are some 305 examples. 307 1. Geopolitical routing : preventing traffic from country A to 308 country B to cross country C. In this case, we may use node 309 administrative tags to encode geographical information (country). 310 Path computation may be required to take into account node 311 administrative tag to permit avoidance of nodes belonging to 312 country C. 314 2. Legacy node avoidance : in some specific cases, it is interesting 315 for a service-provider to force some traffic to avoid legacy 316 nodes in the network. For example, legacy nodes may not be 317 carrier class (no high availability), and a service provider may 318 want to ensure that critical traffic only uses nodes that are 319 providing high availability. 321 In case of inter-AS Traffic-Engineering applications, different ASes 322 SHOULD share their administrative tag policies. They MAY also need 323 to agree upon some common tagging policy for specific applications. 325 For more details on some possible applications with node 326 administrative tags please refer to section 3 [7] in [RFC7777]. 328 6. IANA Considerations 330 This document requests assigning code-points from the registry for 331 BGP-LS attribute TLVs based on Table 2. 333 7. Manageability Considerations 335 This section is structured as recommended in [RFC5706]. 337 7.1. Operational Considerations 339 7.1.1. Operations 341 Existing BGP and BGP-LS operational procedures apply. No new 342 operational procedures are defined in this document. 344 8. TLV/Sub-TLV Code Points Summary 346 This section contains the global table of all TLVs/Sub-TLVs defined 347 in this document. 349 +----------------+----------------+----------+ 350 | TLV Code Point | Description | Length | 351 +----------------+----------------+----------+ 352 | 1040 | Node Admin Tag | variable | 353 +----------------+----------------+----------+ 355 Table 2: Summary Table of TLV/Sub-TLV Codepoints 357 9. Security Considerations 359 Procedures and protocol extensions defined in this document do not 360 affect the BGP security model. See the 'Security Considerations' 361 section of [RFC4271] for a discussion of BGP security. Also refer to 362 [RFC4272] and [RFC6952] for analysis of security issues for BGP. 364 10. Acknowledgements 366 TBA. 368 11. References 370 11.1. Normative References 372 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 373 Requirement Levels", BCP 14, RFC 2119, 374 DOI 10.17487/RFC2119, March 1997, 375 . 377 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 378 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 379 DOI 10.17487/RFC4271, January 2006, 380 . 382 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 383 S. Ray, "North-Bound Distribution of Link-State and 384 Traffic Engineering (TE) Information Using BGP", RFC 7752, 385 DOI 10.17487/RFC7752, March 2016, 386 . 388 11.2. Informative References 390 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 391 RFC 4272, DOI 10.17487/RFC4272, January 2006, 392 . 394 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 395 Management of New Protocols and Protocol Extensions", 396 RFC 5706, DOI 10.17487/RFC5706, November 2009, 397 . 399 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 400 BGP, LDP, PCEP, and MSDP Issues According to the Keying 401 and Authentication for Routing Protocols (KARP) Design 402 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 403 . 405 [RFC7777] Hegde, S., Shakir, R., Smirnov, A., Li, Z., and B. 406 Decraene, "Advertising Node Administrative Tags in OSPF", 407 RFC 7777, DOI 10.17487/RFC7777, March 2016, 408 . 410 [RFC7917] Sarkar, P., Ed., Gredler, H., Hegde, S., Litkowski, S., 411 and B. Decraene, "Advertising Node Administrative Tags in 412 IS-IS", RFC 7917, DOI 10.17487/RFC7917, July 2016, 413 . 415 11.3. URIs 417 [1] http://tools.ietf.org/html/rfc7752#section-3.2 419 [2] http://tools.ietf.org/html/rfc7752#section-3.2.1.4 421 [3] http://tools.ietf.org/html/rfc7917#section-3.1 423 [4] http://tools.ietf.org/html/rfc7777#section-2.1 425 [5] http://tools.ietf.org/html/rfc7917#section-4 427 [6] http://tools.ietf.org/html/rfc7777#section-2.2.1 429 [7] http://tools.ietf.org/html/rfc7777#section-3 431 Authors' Addresses 433 Pushpasis Sarkar (editor) 434 Arrcus, Inc. 436 Email: pushpasis.ietf@gmail.com 438 Hannes Gredler 439 RtBrick, Inc. 441 Email: hannes@rtbrick.com 443 Stephane Litkowski 444 Orange 446 Email: stephane.litkowski@orange.com