]> SR-MPLS Aggregation Segment Orange
bruno.decraene@orange.com
Cisco Systems
ketant.ietf@gmail.com
Cisco Systems
skraza@cisco.com
Juniper Networks
shraddha@juniper.net
rtg Internet Engineering Task Force Segment Routing MPLS Aggregation Segment One of the key features of IP that has helped IP Routing to scale is aggregation of IP prefixes. This is made possible with longest-match lookup in IP forwarding. Contrary to this, MPLS forwarding works on exact match on MPLS labels. This poses a challenge in aggregation of IP prefixes when the forwarding is based on the MPLS labels associated with those IP prefixes. This document introduces an Aggregation Segment for Segment Routing with MPLS data plane which can be used to aggregate IP prefixes along with their SR Prefix Segments. Aggregation Segments enable aggregation of IP prefixes to be performed at border routers to improve scalability of MPLS networks.
Introduction One of the key features of IP that has helped IP Routing to scale is aggregation of IP prefixes. This is made possible with longest-match lookup in IP forwarding. IP allows for aggregation between IGP area/levels and/or Autonomous Systems (AS). Optionally, allows for signaling the loss of reachability of an individual prefix covered by the aggregate prefix in order to enable fast convergence mechanisms, e.g., BGP PIC Edge . Contrary to this, MPLS forwarding works on exact match on MPLS labels. MPLS relies on the propagation of each FEC (viz. a specific IP prefix) across routing areas/domains, either with IGP propagation/redistribution or BGP Label Unicast (BGP-LU) . This poses a challenge in aggregation of IP prefixes when the forwarding is based on the MPLS labels associated with those IP prefixes. Moreover, IGP redistribution scales poorly from an IGP and FIB standpoint, while BGP-LU is an additional protocol and infrastructure to deploy and maintain. BGP-LU may also bring additional complexity in some deployments (e.g., PIM rpf-vector, mLDP recursive FEC, BGP local-as when multiple ASes are involved...) This document introduces an Aggregation Segment for Segment Routing with MPLS (SR-MPLS) data plane which can be used to aggregate IP prefixes along with their SR Prefix Segments. Aggregation Segments provide summarization in the control plane at border routers, and introduce hierarchical MPLS labels in the data plane. The latter allows reduction of scale of FIB entries in the routers of the domains where the aggregate prefix is being used for forwarding.
Requirements Language 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 when, and only when, they appear in all capitals, as shown here.
Aggregation Segment An Aggregation Segment is a segment representing both an aggregate IP prefix and the specific Prefix-SIDs advertised in a compress way. It forms a two-levels MPLS label hierarchy with the Aggregation Segment at the top level and the specific Prefix Segments at the bottom level.
  • The Aggregation Segment is a Prefix Segment associated with the aggregate IP prefix, and hence it is signaled as a Prefix Segment.
  • The specific Prefix Segments that are covered by the aggregate are signalled in a compressed form, with the advertisement of the first prefix, the absolute label associated with that first prefix, and the number of consecutive prefixes.
