INTERNET-DRAFT Santosh Esale
Intended Status: Proposed Standard Kireeti Kompella
Expires: May 8, 2019 Juniper Networks
November 4, 2018
LDP Extensions for RMRdraft-ietf-mpls-ldp-rmr-extensions-01
Abstract
This document describes LDP extensions to signal Resilient MPLS Ring
(RMR) Label Switched Paths (LSPs). An RMR LSP is a multipoint to
point LSP signaled using LDP (Label Distribution Protocol). RMR
Architecture document - draft-ietf-mpls-rmr-02 - describes why and
how MPLS should be used in ring topologies.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Copyright and License Notice
Copyright (c) 2018 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
Esale, et al. Expires May 8, 2019 [Page 1]

INTERNET DRAFT LDP Extensions for RMR November 4, 20181 Introduction
This document describes LDP extensions to signal resilient MPLS ring
(RMR) label switched paths (LSPs). An RMR LSP is a multipoint to
point LSP signaled using LDP (Label Distribution Protocol).
Architecture document of RMR - draft-ietf-mpls-rmr-02 - describes why
and how MPLS should be used in ring topologies.
The ring is either auto-discovered or configured using IGP protocol
such as OSPF or ISIS. IGP extensions for RMR is described in a
companion documents. After the ring discovery, each ring node acting
as egress constructs and signals a clockwise (CW) and anti-clockwise
(AC) ring FEC towards AC and CW direction respectively. Each transit
node that receives the RMR FEC signals this LSP further in same
direction using RMR link state database. In addition, it also adds a
transit and ingress route for this LSP. Once the signaling is
complete, every node in a ring should have two counter rotating LSPs
in CW and AC direction to reach every other node on the ring.
2. Terminology
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 ring LSPs:
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.
Ring node: A member of a ring. Note that a device may belong to
several rings.
Node index: A logical numbering of nodes in a ring, from zero upto
one less than the ring size. Used purely for exposition in this
document.
Ring neighbors: Nodes whose indices differ by one (modulo ring
size).
Ring links: Links that connect ring neighbors.
Express links: Links that connect non-neighboring ring nodes.
Esale, et al. Expires May 8, 2019 [Page 3]

