draft-ietf-mpls-rmr-04.txt   draft-ietf-mpls-rmr-05.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: September 12, 2017 Telefonica Expires: January 3, 2018 Telefonica
March 11, 2017 July 2, 2017
Resilient MPLS Rings Resilient MPLS Rings
draft-ietf-mpls-rmr-04 draft-ietf-mpls-rmr-05
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 September 12, 2017. This Internet-Draft will expire on January 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 2, line 37 skipping to change at page 2, line 37
3.6. Installing FRR LFIB Entries . . . . . . . . . . . . . . . 7 3.6. Installing FRR LFIB Entries . . . . . . . . . . . . . . . 7
3.7. Protection . . . . . . . . . . . . . . . . . . . . . . . 8 3.7. Protection . . . . . . . . . . . . . . . . . . . . . . . 8
4. Autodiscovery . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Autodiscovery . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Ring Announcement Phase . . . . . . . . . . . . . . . . . 10 4.2. Ring Announcement Phase . . . . . . . . . . . . . . . . . 10
4.3. Mastership Phase . . . . . . . . . . . . . . . . . . . . 10 4.3. Mastership Phase . . . . . . . . . . . . . . . . . . . . 10
4.4. Ring Identification Phase . . . . . . . . . . . . . . . . 11 4.4. Ring Identification Phase . . . . . . . . . . . . . . . . 11
4.5. Ring Changes . . . . . . . . . . . . . . . . . . . . . . 11 4.5. Ring Changes . . . . . . . . . . . . . . . . . . . . . . 11
5. Ring Signaling . . . . . . . . . . . . . . . . . . . . . . . 12 5. Ring Signaling . . . . . . . . . . . . . . . . . . . . . . . 12
6. Ring OAM . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Ring OAM . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Advanced Topics . . . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Half-rings . . . . . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7.2. Hub Node Resilience . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 13 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
Rings are a very common topology in transport networks. A ring is Rings are a very common topology in transport networks. A ring is
the simplest topology offering link and node resilience. Rings are the simplest topology offering link and node resilience. Rings are
nearly ubiquitous in access and aggregation networks. As MPLS nearly ubiquitous in access and aggregation networks. As MPLS
increases its presence in such networks, and takes on a greater role increases its presence in such networks, and takes on a greater role
in transport, it is imperative that MPLS handles rings well; this is in transport, it is imperative that MPLS handles rings well; this is
not the case today. not the case today.
skipping to change at page 12, line 31 skipping to change at page 12, line 31
Each ring node should advertise in its ring node TLV the OAM Each ring node should advertise in its ring node TLV the OAM
protocols it supports. Each ring node is expected to run a link- protocols it supports. Each ring node is expected to run a link-
level OAM over each ring link. This should be an OAM protocol that level OAM over each ring link. This should be an OAM protocol that
both neighbors agree on. The default hello time is 3.3 millisecond. both neighbors agree on. The default hello time is 3.3 millisecond.
Each ring node also sends OAM messages over each direction of its Each ring node also sends OAM messages over each direction of its
ring LSP. This is a multi-hop OAM to check LSP liveness; typically, ring LSP. This is a multi-hop OAM to check LSP liveness; typically,
BFD would be used for this. The node chooses the hello interval; the BFD would be used for this. The node chooses the hello interval; the
default is once a second. default is once a second.
7. Security Considerations 7. Advanced Topics
7.1. Half-rings
In some cases, a ring H may be incomplete, either because H is
permanently missing a link (not just because of a failure), or
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
ring a "half-ring". Half-rings are sufficiently common that finding
a way to deal with them effectively is a useful problem to solve.
7.2. Hub Node Resilience
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
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.
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
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
LSP, then to Z via LDP.
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
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.
Since this is a very common and important situation, it is again a
useful problem to solve.
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.
8. Acknowledgments 9. Acknowledgments
Many thanks to Pierre Bichon whose exemplar of self-organizing Many thanks to Pierre Bichon whose exemplar of self-organizing
networks and whose urging for ever simpler provisioning led to the networks and whose urging for ever simpler provisioning led to the
notion of promiscuous nodes. notion of promiscuous nodes.
9. IANA Considerations 10. IANA Considerations
There are no requests as yet to IANA for this document. There are no requests as yet to IANA for this document.
10. References 11. References
10.1. Normative References 11.1. Normative References
[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,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
10.2. Informative References 11.2. Informative References
[I-D.ietf-mpls-rfc4379bis] [I-D.ietf-mpls-rfc4379bis]
Kompella, K., Swallow, G., Pignataro, C., Kumar, N., Kompella, K., Swallow, G., Pignataro, C., Kumar, N.,
Aldrin, S., and M. Chen, "Detecting Multi-Protocol Label Aldrin, S., and M. Chen, "Detecting Multi-Protocol Label
Switched (MPLS) Data Plane Failures", draft-ietf-mpls- Switched (MPLS) Data Plane Failures", draft-ietf-mpls-
rfc4379bis-09 (work in progress), October 2016. rfc4379bis-09 (work in progress), October 2016.
[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,
 End of changes. 10 change blocks. 
17 lines changed or deleted 50 lines changed or added

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