Network Working Group Z. Li Internet-Draft N. Wu Intended status: Standards Track Huawei Expires: September 10, 2015 March 9, 2015 Multi-Topology (MT) Segment in Segment Routing draft-li-spring-multi-topology-segment-00 Abstract Multi-Topologies (MTs) can be used for computing different paths for unicast traffic, multicast traffic, different classes of service based on flexible criteria, or an in-band network management topology. This document proposes the multi-topology segment for segment routing. MRT FRR using multi-topology segment is described as the use case to explains the procedures of the forwarding plane and the control plane for multi-topology segment.. 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 September 10, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. Li & Wu Expires September 10, 2015 [Page 1] Internet-Draft MT Segment in SR March 2015 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. MRT FRR Using Multi-Topology Segment . . . . . . . . . . . . 3 4. Forwarding Mechanisms . . . . . . . . . . . . . . . . . . . . 4 4.1. MRT-FRR in SR . . . . . . . . . . . . . . . . . . . . . . 4 5. Procedures of Control Plane . . . . . . . . . . . . . . . . . 4 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 8.2. Informative References . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction Segment Routing (SR), introduced by [I-D.ietf-spring-segment-routing], leverages the source routing paradigm. A packet can be steered through an ordered list of instructions, which are also called segments. The node segment, adjacency segment, etc. have been proposed for different usecases. This document proposes the multi-topology segment for the segment routing. As stated, Multi-Topologies (MTs) can be used for computing different paths for unicast traffic, multicast traffic, different classes of service based on flexible criteria, or an in-band network management topology. The multi-topology segment is used to identify the multi-topology with the segment ID. MRT FRR using multi-topology segment is described as the use case to explains the procedures of the forwarding plane and the control plane for multi-topology segment. 2. Terminology o Segment: a segment identifies an instruction. Li & Wu Expires September 10, 2015 [Page 2] Internet-Draft MT Segment in SR March 2015 o Multi-Topology Segment, Multi-Topology-SID: a Topology Segment is an IGP segment attached to a IGP multi-topology. A Multi Topology Segment is always global within the SR/IGP domain and identifies an instruction to indicate one specified topology. The Multi- Topology -SID is the SID of the Multi-Topology Segment. o Maximally Redundant Trees (MRT): A pair of trees where the path from any node X to the root R along the first tree and the path from the same node X to the root along the second tree share the minimum number of nodes and the minimum number of links. Each such shared node is a cut-vertex. Any shared links are cut-links. Any RT is an MRT but many MRTs are not RTs. o GADAG: Generalized ADAG - a graph that is the combination of the ADAGs of all blocks. o GADAG root: The root node of GADAG. o MRT-Red: MRT-Red is used to describe one of the two MRTs; it is used to described the associated forwarding topology and MT-ID. Specifically, MRT-Red is the decreasing MRT where links in the GADAG are taken in the direction from a higher topologically ordered node to a lower one. o MRT-Blue: MRT-Blue is used to describe one of the two MRTs; it is used to described the associated forwarding topology and MT-ID. Specifically, MRT-Blue is the increasing MRT where links in the GADAG are taken in the direction from a lower topologically ordered node to a higher one. 3. MRT FRR Using Multi-Topology Segment As described in [I-D.ietf-rtgwg-mrt-frr-architecture], MRT-FRR leverages multi-topologies mechanism to support a pair of Maximally Redundant Trees (MRT) and provides disjoint alternates for a common destination. Unfortunately, IP header could not provides extra bits to indicate its topology. So for the IP network MRT-FRR has to depend on IP tunnels, which will consume more IP addresses. This dilemma can be solved through allocating segments for the MRT- Red topology and the MRT-Blue topology respectively. These Multi- Topology Segments (Multi-Topology SID) SHOULD have global semantics in the SR domain. Thus multi-topology forwarding can be easily achieved with global segments indicating corresponding topologies. With the help of Segment Routing mechanism, for MRT FRR in the IP network no extra IP address will be introduced and LDP protocol is not necessary to be introduced. Li & Wu Expires September 10, 2015 [Page 3] Internet-Draft MT Segment in SR March 2015 4. Forwarding Mechanisms 4.1. MRT-FRR in SR As stated before, MRT-FRR in segment routing domain can depend on topology indicating segment to do multi-topology forwarding. There are three types of routers involved into MRT-FRR forwarding. At the MRT ingress router, the IP packet enters segment routing network for MRT then follows the MRT path to the destination with a Topology Segment inserted into the packet header. In the MRT-FRR scenario, a Multi-Topology Segment indicating MRT-Red or MRT-Blue is used to steer the packet along the alternate path. At the transit router, a packet is received with one segment indicating the corresponding topology it belongs to. The router will pop the segment, look up the route in the corresponding FIB. When forwarding the packet to the next hop, the multi-topology segment will be pushed again. At the egress router, the packet will pop the Multi-Topology Segment and continue to forward the packet to the destination. When MPLS forwarding is applied for the segment routing, the multi- topology segment can map to the MPLS label to indicate the multi- topology. 5. Procedures of Control Plane IGP extensions should be introduced to carries the topology-id and its corresponding index that determines the actual SID/label value inside the set of all advertised SID/label ranges of a given router. A receiving router uses the index to determine the actual SID/label value in order to identify corresponding topology. The Multi- Topology SID MUST be unique within a given IGP domain. The initiation of advertisement of the Multi-Topology SID binding SHOULD be advertised by a specific node in the SR domain. The node can be specified manually or chosen automatically. 6. IANA Considerations This document makes no request of IANA. 7. Security Considerations This document does not introduce new security threat. Li & Wu Expires September 10, 2015 [Page 4] Internet-Draft MT Segment in SR March 2015 8. References 8.1. Normative References [I-D.ietf-rtgwg-mrt-frr-architecture] Atlas, A., Kebler, R., Bowers, C., Envedi, G., Csaszar, A., Tantsura, J., and R. White, "An Architecture for IP/ LDP Fast-Reroute Using Maximally Redundant Trees", draft- ietf-rtgwg-mrt-frr-architecture-05 (work in progress), January 2015. [I-D.ietf-spring-segment-routing] Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., and E. Crabbe, "Segment Routing Architecture", draft-ietf- spring-segment-routing-01 (work in progress), February 2015. 8.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Authors' Addresses Zhenbin Li Huawei Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Nan Wu Huawei Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: eric.wu@huawei.com Li & Wu Expires September 10, 2015 [Page 5]