idnits 2.17.1 draft-gredler-idr-bgp-ls-segment-routing-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 14, 2014) is 3724 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) == 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 (==), 1 comment (--). 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: August 18, 2014 S. Previdi 6 C. Filsfils 7 Cisco Systems, Inc. 8 M. Chen 9 Huawei Technologies 10 J. Tantsura 11 Ericsson 12 February 14, 2014 14 BGP Link-State extensions for Segment Routing 15 draft-gredler-idr-bgp-ls-segment-routing-extension-01 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 August 18, 2014. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. BGP-LS Extensions for Segment Routing . . . . . . . . . . . . 6 75 2.1. Node Attribute TLVs . . . . . . . . . . . . . . . . . . . 7 76 2.2. Link Attribute TLVs . . . . . . . . . . . . . . . . . . . 7 77 2.3. Prefix Attribute TLVs . . . . . . . . . . . . . . . . . . 8 78 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 79 4. Manageability Considerations . . . . . . . . . . . . . . . . . 8 80 4.1. Operational Considerations . . . . . . . . . . . . . . . . 8 81 4.1.1. Operations . . . . . . . . . . . . . . . . . . . . . . 8 82 5. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 8 83 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 84 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 86 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 87 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 90 1. Introduction 92 Segment Routing (SR) allows for a flexible definition of end-to-end 93 paths within link-state topologies by encoding paths as sequences of 94 topological sub-paths, called "segments". Segment routing is an 95 amalgamation of source routing and MPLS. In Segment Routing, the 96 ingress node prepends a sequence of instructions, called "segments", 97 to the packet. The SR capable nodes sequentially execute the 98 instructions on the packet to achieve packet forwarding via required 99 topological paths as well as service paths. 101 The segments can be thought of, in a simple way, to represent 102 instructions such as "go to node N using the shortest path", "follow 103 the shortest path for prefix P", "use link/node/ERO L", etc. Each 104 segment is identified by a 32 bit Segment Identifier (SID) (when 105 unmodified MPLS data-plane is used, the SIDs are restricted to 20 106 bits). There are "global" segments that are known to all SR nodes in 107 the local domain, and there are local segments whose semantics are 108 known only to the nodes that originate them. The segment routing 109 architecture is described in [I-D.filsfils-rtgwg-segment-routing] and 110 segment routing use-cases in 111 [I-D.filsfils-rtgwg-segment-routing-use-cases]. 113 Segment routing is enabled in a network by advertising the segments 114 (including the associated SIDs) to the nodes in the network. The IGP 115 link-state routing protocols (IS-IS 116 [I-D.previdi-isis-segment-routing-extensions], OSPFv2 117 [I-D.psenak-ospf-segment-routing-extensions] and OSPFv3 118 [I-D.psenak-ospf-segment-routing-ospfv3-extension]) have been 119 extended to advertise the segments. Using these extensions, segment 120 routing can be enabled within an IGP domain. 122 +------------+ 123 | Consumer | 124 +------------+ 125 ^ 126 | 127 v 128 +-------------------+ 129 | BGP Speaker | +-----------+ 130 | (Route-Reflector) | | Consumer | 131 +-------------------+ +-----------+ 132 ^ ^ ^ ^ 133 | | | | 134 +---------------+ | +-------------------+ | 135 | | | | 136 v v v v 137 +-----------+ +-----------+ +-----------+ 138 | BGP | | BGP | | BGP | 139 | Speaker | | Speaker | . . . | Speaker | 140 +-----------+ +-----------+ +-----------+ 141 ^ ^ ^ 142 | | | 143 IGP IGP IGP 145 Figure 1: Link State info collection 147 Segment Routing (SR) allows advertisement of single or multi-hop 148 paths. The flooding scope for the IGP extensions for Segment routing 149 is IGP area-wide. Consequently, the contents of a Link State 150 Database (LSDB) or a Traffic Engineering Database (TED) has the scope 151 of an IGP area and therefore by using the IGP alone it is not 152 possible to construct segments across an IGP Area or AS boundaries. 154 To address the need for applications that require visibility into 155 LSDB across IGP areas, or even across ASes, the BGP-LS address- 156 family/sub-address-family have been defined that allows BGP to carry 157 LSDB information. The BGP Network Layer Reachability Information 158 (NLRI) encoding format for BGP-LS and a new BGP Path Attribute called 159 BGP-LS attribute are defined in [I-D.ietf-idr-ls-distribution]. The 160 identifying key of each LSDB object, namely a node, a link or a 161 prefix, is encoded in the NLRI and the properties of the object are 162 encoded in the BGP-LS attribute. Figure Figure 1 describes a typical 163 deployment scenario. In each IGP area, one or more nodes are 164 configured with BGP-LS. These BGP speakers form an IBGP mesh by 165 connecting to one or more route-reflectors. This way, all BGP 166 speakers - specifically the route-reflectors - obtain LSDB 167 information from all IGP areas (and from other ASes from EBGP peers). 168 An external component connects to the route-reflector to obtain this 169 information (perhaps moderated by a policy regarding what information 170 is sent to the external component, and what information isn't). 172 This document describes extensions to BGP-LS to carry the segments. 173 An external component - a Controller - then can collect segment 174 information in the "northbound direction" across IGP areas/autonomous 175 systems and construct the segment stack that need to be added to an 176 incoming packet to achieve the desired end-to-end forwarding. 178 2. BGP-LS Extensions for Segment Routing 180 The BGP-LS NLRI can be a node NLRI, a link NLRI or a prefix NLRI. 181 The corresponding BGP-LS attribute is a node attribute, a link 182 attribute or a prefix attribute. BGP-LS 183 [I-D.ietf-idr-ls-distribution] defines the TLVs that map link-state 184 information to BGP-LS NLRI and BGP-LS attribute. This document adds 185 additional BGP-LS attribute TLVs to encode SR information. 187 [I-D.previdi-isis-segment-routing-extensions] defines the following 188 TLVs to encode SR information. 190 o TLV for Prefix-SID 192 o TLV for Adjacency-SID between two nodes as well as between nodes 193 in a LAN 195 o TLV for SID/Label binding for advertising paths from other 196 protocols (and their optional ERO) 198 o TLV for SR Capabilities 200 o TLV for SR Algorithm 202 These TLVs are mapped to BGP-LS attribute TLVs in the following way. 204 0 1 2 3 205 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 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Type | Length | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 // Value (variable) // 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 Figure 2: TLV format 214 The 2 octet Type field values are defined in Table 1, Table 2, and 215 Table 3. The next 2 octet Length field encodes length of the rest of 216 the TLV. The Value portion of the TLV is variable and is equal to 217 the corresponding Value portion of the TLV defined in 218 [I-D.previdi-isis-segment-routing-extensions]. 220 In each case, multiple TLVs for a given type are allowed to be added. 221 The semantics of multiple such values are determined by 222 [I-D.previdi-isis-segment-routing-extensions]. 224 2.1. Node Attribute TLVs 226 The following 'Node Attribute' TLVs are defined: 228 +---------------+-------------------+----------+--------------------+ 229 | TLV Code | Description | Length | IS-IS SR | 230 | Point | | | TLV/sub-TLV | 231 +---------------+-------------------+----------+--------------------+ 232 | 1033 | SID/Label Binding | variable | 149 | 233 | 1034 | SR Capabilities | variable | 2 | 234 | 1035 | SR Algorithm | variable | 15 | 235 +---------------+-------------------+----------+--------------------+ 237 Table 1: Node Attribute TLVs 239 The sections refer to [I-D.previdi-isis-segment-routing-extensions]. 241 These TLVs can ONLY be added to the Node Attribute associated with 242 the Node NLRI that originates the corresponding SR TLV. 244 2.2. Link Attribute TLVs 246 The following 'Link Attribute' TLVs are are defined: 248 +-----------+----------------------------+----------+---------------+ 249 | TLV Code | Description | Length | IS-IS SR | 250 | Point | | | TLV/sub-TLV | 251 +-----------+----------------------------+----------+---------------+ 252 | 1099 | Adjacency Segment | variable | 31 | 253 | | Identifier (Adj-SID) TLV | | | 254 | 1100 | LAN Adjacency Segment | variable | 32 | 255 | | Identifier (Adj-SID) TLV | | | 256 +-----------+----------------------------+----------+---------------+ 258 Table 2: Link Attribute TLVs 260 The sections refer to [I-D.previdi-isis-segment-routing-extensions]. 262 These TLVs can ONLY be added to the Link Attribute associated with 263 the link whose local node originates the corresponding SR TLV. 265 For a LAN, normally a node only announces its adjacency to the 266 pseudo-node. [I-D.previdi-isis-segment-routing-extensions] allows a 267 node to announce adjacency to all other nodes attached to the LAN. 268 In such a case, the corresponding BGP-LS link NLRI must be originated 269 for each additional link in order to add the SR TLVs to the Link 270 Attribute. 272 2.3. Prefix Attribute TLVs 274 The following 'Prefix Attribute' TLVs are defined: 276 +----------------+-------------+----------+----------------------+ 277 | TLV Code Point | Description | Length | IS-IS SR TLV/sub-TLV | 278 +----------------+-------------+----------+----------------------+ 279 | 1158 | Prefix SID | variable | 3 | 280 +----------------+-------------+----------+----------------------+ 282 Table 3: Prefix Attribute TLVs 284 The sections refer to [I-D.previdi-isis-segment-routing-extensions]. 286 These TLVs can ONLY be added to the Prefix Attribute whose local node 287 in the corresponding prefix NLRI is the node that originates the 288 corresponding SR TLV. 290 3. IANA Considerations 292 This document requests assigning code-points from the registry for 293 BGP-LS attribute TLVs based on table Table 4. 295 4. Manageability Considerations 297 This section is structured as recommended in [RFC5706]. 299 4.1. Operational Considerations 301 4.1.1. Operations 303 Existing BGP and BGP-LS operational procedures apply. No new 304 operation procedures are defined in this document. 306 5. TLV/Sub-TLV Code Points Summary 308 This section contains the global table of all TLVs/Sub-TLVs defined 309 in this document. 311 +-----------+----------------------------+----------+---------------+ 312 | TLV Code | Description | Length | IS-IS SR | 313 | Point | | | TLV/sub-TLV | 314 +-----------+----------------------------+----------+---------------+ 315 | 1033 | SID/Label Binding | variable | 149 | 316 | 1034 | SR Capabilities | variable | 2 | 317 | 1035 | SR Algorithm | variable | 15 | 318 | 1099 | Adjacency Segment | variable | 31 | 319 | | Identifier (Adj-SID) TLV | | | 320 | 1100 | LAN Adjacency Segment | variable | 32 | 321 | | Identifier (Adj-SID) TLV | | | 322 | 1158 | Prefix SID | variable | 3 | 323 +-----------+----------------------------+----------+---------------+ 325 Table 4: Summary Table of TLV/Sub-TLV Codepoints 327 6. Security Considerations 329 Procedures and protocol extensions defined in this document do not 330 affect the BGP security model. See the 'Security Considerations' 331 section of [RFC4271] for a discussion of BGP security. Also refer to 332 [RFC4272] and [RFC6952] for analysis of security issues for BGP. 334 7. Acknowledgements 336 TBD. 338 8. References 340 8.1. Normative References 342 [I-D.ietf-idr-ls-distribution] 343 Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. 344 Ray, "North-Bound Distribution of Link-State and TE 345 Information using BGP", draft-ietf-idr-ls-distribution-04 346 (work in progress), November 2013. 348 [I-D.previdi-isis-segment-routing-extensions] 349 Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., and 350 S. Litkowski, "IS-IS Extensions for Segment Routing", 351 draft-previdi-isis-segment-routing-extensions-04 (work in 352 progress), October 2013. 354 [I-D.psenak-ospf-segment-routing-extensions] 355 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 356 Shakir, R., and W. Henderickx, "OSPF Extensions for 357 Segment Routing", 358 draft-psenak-ospf-segment-routing-extensions-03 (work in 359 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", 365 draft-psenak-ospf-segment-routing-ospfv3-extension-00 366 (work in progress), October 2013. 368 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 369 Requirement Levels", BCP 14, RFC 2119, March 1997. 371 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 372 Protocol 4 (BGP-4)", RFC 4271, January 2006. 374 8.2. Informative References 376 [I-D.filsfils-rtgwg-segment-routing] 377 Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., 378 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 379 Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, 380 "Segment Routing Architecture", 381 draft-filsfils-rtgwg-segment-routing-01 (work in 382 progress), October 2013. 384 [I-D.filsfils-rtgwg-segment-routing-use-cases] 385 Filsfils, C., Francois, P., Previdi, S., Decraene, B., 386 Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., 387 Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. 388 Crabbe, "Segment Routing Use Cases", 389 draft-filsfils-rtgwg-segment-routing-use-cases-02 (work in 390 progress), October 2013. 392 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 393 RFC 4272, January 2006. 395 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 396 Management of New Protocols and Protocol Extensions", 397 RFC 5706, November 2009. 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, May 2013. 404 Authors' Addresses 406 Hannes Gredler (editor) 407 Juniper Networks, Inc. 408 1194 N. Mathilda Ave. 409 Sunnyvale, CA 94089 410 US 412 Email: hannes@juniper.net 414 Saikat Ray (editor) 415 Cisco Systems, Inc. 416 170, West Tasman Drive 417 San Jose, CA 95134 418 US 420 Email: sairay@cisco.com 422 Stefano Previdi 423 Cisco Systems, Inc. 424 Via Del Serafico, 200 425 Rome 00142 426 Italy 428 Email: sprividi@cisco.com 430 Clarence Filsfils 431 Cisco Systems, Inc. 432 Brussels 433 Belgium 435 Email: cfilsfil@cisco.com 437 Mach(Guoyi) Chen 438 Huawei Technologies 439 Huawei Building, No. 156 Beiqing Rd. 440 Beijing 100095 441 China 443 Email: mach.chen@huawei.com 444 Jeff Tantsura 445 Ericsson 446 300 Holger Way 447 San Jose, CA 95134 448 US 450 Email: jeff.tantsura@ericsson.com