--- 1/draft-ietf-mpls-mp-ldp-reqs-05.txt 2010-12-01 12:15:11.000000000 +0100 +++ 2/draft-ietf-mpls-mp-ldp-reqs-06.txt 2010-12-01 12:15:11.000000000 +0100 @@ -1,82 +1,88 @@ MPLS J. Le Roux, Ed. Internet-Draft T. Morin Intended status: Informational V. Parfait -Expires: May 30, 2011 France Telecom - Orange +Expires: June 4, 2011 France Telecom - Orange L. Fang Cisco L. Wang Telenor Y. Kamite NTT S. Amante Level3 - November 26, 2010 + December 01, 2010 Requirements for Point-To-Multipoint Extensions to the Label Distribution Protocol - draft-ietf-mpls-mp-ldp-reqs-05 + draft-ietf-mpls-mp-ldp-reqs-06 Abstract This document lists a set of functional requirements for Label Distribution Protocol (LDP) extensions for setting up point-to- multipoint (P2MP) Label Switched Paths (LSP), in order to deliver point-to-multipoint applications over a Multi Protocol Label Switching (MPLS) infrastructure. It is intended that solutions that specify LDP procedures for setting up P2MP LSP satisfy these requirements. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Status of this Memo - This Internet-Draft is submitted to IETF in full conformance with the + This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. + Task Force (IETF). Note that other groups may also distribute + working documents as Internet-Drafts. The list of current Internet- + Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - The list of current Internet-Drafts can be accessed at - http://www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on May 30, 2011. + This Internet-Draft will expire on June 4, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as - described in the BSD License. + described in the Simplified BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. Table of Contents 1. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Problem Statement and Requirements Overview . . . . . . . . . 6 3.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 6 3.2. Requirements overview . . . . . . . . . . . . . . . . . . 7 @@ -401,21 +407,21 @@ In order to scale well with a large number of leaves it is RECOMMENDED to follow a leaf-initiated P2MP LSP setup approach. For that purpose, leaves will have to be aware of the P2MP LSP 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 of this document. The P2MP LDP mechanism MUST allow the dynamic addition and removal of leaves to and from a P2MP LSP, without any restriction (provided 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. It is RECOMMENDED that these operations do not cause any additional processing except on the path from the added/removed Leaf LSR to the Branch LSR. 5.5. Label Advertisement The P2MP LDP mechanism MUST support downstream unsolicited label advertisement mode. This is well suited to a leaf-initiated approach and is consistent with P2P/MP2P LDP operations. @@ -432,21 +438,21 @@ Note, in particular, that data duplication might occur if P2MP LSP rerouting is being performed (See also section 6.8). 5.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 + avoidance mechanism MUST NOT impact the scalability of the P2MP LDP solution. The P2MP LDP mechanism SHOULD have a mechanism to avoid routing loops in the data plane even during transient events. Furthermore, the P2MP LDP mechanism MUST avoid routing loops in the data plane, that may trigger unexpected non-localized exponential growth of traffic. 5.8. P2MP LSP Re-routing @@ -597,21 +603,21 @@ 5.18. Backward Compatibility In order to allow for a smooth migration, the P2MP LDP mechanism SHOULD offer as much backward compatibility as possible. In particular, the solution SHOULD allow the setup of a P2MP LSP along non-Branch Transit LSRs that do not support P2MP LDP extensions. Also, the P2MP LDP solution MUST co-exist with current LDP mechanisms 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 to be signalled on the same interface. 6. Shared Trees For traffic delivery between a group of N Leaf LSRs which are acting indifferently as Ingress or Egress LSRs, it may be useful to setup a shared tree connecting all these LSRs, instead of having N P2MP LSPs. This would reduce the amount of control and forwarding state that has to be maintained on a given LSR. @@ -641,21 +647,21 @@ 6.1. Requirements for MP2MP LSPs A MP2MP LSP is a LSP connecting a group of Leaf LSRs acting indifferently as Ingress or Egress LSRs. Traffic sent by any Leaf LSR is received by all other Leaf LSRs of the group. Procedures for setting up MP2MP LSPs with LDP SHOULD be specified. 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. + The MP2MP LDP procedures MUST NOT impede the operations of P2MP LSP. Requirements for P2MP LSPs, set forth in section 6, apply equally to MP2MP LSPs. Particular attention should be given on the below requirements: o The solution MUST support recovery upon link and transit node failure and there MUST NOT be any single point of failure (provided network connectivity is redundant); o The size of MP2MP state on a LSR, for one particular MP2MP LSP, @@ -667,21 +673,21 @@ receive traffic for a given LSP on multiple interfaces. There are additional requirements specific to MP2MP LSPs: o It is RECOMMENDED that a MP2MP MPLS LSP follow shortest paths to a specific LSR called root LSR; o It is RECOMMENDED to define several root LSRs (e.g. a primary and 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; o The solution SHOULD avoid that all traffic between any pair of leaves is traversing a root LSR, and SHOULD as much as possible minimize the distance between two leaves (similarly to PIM-Bidir trees); o It MUST be possible to check connectivity of a MP2MP LSP in both directions. @@ -701,21 +707,21 @@ Particularly the P2MP LDP mechanism SHOULD be designed with as key objective to minimize the additional amount of state and additional processing required in the network. Also, the P2MP LDP mechanism SHOULD be designed so that convergence times in case of link or node failure are minimized, in order to limit traffic disruption. 7.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 and diminish the benefits of deploying such solution. 8. Security Considerations This document does not introduce any new security issue beyond those inherent to LDP, and 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