draft-ietf-mpls-rmr-06.txt   draft-ietf-mpls-rmr-07.txt 
MPLS WG K. Kompella MPLS WG K. Kompella
Internet-Draft Juniper Networks, Inc. Internet-Draft Juniper Networks, Inc.
Intended status: Standards Track L. Contreras Intended status: Standards Track L. Contreras
Expires: July 7, 2018 Telefonica Expires: September 5, 2018 Telefonica
January 3, 2018 March 4, 2018
Resilient MPLS Rings Resilient MPLS Rings
draft-ietf-mpls-rmr-06 draft-ietf-mpls-rmr-07
Abstract Abstract
This document describes the use of the MPLS control and data planes This document describes the use of the MPLS control and data planes
on ring topologies. It describes the special nature of rings, and on ring topologies. It describes the special nature of rings, and
proceeds to show how MPLS can be effectively used in such topologies. proceeds to show how MPLS can be effectively used in such topologies.
It describes how MPLS rings are configured, auto-discovered and It describes how MPLS rings are configured, auto-discovered and
signaled, as well as how the data plane works. Companion documents signaled, as well as how the data plane works. Companion documents
describe the details of discovery and signaling for specific describe the details of discovery and signaling for specific
protocols. protocols.
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 July 7, 2018. This Internet-Draft will expire on September 5, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
skipping to change at page 12, line 41 skipping to change at page 12, line 41
7. Advanced Topics 7. Advanced Topics
7.1. Half-rings 7.1. Half-rings
In some cases, a ring H may be incomplete, either because H is In some cases, a ring H may be incomplete, either because H is
permanently missing a link (not just because of a failure), or permanently missing a link (not just because of a failure), or
because the link required to complete H is in a different IGP area. because the link required to complete H is in a different IGP area.
Either way, the ring discovery algorithm will fail. We call such a Either way, the ring discovery algorithm will fail. We call such a
ring a "half-ring". Half-rings are sufficiently common that finding ring a "half-ring". Half-rings are sufficiently common that finding
a way to deal with them effectively is a useful problem to solve. a way to deal with them effectively is a useful problem to solve.
This topic will not be addressed in this document; that task is left
for a future document.
7.2. Hub Node Resilience 7.2. Hub Node Resilience
Let's call the node(s) that connect a ring to the rest of the network Let's call the node(s) that connect a ring to the rest of the network
"hub node(s)" (usually, there are a pair of hub nodes.) Suppose a "hub node(s)" (usually, there are a pair of hub nodes.) Suppose a
ring has two hub nodes H1 and H2. Suppose further that a non-hub ring has two hub nodes H1 and H2. Suppose further that a non-hub
ring node X wants to send traffic to some node Z outside the ring. ring node X wants to send traffic to some node Z outside the ring.
This could be done, say, by having targeted LDP (T-LDP) sessions from This could be done, say, by having targeted LDP (T-LDP) sessions from
H1 and H2 to X advertising LDP reachability to Z via H1 (H2); there H1 and H2 to X advertising LDP reachability to Z via H1 (H2); there
would be a two-label stack from X to reach Z. Say that to reach Z, X would be a two-label stack from X to reach Z. Say that to reach Z, X
prefers H1; thus, traffic from X to Z will first go to H1 via a ring prefers H1; thus, traffic from X to Z will first go to H1 via a ring
LSP, then to Z via LDP. LSP, then to Z via LDP.
If H1 fails, traffic from X to Z will drop until the T-LDP session If H1 fails, traffic from X to Z will drop until the T-LDP session
from H1 to Z fails, the IGP reconverges, and H2's label to Z is from H1 to Z fails, the IGP reconverges, and H2's label to Z is
chosen. Thereafter, traffic will go from X to H2 via a ring LSP, chosen. Thereafter, traffic will go from X to H2 via a ring LSP,
then to Z via LDP. However, this convergence could take a long time. then to Z via LDP. However, this convergence could take a long time.
Since this is a very common and important situation, it is again a Since this is a very common and important situation, it is again a
useful problem to solve. useful problem to solve. However, this topic too will not be
addressed in this document; that task is left for a future document.
8. Security Considerations 8. Security Considerations
It is not anticipated that either the notion of MPLS rings or the It is not anticipated that either the notion of MPLS rings or the
extensions to various protocols to support them will cause new extensions to various protocols to support them will cause new
security loopholes. As this document is updated, this section will security loopholes. As this document is updated, this section will
also be updated. also be updated.
9. Acknowledgments 9. Acknowledgments
 End of changes. 5 change blocks. 
5 lines changed or deleted 8 lines changed or added

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