--- 1/draft-ietf-mpls-mp-ldp-reqs-01.txt 2007-03-02 22:13:40.000000000 +0100 +++ 2/draft-ietf-mpls-mp-ldp-reqs-02.txt 2007-03-02 22:13:40.000000000 +0100 @@ -1,35 +1,35 @@ Network Working Group J.-L. Le Roux (Editor) Internet Draft France Telecom Category: Informational -Expires: January 2007 T. Morin +Expires: September 2007 T. Morin France Telecom Vincent Parfait - Equant + Orange Business Services Luyuan Fang - AT&T + 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 - draft-ietf-mpls-mp-ldp-reqs-01.txt + draft-ietf-mpls-mp-ldp-reqs-02.txt Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other @@ -244,21 +244,21 @@ inherit its capability sets from [LDP]. It is of paramount importance that the P2MP LDP mechanism MUST NOT impede the operation of existing P2P/MP2P LSPs. The P2MP LDP mechanism MAY also allow setting up multipoint-to- multipoint (MP2MP) LSPs connecting a group of Leaf LSRs acting 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 LSR. -4. Application scenario +4. Application Scenario Figure 1 below illustrates an LDP enabled MPLS provider network, used to carry both unicast and multicast traffic of VPN customers following for instance the architecture defined in [2547-MCAST] for BGP/MPLS VPNs, or the one defined in [VPLS-MCAST]. A set of MP2P LDP LSPs are setup between 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 @@ -508,21 +508,21 @@ In order to facilitate correct management, P2MP LDP LSPs MUST have unique identifiers, otherwise it is impossible to determine which LSP is being managed. Built-in diagnostic tools MUST be defined to check the connectivity, trace the path and ensure fast detection of data plane failures on P2MP LDP LSPs. Further and precise requirements and mechanisms for P2MP MPLS OAM purpose are out of the scope of this document and are addressed in - [P2MP-OAM-REQ]. + [RFC4687]. 5.15. Graceful Restart and Fault Recovery LDP Graceful Restart mechanisms [LDP-GR] and Fault Recovery [LDP-FT] mechanisms SHOULD be enhanced to support P2MP LDP LSPs. 5.16. Robustness A solution MUST avoid single points of failures provided there is enough network connectivity. @@ -572,21 +572,21 @@ P2MP LSPs. This would reduce the amount of control and forwarding state that has to be maintained on a given LSR. There are actually two main options for supporting such shared trees: - This could rely on the applications protocols that use LDP 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 LSP from this root to all Leaf LSRs. For instance with 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 particular root PE acting as tree root, - with a P2MP LDP LSP from this root PE to each PEs of the Group. - Or this could rely on a specific LDP mechanism allowing to setup multipoint-to-multipoint MPLS LSPs (MP2MP LSPs). The former approach (Combination of MP2P and P2MP LSPs at the application level) is out of the scope of this document while the @@ -603,21 +603,21 @@ An implementation that support P2MP LDP LSPs MAY also support MP2MP LDP 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 MP2MP LSPs. Particular attention should be given on the below requirements: - 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 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, SHOULD only depend on the number of adjacent LSRs on the LSP; - Furthermore, the MP2MP LDP mechanism MUST avoid routing loops that may trigger exponential growth of traffic. Note that this requirement is more challenging with MP2MP LSPs as a LSR can receive traffic for a given LSP on multiple interfaces. @@ -706,63 +706,63 @@ [L2VPN-MCAST-REQ] Y. Kamite et al. "Requirements for Multicast Support in Virtual Private LAN Services", draft-ietf-l2vpn-vpls- mcast-reqts, work in progress. [2547-MCAST] E. Rosen, R. Aggarwal, et. al., "Multicast in MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast, work in progress. [VPLS-MCAST] R.Aggarwal, Y Kamite, L Fang, “VPLS Multicast” draft- ietf-l2vpn-vpls-mcast, work in progress. - [P2MP-OAM-REQ] S. Yasukawa, A. Farrel, D. King, T. Nadeau, "OAM - Requirements for Point-To-Multipoint MPLS Networks", draft-ietf-mpls- - p2mp-oam-reqs, work in progress. + [RFC4687] S. Yasukawa, A. Farrel, D. King, T. Nadeau, "OAM + Requirements for Point-To-Multipoint MPLS Networks", RFC4687, + September 2006. [P2MP-TE-REQ] S. Yasukawa, et. al., "Requirements for Point-to- Multipoint capability extension to MPLS", RFC4461, April 2006. [P2MP-TE-RSVP] R. Aggarwal, D. Papadimitriou, S. Yasukawa, et. al.., "Extensions to RSVP-TE for Point to Multipoint TE LSPs", draft-ietf- mpls-rsvp-te-p2mp, work in progress. 11. Editor Address Jean-Louis Le Roux France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE - Email: jeanlouis.leroux@orange-ft.com + Email: jeanlouis.leroux@orange-ftgroup.com 12. Contributors Addresses Thomas Morin France Telecom 2, avenue Pierre-Marzin 22307 Lannion Cedex FRANCE - Email: thomas.morin@orange-ft.com + Email: thomas.morin@orange-ftgroup.com Vincent Parfait - EQUANT + Orange Business Services 1041 Route des Dolines Sophia Antipolis 06560 Valbonne FRANCE - Email: vincent.parfait@orange-ft.com + Email: vincent.parfait@orange-ftgroup.com Luyuan Fang - AT&T - 200 Laurel Avenue - Middletown, NJ 07748 + Cisco Systems, Inc. + 300 Beaver Brook Road + Boxborough, MA 01719 USA - Email: luyuanfang@att.com + EMail: lufang@cisco.com Luyuan Fang Lei Wang Telenor Snaroyveien 30 Fornebu 1331 NORWAY Email: lei.wang@telenor.com Yuji Kamite NTT Communications Corporation @@ -798,23 +798,24 @@ http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET - ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, - INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE - INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + This document and the information contained herein are provided + on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE + REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE + IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL + WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY + WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE + ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS + FOR A PARTICULAR PURPOSE. Copyright Statement - Copyright (C) The Internet Society (2006). This document is subject - to the rights, licenses and restrictions contained in BCP 78, and - except as set forth therein, the authors retain all their rights. + Copyright (C) The IETF Trust (2007). This document is subject to the + rights, licenses and restrictions contained in BCP 78, and except as + set forth therein, the authors retain all their rights.