[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