< draft-kompella-spring-rmr-00.txt   draft-kompella-spring-rmr-01.txt >
SPRING K. Kompella SPRING Working Group K. Kompella
Internet-Draft A. Deshmukh Internet-Draft T. Saad
Intended status: Standards Track R. Torvi Intended status: Standards Track A. Deshmukh
Expires: April 25, 2019 Juniper Networks, Inc. Expires: January 8, 2020 Juniper Networks
October 22, 2018 July 07, 2019
Resilient MPLS Rings Resilient MPLS Rings using Segment Routing
draft-kompella-spring-rmr-00 draft-kompella-spring-rmr-01
Abstract Abstract
This document describes the use of the SPRING MPLS data plane for This document describes the use of Segment Routing (SR) control plane
Resilient MPLS Rings. It describes how to create the bidirectional to setup LSP(s) for resilient MPLS ring networks. It specifies how
ring LSPs with SPRING, and how protection works. clockwise and anti-clockwise ring LSP(s) are signaled using SR IGP
protocol extensions, and how such ring LSP(s) are combined to achieve
Requirements Language ring protection.
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].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2019. This Internet-Draft will expire on January 8, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Ring Taxonomy . . . . . . . . . . . . . . . . . . . . . . 3
3. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol extensions . . . . . . . . . . . . . . . . . . . . . 4
3.1. Installing Primary LFIB Entries . . . . . . . . . . . . . 5 3.1. SR Ring Capability . . . . . . . . . . . . . . . . . . . 4
3.2. Installing Protection LFIB Entries . . . . . . . . . . . 5 3.1.1. IS-IS SR RMR Ring Capabilities Sub-TLV . . . . . . . 5
3.3. Protection . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.2. OSPF SR RMR Ring Capabilities Sub-TLV . . . . . . . . 5
4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 3.2. SR Ring Prefix Segment Identifier (Ring-SID) . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 3.3. Ring Segment Identifier (Ring-SID) . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.4. Ring-SID Propagation . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . 6 4. Ring SR Signaling Procedures . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . 6 4.1. Ring SID Assignment . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 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 1. Introduction
Rings are a very common topology in transport networks. A ring is Ring topologies are very common in transport networks, and are
the simplest topology offering link and node resilience. Rings are ubiquitous in access and aggregation networks.
nearly ubiquitous in access and aggregation networks. As MPLS
increases its presence in such networks, and takes on a greater role
in transport, it is imperative that MPLS handles rings well;
[I-D.ietf-mpls-rmr] shows how this can be done.
[I-D.ietf-teas-rsvp-rmr-extension] shows how RSVP-TE [RFC3209] can be
used to signal RMR ring LSPs. [I-D.ietf-mpls-ldp-rmr-extensions]
shows how LDP [RFC5036] can be used to signal RMR LSPs. This
document shows how SPRING SID bindings can be used to create RMR
LSPs, how the basic bidirectional LSPs are set up, and how protection
works.
While RMR looks at rings potentially with "express links", this This draft introduces the necessary extensions to Segment Routing
document focuses on simple rings. These are most common in access (SR) IGP signaling protocol(s) that are needed to establish Label
networks. Future revisions will look at more general rings. 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).
1.1. Definitions 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
segments can be advertised by link-state routing protocols such as
IS-IS or OSPF.
A (directed) graph G = (V, E) consists of a set of vertices (or Rings are auto-discovered using the mechanisms described in the
nodes) V and a set of edges (or links) E. An edge is an ordered pair [I-D.ietf-mpls-rmr]. Signaling extensions for IS-IS and OSPF are
of nodes (a, b), where a and b are in V. (In this document, the introduced in [I-D.kompella-isis-ospf-rmr] to enable the auto-
terms node and link will be used instead of vertex and edge.) discovery of ring topologies. After the ring topology is discovered,
A ring is a subgraph of G. A ring consists of a subset of n nodes each node in the ring determines its Clockwise (CW) and Anti-
{R_i, 0 <= i < n} of V. The directed edges {(R_i, R_i+1) and (R_i+1, clockwise (AC) ring neighbors and associated ring links.
R_i), 0 <= i < n-1} must be a subset of E (note that index arithmetic
is done modulo n). We define the direction from node R_i to R_i+1 as
"clockwise" (CW) and the reverse direction as "anticlockwise" (AC).
As there may be several rings in a graph, we number each ring with a
distinct ring ID RID.
R0 . . . R1 [I-D.ietf-teas-rsvp-rmr-extension] describes the necessary RSVP-TE
. . [RFC3209] signaling protocol extensions that are needed to setup
R7 R2 Resilient MPLS Ring (RMR) LSPs. [I-D.ietf-mpls-ldp-rmr-extensions]
Anti- | . Ring . | describes extensions to LDP [RFC5036] signaling protocol that are
Clockwise | . . | Clockwise needed for LDP setup RMR LSPs.
v . RID = 17 . v
R6 R3
. .
R5 . . . R4
Figure 1: Ring with 8 nodes 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 following terminology is used for ring LSPs: 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.
Ring ID (RID): A non-zero number that identifies a ring; this is 2. Terminology
unique in some scope of a Service Provider's network. A node may
belong to multiple rings.
Ring node: A member of a ring. Note that a device may belong to The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
several rings. "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.
Node index: A logical numbering of nodes in a ring, from zero upto 2.1. Ring Taxonomy
one less than the ring size. Used purely for exposition in this
document.
Ring master: The ring master initiates the ring identification A ring consists of a subset of n nodes {R_i, 0 <= i < n}. The
process. Mastership is indicated in the IGP by a two-bit field. 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).
Ring neighbors: Nodes whose indices differ by one (modulo ring The following terminology is used for rings:
size).
Ring size: The ring size for a given instantiation is N. This can Ring ID (RID):
change as nodes are added or removed, or go up or down. 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
Ring links: Links that connnect ring neighbors. Ring Node:
A member of a ring. Note that a node may belong to several rings.
Express links: Links that connnect non-neighboring ring nodes. 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 direction: A two-bit field in the IGP indicating the direction Ring Master:
of a link. The choices are: The ring master initiates the ring identification process.
Mastership is indicated in the IGP by a two-bit field.
UN: 00 undefined link Ring Neighbors:
Nodes whose indices differ by one (modulo ring size).
CW: 01 clockwise ring link 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.
AC: 10 anticlockwise ring link Ring Links:
Links that connect ring neighbors.
EX: 11 express link Express Links:
Links that connect non-neighboring ring nodes.
Ring Identification: The process of discovering ring nodes, ring Ring LSP:
links, link directions, and express links. Each LSP in the ring is a multipoint to point LSP such that LSP
can have multiple ingress nodes and one egress node.
The following notation is used for ring LSPs: Ring Identification:
The process of discovering ring nodes, ring links, link
directions, and express links.
R_k: A ring node with index k. R_k has AC neighbor R_(k-1) and CW Ring SID:
neighbor R_(k+1). 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.
NS_k: Node SID for node R_k. Note that index arithmetic is done 3. Protocol extensions
modulo the ring size N.
CAS_k, AAS_k: Clockwise adjacency SID at R_k, i.e., link R_k, R_k+1 This section describes the necessary IGP protocol extensions to SR to
and anticlockwise adjacency SID R_k, R_k-1 respectively. Note allow signaling and establishing RMR LSP(s) to each node in a ring.
that index arithmetic is done modulo the ring size N.
CSS_jk: A clockwise node SID stack, typically with one or two SIDs, 3.1. SR Ring Capability
to be pushed by R_j to reach R_k in a clockwise direction.
ASS_jk: An anticlockwise node SID stack, typically with one or two A new sub-TLV is defined for SR RMR Ring Capability to advertise node
SIDs, to be pushed by R_j to reach R_k in an anticlockwise support for signaling SR RMR LSP(s) using extensions in IS-IS and
direction. OSPF protocol(s).
2. Motivation 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.
A ring is the simplest topology that offers resilience. This is The SR RMR Ring Capability sub-TLV has the following format:
perhaps the main reason to lay out fiber in a ring. Thus, effective
mechanisms for fast failover on rings are needed. Furthermore, there
are large numbers of rings. Thus, configuration of rings needs to be
as simple as possible.
The goals of this document are to present mechanisms for improved 0 1 2 3
resilience in ring networks (using ideas that are reminiscent of 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
Bidirectional Line Switched Rings), for automatic bring-up of LSPs, +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
better bandwidth management and for auto-hierarchy. These goals are | Type | Length | Flags |
achieved using extensions to existing IGP. This document shows how +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
to do this using SPRING techniques, in particular, node SIDs. Note
that in a simple ring topology, there is no need for complex
algorithms to find loop-free protection paths.
3. Theory of Operation Type: TBD-1
We assume that a ring R has been configured, IGP advertisements have Length: length in octets, 1.
been made, and ring discovery is complete ([I-D.ietf-mpls-rmr]). We
also assume that node and adjacency SIDs have been distributed.
3.1. Installing Primary LFIB Entries Flags: 1 octet. Currently no flags are defined.
Ring LSPs are not provisioned. Once a ring node R_i knows its RID, 0 1 2 3 4 5 6 7
its ring links and directions, it kicks off ring LSP computation +-+-+-+-+-+-+-+-+
automatically. In particular, R_j computes clockwise and | Reserved |
anticlockwise SID stacks CSS_jk and ASS_jk to node R_k. R_j then +-+-+-+-+-+-+-+-+
installs two FIB entries for R_k, CSS_jk and ASS_jk. It is up to an
application to choose whether to go clockwise or anticlockwise from
R_j to R_k.
R_j also computes CSS_jj and ASS_jj. Clearly, R_j does not act as 3.1.1. IS-IS SR RMR Ring Capabilities Sub-TLV
ingress for its own LSPs. However, R_j can send OAM messages, for
example, an MPLS ping or traceroute ([I-D.ietf-mpls-rfc4379bis]),
using CSS_jj or ASS_jj, to test the entire ring LSP anchored at R_j
in both directions.
3.2. Installing Protection LFIB Entries In IS-IS, the Router Capability TLV TLV-242 defined in [RFC7981] is
used to carry the SR RMR Ring Capability sub-TLV.
At the same time that R_j sets up its primary clockwise and 3.1.2. OSPF SR RMR Ring Capabilities Sub-TLV
anticlockwise SID stacks, it sets up protection for each other node
R_k. R_j does this by installing a protection SID stack for the node
SID to R_k, NS_k. If the shortest path to R_k is clockwise, then the
protection SID stack for NS_k is ASS_jk. Otherwise, it is CSS_jk.
Similarly, the protection entry for an adjacency SID CAS_j is In OSPF, a top-level TLV of the Router Information Opaque LSA
ASS_j,j+1 and for AAS_j is CSS_j,j-1. (defined in [RFC7770]) is used to carry the SR RMR Ring Capability
sub-TLV.
3.3. Protection 3.2. SR Ring Prefix Segment Identifier (Ring-SID)
If a node R_j detects a failure from R_j+1 -- either all links to In order to setup an SR RMR LSP(s) in CW and AC directions towards
R_j+1 fail, or R_j+1 itself fails, R_j switches traffic on all CW each node of the ring, this document defines a new Ring SR Prefix
node and adjacency SIDs to their protection LFIB entries. This Segment Identifier (Ring-SID) sub-TLV.
switchover can be very fast, as the protection LFIB entries can be
preprogrammed. Fast detection and fast switchover lead to minimal
traffic loss.
R_j then sends an indication to R_j-1 that the CW direction is not The Ring-SID sub-TLV carries the IGP Segment Routing Ring-SID that is
working, so that R_j-1 can similarly switch traffic to the AC associated with the advertised prefix by the node. The Ring-SID is
direction. This can be by an IGP update; other, potentially quicker, unique within a specific ring in an IGP domain.
mechanisms would be preferable. These indications propagate AC until
each traffic source on the ring AC of the failure is aware of the
failure. Thus, within a short period, traffic will be flowing on the
reverse path than that which was chosen, since there is a failure on
the ring.
4. Security Considerations For IS-IS protocol, the Ring-SID MAY be present in any of the
following TLVs:
It is not anticipated that either the notion of MPLS rings or the TLV-135 (Extended IPv4 reachability) defined in [RFC5305].
extensions to various protocols to support them will cause new
security loopholes. As this document is updated, this section will TLV-235 (Multitopology IPv4 Reachability) defined in [RFC5120].
also be updated.
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:
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].
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.
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-
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.
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
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 5. IANA Considerations
There are no requests as yet to IANA for this document. TODO.
6. References 6. Security Considerations
6.1. Normative References 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.
[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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
6.2. Informative References [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <https://www.rfc-editor.org/info/rfc5036>.
[I-D.ietf-mpls-ldp-rmr-extensions] [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Esale, S. and K. Kompella, "LDP Extensions for RMR", 2018. Topology (MT) Routing in Intermediate System to
Intermediate Systems (IS-ISs)", RFC 5120,
DOI 10.17487/RFC5120, February 2008,
<https://www.rfc-editor.org/info/rfc5120>.
[I-D.ietf-mpls-rfc4379bis] [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Kompella, K., Swallow, G., Pignataro, C., Kumar, N., Engineering", RFC 5305, DOI 10.17487/RFC5305, October
Aldrin, S., and M. Chen, "Detecting Multi-Protocol Label 2008, <https://www.rfc-editor.org/info/rfc5305>.
Switched (MPLS) Data Plane Failures", draft-ietf-mpls-
rfc4379bis-09 (work in progress), October 2016.
[I-D.ietf-mpls-rmr] [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
Kompella, K. and L. Contreras, "Resilient MPLS Rings", DOI 10.17487/RFC5308, October 2008,
2018. <https://www.rfc-editor.org/info/rfc5308>.
[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, <https://www.rfc-editor.org/info/rfc7684>.
[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, <https://www.rfc-editor.org/info/rfc7770>.
[RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions
for Advertising Router Information", RFC 7981,
DOI 10.17487/RFC7981, October 2016,
<https://www.rfc-editor.org/info/rfc7981>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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, <https://www.rfc-editor.org/info/rfc8402>.
9.2. Informative References
[I-D.ietf-teas-rsvp-rmr-extension] [I-D.ietf-teas-rsvp-rmr-extension]
Deshmukh, A. and K. Kompella, "RSVP Extensions for RMR", Deshmukh, A. and K. Kompella, "RSVP Extensions for RMR",
2018. draft-ietf-teas-rsvp-rmr-extension-01 (work in progress),
June 2018.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
<https://www.rfc-editor.org/info/rfc3209>. <https://www.rfc-editor.org/info/rfc3209>.
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <https://www.rfc-editor.org/info/rfc5036>.
Authors' Addresses Authors' Addresses
Kireeti Kompella Kireeti Kompella
Juniper Networks, Inc. Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
USA
Email: kireeti.kompella@gmail.com Email: kireeti.kompella@gmail.com
Abhishek Deshmukh Tarek Saad
Juniper Networks, Inc. Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
USA
Email: adeshmukh@juniper.net Email: tsaad@juniper.net
Ravi Torvi Abhishek Deshmukh
Juniper Networks, Inc. Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
USA
Email: rtorvi@juniper.net Email: adeshmukh@juniper.net
 End of changes. 63 change blocks. 
198 lines changed or deleted 567 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/