< draft-ietf-mpls-ldp-mrt-04.txt   draft-ietf-mpls-ldp-mrt-05.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 2, 2017 Juniper Networks Expires: August 21, 2017 Juniper Networks
J. Tantsura J. Tantsura
Individual Individual
IJ. Wijnands IJ. Wijnands
Cisco Systems, Inc. Cisco Systems, Inc.
September 29, 2016 February 17, 2017
LDP Extensions to Support Maximally Redundant Trees LDP Extensions to Support Maximally Redundant Trees
draft-ietf-mpls-ldp-mrt-04 draft-ietf-mpls-ldp-mrt-05
Abstract Abstract
This document specifies extensions to the Label Distribution This document specifies extensions to the Label Distribution
Protocol(LDP) to support the creation of label-switched paths for Protocol(LDP) to support the creation of label-switched paths for
Maximally Redundant Trees (MRT). A prime use of MRTs is for unicast Maximally Redundant Trees (MRT). A prime use of MRTs is for unicast
and multicast IP/LDP Fast-Reroute, which 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 (Label Switching Routers) and
Capability. LERs (Label Edge Routers) advertising the MRT 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 MPLS MT-ID different multi-topology IDs to be allocated from the MPLS MT-ID
space. space.
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 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 2, 2017. This Internet-Draft will expire on August 21, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 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
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
skipping to change at page 3, line 16 skipping to change at page 3, line 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 [RFC7812]. It is necessary to be LDP Fast-Reroute can use MRTs [RFC7812]. It is necessary to be
familiar with the architecture in [RFC7812] to understand how and why familiar with the architecture in [RFC7812] to understand how and why
the LDP extensions for behavior are needed. the LDP extensions for behavior are needed.
At least one common standardized algorithm (e.g. the MRT Lowpoint At least one common standardized algorithm (e.g. the MRT Lowpoint
algorithm explained and fully documented in [RFC7811]) is required so algorithm explained and fully documented in [RFC7811]) is required to
that the routers supporting MRT computation consistently compute the be deployed so that the routers supporting MRT computation
same MRTs. LDP depends on an IGP for computation of MRTs and consistently compute the same MRTs. LDP depends on an IGP for
alternates. Extensions to OSPF are defined in [I-D.ietf-ospf-mrt]. computation of MRTs and alternates. Extensions to OSPF are defined
Extension to IS-IS are defined in [I-D.ietf-isis-mrt]. in [I-D.ietf-ospf-mrt]. Extension to IS-IS are defined in
[I-D.ietf-isis-mrt].
MRT can also be used to protect multicast traffic (signalled via PIM MRT can also be used to protect multicast traffic (signalled via PIM
or mLDP) using either global protection or local protection or mLDP) using either global protection or local protection as
[I-D.atlas-rtgwg-mrt-mc-arch]. An MRT path can be used to provide described in [I-D.atlas-rtgwg-mrt-mc-arch]. An MRT path can be used
node-protection for mLDP traffic via the mechanisms described in to provide node-protection for mLDP traffic via the mechanisms
[I-D.wijnands-mpls-mldp-node-protection]; an MRT path can also be described in [I-D.wijnands-mpls-mldp-node-protection]; an MRT path
used to provide link protection for mLDP traffic. can also be used to provide link protection for mLDP traffic.
For each destination, IP/LDP Fast-Reroute with MRT (MRT-FRR) creates For each destination, IP/LDP Fast-Reroute with MRT (MRT-FRR) creates
two alternate destination-based trees separate from the shortest path two alternate destination-based trees separate from the shortest path
forwarding used during stable operation. LDP uses the multi-topology forwarding used during stable operation. LDP uses the multi-topology
extensions [RFC7307] to signal Forwarding Equivalency Classes (FECs) extensions [RFC7307] to signal Forwarding Equivalency Classes (FECs)
for these two sets of forwarding trees, MRT-Blue and MRT-Red. for these two sets of forwarding trees, MRT-Blue and MRT-Red.
In order to create MRT paths and support IP/LDP Fast-Reroute, a new In order to create MRT paths and support IP/LDP Fast-Reroute, a new
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
skipping to change at page 7, line 30 skipping to change at page 7, line 30
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
Rainbow MRT MT-ID with an IMPLICIT_NULL label to indicate Rainbow MRT MT-ID with an IMPLICIT_NULL label to indicate
penultimate-hop-popping for all three types of FECs (shortest path, penultimate-hop-popping for all three types of FECs (shortest path,
red, and blue). The EXPLICIT_NULL label advertised using the Rainbow red, and blue). The EXPLICIT_NULL label advertised using the Rainbow
MRT MT-ID similarly applies to all the types of FECs. Note that the MRT MT-ID similarly applies to all the types of FECs. Note that the
only scenario in which it is generally useful to advertise the only scenario in which it is generally useful to advertise the
implicit or explicit null label for all three FEC types is when the implicit or explicit null label for all three FEC types is when the
FEC refers to the LSR itself. See Section 5.2.3 for more details. FEC refers to the LSR itself. See Section 5.2.3 for more details.
The value of the Rainbow MRT MPLS MT-ID (TBD-MRT-LDP-3) will be The value of the Rainbow MRT MPLS MT-ID (TBD-MRT-LDP-3) will be
assigned by IANA from the MPLS MT-ID space. Prototype experiments assigned by IANA from the MPLS MT-ID space.
have used the value 3999.
4.3. MRT-Blue and MRT-Red FECs 4.3. MRT-Blue and MRT-Red FECs
To provide MRT support in LDP, the MT Prefix FEC is used. [RFC7812] To provide MRT support in LDP, the MT Prefix FEC is used. [RFC7812]
defines the Default MRT Profile. This document contains the IANA defines the Default MRT Profile. Section 8 of this document
request for the MRT-Red and MRT-Blue MPLS MT-IDs associated with the specifies code points for the MRT-Red and MRT-Blue MPLS MT-IDs
Default MRT Profile (TBD-MRT-LDP-4 and TBD-MRT-LDP-5). associated with the Default MRT Profile (TBD-MRT-LDP-4 and TBD-MRT-
LDP-5).
The MT Prefix FEC encoding is defined in [RFC7307] and is used The MT Prefix FEC encoding is defined in [RFC7307] and is used
without alteration for advertising label mappings for MRT-Blue, MRT- without alteration for advertising label mappings for MRT-Blue, MRT-
Red and Rainbow MRT FECs. Red and Rainbow MRT FECs.
5. LDP MRT FEC Advertisements 5. LDP MRT FEC Advertisements
This sections describes how and when labels for MRT-Red and MRT-Blue This sections describes how and when labels for MRT-Red and MRT-Blue
FECs are advertised. The associated LSPs must be created before a FECs are advertised. The associated LSPs must be created before a
failure occurs, in order to provide protection paths which are failure occurs, in order to provide protection paths which are
skipping to change at page 8, line 37 skipping to change at page 8, line 37
Blue forwarding trees for the destination. An LDP peer receiving Blue forwarding trees for the destination. An LDP peer receiving
these advertisements forwards MRT traffic to the ABR using these two these advertisements forwards MRT traffic to the ABR using these two
different labels, depending on the FEC of the traffic. We refer to different labels, depending on the FEC of the traffic. We refer to
this as best-area advertising and forwarding behavior, which is this as best-area advertising and forwarding behavior, which is
identical to normal MRT behavior. identical to normal MRT behavior.
For all other LDP peers supporting MRT, the ABR advertises a FEC- For all other LDP peers supporting MRT, the ABR advertises a FEC-
label binding for the Rainbow MRT MT-ID scoped FEC with the label label binding for the Rainbow MRT MT-ID scoped FEC with the label
corresponding to the default forwarding tree for the destination. An corresponding to the default forwarding tree for the destination. An
LDP peer receiving this advertisement forwards MRT traffic to the ABR LDP peer receiving this advertisement forwards MRT traffic to the ABR
using this label, for both MRT Red and MRT Blue traffic. We refer to using this label, for both MRT-Red and MRT-Blue traffic. We refer to
this as non-best-area advertising and forwarding behavior. this as non-best-area advertising and forwarding behavior.
The use of the Rainbow-FEC by the ABR for non-best-area The use of the Rainbow-FEC by the ABR for non-best-area
advertisements is RECOMMENDED. An ABR MAY advertise the label for advertisements is RECOMMENDED. An ABR MAY advertise the label for
the default topology in separate MRT-Blue and MRT-Red advertisements. the default topology in separate MRT-Blue and MRT-Red advertisements.
An LSR advertising the MRT capability MUST recognize the Rainbow MRT An LSR advertising the MRT capability MUST recognize the Rainbow MRT
MT-ID and associate the advertised label with the specific prefix MT-ID and associate the advertised label with the specific prefix
with the MRT-Red and MRT-Blue MT-IDs associated with all MRT Profiles with the MRT-Red and MRT-Blue MT-IDs associated with all MRT Profiles
that advertise LDP as the forwarding mechanism. that advertise LDP as the forwarding mechanism.
skipping to change at page 9, line 10 skipping to change at page 9, line 10
peer may need to transition from best-area advertising and forwarding peer may need to transition from best-area advertising and forwarding
behavior to non-best-area behavior for a given destination, and vice behavior to non-best-area behavior for a given destination, and vice
versa. When the ABR requires best-area behavior for a red(blue) FEC, versa. When the ABR requires best-area behavior for a red(blue) FEC,
it MUST withdraw any existing label mappings advertisements for the it MUST withdraw any existing label mappings advertisements for the
corresponding rainbow FEC and advertise label mappings for the corresponding rainbow FEC and advertise label mappings for the
red(blue) FEC. When the ABR requires non-best-area behavior for a red(blue) FEC. When the ABR requires non-best-area behavior for a
red(blue) FEC, it MUST withdraw any existing label mappings for both red(blue) FEC, it MUST withdraw any existing label mappings for both
red and blue FECs and advertise label mappings for the corresponding red and blue FECs and advertise label mappings for the corresponding
Rainbow FEC label binding. Rainbow FEC label binding.
If an LSR receives a label mapping advertisement for a rainbow FEC In this transition, an ABR should never advertise a red(blue) FEC
from an MRT LDP peer while it still retains a label mapping for the before withdrawing the corrsponding rainbow FEC (or vice versa).
However, should this situation occur, the expected behavior of an LSR
receiving these conflicting advertisements is defined as foll If an
LSR receives a label mapping advertisement for a rainbow FEC from an
MRT LDP peer while it still retains a label mapping for the
corresponding red or blue FEC, the LSR MUST continue to use the label corresponding red or blue FEC, the LSR MUST continue to use the label
mapping for the red or blue FEC, and it MUST send a Label Release mapping for the red or blue FEC, and it MUST send a Label Release
Message corresponding to the rainbow FEC label advertisement. If an Message corresponding to the rainbow FEC label advertisement. If an
LSR receives a label mapping advertisement for red or blue FEC while LSR receives a label mapping advertisement for red or blue FEC while
it still retains a label mapping for the corresponding rainbow FEC, it still retains a label mapping for the corresponding rainbow FEC,
the LSR MUST continue to use the label mapping for the rainbow FEC, the LSR MUST continue to use the label mapping for the rainbow FEC,
and it MUST send a Label Release Message corresponding to the red or and it MUST send a Label Release Message corresponding to the red or
blue FEC label advertisement. blue FEC label advertisement.
5.1.2. Proxy-node attachment router behavior 5.1.2. Proxy-node attachment router behavior
skipping to change at page 9, line 50 skipping to change at page 10, line 6
red and blue next-hops to reach those red and blue proxy-node red and blue next-hops to reach those red and blue proxy-node
attachment routers. attachment routers.
In terms of LDP behavior, a red proxy-node attachment router for a In terms of LDP behavior, a red proxy-node attachment router for a
given prefix MUST originate a label mapping for the red FEC for that given prefix MUST originate a label mapping for the red FEC for that
prefix, while the a blue proxy-node attachment router for a given prefix, while the a blue proxy-node attachment router for a given
prefix MUST originate a label mapping for the blue FEC for that prefix MUST originate a label mapping for the blue FEC for that
prefix. If the red(blue) proxy-node attachment router is an Island prefix. If the red(blue) proxy-node attachment router is an Island
Border Router (IBR), then when it receives a packet with the label Border Router (IBR), then when it receives a packet with the label
corresponding to the red(blue) FEC for a prefix, it MUST forward the corresponding to the red(blue) FEC for a prefix, it MUST forward the
packet to the Island Neighbor (IN) whose whose cost was used in the packet to the Island Neighbor (IN) whose cost was used in the
selection of the IBR as a proxy-node attachment router. The IBR MUST selection of the IBR as a proxy-node attachment router. The IBR MUST
swap the incoming label for the outgoing label corresponding to the swap the incoming label for the outgoing label corresponding to the
shortest path FEC for the prefix advertised by the IN. In the case shortest path FEC for the prefix advertised by the IN. In the case
where the IN does not support LDP, the IBR MUST pop the incoming where the IN does not support LDP, the IBR MUST pop the incoming
label and forward the packet to the IN. label and forward the packet to the IN.
If the proxy-node attachment router is not an IBR, then the packet If the proxy-node attachment router is not an IBR, then the packet
MUST be removed from the MRT forwarding topology and sent along the MUST be removed from the MRT forwarding topology and sent along the
interface(s) that caused the router to advertise the prefix. This interface(s) that caused the router to advertise the prefix. This
interface might be out of the area/level/AS. interface might be out of the area/level/AS.
skipping to change at page 15, line 41 skipping to change at page 15, line 41
0 Default/standard topology [RFC7307] 0 Default/standard topology [RFC7307]
1 IPv4 in-band management [RFC7307] 1 IPv4 in-band management [RFC7307]
2 IPv6 routing topology [RFC7307] 2 IPv6 routing topology [RFC7307]
3 IPv4 multicast topology [RFC7307] 3 IPv4 multicast topology [RFC7307]
4 IPv6 multicast topology [RFC7307] 4 IPv6 multicast topology [RFC7307]
5 IPv6 in-band management [RFC7307] 5 IPv6 in-band management [RFC7307]
6-3944 Unassigned (for future IGP topologies) 6-3944 Unassigned (for future IGP topologies)
TBD-MRT-LDP-3 Rainbow MRT MPLS MT-ID [This draft] TBD-MRT-LDP-3 Rainbow MRT MPLS MT-ID [This draft]
TBD-MRT-LDP-4 Default Profile MRT-Red MPLS MT-ID [This draft] TBD-MRT-LDP-4 Default Profile MRT-Red MPLS MT-ID [This draft]
TBD-MRT-LDP-5 Default Profile MRT-Blue MPLS MT-ID [This draft] TBD-MRT-LDP-5 Default Profile MRT-Blue MPLS MT-ID [This draft]
3948-3995 Unassigned (for future MRT-related values) 3948-3995 Unassigned (for future MRT-related values) [This draft]
3996-4095 Reserved for Experimental Use [RFC7307] 3996-4095 Reserved for Experimental Use [RFC7307]
4096-65534 Unassigned (for MPLS topologies) 4096-65534 Unassigned (for MPLS topologies)
65535 Wildcard Topology [RFC7307] 65535 Wildcard Topology [RFC7307]
9. Acknowledgements 9. Acknowledgements
The authors would like to thank Ross Callon, Loa Andersson, Stewart The authors would like to thank Ross Callon, Loa Andersson, Stewart
Bryant, Mach Chen, and Greg Mirsky for their suggestions. Bryant, Mach Chen, Greg Mirsky, and Uma Chunduri for their comments
and suggestions.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed.,
"LDP Specification", RFC 5036, DOI 10.17487/RFC5036, "LDP Specification", RFC 5036, DOI 10.17487/RFC5036,
October 2007, <http://www.rfc-editor.org/info/rfc5036>. October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL. [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
 End of changes. 15 change blocks. 
28 lines changed or deleted 34 lines changed or added

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