draft-ietf-mpls-mp-ldp-reqs-01.txt   draft-ietf-mpls-mp-ldp-reqs-02.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: January 2007 T. Morin Expires: September 2007 T. Morin
France Telecom France Telecom
Vincent Parfait Vincent Parfait
Equant Orange Business Services
Luyuan Fang Luyuan Fang
AT&T Cisco Systems, Inc.
Lei Wang Lei Wang
Telenor Telenor
Yuji Kamite Yuji Kamite
NTT Communications NTT Communications
Shane Amante Shane Amante
Level 3 Communications 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-01.txt draft-ietf-mpls-mp-ldp-reqs-02.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
skipping to change at page 6, line 11 skipping to change at page 6, line 11
inherit its capability sets from [LDP]. It is of paramount importance inherit its capability sets from [LDP]. It is of paramount importance
that the P2MP LDP mechanism MUST NOT impede the operation of existing that the P2MP LDP mechanism MUST NOT impede the operation of existing
P2P/MP2P LSPs. P2P/MP2P 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 4. 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 A set of MP2P LDP LSPs are setup between PE routers to carry unicast
VPN traffic within the MPLS backbone. VPN traffic within the MPLS backbone.
A set of P2MP LDP LSPs are setup between PE routers acting as Ingress A set of P2MP LDP LSPs are setup between PE routers acting as Ingress
skipping to change at page 11, line 37 skipping to change at page 11, line 37
In order to facilitate correct management, P2MP LDP LSPs MUST have In order to facilitate correct management, P2MP LDP LSPs MUST have
unique identifiers, otherwise it is impossible to determine which LSP unique identifiers, otherwise it is impossible to determine which LSP
is being managed. is being managed.
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
[P2MP-OAM-REQ]. [RFC4687].
5.15. Graceful Restart and Fault Recovery 5.15. Graceful Restart and Fault Recovery
LDP Graceful Restart mechanisms [LDP-GR] and Fault Recovery [LDP-FT] LDP Graceful Restart mechanisms [LDP-GR] and Fault Recovery [LDP-FT]
mechanisms SHOULD be enhanced to support P2MP LDP LSPs. mechanisms SHOULD be enhanced to support P2MP LDP LSPs.
5.16. Robustness 5.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.
skipping to change at page 12, line 48 skipping to change at page 12, line 48
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 all 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: shared tree by combining (see section 6.6 of [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 PEs 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
skipping to change at page 13, line 27 skipping to change at page 13, line 27
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 5 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 be no 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). Note that transit node
failure recovery is likely to be more complex to handle with MP2MP failure recovery is likely to be more complex to handle with MP2MP
LSPs than with P2MP LSPs; 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.
skipping to change at page 15, line 30 skipping to change at page 15, line 30
[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.
[P2MP-OAM-REQ] 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", draft-ietf-mpls- Requirements for Point-To-Multipoint MPLS Networks", RFC4687,
p2mp-oam-reqs, work in progress. September 2006.
[P2MP-TE-REQ] S. Yasukawa, et. al., "Requirements for Point-to- [P2MP-TE-REQ] S. Yasukawa, et. al., "Requirements for Point-to-
Multipoint capability extension to MPLS", RFC4461, April 2006. Multipoint capability extension to MPLS", RFC4461, April 2006.
[P2MP-TE-RSVP] R. Aggarwal, D. Papadimitriou, S. Yasukawa, et. al.., [P2MP-TE-RSVP] 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", draft-ietf-
mpls-rsvp-te-p2mp, work in progress. mpls-rsvp-te-p2mp, work in progress.
11. Editor Address 11. Editor 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-ft.com Email: jeanlouis.leroux@orange-ftgroup.com
12. Contributors Addresses 12. 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-ft.com Email: thomas.morin@orange-ftgroup.com
Vincent Parfait Vincent Parfait
EQUANT 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-ft.com Email: vincent.parfait@orange-ftgroup.com
Luyuan Fang Luyuan Fang
AT&T Cisco Systems, Inc.
200 Laurel Avenue 300 Beaver Brook Road
Middletown, NJ 07748 Boxborough, MA 01719
USA USA
Email: luyuanfang@att.com 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 31 skipping to change at page 17, line 31
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject Copyright (C) The IETF Trust (2007). This document is subject to the
to the rights, licenses and restrictions contained in BCP 78, and rights, licenses and restrictions contained in BCP 78, and except as
except as set forth therein, the authors retain all their rights. set forth therein, the authors retain all their rights.
 End of changes. 18 change blocks. 
27 lines changed or deleted 28 lines changed or added

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