idnits 2.17.1 draft-psarkar-idr-bgp-ls-node-admin-tag-extension-04.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 (May 13, 2016) is 2904 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 453 -- Looks like a reference, but probably isn't: '2' on line 456 -- Looks like a reference, but probably isn't: '3' on line 459 -- Looks like a reference, but probably isn't: '4' on line 462 == 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 (~~), 3 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 Individual Contributor 5 Expires: November 14, 2016 S. Litkowski 6 Orange 7 May 13, 2016 9 Advertising Node Admin Tags in BGP Link-State Advertisements 10 draft-psarkar-idr-bgp-ls-node-admin-tag-extension-04 12 Abstract 14 This document describes the protocol extensions to collect 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 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 November 14, 2016. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Per-Node Administrative Tag . . . . . . . . . . . . . . . . . 4 63 3. BGP-LS Extensions for Per-Node Administrative Tags . . . . . 4 64 3.1. Node Admin Tag TLV . . . . . . . . . . . . . . . . . . . 5 65 4. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 7 66 5. Applications . . . . . . . . . . . . . . . . . . . . . . . . 8 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 7. Manageability Considerations . . . . . . . . . . . . . . . . 9 69 7.1. Operational Considerations . . . . . . . . . . . . . . . 9 70 7.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 9 71 8. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 9 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 76 11.2. Informative References . . . . . . . . . . . . . . . . . 10 77 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 Advertising Node Administrative Tags in Link State protocols like IS- 83 IS [I-D.ietf-isis-node-admin-tag] and OSPF 84 [I-D.ietf-ospf-node-admin-tag] 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 [I-D.ietf-idr-ls-distribution]. The 101 identifying key of each LSDB object, namely a node, a link or a 102 prefix, is encoded in the NLRI and the properties of the object are 103 encoded in the BGP-LS attribute. Figure 1 describes a typical 104 deployment scenario. In each IGP area, one or more nodes are 105 configured with BGP-LS. These BGP speakers form an IBGP mesh by 106 connecting to one or more route-reflectors. This way, all BGP 107 speakers - specifically the route-reflectors - obtain LSDB 108 information from all IGP areas (and from other ASes from EBGP peers). 109 An external component connects to the route-reflector to obtain this 110 information (perhaps moderated by a policy regarding what information 111 is sent to the external component, 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 142 [I-D.ietf-idr-ls-distribution] 144 2. Per-Node Administrative Tag 146 An administrative Tag is a 32-bit integer value that can be used to 147 identify a group of nodes in the entire routing domain. The new sub- 148 TLV specifies one or more administrative tag values. A BGP Link- 149 State speaker that also participates in the IGP link state 150 advertisements exchange may learn one or more node administrative 151 tags advertised by another router in the same IGP domain. Such BGP- 152 LS speaker shall encode the same set of node administrative tags in 153 the corresponding Node Attribute TLV representing the network device 154 that originated the node administrative tags. 156 The node administrative tags advertised in IGP link state 157 advertisements will have either per-area(or levels in IS-IS)scope or 158 'global' scope. Operator may choose to a set of node administrative 159 tags across areas (or levels in IS-IS) and another advertise set of 160 node administrative tags within the specific area (or level). But 161 evidently two areas within the same AS or two different may use the 162 same node administrative tag for different purposes. In such case 163 applications will need to distinguish between the per-area(or level) 164 scoped administrative tags originated from a specific node against 165 those originated from the same node with 'global' scope. 167 A BGP-LS router in a given AS while copying the node administrative 168 tags learnt from IGP link-state advertisements, MUST also copy the 169 scope associated with the node administrative tags. Refer to 170 Section 3.1 for how to encode the associated scope of a node 171 administrative tags as well. 173 To be able to distinguish between the significance of a per-area(or 174 level) administrative tag learnt in one area, from that advertised in 175 another area, or another AS, any applications receiving such a BGP-LS 176 advertisements MUST consider the scope associated with each node 177 administrative tag with 'per-area (or per-level) along with the 178 area(or level in IS-IS) associated with corresponding IGP link state 179 advertisement and the AS number associated with the originating node. 180 The area(or level) associated with corresponding IGP link state 181 advertisement and the AS number associated with the originating node 182 can be derived from appropriate node attributes (already defined in 183 BGP-LS [I-D.ietf-idr-ls-distribution]) attached with the 184 corresponding Node NLRI. 186 3. BGP-LS Extensions for Per-Node Administrative Tags 188 The BGP-LS NLRI can be a node NLRI, a link NLRI or a prefix NLRI. 189 The corresponding BGP-LS attribute is a node attribute, a link 190 attribute or a prefix attribute. BGP-LS 191 [I-D.ietf-idr-ls-distribution] defines the TLVs that map link-state 192 information to BGP-LS NLRI and BGP-LS attribute. This document adds 193 an new Node Attribute TLV called 'Node Admin Tag TLV' to encode node 194 administrative tags information. 196 [I-D.ietf-isis-node-admin-tag] defines the 'Node Admin Tag' sub-TLV 197 in the Router Capability TLV (type 242) in IS-IS Link State PDUs to 198 encode node administrative tags. Similarly 199 [I-D.ietf-isis-node-admin-tag] defines the 'Node Administrative Tag' 200 TLV in OSPF Router Information LSAs to encode node administrative 201 tags in OSPF Link State update packets. The node administrative tags 202 TLVs learnt from the IGP link state advertisements of a specific node 203 will all be inserted in a new Node Admin Tag TLV and added to the 204 corresponding Node are mapped to the corresponding BGP-LS Node NLRI. 205 Node administrative tags from IGP advertisements are mapped to the 206 corresponding Node Admin Tag TLV in the following way. 208 +----------+---------------+----------+---------------+-------------+ 209 | TLV Code | Description | Length | IS-IS TLV | OSPF | 210 | Point | | | /sub-TLV | LSA/TLV | 211 +----------+---------------+----------+---------------+-------------+ 212 | TBD | Node Admin | Variable | 242/TBD [1] | RI-LSA/TBD | 213 | | Tag TLV | | | [2] | 214 +----------+---------------+----------+---------------+-------------+ 216 Table 1: Node Admin Tag TLV Mapping from IGP 218 3.1. Node Admin Tag TLV 220 The new Node Administrative Tag TLV, like other BGP-LS Node Attribute 221 TLVs, is formatted as Type/Length/Value (TLV)triplets. Figure 2 222 below shows the format of the new TLV. 224 0 1 2 3 225 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 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Type | Length | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | Flags | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Administrative Tag #1 | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Administrative Tag #2 | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 // // 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Administrative Tag #N | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 Type : A 2-octet field specifiying code-point of the new 241 TLV type. Code-point: TBA (suggested 1040) 243 Length: A 2-octet field that indicates the length of the value 244 portion in octets and will be a multiple of 4 octets 245 dependent on the number of tags advertised. 247 Value: A 2-octet 'Flags' field, followed by a sequence of multiple 248 4 octets defining the administrative tags. 250 Flags: A 2-octet field that carries flags associated with 251 all the administrative flags encoded in this TLV. 252 Following is the format of this field. 254 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 |L| Reserved | 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 The following bit flags are defined: 261 L bit : If the L bit is set (1), it signifies that 262 all administrative flags encoded in this 263 TLV has per-area(or level in IS-IS) scope, 264 and should not be mixed with ones with same 265 value but with 'global' scope (L bit reset 266 to 0). 268 Figure 2: BGP Link-State Node Administrative Tag TLV 270 This new type of 'Node Admin Tag' TLVs can ONLY be added to the Node 271 Attribute associated with the Node NLRI that originates the 272 corresponding node administrative tags in IGP domain. 274 All the node administrative tags with 'per-area' (or per-level) 275 scope, originated by a single node in IGP domain SHALL be re- 276 originated in a single 'Node Admin Tag' TLV and inserted in the Node 277 NLRI generated for the same node. Similarly, all the node 278 administrative tags with 'global' scope originated by the same node 279 in IGP domain SHALL be re-originated in another 'Node Admin Tag' TLV 280 and inserted in the same Node NLRI generated for the originating 281 node. Multiple instances of a TLV may be generated by the BGP-lS 282 router for a given node in the IGP domain. This MAY happen if the 283 original node's link state advertisement carries more than 16383 node 284 administrative groups and a single TLV does not provide sufficient 285 space. As such multiple occurence of the 'Node Admin Tag' TLVs under 286 a single BGP LS NLRI is cumulative. 288 While copying node administrative tags from IGP link-state 289 advertisements to corresponding BGP-LS advertisements, the said BGP- 290 LS speaker MAY run all the node administrative flags through a 291 locally configured policy that selects which ones should be exported 292 and which ones not. And then the node administrative tag is copied 293 to the BGP-LS advertisement if it is permitted to do so by the said 294 policy. 296 4. Elements of Procedure 298 Meaning of the Node administrative tags is generally opaque to BGP 299 Link-State protocol. Router advertising the node administrative tag 300 (or tags) may be configured to do so without knowing (or even 301 explicitly supporting) functionality implied by the tag. 303 Interpretation of tag values is specific to the administrative domain 304 of a particular network operator. The meaning of a node 305 administrative tag is defined by the network local policy and is 306 controlled via the configuration. However multiple administrative 307 domain owners may agree on a common meaning implied by a 308 administrative tag for mutual benefit. 310 The semantics of the tag order has no meaning. There is no implied 311 meaning to the ordering of the tags that indicates a certain 312 operation or set of operations that need to be performed based on the 313 ordering. 315 Each tag SHOULD be treated as an independent identifier that MAY be 316 used in policy to perform a policy action. Node administrative tags 317 carried by the Node Admin Tag TLV SHOULD be used to indicate a 318 independent characteristics of the node in IGP domain that originated 319 it. The TLV SHOULD be considered as an unordered list. Whilst 320 policies may be implemented based on the presence of multiple tags 321 (e.g., if tag A AND tag B are present), they MUST NOT be reliant upon 322 the order of the tags (i.e., all policies should be considered 323 commutative operations, such that tag A preceding or following tag B 324 does not change their outcome). 326 For more details on guidance on usage of node administrative tags 327 please refer to section 4 [3] in [I-D.ietf-isis-node-admin-tag]. 329 5. Applications 331 [I-D.ietf-isis-node-admin-tag] and [I-D.ietf-ospf-node-admin-tag] 332 present some applications of node administrative tags. 334 The policy-based Explicit routing use case can be extended to inter- 335 area or inter-AS scenarios where an end to end path needs to avoid or 336 include nodes that have particular properties. Following are some 337 examples. 339 1. Geopolitical routing : preventing traffic from country A to 340 country B to cross country C. In this case, we may use node 341 administrative tags to encode geographical information (country). 342 Path computation will be required to take into account node 343 administrative tag to permit avoidance of nodes belonging to 344 country C. 346 2. Legacy node avoidance : in some specific cases, it is interesting 347 for service-provider to force some traffic to avoid legacy nodes 348 in the network. For example, legacy nodes may not be carrier 349 class (no high availability), and service provider wants to 350 ensure that critical traffic only uses nodes that are providing 351 high availability. 353 In case of inter-AS Traffic-Engineering applications, different ASes 354 SHOULD share their administrative tag policies. They MAY also need 355 to agree upon some common tagging policy for specific applications. 357 For more details on some possible applications with node 358 administrative tags please refer to section 5 [4] in 359 [I-D.ietf-isis-node-admin-tag]. 361 6. IANA Considerations 363 This document requests assigning code-points from the registry for 364 BGP-LS attribute TLVs based on table Table 2. 366 7. Manageability Considerations 368 This section is structured as recommended in [RFC5706]. 370 7.1. Operational Considerations 372 7.1.1. Operations 374 Existing BGP and BGP-LS operational procedures apply. No new 375 operation procedures are defined in this document. 377 8. TLV/Sub-TLV Code Points Summary 379 This section contains the global table of all TLVs/Sub-TLVs defined 380 in this document. 382 +----------------+----------------+----------+ 383 | TLV Code Point | Description | Length | 384 +----------------+----------------+----------+ 385 | 1040 | Node Admin Tag | variable | 386 +----------------+----------------+----------+ 388 Table 2: Summary Table of TLV/Sub-TLV Codepoints 390 9. Security Considerations 392 Procedures and protocol extensions defined in this document do not 393 affect the BGP security model. See the 'Security Considerations' 394 section of [RFC4271] for a discussion of BGP security. Also refer to 395 [RFC4272] and [RFC6952] for analysis of security issues for BGP. 397 10. Acknowledgements 399 TBD. 401 11. References 403 11.1. Normative References 405 [I-D.ietf-idr-ls-distribution] 406 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 407 Ray, "North-Bound Distribution of Link-State and TE 408 Information using BGP", draft-ietf-idr-ls-distribution-13 409 (work in progress), October 2015. 411 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 412 Requirement Levels", BCP 14, RFC 2119, 413 DOI 10.17487/RFC2119, March 1997, 414 . 416 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 417 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 418 DOI 10.17487/RFC4271, January 2006, 419 . 421 11.2. Informative References 423 [I-D.ietf-isis-node-admin-tag] 424 Sarkar, P., Gredler, H., Hegde, S., Litkowski, S., 425 Decraene, B., Li, Z., Aries, E., Rodriguez, R., and H. 426 Raghuveer, "Advertising Per-node Admin Tags in IS-IS", 427 draft-ietf-isis-node-admin-tag-00 (work in progress), 428 December 2014. 430 [I-D.ietf-ospf-node-admin-tag] 431 Hegde, S., Raghuveer, H., Gredler, H., Shakir, R., 432 Smirnov, A., Li, Z., and B. Decraene, "Advertising per- 433 node administrative tags in OSPF", draft-ietf-ospf-node- 434 admin-tag-00 (work in progress), October 2014. 436 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 437 RFC 4272, DOI 10.17487/RFC4272, January 2006, 438 . 440 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 441 Management of New Protocols and Protocol Extensions", 442 RFC 5706, DOI 10.17487/RFC5706, November 2009, 443 . 445 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 446 BGP, LDP, PCEP, and MSDP Issues According to the Keying 447 and Authentication for Routing Protocols (KARP) Design 448 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 449 . 451 11.3. URIs 453 [1] http://tools.ietf.org/html/draft-ietf-isis-node-admin-tag- 454 00#section-3.1 456 [2] http://tools.ietf.org/html/draft-ietf-ospf-node-admin-tag- 457 00#section-4.1 459 [3] http://tools.ietf.org/html/draft-ietf-isis-node-admin-tag- 460 00#section-4 462 [4] http://tools.ietf.org/html/draft-ietf-isis-node-admin-tag- 463 00#section-5 465 Authors' Addresses 467 Pushpasis Sarkar (editor) 468 Individual Contributor 470 Email: pushpasis.ietf@gmail.com 472 Hannes Gredler 473 Individual Contributor 475 Email: hannes@gredler.at 477 Stephane Litkowski 478 Orange 480 Email: stephane.litkowski@orange.com