Networking Working Group Ran. Chen Internet-Draft Ting. Liao Intended status: Standards Track ZTE Corporation Expires: April 14, 2016 October 12, 2015 Spring Segment List ID draft-chen-spring-segment-list-id-01 Abstract Segment Routing allows a node to steer a packet through an ordered list of instructions, called segments. The ingress node prepends a SR header to a packet containing a set of "segments". A segment can represent any instruction topological or service-based. The Segment Routing architecture can be implemented using MPLS 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, but it has implications on label stack depth. This document describes how to decrease the depth of the label stack in order to do effective Segment Routing operation. 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 April 14, 2016. Copyright Notice Copyright (c) 2015 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 Chen & Liao Expires April 14, 2016 [Page 1] Internet-Draft Segment Routing October 2015 (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. Conventions used in this document . . . . . . . . . . . . . . 3 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Solutions considered . . . . . . . . . . . . . . . . . . . . 3 4.1. Jointing method . . . . . . . . . . . . . . . . . . . . . 3 4.1.1. Forwarding Mechanisms . . . . . . . . . . . . . . . . 5 4.2. Translation segment list to label stack method . . . . . 5 4.2.1. Forwarding Mechanisms . . . . . . . . . . . . . . . . 8 5. Distribution of a binding Segment list ID for segment list information using BGP-LS or PCEP . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1. Normative references . . . . . . . . . . . . . . . . . . 10 8.2. Informative references . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Segment Routing (SR), as described in Draft [I-D.ietf-spring-segment-routing]allows a node to steer a packet through an ordered list of instructions, called segments. This can be directly applied to the MPLS with no change on the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels, but it has implications on label stack depth. There may be many specified nodes or links included in the path based on policy, and this will greatly increase the stack depth. If the label stack depth exceeds the LSR label stack processing capabilities, the hardware should be upgrade to support a deeper label stack capability. This document describes how to decrease the depth of the label stack in order to do effective Segment Routing operation. It does not need to upgrade the hardware. Chen & Liao Expires April 14, 2016 [Page 2] Internet-Draft Segment Routing October 2015 2. Conventions used in this document 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 RFC2119. 3. Terminology SR:Segment Routing SID:Segment Identifier SLID: Segment List Identifier, a segment list is identified by a Segment list ID (SLID). SRLD:specific Readable Label Depth 4. Solutions considered There are two solutions described in the draft, both of them do not need to upgrade the hardware. In this document, we define the Segment List Identifier (SLID). The segment list is identified by a Segment list ID (SLID). Segment list ID (SLID) is allocated by the controller. The segment list and the SLID can be advertised to the related nodes. The related nodes would be the jointing nodes, or all the segment nodes that contained in the segment list, or only be advertised to the ingress node. o In the first case, the jointing nodes need to maintain the MPLS forwarding entry for the SLID. o In the second case, each segment node needs to maintain the MPLS forwarding entry for the SLID. o In the last case, the ingress node floods the SLID via the IGP to all the SR nodes in the SR domain and the SR node should maintain the SR list and the SLID mapping. Each segment nodes that contained in the segment list would maintain the MPLS forwarding entry for the SLID. 4.1. Jointing method The jointing method is based on the stack processing capability of each node. The controller should have the capability to acquire the Chen & Liao Expires April 14, 2016 [Page 3] Internet-Draft Segment Routing October 2015 stack processing capability of each node. It may be analyzed from the chip's version or from the node advertising. In the proposed mechanism, an unused ID from the SRGB is allocated by the controller to identify the segment list which is out of the stack processing capability. +----------------------+ /- _| Controller | _ / / +----------------------+_ \ / / | | | | | \ \ \ / / | | | | | \ \ \ +---+ / +---+ | | +---+ | +---+ \ \+---+ -------- |R1 |---/---|R3 |--|---|--|R5 |---|-|R7 |---\-- |R9 | +---+ / +---+ | | +---+ | +---+ \ +---+ | / | / \ | \ | \ | | / | / \ | \ | \ | +---+ +---+ +---+ +---+ +---+ |R2 |-------|R4 |--------|R6 |-----|R8 |-------|R10|----------- +---+ +---+ +---+ +---+ +---+ Figure 1 In this example, we assumes that: o Each node's chip version is the same, and the stack processing capability is 5. o All nodes are SR capable. o All SR nodes have the same SRGB consisting of: [100, 200] o The operator (likely via the SDN Controller) as provisioned the Node-SIDs 101, 102, 103, 104, 105, 106, 107, 108, 109,and 110 respectively at nodes R1, R2, R3, R4, R5, R6, R7, R8, R9 and R10. o The controller computes a list for: {R1, R2, R4, R3, R5, R6, R8, R7, R9, and R10}, and allocates an unused ID 100 to identify the segment list. o The controller advertises the binding Segment list ID (SLID) 100 for segment list {R1, R2, R4, R3, R5, R6, R8, R7, R9, and R10} to the jointing nodes R1 and R5, or advertises the binding Segment list ID (SLID) 100 for partitioned segment list {R1, R2, R4, R3, Chen & Liao Expires April 14, 2016 [Page 4] Internet-Draft Segment Routing October 2015 and R5} to the jointing nodes R1 and Segment list ID (SLID) 100 for partitioned segment list {R6, R8, R7, R9, and R10} to R5. 4.1.1. Forwarding Mechanisms Node R1 maintains the following LIB entry: Incoming Label: NULL Label Operation: PUSH Outgoing Label: {102,104,103,105,100} Outgoing interface: port to R2 Node R5 maintains the following LIB entry: Incoming Label: 105 &100 Ingress Operation: POP and PUSH Outgoing Label: {106,108,107,109,110} Outgoing interface: R6 Node R10 maintains the following LIB entry: Incoming Label: 110 Ingress Operation: POP Outgoing Label: NULL Outgoing interface: NULL Other nodes are simple as following (i.e.R7): Incoming Label: 107&109 Ingress Operation: POP and SWAP Outgoing Label: 109 Outgoing interface: port to R9 The following shows the progression of the packet as it enters and leaves the SR domain when the SLID is used. R1 encapsulates the SR header list{102,104,103,105,100}. R5 receives the packet, and converts 100 to the following list sequence{106,108,107,109,110}.R5 refreshs the SR header list{106,108,107,109,110}, and then the packet is transited to R6-R8-R7-R9-R10. 4.2. Translation segment list to label stack method In this proposed mechanism, Segment list ID (SLID) is allocated by the controller. The segment list and the SLID can be advertised to all the segment nodes that contained in the segment list, or only be advertised to the ingress node. Chen & Liao Expires April 14, 2016 [Page 5] Internet-Draft Segment Routing October 2015 A node N (Not the last segment node) maintains the following LIB entry: Incoming Active Segment: SRGB_Node_N[SL-SID] Label Operation: SWAP and PUSH (i.e. SWAP with SRGB_Node_N+1[SL-SID] and PUSH the outer-label destination to next segment Node_N+1) Outgoing interface: the interface towards the next-hop along the shortest-path to Node_N+1 Especially, if next segment is not a node segment but an adjacency segment, the label operation would only be SWAP (i.e. SWAP with SRGB_Node_N+1[SL-SID], Node_N+1 is adjacency to Node_N.), and outgoing interface is determined by the adjacency. The last segment node M maintains the following LIB entry: Incoming Active Segment: SRGB_Node_M[SL-SID] Label Operation: POP Outgoing interface: NULL Entire outgoing label stack of the packet in Node N from outer to inner is as follows: +-----------------------------------+ | SRGB_nexthop[Node_N+1-SID] | +-----------------------------------+ | SRGB_Node_N+1[SL-SID] | +-----------------------------------+ Entire outgoing label stack in ingress node from outer to inner is as follows: +-----------------------------------+ | SRGB_nexthop[Node_ 1-SID] | +-----------------------------------+ | SRGB_Node_1 [SL-SID] | +-----------------------------------+ Note:Node 1 is the first node segment. Especially, if the first segment is not a node segment but an adjacency segment, the label stack would only be SRGB_Node_1 [SL- SID]. Node_1 is adjacency to ingress node. Then, any length of the segment list can be encoded as two-level label stacks. Chen & Liao Expires April 14, 2016 [Page 6] Internet-Draft Segment Routing October 2015 Let us analyze the following example: +----------------------+ /- _| Controller | _ / / +----------------------+_ \ / / | | \ \ / / | | \ \ +---+ / +---+ | +---+ +---+ \ \+---+ -------- |R0 |---/---|A1 |-----|--|R1 |-----|A2 |---\-- |R2 | +---+ / +---+ | +---+ +---+ \ +---+ | / \ | \ | | / \ | \ | +---+ +---+ +---+ |R3 |--------------------|R4 |-----------------|R5 |----------- +---+ +---+ +---+ Figure 2 An SDN Controller (SC) is connected to the network and is able to retrieve the topology and traffic information. We assume that: o The operator (likely via the SDN Controller) as provisioned the Node-SIDs 101, 102, 103, 104, 105,and 106 respectively at nodes R0, R1, R2, R3, R4 and R5. o The controller can steer the traffic from R0 to R5 an explicit path R1R2R5. The controller allocates a binding Segment list ID (SLID) 300 for segment list {R1, R2, and R5}. o The controller advertises the binding Segment list ID (SLID) 300 for segment list {R1, R2, and R5} to all the segment nodes (i.e. R1, R2, and R5) that contained in the segment list. Those extensions would be described in section 5. o In this example, all nodes are SR capable, including A1/A2/A3. o Each SR node may have a different SRGB. o The next-hop along the shortest-path from R0 to R1 is A1. A1 can also be LDP/ RSVP-TE/BGP capable (optional). The next-hop along the shortest-path from R1 to R2 is A2. A2 is either an SR node or Chen & Liao Expires April 14, 2016 [Page 7] Internet-Draft Segment Routing October 2015 LDP/RSVP-TE/BGP node. The next-hop along the shortest-path from R2 to R5 is A3. A3 is either an SR node or LDP/RSVP-TE/BGP node. o Any length of the segment list is encoded as two-level label stacks. 4.2.1. Forwarding Mechanisms Then, Node R1 maintains the following LIB entry: Incoming Label: SRGB_R1 [300] Label Operation: SWAP and PUSH Outgoing Label: SRGB_R2 [300], SRGB_A2[103] Outgoing interface: port to A2 Node R2 maintains the following LIB entry: Incoming Label: SRGB_R2[300] Label Operation: SWAP and PUSH Outgoing Label: SRGB_R5 [300], SRGB_A3[106] Outgoing interface: port to A2 or simple as following (because R2 knows it is the penultimate segment of the segment list): Incoming Label: SRGB_R2 [300] Ingress Operation: SWAP Outgoing Label: SRGB_A 3[106] Outgoing interface: port to A3 Node R5 maintains the following LIB entry: Incoming Label: SRGB_R5 [106] Ingress Operation: POP Outgoing Label: NULL Outgoing interface: NULL The following shows the progression of the packet as it enters and leaves the SR domain when the SLID is used. Chen & Liao Expires April 14, 2016 [Page 8] Internet-Draft Segment Routing October 2015 Packets sent by ingress R0 Packets sent by A1 Packets sent by R1 +---------------+ +----------------+ | SRGB_A1[102] | | SRGB_A2[103] | +---------------+ +----------------+ +----------------+ | SRGB_R1[300] |------> | SRGB_R1[300] |------> | SRGB_R2[300] |-------> ++=============++ ++==============++ ++==============++ || Packet || || Packet || || Packet || ++=============++ ++==============++ ++==============++ Packets sent by A2 Packets sent by R2 Packets sent by A3 +---------------+ +----------------+ +----------------+ | SRGB_R2[300] |------> | SRGB_A3[106] |------> | SRGB_R5[106] | ++=============++ ++==============++ ++==============++-------> || Packet || || Packet || || Packet || ++=============++ ++==============++ ++==============++ Packets sent by R5 ++=============++ || Packet || ++=============++ As an optional solution, the ingress node can also encode the label stack according to the global specific Readable label depth (SRLD). Also, the LIB entry (for SL-SID) in each segment node can swap the label stack according to SRLD. This option will be specified in a future version. The global SRLD can be configured, or it can be minimum Readable label depth of all the SR nodes. The RLD has been specified in [I-D.kini-mpls-spring-entropy-label]. The minimum Readable label depth of all the SR nodes can be learned via protocols. 5. Distribution of a binding Segment list ID for segment list information using BGP-LS or PCEP TBD. 6. IANA Considerations TBD. 7. Security Considerations TBD. Chen & Liao Expires April 14, 2016 [Page 9] Internet-Draft Segment Routing October 2015 8. References 8.1. Normative references [I-D.ietf-ospf-segment-routing-extensions] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Extensions for Segment Routing", draft-ietf-ospf-segment- routing-extensions-05 (work in progress), June 2015. [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., and r. rjs@rob.sh, "Segment Routing Architecture", draft- ietf-spring-segment-routing-05 (work in progress), September 2015. [I-D.ietf-spring-segment-routing-mpls] Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., and E. Crabbe, "Segment Routing with MPLS data plane", draft-ietf-spring-segment-routing-mpls-01 (work in progress), May 2015. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, . [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, . 8.2. Informative references [I-D.kini-mpls-spring-entropy-label] Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., Shakir, R., Xu, X., Henderickx, W., and J. Tantsura, "Entropy labels for source routed stacked tunnels", draft- kini-mpls-spring-entropy-label-03 (work in progress), March 2015. Authors' Addresses Chen & Liao Expires April 14, 2016 [Page 10] Internet-Draft Segment Routing October 2015 Ran Chen ZTE Corporation No.50 Software Avenue,Yuhuatai District Nanjing, Jiangsu Province 210012 China Phone: +86 025 88014636 Email: chen.ran@zte.com.cn Ting Liao ZTE Corporation No.50 Software Avenue,Yuhuatai District Nanjing, Jiangsu Province 210012 China Email: liao.ting@zte.com.cn Chen & Liao Expires April 14, 2016 [Page 11]