draft-atlas-mpls-ldp-mrt-02.txt   draft-atlas-mpls-ldp-mrt-03.txt 
MPLS Working Group A. Atlas MPLS Working Group A. Atlas
Internet-Draft K. Tiruveedhula Internet-Draft K. Tiruveedhula
Intended status: Standards Track C. Bowers Intended status: Standards Track C. Bowers
Expires: April 30, 2015 Juniper Networks Expires: June 18, 2015 Juniper Networks
J. Tantsura J. Tantsura
Ericsson Ericsson
IJ. Wijnands IJ. Wijnands
Cisco Systems, Inc. Cisco Systems, Inc.
October 27, 2014 December 15, 2014
LDP Extensions to Support Maximally Redundant Trees LDP Extensions to Support Maximally Redundant Trees
draft-atlas-mpls-ldp-mrt-02 draft-atlas-mpls-ldp-mrt-03
Abstract Abstract
This document specifies extensions to LDP to support the creation of This document specifies extensions to the Label Distribution
label-switched paths for Maximally Redundant Trees (MRT). A prime Protocol(LDP) to support the creation of label-switched paths for
use of MRTs is for unicast and multicast IP/LDP Fast-Reroute, which Maximally Redundant Trees (MRT). A prime use of MRTs is for unicast
we will refer to as MRT-FRR. and multicast IP/LDP Fast-Reroute, which we will refer to as MRT-FRR.
The sole protocol extension to LDP is simply the ability to advertise The sole protocol extension to LDP is simply the ability to advertise
an MRT Capability. This document describes that extension and the an MRT Capability. This document describes that extension and the
associated behavior expected for LSRs and LERs advertising the MRT associated behavior expected for LSRs and LERs advertising the MRT
Capability. Capability.
MRT-FRR uses LDP multi-topology extensions and requires three MRT-FRR uses LDP multi-topology extensions and requires three
different multi-topology IDs to be allocated from the LDP MT-ID different multi-topology IDs to be allocated from the LDP MT-ID
space. space.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
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 April 30, 2015. This Internet-Draft will expire on June 18, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 27 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview of LDP Signaling Extensions for MRT . . . . . . . . 5 4. Overview of LDP Signaling Extensions for MRT . . . . . . . . 5
4.1. MRT Capability Advertisement . . . . . . . . . . . . . . 5 4.1. MRT Capability Advertisement . . . . . . . . . . . . . . 5
4.1.1. Interaction of LDP MRT Capability with IPv4 and IPv6 6 4.1.1. Interaction of MRT Capability and MT Capability . . . 6
4.1.2. Interaction of LDP MRT Capability with IPv4 and IPv6 6
4.2. Use of the Rainbow MRT MT-ID . . . . . . . . . . . . . . 7 4.2. Use of the Rainbow MRT MT-ID . . . . . . . . . . . . . . 7
4.3. MRT-Blue and MRT-Red FECs . . . . . . . . . . . . . . . . 7 4.3. MRT-Blue and MRT-Red FECs . . . . . . . . . . . . . . . . 7
5. LDP MRT FEC Advertisements . . . . . . . . . . . . . . . . . 7 5. LDP MRT FEC Advertisements . . . . . . . . . . . . . . . . . 7
5.1. MRT-specific behavior . . . . . . . . . . . . . . . . . . 8 5.1. MRT-specific behavior . . . . . . . . . . . . . . . . . . 8
5.1.1. ABR behavior and use of the Rainbow FEC . . . . . . . 8 5.1.1. ABR behavior and use of the Rainbow FEC . . . . . . . 8
5.1.2. Proxy-node attachment router behavior . . . . . . . . 9 5.1.2. Proxy-node attachment router behavior . . . . . . . . 9
5.2. LDP protocol procedures in the context of MRT label 5.2. LDP protocol procedures in the context of MRT label
distribution . . . . . . . . . . . . . . . . . . . . . . 10 distribution . . . . . . . . . . . . . . . . . . . . . . 10
5.2.1. LDP peer in RFC5036 . . . . . . . . . . . . . . . . . 10 5.2.1. LDP peer in RFC5036 . . . . . . . . . . . . . . . . . 10
5.2.2. Next hop in RFC5036 . . . . . . . . . . . . . . . . . 10 5.2.2. Next hop in RFC5036 . . . . . . . . . . . . . . . . . 10
skipping to change at page 2, line 50 skipping to change at page 2, line 51
requirements in RFC5036 . . . . . . . . . . . . . . . 12 requirements in RFC5036 . . . . . . . . . . . . . . . 12
5.2.5. Validating FECs in routing table . . . . . . . . . . 13 5.2.5. Validating FECs in routing table . . . . . . . . . . 13
5.2.6. Recognizing new FECs . . . . . . . . . . . . . . . . 13 5.2.6. Recognizing new FECs . . . . . . . . . . . . . . . . 13
5.2.7. Not propagating Rainbow FEC label mappings . . . . . 13 5.2.7. Not propagating Rainbow FEC label mappings . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
This document describes the LDP signaling extension and associated This document describes the LDP signaling extension and associated
behavior necessary to support the architecture that defines how IP/ behavior necessary to support the architecture that defines how IP/
LDP Fast-Reroute can use MRTs [I-D.ietf-rtgwg-mrt-frr-architecture]. LDP Fast-Reroute can use MRTs [I-D.ietf-rtgwg-mrt-frr-architecture].
It is necessary to be familiar with the architecture in It is necessary to be familiar with the architecture in
[I-D.ietf-rtgwg-mrt-frr-architecture] to understand how and why the [I-D.ietf-rtgwg-mrt-frr-architecture] to understand how and why the
LDP extensions for behavior are needed. LDP extensions for behavior are needed.
skipping to change at page 3, line 46 skipping to change at page 3, line 46
capability extension is needed for LDP. An LDP implementation capability extension is needed for LDP. An LDP implementation
supporting MRT MUST also follow the rules described here for supporting MRT MUST also follow the rules described here for
originating and managing FECs related to MRT, as indicated by their originating and managing FECs related to MRT, as indicated by their
multi-topology ID. Network reconvergence is described in multi-topology ID. Network reconvergence is described in
[I-D.ietf-rtgwg-mrt-frr-architecture] and the worst-case network [I-D.ietf-rtgwg-mrt-frr-architecture] and the worst-case network
convergence time can be flooded via the extension in Section 7 of convergence time can be flooded via the extension in Section 7 of
[I-D.atlas-ospf-mrt]. [I-D.atlas-ospf-mrt].
IP/LDP Fast-Reroute using MRTs can provide 100% coverage for link and IP/LDP Fast-Reroute using MRTs can provide 100% coverage for link and
node failures in an arbitrary network topology where the failure node failures in an arbitrary network topology where the failure
doesn't split the network. It can also be deployed incrementally; an doesn't partition the network. It can also be deployed
MRT Island is formed of connected supporting routers and the MRTs are incrementally; an MRT Island is formed of connected supporting
computed inside that island. routers and the MRTs are computed inside that island.
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] document are to be interpreted as described in [RFC2119]
3. Terminology 3. Terminology
For ease of reading, some of the terminology defined in For ease of reading, some of the terminology defined in
skipping to change at page 5, line 14 skipping to change at page 5, line 14
Island Border Router (IBR): A router in the MRT Island that is Island Border Router (IBR): A router in the MRT Island that is
connected to a router not in the MRT Island and both routers are connected to a router not in the MRT Island and both routers are
in a common area or level. in a common area or level.
Island Neighbor (IN): A router that is not in the MRT Island but is Island Neighbor (IN): A router that is not in the MRT Island but is
adjacent to an IBR and in the same area/level as the IBR.. adjacent to an IBR and in the same area/level as the IBR..
4. Overview of LDP Signaling Extensions for MRT 4. Overview of LDP Signaling Extensions for MRT
Routers need to know which of their neighbors support MRT. Routers need to know which of their LDP neighbors support MRT. This
Supporting MRT indicates several different aspects of behavior, as is communicated using the MRT Capability Advertisement. Supporting
listed below. MRT indicates several different aspects of behavior, as listed below.
1. Support for Multi-Topology (MT) - this MAY also be indicated via 1. Sending and receiving multi-topology FEC elements, as defined in
the Multi-Topology LDP Capability [RFC7307]. [RFC7307].
2. Understand the Rainbow MRT MT-ID and apply the associated labels 2. Understanding the Rainbow MRT MT-ID and applying the associated
to all relevant MT-IDs. labels to all relevant MT-IDs.
3. Advertise the Rainbow MRT MT-ID to the appropriate neighbors for 3. Advertising the Rainbow MRT FEC to the appropriate neighbors for
the associated prefix. the appropriate prefix.
4. If acting as LDP egress for a prefix in the default topology, 4. If acting as LDP egress for a prefix in the default topology,
also advertise and act as egress for the same prefix in MRT-Red also acting as egress for the same prefix in MRT-Red and MRT-
and MRT-Blue. Blue.
5. For a FEC learned from a neighbor that does not support MRT, 5. For a FEC learned from a neighbor that does not support MRT,
originate FECS for MRT-Red and MRT-Blue with the same prefix. originating FECs for MRT-Red and MRT-Blue with the same prefix.
This MRT Island egress behavior is to support an MRT Island that This MRT Island egress behavior is to support an MRT Island that
does not include all routers in the area/level. does not include all routers in the area/level.
4.1. MRT Capability Advertisement 4.1. MRT Capability Advertisement
It is not possible to support MRT without supporting the LDP multi-
topology extensions, but it is possible that the only use of the
multi-topology extensions is for MRT. In that case, a router MAY not
negotiate the multi-topology capability and only negotiate the MRT
Capability with its LDP peers. Negotiation of the multi-topology
capability is not required with negotiation of the MRT capability.
A new MRT Capability Parameter TLV is defined in accordance with LDP A new MRT Capability Parameter TLV is defined in accordance with LDP
Capability definition guidelines[RFC5561]. Capability definition guidelines[RFC5561].
The LDP MRT capability can be advertised during LDP session The LDP MRT capability can be advertised during LDP session
initialization or after the LDP session is established. initialization or after the LDP session is established.
Advertisement of the MRT capability indicates support of the Advertisement of the MRT capability indicates support of the
procedures for establishing the MRT-Blue and MRT-Red LSP paths procedures for establishing the MRT-Blue and MRT-Red LSP paths
detailed in this document. If the peer has not advertised the MRT detailed in this document. If the peer has not advertised the MRT
capability, then it indicates that LSR does not support MRT capability, then it indicates that LSR does not support MRT
procedures. procedures.
skipping to change at page 6, line 42 skipping to change at page 6, line 36
MRT Capability: TBA-MRT-LDP-1 (To Be Allocated by IANA) MRT Capability: TBA-MRT-LDP-1 (To Be Allocated by IANA)
Length: The length (in octets) of TLV. Its value is 1. Length: The length (in octets) of TLV. Its value is 1.
S-bit: The State bit MUST be 1 if used in LDP "Initialization" S-bit: The State bit MUST be 1 if used in LDP "Initialization"
message. MAY be set to 0 or 1 in dynamic "Capability" message to message. MAY be set to 0 or 1 in dynamic "Capability" message to
advertise or withdraw the capability respectively, as described in advertise or withdraw the capability respectively, as described in
[RFC5561]. [RFC5561].
4.1.1. Interaction of LDP MRT Capability with IPv4 and IPv6 4.1.1. Interaction of MRT Capability and MT Capability
An LSR which advertises the MRT LDP capability is expected to An LSR advertising the LDP MRT Capability MUST also advertise the LDP
advertise MRT-related FEC-label bindings for both IPv4 and IPv6 Multi-topology (MT) capability. If an LSR negotiates LDP MRT
address families, if the LSR originates shortest-path FEC-label Capability with an LDP neighbor without also negotiating the LDP MT
bindings for those address families. Capability, the LSR MUST behave as if LDP MRT Capability has not been
negotiated and respond with the "MRT Capability negotiated without MT
Capability" status code in the LDP Notification message (defined in
the document). The E-bit of this Notification should be set to 0 to
indicate that this is an Advisory Notification. The LDP session
SHOULD NOT be terminated.
4.1.2. Interaction of LDP MRT Capability with IPv4 and IPv6
The MRT LDP Capability Advertisement does not distinguish between
IPv4 and IPv6 address families. An LSR which advertises the MRT LDP
capability is expected to advertise MRT-related FEC-label bindings
for the same address families for which it advertises shortest-path
FEC-label bindings. Therefore, an LSR advertising MRT LDP capability
and shortest path FEC-label bindings for IPv4 only (or IPv6 only)
would be expected to advertise MRT-related FEC-label binding for IPv4
only (or IPv6 only). An LSR advertising the MRT LDP capability and
shortest-path FEC label bindings for BOTH IPv4 and IPv6 is expected
to advertise MRT-related FEC-label bindings for BOTH IPv4 and IPv6.
In this scenario, advertising MRT-related FEC-label bindings only for
IPv4 only (or only for IPv6) is not supported.
4.2. Use of the Rainbow MRT MT-ID 4.2. Use of the Rainbow MRT MT-ID
Section 10.1 of [I-D.ietf-rtgwg-mrt-frr-architecture] describes the Section 10.1 of [I-D.ietf-rtgwg-mrt-frr-architecture] describes the
need for an area border router (ABR) to have different neighbors use need for an area border router (ABR) to have different neighbors use
different MPLS labels when sending traffic to the ABR for the same different MPLS labels when sending traffic to the ABR for the same
FEC. More detailed discussion of the Rainbow MRT MT-ID is provided FEC. More detailed discussion of the Rainbow MRT MT-ID is provided
in Section 5.1.1. in Section 5.1.1.
Another use for the Rainbow MRT MT-ID is for an LSR to send the Another use for the Rainbow MRT MT-ID is for an LSR to send the
skipping to change at page 14, line 15 skipping to change at page 14, line 21
7. IANA Considerations 7. IANA Considerations
IANA is requested to allocate a value for the new LDP Capability TLV IANA is requested to allocate a value for the new LDP Capability TLV
(the first free value in the range 0x0500 to 0x05FF) from the LDP (the first free value in the range 0x0500 to 0x05FF) from the LDP
registry "TLV Type Name Space": MRT Capability TLV (TBA-MRT-LDP-1). registry "TLV Type Name Space": MRT Capability TLV (TBA-MRT-LDP-1).
Value Description Reference Notes / Reg. Date Value Description Reference Notes / Reg. Date
------------- ------------------ ------------ ----------------- ------------- ------------------ ------------ -----------------
TBA-MRT-LDP-1 MRT Capability TLV [This draft] TBA-MRT-LDP-1 MRT Capability TLV [This draft]
IANA is requested to allocate a value for the new LDP Status Code
(the first free value in the range 0x00000032-0x00000036) from the
LDP registry "Status Code Name Space": "MRT Capability negotiated
without MT Capability" (TBA-MRT-LDP-3).
Value E Description Reference Notes / Reg. Date
------------- - ------------------------- --------- -----------------
TBA-MRT-LDP-3 0 MRT Capability negotiated [This draft]
without MT Capability
IANA is requested to allocate a value from the MPLS Multi-Topology IANA is requested to allocate a value from the MPLS Multi-Topology
Identifiers Name Space [RFC7307]: Rainbow MRT MT-ID (TBA-MRT-LDP-2). Identifiers Name Space [RFC7307]: Rainbow MRT MT-ID (TBA-MRT-LDP-2).
Value Purpose Reference Value Purpose Reference
------------- ------------------ ------------ ------------- ------------------ ------------
TBA-MRT-LDP-2 Rainbow MRT MT-ID [This draft] TBA-MRT-LDP-2 Rainbow MRT MT-ID [This draft]
8. Acknowledgements 8. Acknowledgements
The authors would like to thank Ross Callon and Loa Andersson for The authors would like to thank Ross Callon, Loa Andersson, Stewart
their suggestions. Bryant, Mach Chen, and Greg Mirsky for their suggestions.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-rtgwg-mrt-frr-algorithm] [I-D.ietf-rtgwg-mrt-frr-algorithm]
Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A. Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A.
Gopalan, "Algorithms for computing Maximally Redundant Gopalan, "Algorithms for computing Maximally Redundant
Trees for IP/LDP Fast-Reroute", draft-rtgwg-mrt-frr- Trees for IP/LDP Fast-Reroute", draft-rtgwg-mrt-frr-
algorithm-01 (work in progress), July 2014. algorithm-01 (work in progress), July 2014.
 End of changes. 19 change blocks. 
39 lines changed or deleted 63 lines changed or added

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