INTERNET DRAFT LDP Extensions for RMR November 4, 2018
MP2P LSP: Each LSP in the ring is a multipoint to point LSP such
that LSP can have multiple ingress nodes and one egress node.
3. Protocol extensions
This section describes LDP extensions to signal RMR LSP in a ring.
3.1. Ring LSP Capability
RMR LSPs support for a LSR is advertised using LDP capabilities as
defined in [RFC5561]. An implementation that supports the RMR
procedures specified in this document MUST add the procedures
pertaining to Capability Parameters for Initialization messages.
A new optional capability parameter TLV, RMR Capability, is defined.
Following is the format of the RMR Capability Parameter:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| RMR Capability (TBD) | Length (= 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S| Reserved |
+-+-+-+-+-+-+-+-+
As described in [RFC5561]
U: set to 1. Ignore, if not known.
F: Set to 0. Do not forward.
S: MUST be set to 1 to advertise the RMR Capability TLV.
The RMR Capability TLV MUST be advertised in the LDP Initialization
message. If the peer has not advertised the RMR capability, then
label messages pertaining to RMR FEC Element MUST NOT be sent to the
peer.
3.2. Ring FEC Element
In order to setup RMR LSP in clockwise and anti-clockwise direction
for every ring node, this document defines new protocol entity, the
RMR FEC Element, to be used as a FEC Element in the FEC TLV.
The RMR FEC Element consists of the ring address, ring identifier and
ring flags which depicts ring direction. The combination of ring
address, ring identifier and ring flags uniquely identifies a ring
Esale, et al. Expires May 8, 2019 [Page 4]

INTERNET DRAFT LDP Extensions for RMR November 4, 2018
path is R4 to reach R0 and that the label map arrived from router R4
for a anti-clockwise LSP. Therefore, R5 selects the upstream session
for this LSP as R6.
4.2 Ring Label Mapping Procedures
The procedures in the subsequent sections are organized by the role
that a node plays to establish a ring LSP. Each node is egress for
its own prefixes and transit for every prefix received with a Label
Mapping message. Every transit node is also a ingress for that LSP.
4.2.1 Definitions
This section defines the notations for initiation, decoding,
processing and propagation of RMR FEC Element.
1. RMR FEC Element <P, R, C> or <P, R, A>: a FEC Element with egress
prefix P, RID R and clockwise direction C or
anti-clockwise direction A.
2. RMR Label Mapping <P, R, C, L> or <P, R, A, L>: a Label Mapping
message with a FEC TLV with a single RMR FEC Element <P, R, C> or
<P, R, A> and Label TLV with label L. Label L MUST be allocated
from the per-platform label space of the LSR sending the Label
Mapping message. The use of the interface label space is outside
the scope of this document.
3. RMR Label Withdraw <P, R, C, L> or <P, R, A, L>: a Label Withdraw
message with a FEC TLV with a single RMR FEC Element <P, R, C> or
<P, R, A> and Label TLV with label L.
4. RMR LSP <P, R, C> or <P, R, A>: A RMR LSP with egress prefix P,
Ring ID R and clockwise direction C or anti-clockwise direction A.
4.2.2 Preliminary
A node X wishing to participate in LDP RMR signaling MUST negotiate
the RMR capability with all its neighbors. When the IGP informs X of
its RMR neighbors A and C for RID R, it MUST check that A and C have
also negotiated the RMR capability with X. If these conditions are
not satisfied, X cannot participate in signaling for ring R. This
applies for all roles that X may play: ingress, transit and egress.
4.2.3 Egress LSR
Every ring node initiates two counter-rotating LSPs that egress on
that node. After the IGP discovers the ring, LDP constructs the
clockwise RMR FEC <P, R, C> and sends it in a Label Mapping message
to anti-clockwise neighbor. Similarly, LDP constructs a anti-
clockwise RMR FEC <P, R, A> and sends it in a Label Mapping message
Esale, et al. Expires May 8, 2019 [Page 7]

INTERNET DRAFT LDP Extensions for RMR November 4, 2018
to clockwise neighbor. This SHOULD establish a clockwise and anti-
clockwise LSP - in terms of data traffic - in the clockwise and anti-
clockwise direction respectively.
Furthermore, if a label other than implicit or explicit null is
advertised for a LSP, LDP SHOULD add a pop route for this label in
the Incoming Label Map (ILM) MPLS table.
When the node is no longer part of the ring, it MUST tear down its
egress LSPs - CW and AC - by sending a label withdraw message.
4.2.4 Ingress and Transit LSR
When a transit LSR R5 depicted in figure 1 receives a label map
message with RMR FEC Element <R0, 17, A, L1> from a downstream LDP
session to R4, it SHOULD verify that R4 is indeed its anticlockwise
neighbor for ring 17. If not, it SHOULD stop decoding the FEC TLV,
abort processing the message containing the TLV, send an "Unknown
FEC" Notification message to its LDP peer R4 signaling an error and
close the session.
If the LSR encounters no other error while parsing the RMR FEC
element, it allocates a Label L2 and determines a upstream LDP
session as R6 using the algorithm described in section 'Upstream
LSR'. It also programs a MPLS ILM table with label route L2 swapped
to L1 and Ingress tunnel table with prefix R0 with label push L1 on
all the LDP interfaces to R4, and sends the RMR FEC Element <R0, 17,
A, L2> to R6.
If a session to the anti-clockwise neighbor for RID 17 depicted in
Figure 2, namely R6, does not exist, the RMR FEC Element <R0, 17, A,
L2> SHOULD NOT be propagated further. Similarly, when the upstream
session changes because of ring topology change, transit LSR should
send a label withdraw for RMR FEC Element <R0, 17, A, L2> to older
upstream session R6 before sending Label Mapping message with RMR FEC
Element <R0, 17, A, L2> to a new upstream session.
4.3 Equal Cost Multipath (ECMP)
A transit and ingress LSR of RMR LSP uses all the links between
itself and downstream LSR to program transit and ingress route. Thus,
ECMP works automatically for a LDP RMR LSP. A vendor could provide
exception when necessary to this behavior by disabling certain ring
links for RMR LSPs.
4.4 ProtectionEsale, et al. Expires May 8, 2019 [Page 8]

INTERNET DRAFT LDP Extensions for RMR November 4, 2018
An RMR LSP consists of two counter-rotating ring LSPs that start and
end at the same node, say R1. As such, this appears to cause a loop,
something that is normally to be avoided by LDP [RSVP-TE]. There are
some benefits to this. Having a ring LSP allows the anchor node R1
to ping itself and thus verify the end-to-end operation of the LSP.
This, in conjunction with link-level OAM, offers a good indication of
the operational state of the LSP. [Also, having R1 be the ingress
means that R1 can initiate the Path messages for the two ring LSPs.
This avoids R1 having to coordinate with its neighbors to signal the
LSPs, and simplifies the case where a ring update changes R1's ring
neighbors.] The cost of this is a little more signaling and a couple
more label entries in the LFIB.
Esale, et al. Expires May 8, 2019 [Page 10]