[mpls] Requesting Help With Unresolved P2MP MPLS TE Requirements
Seisho Yasukawa <yasukawa.seisho@lab.ntt.co.jp> Mon, 04 October 2004 15:49 UTC
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15413; Mon, 4 Oct 2004 11:49:54 -0400 (EDT)
Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEVFC-0003PF-80; Mon, 04 Oct 2004 11:59:22 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CEV4C-0006LH-SN; Mon, 04 Oct 2004 11:48:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CETz5-0004wj-6Y for mpls@megatron.ietf.org; Mon, 04 Oct 2004 10:38:42 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10218 for <mpls@ietf.org>; Mon, 4 Oct 2004 10:38:36 -0400 (EDT)
Received: from tama5.ecl.ntt.co.jp ([129.60.39.102]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CEU8A-0003hO-OO for mpls@ietf.org; Mon, 04 Oct 2004 10:48:03 -0400
Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i94Eb8ND019838; Mon, 4 Oct 2004 23:37:08 +0900 (JST)
Received: from vcs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i94Eb7Wa013430; Mon, 4 Oct 2004 23:37:07 +0900 (JST)
Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i94Eb7o0013427; Mon, 4 Oct 2004 23:37:07 +0900 (JST)
Received: from mfs3.rdh.ecl.ntt.co.jp (localhost [127.0.0.1]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i94Eb62r006049; Mon, 4 Oct 2004 23:37:07 +0900 (JST)
Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i94Eb6Ew006046; Mon, 4 Oct 2004 23:37:06 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i94Eb6il025291; Mon, 4 Oct 2004 23:37:06 +0900 (JST)
Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i94Eb5PR020337; Mon, 4 Oct 2004 23:37:06 +0900 (JST)
Received: from imc.m.ecl.ntt.co.jp (imc0.m.ecl.ntt.co.jp [129.60.5.141]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id i94Eb52H020334; Mon, 4 Oct 2004 23:37:05 +0900 (JST)
Received: from win-yasukawa.lab.ntt.co.jp by imc.m.ecl.ntt.co.jp (8.9.3p2/3.7W) with ESMTP id XAA21854; Mon, 4 Oct 2004 23:37:05 +0900 (JST)
Message-Id: <5.0.2.5.2.20041004232056.055feeb8@imc.m.ecl.ntt.co.jp>
X-Sender: sy003@imc.m.ecl.ntt.co.jp
X-Mailer: QUALCOMM Windows Eudora Version 5.0.2-J
Date: Mon, 04 Oct 2004 23:49:39 +0900
To: mpls@ietf.org
From: Seisho Yasukawa <yasukawa.seisho@lab.ntt.co.jp>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290
X-Mailman-Approved-At: Mon, 04 Oct 2004 11:47:58 -0400
Cc: andy.malis@tellabs.com, jpv@cisco.com, dimitri.papadimitriou@alcatel.be
Subject: [mpls] Requesting Help With Unresolved P2MP MPLS TE Requirements
X-BeenThere: mpls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/mpls>
List-Post: <mailto:mpls@lists.ietf.org>
List-Help: <mailto:mpls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@lists.ietf.org?subject=subscribe>
Sender: mpls-bounces@ietf.org
Errors-To: mpls-bounces@ietf.org
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c
Dear list, We have just published http://www.ietf.org/internet-drafts/draft-ietf-mpls-p2mp-requirement-04.txt which you would find a notable update on the previous revision. The draft contains changes to reflect feedback from the mailing list, private discussions, and from the work of the P2MP MPLS TE signaling solutions team. The draft, titled "Requirements for Point to Multipoint Traffic Engineered MPLS LSPs", aims to focus only on the requirements for establishing point-to-multipoint TE LSPs. That is, it is not concerned with multicast MPLS, but only with P2MP traffic engineering. Several issues remain unresolved in the current version of the draft and I (as editor) would like to solicit your input to help resolve them. The issues are described below and may be found in the draft by searching for the key word "DISCUSS". Please email your thoughts to the MPLS list or to me privately. Many thanks, Seisho Yasukawa ---------------------------------------------------- Issue 1 : Variation of LSP Parameters on different LSP Branches. (section 5.9) Is it a requirement that any of the parameters of an LSP (such as priority, bandwidth, etc.) are allowed to vary on different branches of the P2MP LSP? If so, which parameters and under what circumstances? Currently the draft states that no variation by any transit node is allowed for any parameter set by the ingress, and that homogenous QoS must be provided from the root to all leaves. ---------------------------------------------------- Issue 2 : Partial Re-optimization Initiated by Transit Nodes. (section 5.10) Is it a requirement that a branch node should be able to *independently* re-optimize the P2MP tree downstream of the branch point? There are two questions here: a. Should the branch node have the facility to set up an alternate P2MP tree downstream of the branch and then splice the traffic onto that tree, or should all re-optimization be as the result of the generation of a new P2MP path at the ingress? b. If the branch is capable of performing this function, should it be controlled (i.e. given explicit permission) by the ingress? ---------------------------------------------------- Issue 3 : Tree Re-merge (section 5.11) If (for whatever reason) the P2MP LSP re-merges what should be the behavior in the control and data planes? Consider a node that receives two LSP setup request messages on different upstream interfaces each relating to the same P2MP LSP, but each identifying a different set of receivers. (We may assume that somewhere upstream a branch decision was made that was not necessary.) Further, consider that the two LSP setup messages are forwarded out of the same downstream interface. What should happen in the data plane? There MUST/SHOULD/MAY/SHOULD_NOT be a sharing of labels and resources on the downstream interface? (see also issue 4) What should happen in the control plane? The downstream interface MUST/SHOULD/MAY/SHOULD_NOT see a single LSP setup message that is built by merging the two received requests? Or: should we say that this situation is pathologically broken and attempt to select only one of the setup requests while failing the other? ---------------------------------------------------- Issue 4 : Handling Data Duplication (section 5.12) Can data duplication be tolerated or must every possible measure be taken to prevent it? It is well-known that some applications are sensitive to the receipt of duplicate data, but the manipulation of P2MP trees, in particular in the presence of re-merge (see issue3), but also during tree modification procedures, may lead to duplicate data being delivered to a receiver. Thus, duplication may arise as the result of legitimate network operations. The draft currently states that the solution MUST provide a mechanism to resolve, limit or avoid data duplication at either or both of the point at which the data path diverges and the point at which the data paths converge. ---------------------------------------------------- Issue 5 : Absolute Limits and Design Targets (section 5.19.1) In order to guide the solutions team we have attempted to provide some limits for the scaling and rate of change of P2MP MPLS TE LSP. We are aware that limiting the requirements to traffic engineering should imply some qualitative differences from, say, multicast trees, but we have struggled with determining the absolutes (or even approximations) that are needed to help the solutions team prioritize the different features of the protocol solution. It may be that no specific values can be stated, but that some general principles do exist. Currently we are trying to make statements about the following points for an individual P2MP TE LSP. - Number of recipients. - Number of branch points. - Rate of change of recipients. - Rate of change of core topology. Are you satisfied with current text ? What are appropriate target conditions for above numbers ? ---------------------------------------------------- _______________________________________________ mpls mailing list mpls@lists.ietf.org https://www1.ietf.org/mailman/listinfo/mpls
- [mpls] Requesting Help With Unresolved P2MP MPLS … Seisho Yasukawa