[mpls] MPLS-TP Multipath
Curtis Villamizar <curtis@occnc.com> Tue, 28 February 2012 02:22 UTC
Return-Path: <curtis@occnc.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1BB821F8574 for <mpls@ietfa.amsl.com>; Mon, 27 Feb 2012 18:22:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWMwZYp5kDVo for <mpls@ietfa.amsl.com>; Mon, 27 Feb 2012 18:22:21 -0800 (PST)
Received: from gateway.ipv6.occnc.com (gateway.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:132]) by ietfa.amsl.com (Postfix) with ESMTP id 9C88021F856F for <mpls@ietf.org>; Mon, 27 Feb 2012 18:22:21 -0800 (PST)
Received: from newharbor.ipv6.occnc.com (newharbor.ipv6.occnc.com [IPv6:2001:470:1f07:1545::1:320]) (authenticated bits=0) by gateway.ipv6.occnc.com (8.14.5/8.14.5) with ESMTP id q1S2MGDu084801; Mon, 27 Feb 2012 18:22:17 -0800 (PST) (envelope-from curtis@occnc.com)
Message-Id: <201202280222.q1S2MGDu084801@gateway.ipv6.occnc.com>
To: mpls@ietf.org
From: Curtis Villamizar <curtis@occnc.com>
Date: Mon, 27 Feb 2012 21:22:16 -0500
Subject: [mpls] MPLS-TP Multipath
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: curtis@occnc.com
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 Feb 2012 02:22:25 -0000
FYI- Please discuss this on MPLS rather than on RTGWG. A separate message was sent to each WG to prevent accidental cross-posting. Sorry for the duplicate for those subscribed to both mailing lists. Curtis Briefly changes are as follows: mpls-tp-multipath: Change of author affiliation Switch from CCAMP to MPLS WG (error in prior draft) Numerous spelling corrections Added paragraph citing scaling work in RFC5439 and relevance. mpls-tp-multipath-te-extn: Change of author affiliation Numerous spelling corrections Multipath Link Capability TLV is added to Interface_ID, not Link Identification TLV as in prior version. ------- A new version of I-D, draft-villamizar-mpls-tp-multipath-02.txt has been successfully submitted by Curtis Villamizar and posted to the IETF repository. Filename: draft-villamizar-mpls-tp-multipath Revision: 02 Title: Use of Multipath with MPLS-TP and MPLS Creation date: 2012-02-27 WG ID: Individual Submission Number of pages: 35 Abstract: Many MPLS implementations have supported multipath techniques and many MPLS deployments have used multipath techniques, particularly in very high bandwidth applications, such as provider IP/MPLS core networks. MPLS-TP has discouraged the use of multipath techniques. Some degradation of MPLS-TP OAM performance cannot be avoided when operating over current high bandwidth multipath implementations. The tradeoffs involved in using multipath techniques with MPLS and MPLS-TP are described. Requirements are discussed which enable full MPLS-TP compliant LSP including full OAM capability to be carried over MPLS LSP which are traversing multipath links. Other means of supporting MPLS-TP coexisting with MPLS and multipath are discussed. ------- A new version of I-D, draft-villamizar-mpls-tp-multipath-te-extn-01.txt has been successfully submitted by Curtis Villamizar and posted to the IETF repository. Filename: draft-villamizar-mpls-tp-multipath-te-extn Revision: 01 Title: Multipath Extensions for MPLS Traffic Engineering Creation date: 2012-02-27 WG ID: Individual Submission Number of pages: 26 Abstract: Extensions to OSPF-TE, ISIS-TE, and RSVP-TE are defined in support of carrying LSP with strict packet ordering requirements over multipath and and carrying LSP with strict packet ordering requirements within LSP without violating requirements to maintain packet ordering. LSP with strict packet ordering requirements include MPLS-TP LSP. OSPF-TE and ISIS-TE extensions defined here indicate node and link capability regarding support for ordered aggregates of traffic, multipath traffic distribution, and abilities to support multipath load distribution differently per LSP. RSVP-TE extensions either identifies an LSP as requiring strict packet order, or identifies an LSP as carrying one or more LSP that requires strict packet order at a given depth in the label stack, or identifies an LSP as having no restrictions on packet ordering except the restriction to avoid reordering microflows. In addition an extension indicates whether the first nibble of payload will reliably indicate whether payload is IPv4, IPv6, or other type of payload, most notably pseudowire using a pseudowire control word. -------
- [mpls] MPLS-TP Multipath Curtis Villamizar