From akatlas@gmail.com Thu Feb 16 16:14:06 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F4521E804B for ; Thu, 16 Feb 2012 16:14:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.272 X-Spam-Level: X-Spam-Status: No, score=-3.272 tagged_above=-999 required=5 tests=[AWL=0.327, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 SaytqjhmSj8O for ; Thu, 16 Feb 2012 16:14:06 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 22A9A21F8565 for ; Thu, 16 Feb 2012 16:14:06 -0800 (PST) Received: by iagf6 with SMTP id f6so4259026iag.31 for ; Thu, 16 Feb 2012 16:14:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=PpKHdDoC8YMzK2L0OsCAJAukuhjEI1etG9g1Lpk8G9c=; b=xK7uoEcqc25hFq+SFc+GseNAO3XrFPtjyypxzwpAtK/hfRo0jZg/RkEe9WMYrWzKXg DgcMjAsZH7PCrPrhrxSvg1Q5M3XqwTvKJdhNborL60ZxaqpKXJs+D81/vh3Z2sQ/NfaY 1uNtMumUHXhzDhIXMNd53FkP1i6aMoptjPyhI= MIME-Version: 1.0 Received: by 10.42.166.74 with SMTP id n10mr4677259icy.36.1329437645731; Thu, 16 Feb 2012 16:14:05 -0800 (PST) Received: by 10.50.87.197 with HTTP; Thu, 16 Feb 2012 16:14:05 -0800 (PST) Date: Thu, 16 Feb 2012 19:14:05 -0500 Message-ID: Subject: heads up - RTGWG may be scheduled Friday morning From: Alia Atlas To: rtgwg@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2012 00:14:06 -0000 Before everyone has definitely made their travel plans (I hope), I want to give a heads up that it is very likely that RTGWG will be meeting on Friday morning of IETF. It isn't definite, but we do need more time than was initially apparent. Regards, Alia From curtis@occnc.com Thu Feb 23 12:13:11 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570B521F88B3 for ; Thu, 23 Feb 2012 12:13:11 -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 W0f-aHU9AYsV for ; Thu, 23 Feb 2012 12:13:10 -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 EDC5A21F889F for ; Thu, 23 Feb 2012 12:13:07 -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 q1NKD1xr011267; Thu, 23 Feb 2012 12:13:01 -0800 (PST) (envelope-from curtis@occnc.com) Message-Id: <201202232013.q1NKD1xr011267@gateway.ipv6.occnc.com> To: rtgwg@ietf.org Subject: FYI - Composite Link Use Cases From: Curtis Villamizar Date: Thu, 23 Feb 2012 15:13:01 -0500 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 20:13:11 -0000 FYI- The "Composite Link Use Cases and Design Considerations" draft (draft-symmvo-rtgwg-cl-use-cases-00.txt) contains appendices removed from the "Composite Link Requirements" draft and some text removed from the "Composite Link Framework" draft. This puts use case information in one draft. The "Composite Link Requirements" draft 05 version was recently posted (draft-symmvo-rtgwg-cl-use-cases-00.txt). Comments on or off the WG mailing list would be very welcome. The "Composite Link Framework" draft 05 version should be available to the WG RSN. ETA is a week or two. The authors would like to advance these three documents more or less together. Only the "Composite Link Requirements" draft is currently a WG document. At the upcoming IETF we would like to ask that the additional two documents be considered as WG documents. Of course, it is up to the WG chairs to ask the WG for consensus on adapting a draft as a WG item. Curtis ------- Forwarded Message From: internet-drafts@ietf.org To: curtis@occnc.com Cc: dave.mcdysan@verizon.com, ning.so@verizonbusiness.com, andrew.g.malis@verizon.com, lucyyong@huawei.com, curtis@occnc.com Subject: New Version Notification for draft-symmvo-rtgwg-cl-use-cases-00.txt Message-ID: <20120222160513.17537.69186.idtracker@ietfa.amsl.com> Date: Wed, 22 Feb 2012 08:05:13 -0800 A new version of I-D, draft-symmvo-rtgwg-cl-use-cases-00.txt has been successfully submitted by Curtis Villamizar and posted to the IETF repository. Filename: draft-symmvo-rtgwg-cl-use-cases Revision: 00 Title: Composite Link USe Cases and Design Considerations Creation date: 2012-02-22 WG ID: Individual Submission Number of pages: 23 Abstract: This document provides a set of use cases and design considerations for composite links. Composite link is a formalization of multipath techniques currently in use in IP and MPLS networks and a set of extensions to multipath techniques. Note: symmvo in the draft name is the initials of the set of authors: So, Yong, McDysan, Malis, Villamizar, Osborne. This paragraph will be removed when/if this document is adopted as a WG item. The IETF Secretariat ------- End of Forwarded Message From curtis@occnc.com Mon Feb 27 18:17:19 2012 Return-Path: X-Original-To: rtgwg@ietfa.amsl.com Delivered-To: rtgwg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5E621E8036 for ; Mon, 27 Feb 2012 18:17:19 -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 4FtDwpIwH9jk for ; Mon, 27 Feb 2012 18:17:18 -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 3E3E521E8015 for ; Mon, 27 Feb 2012 18:17:18 -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 q1S2HEL7084609; Mon, 27 Feb 2012 18:17:14 -0800 (PST) (envelope-from curtis@occnc.com) Message-Id: <201202280217.q1S2HEL7084609@gateway.ipv6.occnc.com> To: rtgwg@ietf.org Subject: MPLS-TP Multipath From: Curtis Villamizar Date: Mon, 27 Feb 2012 21:17:14 -0500 X-BeenThere: rtgwg@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Routing Area Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 02:17:19 -0000 FYI- Please discuss this on MPLS rather than on RTGWG. 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. -------