|Internet-Draft||SR over FA Links||February 2022|
|Saad, et al.||Expires 26 August 2022||[Page]|
- SPRING Working Group
- Intended Status:
Segment-Routing over Forwarding Adjacency Links
Label Switched Paths (LSPs) set up in Multiprotocol Label Switching (MPLS) networks can be used to form Forwarding Adjacency (FA) links that carry traffic in those networks. An FA link can be assigned Traffic Engineering (TE) parameters that allow other LSR(s) to include it in their constrained path computation. FA link(s) can be also assigned Segment-Routing (SR) segments that enable the steering of traffic on to the associated FA link(s). The TE and SR attributes of an FA link can be advertised using known protocols that carry link state information. This document elaborates on the usage of FA link(s) and their attributes in SR enabled networks.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 26 August 2022.¶
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
To improve scalability in Multi-Protocol Label Switching (MPLS) networks, it may be useful to create a hierarchy of LSPs as Forwarding Adjacencies (FA). The concept of FA link(s) and FA-LSP(s) was introduced in [RFC4206].¶
In Segment-Routing (SR), this is particularly useful for two main reasons.¶
First, it allows the stitching of sub-path(s) so as to realize an end-to-end SR path. Each sub-path can be represented by a FA link that is supported by one or more underlying LSP(s). The underlying LSP(s) that support an FA link can be setup using different technologies- including RSVP-TE, LDP, and SR. The sub-path(s), or FA link(s) in this case, can possibly interconnect multiple administrative domains, allowing each FA link within a domain to use a different technology to setup the underlying LSP(s).¶
Second, it allows shortening of a large SR Segment-List by compressing one or more slice(s) of the list into a corresponding FA TE link that each can be represented by a single segment- see Section 4. Effectively, it reduces the number of segments that an ingress router has to impose to realize an end-to-end path.¶
The FA links are treated as normal link(s) in the network and hence it can leverage existing link state protocol extensions to advertise properties associated with the FA link. For example, Traffic-Engineering (TE) link parameters and Segment-Routing (SR) segments parameters can be associated with the FA link and advertised throughout the network.¶
Once advertised in the network using a suitable protocols that support carrying link state information, such as OSPF, ISIS or BGP Link State (LS)), other LSR(s) in the network can use the FA TE link(s) as well as possibly other normal TE link(s) when performing path computation and/or when specifying the desired explicit path.¶
Though the concepts discussed in this document are specific to MPLS technology, these are also extensible to other dataplane technologies - e.g. SRv6.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
In Segment-Routing (SR), the adjacency that is established over a link can be assigned an SR Segment [RFC8402]. For example, the Adj-SID allows to strictly steer traffic on to the specific adjacency that is associated with the Adj-SID.¶
Extensions have been defined to ISIS [RFC8667] and OSPF [RFC8665] in order to advertise the the Adjacency-SID associated with a specific IGP adjacency. The same extensions apply to adjacencies over FA link. A node can bind an Adj-SID to an FA data-link. The Adj-SID dictates the forwarding of packets through the specific FA link or FA link(s) identified by the Adj-SID, regardless of its IGP/SPF cost.¶
When the FA link Adj-SID is supported by a single underlying LSP that is associated with a binding label or SID, the same binding label can be used for the FA link Adj-SID. For example, if the FA link is supported by an SR Policy that is assigned a Binding SID B, the Adj-SID of the FA link can be assigned the same Binding SID B.¶
When the FA link Adj-SID is supported by multiple underlying LSP(s) or SR Policies - each having its own Binding label or SID, an independent FA link Adj-SID is allocated and bound to the multiple underlying LSP(s).¶
Adj-SIDs can also be used in order to represent a set of parallel FA link(s) between two endpoints.¶
When parallel FA links are associated with the same Adj-SID, a "weight" factor can be assigned to each link and advertised with the Adj-SID advertised with each FA link. The weight informs the ingress (or an SDN/orchestration system) about the load-balancing factor over the parallel adjacencies.¶
The applicability of each of the three types to FA links is discussed below:¶
o PeerNode SID: a BGP PeerNode segment/SID is a local segment. At the BGP node advertising, the forwarding semantics are:¶
o PeerAdj SID: a BGP PeerAdj segment/SID is a local segment. At the BGP node advertising it, the forwarding semantics are:¶
o PeerSet SID: a BGP PeerSet segment/SID is a local segment. At the BGP node advertising it, the semantics are:¶
In order to determine the potential to establish a TE path through a series of interconnected domains or multi-domain network, it is necessary to have available a certain amount of TE information about each network domain. This need not be the full set of TE information available within each network but does need to express the potential of providing such TE connectivity.¶
Topology abstraction is described in [RFC7926]. Abstraction allows applying a policy to the available TE information within a domain so to produce selective information that represents the potential ability to connect across the domain. Thus, abstraction does not necessarily offer all possible connectivity options, but presents a general view of potential connectivity according to the policies that determine how the domain's administrator wants to allow the domain resources to be used.¶
Hence, the domain may be constructed as a mesh of border node to border node TE FA links. When computing a path for an LSP that crosses the domain, a computation point can see which domain entry points can be connected to which others, and with what TE attributes.¶
The authors would like to thank Peter Psenak for reviewing and providing valuable feedback on this document.¶
- Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
- Kompella, K. and Y. Rekhter, "Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", RFC 3477, DOI 10.17487/RFC3477, , <https://www.rfc-editor.org/info/rfc3477>.
- Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, DOI 10.17487/RFC3630, , <https://www.rfc-editor.org/info/rfc3630>.
- Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, DOI 10.17487/RFC4206, , <https://www.rfc-editor.org/info/rfc4206>.
- Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, , <https://www.rfc-editor.org/info/rfc5305>.
- Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, , <https://www.rfc-editor.org/info/rfc5307>.
- Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and S. Ray, "North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP", RFC 7752, DOI 10.17487/RFC7752, , <https://www.rfc-editor.org/info/rfc7752>.
- Farrel, A., Ed., Drake, J., Bitar, N., Swallow, G., Ceccarelli, D., and X. Zhang, "Problem Statement and Architecture for Information Exchange between Interconnected Traffic-Engineered Networks", BCP 206, RFC 7926, DOI 10.17487/RFC7926, , <https://www.rfc-editor.org/info/rfc7926>.
- Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
- Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, , <https://www.rfc-editor.org/info/rfc8402>.
- Ginsberg, L., Ed., Previdi, S., Wu, Q., Tantsura, J., and C. Filsfils, "BGP - Link State (BGP-LS) Advertisement of IGP Traffic Engineering Performance Metric Extensions", RFC 8571, DOI 10.17487/RFC8571, , <https://www.rfc-editor.org/info/rfc8571>.
- Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", RFC 8665, DOI 10.17487/RFC8665, , <https://www.rfc-editor.org/info/rfc8665>.
- Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, "IS-IS Extensions for Segment Routing", RFC 8667, DOI 10.17487/RFC8667, , <https://www.rfc-editor.org/info/rfc8667>.