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