The specific prefixes covered by the aggregate prefix MUST all have the same prefix length (e.g., a /32 in case of IPv4 or /128 in case of IPv6).
Protocol extensions The protocol extensions are out of scope of this document but the semantic of the advertisements are defined in this document. With regards to the signaling of the Aggregation Segment, it is proposed to simply advertise a SR Prefix SID for the IP aggregate prefix. The advertisement of labels associated with the specific prefixes under the Aggregation Segment requires a protocol extension to advertise the set of prefixes and their label range. This could be signaled in different ways e.g., as sub-TLV of the aggregate prefix advertisement, or as a separate advertisement on the lines of a Segment Routing Mapping Server (SRMS). If the same Aggregation segment is advertised by multiple nodes, it becomes an anycast segment. Absent specific provisions (e.g., context specific label) such anycast segment needs to advertise the same labels related parameters (first prefix, the absolute label associated with that first prefix) for all instances. IP routing rules are not modified: routing use the most specific advertisement. The purpose of the Aggregation Segment extension is simply to signal the SID of the Specific Prefix Segment, it does not affect routing.
Uses cases The Aggregation Segment may be used to aggregate multiple Prefix Segments at a routing border such as an ABR for inter-area/levels IGP topologies, or an ASBR for inter-domain topologies.
Inter-Areas The following inter-areas diagram is used in this section. Aggregation Segment (192.0.2/24) - Prefix SID label 2000 (i.e., index 1000) --------------------------------------------------------> Specific Segment to PE2.x (192.0.2.x) - First Prefix 192.0.2.1 - First Label 1201 - Range 255 LSPs: =========== 2000/1203 =================>------ 1203 ------> LSP to PE2.3 =========== 2000/1205 =================>------ 1205 ------> LSP to PE2.5 ]]> The addressing schema used in area 2 for egress PE is the following: PE2.x, IP 192.0.2.x, SID 20x. E.g., for PE2.3, IP 192.0.2.3 and SID 1003. The SR Global Block (SRGB) is 1000. For scaling purpose, ABR2 advertises a single Aggregation Segment in IS-IS level 2 for all the Prefix Segments of AS2 PEs (PE2.x). ABR1 redistributes this Aggregate Segment into area 1. This Aggregation Segment has a SID 1000 allocated from the SRGB. It also signals a label block for the specific Prefix Segments starting at label 1201 with a range of 255 consecutive labels. Note that, in order to create no additional FIB entry on the aggregation node (ABR) the base label 1201 may be chosen such that the MPLS label used for the specific Prefix SID is the same for the IS-IS L1 Area 2 and for the rest to the network using the Aggregation SID. E.g. for PE2.3, the label used in the area 1 is SRGB + Specific SID = 1000 + 203 and for the rest of the network using the Aggregation Segment, the label used is First Label + Nth Specific SID = 1200 + 3. As a results, all routers in the IGP -except area 2- only install the Global Aggregation Segment SID 1000 with the MPLS label 2000 in their FIB. On an as-needed basis, an ingress PE in the IGP (except in area 2) (e.g., PE1) may install a FIB entry for PE2.3, pushing a two-labels MPLS stack 1003, 2000 (respectively inner and outer labels). As a result, any ingress PE may reach any egress PE while transit routers only needs to install the single label/forwarding entry of the Aggregation Segment.
Inter-Domain The following multi-domain diagram is used in this section. Aggregation Segment (192.0.2/24) - SID 1000 ----------------------------------------------------> Aggregated Segment to PE2.x (192.0.2.x) - First Label 1200 - Range 255 LSPs: =========== 2000/1203 ==========>------- 1203 --------> LSP to PE2.3 =========== 2000/1205 ==========>------- 1205 --------> LSP to PE2.5 ]]> The addressing schema used in IGP Domain 1 for egress PE is the following: PE2.x, IP 192.0.2.x, SID 20x. E.g., for PE2.3, IP 192.0.2.3 and SID 1003. The SR Global Block (SRGB) is 1000 in IGP Domains 1 and 2. Note that they are independent and do not need to be equal or disjoint. For scaling purpose, ASBR advertises a single Aggregation Segment in domain 1 for all the Prefix Segments of domain 2 PEs (PE2.x). This global Aggregation Segment has a SID 1000. It also signals a label block for the Specific Prefix Segments starting at label 1200 with a range of 255 consecutive labels. As a results, all routers in domain 1 install a single the Global Aggregation Segment SID 1000 with the MPLS label 2000 in their FIB. On an as-needed basis, ingress PE (PE1) may install a FIB entry for PE2.3, pushing a two-labels MPLS stack 1203, 2000 (respectively inner and outer labels). As a result, an ingress PE1 in domain 1 may reach any egress PE in domain 2 while transit routers in domain 1 only needs to install the single label/forwarding entry of the Aggregation Segment.
Network Operation Considerations The use of Aggregation Segment reduces the number of states and churn in the control plane protocols, forwarding states and likely configuration, compared to the use of all covered specific Prefix Segments. Optionally, allows for signaling the loss of reachability of an individual prefix covered by Aggregation Segment in order to enable fast convergence mechanisms, e.g., BGP PIC Edge . IP Aggregation on border routers requires IP addresses to be aggregatable hence contiguous. Segment aggregation additionally requires that segment ID are allocated in an ordered and contiguous way. This is aligned with the definition and encoding of the Mapping Server as defined in section 2.4. In case of redundant ABRs or ASBRs advertising the same Aggregation Segment, it's strongly recommended to use the same SRGB and same Aggregation Segment SID on redundant aggregation nodes, since they are essentially advertising an anycast Prefix-SID. This is not a new requirement compared to the current practice of redistributing each specific Prefix Segments in the IGP. All ingress which needs to use the Aggregation Segment needs to be upgraded before replacing the redistribution of each Prefix Segment with the Aggregation Segment. A node advertising the Aggregation Segment MAY support the advertisement of both the Aggregation Segment and all specific Prefix-SID in order to ease incremental deployment.
IANA Considerations This document has no IANA actions.
Security Considerations This documents defines a new type of SR-MPLS segments called Aggregation Segment. It does not brings new security considerations. Existing security considerations for Segment Routing and SR-MPLS are described, respectively, in and .
References Normative References Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Segment Routing Architecture Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain. SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack. SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header. Segment Routing with the MPLS Data Plane Segment Routing (SR) leverages the source-routing paradigm. A node steers a packet through a controlled set of instructions, called segments, by prepending the packet with an SR header. In the MPLS data plane, the SR header is instantiated through a label stack. This document specifies the forwarding behavior to allow instantiating SR over the MPLS data plane (SR-MPLS). Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References IGP Unreachable Prefix Announcement Cisco Systems Cisco Systems Bell Canada Juniper Networks, Inc. Verizon Inc. In the presence of summarization, there is a need to signal loss of reachability to an individual prefix covered by the summary in order to enable fast convergence away from paths to the node which owns the prefix which is no longer reachable. This document describes how to use the existing protocol mechanisms in IS-IS and OSPF, together with the two new flags, to advertise such prefix reachability loss. BGP Prefix Independent Convergence Cisco Systems Cisco Systems Sproute Networks In a network comprising thousands of BGP peers exchanging millions of routes, many routes are reachable via more than one next-hop. Given the large scaling targets, it is desirable to restore traffic after failure in a time period that does not depend on the number of BGP prefixes. This document describes an architecture by which traffic can be re- routed to equal cost multi-path (ECMP) or pre-calculated backup paths in a timeframe that does not depend on the number of BGP prefixes. The objective is achieved through organizing the forwarding data structures in a hierarchical manner and sharing forwarding elements among the maximum possible number of routes. The described technique yields prefix independent convergence while ensuring incremental deployment, complete automation, and zero management and provisioning effort. It is noteworthy to mention that the benefits of BGP Prefix Independent Convergence (BGP-PIC) are hinged on the existence of more than one path whether as ECMP or primary-backup. Using BGP to Bind MPLS Labels to Address Prefixes This document specifies a set of procedures for using BGP to advertise that a specified router has bound a specified MPLS label (or a specified sequence of MPLS labels organized as a contiguous part of a label stack) to a specified address prefix. This can be done by sending a BGP UPDATE message whose Network Layer Reachability Information field contains both the prefix and the MPLS label(s) and whose Next Hop field identifies the node at which said prefix is bound to said label(s). This document obsoletes RFC 3107. IS-IS Extensions for Segment Routing Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This document describes the IS-IS extensions that need to be introduced for Segment Routing operating on an MPLS data plane.