SPRING Working Group K. Kompella Internet-Draft T. Saad Intended status: Standards Track A. Deshmukh Expires: January 8, 2020 Juniper Networks July 07, 2019 Resilient MPLS Rings using Segment Routing draft-kompella-spring-rmr-01 Abstract This document describes the use of Segment Routing (SR) control plane to setup LSP(s) for resilient MPLS ring networks. It specifies how clockwise and anti-clockwise ring LSP(s) are signaled using SR IGP protocol extensions, and how such ring LSP(s) are combined to achieve ring protection. 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 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 January 8, 2020. Copyright Notice Copyright (c) 2019 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 Simplified BSD License text as described in Section 4.e of Kompella, et al. Expires January 8, 2020 [Page 1] Internet-Draft SR RMR Rings July 2019 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Ring Taxonomy . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol extensions . . . . . . . . . . . . . . . . . . . . . 4 3.1. SR Ring Capability . . . . . . . . . . . . . . . . . . . 4 3.1.1. IS-IS SR RMR Ring Capabilities Sub-TLV . . . . . . . 5 3.1.2. OSPF SR RMR Ring Capabilities Sub-TLV . . . . . . . . 5 3.2. SR Ring Prefix Segment Identifier (Ring-SID) . . . . . . 5 3.3. Ring Segment Identifier (Ring-SID) . . . . . . . . . . . 8 3.4. Ring-SID Propagation . . . . . . . . . . . . . . . . . . 8 4. Ring SR Signaling Procedures . . . . . . . . . . . . . . . . 8 4.1. Ring SID Assignment . . . . . . . . . . . . . . . . . . . 8 4.1.1. Static Ring-SID Assignment . . . . . . . . . . . . . 9 4.1.2. Ring-SID Assignment Using SRMS . . . . . . . . . . . 9 4.1.3. Ring-SID Assignment Using DHCP . . . . . . . . . . . 10 4.2. Ring SID LSP Setup . . . . . . . . . . . . . . . . . . . 10 4.2.1. Egress Ring Node . . . . . . . . . . . . . . . . . . 10 4.2.2. Ingress and Transit Ring Nodes . . . . . . . . . . . 11 4.2.3. Protection and Fastreroute . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction Ring topologies are very common in transport networks, and are ubiquitous in access and aggregation networks. This draft introduces the necessary extensions to Segment Routing (SR) IGP signaling protocol(s) that are needed to establish Label Switched Paths (LSPs) for Resilient MPLS Rings (RMR). An RMR LSP is a multipoint to point (MP2P) LSP that is signaled using SR control plane extensions to IGPs (e.g. IS-IS or OSPF). SR as defined in [RFC8402] allows for a flexible definition of end- to-end paths within IGP topologies by encoding the SR path as a sequence of one or more topological sub-paths, or "segments". Such Kompella, et al. Expires January 8, 2020 [Page 2] Internet-Draft SR RMR Rings July 2019 segments can be advertised by link-state routing protocols such as IS-IS or OSPF. Rings are auto-discovered using the mechanisms described in the [I-D.ietf-mpls-rmr]. Signaling extensions for IS-IS and OSPF are introduced in [I-D.kompella-isis-ospf-rmr] to enable the auto- discovery of ring topologies. After the ring topology is discovered, each node in the ring determines its Clockwise (CW) and Anti- clockwise (AC) ring neighbors and associated ring links. [I-D.ietf-teas-rsvp-rmr-extension] describes the necessary RSVP-TE [RFC3209] signaling protocol extensions that are needed to setup Resilient MPLS Ring (RMR) LSPs. [I-D.ietf-mpls-ldp-rmr-extensions] describes extensions to LDP [RFC5036] signaling protocol that are needed for LDP setup RMR LSPs. This document describes how Segment Routing (SR) IGP control plane can be extended to allow for the setup of RMR LSPs and how a pair of CW and AC SR MPLS LSPs can provide the required protection for ring topologies. The first revisions of this document will focus on the simple most common ring topologies in access networks that do not include any "express links". Future revisions of this document will expand on express link(s) for the more general rings. 2. Terminology 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. 2.1. Ring Taxonomy A ring consists of a subset of n nodes {R_i, 0 <= i < n}. The direction from node R_i to R_i+1 is defined as as "clockwise" (CW) and the reverse direction is defined as "anti-clockwise" (AC). As there may be several rings in a graph, each ring is numbered with a distinct Ring ID (RID). The following terminology is used for rings: Ring ID (RID): A non-zero number that identifies a ring; this is unique in some scope of a Service Provider's network. A node may belong to multiple rings, each identified by its unique RID Kompella, et al. Expires January 8, 2020 [Page 3] Internet-Draft SR RMR Rings July 2019 Ring Node: A member of a ring. Note that a node may belong to several rings. Node Index: A logical numbering of nodes in a ring, from zero up to one less than the ring size. Used purely for exposition in this document. Ring Master: The ring master initiates the ring identification process. Mastership is indicated in the IGP by a two-bit field. Ring Neighbors: Nodes whose indices differ by one (modulo ring size). Ring Size: The ring size for a given instantiation is N. This can change as nodes are added or removed, or go up or down. Ring Links: Links that connect ring neighbors. Express Links: Links that connect non-neighboring ring nodes. Ring LSP: Each LSP in the ring is a multipoint to point LSP such that LSP can have multiple ingress nodes and one egress node. Ring Identification: The process of discovering ring nodes, ring links, link directions, and express links. Ring SID: Each ring node advertises 2 unique Ring Prefix Segment Identifiers(Ring SIDs). CW ring SID is advertised by ring node to receive traffic in clockwise direction. AC ring SID is advertised by ring node to receive traffic in anti-clockwise direction. 3. Protocol extensions This section describes the necessary IGP protocol extensions to SR to allow signaling and establishing RMR LSP(s) to each node in a ring. 3.1. SR Ring Capability A new sub-TLV is defined for SR RMR Ring Capability to advertise node support for signaling SR RMR LSP(s) using extensions in IS-IS and OSPF protocol(s). Kompella, et al. Expires January 8, 2020 [Page 4] Internet-Draft SR RMR Rings July 2019 If the SR RMR Ring Capability is not advertised by a node, such node is considered not capable of establishing SR RMR LSP(s) using SR control plane extensions. The SR RMR Ring Capability sub-TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD-1 Length: length in octets, 1. Flags: 1 octet. Currently no flags are defined. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+ 3.1.1. IS-IS SR RMR Ring Capabilities Sub-TLV In IS-IS, the Router Capability TLV TLV-242 defined in [RFC7981] is used to carry the SR RMR Ring Capability sub-TLV. 3.1.2. OSPF SR RMR Ring Capabilities Sub-TLV In OSPF, a top-level TLV of the Router Information Opaque LSA (defined in [RFC7770]) is used to carry the SR RMR Ring Capability sub-TLV. 3.2. SR Ring Prefix Segment Identifier (Ring-SID) In order to setup an SR RMR LSP(s) in CW and AC directions towards each node of the ring, this document defines a new Ring SR Prefix Segment Identifier (Ring-SID) sub-TLV. The Ring-SID sub-TLV carries the IGP Segment Routing Ring-SID that is associated with the advertised prefix by the node. The Ring-SID is unique within a specific ring in an IGP domain. For IS-IS protocol, the Ring-SID MAY be present in any of the following TLVs: TLV-135 (Extended IPv4 reachability) defined in [RFC5305]. Kompella, et al. Expires January 8, 2020 [Page 5] Internet-Draft SR RMR Rings July 2019 TLV-235 (Multitopology IPv4 Reachability) defined in [RFC5120]. TLV-236 (IPv6 IP Reachability) defined in [RFC5308]. TLV-237 (Multitopology IPv6 IP Reachability) defined in [RFC5120]. For OSPF protocol, the Ring-SID sub-TLV is carried as part of the OSPF Extended Prefix TLV defined in [RFC7684]. The Ring-SID sub-TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Flags | Algorithm | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ring ID (RID) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ring-SID Index/Label (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: TBD-2 Length: 9 or 10 depending on the size of the SID (index vs. absolute label) Flags: 1 octet field of following flags: TBD. Length: length in octets, 1. 0 1 2 3 4 5 6 7 +--+--+--+--+--+--+--+--+ |D |NP|M |E |V | | | | +--+--+--+--+--+--+--+--+ where: D-Flag: identifies the direction towards the downstream neighbors. The possible values are: Kompella, et al. Expires January 8, 2020 [Page 6] Internet-Draft SR RMR Rings July 2019 0: CW next-hop(s) neighbor(s) derived after the completion of ring identification phase. 1: AC next-hop(s) neighbor(s) derived after the completion of ring identification phase. NP-Flag: No-PHP flag. If set, then the penultimate hop MUST NOT pop the Prefix-SID before delivering packets to the node that advertised the Ring-SID. M-Flag: Mapping Server Flag. If set, the SID was advertised by a Segment Routing Mapping Server as described in [I-D.ietf-spring-segment-routing-ldp-interop]. E-Flag: Explicit-Null Flag. If set, any upstream neighbor of the Prefix-SID originator MUST replace the Prefix-SID with the Explicit-NULL label (0 for IPv4) before forwarding the packet. V-Flag: Value/Index Flag. If set, then the Prefix-SID carries an absolute value. If not set, then the Ring-SID carries an index. Other bits: Reserved. These MUST be zero when sent and are ignored when received. Algorithm: Single octet identifying the algorithm to use to derive the downstream member ring next-hop(s) to reach a specific ring node. The following values are defined by this document: 0: Include all next-hop(s) derived from the completion of ring identification process. The D-Flag indicates whether CW or AC are to be considered. Other user-defined algorithms identifiers from the range 128-255 can be defined and used as described in [I-D.ietf-lsr-flex-algo]. Ring-ID: The Ring ID that the Ring-SID is advertised for. Ring-SID: The 'Ring SID' MUST be unique within a given IGP domain (when the L-flag is not set). SID/Index/Label: as defined in [I-D.ietf-isis-segment-routing-extensions]. Kompella, et al. Expires January 8, 2020 [Page 7] Internet-Draft SR RMR Rings July 2019 3.3. Ring Segment Identifier (Ring-SID) An alternative means of propagating the CW and AC Ring SIDs is as a sub-TLV of the RMR TLV. This sub-TLV has the following format in IS- IS: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type (TBD) | Length (8) | CW Ring SID ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... CW Ring SID | AC Ring SID ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... AC Ring SID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: Type: is the type of the sub-TLV (TBD) Length: 8 Value: The CW SID followed by the AC SID. 3.4. Ring-SID Propagation The rules for the propagation of a Ring-SID follow those dictated in [I-D.ietf-isis-segment-routing-extensions] and [I-D.ietf-ospf-segment-routing-extensions]. 4. Ring SR Signaling Procedures 4.1. Ring SID Assignment As described in [I-D.ietf-mpls-rmr], a ring of RID r can be either configured on all nodes participating in ring r, or be configured on select master member ring node(s) while running other nodes in promiscuous mode. All ring node(s) participating in a ring use the IGP extensions defined in [I-D.kompella-isis-ospf-rmr] to advertise their ring membership and to complete ring discovery and identification phase. A unique CW and AC Ring-SIDi(s) are assigned to a prefix on residing on each ring member node participating in the ring. Kompella, et al. Expires January 8, 2020 [Page 8] Internet-Draft SR RMR Rings July 2019 4.1.1. Static Ring-SID Assignment An operator can choose to statically assign and configure the unique CW and AC Ring-SID(s) associated with the prefixes residing on each member node of the ring. In such case, it is expected that Ring-SID assignment and management becomes the responsibility of the network operator in order to ensure global uniqueness. When static provisioning of Ring-SID(s) on ring node(s) is implemented, the Ring-SID(s) sub-TLV(s) are explicitly advertised along with the prefix reachability advertisement. Examples of such explicit advertisement(s) for prefix-SID(s) are given in [I-D.ietf-isis-segment-routing-extensions], [I-D.ietf-ospf-segment-routing-extensions], and [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. 4.1.2. Ring-SID Assignment Using SRMS It is possible to leverage the Segment Routing Mapping Server (SRMS) functionality as defined in [I-D.ietf-spring-segment-routing-ldp-interop] to assign, advertise, and manage Ring-SID(s) on behalf of all ring nodes in the network. This simplifies the burden on the operator to provision rings and Ring-SID(s) on network ring nodes, by restricting configuration to only select nodes in the ring (e.g. master node(s)). The SRMS functionality consists of two functional blocks: a Mapping Server (MS) and a Mapping Client (MC). The SR MS functionality supports the advertisement of prefix-SID(s) to a prefix without the need to explicitly advertise such assignment within a prefix reachability advertisement. This document extends the MS functionality to allow it to advertise the Ring-SID to prefix mapping in a similar fashion. The SR MC is any node that receives and uses the MS mapping advertisements. The MC interprets the SR mapping Ring-SID advertisement as an assignment of a Ring-SID to a prefix. Note that the SRMS node can serve as both an MS and an MC. To implement the SRMS for assigning and managing Ring-SID(s), the network operator reserves a block of SR Ring SID indices and delegates it to the SRMS. When a ring of RID r is configured/enabled on a ring master node, the SRMS learns of ring nodes participating in ring RID r using the ring node TLV defined in [I-D.kompella-isis-ospf-rmr]. Whenever the SRMS discovers a new ring node, it automatically assigns two unique Ring- Kompella, et al. Expires January 8, 2020 [Page 9] Internet-Draft SR RMR Rings July 2019 SID(s)- for CW and AC Ring-SID LSP(s) - from the available SID(s) within the Ring SID block available on the SRMS. After CW and AC Ring-SID(s) are assigned to a ring node prefix, the SRMS can advertises the Ring-SID sub-TLV in a SID/label binding TLV as described in [I-D.ietf-isis-segment-routing-extensions] and [I-D.ietf-ospf-segment-routing-extensions]. 4.1.3. Ring-SID Assignment Using DHCP The Dynamic Host Configuration Protocol is uniquely well-suited for handling node and ring SID assignments. When ring directions have been established for all links in the ring, each node can request, as a DHCP client, a pair of ring SIDs. The DHCP server responds with two unique values from the SID block(s) for Ring SIDs with which it has been configured. The DHCP server SHOULD be configured with very long leases for such assignments, as well as "sticky" assignments; that is, should a lease expire, the pair of values assigned should not be offered to another client unless the server has run out of ring SID values; also, should the same client re-request ring SIDs, the server should return the same SIDs if at all possible. Further details are provided in [I-D.kompella-spring-dhcp]. 4.2. Ring SID LSP Setup Any ring node that receives a Ring-SID advertisement either part of an explicit prefix TLV advertisement or part of a SID/label binding TLV advertised by the SRMS will perform the following depending on ring node role. 4.2.1. Egress Ring Node An node that is member of a ring RID r can advertise a Ring-SID sub- TLV associated with local prefix. If the node learns of a Ring-SID sub-TLV associated to local prefix using the SID/label binding TLV advertised by the SRMS, the node first verify it is member of ring indicated in the Ring-SID sub-TLV. If not, the node does not process the Ring-SID sub-TLV any further. Otherwise, when the node is member of the ring indicated in the Ring- SID sub-TLV it ensures that the corresponding local MPLS label from its SRGB is assigned and bound to the specific local prefix and RID. If no pen-ultimate hop popping is desired, an egress Incoming Label Map (ILM) entry corresponding for the corresponding local label is installed in the forwarding table as usual. Kompella, et al. Expires January 8, 2020 [Page 10] Internet-Draft SR RMR Rings July 2019 4.2.2. Ingress and Transit Ring Nodes An ingress or transit node that receives a Ring-SID sub-TLV advertisement for a remote prefix through an explicit prefix TLV advertisement, or through a SID/label binding TLV for a remote prefix will first verify that it is member of the ring indicated in the Ring-SID sub-TLV advertisement before processing it any further. If the ingress or transit node are is not member of the Ring-SID's ring, the node MUST not process the Ring-SID any further. Otherwise, if the ingress or transit node is member of the ring indicated in the Ring-SID, the ingress or transit node ensures that the corresponding local MPLS label in its SRGB is assigned and bound to the specific remote prefix and for the specific ring. As described in Section 3.2, the Ring-SID sub-TLV carries an Algorithm identifier that indicates the procedure to derive the set of next-hop(s) to reach a CW or AC neighbor. The default algorithm (Algorithm 0) is to include all next-hop(s)/links between itself and the respective downstream neighbor. The D-Flag in the Flags field within the Ring-SID sub-TLV indicates whether the CW or AC downstream neighbors are intended. An operator may make use of other user-defined Algorithms to allow a ingress or transit ring node to select specific link(s)/neighbors that connect to the downstream CW or AC neighbor. Once the CW and AC next-hop(s) are determined, the ingress or transit router(s) of the RMR ring LSP add the corresponding ILM entries for the CW and AC labels and map each to the set of CW and AC Next-hop Label Forwarding Entries (NHLFE)s. 4.2.3. Protection and Fastreroute The ingress or a transit node that receives a Ring-SID advertisement from a remote ring node, in addition to assigning and programming the primary CW or AC next-hop(s) as described in the previous section, assigns the opposite direction AC or CW next-hop and its associated AC or CW Ring-SID as a backup path. Upon failure, the ingress or a transit router that detects a local link failure of the Ring-SID's primary next-hop, immediately diverts traffic on to the pre-programmed backup next-hop of the Ring-SID. Traffic originally flowing in a CW or AC direction will be diverted to flow on to flow in the AC or CW direction after the failure. In case of a failure at a transit ring node along the path of a Ring- SID, any upstream router that learns of the downstream link failure Kompella, et al. Expires January 8, 2020 [Page 11] Internet-Draft SR RMR Rings July 2019 via IGP link updates, can locally reroute(s) the traffic towards the backup next-hop. This optimizes the repair path and avoids packets from being unnecessarily forwarded to the ring node where local fault occurred, and the be looped back on the opposite Ring-SID due to the fault. 5. IANA Considerations TODO. 6. Security Considerations It is not anticipated the extensions to IGP SR protocols described in this document may introduce additional security risk(s). Future revisions of this document will update this section with details about those risks. 7. Acknowledgement The authors would like to thank XX for reviewing and providing valuable feedback on this document. 8. Contributors Raveendra Torvi Juniper Networks Email: rtorvi@juniper.net Vishnu Pavan Beeram Juniper Networks Email: vbeeram@juniper.net 9. References 9.1. Normative References [I-D.ietf-isis-segment-routing-extensions] Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., Gredler, H., and B. Decraene, "IS-IS Extensions for Segment Routing", draft-ietf-isis-segment-routing- extensions-25 (work in progress), May 2019. Kompella, et al. Expires January 8, 2020 [Page 12] Internet-Draft SR RMR Rings July 2019 [I-D.ietf-lsr-flex-algo] Psenak, P., Hegde, S., Filsfils, C., Talaulikar, K., and A. Gulko, "IGP Flexible Algorithm", draft-ietf-lsr-flex- algo-03 (work in progress), July 2019. [I-D.ietf-mpls-ldp-rmr-extensions] Esale, S. and K. Kompella, "LDP Extensions for RMR", draft-ietf-mpls-ldp-rmr-extensions-02 (work in progress), June 2019. [I-D.ietf-mpls-rmr] Kompella, K. and L. Contreras, "Resilient MPLS Rings", draft-ietf-mpls-rmr-11 (work in progress), June 2019. [I-D.ietf-ospf-ospfv3-segment-routing-extensions] Psenak, P. and S. Previdi, "OSPFv3 Extensions for Segment Routing", draft-ietf-ospf-ospfv3-segment-routing- extensions-23 (work in progress), January 2019. [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-27 (work in progress), December 2018. [I-D.ietf-spring-segment-routing-ldp-interop] Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., and S. Litkowski, "Segment Routing interworking with LDP", draft-ietf-spring-segment-routing-ldp-interop-15 (work in progress), September 2018. [I-D.kompella-isis-ospf-rmr] Kompella, K., "IGP Extensions for Resilient MPLS Rings", draft-kompella-isis-ospf-rmr-00 (work in progress), October 2016. [I-D.kompella-spring-dhcp] Kompella, K. and R. Bonica, "Using DHCP to Manage Node and Ring SID Assignment", draft-kompella-spring-dhcp-00 (work in progress), July 2019. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Kompella, et al. Expires January 8, 2020 [Page 13] Internet-Draft SR RMR Rings July 2019 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, . [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, . [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, . [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, DOI 10.17487/RFC5308, October 2008, . [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 2015, . [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, February 2016, . [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions for Advertising Router Information", RFC 7981, DOI 10.17487/RFC7981, October 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . 9.2. Informative References [I-D.ietf-teas-rsvp-rmr-extension] Deshmukh, A. and K. Kompella, "RSVP Extensions for RMR", draft-ietf-teas-rsvp-rmr-extension-01 (work in progress), June 2018. Kompella, et al. Expires January 8, 2020 [Page 14] Internet-Draft SR RMR Rings July 2019 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, . Authors' Addresses Kireeti Kompella Juniper Networks Email: kireeti.kompella@gmail.com Tarek Saad Juniper Networks Email: tsaad@juniper.net Abhishek Deshmukh Juniper Networks Email: adeshmukh@juniper.net Kompella, et al. Expires January 8, 2020 [Page 15]