idnits 2.17.1 draft-psarkar-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 (August 11, 2015) is 3179 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 477 -- Looks like a reference, but probably isn't: '2' on line 480 -- Looks like a reference, but probably isn't: '3' on line 485 -- Looks like a reference, but probably isn't: '4' on line 488 == Outdated reference: A later version (-13) exists of draft-ietf-idr-ls-distribution-07 == Outdated reference: A later version (-11) exists of draft-ietf-isis-node-admin-tag-00 == Outdated reference: A later version (-09) exists of draft-ietf-ospf-node-admin-tag-00 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 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 H. Gredler 4 Intended status: Standards Track Juniper Networks, Inc. 5 Expires: February 12, 2016 S. Litkowski 6 Orange 7 August 11, 2015 9 Advertising Per-node Admin Tags in BGP Link-State Advertisements 10 draft-psarkar-idr-bgp-ls-node-admin-tag-extension-01 12 Abstract 14 This document describes the protocol extensions to collect per-node 15 administrative tags adevertised in IGP Link State advertisements and 16 disseminate the same in BGP Link-State advertisement protocol, to 17 facilitate inter-AS TE applications that may need the same per-node 18 administrative tags to associate a subset of network devices spanning 19 across more than one AS with a specific functionality. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in RFC 2119 [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on February 12, 2016. 44 Copyright Notice 46 Copyright (c) 2015 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 Internet-DrafAdvertising Per-node Admin Tags in BGP Link-Sta August 2015 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Per-Node Administrative Tag . . . . . . . . . . . . . . . . . 4 65 3. BGP-LS Extensions for Per-Node Administrative Tags . . . . . 4 66 3.1. Node Admin Tag TLV . . . . . . . . . . . . . . . . . . . 5 67 4. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 7 68 5. Applications . . . . . . . . . . . . . . . . . . . . . . . . 8 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 70 7. Manageability Considerations . . . . . . . . . . . . . . . . 9 71 7.1. Operational Considerations . . . . . . . . . . . . . . . 9 72 7.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 9 73 8. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 9 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 75 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 78 11.2. Informative References . . . . . . . . . . . . . . . . . 10 79 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 82 1. Introduction 84 Advertising Per-node Administrative Tags in Link State protocols like 85 IS-IS [I-D.ietf-isis-node-admin-tag] and OSPF 86 [I-D.ietf-ospf-node-admin-tag] allows adding an optional operational 87 capability, that allows tagging and grouping of the nodes in a IGP 88 domain. This, among other applications, allows simple management and 89 easy control over route and path selection, based on local configured 90 policies. However per-node administrative tags advertised in IGP 91 advertisements let network operators associate nodes within a single 92 AS (if not a single area). This limits the use of such per-node 93 administrative tags and applications that need to associate a subset 94 of network devices spanning across multiple AS with a specific 95 functionality cannot use them. 97 To address the need for applications that require visibility into 98 LSDB across IGP areas, or even across ASes, the BGP-LS address- 100 Internet-DrafAdvertising Per-node Admin Tags in BGP Link-Sta August 2015 102 family/sub-address-family have been defined that allows BGP to carry 103 LSDB information. The BGP Network Layer Reachability Information 104 (NLRI) encoding format for BGP-LS and a new BGP Path Attribute called 105 BGP-LS attribute are defined in [I-D.ietf-idr-ls-distribution]. The 106 identifying key of each LSDB object, namely a node, a link or a 107 prefix, is encoded in the NLRI and the properties of the object are 108 encoded in the BGP-LS attribute. Figure 1 describes a typical 109 deployment scenario. In each IGP area, one or more nodes are 110 configured with BGP-LS. These BGP speakers form an IBGP mesh by 111 connecting to one or more route-reflectors. This way, all BGP 112 speakers - specifically the route-reflectors - obtain LSDB 113 information from all IGP areas (and from other ASes from EBGP peers). 114 An external component connects to the route-reflector to obtain this 115 information (perhaps moderated by a policy regarding what information 116 is sent to the external component, and what information isn't). 118 +------------+ 119 | Consumer | 120 +------------+ 121 ^ 122 | 123 v 124 +-------------------+ 125 | BGP Speaker | +-----------+ 126 | (Route-Reflector) | | Consumer | 127 +-------------------+ +-----------+ 128 ^ ^ ^ ^ 129 | | | | 130 +---------------+ | +-------------------+ | 131 | | | | 132 v v v v 133 +-----------+ +-----------+ +-----------+ 134 | BGP | | BGP | | BGP | 135 | Speaker | | Speaker | . . . | Speaker | 136 +-----------+ +-----------+ +-----------+ 137 ^ ^ ^ 138 | | | 139 IGP IGP IGP 141 Figure 1: Link State info collection 143 For the purpose of advertising per-node administrative tags within 144 BGP Link-State advertisements, a new Node Attribute TLV to be carried 145 in the corresponding BGP-LS Node NLRI is proposed. For more details 146 on the Node Attribute TLVs please refer to section 3.3.1 in 147 [I-D.ietf-idr-ls-distribution] 149 Internet-DrafAdvertising Per-node Admin Tags in BGP Link-Sta August 2015 151 2. Per-Node Administrative Tag 153 An administrative Tag is a 32-bit integer value that can be used to 154 identify a group of nodes in the entire routing domain. The new sub- 155 TLV specifies one or more administrative tag values. A BGP Link- 156 State speaker that also participates in the IGP link state 157 advertisements exchange may learn one or more per-node administrative 158 tags advertised by another router in the same IGP domain. Such BGP- 159 LS speaker shall encode the same set of per-node administrative tags 160 in the corresponding Node Attribute TLV representing the network 161 device that originated the per-node administrative tags. 163 The per-node administrative tags advertised in IGP link state 164 advertisements will have either per-area(or levels in IS-IS)scope or 165 'global' scope. Operator may choose to a set of per-node 166 administrative tags across areas (or levels in IS-IS) and another 167 advertise set of per-node administrative tags within the specific 168 area (or level). But evidently two areas within the same AS or two 169 different may use the same per-node administrative tag for different 170 purposes. In such case applications will need to distinguish between 171 the per-area(or level) scoped administrative tags originated from a 172 specific node against those originated from the same node with 173 'global' scope. 175 A BGP-LS router in a given AS while copying the per-node 176 administrative tags learnt from IGP link-state advertisements, MUST 177 also copy the scope associated with the per-node administrative tags. 178 Refer to Section 3.1 for how to encode the associated scope of a per- 179 node administrative tags as well. 181 To be able to distinguish between the significance of a per-area(or 182 level) administrative tag learnt in one area, from that advertised in 183 another area, or another AS, any applications receiving such a BGP-LS 184 advertisements MUST consider the scope associated with each per-node 185 administrative tag with 'per-area (or per-level) along with the 186 area(or level in IS-IS) associated with corresponding IGP link state 187 advertisement and the AS number associated with the originating node. 188 The area(or level) associated with corresponding IGP link state 189 advertisement and the AS number associated with the originating node 190 can be derived from appropriate node attributes (already defined in 191 BGP-LS [I-D.ietf-idr-ls-distribution]) attached with the 192 corresponding Node NLRI. 194 3. BGP-LS Extensions for Per-Node Administrative Tags 196 The BGP-LS NLRI can be a node NLRI, a link NLRI or a prefix NLRI. 197 The corresponding BGP-LS attribute is a node attribute, a link 198 attribute or a prefix attribute. BGP-LS 200 Internet-DrafAdvertising Per-node Admin Tags in BGP Link-Sta August 2015 202 [I-D.ietf-idr-ls-distribution] defines the TLVs that map link-state 203 information to BGP-LS NLRI and BGP-LS attribute. This document adds 204 an new Node Attribute TLV called 'Node Admin Tag TLV' to encode per- 205 node administrative tags information. 207 [I-D.ietf-isis-node-admin-tag] defines the 'Per-node Admin Tag' sub- 208 TLV in the Router Capability TLV (type 242) in IS-IS Link State PDUs 209 to encode per-node administrative tags. Similarly 210 [I-D.ietf-isis-node-admin-tag] defines the 'Per-node Administrative 211 Tag' TLV in OSPF Router Information LSAs to encode per-node 212 administrative tags in OSPF Link State update packets. The per-node 213 administrative tags TLVs learnt from the IGP link state 214 advertisements of a specific node will all be inserted in a new Node 215 Admin Tag TLV and added to the corresponding Node are mapped to the 216 corresponding BGP-LS Node NLRI. Per-node administrative tags from 217 IGP advertisements are mapped to the corresponding Node Admin Tag TLV 218 in the following way. 220 +----------+---------------+----------+---------------+-------------+ 221 | TLV Code | Description | Length | IS-IS TLV | OSPF | 222 | Point | | | /sub-TLV | LSA/TLV | 223 +----------+---------------+----------+---------------+-------------+ 224 | TBD | Node Admin | Variable | 242/TBD [1] | RI-LSA/TBD | 225 | | Tag TLV | | | [2] | 226 +----------+---------------+----------+---------------+-------------+ 228 Table 1: Node Admin Tag TLV Mapping from IGP 230 3.1. Node Admin Tag TLV 232 The new Node Administrative Tag TLV, like other BGP-LS Node Attribute 233 TLVs, is formatted as Type/Length/Value (TLV)triplets. Figure 2 234 below shows the format of the new TLV. 236 Internet-DrafAdvertising Per-node Admin Tags in BGP Link-Sta August 2015 238 0 1 2 3 239 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 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Type | Length | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Flags | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Administrative Tag #1 | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Administrative Tag #2 | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 // // 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Administrative Tag #N | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 Type : A 2-octet field specifiying code-point of the new 255 sub-TLV type. Code-point: TBA (suggested 1040) 257 Length: A 2-octet field that indicates the length of the value 258 portion in octets and will be a multiple of 4 octets 259 dependent on the number of tags advertised. 261 Value: A 2-octet 'Flags' field, followed by a sequence of multiple 262 4 octets defining the administrative tags. 264 Flags: A 2-octet field that carries flags associated with 265 all the administrative flags encoded in this TLV. 266 Following is the format of this field. 268 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 |L| Reserved | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 The following bit flags are defined: 275 L bit : If the L bit is set (1), it signifies that 276 all administrative flags encoded in this 277 TLV has per-area(or level in IS-IS) scope, 278 and should not be mixed with ones with same 279 value but with 'global' scope (L bit reset 280 to 0). 282 Figure 2: BGP Link-State Node Administrative Tag TLV 284 Internet-DrafAdvertising Per-node Admin Tags in BGP Link-Sta August 2015 286 This new type of 'Node Admin Tag' TLVs can ONLY be added to the Node 287 Attribute associated with the Node NLRI that originates the 288 corresponding per-node administrative tags in IGP domain. 290 All the per-node administrative tags with 'per-area' (or per-level) 291 scope, originated by a single node in IGP domain SHALL be re- 292 originated in a single 'Node Admin Tag' TLV and inserted in the Node 293 NLRI generated for the same node. Similarly, all the per-node 294 administrative tags with 'global' scope originated by the same node 295 in IGP domain SHALL be re-originated in another 'Node Admin Tag' TLV 296 and inserted in the same Node NLRI generated for the originating 297 node. Multiple instances of a TLV may be generated by the BGP-lS 298 router for a given node in the IGP domain. This MAY happen if the 299 original node's link state advertisement carries more than 16383 per- 300 node administrative groups and a single TLV does not provide 301 sufficient space. As such multiple occurence of the 'Node Admin Tag' 302 TLVs under a single BGP LS NLRI is cumulative. 304 While copying per-node administrative tags from IGP link-state 305 advertisements to corresponding BGP-LS advertisements, the said BGP- 306 LS speaker MAY run all the per-node administrative flags through a 307 locally configured policy that selects which ones should be exported 308 and which ones not. And then the per-node administrative tag is 309 copied to the BGP-LS advertisement if it is permitted to do so by the 310 said policy. 312 4. Elements of Procedure 314 Meaning of the Per-node administrative tags is generally opaque to 315 BGP Link-State protocol. Router advertising the per-node 316 administrative tag (or tags) may be configured to do so without 317 knowing (or even explicitly supporting) functionality implied by the 318 tag. 320 Interpretation of tag values is specific to the administrative domain 321 of a particular network operator. The meaning of a per-node 322 administrative tag is defined by the network local policy and is 323 controlled via the configuration. However multiple administrative 324 domain owners may agree on a common meaning implied by a 325 administrative tag for mutual benefit. 327 The semantics of the tag order has no meaning. There is no implied 328 meaning to the ordering of the tags that indicates a certain 329 operation or set of operations that need to be performed based on the 330 ordering. 332 Each tag SHOULD be treated as an independent identifier that MAY be 333 used in policy to perform a policy action. Per-node administrative 335 Internet-DrafAdvertising Per-node Admin Tags in BGP Link-Sta August 2015 337 tags carried by the Node Admin Tag TLV SHOULD be used to indicate a 338 independent characteristics of the node in IGP domain that originated 339 it. The TLV SHOULD be considered as an unordered list. Whilst 340 policies may be implemented based on the presence of multiple tags 341 (e.g., if tag A AND tag B are present), they MUST NOT be reliant upon 342 the order of the tags (i.e., all policies should be considered 343 commutative operations, such that tag A preceding or following tag B 344 does not change their outcome). 346 For more details on guidance on usage of per-node administrative tags 347 please refer to section 4 [3] in [I-D.ietf-isis-node-admin-tag]. 349 5. Applications 351 [I-D.ietf-isis-node-admin-tag] and [I-D.ietf-ospf-node-admin-tag] 352 present some applications of node administrative tags. 354 The policy-based Explicit routing use case can be extended to inter- 355 area or inter-AS scenarios where an end to end path needs to avoid or 356 include nodes that have particular properties. Following are some 357 examples. 359 1. Geopolitical routing : preventing traffic from country A to 360 country B to cross country C. In this case, we may use node 361 administrative tags to encode geographical information (country). 362 Path computation will be required to take into account node 363 administrative tag to permit avoidance of nodes belonging to 364 country C. 366 2. Legacy node avoidance : in some specific cases, it is interesting 367 for service-provider to force some traffic to avoid legacy nodes 368 in the network. For example, legacy nodes may not be carrier 369 class (no high availability), and service provider wants to 370 ensure that critical traffic only uses nodes that are providing 371 high availability. 373 In case of inter-AS Traffic-Engineering applications, different ASes 374 SHOULD share their admin tag policies. They MAY also need to agree 375 upon some common tagging policy for specific applications. 377 For more details on some possible applications with per-node 378 administrative tags please refer to section 5 [4] in 379 [I-D.ietf-isis-node-admin-tag]. 381 Internet-DrafAdvertising Per-node Admin Tags in BGP Link-Sta August 2015 383 6. IANA Considerations 385 This document requests assigning code-points from the registry for 386 BGP-LS attribute TLVs based on table Table 2. 388 7. Manageability Considerations 390 This section is structured as recommended in [RFC5706]. 392 7.1. Operational Considerations 394 7.1.1. Operations 396 Existing BGP and BGP-LS operational procedures apply. No new 397 operation procedures are defined in this document. 399 8. TLV/Sub-TLV Code Points Summary 401 This section contains the global table of all TLVs/Sub-TLVs defined 402 in this document. 404 +----------------+----------------+----------+ 405 | TLV Code Point | Description | Length | 406 +----------------+----------------+----------+ 407 | 1040 | Node Admin Tag | variable | 408 +----------------+----------------+----------+ 410 Table 2: Summary Table of TLV/Sub-TLV Codepoints 412 9. Security Considerations 414 Procedures and protocol extensions defined in this document do not 415 affect the BGP security model. See the 'Security Considerations' 416 section of [RFC4271] for a discussion of BGP security. Also refer to 417 [RFC4272] and [RFC6952] for analysis of security issues for BGP. 419 10. Acknowledgements 421 TBD. 423 11. References 425 11.1. Normative References 427 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 428 Requirement Levels", BCP 14, RFC 2119, 429 DOI 10.17487/RFC2119, March 1997, 430 . 432 Internet-DrafAdvertising Per-node Admin Tags in BGP Link-Sta August 2015 434 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 435 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 436 DOI 10.17487/RFC4271, January 2006, 437 . 439 11.2. Informative References 441 [I-D.ietf-idr-ls-distribution] 442 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 443 Ray, "North-Bound Distribution of Link-State and TE 444 Information using BGP", draft-ietf-idr-ls-distribution-07 445 (work in progress), November 2014. 447 [I-D.ietf-isis-node-admin-tag] 448 Sarkar, P., Gredler, H., Hegde, S., Litkowski, S., 449 Decraene, B., Li, Z., Aries, E., Rodriguez, R., and H. 450 Raghuveer, "Advertising Per-node Admin Tags in IS-IS", 451 draft-ietf-isis-node-admin-tag-00 (work in progress), 452 December 2014. 454 [I-D.ietf-ospf-node-admin-tag] 455 Hegde, S., Raghuveer, H., Gredler, H., Shakir, R., 456 Smirnov, A., Li, Z., and B. Decraene, "Advertising per- 457 node administrative tags in OSPF", draft-ietf-ospf-node- 458 admin-tag-00 (work in progress), October 2014. 460 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 461 RFC 4272, DOI 10.17487/RFC4272, January 2006, 462 . 464 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 465 Management of New Protocols and Protocol Extensions", 466 RFC 5706, DOI 10.17487/RFC5706, November 2009, 467 . 469 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 470 BGP, LDP, PCEP, and MSDP Issues According to the Keying 471 and Authentication for Routing Protocols (KARP) Design 472 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 473 . 475 11.3. URIs 477 [1] http://tools.ietf.org/html/draft-ietf-isis-node-admin-tag- 478 00#section-3.1 480 [2] http://tools.ietf.org/html/draft-ietf-ospf-node-admin-tag- 481 00#section-4.1 483 Internet-DrafAdvertising Per-node Admin Tags in BGP Link-Sta August 2015 485 [3] http://tools.ietf.org/html/draft-ietf-isis-node-admin-tag- 486 00#section-4 488 [4] http://tools.ietf.org/html/draft-ietf-isis-node-admin-tag- 489 00#section-5 491 Authors' Addresses 493 Pushpasis Sarkar (editor) 494 Juniper Networks, Inc. 495 Electra, Exora Business Park 496 Bangalore, KA 560103 497 India 499 Email: psarkar@juniper.net 501 Hannes Gredler 502 Juniper Networks, Inc. 503 1194 N. Mathilda Ave. 504 Sunnyvale, CA 94089 505 US 507 Email: hannes@juniper.net 509 Stephane Litkowski 510 Orange 512 Email: stephane.litkowski@orange.com