idnits 2.17.1 draft-saad-sr-fa-link-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 (July 13, 2020) is 1382 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SPRING Working Group T. Saad 3 Internet-Draft V. Beeram 4 Intended status: Informational C. Barth 5 Expires: January 14, 2021 Juniper Networks, Inc. 6 S. Sivabalan 7 Ciena Corporation. 8 July 13, 2020 10 Segment-Routing over Forwarding Adjacency Links 11 draft-saad-sr-fa-link-02 13 Abstract 15 Label Switched Paths (LSPs) set up in Multiprotocol Label Switching 16 (MPLS) networks can be used to form Forwarding Adjacency (FA) links 17 that carry traffic in those networks. An FA link can be assigned 18 Traffic Engineering (TE) parameters that allow other LSR(s) to 19 include it in their constrained path computation. FA link(s) can be 20 also assigned Segment-Routing (SR) segments that enable the steering 21 of traffic on to the associated FA link(s). The TE and SR attributes 22 of an FA link can be advertised using known protocols that carry link 23 state information. This document elaborates on the usage of FA 24 link(s) and their attributes in SR enabled networks. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 14, 2021. 43 Copyright Notice 45 Copyright (c) 2020 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Forwarding Adjacency Links . . . . . . . . . . . . . . . . . 3 63 3.1. Creation and Management . . . . . . . . . . . . . . . . . 4 64 3.2. Link Flooding . . . . . . . . . . . . . . . . . . . . . . 4 65 3.3. Underlay LSP(s) . . . . . . . . . . . . . . . . . . . . . 5 66 3.4. State Changes . . . . . . . . . . . . . . . . . . . . . . 5 67 3.5. TE Parameters . . . . . . . . . . . . . . . . . . . . . . 5 68 3.6. Link Local and Remote Identifiers . . . . . . . . . . . . 6 69 4. Segment-Routing over FA Links . . . . . . . . . . . . . . . . 7 70 4.1. SR IGP Segments for FA . . . . . . . . . . . . . . . . . 7 71 4.1.1. Parallel Adjacencies . . . . . . . . . . . . . . . . 7 72 4.2. SR BGP Segments for FA . . . . . . . . . . . . . . . . . 7 73 4.3. Applicability to Interdomain . . . . . . . . . . . . . . 8 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 76 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 9 77 8. Normative References . . . . . . . . . . . . . . . . . . . . 9 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 To improve scalability in Multi-Protocol Label Switching (MPLS) 83 networks, it may be useful to create a hierarchy of LSPs as 84 Forwarding Adjacencies (FA). The concept of FA link(s) and FA-LSP(s) 85 was introduced in [RFC4206]. 87 In Segment-Routing (SR), this is particularly useful for two main 88 reasons. 90 First, it allows the stitching of sub-path(s) so as to realize an 91 end-to-end SR path. Each sub-path can be represented by a FA link 92 that is supported by one or more underlying LSP(s). The underlying 93 LSP(s) that support an FA link can be setup using different 94 technologies- including RSVP-TE, LDP, and SR. The sub-path(s), or FA 95 link(s) in this case, can possibly interconnect multiple 96 administrative domains, allowing each FA link within a domain to use 97 a different technology to setup the underlying LSP(s). 99 Second, it allows shortening of a large SR Segment-List by 100 compressing one or more slice(s) of the list into a corresponding FA 101 TE link that each can be represented by a single segment- see 102 Section 4. Effectively, it reduces the number of segments that an 103 ingress router has to impose to realize an end-to-end path. 105 The FA links are treated as normal link(s) in the network and hence 106 it can leverage existing link state protocol extensions to advertise 107 properties associated with the FA link. For example, Traffic- 108 Engineering (TE) link parameters and Segment-Routing (SR) segments 109 parameters can be associated with the FA link and advertised 110 throughout the network. 112 Once advertised in the network using a suitable protocols that 113 support carrying link state information, such as OSPF, ISIS or BGP 114 Link State (LS)), other LSR(s) in the network can use the FA TE 115 link(s) as well as possibly other normal TE link(s) when performing 116 path computation and/or when specifying the desired explicit path. 118 Though the concepts discussed in this document are specific to MPLS 119 technology, these are also extensible to other dataplane technologies 120 - e.g. SRv6. 122 2. Terminology 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in BCP 127 14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 3. Forwarding Adjacency Links 132 FA Link(s) can be created and supported by underlying FA LSPs. The 133 FA link is of type point-to-point. FA links may be represented as 134 either unnumbered or numbered. The nodes connected by an FA link do 135 not usually establish a routing adjacency over the FA link. When FA 136 links are numbered with IPv4 addresses, the local and remote IPv4 137 addresses can come out of a /31 that is allocated by the LSR that 138 originates the FA-LSP. For unnumbered FA link(s), other provisions 139 may exist to exchange link identifier(s) between the endpoints of the 140 FA. 142 3.1. Creation and Management 144 In general, the creation/termination of an FA link and its FA-LSP is 145 driven either via configuration on the LSR at the head-end of the 146 adjacency, or dynamically using suitable North Bound Interface (NBI) 147 protocol, e.g. Netconf, gRPC, PCEP, etc. 149 The following FA-LSP attributes may be configured, including: 150 bandwidth and resource colors, and other constraints. The path taken 151 by the FA-LSP may be either computed by the LSR at the head-end of 152 the FA-LSP, or externally by a PCE and furnished to the headend. 154 The attributes of the FA link can be inherited from the underlying 155 LSP(s) that induced its creation. In general, for dynamically 156 provisioned FAs, a policy-based mechanism may be needed to associate 157 link attributes to those of the FA-LSPs. 159 When the FA link is supported by bidirectional FA LSP(s), a pair of 160 FA link(s) are advertised from each endpoint of the FA. These are 161 usually referred to as symmetrical link(s). 163 3.2. Link Flooding 165 Multiple protocols exist that can exchange link state information in 166 the network. For example, when advertising TE link(s) and their 167 attribute(s) using OSPF and ISIS protocols, the respective extensions 168 are defined in [RFC3630] and [RFC5305]. Also, when exchanging such 169 information in BGP protocol, extensions for BGP link state are 170 defined in [RFC7752] and [RFC8571]. The same protocol encodings can 171 be used to advertise FA(s) as TE link(s). As a result, the FA TE 172 link(s) and other normal TE link(s) will appear in the TE link state 173 database of any LSR in the network, and can be used for computing 174 end-to-end TE path(s). 176 When IGP protocols are used to advertise link state information about 177 FA links, the FA link(s) can appear in both the TE topology as well 178 as the IGP topology. It is desirable, sometimes, to restrict the use 179 of the FA link(s) within the TE topology to compute traffic 180 engineered paths, and not use them during normal IGP Shortest Path 181 First (SPF) computations. This is possible using different 182 mechanisms and depending on the IGP protocol used to exchange the FA 183 link state information. 185 For example, when using ISIS to carry FA link state information, 186 [RFC5305] section 3 describes a way to restrict the link to the TE 187 topology by setting the IGP link metric to maximum (2^24 - 1). 188 Alternatively, when using OSPF, the FA link(s) can be advertised 189 using TE Opaque LSA(s) only, and hence, strictly show up in the TE 190 topology as described in [RFC3630] . 192 3.3. Underlay LSP(s) 194 The LSR that hosts an FA link can setup the underlying LSP(s) using 195 different technologies - e.g. RSVP-TE, LDP, and SR. 197 The FA link can be supported by one or more underlay LSP(s) that 198 terminate on the same remote endpoint. The underlay path(s) can be 199 setup using different signaling technologies, e.g. using RSVP-TE, 200 LDP, SR, etc. When multiple LSP(s) support the same FA link, the 201 attributes of the FA link can be derived from the aggregate 202 properties of each of the underlying LSP(s). 204 3.4. State Changes 206 The state of an FA TE link reflects the state of the underlying LSP 207 path that supports it. The TE link is assumed operational and is 208 advertised as long as the underlying LSP path is valid. When all 209 underlying LSP paths are invalidated, the FA TE link advertisement is 210 withdrawn. 212 3.5. TE Parameters 214 The TE metrics and TE attributes are used by path computation 215 algorithms to select the TE link(s) that a TE path traverses. When 216 advertising an FA link in OSPF or ISIS, or BGP-LS, the following TE 217 parameters are defined: 219 TE Path metrics: the FA link advertisement can include information 220 about TE, IGP, and other performance metrics (e.g. delay, and 221 loss). The FA link TE metrics, in this case, can be derived from 222 the underlying path(s) that support the FA link by producing the 223 path accumulative metrics. When multiple LSP(s) support the same 224 FA link, then the higher accumulative metric amongst the LSP(s) is 225 inherited by the FA link. 227 Resource Class/Color: An FA link can be assigned (e.g. via 228 configuration) a specific set of admin-groups. Alternatively, in 229 some cases, this can be derived from the underlying path affinity 230 - for example, the underlying path strictly includes a specific 231 admin-group. 233 SRLGs: An FA advertisement could contain the information about the 234 Shared Risk Link Groups (SRLG) for the path taken by the FA LSP 235 associated with that FA. This information may be used for path 236 calculation by other LSRs. The information carried is the union 237 of the SRLGs of the underlying TE links that make up the FA LSP 238 path. It is possible that the underlying path information might 239 change over time, via configuration updates or dynamic route 240 modifications, resulting in the change of the union of SRLGs for 241 the FA link. If multiple LSP(s) support the same FA link, then it 242 is expected all LSP(s) have the same SRLG union - note, that the 243 exact paths need not be the same. 245 It is worth noting, that topology changes in the network may affect 246 the FA link underlying LSP path(s), and hence, can dynamically change 247 the TE metrics and TE attributes of the FA links. 249 3.6. Link Local and Remote Identifiers 251 It is possible for the FA link to be numbered or unnumbered. 252 [RFC4206] describes a procedure for identifying a numbered FA TE link 253 using IPv4 addresses. 255 For unnumbered FA link(s), the assignment and handling of the local 256 and remote link identifiers is specified in [RFC3477]. The LSR at 257 each end of the unnumbered FA link assigns an identifier to that 258 link. This identifier is a non-zero 32-bit number that is unique 259 within the scope of the LSR that assigns it. There is no a priori 260 relationship between the identifiers assigned to a link by the LSRs 261 at each end of that link. 263 The FA link is a unidirectional and point-to-point link. Hence, the 264 combination of link local identifier and advertising node can 265 uniquely identify the link in the TED. In some cases, however, it is 266 desirable to associate the forward and reverse FA links in the TED. 267 In this case, the combination of link local and remote identifier can 268 identify the pair of forward and reverse FA link(s). The LSRs at the 269 two end points of an unnumbered link can exchange with each other the 270 identifiers they assign to the link. Exchanging the identifiers may 271 be accomplished by configuration, or by means of protocol extensions. 272 For example, when the FA link is established over RSVP-TE FA LSP(s), 273 then RSVP extensions have been introduced to exchange the FA link 274 identifier in [RFC3477]. Other protocol extensions pertaining to 275 specific link state protocols, and LSP setup technologies will be 276 discussed in a separate document. 278 If the link remote identifier is unknown, the value advertised is set 279 to 0 [RFC5307]. 281 4. Segment-Routing over FA Links 283 The Segment Routing (SR) architecture [RFC4206] describes that an IGP 284 adjacency can be formed over a FA link - in which the remote node of 285 an IGP adjacency is a non-adjacent IGP neighbor. 287 In Segment-Routing (SR), the adjacency that is established over a 288 link can be assigned an SR Segment [RFC8402]. For example, the Adj- 289 SID allows to strictly steer traffic on to the specific adjacency 290 that is associated with the Adj-SID. 292 4.1. SR IGP Segments for FA 294 Extensions have been defined to ISIS [RFC8667] and OSPF [RFC8665] in 295 order to advertise the the Adjacency-SID associated with a specific 296 IGP adjacency. The same extensions apply to adjacencies over FA 297 link. A node can bind an Adj-SID to an FA data-link. The Adj-SID 298 dictates the forwarding of packets through the specific FA link or FA 299 link(s) identified by the Adj-SID, regardless of its IGP/SPF cost. 301 When the FA link Adj-SID is supported by a single underlying LSP that 302 is associated with a binding label or SID, the same binding label can 303 be used for the FA link Adj-SID. For example, if the FA link is 304 supported by an SR Policy that is assigned a Binding SID B, the Adj- 305 SID of the FA link can be assigned the same Binding SID B. 307 When the FA link Adj-SID is supported by multiple underlying LSP(s) 308 or SR Policies - each having its own Binding label or SID, an 309 independent FA link Adj-SID is allocated and bound to the multiple 310 underlying LSP(s). 312 4.1.1. Parallel Adjacencies 314 Adj-SIDs can also be used in order to represent a set of parallel FA 315 link(s) between two endpoints. 317 When parallel FA links are associated with the same Adj-SID, a 318 "weight" factor can be assigned to each link and advertised with the 319 Adj-SID advertised with each FA link. The weight informs the ingress 320 (or an SDN/orchestration system) about the load-balancing factor over 321 the parallel adjacencies. 323 4.2. SR BGP Segments for FA 325 BGP segments are allocated and distributed by BGP. The SR 326 architecture [RFC8402] defines three types of BGP segments for Egress 327 Peer Engineering (EPE): PeerNode SID, PeerAdj SID, and PeerSet SID. 329 The applicability of each of the three types to FA links is discussed 330 below: 332 o PeerNode SID: a BGP PeerNode segment/SID is a local segment. At 333 the BGP node advertising, the forwarding semantics are: 335 * SR operation: NEXT. 337 * Next-Hop: forward over any FA link associated with the segment 338 that terminates on remote endpoint. 340 o PeerAdj SID: a BGP PeerAdj segment/SID is a local segment. At the 341 BGP node advertising it, the forwarding semantics are: 343 * SR operation: NEXT. 345 * Next-Hop: forward over the specific FA link to the remote 346 endpoint to which the segment is related. 348 o PeerSet SID: a BGP PeerSet segment/SID is a local segment. At the 349 BGP node advertising it, the semantics are: 351 * SR operation: NEXT. 353 * Next-Hop: load-balance across any of the FA links to any remote 354 endpoint in the related set. The group definition is a policy 355 set by the operator. 357 4.3. Applicability to Interdomain 359 In order to determine the potential to establish a TE path through a 360 series of interconnected domains or multi-domain network, it is 361 necessary to have available a certain amount of TE information about 362 each network domain. This need not be the full set of TE information 363 available within each network but does need to express the potential 364 of providing such TE connectivity. 366 Topology abstraction is described in [RFC7926]. Abstraction allows 367 applying a policy to the available TE information within a domain so 368 to produce selective information that represents the potential 369 ability to connect across the domain. Thus, abstraction does not 370 necessarily offer all possible connectivity options, but presents a 371 general view of potential connectivity according to the policies that 372 determine how the domain's administrator wants to allow the domain 373 resources to be used. 375 Hence, the domain may be constructed as a mesh of border node to 376 border node TE FA links. When computing a path for an LSP that 377 crosses the domain, a computation point can see which domain entry 378 points can be connected to which others, and with what TE attributes. 380 5. IANA Considerations 382 TBD. 384 6. Security Considerations 386 TBD. 388 7. Acknowledgement 390 The authors would like to thank Peter Psenak for reviewing and 391 providing valuable feedback on this document. 393 8. Normative References 395 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 396 Requirement Levels", BCP 14, RFC 2119, 397 DOI 10.17487/RFC2119, March 1997, 398 . 400 [RFC3477] Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links 401 in Resource ReSerVation Protocol - Traffic Engineering 402 (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, January 2003, 403 . 405 [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering 406 (TE) Extensions to OSPF Version 2", RFC 3630, 407 DOI 10.17487/RFC3630, September 2003, 408 . 410 [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) 411 Hierarchy with Generalized Multi-Protocol Label Switching 412 (GMPLS) Traffic Engineering (TE)", RFC 4206, 413 DOI 10.17487/RFC4206, October 2005, 414 . 416 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 417 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 418 2008, . 420 [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions 421 in Support of Generalized Multi-Protocol Label Switching 422 (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, 423 . 425 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 426 S. Ray, "North-Bound Distribution of Link-State and 427 Traffic Engineering (TE) Information Using BGP", RFC 7752, 428 DOI 10.17487/RFC7752, March 2016, 429 . 431 [RFC7926] Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., 432 Ceccarelli, D., and X. Zhang, "Problem Statement and 433 Architecture for Information Exchange between 434 Interconnected Traffic-Engineered Networks", BCP 206, 435 RFC 7926, DOI 10.17487/RFC7926, July 2016, 436 . 438 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 439 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 440 May 2017, . 442 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 443 Decraene, B., Litkowski, S., and R. Shakir, "Segment 444 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 445 July 2018, . 447 [RFC8571] Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and 448 C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of 449 IGP Traffic Engineering Performance Metric Extensions", 450 RFC 8571, DOI 10.17487/RFC8571, March 2019, 451 . 453 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 454 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 455 Extensions for Segment Routing", RFC 8665, 456 DOI 10.17487/RFC8665, December 2019, 457 . 459 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 460 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 461 Extensions for Segment Routing", RFC 8667, 462 DOI 10.17487/RFC8667, December 2019, 463 . 465 Authors' Addresses 467 Tarek Saad 468 Juniper Networks, Inc. 470 Email: tsaad@juniper.net 472 Vishnu Pavan Beeram 473 Juniper Networks, Inc. 475 Email: vbeeram@juniper.net 477 Colby Barth 478 Juniper Networks, Inc. 480 Email: cbarth@juniper.net 482 Siva Sivabalan 483 Ciena Corporation. 485 Email: ssivabal@ciena.com