SPRING C. Filsfils Internet-Draft S. Previdi Intended status: Standards Track P. Psenak Expires: October 27, 2016 L. Ginsberg Cisco Systems, Inc. April 25, 2016 Segment Routing Recursive Information draft-filsfils-spring-sr-recursing-info-02 Abstract 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). There are use cases where it is desirable to utilize a SID associated with a given node in order to transport traffic destined to different local services supported by such node. This document defines the mechanism to do so and illustrates it. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo 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 http://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 October 27, 2016. Filsfils, et al. Expires October 27, 2016 [Page 1] Internet-Draft SR Recursive Information April 2016 Copyright Notice Copyright (c) 2016 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 (http://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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Segment Routing Recursing Information (SRRI) . . . . . . . . 3 4. Illustration . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Reference Diagram . . . . . . . . . . . . . . . . . . . . 5 4.2. Description . . . . . . . . . . . . . . . . . . . . . . . 5 5. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 9. Normative References . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction Segment Routing (SR) as defined in [I-D.ietf-spring-segment-routing] utilizes forwarding instructions called "segments" to direct packets through the network. When an MPLS dataplane is in use Segment Identifiers (SIDs) are assigned to prefixes and are associated with a specific algorithm. SIDs may be Local or Global in scope. When a SID has global scope the SID is mapped via the Segment Routing Global Block (SRGB) to a node specific label which acts as the forwarding instruction. There are use cases where it is desirable to utilize a SID associated with a node N to transport traffic destined to different local services supported by N. This document defines the mechanism to do so and illustrates it. Filsfils, et al. Expires October 27, 2016 [Page 2] Internet-Draft SR Recursive Information April 2016 2. Use Cases In some deployments, multiple loopback addresses are configured in a single router. Each of these loopback addresses can serve as the address of the node. Specific addresses within this set of node addresses may be used as the endpoint for a particular service or capability. If the number of labeled entries installed in the forwarding plane is a concern, the use of a single label for the set of node addresses (or for some subset of the set of node addresses) can be used in order to reduce the number of forwarding entries required to reach any of the node addresses. This, in turn, would require sharing of a SID among multiple prefixes. Some deployments attach different services to an edge router in a network via unique interfaces. Rather than assigning a unique SID for the address associated with each service the desired behavior is to use a Node-SID to reach the edge router and then utilize a service specific Local SID to direct the packet to the correct service. The first use case is a sub-case of the second one where the local SID is not present (e.g. encoded as implicit-null). Hence in the remainder of this document, we will focus on the more generic use case, i.e., utilizing a single Node-SID in combination with an optional Local SID to transport traffic up to the node and then have the node apply the correct service based on the local SID (if present). 3. Segment Routing Recursing Information (SRRI) This document introduces and defines the concept of a "Segment Routing Recursing Information (SRRI) that needs to be carried into IGPs (ISIS and OSPF), e.g., as a TLV (or SubTLV) attached to the prefix advertisement. The description in this document is protocol agnostic and can be applied to both IGPs (IS-IS and OSPF). The protocol specific format of this advertisement will be defined in protocol specific specifications. Advertisement of a prefix P with SRRI (R, Alg, SID-L) indicates that a remote node M MUST use a segment list {SID(R), SID-L) to transport traffic to P; where SID(R) is the prefix SID of R for the specified algorithm. The generic advertisement format is then: Filsfils, et al. Expires October 27, 2016 [Page 3] Internet-Draft SR Recursive Information April 2016 IPv4 SRRI +-----------------------+ | Flags | 1 byte +-----------------------+ | Algorithm | 1 byte +-----------------------+ | Recursing SID Address | 4 bytes +-----------------------+ | Local SID | 4 bytes (optional) +-----------------------+ IPv6 SRRI +-----------------------+ | Flags | 1 byte +-----------------------+ | Algorithm | 1 byte +-----------------------+ | Recursing SID Address | 16 bytes +-----------------------+ | Local SID | 4 bytes (optional) +-----------------------+ where: o "Flags" is one byte field of flags. Only one flag is currently defined: the V-flag. If set, the receiver of the SRRI MUST verify that the originator of the prefix the SRRI is attached to and the prefix covering the Recursing SID address are originated by the same node ("same origin node"). o "Algorithm" defines the algorithm related to the prefix reachability as defined in [I-D.ietf-spring-segment-routing]. o "Recursing SID Address" contains an IPv4 or IPv6 address whose Node-SID is to be used in order to reach the prefix with which the SRRI information is associated. o "Local SID" is the local SID allocated to the prefix the SRRI is attached to. The SRRI is associated with a prefix reachability advertisement. The manner of this association is protocol specific. The following apply to the SRRI: Filsfils, et al. Expires October 27, 2016 [Page 4] Internet-Draft SR Recursive Information April 2016 o The prefix reachability advertisement this SRRI is attached to MUST NOT have a Prefix-SID assigned for the algorithm specified in the SRRI. o Multiple "Recursing SID Address" and "Local SID" MAY be associated with the same parent prefix. 4. Illustration 4.1. Reference Diagram The following reference topology diagram is used: A----B----D \ \ / \ \/ \ /\ \ / \ C----E |------|------| Area Area 0 1 A is in Area 0 B and C are ABRs D and E are in Area 1 D has a loopback 1.0.0.4/32 and Node SID 16004 D has a local service 1.0.0.99/32 with Local SID 30004 E has a loopback 1.0.0.5/32 and Node SID 16005 E has a local service 1.0.0.99/32 with Local SID 30005 For simplicity, we abstracted the algorithm variable in the SRRI and process. 4.2. Description D advertises prefix 1.0.0.99/32 with SRRI (1.0.0.4, 30004, V=1) B receives the 1.0.0.99/32 prefix advertisement from D. Since the V-flag is set, B MUST confirm that D also originates the "Recursing SID address" 1.0.0.4/32 (i.e.: "same origin node"). If same origin node is not confirmed, then B does not install any SR RIB entry for prefix 1.0.0.99/32. If same origin node is confirmed, B installs an SR RIB entry for 1.0.0.99/32 which uses the segment list {16004, 30004} and the OIF to 16004. Filsfils, et al. Expires October 27, 2016 [Page 5] Internet-Draft SR Recursive Information April 2016 Furthermore, B leaks the prefix in area 0 and advertises it with the SRRI (1.0.0.4, 30004, V=0). The V-flag unset indicates that area 0 nodes do not need to perform the "same origin node" check. E advertises prefix 1.0.0.99/32 with the SRRI (1.0.0.5, 30005, V=1) B does the same for the route from E as he did for the route from D. Specifically, let us highlight two elements: o First, B ends up with an ECMP SR-based RIB entry to 1.0.0.99/32: - {16004, 30004} OIF to 16004 - {16005, 30005} OIF to 16005 o Second, B advertises 1.0.0.99/32 in area 0 with two SRRI's: - (1.0.0.4, 30004, V=0) - (1.0.0.5, 30005, V=0) C does the same for the routes from D and E. Briefly, C advertises 1.0.0.99/32 in area 0 with two SRRI's: - (1.0.0.4, 30004, V=0) - (1.0.0.5, 30005, V=0) A learns 1.0.0.99/32 from B and C and uses normal IGP process to select one, the other or both. Let us assume A prefers the path via B. A receives the 1.0.0.99/32 prefix advertisement from B. Since the V-flag is unset, no "same origin node" is verified. A installs an SR RIB entry for 1.0.0.99/32 with an ECMP set of path: path 1 is {16004, 30004} and the OIF to 16004 path 2 is {16005, 30005} and the OIF to 16005 5. Benefits The mechanism and SR Recursive Information defined in this document supports: o single-area and multi-area deployments. o single-homed and multi-homed prefixes. o the presence of a Local-SID or not. Filsfils, et al. Expires October 27, 2016 [Page 6] Internet-Draft SR Recursive Information April 2016 o Any combination of the above. The Segment Routing Recursive Information minimize the number of global prefix SID's. Finally, the Segment Routing Recursive Information is consistent with the MPLS FIB structure: different FEC's have different entries. 6. IANA Considerations This document doesn't introduce any new code-point. 7. Security Considerations TBD 8. Acknowledgements We would like to thank Les Ginsberg and Ahmed Bashandy for their contributions. 9. Normative References [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", draft-ietf- spring-segment-routing-07 (work in progress), December 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Authors' Addresses Clarence Filsfils Cisco Systems, Inc. Brussels BE Email: cfilsfil@cisco.com Filsfils, et al. Expires October 27, 2016 [Page 7] Internet-Draft SR Recursive Information April 2016 Stefano Previdi Cisco Systems, Inc. Via Del Serafico, 200 Rome 00142 Italy Email: sprevidi@cisco.com Peter Psenak Cisco Systems, Inc. Apollo Business Center Mlynske nivy 43 Bratislava 821 09 Slovakia Email: ppsenak@cisco.com Les Ginsberg Cisco Systems, Inc. US Email: ginsberg@cisco.com Filsfils, et al. Expires October 27, 2016 [Page 8]