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