idnits 2.17.1 draft-ietf-idr-bgp-ls-flex-algo-00.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 30, 2019) is 1794 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 (-26) exists of draft-ietf-lsr-flex-algo-02 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-ext-15 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-03 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing K. Talaulikar 3 Internet-Draft P. Psenak 4 Intended status: Standards Track Cisco Systems 5 Expires: December 1, 2019 S. Zandi 6 G. Dawra 7 LinkedIn 8 May 30, 2019 10 Flexible Algorithm Definition Advertisement with BGP Link-State 11 draft-ietf-idr-bgp-ls-flex-algo-00 13 Abstract 15 Flexible Algorithm is a solution that allows routing protocols (viz. 16 OSPF and IS-IS) to compute paths over a network based on user-defined 17 (and hence, flexible) constraints and metrics. The computation is 18 performed by routers participating in the specific network in a 19 distribute manner using a Flex Algorithm definition. This definition 20 provisioned on one or more routers and propagated (viz. OSPF and IS- 21 IS flooding) through the network. 23 BGP Link-State (BGP-LS) enables the collection of various topology 24 information from the network. This draft defines extensions to BGP- 25 LS address-family to advertise the Flexible Algorithm Definition as a 26 part of the topology information from the network. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 32 "OPTIONAL" in this document are to be interpreted as described in BCP 33 14 [RFC2119] [RFC8174] when, and only when, they appear in all 34 capitals, as shown here. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on December 1, 2019. 53 Copyright Notice 55 Copyright (c) 2019 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. BGP-LS Extensions for Flex Algo Definition . . . . . . . . . 4 72 2.1. Flex Algo Exclude Any Affinity . . . . . . . . . . . . . 5 73 2.2. Flex Algo Include Any Affinity . . . . . . . . . . . . . 6 74 2.3. Flex Algo Include All Affinity . . . . . . . . . . . . . 7 75 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 76 4. Manageability Considerations . . . . . . . . . . . . . . . . 8 77 4.1. Operational Considerations . . . . . . . . . . . . . . . 8 78 4.2. Management Considerations . . . . . . . . . . . . . . . . 8 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 80 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 82 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 83 7.2. Informative References . . . . . . . . . . . . . . . . . 9 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 86 1. Introduction 88 IGP protocols (OSPF and IS-IS) traditionally compute best paths over 89 the network based on the IGP metric assigned to the links. Many 90 network deployments use RSVP-TE [RFC3209] based or Segment Routing 91 (SR) Policy [I-D.ietf-spring-segment-routing-policy] based solutions 92 to enforce traffic over a path that is computed using different 93 metrics or constraints than the shortest IGP path. 94 [I-D.ietf-lsr-flex-algo] defines the Flexible Algorithm solution that 95 allows IGPs themselves to compute constraint based paths over the 96 network. 98 Flexible Algorithm is called so as it allows a user the flexibility 99 to define 101 o the type of calculation to be used (e.g. shortest path) 103 o the metric type to be used (e.g. IGP metric or TE metric) 105 o the set of constraints to be used (e.g. inclusion or exclusion of 106 certain links using affinities) 108 The operations of the flexible algorithm solution is described in 109 detail in [I-D.ietf-lsr-flex-algo] and a high level summary of the 110 same is described here for clarity. The network operator enables the 111 participation of specific nodes in the network for a specific 112 algorithm and then provisions the definition of that flexible 113 algorithm on one or more of these nodes. The nodes where the 114 flexible algorithm definition is advertised then flood these 115 definitions via respective IGP (IS-IS and OSPFv2/v3) mechanisms to 116 all other nodes in the network. The nodes select the definition for 117 each algorithm based on the flooded information in a deterministic 118 manner and thus all nodes participating in a flexible algorithm 119 computation arrive at a common understanding of the type of 120 calculation that they need to use. 122 When using Segment Routing (SR) [RFC8402] forwarding plane, the 123 result of a flex algorithm computation is the provisioning of the 124 Prefix SIDs associated with that algorithm with paths based on the 125 topology computed based on that algorithm. This flex algorithm 126 computation is within an IGP area or level similar to the default 127 shortest path tree (SPT) algorithm. 129 The BGP-LS extensions for SR are defined in 130 [I-D.ietf-idr-bgp-ls-segment-routing-ext] and includes the 132 o SR Algorithm TLV to indicate the participation of a node in a flex 133 algorithm computation 135 o Prefix SID TLV to indicate the association of the Prefix-SIDs to a 136 specific flex algorithm 138 Thus a controller or a Path Computation Engine (PCE) is aware of the 139 IGP topology across multiple domains which includes the above 140 information related to the flexible algorithm. This draft defines 141 extensions to BGP-LS for carrying the Flexible Algorithm Definition 142 information so that it enables the controller/PCE to learn the 143 mapping of the flex algorithm number to its definition in each area/ 144 domain of the underlying IGP. The controller/PCE also learns the 145 type of computation used and the constraints for the same. This 146 information can then be leveraged by it for setting up SR Policy 147 paths end to end across domains by leveraging the appropriate Flex 148 Algorithm specific Prefix SIDs in its Segment List 149 [I-D.ietf-spring-segment-routing-policy]. e.g. picking the Flex 150 Algorithm Prefix SID or ABRs/ASBRs corresponding to a definition that 151 optimizes on the delay metric enables the PCE/controller to build an 152 end to end low latency path across IGP domains with minimal Prefix- 153 SIDs in the SID list. 155 2. BGP-LS Extensions for Flex Algo Definition 157 The BGP-LS [RFC7752] specifies the Node NLRI for advertisement of 158 nodes and their attributes using the BGP-LS Attribute. The Flexible 159 Algorithm Definition (FAD) advertised by a node are considered as its 160 node level attributes and advertised as such. 162 This document defines a new BGP-LS Attribute TLV called the Flexible 163 Algorithm Definition (FAD) TLV and its format is as follows: 165 0 1 2 3 166 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 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Type | Length | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 |Flex-Algorithm | Metric-Type | Calc-Type | Priority | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | sub-TLVs ... // 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 Figure 1: Flex Algorithm Definition TLV 177 where: 179 o Type: TBD (see IANA Considerations Section 3) 181 o Length: variable. Minimum of 8 octets. 183 o Flex-Algorithm : 1 octet value in the range between 128 and 255 184 inclusive which is the range defined for Flexible Algorithms in 185 the IANA "IGP Parameters" registries under the "IGP Algorithm 186 Types" registry [I-D.ietf-lsr-flex-algo]. 188 o Metric-Type : 1 octet value indicating the type of the metric used 189 in the computation. Values allowed come from the IANA "IGP 190 Parameters" registries under the "Flexible Algorithm Definition 191 Metric-Type" registry [I-D.ietf-lsr-flex-algo]. 193 o Calculation-Type : 1 octet value in the range between 0 and 127 194 inclusive which is the range defined for the standard algorithms 195 in the IANA "IGP Parameters" registries under the "IGP Algorithm 196 Types" registry [I-D.ietf-lsr-flex-algo]. 198 o Priority : 1 octet value between 0 and 255 inclusive that 199 specifies the priority of the FAD. 201 o sub-TLVs : zero or more sub-TLVs may be included as described 202 further in this section. 204 The FAD TLV can only be added to the BGP-LS Attribute of the Node 205 NLRI if the corresponding node originates the underlying IGP TLV/sub- 206 TLV as described below. This information is derived from the 207 protocol specific advertisements as below.. 209 o IS-IS, as defined by the ISIS Flexible Algorithm Definition sub- 210 TLV in [I-D.ietf-lsr-flex-algo]. 212 o OSPFv2/OSPFv3, as defined by the OSPF Flexible Algorithm 213 Definition TLV in [I-D.ietf-lsr-flex-algo]. 215 The following sub-sections define the sub-TLVs for the FAD TLV. 217 2.1. Flex Algo Exclude Any Affinity 219 The Flex Algo Exclude Any Affinity sub-TLV is an optional sub-TLV 220 that is used to carry the affinity constraints [RFC2702] associated 221 with the flex algo definition and enable the exclusion of links 222 carrying any of the specified affinities from the computation of the 223 specific algorithm as described in [I-D.ietf-lsr-flex-algo]. The 224 affinity is expressed in terms of Extended Admin Group (EAG) as 225 defined in [RFC7308]. 227 The TLV has the following format: 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Type | Length | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Exclude-Any EAG (variable) // 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 where: 239 o Type: TBD (see IANA Considerations Section 3) 241 o Length: variable, dependent on the size of the Extended Admin 242 Group. MUST be a multiple of 4 octets. 244 o Exclude-Any EAG : the bitmask used to represent the affinities to 245 be excluded. 247 The information in the Flex Algo Exclude Any Affinity sub-TLV is 248 derived from the IS-IS and OSPF protocol specific Flexible Algorithm 249 Exclude Admin Group sub-TLV as defined in [I-D.ietf-lsr-flex-algo]. 251 2.2. Flex Algo Include Any Affinity 253 The Flex Algo Incude Any Affinity sub-TLV is an optional sub-TLV that 254 is used to carry the affinity constraints [RFC2702] associated with 255 the flex algo definition and enable the inclusion of links carrying 256 any of the specified affinities in the computation of the specific 257 algorithm as described in [I-D.ietf-lsr-flex-algo]. The affinity is 258 expressed in terms of Extended Admin Group (EAG) as defined in 259 [RFC7308]. 261 The TLV has the following format: 263 0 1 2 3 264 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 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Type | Length | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Include-Any EAG (variable) // 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 where: 273 o Type: TBD (see IANA Considerations Section 3) 275 o Length: variable, dependent on the size of the Extended Admin 276 Group. MUST be a multiple of 4 octets. 278 o Include-Any EAG : the bitmask used to represent the affinities to 279 be included. 281 The information in the Flex Algo Include Any Affinity sub-TLV is 282 derived from the IS-IS and OSPF protocol specific Flexible Algorithm 283 Include-Any Admin Group sub-TLV as defined in 284 [I-D.ietf-lsr-flex-algo]. 286 2.3. Flex Algo Include All Affinity 288 The Flex Algo Incude All Affinity sub-TLV is an optional sub-TLV that 289 is used to carry the affinity constraints [RFC2702] associated with 290 the flex algo definition and enable the inclusion of links carrying 291 all of the specified affinities in the computation of the specific 292 algorithm as described in [I-D.ietf-lsr-flex-algo]. The affinity is 293 expressed in terms of Extended Admin Group (EAG) as defined in 294 [RFC7308]. 296 The TLV has the following format: 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Type | Length | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Include-All EAG (variable) // 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 where: 308 o Type: TBD (see IANA Considerations Section 3) 310 o Length: variable, dependent on the size of the Extended Admin 311 Group. MUST be a multiple of 4 octets. 313 o Include-All EAG : the bitmask used to represent the affinities to 314 be included. 316 The information in the Flex Algo Include All Affinity sub-TLV is 317 derived from the IS-IS and OSPF protocol specific Flexible Algorithm 318 Include-All Admin Group sub-TLV as defined in 319 [I-D.ietf-lsr-flex-algo]. 321 3. IANA Considerations 323 This document requests assigning code-points from the registry "BGP- 324 LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute 325 TLVs" based on table below. The column "IS-IS TLV/Sub-TLV" defined 326 in the registry does not require any value and should be left empty. 328 +------------+----------------------------------------+----------+ 329 | Code Point | Description | Length | 330 +------------+----------------------------------------+----------+ 331 | TBD | Flex Algorithm Definition TLV | variable | 332 | TBD | Flex Algo Exclude Any Affinity sub-TLV | variable | 333 | TBD | Flex Algo Include Any Affinity sub-TLV | variable | 334 | TBD | Flex Algo Include All Affinity sub-TLV | variable | 335 +------------+----------------------------------------+----------+ 337 4. Manageability Considerations 339 This section is structured as recommended in [RFC5706]. 341 The new protocol extensions introduced in this document augment the 342 existing IGP topology information that was distributed via [RFC7752]. 343 Procedures and protocol extensions defined in this document do not 344 affect the BGP protocol operations and management other than as 345 discussed in the Manageability Considerations section of [RFC7752]. 346 Specifically, the malformed NLRIs attribute tests in the Fault 347 Management section of [RFC7752] now encompass the new TLVs for the 348 BGP-LS NLRI in this document. 350 4.1. Operational Considerations 352 No additional operation considerations are defined in this document. 354 4.2. Management Considerations 356 No additional management considerations are defined in this document. 358 5. Security Considerations 360 The new protocol extensions introduced in this document augment the 361 existing IGP topology information that was distributed via [RFC7752]. 362 Procedures and protocol extensions defined in this document do not 363 affect the BGP security model other than as discussed in the Security 364 Considerations section of [RFC7752]. 366 6. Acknowledgements 368 The authors would like to thank Les Ginsberg for his reviews and 369 contributions to this work. 371 7. References 373 7.1. Normative References 375 [I-D.ietf-lsr-flex-algo] 376 Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and 377 A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- 378 algo-02 (work in progress), May 2019. 380 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 381 Requirement Levels", BCP 14, RFC 2119, 382 DOI 10.17487/RFC2119, March 1997, 383 . 385 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 386 S. Ray, "North-Bound Distribution of Link-State and 387 Traffic Engineering (TE) Information Using BGP", RFC 7752, 388 DOI 10.17487/RFC7752, March 2016, 389 . 391 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 392 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 393 May 2017, . 395 7.2. Informative References 397 [I-D.ietf-idr-bgp-ls-segment-routing-ext] 398 Previdi, S., Talaulikar, K., Filsfils, C., Gredler, H., 399 and M. Chen, "BGP Link-State extensions for Segment 400 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-15 401 (work in progress), May 2019. 403 [I-D.ietf-spring-segment-routing-policy] 404 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 405 bogdanov@google.com, b., and P. Mattes, "Segment Routing 406 Policy Architecture", draft-ietf-spring-segment-routing- 407 policy-03 (work in progress), May 2019. 409 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 410 McManus, "Requirements for Traffic Engineering Over MPLS", 411 RFC 2702, DOI 10.17487/RFC2702, September 1999, 412 . 414 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 415 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 416 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 417 . 419 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 420 Management of New Protocols and Protocol Extensions", 421 RFC 5706, DOI 10.17487/RFC5706, November 2009, 422 . 424 [RFC7308] Osborne, E., "Extended Administrative Groups in MPLS 425 Traffic Engineering (MPLS-TE)", RFC 7308, 426 DOI 10.17487/RFC7308, July 2014, 427 . 429 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 430 Decraene, B., Litkowski, S., and R. Shakir, "Segment 431 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 432 July 2018, . 434 Authors' Addresses 436 Ketan Talaulikar 437 Cisco Systems 438 India 440 Email: ketant@cisco.com 442 Peter Psenak 443 Cisco Systems 444 Slovakia 446 Email: ppsenak@cisco.com 448 Shawn Zandi 449 LinkedIn 450 USA 452 Email: szandi@linkedin.com 454 Gaurav Dawra 455 LinkedIn 456 USA 458 Email: gdawra.ietf@gmail.com