draft-ietf-mpls-mp-ldp-reqs-02.txt   draft-ietf-mpls-mp-ldp-reqs-03.txt 
Network Working Group J.-L. Le Roux (Editor) Network Working Group J.-L. Le Roux (Editor)
Internet Draft France Telecom Internet Draft France Telecom
Category: Informational Category: Informational
Expires: September 2007 T. Morin November 2007
France Telecom
Vincent Parfait
Orange Business Services
Luyuan Fang
Cisco Systems, Inc.
Lei Wang
Telenor
Yuji Kamite
NTT Communications
Shane Amante
Level 3 Communications
Requirements for Point-To-Multipoint Extensions to Requirements for Point-To-Multipoint Extensions to
the Label Distribution Protocol the Label Distribution Protocol
draft-ietf-mpls-mp-ldp-reqs-02.txt draft-ietf-mpls-mp-ldp-reqs-03.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
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".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document lists a set of functional requirements for Label This document lists a set of functional requirements for Label
Distribution Protocol (LDP) extensions for setting up point-to- Distribution Protocol (LDP) extensions for setting up point-to-
multipoint (P2MP) Label Switched Paths (LSP), in order to deliver multipoint (P2MP) Label Switched Paths (LSP), in order to deliver
point-to-multipoint applications over a Multi Protocol Label point-to-multipoint applications over a Multi Protocol Label
Switching (MPLS) infrastructure. It is intended that solutions that Switching (MPLS) infrastructure. It is intended that solutions that
specify LDP procedures for setting up P2MP LSP satisfy these specify LDP procedures for setting up P2MP LSP satisfy these
requirements. requirements.
skipping to change at page 2, line 19 skipping to change at page 2, line 11
multipoint (P2MP) Label Switched Paths (LSP), in order to deliver multipoint (P2MP) Label Switched Paths (LSP), in order to deliver
point-to-multipoint applications over a Multi Protocol Label point-to-multipoint applications over a Multi Protocol Label
Switching (MPLS) infrastructure. It is intended that solutions that Switching (MPLS) infrastructure. It is intended that solutions that
specify LDP procedures for setting up P2MP LSP satisfy these specify LDP procedures for setting up P2MP LSP satisfy these
requirements. requirements.
Conventions used in this document Conventions used in this document
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 RFC-2119. document are to be interpreted as described in [RFC2119].
Table of Contents Table of Contents
1. Terminology.................................................3 1. Contributing Authors........................................3
2. Introduction................................................4 2. Definitions.................................................3
3. Problem Statement and Requirements Overview.................5 2.1. Acronyms....................................................3
3.1. Problem Statement...........................................5 2.2. Terminology.................................................3
3.2. Requirements overview.......................................5 3. Introduction................................................5
4. Application scenario........................................6 4. Problem Statement and Requirements Overview.................6
5. Detailed Requirements.......................................7 4.1. Problem Statement...........................................6
5.1. P2MP LSPs...................................................7 4.2. Requirements overview.......................................6
5.2. P2MP LSP FEC................................................7 5. Application scenario........................................7
5.3. P2MP LDP routing............................................8 6. Detailed Requirements.......................................8
5.4. Setting up, tearing down and modifying P2MP LSPs............8 6.1. P2MP LSPs...................................................8
5.5. Label Advertisement.........................................8 6.2. P2MP LSP FEC................................................8
5.6. Data Duplication............................................8 6.3. P2MP LDP routing............................................9
5.7. Avoiding loops..............................................9 6.4. Setting up, tearing down and modifying P2MP LSPs............9
5.8. P2MP LSP Re-routing.........................................9 6.5. Label Advertisement.........................................9
5.8.1. Rerouting upon Network Failure..............................9 6.6. Data Duplication............................................9
5.8.2. Rerouting on a Better Path..................................9 6.7. Detecting and Avoiding Loops...............................10
5.8.3. Rerouting upon Planned Maintenance.........................10 6.8. P2MP LSP Re-routing........................................10
5.9. Support for LAN interfaces.................................10 6.8.1. Rerouting upon Network Failure.............................10
5.10. Support for encapsulation in P2P and P2MP TE tunnels.......10 6.8.2. Rerouting on a Better Path.................................10
5.11. Label spaces...............................................10 6.8.3. Rerouting upon Planned Maintenance.........................11
5.12. IPv4/IPv6 support..........................................11 6.9. Support for LAN interfaces.................................11
5.13. Multi-Area LSPs............................................11 6.10. Support for encapsulation in P2P and P2MP TE tunnels.......11
5.14. OAM........................................................11 6.11. Label spaces...............................................11
5.15. Graceful Restart and Fault Recovery........................11 6.12. IPv4/IPv6 support..........................................11
5.16. Robustness.................................................11 6.13. Multi-Area/AS LSPs.........................................12
5.17. Scalability................................................11 6.14. OAM........................................................12
5.17.1. Orders of magnitude of the expected numbers of P2MP 6.15. Graceful Restart and Fault Recovery........................12
LSPs in operational networks.............................12 6.16. Robustness.................................................12
5.18. Backward Compatibility.....................................12 6.17. Scalability................................................12
6. Shared Trees...............................................12 6.17.1. Orders of magnitude expected in operational networks......13
6.1. Requirements for MP2MP LSPs................................13 6.18. Backward Compatibility.....................................13
7. Evaluation criteria........................................14 7. Shared Trees...............................................13
7.1. Performances...............................................14 7.1. Requirements for MP2MP LSPs................................14
7.2. Complexity and Risks.......................................14 8. Evaluation criteria........................................14
8. Security Considerations....................................14 8.1. Performances...............................................14
9. Acknowledgments............................................14 8.2. Complexity and Risks.......................................15
10. References.................................................14 9. Security Considerations....................................15
10.1. Normative references.......................................14 10. IANA Considerations........................................15
10.2. Informative references.....................................15 11. Acknowledgments............................................15
11. Editor Address.............................................15 12. References.................................................15
12. Contributors Addresses.....................................16 12.1. Normative references.......................................15
13. Intellectual Property Statement............................17 12.2. Informative references.....................................16
13. Editor's Address...........................................16
14. Contributors' Addresses....................................17
15. Intellectual Property Statement............................18
1. Terminology 1. Contributing Authors
LSR: Label Switching Router The co-authors listed below contributed to the text and content of
this document.
LSP: MPLS Label Switched Path Shane Amante, Level 3 Communications, LLC.
Luyuan Fang, Cisco Systems.
Yuji Kamite, NTT Communications Corporation.
Jean-Louis Le Roux, France Telecom.
Thomas Morin, France Telecom.
Vincent Parfait, Orange Business Services.
Lei Wang, Telenor.
Ingress LSR: Router acting as a sender of an LSP 2. Definitions
Egress LSR: Router acting as a receiver of an LSP 2.1. Acronyms
P2P LSP: A LSP that has one unique Ingress LSR and one unique P2P: Point-To-Point
P2MP: Point-To-MultiPoint
MP2MP: MultiPoint-To-Multipoint
PE: Provider Edge router
P: Provider router
IGP: Interior Gateway Protocol
AS: Autonomous System
2.2. Terminology
The reader is assumed to be familiar with the terminology in
[RFC3031], [RFC5036], and [RFC4026].
Ingress LSR:
Router acting as a sender of an LSP
Egress LSR:
Router acting as a receiver of an LSP
P2P LSP:
A LSP that has one unique Ingress LSR and one unique
Egress LSR Egress LSR
MP2P LSP: A LSP that has one or more Ingress LSRs and one unique MP2P LSP:
A LSP that has one or more Ingress LSRs and one unique
Egress LSR Egress LSR
P2MP LSP: A LSP that has one unique Ingress LSR and one or more P2MP LSP:
A LSP that has one unique Ingress LSR and one or more
Egress LSRs Egress LSRs
MP2MP LSP: A LSP that as one or more Leaf LSRs acting MP2MP LSP:
indifferently as Ingress or Egress LSR
Leaf LSR: Egress LSR of a P2MP LSP or Ingress/Egress LSR of a A LSP that as one or more Leaf LSRs acting indifferently as
MP2MP LSP Ingress or Egress LSR
Transit LSR: A LSR of a P2MP LSP that has one or more downstream Leaf LSR:
Egress LSR of a P2MP LSP or Ingress/Egress LSR of a MP2MP LSP
Transit LSR:
A LSR of a P2MP or MP2MP LSP that has one or more Downstream
LSRs LSRs
Branch LSR: A LSR of a P2MP LSP that has more than one downstream Branch LSR:
LSR
Bud LSR: A LSR of a P2MP LSP that is an egress but also has one or A LSR of a P2MP or MP2MP LSP that has more than one
more directly connected downstream LSRs downstream LSR
2. Introduction Bud LSR:
Many operators have deployed LDP [LDP] for setting up point-to-point A LSR of a P2MP or MP2MP LSP that is an egress but also
(P2P) and multipoint-to-point (MP2P) LSPs, in order to offer point-to has one or more directly connected downstream LSR(s)
-point services in MPLS backbones.
P2MP tree:
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.
3. Introduction
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
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
[L3VPN-MCAST-REQ] and [L2VPN-MCAST-REQ]. [RFC4834] and [L2VPN-MCAST-REQ].
This requires mechanisms for setting up point-to-multipoint LSPs This requires mechanisms for setting up point-to-multipoint LSPs
(P2MP LSP), i.e. LSPs with one Ingress LSR, a set of Egress LSRs, and (P2MP LSP), i.e. LSPs with one Ingress LSR, a set of Egress LSRs, and
with MPLS traffic replication at some Branch LSRs. 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 [P2MP-TE-RSVP]. Engineered LSPs (P2MP TE LSPs), have been defined in [RFC4875].
They meet requirements expressed in [P2MP-TE-REQ]. This approach is They meet requirements expressed in [RFC4461]. This approach is
useful, in network environments where P2MP Traffic Engineering useful, in network environments where P2MP Traffic Engineering
capabilities are needed (Optimization, QoS, Fast recovery). capabilities 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 have already deployed LDP for P2P traffic, an interesting and useful
approach would be to rely on LDP extensions in order to setup point- approach would be to rely on LDP extensions in order to setup point-
to-multipoint (P2MP) LSPs. This would bring consistency with P2P MPLS to-multipoint (P2MP) LSPs. This would bring consistency with P2P MPLS
applications and would ease the delivery of point-to-multipoint applications and would ease the delivery of point-to-multipoint
services in an MPLS backbone. services in an MPLS backbone.
skipping to change at page 4, line 52 skipping to change at page 5, line 52
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:
- Section 3 points out the problem statement; - Section 4 points out the problem statement;
- Section 4 illustrates an application scenario; - Section 5 illustrates an application scenario;
- Section 5 addresses detailed requirements for P2MP LSPs; - Section 6 addresses detailed requirements for P2MP LSPs;
- Section 6 finally discusses group communication, and - Section 7 finally discusses requirements for
requirements for MP2MP LSPs. MultiPoint-to-MultiPoint (MP2MP) LSPs.
3. Problem Statement and Requirements Overview 4. Problem Statement and Requirements Overview
3.1. Problem Statement 4.1. Problem Statement
Many operators have deployed LDP [LDP] for setting up P2P and MP2P LDP [RFC5036] has been deployed for setting up P2P and MP2P MPLS LSPs
MPLS LSPs as PE-to-PE tunnels so as to carry point-to-point traffic as PE-to-PE tunnels so as to carry point-to-point traffic essentially
essentially in Layer 3 and Layer 2 VPN networks. There are emerging in Layer 3 and Layer 2 VPN networks. There are emerging requirements
requirements for supporting multicast traffic delivery within these for supporting multicast traffic delivery within these VPN
VPN infrastructures ([L3VPN-MCAST-REQ] and [L2VPN-MCAST-REQ]). For infrastructures ([RFC4834] and [L2VPN-MCAST-REQ]). For various
various reasons, including consistency with P2P applications, and reasons, including consistency with P2P applications, and taking full
taking full advantages of MPLS network infrastructure, it would be advantages of MPLS network infrastructure, it would be highly
highly desirable to use MPLS LSPs for the delivery of multicast desirable to use MPLS LSPs for the delivery of multicast traffic.
traffic. This could be implemented by setting up a group of P2P or This could be implemented by setting up a group of P2P or MP2P LSPs,
MP2P LSPs, but such an approach may be sub-optimal since it would but such an approach may be sub-optimal since it would result in data
result in data replication at the ingress LSR, and bandwidth replication at the ingress LSR, and bandwidth inefficiency (duplicate
inefficiency (duplicate data traffic within the network). Hence new data traffic within the network). Hence new mechanisms are required
mechanisms are required that would allow traffic from an Ingress LSR that would allow traffic from an Ingress LSR to be efficiently
to be efficiently delivered to a number of Egress LSRs in an MPLS delivered to a number of Egress LSRs in an MPLS backbone, avoiding
backbone, avoiding duplicate copies of a packet on a given link. duplicate copies of a packet on a given link.
Such efficient traffic delivery requires setting up P2MP LSPs. A P2MP Such efficient traffic delivery requires setting up P2MP LSPs. A P2MP
LSP is an LSP starting at an Ingress LSR, and ending on a set of one 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 or more Egress LSRs. Traffic sent by the Ingress LSR is replicated on
one or more Branch LSRs down to Egress LSRs. one or more Branch LSRs down to Egress LSRs.
RSVP-TE extensions for setting up P2MP TE LSPs, which meet RSVP-TE extensions for setting up P2MP TE LSPs, which meet
requirements expressed in [P2MP-TE-REQ], have been defined in [P2MP- requirements expressed in [RFC4461], have been defined in [RFC4875].
TE-RSVP]. This approach is useful, in network environments where This approach is useful, in network environments where Traffic
Traffic Engineering capabilities are required. However, for operators Engineering capabilities are required. However, for operators that
that deployed LDP for setting up PE-to-PE unicast MPLS LSPs, and deployed LDP for setting up PE-to-PE unicast MPLS LSPs, and without
without the need for traffic engineering, an interesting approach the need for traffic engineering, an interesting approach would be
would be using LDP extensions for setting up P2MP LSPs. using LDP extensions for setting up P2MP LSPs.
The following gives a set of guidelines that a specification of LDP The following gives a set of guidelines that a specification of LDP
extensions for setting up P2MP LSPs should follow. extensions for setting up P2MP LSPs should follow.
3.2. Requirements overview 4.2. 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 [LDP]. It is of paramount importance inherit its capability sets from [RFC5036]. It is of paramount
that the P2MP LDP mechanism MUST NOT impede the operation of existing importance that the P2MP LDP mechanism MUST NOT impede the operation
P2P/MP2P LSPs. of existing P2P/MP2P LDP LSPs. Also the P2MP LDP mechanism MUST co-
exist with P2P and P2MP RSVP-TE mechanisms [RFC3209], [RFC4875]. It
is of paramount importance that the P2MP LDP mechanism MUST NOT
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 [2547-MCAST] for following for instance the architecture defined in [2547-MCAST] for
BGP/MPLS VPNs, or the one defined in [VPLS-MCAST]. BGP/MPLS VPNs, or the one defined in [VPLS-MCAST].
A set of MP2P LDP LSPs are setup between PE routers to carry unicast In this example, a set of MP2P LDP LSPs are setup between Provider
VPN traffic within the MPLS backbone. Edge (PE) routers to carry unicast VPN traffic within the MPLS
backbone.
A set of P2MP LDP LSPs are setup between PE routers acting as Ingress And in this example a set of P2MP LDP LSPs are setup between PE
LSRs and PE routers acting as Egress LSRs, so as to support multicast routers acting as Ingress LSRs and PE routers acting as Egress LSRs,
VPN traffic delivery within the MPLS backbone. so as to support multicast VPN traffic delivery within the MPLS
backbone.
For instance, a P2MP LDP LSP is setup between Ingress LSR PE1 and For instance, a P2MP LDP LSP is setup between Ingress LSR PE1 and
Egress LSRs PE2, PE3, and PE4. It is used to transport multicast Egress LSRs PE2, PE3, and PE4. It is used to transport multicast
traffic from PE1 to PE2, PE3 and PE4. P1 is a Branch LSR, it traffic from PE1 to PE2, PE3 and PE4. P1 is a Branch LSR, it
replicates MPLS traffic sent by PE1 to P2, P3 and PE2. P2 and P3 are replicates MPLS traffic sent by PE1 to P2, P3 and PE2. P2 and P3 are
non-branch transit LSRs, they forward MPLS traffic sent by P1 to PE3 non-branch transit LSRs, they forward MPLS traffic sent by P1 to PE3
and PE4 respectively. and PE4 respectively.
PE1 PE1
*| *** P2MP LDP LSP *| *** P2MP LDP LSP
skipping to change at page 7, line 20 skipping to change at page 8, line 20
*/ \* */ \*
*****/ \* *** *****/ \* ***
PE3----P2 P3----PE4 PE3----P2 P3----PE4
*| |* *| |*
*| |* *| |*
*| |* *| |*
PE5 PE6 PE5 PE6
Figure 2: Attachment of PE5 and PE6. Figure 2: Attachment of PE5 and PE6.
5. Detailed Requirements The above example is provided for the sake of illustration.
Note that P2MP LSPs ingress and egress LSRs may not necessarily be PE
routers. Also branch LSRs may not necessarily be P routers.
5.1. P2MP LSPs 6. Detailed Requirements
6.1. P2MP LSPs
The P2MP LDP mechanism MUST support setting up P2MP LSPs. The P2MP LDP mechanism MUST support setting up P2MP LSPs.
Data plane aspects related to P2MP LSPs are those already defined in Data plane aspects related to P2MP LSPs are those already defined in
[P2MP-TE-REQ]. That is, a P2MP LSP has one Ingress LSR and one or [RFC4461]. 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 more Egress LSRs. Traffic sent by the Ingress LSR is received by all
Egress LSRs. The specific aspects related to P2MP LSPs is the action Egress LSRs. The specific aspects related to P2MP LSPs is the action
required at a Branch LSR, where data replication occurs. required at a Branch LSR, where data replication occurs.
Incoming labelled data is appropriately replicated to several Incoming labelled data is appropriately replicated to several
outgoing interfaces which may use different labels. Only one copy of outgoing interfaces which may use different labels. Only one copy of
a packet MUST be sent on a given link of a P2MP LSP. a packet MUST be sent on a given link of a P2MP LSP.
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 within the whole LDP domain, whatever the number of leaves, which
may vary dynamically. may vary dynamically. This identifier will be used so as to
This identifier will be used so as to add/remove leaves to/from the add/remove leaves to/from the P2MP tree.
P2MP tree.
5.2. P2MP LSP FEC 6.2. P2MP LSP FEC
As with P2P MPLS technology [LDP], traffic MUST be classified into a As with P2P MPLS technology [RFC5036], traffic MUST be classified
FEC in this P2MP extension. All packets which belong to a particular into a FEC in this P2MP extension. All packets which belong to a
P2MP FEC and which travel from a particular node MUST use the same particular P2MP FEC and which travel from a particular node MUST use
P2MP LSP. the same P2MP LSP.
As such, a solution MUST specify a FEC that is suitable for P2MP As such, a new LDP FEC that is suitable for P2MP forwarding MUST be
forwarding. Such P2MP FEC MUST be distinguished clearly from the specified.
existing P2P FEC.
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 a shortest path
to the Ingress LSR so as to setup an MPLS shortest path tree. to the Ingress LSR so as to setup an MPLS shortest 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. network and a large amount of leaf LSRs for a single P2MP LSP (see
also section 5.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. operations be leaf-initiated.
These operations MUST not impact the data transfer (packet loss, These operations MUST not impact the data transfer (packet loss,
duplication, delay) towards other leaves. It is RECOMMENDED that duplication, delay) towards other leaves. It is RECOMMENDED that
these operations do not cause any additional processing except on the these operations do not cause any additional processing except on the
path from the added/removed Leaf LSR to the Branch LSR. path from the added/removed Leaf LSR to the Branch LSR.
5.5. Label Advertisement 6.5. Label Advertisement
The P2MP LDP mechanism SHOULD 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.
5.6. Data Duplication Other advertisement modes MAY also be supported.
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 be avoided as much as possible, 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 5.8). rerouting is being performed (See also section 6.8).
5.7. Avoiding loops 6.7. Detecting and Avoiding Loops
The P2MP LDP extension MUST have a mechanism to detect routing loops.
This may rely on extensions to the LDP Loop detection mechanism
defined in [RFC5036]. A loop detection mechanism may require
recording the set of LSRs traversed on the P2MP Tree. The P2MP loop
avoidance mechanism MUST not impact the scalability of the P2MP LDP
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
even during transient events. in the data plane even during transient events.
Furthermore, the P2MP LDP mechanism MUST avoid routing loops that may Furthermore, the P2MP LDP mechanism MUST avoid routing loops in the
trigger unexpected non-localized exponential growth of traffic. Note data plane, that may trigger unexpected non-localized exponential
that any loop-avoidance mechanism MUST respect scalability growth of traffic.
requirements.
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:
- Network failure (link or node); - Network failure (link or node);
- A better path exists (e.g. new link, metric change); - A better path exists (e.g. new link, metric change);
- Planned maintenance. - 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 also implies 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). The rerouting time SHOULD be minimized as of link or node failure(s), by relying upon update of the routes in
much as possible so as to reduce traffic disruption. the RIB. The rerouting time SHOULD be minimized as much as possible
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 rebuild which may be caused by the instability of a specific
link/node in the network. link/node in the network. This will rely on IGP dampening but may be
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.
Traffic disruption and data duplication SHOULD be minimized as much This will rely on update of the routes in the RIB.
as possible during such rerouting.
There is actually a tension between packet loss minimization and
packet duplication minimization objectives.
It SHOULD be feasible to avoid either data duplication or packet loss
during such rerouting.
A solution MAY provide the operator with means to choose between
favoring avoiding packet loss at the expense of potential packet
duplication, and favoring avoiding duplication against packet loss.
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. deactivated for maintenance purposes.
Traffic disruption and data duplication SHOULD be minimized as much Traffic disruption and data duplication SHOULD be minimized as much
as possible during such planned maintenance. as possible during such planned maintenance.
There is actually a tension between packet loss minimization and P2MP LSP rerouting upon planned maintenance MAY rely on a make before
packet duplication minimization objectives. break procedure.
It SHOULD be feasible to avoid either data duplication or packet loss
during such rerouting.
A solution MAY provide the operator with means to choose between
favoring avoiding packet loss at the expense of packet duplication,
and favoring avoiding duplication against packet loss.
5.9. Support for LAN interfaces 6.9. Support for LAN interfaces
The P2MP LDP mechanism MUST provide a way for a Branch LSR to send a The P2MP LDP mechanism SHOULD provide a way for a Branch LSR to send
single copy of the data onto an Ethernet LAN interface and reach a single copy of the data onto an Ethernet LAN interface and reach
multiple adjacent downstream nodes. This requires that the same label multiple adjacent downstream nodes. This requires that the same label
be negotiated with all downstream LSRs for the LSP. 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 a LAN interface,
the P2MP LDP mechanism MUST provide a way for all downstream LSRs of the P2MP LDP mechanism SHOULD provide a way for all downstream LSRs
a given P2MP LSP to select the same upstream LSR, so as to avoid of a given P2MP LSP to select the same upstream LSR, so as to avoid
traffic replication. traffic replication. In addition, the P2MP LDP mechanism SHOULD allow
In addition, the P2MP LDP mechanism SHOULD allow for an efficient for an efficient balancing of a set of P2MP LSPs among a set of
balancing of a set of P2MP LSPs among a set of candidate upstream candidate upstream LSRs on a LAN interface.
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 LDP label be negotiated LAN interfaces, this requires that the same label be negotiated with
with all downstream LSRs for 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 be equally applicable to IPv4 and IPv6
traffic. Likewise, it SHOULD be possible to convey both kinds of
traffic in a given P2MP LSP facility.
Also the P2MP LDP mechanism MUST support the establishment of LDP The P2MP LDP mechanism MUST support the establishment of LDP sessions
sessions over both IPv4 and IPv6 control planes. over both IPv4 and IPv6 control planes.
5.13. Multi-Area 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.
5.14. OAM 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 same AS
as the Ingress LSR. This SHOULD be possible without requiring the
advertisement of Ingress LSRs' addresses across ASes.
LDP management tools ([LDP-MIB], etc.) MUST be enhanced to support 6.14. OAM
P2MP LDP extensions. This may yield a new MIB module, which may
possibly be inherited from the LDP MIB.
In order to facilitate correct management, P2MP LDP LSPs MUST have LDP management tools ([RFC3815], etc.) will have to be enhanced to
unique identifiers, otherwise it is impossible to determine which LSP support P2MP LDP extensions. This may yield a new MIB module, which
is being managed. 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 [LDP-GR] and Fault Recovery [LDP-FT] LDP Graceful Restart mechanisms [RFC3478] and Fault Recovery
mechanisms 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 avoid single points of failures provided there is
enough network connectivity. enough network connectivity.
5.17. Scalability 6.17. Scalability
Scalability is a key requirement for the P2MP LDP mechanism. Scalability is a key requirement for the P2MP LDP mechanism.
It MUST be designed to scale well with an increase in the number of It MUST be designed to scale well with an increase in the number of
any of the following: any of the following:
- number of Leaf LSRs per P2MP LSP; - number of Leaf LSRs per P2MP LSP;
- number of Downstream LSRs per Branch LSR; - number of Downstream LSRs per Branch LSR;
- number of P2MP LSPs per LSR. - 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 of the expected numbers of P2MP LSPs in 6.17.1. Orders of magnitude expected in operational networks
operational networks
Typical orders of magnitude that we expect should be supported are: Typical orders of magnitude that we expect should be supported are:
- tens of thousands of P2MP trees spread out across core network - tens of thousands of P2MP trees spread out across core network
routers; routers;
- hundreds, or a few thousands, of leaves per tree; - hundreds, or a few thousands, of leaves per tree;
See also section 4.2 of [L3VPN-MCAST-REQ]. 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 [LDP]. The P2MP LDP solution 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 P2MP LSPs MUST be designed in such a way that it allows P2P/MP2P and P2MP LSPs
to be signalled on the same interface. 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 Leaf LSRs which are acting
indifferently as Ingress or Egress LSRs, it may be useful to indifferently as Ingress or Egress LSRs, it may be useful to
setup a shared tree connecting all these LSRs, instead of having N setup a shared tree connecting all these LSRs, instead of having N
P2MP LSPs. This would reduce the amount of control and forwarding P2MP LSPs. This would reduce the amount of control and forwarding
state that has 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:
- This could rely on the applications protocols that use LDP - This could rely on the applications protocols that use LDP
LSPs. A shared tree could consist of the combination of a LSPs. A shared tree could consist of the combination of a
MP2P LDP LSP from Leafs LSRs to a given root node, with a P2MP MP2P LDP LSP from Leafs LSRs to a given root node, with a P2MP
LSP from this root to all Leaf LSRs. For instance with LSP from this root to Leaf LSRs. For instance with
Multicast L3 VPN applications, it would be possible to build a Multicast L3 VPN applications, it would be possible to build a
shared tree by combining (see section 6.6 of [2547-MCAST]): shared tree by combining (see [2547-MCAST]):
- a MP2P unicast LDP LSP, from each PE of the group to a - a MP2P unicast LDP LSP, from each PE of the group to a
particular root PE acting as tree root, particular root PE acting as tree root,
- with a P2MP LDP LSP from this root PE to each PEs of the - with a P2MP LDP LSP from this root PE to each PE of the
Group. group.
- Or this could rely on a specific LDP mechanism allowing to - Or this could rely on a specific LDP mechanism allowing to
setup multipoint-to-multipoint MPLS LSPs (MP2MP LSPs). setup 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 MP2MP LSP is a LSP connecting a group of Leaf LSRs acting
indifferently as Ingress or Egress LSRs. Traffic sent by any Leaf indifferently as Ingress or Egress LSRs. Traffic sent by any Leaf LSR
LSRs is received by all other Leaf LSRs of the group. is received by all other Leaf LSRs of the group.
Procedures for setting up MP2MP LSPs 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 5 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:
- The solution MUST support recovery upon link and transit node - The solution MUST support recovery upon link and transit node
failure and there MUST NOT be any single point of failure (provided failure and there MUST NOT be any single point of failure (provided
network connectivity is redundant). Note that transit node network connectivity is redundant);
failure recovery is likely to be more complex to handle with MP2MP
LSPs than with P2MP LSPs;
- The size of MP2MP state on a LSR, for one particular MP2MP LSP, - 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;
- Furthermore, the MP2MP LDP mechanism MUST avoid routing loops that - 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 can
receive traffic for a given LSP on multiple interfaces. 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:
- It is RECOMMENDED that a MP2MP MPLS LSP follow shortest paths to a - It is RECOMMENDED that a MP2MP MPLS LSP follow shortest paths to a
skipping to change at page 14, line 5 skipping to change at page 14, line 46
a backup) to ensure redundancy upon root LSR failure; a backup) to ensure redundancy upon root LSR failure;
- The receiver SHOULD not receive back a packet it has sent on the - The receiver SHOULD not receive back a packet it has sent on the
MP2MP LSP; MP2MP LSP;
- The solution SHOULD avoid that all traffic between any pair of - 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, and SHOULD as much as possible
minimize the distance between two leaves (similarly to PIM-Bidir minimize the distance between two leaves (similarly to PIM-Bidir
trees); trees);
- It MUST be possible to check connectivity of a MP2MP LSP in both - 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. Performances
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) Time to add or remove a Leaf LSR;
(2) Time to repair a P2MP LSP in case of link or node (2) Time to repair a P2MP LSP in case of link or node
failure; failure;
(3) Scalability (state size, number of messages, message size). (3) 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 when deploying P2MP LDP. 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 P2MP LDP 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 This document does not introduce any new security issue beyond those
inherent to LDP, and a P2MP LDP solution may rely on the security inherent to LDP, and a P2MP LDP solution will rely on the security
mechanisms defined in [LDP] (e.g. TCP MD5 Signature). mechanisms defined in [RFC5036] (e.g. TCP MD5 Signature).
9. Acknowledgments An evaluation of the security features for MPLS networks may be found
in [MPLS-SEC], and where issues or further work is identified by that
document, new security features or procedures for the MPLS protocols
will need to be developed.
10. IANA Considerations
This informational document makes no requests to IANA for action.
11. Acknowledgments
We would like to thank Christian Jacquenet (France Telecom), We would like to thank Christian Jacquenet (France Telecom),
Hitoshi Fukuda (NTT Communications), Ina Minei (Juniper), Dean Hitoshi Fukuda (NTT Communications), Ina Minei (Juniper), Dean
Cheng (Cisco Systems), and Benjamin Niven-Jenkins (British Telecom), Cheng (Cisco Systems), Benjamin Niven-Jenkins (British Telecom),
for their highly useful comments and suggestions. and Loa Andersson (Acreo) for their useful comments and suggestions.
We would also like to thank authors of [P2MP-TE-REQ] from which some We would also like to thank authors of [RFC4461] from which some text
text of this document has been inspired. of this document has been inspired.
10. References 12. References
10.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.
[LDP] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas, [RFC5036] L. Andersson, I. Minei, B. Thomas, "LDP Specification", RFC
"LDP Specification", RFC 3036, January 2001 5036, September 2006.
[LDP-MIB] J. Cuchiarra et al. "Definitions of Managed Objects for the
[RFC3815] J. Cuchiarra et al. "Definitions of Managed Objects for the
Multiprotocol Label Switching (MPLS), Label Distribution Protocol Multiprotocol Label Switching (MPLS), Label Distribution Protocol
(LDP)", RFC3815, June 2004. (LDP)", RFC3815, June 2004.
[LDP-GR] M. Leelanivas, Y. Rekhter, R. Aggarwal, " Graceful Restart [RFC3478] M. Leelanivas, Y. Rekhter, R. Aggarwal, "Graceful Restart
Mechanism for Label Distribution Protocol" RFC3478, February 2003. Mechanism for Label Distribution Protocol" RFC3478, February 2003.
[LDP-FT] A. Farrel, " Fault Tolerance for the Label Distribution [RFC3479] A. Farrel, "Fault Tolerance for the Label Distribution
Protocol (LDP)", RFC3479, February 2003. Protocol (LDP)", RFC3479, February 2003.
10.2. Informative references 12.2. Informative references
[L3VPN-MCAST-REQ] T. Morin, Ed., "Requirements for Multicast in L3 [RFC4834] T. Morin, Ed., "Requirements for Multicast in L3
Provider-Provisioned VPNs", draft-ietf-l3vpn-ppvpn-mcast-reqts, work Provider-Provisioned VPNs", RFC 4834, April 2007.
in progress.
[L2VPN-MCAST-REQ] Y. Kamite et al. "Requirements for Multicast [L2VPN-MCAST-REQ] Y. Kamite et al. "Requirements for Multicast
Support in Virtual Private LAN Services", draft-ietf-l2vpn-vpls- Support in Virtual Private LAN Services", draft-ietf-l2vpn-vpls-
mcast-reqts, work in progress. mcast-reqts, work in progress.
[2547-MCAST] E. Rosen, R. Aggarwal, et. al., "Multicast in MPLS/BGP [2547-MCAST] E. Rosen, R. Aggarwal, et. al., "Multicast in MPLS/BGP
IP VPNs", draft-ietf-l3vpn-2547bis-mcast, work in progress. IP VPNs", draft-ietf-l3vpn-2547bis-mcast, work in progress.
[VPLS-MCAST] R.Aggarwal, Y Kamite, L Fang, “VPLS Multicast” draft- [VPLS-MCAST] R.Aggarwal, Y Kamite, L Fang, "VPLS Multicast" draft-
ietf-l2vpn-vpls-mcast, work in progress. ietf-l2vpn-vpls-mcast, work in progress.
[RFC4687] S. Yasukawa, A. Farrel, D. King, T. Nadeau, "OAM [RFC4687] S. Yasukawa, A. Farrel, D. King, T. Nadeau, "OAM
Requirements for Point-To-Multipoint MPLS Networks", RFC4687, Requirements for Point-To-Multipoint MPLS Networks", RFC4687,
September 2006. September 2006.
[P2MP-TE-REQ] S. Yasukawa, et. al., "Requirements for Point-to- [RFC4461] S. Yasukawa, et. al., "Requirements for Point-to-Multipoint
Multipoint capability extension to MPLS", RFC4461, April 2006. capability extension to MPLS", RFC 4461, April 2006.
[P2MP-TE-RSVP] R. Aggarwal, D. Papadimitriou, S. Yasukawa, et. al.., [RFC4875] R. Aggarwal, D. Papadimitriou, S. Yasukawa, et. al.,
"Extensions to RSVP-TE for Point to Multipoint TE LSPs", draft-ietf- "Extensions to RSVP-TE for Point to Multipoint TE LSPs", RFC 4875,
mpls-rsvp-te-p2mp, work in progress. May 2007.
11. Editor Address [RFC4026] Andersson, L., Madsen, T., "PPVPN Terminology", RFC 4026,
March 2005.
[RFC3209] Awduche, D, Berger, L., Gan, D., Li, T., Srinivasan, V.,
Swallow, G. "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209,
December 2001.
13. Editor's Address
Jean-Louis Le Roux Jean-Louis Le Roux
France Telecom France Telecom
2, avenue Pierre-Marzin 2, avenue Pierre-Marzin
22307 Lannion Cedex 22307 Lannion Cedex
FRANCE FRANCE
Email: jeanlouis.leroux@orange-ftgroup.com Email: jeanlouis.leroux@orange-ftgroup.com
12. Contributors Addresses 14. Contributors' Addresses
Thomas Morin Thomas Morin
France Telecom France Telecom
2, avenue Pierre-Marzin 2, avenue Pierre-Marzin
22307 Lannion Cedex 22307 Lannion Cedex
FRANCE FRANCE
Email: thomas.morin@orange-ftgroup.com Email: thomas.morin@orange-ftgroup.com
Vincent Parfait Vincent Parfait
Orange Business Services Orange Business Services
1041 Route des Dolines 1041 Route des Dolines
Sophia Antipolis Sophia Antipolis
06560 Valbonne 06560 Valbonne
FRANCE FRANCE
Email: vincent.parfait@orange-ftgroup.com Email: vincent.parfait@orange-ftgroup.com
Luyuan Fang Luyuan Fang
Cisco Systems, Inc. Cisco Systems, Inc.
300 Beaver Brook Road Email: lufang@cisco.com
Boxborough, MA 01719
USA
EMail: lufang@cisco.com Luyuan Fang
Lei Wang Lei Wang
Telenor Telenor
Snaroyveien 30 Snaroyveien 30
Fornebu 1331 Fornebu 1331
NORWAY NORWAY
Email: lei.wang@telenor.com Email: lei.wang@telenor.com
Yuji Kamite Yuji Kamite
NTT Communications Corporation NTT Communications Corporation
skipping to change at page 17, line 5 skipping to change at page 18, line 5
JAPAN JAPAN
Email: y.kamite@ntt.com Email: y.kamite@ntt.com
Shane Amante Shane Amante
Level 3 Communications, LLC Level 3 Communications, LLC
1025 Eldorado Blvd 1025 Eldorado Blvd
Broomfield, CO 80021 Broomfield, CO 80021
USA USA
Email: shane@level3.net Email: shane@level3.net
13. Intellectual Property Statement 15. Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 114 change blocks. 
264 lines changed or deleted 316 lines changed or added

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