draft-ietf-mpls-mp-ldp-reqs-06.txt   draft-ietf-mpls-mp-ldp-reqs-07.txt 
MPLS J. Le Roux, Ed. MPLS J. Le Roux, Ed.
Internet-Draft T. Morin Internet-Draft T. Morin, Ed.
Intended status: Informational V. Parfait Intended status: Historic France Telecom - Orange
Expires: June 4, 2011 France Telecom - Orange Expires: November 13, 2011 May 12, 2011
L. Fang
Cisco
L. Wang
Telenor
Y. Kamite
NTT
S. Amante
Level3
December 01, 2010
Requirements for Point-To-Multipoint Extensions to the Label Requirements for Point-To-Multipoint Extensions to the Label
Distribution Protocol Distribution Protocol
draft-ietf-mpls-mp-ldp-reqs-06 draft-ietf-mpls-mp-ldp-reqs-07
Abstract Abstract
This document lists a set of functional requirements for Label This document lists a set of functional requirements that served as
Distribution Protocol (LDP) extensions for setting up point-to- input to the design of Label Distribution Protocol (LDP) extensions
multipoint (P2MP) Label Switched Paths (LSP), in order to deliver for setting up point-to-multipoint (P2MP) Label Switched Paths (LSP),
point-to-multipoint applications over a Multi Protocol Label in order to deliver point-to-multipoint applications over a Multi
Switching (MPLS) infrastructure. It is intended that solutions that Protocol Label Switching (MPLS) infrastructure.
specify LDP procedures for setting up P2MP LSP satisfy these
requirements.
Requirements Language 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].
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
skipping to change at page 2, line 6 skipping to change at page 1, line 41
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 June 4, 2011. This Internet-Draft will expire on November 13, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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 7 skipping to change at page 3, line 7
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 4
1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
3. Problem Statement and Requirements Overview . . . . . . . . . 6 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 6 4. Requirements overview . . . . . . . . . . . . . . . . . . . . 7
3.2. Requirements overview . . . . . . . . . . . . . . . . . . 7 5. Application scenario . . . . . . . . . . . . . . . . . . . . . 7
4. Application scenario . . . . . . . . . . . . . . . . . . . . . 7 6. Detailed Requirements . . . . . . . . . . . . . . . . . . . . 9
5. Detailed Requirements . . . . . . . . . . . . . . . . . . . . 9 6.1. P2MP LSPs . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. P2MP LSPs . . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. P2MP LSP FEC . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. P2MP LSP FEC . . . . . . . . . . . . . . . . . . . . . . . 9 6.3. P2MP LDP routing . . . . . . . . . . . . . . . . . . . . . 9
5.3. P2MP LDP routing . . . . . . . . . . . . . . . . . . . . . 9 6.4. Setting up, tearing down and modifying P2MP LSPs . . . . . 10
5.4. Setting up, tearing down and modifying P2MP LSPs . . . . . 9 6.5. Label Advertisement . . . . . . . . . . . . . . . . . . . 10
5.5. Label Advertisement . . . . . . . . . . . . . . . . . . . 10 6.6. Data Duplication . . . . . . . . . . . . . . . . . . . . . 10
5.6. Data Duplication . . . . . . . . . . . . . . . . . . . . . 10 6.7. Detecting and Avoiding Loops . . . . . . . . . . . . . . . 10
5.7. Detecting and Avoiding Loops . . . . . . . . . . . . . . . 10 6.8. P2MP LSP Re-routing . . . . . . . . . . . . . . . . . . . 11
5.8. P2MP LSP Re-routing . . . . . . . . . . . . . . . . . . . 11 6.9. Support for multi-access networks . . . . . . . . . . . . 12
5.9. Support for LAN interfaces . . . . . . . . . . . . . . . . 12 6.10. Support for encapsulation in P2P and P2MP TE tunnels . . . 12
5.10. Support for encapsulation in P2P and P2MP TE tunnels . . . 12 6.11. Label spaces . . . . . . . . . . . . . . . . . . . . . . . 12
5.11. Label spaces . . . . . . . . . . . . . . . . . . . . . . . 12 6.12. IPv4/IPv6 support . . . . . . . . . . . . . . . . . . . . 12
5.12. IPv4/IPv6 support . . . . . . . . . . . . . . . . . . . . 12 6.13. Multi-Area/AS LSPs . . . . . . . . . . . . . . . . . . . . 13
5.13. Multi-Area/AS LSPs . . . . . . . . . . . . . . . . . . . . 12 6.14. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.14. OAM . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.15. Graceful Restart and Fault Recovery . . . . . . . . . . . 13
5.15. Graceful Restart and Fault Recovery . . . . . . . . . . . 13 6.16. Robustness . . . . . . . . . . . . . . . . . . . . . . . . 13
5.16. Robustness . . . . . . . . . . . . . . . . . . . . . . . . 13 6.17. Scalability . . . . . . . . . . . . . . . . . . . . . . . 13
5.17. Scalability . . . . . . . . . . . . . . . . . . . . . . . 13 6.18. Backward Compatibility . . . . . . . . . . . . . . . . . . 14
5.18. Backward Compatibility . . . . . . . . . . . . . . . . . . 14 7. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Shared Trees . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Requirements for MP2MP LSPs . . . . . . . . . . . . . . . 15
6.1. Requirements for MP2MP LSPs . . . . . . . . . . . . . . . 15 8. Evaluation criteria . . . . . . . . . . . . . . . . . . . . . 16
7. Evaluation criteria . . . . . . . . . . . . . . . . . . . . . 16 8.1. Performance . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Performances . . . . . . . . . . . . . . . . . . . . . . . 16 8.2. Complexity and Risks . . . . . . . . . . . . . . . . . . . 16
7.2. Complexity and Risks . . . . . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 12.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 12.2. Informative References . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Definitions 1. Contributing Authors
1.1. Acronyms The following people contributed to the text and content of this
document:
o Shane Amante, Level 3 Communications, LLC
o Luyuan Fang, Cisco Systems
o Yuji Kamite, NTT Communications Corporation
o Jean-Louis Le Roux, France Telecom - Orange
o Thomas Morin, France Telecom - Orange
o Vincent Parfait, France Telecom - Orange, Orange Business Services
o Lei Wang, Telenor
2. Definitions
2.1. Acronyms
P2P: Point-To-Point P2P: Point-To-Point
MP2P: Multipoint-to-Point
P2MP: Point-To-MultiPoint P2MP: Point-To-MultiPoint
MP2MP: MultiPoint-To-Multipoint MP2MP: MultiPoint-To-Multipoint
LSP: Label Switched Path
LSR: Label Switching Router
PE: Provider Edge router PE: Provider Edge router
P: Provider router P: Provider router
IGP: Interior Gateway Protocol IGP: Interior Gateway Protocol
AS: Autonomous System AS: Autonomous System
1.2. Terminology 2.2. Terminology
The reader is assumed to be familiar with the terminology in The reader is assumed to be familiar with the terminology in
[RFC3031], [RFC5036], and [RFC4026]. [RFC3031], [RFC5036], and [RFC4026].
Ingress LSR: Ingress LSR:
Router acting as a sender of an LSP Router acting as a sender of an LSP
Egress LSR: Egress LSR:
Router acting as a receiver of an LSP Router acting as a receiver of an LSP
skipping to change at page 5, line 19 skipping to change at page 5, line 46
A LSR of a P2MP or MP2MP LSP that has more than one downstream LSR A LSR of a P2MP or MP2MP LSP that has more than one downstream LSR
Bud LSR: Bud LSR:
A LSR of a P2MP or MP2MP LSP that is an egress but also has one or A LSR of a P2MP or MP2MP LSP that is an egress but also has one or
more directly connected downstream LSR(s) more directly connected downstream LSR(s)
P2MP tree: P2MP tree:
The ordered set of LSRs and links that comprise the path of a P2MP The ordered set of LSRs and links that comprise the path of a P2MP
LSP from its ingress LSR to all of its egress LSRs. LSP from its ingress LSR to all of its egress LSRs.
2. Introduction 3. Introduction
Note that this document captures requirements that served as input to
the design of [I-D.ietf-mpls-ldp-p2mp] and is published with Historic
status with the perspective of documenting the work done.
LDP [RFC5036] has been deployed for setting up point-to-point (P2P) LDP [RFC5036] has been deployed for setting up point-to-point (P2P)
and multipoint-to-point (MP2P) LSPs, in order to offer point-to-point and multipoint-to-point (MP2P) LSPs, in order to offer point-to-point
services in MPLS backbones. services in MPLS backbones.
There are emerging requirements for supporting delivery of point-to- There are emerging requirements for supporting delivery of point-to-
multipoint applications in MPLS backbones, such as those defined in multipoint applications in MPLS backbones, such as those defined in
[RFC4834] and [RFC5501]. [RFC4834] and [RFC5501].
This requires mechanisms for setting up point-to-multipoint LSPs For various reasons, including consistency with P2P applications, and
(P2MP LSP), i.e. LSPs with one Ingress LSR, a set of Egress LSRs, taking full advantages of MPLS network infrastructure, it would be
and with MPLS traffic replication at some Branch LSRs. highly desirable to use MPLS LSPs for the delivery of multicast
traffic. This could be implemented by setting up a group of P2P or
MP2P LSPs, but such an approach may be inefficient since it would
result in data replication at the ingress LSR and duplicate data
traffic within the network. Hence new mechanisms are required that
would allow traffic from an Ingress LSR to be efficiently delivered
to a number of Egress LSRs in an MPLS backbone on a point-to-
multipoint LSP (P2MP LSP), avoiding duplicate copies of a packet on a
given link and with MPLS traffic replication at some Branch LSRs.
RSVP-TE extensions for setting up Point-To-Multipoint Traffic RSVP-TE extensions for setting up Point-To-Multipoint Traffic
Engineered LSPs (P2MP TE LSPs), have been defined in [RFC4875]. They Engineered LSPs (P2MP TE LSPs), have been defined in [RFC4875]. They
meet requirements expressed in [RFC4461]. This approach is useful, meet requirements expressed in [RFC4461]. This approach is useful,
in network environments where P2MP Traffic Engineering capabilities in network environments where P2MP Traffic Engineering capabilities
are needed (Optimization, QoS, Fast recovery). are needed (Optimization, QoS, Fast recovery).
However for operators who want to support point-to-multipoint traffic However for operators who want to support point-to-multipoint traffic
delivery on an MPLS backbone, without Traffic Engineering needs, and delivery on an MPLS backbone, without Traffic Engineering needs, and
have already deployed LDP for P2P traffic, an interesting and useful who have already deployed LDP for P2P traffic, an interesting and
approach would be to rely on LDP extensions in order to setup point- useful approach would be to rely on LDP extensions in order to setup
to-multipoint (P2MP) LSPs. This would bring consistency with P2P point-to-multipoint (P2MP) LSPs. This would bring consistency with
MPLS applications and would ease the delivery of point-to-multipoint P2P MPLS applications and would ease the delivery of point-to-
services in an MPLS backbone. multipoint services in an MPLS backbone.
This document focuses on the LDP approach for setting up P2MP LSPs. This document focuses on the LDP approach for setting up P2MP LSPs.
It lists a detailed set of requirements for P2MP extensions to LDP, It lists a detailed set of requirements for P2MP extensions to LDP,
so as to deliver P2MP traffic over a LDP-enabled MPLS infrastructure. so as to deliver P2MP traffic over a LDP-enabled MPLS infrastructure.
These requirements should be used as guidelines when specifying LDP The original intent was that these requirements should be used as
extensions. It is intended that solutions that specify LDP guidelines when specifying LDP extensions.
procedures for P2MP LSP setup, satisfy these requirements.
Note that generic requirements for P2MP extensions to MPLS are out of Note that generic requirements for P2MP extensions to MPLS are out of
the scope of this document. Rather this document describes solution the scope of this document. Rather this document describes solution
specific requirements related to LDP extensions in order to set up specific requirements related to LDP extensions in order to set up
P2MP LSPs. P2MP LSPs.
Note also that other mechanisms could be used for setting up P2MP Note also that other mechanisms could be used for setting up P2MP
LSPs, such as for instance PIM extensions, but these are out of the LSPs, such as for instance PIM extensions, but these are out of the
scope of this document. The objective is not to compare these scope of this document. The objective is not to compare these
mechanisms but rather to focus on the requirements for an LDP mechanisms but rather to focus on the requirements for an LDP
extension approach. extension approach.
The document is structured as follows: The document is structured as follows:
o Section 3 points out the problem statement; o Section 4 is an overview of the requirements;
o Section 4 illustrates an application scenario;
o Section 5 addresses detailed requirements for P2MP LSPs;
o Section Section 6 finally discusses requirements for shared trees
and MultiPoint-to-MultiPoint (MP2MP) LSPs.
3. Problem Statement and Requirements Overview
3.1. Problem Statement
LDP [RFC5036] has been deployed for setting up P2P and MP2P MPLS LSPs
as PE-to-PE tunnels so as to carry point-to-point traffic essentially
in Layer 3 and Layer 2 VPN networks. There are emerging requirements
for supporting multicast traffic delivery within these VPN
infrastructures ([RFC4834] and [RFC5501]). For various reasons,
including consistency with P2P applications, and taking full
advantages of MPLS network infrastructure, it would be highly
desirable to use MPLS LSPs for the delivery of multicast traffic.
This could be implemented by setting up a group of P2P or MP2P LSPs,
but such an approach may be sub-optimal since it would result in data
replication at the ingress LSR, and bandwidth inefficiency (duplicate
data traffic within the network). Hence new mechanisms are required
that would allow traffic from an Ingress LSR to be efficiently
delivered to a number of Egress LSRs in an MPLS backbone, avoiding
duplicate copies of a packet on a given link.
Such efficient traffic delivery requires setting up P2MP LSPs. A o Section 5 illustrates an application scenario;
P2MP LSP is an LSP starting at an Ingress LSR, and ending on a set of
one or more Egress LSRs. Traffic sent by the Ingress LSR is
replicated on one or more Branch LSRs down to Egress LSRs.
RSVP-TE extensions for setting up P2MP TE LSPs, which meet o Section 6 addresses detailed requirements for P2MP LSPs;
requirements expressed in [RFC4461], have been defined in [RFC4875].
This approach is useful, in network environments where Traffic
Engineering capabilities are required. However, for operators that
deployed LDP for setting up PE-to-PE unicast MPLS LSPs, and without
the need for traffic engineering, an interesting approach would be
using LDP extensions for setting up P2MP LSPs.
The following gives a set of guidelines that a specification of LDP o Section 7 finally discusses requirements for shared trees and
extensions for setting up P2MP LSPs should follow. MultiPoint-to-MultiPoint (MP2MP) LSPs.
3.2. Requirements overview 4. Requirements overview
The P2MP LDP mechanism MUST support setting up P2MP LSPs, i.e. LSPs The P2MP LDP mechanism MUST support setting up P2MP LSPs, i.e. LSPs
with one Ingress LSR and one or more Egress LSRs, with traffic with one Ingress LSR and one or more Egress LSRs, with traffic
replication at some Branch LSRs. replication at some Branch LSRs.
The P2MP LDP mechanism MUST allow the addition or removal of leaves The P2MP LDP mechanism MUST allow the addition or removal of leaves
associated with a P2MP LSP. associated with a P2MP LSP.
The P2MP LDP mechanism MUST co-exist with current LDP mechanisms and The P2MP LDP mechanism MUST co-exist with current LDP mechanisms and
inherit its capability sets from [RFC5036]. It is of paramount inherit its capability sets from [RFC5036]. It is of paramount
skipping to change at page 7, line 31 skipping to change at page 7, line 32
replication at some Branch LSRs. replication at some Branch LSRs.
The P2MP LDP mechanism MUST allow the addition or removal of leaves The P2MP LDP mechanism MUST allow the addition or removal of leaves
associated with a P2MP LSP. associated with a P2MP LSP.
The P2MP LDP mechanism MUST co-exist with current LDP mechanisms and The P2MP LDP mechanism MUST co-exist with current LDP mechanisms and
inherit its capability sets from [RFC5036]. It is of paramount inherit its capability sets from [RFC5036]. It is of paramount
importance that the P2MP LDP mechanism MUST NOT impede the operation importance that the P2MP LDP mechanism MUST NOT impede the operation
of existing P2P/MP2P LDP LSPs. Also the P2MP LDP mechanism MUST co- of existing P2P/MP2P LDP LSPs. Also the P2MP LDP mechanism MUST co-
exist with P2P and P2MP RSVP-TE mechanisms [RFC3209], [RFC4875]. It exist with P2P and P2MP RSVP-TE mechanisms [RFC3209], [RFC4875]. It
is of paramount importance that the P2MP LDP mechanism MUST NOT is of paramount importance that the P2MP LDP mechanism MUST NOT
impede the operation of existing P2P and P2MP RSVP-TE LSPs. impede the operation of existing P2P and P2MP RSVP-TE LSPs.
The P2MP LDP mechanism MAY also allow setting up multipoint-to- The P2MP LDP mechanism MAY also allow setting up multipoint-to-
multipoint (MP2MP) LSPs connecting a group of Leaf LSRs acting multipoint (MP2MP) LSPs connecting a group of Leaf LSRs acting
indifferently as Ingress LSR or Egress LSR. This may allow a indifferently as Ingress LSR or Egress LSR. This may allow a
reduction in the amount of LDP state that needs to be maintained by a reduction in the amount of LDP state that needs to be maintained by a
LSR. LSR.
4. Application scenario 5. Application scenario
Figure 1 below illustrates an LDP enabled MPLS provider network, used Figure 1 below illustrates an LDP enabled MPLS provider network, used
to carry both unicast and multicast traffic of VPN customers to carry both unicast and multicast traffic of VPN customers
following for instance the architecture defined in following for instance the architecture defined in
[I-D.ietf-l3vpn-2547bis-mcast] for BGP/MPLS VPNs, or the one defined [I-D.ietf-l3vpn-2547bis-mcast] for BGP/MPLS VPNs, or the one defined
in [I-D.ietf-l2vpn-vpls-mcast]. in [I-D.ietf-l2vpn-vpls-mcast].
In this example, a set of MP2P LDP LSPs are setup between Provider In this example, a set of MP2P LDP LSPs are setup between Provider
Edge (PE) routers to carry unicast VPN traffic within the MPLS Edge (PE) routers to carry unicast VPN traffic within the MPLS
backbone. backbone.
skipping to change at page 9, line 9 skipping to change at page 9, line 11
*| |* *| |*
*| |* *| |*
PE5 PE6 PE5 PE6
Figure 2: Attachment of PE5 and PE6. Figure 2: Attachment of PE5 and PE6.
The above example is provided for the sake of illustration. Note The above example is provided for the sake of illustration. Note
that P2MP LSPs ingress and egress LSRs may not necessarily be PE that P2MP LSPs ingress and egress LSRs may not necessarily be PE
routers. Also branch LSRs may not necessarily be P routers. routers. Also branch LSRs may not necessarily be P routers.
5. Detailed Requirements 6. Detailed Requirements
5.1. P2MP LSPs 6.1. P2MP LSPs
The P2MP LDP mechanism MUST support setting up P2MP LSPs. Data plane The P2MP LDP mechanism MUST support setting up P2MP LSPs. Data plane
aspects related to P2MP LSPs are those already defined in [RFC4461]. aspects related to P2MP LSPs are those already defined in [RFC4461].
That is, a P2MP LSP has one Ingress LSR and one or more Egress LSRs. That is, a P2MP LSP has one Ingress LSR and one or more Egress LSRs.
Traffic sent by the Ingress LSR is received by all Egress LSRs. The Traffic sent by the Ingress LSR is received by all Egress LSRs. The
specific aspects related to P2MP LSPs is the action required at a specific aspects related to P2MP LSPs is the action required at a
Branch LSR, where data replication occurs. Incoming labelled data is Branch LSR, where data replication occurs. Incoming labelled data is
appropriately replicated to several outgoing interfaces which may use appropriately replicated to several outgoing interfaces which may use
different labels. Only one copy of a packet MUST be sent on a given different labels.
link of a P2MP LSP.
An LSR SHOULD NOT send more than one copy of a packet on any given
link of a P2MP LSP. Exceptions to this are mentioned in Section 6.9
and Section 6.18.
A P2MP LSP MUST be identified by a constant and unique identifier A P2MP LSP MUST be identified by a constant and unique identifier
within the whole LDP domain, whatever the number of leaves, which may within the whole LDP domain, whatever the number of leaves, which may
vary dynamically. This identifier will be used so as to add/remove vary dynamically. This identifier will be used so as to add/remove
leaves to/from the P2MP tree. leaves to/from the P2MP tree.
5.2. P2MP LSP FEC 6.2. P2MP LSP FEC
As with P2P MPLS technology [RFC5036], traffic MUST be classified As with P2P MPLS technology [RFC5036], traffic MUST be classified
into a FEC in this P2MP extension. All packets which belong to a into a FEC in this P2MP extension. All packets which belong to a
particular P2MP FEC and which travel from a particular node MUST use particular P2MP FEC and which travel from a particular node MUST use
the same P2MP LSP. the same P2MP LSP.
As such, a new LDP FEC that is suitable for P2MP forwarding MUST be If existing FECs cannot be used for this purpose, a new LDP FEC that
specified. is suitable for P2MP forwarding MUST be specified.
5.3. P2MP LDP routing 6.3. P2MP LDP routing
As with P2P and MP2P LDP LSPs, the P2MP LDP mechanism MUST support As with P2P and MP2P LDP LSPs, the P2MP LDP mechanism MUST support
hop-by-hop LSP routing. P2MP LDP-based routing SHOULD rely upon the hop-by-hop LSP routing. P2MP LDP-based routing SHOULD rely upon the
information maintained in LSR Routing Information Bases (RIB). information maintained in LSR Routing Information Bases (RIB).
It is RECOMMENDED that the P2MP LSP routing rely upon a shortest path It is RECOMMENDED that the P2MP LSP routing rely upon the unicast
to the Ingress LSR so as to setup an MPLS shortest path tree. route to the Ingress LSR to build a reverse path tree.
5.4. Setting up, tearing down and modifying P2MP LSPs 6.4. Setting up, tearing down and modifying P2MP LSPs
The P2MP LDP mechanism MUST support the establishment, maintenance The P2MP LDP mechanism MUST support the establishment, maintenance
and teardown of P2MP LSPs in a scalable manner. This MUST include and teardown of P2MP LSPs in a scalable manner. This MUST include
both the existence of a large amount of P2MP LSPs within a single both the existence of a large amount of P2MP LSPs within a single
network and a large amount of leaf LSRs for a single P2MP LSP (see network and a large amount of leaf LSRs for a single P2MP LSP (see
also section 5.17 for scalability considerations and figures). also Section 6.17 for scalability considerations and figures).
In order to scale well with a large number of leaves it is In order to scale well with a large number of leaves it is
RECOMMENDED to follow a leaf-initiated P2MP LSP setup approach. For RECOMMENDED to follow a leaf-initiated P2MP LSP setup approach. For
that purpose, leaves will have to be aware of the P2MP LSP that purpose, leaves will have to be aware of the P2MP LSP
identifier. The ways a Leaf LSR discovers P2MP LSPs identifiers rely identifier. The ways a Leaf LSR discovers P2MP LSPs identifiers rely
on the applications that will use P2MP LSPs, and are out of the scope on the applications that will use P2MP LSPs, and are out of the scope
of this document. of this document.
The P2MP LDP mechanism MUST allow the dynamic addition and removal of The P2MP LDP mechanism MUST allow the dynamic addition and removal of
leaves to and from a P2MP LSP, without any restriction (provided leaves to and from a P2MP LSP, without any restriction (provided
there is network connectivity). It is RECOMMENDED that these there is network connectivity). It is RECOMMENDED that these
operations be leaf-initiated. These operations MUST NOT impact the operations be leaf-initiated. These operations MUST NOT impact the
data transfer (packet loss, duplication, delay) towards other leaves. data transfer (packet loss, duplication, delay) towards other leaves.
It is RECOMMENDED that these operations do not cause any additional It is RECOMMENDED that these operations do not cause any additional
processing except on the path from the added/removed Leaf LSR to the processing except on the path from the added/removed Leaf LSR to the
Branch LSR. Branch LSR.
5.5. Label Advertisement 6.5. Label Advertisement
The P2MP LDP mechanism MUST support downstream unsolicited label The P2MP LDP mechanism MUST support downstream unsolicited label
advertisement mode. This is well suited to a leaf-initiated approach advertisement mode. This is well suited to a leaf-initiated approach
and is consistent with P2P/MP2P LDP operations. and is consistent with P2P/MP2P LDP operations.
Other advertisement modes MAY also be supported. Other advertisement modes MAY also be supported.
5.6. Data Duplication 6.6. Data Duplication
Data duplication refers to the receipt of multiple copies of a packet Data duplication refers to the receipt of multiple copies of a packet
by any leaf. Although this may be a marginal situation, it may also by any leaf. Although this may be a marginal situation, it may also
be detrimental for certain applications. Hence, data duplication be detrimental for certain applications. Hence, data duplication
SHOULD as much as possible be avoided, and limited to (hopefully SHOULD as much as possible be avoided, and limited to (hopefully
rare) transitory conditions. rare) transitory conditions.
Note, in particular, that data duplication might occur if P2MP LSP Note, in particular, that data duplication might occur if P2MP LSP
rerouting is being performed (See also section 6.8). rerouting is being performed (See also Section 6.8).
5.7. Detecting and Avoiding Loops 6.7. Detecting and Avoiding Loops
The P2MP LDP extension MUST have a mechanism to detect routing loops. The P2MP LDP extension MUST have a mechanism to detect routing loops.
This may rely on extensions to the LDP Loop detection mechanism This MAY rely on extensions to the LDP Loop detection mechanism
defined in [RFC5036]. A loop detection mechanism may require defined in [RFC5036]. A loop detection mechanism MAY require
recording the set of LSRs traversed on the P2MP Tree. The P2MP loop recording the set of LSRs traversed on the P2MP Tree. The P2MP loop
avoidance mechanism MUST NOT impact the scalability of the P2MP LDP avoidance mechanism MUST NOT impact the scalability of the P2MP LDP
solution. solution.
The P2MP LDP mechanism SHOULD have a mechanism to avoid routing loops The P2MP LDP mechanism SHOULD have a mechanism to avoid routing loops
in the data plane even during transient events. in the data plane even during transient events.
Furthermore, the P2MP LDP mechanism MUST avoid routing loops in the Furthermore, the P2MP LDP mechanism MUST avoid routing loops in the
data plane, that may trigger unexpected non-localized exponential data plane, that may trigger unexpected non-localized exponential
growth of traffic. growth of traffic.
5.8. P2MP LSP Re-routing 6.8. P2MP LSP Re-routing
The P2MP LDP mechanism MUST support the rerouting of a P2MP LSP in The P2MP LDP mechanism MUST support the rerouting of a P2MP LSP in
the following cases: the following cases:
o Network failure (link or node); o Network failure (link or node);
o A better path exists (e.g. new link, metric change); o A better path exists (e.g. new link, metric change);
o Planned maintenance. o Planned maintenance.
Given that P2MP LDP routing should rely on the RIB, the achievement Given that P2MP LDP routing should rely on the RIB, the achievement
of the following requirements also implies the underlying routing of the following requirements relies on the underlying routing
protocols (IGP, etc.). protocols (IGP, etc.).
5.8.1. Rerouting upon Network Failure 6.8.1. Rerouting upon Network Failure
The P2MP LDP mechanism MUST allow for rerouting of a P2MP LSP in case The P2MP LDP mechanism MUST allow for rerouting of a P2MP LSP in case
of link or node failure(s), by relying upon update of the routes in of link or node failure(s), by relying upon update of the routes in
the RIB. The rerouting time SHOULD be minimized as much as possible the RIB. The rerouting time SHOULD be minimized as much as possible
so as to reduce traffic disruption. so as to reduce traffic disruption.
A mechanism MUST be defined to prevent constant P2MP LSP teardown and A mechanism MUST be defined to prevent constant P2MP LSP teardown and
rebuild which may be caused by the instability of a specific link/ rebuild which may be caused by the instability of a specific link/
node in the network. This will rely on IGP dampening but may be node in the network. This can rely on IGP dampening but may be
completed by specific dampening at the LDP level. completed by specific dampening at the LDP level.
5.8.2. Rerouting on a Better Path 6.8.2. Rerouting on a Better Path
The P2MP LDP mechanism MUST allow for rerouting of a P2MP LSP in case The P2MP LDP mechanism MUST allow for rerouting of a P2MP LSP in case
a better path is created in the network, for instance as a result of a better path is created in the network, for instance as a result of
a metric change, a link repair, or the addition of links or nodes. a metric change, a link repair, or the addition of links or nodes.
This will rely on update of the routes in the RIB. This will rely on update of the routes in the RIB.
5.8.3. Rerouting upon Planned Maintenance 6.8.3. Rerouting upon Planned Maintenance
The P2MP LDP mechanism MUST support planned maintenance operations. The P2MP LDP mechanism MUST support planned maintenance operations.
It MUST be possible to reroute a P2MP LSP before a link/node is It MUST be possible to reroute a P2MP LSP before a link/node is
deactivated for maintenance purposes. Traffic disruption and data deactivated for maintenance purposes. Traffic disruption and data
duplication SHOULD be minimized as much as possible during such duplication SHOULD be minimized as much as possible during such
planned maintenance. P2MP LSP rerouting upon planned maintenance MAY planned maintenance. P2MP LSP rerouting upon planned maintenance MAY
rely on a make before break procedure. rely on a make before break procedure.
5.9. Support for LAN interfaces 6.9. Support for multi-access networks
The P2MP LDP mechanism SHOULD provide a way for a Branch LSR to send The P2MP LDP mechanism SHOULD provide a way for a Branch LSR to send
a single copy of the data onto an Ethernet LAN interface and reach a single copy of the data onto an interface to a multi-access network
multiple adjacent downstream nodes. This requires that the same (e.g. an Ethernet LAN) and reach multiple adjacent downstream nodes.
label be negotiated with all downstream LSRs for the LSP. This requires that the same label be negotiated with all downstream
LSRs for the LSP.
When there are several candidate upstream LSRs on a LAN interface, When there are several candidate upstream LSRs on an interface to a
the P2MP LDP mechanism SHOULD provide a way for all downstream LSRs multi-access LAN, the P2MP LDP mechanism SHOULD provide a way for all
of a given P2MP LSP to select the same upstream LSR, so as to avoid downstream LSRs of a given P2MP LSP to select the same upstream LSR,
traffic replication. In addition, the P2MP LDP mechanism SHOULD so as to avoid traffic replication. In addition, the P2MP LDP
allow for an efficient balancing of a set of P2MP LSPs among a set of mechanism SHOULD allow for an efficient balancing of a set of P2MP
candidate upstream LSRs on a LAN interface. LSPs among a set of candidate upstream LSRs on a LAN interface.
5.10. Support for encapsulation in P2P and P2MP TE tunnels 6.10. Support for encapsulation in P2P and P2MP TE tunnels
The P2MP LDP mechanism MUST support nesting P2MP LSPs into P2P and The P2MP LDP mechanism MUST support nesting P2MP LSPs into P2P and
P2MP TE tunnels. P2MP TE tunnels.
The P2MP LDP mechanism MUST provide a way for a Branch LSR of a P2MP The P2MP LDP mechanism MUST provide a way for a Branch LSR of a P2MP
LSP, which is also a Head End LSR of a P2MP TE tunnel, to send a LSP, which is also a Head End LSR of a P2MP TE tunnel, to send a
single copy of the data onto the tunnel and reach all downstream LSRs single copy of the data onto the tunnel and reach all downstream LSRs
on the P2MP LSP, which are also Egress LSRs of the tunnel. As with on the P2MP LSP, which are also Egress LSRs of the tunnel. As with
LAN interfaces, this requires that the same label be negotiated with LAN interfaces, this requires that the same label be negotiated with
all downstream LSRs of the P2MP LDP LSP. all downstream LSRs of the P2MP LDP LSP.
5.11. Label spaces 6.11. Label spaces
Labels for P2MP LSPs and P2P/MP2P LSPs MAY be assigned from shared or Labels for P2MP LSPs and P2P/MP2P LSPs MAY be assigned from shared or
dedicated label spaces. dedicated label spaces.
Note that dedicated label spaces will require the establishment of Note that dedicated label spaces will require the establishment of
separate P2P and P2MP LDP sessions. separate P2P and P2MP LDP sessions.
5.12. IPv4/IPv6 support 6.12. IPv4/IPv6 support
The P2MP LDP mechanism MUST support the establishment of LDP sessions The P2MP LDP mechanism MUST support the establishment of LDP sessions
over both IPv4 and IPv6 control planes. over both IPv4 and IPv6 control planes.
5.13. Multi-Area/AS LSPs 6.13. Multi-Area/AS LSPs
The P2MP LDP mechanism MUST support the establishment of multi-area The P2MP LDP mechanism MUST support the establishment of multi-area
P2MP LSPs, i.e. LSPs whose leaves do not all reside in the same IGP P2MP LSPs, i.e. LSPs whose leaves do not all reside in the same IGP
area as the Ingress LSR. This SHOULD be possible without requiring area as the Ingress LSR. This SHOULD be possible without requiring
the advertisement of Ingress LSRs' addresses across IGP areas. the advertisement of Ingress LSRs' addresses across IGP areas.
The P2MP LDP mechanism MUST also support the establishment of The P2MP LDP mechanism MUST also support the establishment of
inter-AS P2MP LSPs, i.e. LSPs whose leaves do not all reside in the inter-AS P2MP LSPs, i.e. LSPs whose leaves do not all reside in the
same AS as the Ingress LSR. This SHOULD be possible without same AS as the Ingress LSR. This SHOULD be possible without
requiring the advertisement of Ingress LSRs' addresses across ASes. requiring the advertisement of Ingress LSRs' addresses across ASes.
5.14. OAM 6.14. OAM
LDP management tools ([RFC3815], etc.) will have to be enhanced to LDP management tools ([RFC3815], etc.) will have to be enhanced to
support P2MP LDP extensions. This may yield a new MIB module, which support P2MP LDP extensions. This may yield a new MIB module, which
may possibly be inherited from the LDP MIB. may possibly be inherited from the LDP MIB.
Built-in diagnostic tools MUST be defined to check the connectivity, Built-in diagnostic tools MUST be defined to check the connectivity,
trace the path and ensure fast detection of data plane failures on trace the path and ensure fast detection of data plane failures on
P2MP LDP LSPs. P2MP LDP LSPs.
Further and precise requirements and mechanisms for P2MP MPLS OAM Further and precise requirements and mechanisms for P2MP MPLS OAM
purpose are out of the scope of this document and are addressed in purpose are out of the scope of this document and are addressed in
[RFC4687]. [RFC4687].
5.15. Graceful Restart and Fault Recovery 6.15. Graceful Restart and Fault Recovery
LDP Graceful Restart mechanisms [RFC3478] and Fault Recovery LDP Graceful Restart mechanisms [RFC3478] and Fault Recovery
mechanisms [RFC3479] SHOULD be enhanced to support P2MP LDP LSPs. mechanisms [RFC3479] SHOULD be enhanced to support P2MP LDP LSPs.
5.16. Robustness 6.16. Robustness
A solution MUST avoid single points of failures provided there is A solution MUST be designed to re-establish connectivity for P2MP and
enough network connectivity. MP2MP LSPs in the event of failures, provided there exists network
connectivity between ingress and egress nodes (i.e. designed without
introducing single points of failure).
5.17. Scalability 6.17. Scalability
Scalability is a key requirement for the P2MP LDP mechanism. It MUST Scalability is a key requirement for the P2MP LDP mechanism. It MUST
be designed to scale well with an increase in the number of any of be designed to scale well with an increase in the number of any of
the following: the following:
o number of Leaf LSRs per P2MP LSP; o number of Leaf LSRs per P2MP LSP;
o number of Downstream LSRs per Branch LSR; o number of Downstream LSRs per Branch LSR;
o number of P2MP LSPs per LSR. o number of P2MP LSPs per LSR.
In order to scale well with an increase in the number of leaves, it In order to scale well with an increase in the number of leaves, it
is RECOMMENDED that the size of a P2MP LSP state on a LSR, for one is RECOMMENDED that the size of a P2MP LSP state on a LSR, for one
particular LSP, depend only on the number of adjacent LSRs on the particular LSP, depend only on the number of adjacent LSRs on the
LSP. LSP.
5.17.1. Orders of magnitude expected in operational networks 6.17.1. Orders of magnitude expected in operational networks
Typical orders of magnitude that we expect should be supported are: Typical orders of magnitude that we expect should be supported are:
o tens of thousands of P2MP trees spread out across core network o tens of thousands of P2MP trees spread out across core network
routers; routers;
o hundreds, or a few thousands, of leaves per tree; o hundreds, or a few thousands, of leaves per tree;
See also section 4.2 of [RFC4834]. See also section 4.2 of [RFC4834].
5.18. Backward Compatibility 6.18. Backward Compatibility
In order to allow for a smooth migration, the P2MP LDP mechanism In order to allow for a smooth migration, the P2MP LDP mechanism
SHOULD offer as much backward compatibility as possible. In SHOULD offer as much backward compatibility as possible. In
particular, the solution SHOULD allow the setup of a P2MP LSP along particular, the solution SHOULD allow the setup of a P2MP LSP along
non-Branch Transit LSRs that do not support P2MP LDP extensions. non-Branch Transit LSRs that do not support P2MP LDP extensions.
Also, the P2MP LDP solution MUST co-exist with current LDP mechanisms Also, the P2MP LDP solution MUST co-exist with current LDP mechanisms
and inherit its capability sets from [RFC5036]. The P2MP LDP and inherit its capability sets from [RFC5036]. The P2MP LDP
solution MUST NOT impede the operation of P2P/MP2P LSPs. A P2MP LDP solution MUST NOT impede the operation of P2P/MP2P LSPs. A P2MP LDP
solution MUST be designed in such a way that it allows P2P/MP2P and solution MUST be designed in such a way that it allows P2P/MP2P and
P2MP LSPs to be signalled on the same interface. P2MP LSPs to be signalled on the same interface.
6. Shared Trees 7. Shared Trees
For traffic delivery between a group of N Leaf LSRs which are acting For traffic delivery between a group of N LSRs that act as egress
indifferently as Ingress or Egress LSRs, it may be useful to setup a and/or egress nodes on different P2MP flows, it may be useful to
shared tree connecting all these LSRs, instead of having N P2MP LSPs. setup a shared tree connecting all these LSRs, instead of having N
This would reduce the amount of control and forwarding state that has P2MP LSPs. This would reduce the amount of control and forwarding
to be maintained on a given LSR. state that has to be maintained on a given LSR.
There are actually two main options for supporting such shared trees: There are actually two main options for supporting such shared trees:
o This could rely on the applications protocols that use LDP LSPs. o This could rely on the applications protocols that use LDP LSPs.
A shared tree could consist of the combination of a MP2P LDP LSP A shared tree could consist of the combination of a MP2P LDP LSP
from Leafs LSRs to a given root node, with a P2MP LSP from this from Leafs LSRs to a given root node, with a P2MP LSP from this
root to Leaf LSRs. For instance with Multicast L3 VPN root to Leaf LSRs. For instance with Multicast L3 VPN
applications, it would be possible to build a shared tree by applications, it would be possible to build a shared tree by
combining (see [I-D.ietf-l3vpn-2547bis-mcast]): combining (see [I-D.ietf-l3vpn-2547bis-mcast]):
skipping to change at page 15, line 7 skipping to change at page 15, line 18
* with a P2MP LDP LSP from this root PE to each PE of the group. * with a P2MP LDP LSP from this root PE to each PE of the group.
o Or this could rely on a specific LDP mechanism allowing to setup o Or this could rely on a specific LDP mechanism allowing to setup
multipoint-to-multipoint MPLS LSPs (MP2MP LSPs). multipoint-to-multipoint MPLS LSPs (MP2MP LSPs).
The former approach (Combination of MP2P and P2MP LSPs at the The former approach (Combination of MP2P and P2MP LSPs at the
application level) is out of the scope of this document while the application level) is out of the scope of this document while the
latter (MP2MP LSPs) belong to the scope of this document. latter (MP2MP LSPs) belong to the scope of this document.
Requirements for the set up of MP2MP LSPs are listed below. Requirements for the set up of MP2MP LSPs are listed below.
6.1. Requirements for MP2MP LSPs 7.1. Requirements for MP2MP LSPs
A MP2MP LSP is a LSP connecting a group of Leaf LSRs acting A Multipoint-to-multipoint (MP2MP) LSP is an LSP connecting a group
indifferently as Ingress or Egress LSRs. Traffic sent by any Leaf of Leaf LSRs acting as Egress and/or Ingress LSRs. Traffic sent by
LSR is received by all other Leaf LSRs of the group. any Leaf LSR is received by all other Leaf LSRs of the group.
Procedures for setting up MP2MP LSPs with LDP SHOULD be specified. Procedures for setting up MP2MP LSPs with LDP SHOULD be specified.
An implementation that support P2MP LDP LSPs MAY also support MP2MP An implementation that support P2MP LDP LSPs MAY also support MP2MP
LDP LSP. LDP LSP.
The MP2MP LDP procedures MUST NOT impede the operations of P2MP LSP. The MP2MP LDP procedures MUST NOT impede the operations of P2MP LSP.
Requirements for P2MP LSPs, set forth in section 6, apply equally to Requirements for P2MP LSPs, set forth in Section 6, apply equally to
MP2MP LSPs. Particular attention should be given on the below MP2MP LSPs. Particular attention should be given on the below
requirements: requirements:
o The solution MUST support recovery upon link and transit node o The solution MUST support recovery upon link and transit node
failure and there MUST NOT be any single point of failure failure and be designed to re-establish connectivity for MP2MP
(provided network connectivity is redundant); LSPs in the event of failures, provided there exists network
connectivity between ingress and egress nodes (i.e. designed
without introducing single points of failure);
o The size of MP2MP state on a LSR, for one particular MP2MP LSP, o The size of MP2MP state on a LSR, for one particular MP2MP LSP,
SHOULD only depend on the number of adjacent LSRs on the LSP; SHOULD only depend on the number of adjacent LSRs on the LSP;
o Furthermore, the MP2MP LDP mechanism MUST avoid routing loops that o Furthermore, the MP2MP LDP mechanism MUST avoid routing loops that
may trigger exponential growth of traffic. Note that this may trigger exponential growth of traffic. Note that this
requirement is more challenging with MP2MP LSPs as a LSR can requirement is more challenging with MP2MP LSPs as a LSR may need
receive traffic for a given LSP on multiple interfaces. to receive traffic for a given LSP on multiple interfaces.
There are additional requirements specific to MP2MP LSPs: There are additional requirements specific to MP2MP LSPs:
o It is RECOMMENDED that a MP2MP MPLS LSP follow shortest paths to a o It is RECOMMENDED that a MP2MP MPLS LSP is built based on the
specific LSR called root LSR; unicast route to a specific LSR called root LSR;
o It is RECOMMENDED to define several root LSRs (e.g. a primary and o It is RECOMMENDED to define several root LSRs (e.g. a primary and
a backup) to ensure redundancy upon root LSR failure; a backup) to ensure redundancy upon root LSR failure;
o The receiver SHOULD NOT receive back a packet it has sent on the o The receiver SHOULD NOT receive back a packet it has sent on the
MP2MP LSP; MP2MP LSP;
o The solution SHOULD avoid that all traffic between any pair of o The solution SHOULD avoid that all traffic between any pair of
leaves is traversing a root LSR, and SHOULD as much as possible leaves is traversing a root LSR (similarly to PIM-Bidir trees) and
minimize the distance between two leaves (similarly to PIM-Bidir SHOULD provide the operator with means to minimize the delay
trees); between two leaves;
o It MUST be possible to check connectivity of a MP2MP LSP in both o It MUST be possible to check connectivity of a MP2MP LSP in both
directions. directions.
7. Evaluation criteria 8. Evaluation criteria
7.1. Performances 8.1. Performance
The solution will be evaluated with respect to the following The solution will be evaluated with respect to the following
criteria: criteria:
(1) Time to add or remove a Leaf LSR; (1) Efficiency of network resource usage;
(2) Time to repair a P2MP LSP in case of link or node failure; (2) Time to add or remove a Leaf LSR;
(3) Scalability (state size, number of messages, message size). (3) Time to repair a P2MP LSP in case of link or node failure;
(4) Scalability (state size, number of messages, message size).
Particularly the P2MP LDP mechanism SHOULD be designed with as key Particularly the P2MP LDP mechanism SHOULD be designed with as key
objective to minimize the additional amount of state and additional objective to minimize the additional amount of state and additional
processing required in the network. processing required in the network.
Also, the P2MP LDP mechanism SHOULD be designed so that convergence Also, the P2MP LDP mechanism SHOULD be designed so that convergence
times in case of link or node failure are minimized, in order to times in case of link or node failure are minimized, in order to
limit traffic disruption. limit traffic disruption.
7.2. Complexity and Risks 8.2. Complexity and Risks
The proposed solution SHOULD NOT introduce complexity to the current The proposed solution SHOULD NOT introduce complexity to the current
LDP operations to such a degree that it would affect the stability LDP operations to such a degree that it would affect the stability
and diminish the benefits of deploying such solution. and diminish the benefits of deploying such solution.
8. Security Considerations 9. Security Considerations
This document does not introduce any new security issue beyond those It is expected that addressing the requirements defined in this
inherent to LDP, and a P2MP LDP solution will rely on the security document should not introduce any new security issue beyond those
mechanisms defined in [RFC5036] (e.g. TCP MD5 Signature). inherent to LDP, and that a P2MP LDP solution will rely on the
security mechanisms defined in [RFC5036] (e.g. TCP MD5 Signature).
An evaluation of the security features for MPLS networks may be found An evaluation of the security features for MPLS networks may be found
in [RFC5920], and where issues or further work is identified by that in [RFC5920], and where issues or further work is identified by that
document, new security features or procedures for the MPLS protocols document, new security features or procedures for the MPLS protocols
will need to be developed. will need to be developed.
9. IANA Considerations 10. IANA Considerations
This informational document makes no requests to IANA for action. This informational document makes no requests to IANA for action.
10. Acknowledgments 11. Acknowledgments
We would like to thank Christian Jacquenet (France Telecom), Hitoshi We would like to thank Christian Jacquenet, Hitoshi Fukuda, Ina
Fukuda (NTT), Ina Minei (Juniper), Dean Cheng (Cisco), and Benjamin Minei, Dean Cheng, and Benjamin Niven-Jenkins, for their highly
Niven-Jenkins (BT), for their highly useful comments and suggestions. useful comments and suggestions. We would also like to thank Adrian
Farrel for reviewing this document before publication.
We would also like to thank authors of [RFC4461] from which some text We would also like to thank authors of [RFC4461] from which some of
of this document has been inspired. the text in this document has been inspired.
11. References 12. References
11.1. Normative References 12.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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
Label Switching Architecture", RFC 3031, January 2001. Label Switching Architecture", RFC 3031, January 2001.
[RFC3478] Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful [RFC3478] Leelanivas, M., Rekhter, Y., and R. Aggarwal, "Graceful
Restart Mechanism for Label Distribution Protocol", Restart Mechanism for Label Distribution Protocol",
RFC 3478, February 2003. RFC 3478, February 2003.
[RFC3479] Farrel, A., "Fault Tolerance for the Label Distribution [RFC3479] Farrel, A., "Fault Tolerance for the Label Distribution
Protocol (LDP)", RFC 3479, February 2003. Protocol (LDP)", RFC 3479, February 2003.
[RFC3815] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions [RFC3815] Cucchiara, J., Sjostrand, H., and J. Luciani, "Definitions
of Managed Objects for the Multiprotocol Label Switching of Managed Objects for the Multiprotocol Label Switching
(MPLS), Label Distribution Protocol (LDP)", RFC 3815, (MPLS), Label Distribution Protocol (LDP)", RFC 3815,
June 2004. June 2004.
[RFC4461] Yasukawa, S., "Signaling Requirements for Point-to-
Multipoint Traffic-Engineered MPLS Label Switched Paths
(LSPs)", RFC 4461, April 2006.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007. Specification", RFC 5036, October 2007.
11.2. Informative References 12.2. Informative References
[I-D.ietf-l2vpn-vpls-mcast] [I-D.ietf-l2vpn-vpls-mcast]
Aggarwal, R., Kamite, Y., Fang, L., and Y. Rekhter, Aggarwal, R., Kamite, Y., Fang, L., and Y. Rekhter,
"Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-08 (work "Multicast in VPLS", draft-ietf-l2vpn-vpls-mcast-08 (work
in progress), October 2010. in progress), October 2010.
[I-D.ietf-l3vpn-2547bis-mcast] [I-D.ietf-l3vpn-2547bis-mcast]
Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y.,
Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in
MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-10 (work MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-10 (work
in progress), January 2010. in progress), January 2010.
[I-D.ietf-mpls-ldp-p2mp]
Minei, I., Wijnands, I., Kompella, K., and B. Thomas,
"Label Distribution Protocol Extensions for Point-to-
Multipoint and Multipoint-to-Multipoint Label Switched
Paths", draft-ietf-mpls-ldp-p2mp-13 (work in progress),
April 2011.
[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, December 2001. Tunnels", RFC 3209, December 2001.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual [RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned Virtual
Private Network (VPN) Terminology", RFC 4026, March 2005. Private Network (VPN) Terminology", RFC 4026, March 2005.
[RFC4461] Yasukawa, S., "Signaling Requirements for Point-to-
Multipoint Traffic-Engineered MPLS Label Switched Paths
(LSPs)", RFC 4461, April 2006.
[RFC4687] Yasukawa, S., Farrel, A., King, D., and T. Nadeau, [RFC4687] Yasukawa, S., Farrel, A., King, D., and T. Nadeau,
"Operations and Management (OAM) Requirements for Point- "Operations and Management (OAM) Requirements for Point-
to-Multipoint MPLS Networks", RFC 4687, September 2006. to-Multipoint MPLS Networks", RFC 4687, September 2006.
[RFC4834] Morin, T., Ed., "Requirements for Multicast in Layer 3 [RFC4834] Morin, T., Ed., "Requirements for Multicast in Layer 3
Provider-Provisioned Virtual Private Networks (PPVPNs)", Provider-Provisioned Virtual Private Networks (PPVPNs)",
RFC 4834, April 2007. RFC 4834, April 2007.
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic "Extensions to Resource Reservation Protocol - Traffic
skipping to change at page 18, line 38 skipping to change at page 19, line 12
[RFC5501] Kamite, Y., Wada, Y., Serbest, Y., Morin, T., and L. Fang, [RFC5501] Kamite, Y., Wada, Y., Serbest, Y., Morin, T., and L. Fang,
"Requirements for Multicast Support in Virtual Private LAN "Requirements for Multicast Support in Virtual Private LAN
Services", RFC 5501, March 2009. Services", RFC 5501, March 2009.
[RFC5920] Fang, L., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, July 2010.
Authors' Addresses Authors' Addresses
Jean-Louis (editor) Jean-Louis Le Roux (editor)
France Telecom - Orange France Telecom - Orange
Email: jeanlouis.leroux@orange-ftgroup.com Email: jeanlouis.leroux@orange-ftgroup.com
Thomas Morin Thomas Morin (editor)
France Telecom - Orange France Telecom - Orange
Email: thomas.morin@orange-ftgroup.com Email: thomas.morin@orange-ftgroup.com
Vincent Parfait Vincent Parfait
France Telecom - Orange, Orange Business Services France Telecom - Orange, Orange Business Services
Email: vincent.parfait@orange-ftgroup.com Email: vincent.parfait@orange-ftgroup.com
Luyuan Fang Luyuan Fang
Cisco Systems, Inc. Cisco Systems, Inc.
Email: lufang@cisco.com Email: lufang@cisco.com
 End of changes. 87 change blocks. 
213 lines changed or deleted 218 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/