idnits 2.17.1 draft-ietf-idr-bgp-ls-node-admin-tag-extension-01.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 (June 04, 2017) is 2491 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 446 -- Looks like a reference, but probably isn't: '2' on line 448 -- Looks like a reference, but probably isn't: '3' on line 450 -- Looks like a reference, but probably isn't: '4' on line 452 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 5 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: December 6, 2017 RtBrick, Inc. 6 S. Litkowski 7 Orange 8 June 04, 2017 10 Advertising Node Admin Tags in BGP Link-State Advertisements 11 draft-ietf-idr-bgp-ls-node-admin-tag-extension-01 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 http://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 December 6, 2017. 45 Copyright Notice 47 Copyright (c) 2017 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 (http://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 . . . . . . . . . . . . . . . . . 4 64 3. BGP-LS Extensions for Per-Node Administrative Tags . . . . . 5 65 3.1. Node Admin Tag TLV . . . . . . . . . . . . . . . . . . . 5 66 4. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 7 67 5. Applications . . . . . . . . . . . . . . . . . . . . . . . . 8 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . . . 10 81 1. Introduction 83 Advertising Node Administrative Tags in Link State protocols like IS- 84 IS [RFC7917] and OSPF [RFC7777] allows adding 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 LSDB across IGP areas, or even across ASes, the BGP-LS address- 97 family/sub-address-family have been defined that allows BGP to carry 98 LSDB information. The BGP Network Layer Reachability Information 99 (NLRI) encoding format for BGP-LS and a new BGP Path Attribute called 100 BGP-LS attribute are defined in [RFC7752]. The identifying key of 101 each LSDB object, namely a node, a link or a prefix, is encoded in 102 the NLRI and the properties of the object are encoded in the BGP-LS 103 attribute. Figure 1 describes a typical deployment scenario. In 104 each IGP area, one or more nodes are configured with BGP-LS. These 105 BGP speakers form an IBGP mesh by connecting to one or more route- 106 reflectors. This way, all BGP speakers - specifically the route- 107 reflectors - obtain LSDB information from all IGP areas (and from 108 other ASes from EBGP peers). An external component connects to the 109 route-reflector to obtain this information (perhaps moderated by a 110 policy regarding what information is sent to the external component, 111 and what information isn't). 113 +------------+ 114 | Consumer | 115 +------------+ 116 ^ 117 | 118 v 119 +-------------------+ 120 | BGP Speaker | +-----------+ 121 | (Route-Reflector) | | Consumer | 122 +-------------------+ +-----------+ 123 ^ ^ ^ ^ 124 | | | | 125 +---------------+ | +-------------------+ | 126 | | | | 127 v v v v 128 +-----------+ +-----------+ +-----------+ 129 | BGP | | BGP | | BGP | 130 | Speaker | | Speaker | . . . | Speaker | 131 +-----------+ +-----------+ +-----------+ 132 ^ ^ ^ 133 | | | 134 IGP IGP IGP 136 Figure 1: Link State info collection 138 For the purpose of advertising node administrative tags within BGP 139 Link-State advertisements, a new Node Attribute TLV to be carried in 140 the corresponding BGP-LS Node NLRI is proposed. For more details on 141 the Node Attribute TLVs please refer to section 3.3.1 in [RFC7752] 143 2. Per-Node Administrative Tag 145 An administrative Tag is a 32-bit integer value that can be used to 146 identify a group of nodes in the entire routing domain. The new sub- 147 TLV specifies one or more administrative tag values. A BGP Link- 148 State speaker that also participates in the IGP link state 149 advertisements exchange may learn one or more node administrative 150 tags advertised by another router in the same IGP domain. Such BGP- 151 LS speaker shall encode the same set of node administrative tags in 152 the corresponding Node Attribute TLV representing the network device 153 that originated the node administrative tags. 155 The node administrative tags advertised in IGP link state 156 advertisements will have either per-area(or levels in IS-IS)scope or 157 'global' scope. Operator may choose to a set of node administrative 158 tags across areas (or levels in IS-IS) and another advertise set of 159 node administrative tags within the specific area (or level). But 160 evidently two areas within the same AS or two different may use the 161 same node administrative tag for different purposes. In such case 162 applications will need to distinguish between the per-area(or level) 163 scoped administrative tags originated from a specific node against 164 those originated from the same node with 'global' scope. 166 A BGP-LS router in a given AS while copying the node administrative 167 tags learnt from IGP link-state advertisements, MUST also copy the 168 scope associated with the node administrative tags. Refer to 169 Section 3.1 for how to encode the associated scope of a node 170 administrative tags as well. 172 To be able to distinguish between the significance of a per-area(or 173 level) administrative tag learnt in one area, from that advertised in 174 another area, or another AS, any applications receiving such a BGP-LS 175 advertisements MUST consider the scope associated with each node 176 administrative tag with 'per-area (or per-level) along with the 177 area(or level in IS-IS) associated with corresponding IGP link state 178 advertisement and the AS number associated with the originating node. 179 The area(or level) associated with corresponding IGP link state 180 advertisement and the AS number associated with the originating node 181 can be derived from appropriate node attributes (already defined in 182 BGP-LS [RFC7752]) attached with the corresponding Node NLRI. 184 3. BGP-LS Extensions for Per-Node Administrative Tags 186 The BGP-LS NLRI can be a node NLRI, a link NLRI or a prefix NLRI. 187 The corresponding BGP-LS attribute is a node attribute, a link 188 attribute or a prefix attribute. BGP-LS [RFC7752] defines the TLVs 189 that map link-state information to BGP-LS NLRI and BGP-LS attribute. 190 This document adds an new Node Attribute TLV called 'Node Admin Tag 191 TLV' to encode node administrative tags information. 193 [RFC7917] defines the 'Node Admin Tag' sub-TLV in the Router 194 Capability TLV (type 242) in IS-IS Link State PDUs to encode node 195 administrative tags. Similarly [RFC7917] defines the 'Node 196 Administrative Tag' TLV in OSPF Router Information LSAs to encode 197 node administrative tags in OSPF Link State update packets. The node 198 administrative tags TLVs learnt from the IGP link state 199 advertisements of a specific node will all be inserted in a new Node 200 Admin Tag TLV and added to the corresponding Node are mapped to the 201 corresponding BGP-LS Node NLRI. Node administrative tags from IGP 202 advertisements are mapped to the corresponding Node Admin Tag TLV in 203 the following way. 205 +----------+---------------+----------+---------------+-------------+ 206 | TLV Code | Description | Length | IS-IS TLV | OSPF | 207 | Point | | | /sub-TLV | LSA/TLV | 208 +----------+---------------+----------+---------------+-------------+ 209 | TBD | Node Admin | Variable | 242/TBD [1] | RI-LSA/TBD | 210 | | Tag TLV | | | [2] | 211 +----------+---------------+----------+---------------+-------------+ 213 Table 1: Node Admin Tag TLV Mapping from IGP 215 3.1. Node Admin Tag TLV 217 The new Node Administrative Tag TLV, like other BGP-LS Node Attribute 218 TLVs, is formatted as Type/Length/Value (TLV)triplets. Figure 2 219 below shows the format of the new TLV. 221 0 1 2 3 222 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 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Type | Length | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Flags | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Administrative Tag #1 | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Administrative Tag #2 | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 // // 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Administrative Tag #N | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 Type : A 2-octet field specifiying code-point of the new 238 TLV type. Code-point: TBA (suggested 1040) 240 Length: A 2-octet field that indicates the length of the value 241 portion in octets and will be a multiple of 4 octets 242 dependent on the number of tags advertised. 244 Value: A 2-octet 'Flags' field, followed by a sequence of multiple 245 4 octets defining the administrative tags. 247 Flags: A 2-octet field that carries flags associated with 248 all the administrative flags encoded in this TLV. 249 Following is the format of this field. 251 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 |L| Reserved | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 The following bit flags are defined: 258 L bit : If the L bit is set (1), it signifies that 259 all administrative flags encoded in this 260 TLV has per-area(or level in IS-IS) scope, 261 and should not be mixed with ones with same 262 value but with 'global' scope (L bit reset 263 to 0). 265 Figure 2: BGP Link-State Node Administrative Tag TLV 267 This new type of 'Node Admin Tag' TLVs can ONLY be added to the Node 268 Attribute associated with the Node NLRI that originates the 269 corresponding node administrative tags in IGP domain. 271 All the node administrative tags with 'per-area' (or per-level) 272 scope, originated by a single node in IGP domain SHALL be re- 273 originated in a single 'Node Admin Tag' TLV and inserted in the Node 274 NLRI generated for the same node. Similarly, all the node 275 administrative tags with 'global' scope originated by the same node 276 in IGP domain SHALL be re-originated in another 'Node Admin Tag' TLV 277 and inserted in the same Node NLRI generated for the originating 278 node. Multiple instances of a TLV may be generated by the BGP-lS 279 router for a given node in the IGP domain. This MAY happen if the 280 original node's link state advertisement carries more than 16383 node 281 administrative groups and a single TLV does not provide sufficient 282 space. As such multiple occurence of the 'Node Admin Tag' TLVs under 283 a single BGP LS NLRI is cumulative. 285 While copying node administrative tags from IGP link-state 286 advertisements to corresponding BGP-LS advertisements, the said BGP- 287 LS speaker MAY run all the node administrative flags through a 288 locally configured policy that selects which ones should be exported 289 and which ones not. And then the node administrative tag is copied 290 to the BGP-LS advertisement if it is permitted to do so by the said 291 policy. 293 4. Elements of Procedure 295 Meaning of the Node administrative tags is generally opaque to BGP 296 Link-State protocol. Router advertising the node administrative tag 297 (or tags) may be configured to do so without knowing (or even 298 explicitly supporting) functionality implied by the tag. 300 Interpretation of tag values is specific to the administrative domain 301 of a particular network operator. The meaning of a node 302 administrative tag is defined by the network local policy and is 303 controlled via the configuration. However multiple administrative 304 domain owners may agree on a common meaning implied by a 305 administrative tag for mutual benefit. 307 The semantics of the tag order has no meaning. There is no implied 308 meaning to the ordering of the tags that indicates a certain 309 operation or set of operations that need to be performed based on the 310 ordering. 312 Each tag SHOULD be treated as an independent identifier that MAY be 313 used in policy to perform a policy action. Node administrative tags 314 carried by the Node Admin Tag TLV SHOULD be used to indicate a 315 independent characteristics of the node in IGP domain that originated 316 it. The TLV SHOULD be considered as an unordered list. Whilst 317 policies may be implemented based on the presence of multiple tags 318 (e.g., if tag A AND tag B are present), they MUST NOT be reliant upon 319 the order of the tags (i.e., all policies should be considered 320 commutative operations, such that tag A preceding or following tag B 321 does not change their outcome). 323 For more details on guidance on usage of node administrative tags 324 please refer to section 4 [3] in [RFC7917]. 326 5. Applications 328 [RFC7917] and [RFC7777] present some applications of node 329 administrative tags. 331 The Policy-based Explicit routing use case can be extended to inter- 332 area or inter-AS scenarios where an end to end path needs to avoid or 333 include nodes that have particular properties. Following are some 334 examples. 336 1. Geopolitical routing : preventing traffic from country A to 337 country B to cross country C. In this case, we may use node 338 administrative tags to encode geographical information (country). 339 Path computation will be required to take into account node 340 administrative tag to permit avoidance of nodes belonging to 341 country C. 343 2. Legacy node avoidance : in some specific cases, it is interesting 344 for service-provider to force some traffic to avoid legacy nodes 345 in the network. For example, legacy nodes may not be carrier 346 class (no high availability), and service provider wants to 347 ensure that critical traffic only uses nodes that are providing 348 high availability. 350 In case of inter-AS Traffic-Engineering applications, different ASes 351 SHOULD share their administrative tag policies. They MAY also need 352 to agree upon some common tagging policy for specific applications. 354 For more details on some possible applications with node 355 administrative tags please refer to section 3 [4] in [RFC7777]. 357 6. IANA Considerations 359 This document requests assigning code-points from the registry for 360 BGP-LS attribute TLVs based on table Table 2. 362 7. Manageability Considerations 364 This section is structured as recommended in [RFC5706]. 366 7.1. Operational Considerations 368 7.1.1. Operations 370 Existing BGP and BGP-LS operational procedures apply. No new 371 operation procedures are defined in this document. 373 8. TLV/Sub-TLV Code Points Summary 375 This section contains the global table of all TLVs/Sub-TLVs defined 376 in this document. 378 +----------------+----------------+----------+ 379 | TLV Code Point | Description | Length | 380 +----------------+----------------+----------+ 381 | 1040 | Node Admin Tag | variable | 382 +----------------+----------------+----------+ 384 Table 2: Summary Table of TLV/Sub-TLV Codepoints 386 9. Security Considerations 388 Procedures and protocol extensions defined in this document do not 389 affect the BGP security model. See the 'Security Considerations' 390 section of [RFC4271] for a discussion of BGP security. Also refer to 391 [RFC4272] and [RFC6952] for analysis of security issues for BGP. 393 10. Acknowledgements 395 TBA. 397 11. References 399 11.1. Normative References 401 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 402 Requirement Levels", BCP 14, RFC 2119, 403 DOI 10.17487/RFC2119, March 1997, 404 . 406 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 407 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 408 DOI 10.17487/RFC4271, January 2006, 409 . 411 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 412 S. Ray, "North-Bound Distribution of Link-State and 413 Traffic Engineering (TE) Information Using BGP", RFC 7752, 414 DOI 10.17487/RFC7752, March 2016, 415 . 417 11.2. Informative References 419 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 420 RFC 4272, DOI 10.17487/RFC4272, January 2006, 421 . 423 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 424 Management of New Protocols and Protocol Extensions", 425 RFC 5706, DOI 10.17487/RFC5706, November 2009, 426 . 428 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 429 BGP, LDP, PCEP, and MSDP Issues According to the Keying 430 and Authentication for Routing Protocols (KARP) Design 431 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 432 . 434 [RFC7777] Hegde, S., Shakir, R., Smirnov, A., Li, Z., and B. 435 Decraene, "Advertising Node Administrative Tags in OSPF", 436 RFC 7777, DOI 10.17487/RFC7777, March 2016, 437 . 439 [RFC7917] Sarkar, P., Ed., Gredler, H., Hegde, S., Litkowski, S., 440 and B. Decraene, "Advertising Node Administrative Tags in 441 IS-IS", RFC 7917, DOI 10.17487/RFC7917, July 2016, 442 . 444 11.3. URIs 446 [1] http://tools.ietf.org/html/rfc7917#section-3.1 448 [2] http://tools.ietf.org/html/rfc7777#section-2.1 450 [3] http://tools.ietf.org/html/rfc7917#section-4 452 [4] http://tools.ietf.org/html/rfc7777#section-3 454 Authors' Addresses 455 Pushpasis Sarkar (editor) 456 Arrcus, Inc. 458 Email: pushpasis.ietf@gmail.com 460 Hannes Gredler 461 RtBrick, Inc. 463 Email: hannes@rtbrick.com 465 Stephane Litkowski 466 Orange 468 Email: stephane.litkowski@orange.com