draft-ietf-mpls-ldp-mrt-06.txt   draft-ietf-mpls-ldp-mrt-07.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: February 18, 2018 Juniper Networks Expires: May 19, 2018 Juniper Networks
J. Tantsura J. Tantsura
Individual Individual
IJ. Wijnands IJ. Wijnands
Cisco Systems, Inc. Cisco Systems, Inc.
August 17, 2017 November 15, 2017
LDP Extensions to Support Maximally Redundant Trees LDP Extensions to Support Maximally Redundant Trees
draft-ietf-mpls-ldp-mrt-06 draft-ietf-mpls-ldp-mrt-07
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
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 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 February 18, 2018. This Internet-Draft will expire on May 19, 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 (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
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
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 MRT Capability and MT Capability . . . 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.1.2. Interaction of LDP MRT Capability with IPv4 and IPv6 7
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
4.4. Interaction of MRT-related LDP advertisements with the 4.4. Interaction of MRT-related LDP advertisements with the
MRT topology and computations . . . . . . . . . . . . . . 8 MRT topology and computations . . . . . . . . . . . . . . 8
5. LDP MRT FEC Advertisements . . . . . . . . . . . . . . . . . 8 5. LDP MRT FEC Advertisements . . . . . . . . . . . . . . . . . 8
5.1. MRT-specific behavior . . . . . . . . . . . . . . . . . . 9 5.1. MRT-specific behavior . . . . . . . . . . . . . . . . . . 9
5.1.1. ABR behavior and use of the Rainbow FEC . . . . . . . 9 5.1.1. ABR behavior and use of the Rainbow FEC . . . . . . . 9
5.1.2. Proxy-node attachment router behavior . . . . . . . . 10 5.1.2. Proxy-node attachment router behavior . . . . . . . . 10
5.2. LDP protocol procedures in the context of MRT label 5.2. LDP protocol procedures in the context of MRT label
distribution . . . . . . . . . . . . . . . . . . . . . . 11 distribution . . . . . . . . . . . . . . . . . . . . . . 11
5.2.1. LDP peer in RFC5036 . . . . . . . . . . . . . . . . . 11 5.2.1. LDP peer in RFC 5036 . . . . . . . . . . . . . . . . 11
5.2.2. Next hop in RFC5036 . . . . . . . . . . . . . . . . . 11 5.2.2. Next hop in RFC 5036 . . . . . . . . . . . . . . . . 12
5.2.3. Egress LSR in RFC5036 . . . . . . . . . . . . . . . . 12 5.2.3. Egress LSR in RFC 5036 . . . . . . . . . . . . . . . 12
5.2.4. Use of Rainbow FEC to satisfy label mapping existence 5.2.4. Use of Rainbow FEC to satisfy label mapping existence
requirements in RFC5036 . . . . . . . . . . . . . . . 13 requirements in RFC 5036 . . . . . . . . . . . . . . 14
5.2.5. Validating FECs in routing table . . . . . . . . . . 14 5.2.5. Validating FECs in routing table . . . . . . . . . . 14
5.2.6. Recognizing new FECs . . . . . . . . . . . . . . . . 14 5.2.6. Recognizing new FECs . . . . . . . . . . . . . . . . 14
5.2.7. Not propagating Rainbow FEC label mappings . . . . . 14 5.2.7. Not propagating Rainbow FEC label mappings . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. Potential restrictions on MRT-related MT-ID values imposed 7. Potential restrictions on MRT-related MT-ID values imposed
by RFC6420 . . . . . . . . . . . . . . . . . . . . . . . . . 15 by RFC 6420 . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. Normative References . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . 17
10.2. Informative References . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
This document describes the LDP signaling extension and associated This document describes the LDP signaling extensions 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]. The current document
familiar with the architecture in [RFC7812] to understand how and why provides a brief description of the MRT-FRR architecture, focusing on
the LDP extensions for behavior are needed. the aspects most directly related to LDP signaling. The complete
description and specification of the MRT-FRR architecture can be
found in [RFC7812].
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 to algorithm explained and fully documented in [RFC7811]) is required to
be deployed so that the routers supporting MRT computation be deployed so that the routers supporting MRT computation
consistently compute the same MRTs. LDP depends on an IGP for consistently compute the same MRTs. LDP depends on an IGP for
computation of MRTs and alternates. Extensions to OSPF are defined computation of MRTs and alternates. Extensions to OSPF are defined
in [I-D.ietf-ospf-mrt]. Extension to IS-IS are defined in in [I-D.ietf-ospf-mrt]. Extensions to IS-IS are defined in
[I-D.ietf-isis-mrt]. [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 as or mLDP) using either global protection or local protection as
described in [I-D.atlas-rtgwg-mrt-mc-arch]. An MRT path can be used described in [I-D.atlas-rtgwg-mrt-mc-arch]. An MRT path can be used
to provide node-protection for mLDP traffic via the mechanisms to provide node-protection for mLDP traffic via the mechanisms
described in [I-D.wijnands-mpls-mldp-node-protection]; an MRT path described in [RFC7715]; an MRT path can also be used to provide link
can also be used to provide link protection for mLDP traffic. 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 4, line 49 skipping to change at page 4, line 49
Rainbow MRT: It is useful to have an MPLS MT-ID that refers to the Rainbow MRT: It is useful to have an MPLS MT-ID that refers to the
multiple MRT forwarding topologies and to the default forwarding multiple MRT forwarding topologies and to the default forwarding
topology. This is referred to as the Rainbow MRT MPLS MT-ID and topology. This is referred to as the Rainbow MRT MPLS MT-ID and
is used by LDP to reduce signaling and permit the same label to is used by LDP to reduce signaling and permit the same label to
always be advertised to all peers for the same (MT-ID, Prefix). always be advertised to all peers for the same (MT-ID, Prefix).
MRT Island: The set of routers that support a particular MRT MRT Island: The set of routers that support a particular MRT
profile and the links connecting them that support MRT. profile and the links connecting them that support MRT.
Island Border Router (IBR): A router that is not in the MRT Island Island Border Router (IBR): A router in the MRT Island that is
but is adjacent to an IBR and in the same area/level as the IBR. connected to a router not in the MRT Island, both of which are 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..
There are several places in this document where the construction
"red(blue) FEC" is used to cover the case of the red FEC and the case
of the blue FEC, independently. As an example, consider the sentence
"When the ABR requires best-area behavior for a red(blue) FEC, it
MUST withdraw any existing label mappings advertisements for the
corresponding rainbow FEC and advertise label mappings for the
red(blue) FEC." This sentence should be read as applying to red
FECs. Then it should be read as applying to blue FECs.
4. Overview of LDP Signaling Extensions for MRT 4. Overview of LDP Signaling Extensions for MRT
Routers need to know which of their LDP neighbors support MRT. This Routers need to know which of their LDP neighbors support MRT. This
is communicated using the MRT Capability Advertisement. Supporting is communicated using the MRT Capability Advertisement. Supporting
MRT indicates several different aspects of behavior, as listed below. MRT indicates several different aspects of behavior, as listed below.
1. Sending and receiving multi-topology FEC elements, as defined in 1. Sending and receiving multi-topology FEC elements, as defined in
[RFC7307]. [RFC7307].
2. Understanding the Rainbow MRT MT-ID and applying the associated 2. Understanding the Rainbow MRT MT-ID and applying the associated
skipping to change at page 8, line 10 skipping to change at page 8, line 14
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.
4.4. Interaction of MRT-related LDP advertisements with the MRT 4.4. Interaction of MRT-related LDP advertisements with the MRT
topology and computations topology and computations
[RFC7811] and [RFC7812] describe how the MRT topology is created [RFC7811] and [RFC7812] describe how the MRT topology is created
based on information in IGP advertisements. The MRT topology and based on information in IGP advertisements. The MRT topology and
computations rely on on IGP advertisements. The presence or absence computations rely on IGP advertisements. The presence or absence of
of MRT-related LDP advertisements does not affect the MRT topology or MRT-related LDP advertisements does not affect the MRT topology or
the MRT-Red and MRT-Blue next-hops computed for that topology. the MRT-Red and MRT-Blue next-hops computed for that topology.
As an example, consider a network where all nodes are running MRT IGP As an example, consider a network where all nodes are running MRT IGP
extensions to determine the MRT-topology, which is then used to extensions to determine the MRT-topology, which is then used to
compute MRT-Red and MRT-Blue next-hops. The network operator also compute MRT-Red and MRT-Blue next-hops. The network operator also
configures the nodes in this network to exchange MRT-related LDP configures the nodes in this network to exchange MRT-related LDP
advertisements in order to distribute MPLS labels corresponding to advertisements in order to distribute MPLS labels corresponding to
those MRT next-hops. Suppose that, due to a misconfiguration on one those MRT next-hops. Suppose that, due to a misconfiguration on one
particular link, the MRT-related LDP advertisements are not being particular link, the MRT-related LDP advertisements are not being
properly exchanged for that link. Since the MRT-related IGP properly exchanged for that link. Since the MRT-related IGP
advertisements for the link are still being distributed, the link is advertisements for the link are still being distributed, the link is
still included in the MRT topology and computations, In this still included in the MRT topology and computations. In this
scenario, there will be missing MPLS forwarding entries corresponding scenario, there will be missing MPLS forwarding entries corresponding
to paths that use the misconfigured link. to paths that use the misconfigured link.
Note that the situation is analogous to the interaction of normal LDP Note that the situation is analogous to the interaction of normal LDP
advertisements and IGP advertisements for shortest path forwarding. advertisements and IGP advertisements for shortest path forwarding.
Deactivating the distribution of labels for normal shortest path FECs Deactivating the distribution of labels for normal shortest path FECs
on a link does not change the topology on which the SPF algorithm is on a link does not change the topology on which the SPF algorithm is
run by the IGP. run by the IGP.
[RFC5443] "LDP IGP Synchronization" addresses the issue of the LDP
topology not matching the IGP topology by the advertising the maximum
IGP cost on links where LDP is not fully operational. This makes the
IGP topology match the LDP topology. As described in Section 7.3.1
of [RFC7812], MRT is designed to be compatible with the LDP IGP
synchronization mechanism. When the IGP advertises the maximum cost
on a link where LDP is not fully operational, the link is excluded
from MRT Island formation, which prevents the MRT algorithm from
creating any paths using that link.
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. In order to provide protection paths which are
failure occurs, in order to provide protection paths which are
immediately usable by the point of local repair in the event of a immediately usable by the point of local repair in the event of a
failure. failure, the associated LSPs need to be created before a failure
occurs.
In this section, we will use the term "shortest path FEC" to refer to In this section, we will use the term "shortest path FEC" to refer to
the usual FEC associated with the shortest path destination-based the usual FEC associated with the shortest path destination-based
forwarding tree for a given prefix as determined by the IGP. We will forwarding tree for a given prefix as determined by the IGP. We will
use the terms "red FEC" and "blue FEC" to refer to FECs associated use the terms "red FEC" and "blue FEC" to refer to FECs associated
with the MRT-Red and MRT-Blue destination-based forwarding trees for with the MRT-Red and MRT-Blue destination-based forwarding trees for
a given prefix as determined by a particular MRT algorithm. a given prefix as determined by a particular MRT algorithm.
We first describe label distribution behavior specific to MRT. Then We first describe label distribution behavior specific to MRT. Then
we provide the correct interpretation of several important concepts we provide the correct interpretation of several important concepts
skipping to change at page 10, line 10 skipping to change at page 10, line 24
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.
In this transition, an ABR should never advertise a red(blue) FEC In this transition, an ABR should never advertise a red(blue) FEC
before withdrawing the corresponding rainbow FEC (or vice versa). before withdrawing the corresponding rainbow FEC (or vice versa).
However, should this situation occur, the expected behavior of an LSR However, should this situation occur, the expected behavior of an LSR
receiving these conflicting advertisements is defined as foll If an receiving these conflicting advertisements is defined as follows. If
LSR receives a label mapping advertisement for a rainbow FEC from an an LSR receives a label mapping advertisement for a rainbow FEC from
MRT LDP peer while it still retains a label mapping for the 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 11, line 25 skipping to change at page 11, line 39
5.2. LDP protocol procedures in the context of MRT label distribution 5.2. LDP protocol procedures in the context of MRT label distribution
[RFC5036] specifies the LDP label distribution procedures for [RFC5036] specifies the LDP label distribution procedures for
shortest path FECs. In general, the same procedures can be applied shortest path FECs. In general, the same procedures can be applied
to the distribution of label mappings for red and blue FECs, provided to the distribution of label mappings for red and blue FECs, provided
that the procedures are interpreted in the context of MRT FEC label that the procedures are interpreted in the context of MRT FEC label
distribution. The correct interpretation of several important distribution. The correct interpretation of several important
concepts in [RFC5036] in the context of MRT FEC label distribution is concepts in [RFC5036] in the context of MRT FEC label distribution is
provided below. provided below.
5.2.1. LDP peer in RFC5036 5.2.1. LDP peer in RFC 5036
In the context of distributing label mappings for red and blue FECs, In the context of distributing label mappings for red and blue FECs,
we restrict LDP peer in [RFC5036] to mean LDP peers for which the LDP we restrict LDP peer in [RFC5036] to mean LDP peers for which the LDP
MRT capability has been negotiated. In order to make this MRT capability has been negotiated. In order to make this
distinction clear, in this document we will use the term "MRT LDP distinction clear, in this document we will use the term "MRT LDP
peer" to refer to an LDP peer for which the LDP MRT capability has peer" to refer to an LDP peer for which the LDP MRT capability has
been negotiated. been negotiated.
5.2.2. Next hop in RFC5036 5.2.2. Next hop in RFC 5036
Several procedures in [RFC5036] use the next hop of a (shortest path) Several procedures in [RFC5036] use the next hop of a (shortest path)
FEC to determine behavior. The next hop of the shortest path FEC is FEC to determine behavior. The next hop of the shortest path FEC is
based on the shortest path forwarding tree to the prefix associated based on the shortest path forwarding tree to the prefix associated
with the FEC. When the procedures of [RFC5036] are used to with the FEC. When the procedures of [RFC5036] are used to
distribute label mapping for red and blue FECs, the next hop for the distribute label mapping for red and blue FECs, the next hop for the
red/blue FEC is based on the MRT-Red/Blue forwarding tree to the red(blue) FEC is based on the MRT-Red(Blue) forwarding tree to the
prefix associated with the FEC. prefix associated with the FEC.
For example, Appendix A.1.7. of [RFC5036] specifies the response by For example, Appendix A.1.7 of [RFC5036] specifies the response by an
an LSR to a change in the next hop for a FEC. For a shortest path LSR to a change in the next hop for a FEC. For a shortest path FEC,
FEC, the next hop may change as the result of the LSR running a the next hop may change as the result of the LSR running a shortest
shortest path computation on a modified IGP topology database. For path computation on a modified IGP topology database. For the red
the red and blue FECs, the red and blue next hops may change as the and blue FECs, the red and blue next hops may change as the result of
result of the LSR running a particular MRT algorithm on a modified the LSR running a particular MRT algorithm on a modified IGP topology
IGP topology database. database.
As another example, Section 2.6.1.2 of [RFC5036] specifies how that As another example, Section 2.6.1.2 of [RFC5036] specifies that when
when an LSR is using LSP Ordered Control, it may initiate the an LSR is using LSP Ordered Control, it may initiate the transmission
transmission of a label mapping only for a (shortest path) FEC for of a label mapping only for a (shortest path) FEC for which it has a
which it has a label mapping for the FEC next hop, or for which the label mapping for the FEC next hop, or for which the LSR is the
LSR is the egress. The FEC next hop for a shortest path FEC is based egress. The FEC next hop for a shortest path FEC is based on the
on the shortest path forwarding tree to the prefix associated with shortest path forwarding tree to the prefix associated with the FEC.
the FEC. In the context of distributing MRT LDP labels, this In the context of distributing MRT LDP labels, this procedure is
procedure is understood to mean the following. When an LSR is using understood to mean the following. When an LSR is using LSP Ordered
LSP Ordered Control, it may initiate the transmission of a label Control, it may initiate the transmission of a label mapping only for
mapping only for a red(blue) FEC for which it has a label mapping for a red(blue) FEC for which it has a label mapping for the red(blue)
the red(blue) FEC next hop, or for which the LSR is the egress. The FEC next hop, or for which the LSR is the egress. The red or blue
red or blue FEC next hop is based on the MRT-Red or Blue forwarding FEC next hop is based on the MRT-Red or Blue forwarding tree to the
tree to the prefix associated with the FEC. prefix associated with the FEC.
5.2.3. Egress LSR in RFC5036 5.2.3. Egress LSR in RFC 5036
Procedures in [RFC5036] related to Ordered Control label distribution Procedures in [RFC5036] related to Ordered Control label distribution
mode rely on whether or not an LSR may act as an egress LSR for a mode rely on whether or not an LSR may act as an egress LSR for a
particular FEC in order to determine whether or not the LSR may particular FEC in order to determine whether or not the LSR may
originate a label mapping for that FEC. The status of being an originate a label mapping for that FEC. The status of being an
egress LSR for a particular FEC is also used in loop detection egress LSR for a particular FEC is also used in loop detection
procedures in [RFC5036]. Section 2.6.1.2 of [RFC5036] specifies the procedures in [RFC5036]. Section 2.6.1.2 of [RFC5036] specifies the
conditions under which an LSR may act as an egress LSR with respect conditions under which an LSR may act as an egress LSR with respect
to a particular (shortest path) FEC. to a particular (shortest path) FEC.
skipping to change at page 13, line 16 skipping to change at page 13, line 32
requires non-best-area advertising and forwarding behavior for requires non-best-area advertising and forwarding behavior for
the prefix associated with the FEC. the prefix associated with the FEC.
Note that condition(3) scopes an LSR's status as an egress LSR with Note that condition(3) scopes an LSR's status as an egress LSR with
respect to a particular FEC to a particular MRT LDP peer. Therefore, respect to a particular FEC to a particular MRT LDP peer. Therefore,
the condition "Is LSR egress for FEC?" that occurs in several the condition "Is LSR egress for FEC?" that occurs in several
procedures in [RFC5036] needs to be interpreted as "Is LSR egress for procedures in [RFC5036] needs to be interpreted as "Is LSR egress for
FEC with respect to Peer?" FEC with respect to Peer?"
Also note that there is no explicit condition that allows an LSR to Also note that there is no explicit condition that allows an LSR to
be classified as an egress LSR with respect a red or blue FEC based be classified as an egress LSR with respect to a red or blue FEC
only on the primary next-hop for the shortest path FEC not supporting based only on the primary next-hop for the shortest path FEC not
LDP, or not supporting LDP MRT capability. These situations are supporting LDP, or not supporting LDP MRT capability. These
covered by the proxy-node attachment router and ABR conditions situations are covered by the proxy-node attachment router and ABR
(conditions 2 and 3). In particular, an Island Border Router is not conditions (conditions 2 and 3). In particular, an Island Border
the egress LSR for a red(blue) FEC unless it is also the red(blue) Router is not the egress LSR for a red(blue) FEC unless it is also
proxy-node attachment router for that FEC. the red(blue) proxy-node attachment router for that FEC.
Also note that in general a proxy-node attachment router for a given Also note that in general a proxy-node attachment router for a given
prefix should not advertise an implicit or explicit null label for prefix should not advertise an implicit or explicit null label for
the corresponding red or blue FEC, even though it may be an egress the corresponding red or blue FEC, even though it may be an egress
LSR for the shortest path FEC. In general, the proxy-node attachment LSR for the shortest path FEC. In general, the proxy-node attachment
router needs to forward red or blue traffic for that prefix to a router needs to forward red or blue traffic for that prefix to a
particular loop free island neighbor, which may be different from the particular loop free island neighbor, which may be different from the
shortest path next-hop. The proxy-node attachment router needs to shortest path next-hop. The proxy-node attachment router needs to
receive the red or blue traffic with a non-null label to correctly receive the red or blue traffic with a non-null label to correctly
forward it. forward it.
5.2.4. Use of Rainbow FEC to satisfy label mapping existence 5.2.4. Use of Rainbow FEC to satisfy label mapping existence
requirements in RFC5036 requirements in RFC 5036
Several procedures in [RFC5036] require the LSR to determine if it Several procedures in [RFC5036] require the LSR to determine if it
has previously received and retained a label mapping for a FEC from has previously received and retained a label mapping for a FEC from
the next hop. In the case of an LSR that has received and retained a the next hop. In the case of an LSR that has received and retained a
label mapping for a Rainbow FEC from an ABR, the label mapping for label mapping for a Rainbow FEC from an ABR, the label mapping for
the Rainbow FEC satisfies the label mapping existence requirement for the Rainbow FEC satisfies the label mapping existence requirement for
the corresponding red and blue FECs. Label mapping existence the corresponding red and blue FECs. Label mapping existence
requirements in the context of MRT LDP label distribution are requirements in the context of MRT LDP label distribution are
modified as: "Has LSR previously received and retained a label modified as: "Has LSR previously received and retained a label
mapping for the red(blue) FEC (or the corresponding Rainbow FEC) from mapping for the red(blue) FEC (or the corresponding Rainbow FEC) from
skipping to change at page 15, line 5 skipping to change at page 15, line 22
label injected into the network from a compromised location would be label injected into the network from a compromised location would be
forwarded to a destination along a non-shortest path. When this forwarded to a destination along a non-shortest path. When this
technology is deployed, a network security design should not rely on technology is deployed, a network security design should not rely on
assumptions about potentially malicious traffic only following assumptions about potentially malicious traffic only following
shortest paths. shortest paths.
It should be noted that the creation of non-shortest forwarding paths It should be noted that the creation of non-shortest forwarding paths
is not unique to MRT. For example, RSVP-TE [RFC3209] can be used to is not unique to MRT. For example, RSVP-TE [RFC3209] can be used to
construct forwarding paths that do not follow the shortest path. construct forwarding paths that do not follow the shortest path.
7. Potential restrictions on MRT-related MT-ID values imposed by 7. Potential restrictions on MRT-related MT-ID values imposed by RFC
RFC6420 6420
As discussed in the introduction, in addition to unicast forwarding As discussed in the introduction, in addition to unicast forwarding
applications, MRT can be used to provide disjoint trees for multicast applications, MRT can be used to provide disjoint trees for multicast
traffic distribution. In the case of PIM, this is accomplished by traffic distribution. In the case of PIM, this is accomplished by
using the MRT red and blue next-hops as the PIM RPF topology, the using the MRT red and blue next-hops as the PIM RPF topology, the
collection of routes used by PIM to perform the RPF operation when collection of routes used by PIM to perform the RPF operation when
building source trees. The PIM Multi-Topology ID (MT-ID) Join building source trees. The PIM Multi-Topology ID (MT-ID) Join
Attribute defined in section 5.2 of [RFC6420] can be used to Attribute defined in section 5.2 of [RFC6420] can be used to
establish MRT-based multicast distribution trees. [RFC6420] limits establish MRT-based multicast distribution trees. [RFC6420] limits
the values of the PIM MT-ID from 1 through 4095. the values of the PIM MT-ID from 1 through 4095.
skipping to change at page 17, line 12 skipping to change at page 17, line 35
Bryant, Mach Chen, Greg Mirsky, Uma Chunduri and Tony Przygienda for Bryant, Mach Chen, Greg Mirsky, Uma Chunduri and Tony Przygienda for
their comments and suggestions. their comments and suggestions.
10. References 10. References
10.1. Normative References 10.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>. <https://www.rfc-editor.org/info/rfc2119>.
[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, <https://www.rfc-editor.org/info/rfc5036>. October 2007, <https://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.
Le Roux, "LDP Capabilities", RFC 5561, Le Roux, "LDP Capabilities", RFC 5561,
DOI 10.17487/RFC5561, July 2009, <https://www.rfc- DOI 10.17487/RFC5561, July 2009,
editor.org/info/rfc5561>. <https://www.rfc-editor.org/info/rfc5561>.
[RFC6420] Cai, Y. and H. Ou, "PIM Multi-Topology ID (MT-ID) Join [RFC6420] Cai, Y. and H. Ou, "PIM Multi-Topology ID (MT-ID) Join
Attribute", RFC 6420, DOI 10.17487/RFC6420, November 2011, Attribute", RFC 6420, DOI 10.17487/RFC6420, November 2011,
<https://www.rfc-editor.org/info/rfc6420>. <https://www.rfc-editor.org/info/rfc6420>.
[RFC7307] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D. [RFC7307] Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D.
King, "LDP Extensions for Multi-Topology", RFC 7307, King, "LDP Extensions for Multi-Topology", RFC 7307,
DOI 10.17487/RFC7307, July 2014, <https://www.rfc- DOI 10.17487/RFC7307, July 2014,
editor.org/info/rfc7307>. <https://www.rfc-editor.org/info/rfc7307>.
[RFC7811] Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A. [RFC7811] Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A.
Gopalan, "An Algorithm for Computing IP/LDP Fast Reroute Gopalan, "An Algorithm for Computing IP/LDP Fast Reroute
Using Maximally Redundant Trees (MRT-FRR)", RFC 7811, Using Maximally Redundant Trees (MRT-FRR)", RFC 7811,
DOI 10.17487/RFC7811, June 2016, <https://www.rfc- DOI 10.17487/RFC7811, June 2016,
editor.org/info/rfc7811>. <https://www.rfc-editor.org/info/rfc7811>.
[RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for
IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-
FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016,
<https://www.rfc-editor.org/info/rfc7812>. <https://www.rfc-editor.org/info/rfc7812>.
10.2. Informative References 10.2. Informative References
[I-D.atlas-rtgwg-mrt-mc-arch] [I-D.atlas-rtgwg-mrt-mc-arch]
Atlas, A., Kebler, R., Wijnands, I., Csaszar, A., and G. Atlas, A., Kebler, R., Wijnands, I., Csaszar, A., and G.
skipping to change at page 18, line 16 skipping to change at page 18, line 40
Li, Z., Wu, N., <>, Q., Atlas, A., Bowers, C., and J. Li, Z., Wu, N., <>, Q., Atlas, A., Bowers, C., and J.
Tantsura, "Intermediate System to Intermediate System (IS- Tantsura, "Intermediate System to Intermediate System (IS-
IS) Extensions for Maximally Redundant Trees (MRT)", IS) Extensions for Maximally Redundant Trees (MRT)",
draft-ietf-isis-mrt-02 (work in progress), May 2016. draft-ietf-isis-mrt-02 (work in progress), May 2016.
[I-D.ietf-ospf-mrt] [I-D.ietf-ospf-mrt]
Atlas, A., Hegde, S., Bowers, C., Tantsura, J., and Z. Li, Atlas, A., Hegde, S., Bowers, C., Tantsura, J., and Z. Li,
"OSPF Extensions to Support Maximally Redundant Trees", "OSPF Extensions to Support Maximally Redundant Trees",
draft-ietf-ospf-mrt-02 (work in progress), May 2016. draft-ietf-ospf-mrt-02 (work in progress), May 2016.
[I-D.wijnands-mpls-mldp-node-protection]
Wijnands, I., Rosen, E., Raza, K., Tantsura, J., Atlas,
A., and Q. Zhao, "mLDP Node Protection", draft-wijnands-
mpls-mldp-node-protection-04 (work in progress), June
2013.
[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,
<http://www.rfc-editor.org/info/rfc3209>. <https://www.rfc-editor.org/info/rfc3209>.
[RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP
Synchronization", RFC 5443, DOI 10.17487/RFC5443, March
2009, <https://www.rfc-editor.org/info/rfc5443>.
[RFC7715] Wijnands, IJ., Ed., Raza, K., Atlas, A., Tantsura, J., and
Q. Zhao, "Multipoint LDP (mLDP) Node Protection",
RFC 7715, DOI 10.17487/RFC7715, January 2016,
<https://www.rfc-editor.org/info/rfc7715>.
Authors' Addresses Authors' Addresses
Alia Atlas Alia Atlas
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
USA USA
Email: akatlas@juniper.net Email: akatlas@juniper.net
 End of changes. 40 change blocks. 
84 lines changed or deleted 109 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/