idnits 2.17.1 draft-gredler-idr-bgp-ls-segment-routing-extension-02.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 16, 2014) is 3451 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 404 -- Looks like a reference, but probably isn't: '2' on line 407 -- Looks like a reference, but probably isn't: '3' on line 410 -- Looks like a reference, but probably isn't: '4' on line 413 -- Looks like a reference, but probably isn't: '5' on line 416 -- Looks like a reference, but probably isn't: '6' on line 419 -- Looks like a reference, but probably isn't: '7' on line 422 -- Looks like a reference, but probably isn't: '8' on line 425 -- Looks like a reference, but probably isn't: '9' on line 428 -- Looks like a reference, but probably isn't: '10' on line 431 -- Looks like a reference, but probably isn't: '11' on line 434 -- Looks like a reference, but probably isn't: '12' on line 437 == Outdated reference: A later version (-13) exists of draft-ietf-idr-ls-distribution-04 == Outdated reference: A later version (-05) exists of draft-previdi-isis-segment-routing-extensions-04 == Outdated reference: A later version (-05) exists of draft-psenak-ospf-segment-routing-extensions-03 == Outdated reference: A later version (-02) exists of draft-psenak-ospf-segment-routing-ospfv3-extension-00 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing H. Gredler, Ed. 3 Internet-Draft Juniper Networks, Inc. 4 Intended status: Standards Track S. Ray, Ed. 5 Expires: April 19, 2015 S. Previdi 6 C. Filsfils 7 Cisco Systems, Inc. 8 M. Chen 9 Huawei Technologies 10 J. Tantsura 11 Ericsson 12 October 16, 2014 14 BGP Link-State extensions for Segment Routing 15 draft-gredler-idr-bgp-ls-segment-routing-extension-02 17 Abstract 19 Segment Routing (SR) allows for a flexible definition of end-to-end 20 paths within link-state graphs by encoding paths as sequences of 21 topological sub-paths, called "segments". 23 The link-state routing protocols (IS-IS, OSPF and OSPFv3) have been 24 extended to advertise the segments. But flooding based propagation 25 of path segments using IGPs is limited by the perimeter of the IGP 26 domain. For building paths which span across IGP domains (e.g. 27 multiple ASes), the Border Gateway Protocol (BGP) is better suited as 28 its propagation perimeter is not limited like the IGPs. 30 This draft defines extensions to the BGP Link-state address-family to 31 carry path segment information via BGP. 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 37 document are to be interpreted as described in RFC 2119 [RFC2119]. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on April 19, 2015. 56 Copyright Notice 58 Copyright (c) 2014 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 74 2. BGP-LS Extensions for Segment Routing . . . . . . . . . . . . 5 75 2.1. Node Attribute TLVs . . . . . . . . . . . . . . . . . . . 6 76 2.2. Link Attribute TLVs . . . . . . . . . . . . . . . . . . . 6 77 2.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . . . 7 78 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 79 4. Manageability Considerations . . . . . . . . . . . . . . . . 7 80 4.1. Operational Considerations . . . . . . . . . . . . . . . 7 81 4.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 7 82 5. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 7 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 84 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 86 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 87 8.2. Informative References . . . . . . . . . . . . . . . . . 9 88 8.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 91 1. Introduction 93 Segment Routing (SR) allows for a flexible definition of end-to-end 94 paths within link-state topologies by encoding paths as sequences of 95 topological sub-paths, called "segments". Segment routing is an 96 amalgamation of source routing and MPLS. In Segment Routing, the 97 ingress node prepends a sequence of instructions, called "segments", 98 to the packet. The SR capable nodes sequentially execute the 99 instructions on the packet to achieve packet forwarding via required 100 topological paths as well as service paths. 102 The segments can be thought of, in a simple way, to represent 103 instructions such as "go to node N using the shortest path", "follow 104 the shortest path for prefix P", "use link/node/ERO L", etc. Each 105 segment is identified by a 32 bit Segment Identifier (SID) (when 106 unmodified MPLS data-plane is used, the SIDs are restricted to 20 107 bits). There are "global" segments that are known to all SR nodes in 108 the local domain, and there are local segments whose semantics are 109 known only to the nodes that originate them. The segment routing 110 architecture is described in [I-D.filsfils-rtgwg-segment-routing] and 111 segment routing use-cases in 112 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 114 Segment routing is enabled in a network by advertising the segments 115 (including the associated SIDs) to the nodes in the network. The IGP 116 link-state routing protocols (IS-IS 117 [I-D.previdi-isis-segment-routing-extensions], OSPFv2 118 [I-D.psenak-ospf-segment-routing-extensions] and OSPFv3 119 [I-D.psenak-ospf-segment-routing-ospfv3-extension]) have been 120 extended to advertise the segments. Using these extensions, segment 121 routing can be enabled within an IGP domain. 123 +------------+ 124 | Consumer | 125 +------------+ 126 ^ 127 | 128 v 129 +-------------------+ 130 | BGP Speaker | +-----------+ 131 | (Route-Reflector) | | Consumer | 132 +-------------------+ +-----------+ 133 ^ ^ ^ ^ 134 | | | | 135 +---------------+ | +-------------------+ | 136 | | | | 137 v v v v 138 +-----------+ +-----------+ +-----------+ 139 | BGP | | BGP | | BGP | 140 | Speaker | | Speaker | . . . | Speaker | 141 +-----------+ +-----------+ +-----------+ 142 ^ ^ ^ 143 | | | 144 IGP IGP IGP 146 Figure 1: Link State info collection 148 Segment Routing (SR) allows advertisement of single or multi-hop 149 paths. The flooding scope for the IGP extensions for Segment routing 150 is IGP area-wide. Consequently, the contents of a Link State 151 Database (LSDB) or a Traffic Engineering Database (TED) has the scope 152 of an IGP area and therefore by using the IGP alone it is not 153 possible to construct segments across an IGP Area or AS boundaries. 155 To address the need for applications that require visibility into 156 LSDB across IGP areas, or even across ASes, the BGP-LS address- 157 family/sub-address-family have been defined that allows BGP to carry 158 LSDB information. The BGP Network Layer Reachability Information 159 (NLRI) encoding format for BGP-LS and a new BGP Path Attribute called 160 BGP-LS attribute are defined in [I-D.ietf-idr-ls-distribution]. The 161 identifying key of each LSDB object, namely a node, a link or a 162 prefix, is encoded in the NLRI and the properties of the object are 163 encoded in the BGP-LS attribute. Figure Figure 1 describes a typical 164 deployment scenario. In each IGP area, one or more nodes are 165 configured with BGP-LS. These BGP speakers form an IBGP mesh by 166 connecting to one or more route-reflectors. This way, all BGP 167 speakers - specifically the route-reflectors - obtain LSDB 168 information from all IGP areas (and from other ASes from EBGP peers). 169 An external component connects to the route-reflector to obtain this 170 information (perhaps moderated by a policy regarding what information 171 is sent to the external component, and what information isn't). 173 This document describes extensions to BGP-LS to carry the segments. 174 An external component - a Controller - then can collect segment 175 information in the "northbound direction" across IGP areas/autonomous 176 systems and construct the segment stack that need to be added to an 177 incoming packet to achieve the desired end-to-end forwarding. 179 2. BGP-LS Extensions for Segment Routing 181 The BGP-LS NLRI can be a node NLRI, a link NLRI or a prefix NLRI. 182 The corresponding BGP-LS attribute is a node attribute, a link 183 attribute or a prefix attribute. BGP-LS 184 [I-D.ietf-idr-ls-distribution] defines the TLVs that map link-state 185 information to BGP-LS NLRI and BGP-LS attribute. This document adds 186 additional BGP-LS attribute TLVs to encode SR information. 188 [I-D.previdi-isis-segment-routing-extensions] defines the following 189 TLVs to encode SR information. 191 o TLV for Prefix-SID 193 o TLV for Adjacency-SID between two nodes as well as between nodes 194 in a LAN 196 o TLV for SID/Label binding for advertising paths from other 197 protocols (and their optional ERO) 199 o TLV for SR Capabilities 201 o TLV for SR Algorithm 203 These TLVs are mapped to BGP-LS attribute TLVs in the following way. 205 0 1 2 3 206 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 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Type | Length | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 // Value (variable) // 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 Figure 2: TLV format 215 The 2 octet Type field values are defined in Table 1, Table 2, and 216 Table 3. The next 2 octet Length field encodes length of the rest of 217 the TLV. The Value portion of the TLV is variable and is equal to 218 the corresponding Value portion of the TLV defined in 219 [I-D.previdi-isis-segment-routing-extensions]. 221 In each case, multiple TLVs for a given type are allowed to be added. 222 The semantics of multiple such values are determined by 223 [I-D.previdi-isis-segment-routing-extensions]. 225 2.1. Node Attribute TLVs 227 The following 'Node Attribute' TLVs are defined: 229 +---------------+-------------------+----------+--------------------+ 230 | TLV Code | Description | Length | IS-IS SR TLV/sub- | 231 | Point | | | TLV | 232 +---------------+-------------------+----------+--------------------+ 233 | 1033 | SID/Label Binding | variable | 149 [1] | 234 | 1034 | SR Capabilities | variable | 2 [2] | 235 | 1035 | SR Algorithm | variable | 15 [3] | 236 +---------------+-------------------+----------+--------------------+ 238 Table 1: Node Attribute TLVs 240 The sections refer to [I-D.previdi-isis-segment-routing-extensions]. 242 These TLVs can ONLY be added to the Node Attribute associated with 243 the Node NLRI that originates the corresponding SR TLV. 245 2.2. Link Attribute TLVs 247 The following 'Link Attribute' TLVs are are defined: 249 +-----------+----------------------------+----------+---------------+ 250 | TLV Code | Description | Length | IS-IS SR TLV | 251 | Point | | | /sub-TLV | 252 +-----------+----------------------------+----------+---------------+ 253 | 1099 | Adjacency Segment | variable | 31 [4] | 254 | | Identifier (Adj-SID) TLV | | | 255 | 1100 | LAN Adjacency Segment | variable | 32 [5] | 256 | | Identifier (Adj-SID) TLV | | | 257 +-----------+----------------------------+----------+---------------+ 259 Table 2: Link Attribute TLVs 261 The sections refer to [I-D.previdi-isis-segment-routing-extensions]. 263 These TLVs can ONLY be added to the Link Attribute associated with 264 the link whose local node originates the corresponding SR TLV. 266 For a LAN, normally a node only announces its adjacency to the 267 pseudo-node. [I-D.previdi-isis-segment-routing-extensions] allows a 268 node to announce adjacency to all other nodes attached to the LAN. 269 In such a case, the corresponding BGP-LS link NLRI must be originated 270 for each additional link in order to add the SR TLVs to the Link 271 Attribute. 273 2.3. Prefix Attribute TLVs 275 The following 'Prefix Attribute' TLVs are defined: 277 +----------------+-------------+----------+----------------------+ 278 | TLV Code Point | Description | Length | IS-IS SR TLV/sub-TLV | 279 +----------------+-------------+----------+----------------------+ 280 | 1158 | Prefix SID | variable | 3 [6] | 281 +----------------+-------------+----------+----------------------+ 283 Table 3: Prefix Attribute TLVs 285 The sections refer to [I-D.previdi-isis-segment-routing-extensions]. 287 These TLVs can ONLY be added to the Prefix Attribute whose local node 288 in the corresponding prefix NLRI is the node that originates the 289 corresponding SR TLV. 291 3. IANA Considerations 293 This document requests assigning code-points from the registry for 294 BGP-LS attribute TLVs based on table Table 4. 296 4. Manageability Considerations 298 This section is structured as recommended in [RFC5706]. 300 4.1. Operational Considerations 302 4.1.1. Operations 304 Existing BGP and BGP-LS operational procedures apply. No new 305 operation procedures are defined in this document. 307 5. TLV/Sub-TLV Code Points Summary 309 This section contains the global table of all TLVs/Sub-TLVs defined 310 in this document. 312 +-----------+----------------------------+----------+---------------+ 313 | TLV Code | Description | Length | IS-IS SR TLV | 314 | Point | | | /sub-TLV | 315 +-----------+----------------------------+----------+---------------+ 316 | 1033 | SID/Label Binding | variable | 149 [7] | 317 | 1034 | SR Capabilities | variable | 2 [8] | 318 | 1035 | SR Algorithm | variable | 15 [9] | 319 | 1099 | Adjacency Segment | variable | 31 [10] | 320 | | Identifier (Adj-SID) TLV | | | 321 | 1100 | LAN Adjacency Segment | variable | 32 [11] | 322 | | Identifier (Adj-SID) TLV | | | 323 | 1158 | Prefix SID | variable | 3 [12] | 324 +-----------+----------------------------+----------+---------------+ 326 Table 4: Summary Table of TLV/Sub-TLV Codepoints 328 6. Security Considerations 330 Procedures and protocol extensions defined in this document do not 331 affect the BGP security model. See the 'Security Considerations' 332 section of [RFC4271] for a discussion of BGP security. Also refer to 333 [RFC4272] and [RFC6952] for analysis of security issues for BGP. 335 7. Acknowledgements 337 TBD. 339 8. References 341 8.1. Normative References 343 [I-D.ietf-idr-ls-distribution] 344 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 345 Ray, "North-Bound Distribution of Link-State and TE 346 Information using BGP", draft-ietf-idr-ls-distribution-04 347 (work in progress), November 2013. 349 [I-D.previdi-isis-segment-routing-extensions] 350 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., and 351 S. Litkowski, "IS-IS Extensions for Segment Routing", 352 draft-previdi-isis-segment-routing-extensions-04 (work in 353 progress), October 2013. 355 [I-D.psenak-ospf-segment-routing-extensions] 356 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 357 Shakir, R., and W. Henderickx, "OSPF Extensions for 358 Segment Routing", draft-psenak-ospf-segment-routing- 359 extensions-03 (work in progress), October 2013. 361 [I-D.psenak-ospf-segment-routing-ospfv3-extension] 362 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 363 Shakir, R., and W. Henderickx, "OSPFv3 Extensions for 364 Segment Routing", draft-psenak-ospf-segment-routing- 365 ospfv3-extension-00 (work in progress), October 2013. 367 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 368 Requirement Levels", BCP 14, RFC 2119, March 1997. 370 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 371 Protocol 4 (BGP-4)", RFC 4271, January 2006. 373 8.2. Informative References 375 [I-D.filsfils-rtgwg-segment-routing] 376 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 377 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 378 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 379 "Segment Routing Architecture", draft-filsfils-rtgwg- 380 segment-routing-01 (work in progress), October 2013. 382 [I-D.filsfils-rtgwg-segment-routing-use-cases] 383 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 384 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 385 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 386 Crabbe, "Segment Routing Use Cases", draft-filsfils-rtgwg- 387 segment-routing-use-cases-02 (work in progress), October 388 2013. 390 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 391 4272, January 2006. 393 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 394 Management of New Protocols and Protocol Extensions", RFC 395 5706, November 2009. 397 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 398 BGP, LDP, PCEP, and MSDP Issues According to the Keying 399 and Authentication for Routing Protocols (KARP) Design 400 Guide", RFC 6952, May 2013. 402 8.3. URIs 404 [1] http://tools.ietf.org/html/draft-previdi-isis-segment-routing- 405 extensions-04#section-2.4 407 [2] http://tools.ietf.org/html/draft-previdi-isis-segment-routing- 408 extensions-04#section-3.1 410 [3] http://tools.ietf.org/html/draft-previdi-isis-segment-routing- 411 extensions-04#section-3.2 413 [4] http://tools.ietf.org/html/draft-previdi-isis-segment-routing- 414 extensions-04#section-2.3.1 416 [5] http://tools.ietf.org/html/draft-previdi-isis-segment-routing- 417 extensions-04#section-2.3.2 419 [6] http://tools.ietf.org/html/draft-previdi-isis-segment-routing- 420 extensions-04#section-2.2 422 [7] http://tools.ietf.org/html/draft-previdi-isis-segment-routing- 423 extensions-04#section-2.4 425 [8] http://tools.ietf.org/html/draft-previdi-isis-segment-routing- 426 extensions-04#section-3.1 428 [9] http://tools.ietf.org/html/draft-previdi-isis-segment-routing- 429 extensions-04#section-3.2 431 [10] http://tools.ietf.org/html/draft-previdi-isis-segment-routing- 432 extensions-04#section-2.3.1 434 [11] http://tools.ietf.org/html/draft-previdi-isis-segment-routing- 435 extensions-04#section-2.3.2 437 [12] http://tools.ietf.org/html/draft-previdi-isis-segment-routing- 438 extensions-04#section-2.2 440 Authors' Addresses 442 Hannes Gredler (editor) 443 Juniper Networks, Inc. 444 1194 N. Mathilda Ave. 445 Sunnyvale, CA 94089 446 US 448 Email: hannes@juniper.net 450 Saikat Ray (editor) 451 Cisco Systems, Inc. 452 170, West Tasman Drive 453 San Jose, CA 95134 454 US 456 Email: sairay@cisco.com 457 Stefano Previdi 458 Cisco Systems, Inc. 459 Via Del Serafico, 200 460 Rome 00142 461 Italy 463 Email: sprevidi@cisco.com 465 Clarence Filsfils 466 Cisco Systems, Inc. 467 Brussels 468 Belgium 470 Email: cfilsfil@cisco.com 472 Mach(Guoyi) Chen 473 Huawei Technologies 474 Huawei Building, No. 156 Beiqing Rd. 475 Beijing 100095 476 China 478 Email: mach.chen@huawei.com 480 Jeff Tantsura 481 Ericsson 482 300 Holger Way 483 San Jose, CA 95134 484 US 486 Email: jeff.tantsura@ericsson.com