From wwwrun@core3.amsl.com Wed Sep 2 07:39:56 2009 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id B76203A6BA7; Wed, 2 Sep 2009 07:39:56 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090902143956.B76203A6BA7@core3.amsl.com> Date: Wed, 2 Sep 2009 07:39:56 -0700 (PDT) Cc: mpls mailing list , mpls chair , Internet Architecture Board , RFC Editor Subject: [mpls] Protocol Action: 'Signaling LDP Label Advertisement Completion' to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Sep 2009 14:39:56 -0000 The IESG has approved the following document: - 'Signaling LDP Label Advertisement Completion ' as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-end-of-lib-04.txt Technical Summary There are situations following LDP session establishment where it would be useful for a Label Distribution Protocol (LDP) speaker to know when its peer has advertised all of its labels. For example, when an LDP speaker is using LDP-IGP synchronization procedures, it would be useful for the speaker to know when its peer has completed advertisement of its IP label bindings. Similarly, after an LDP session is re-established when LDP Graceful Restart is in effect, it would be helpful for each peer to signal the other after it has advertised all its label bindings. The LDP specification (RFC 5036) provides no mechanism for an LDP speaker to notify a peer when it has completed its initial label advertisements to that peer. This document specifies use of a Notification message with the "End- of-LIB" Status Code for an LDP speaker to signal completion of its label advertisements following session establishment. RFC 5036 implicitly assumes that new Status Codes will be defined over the course of time. However, it does not explicitly define the behavior of an LDP speaker which does not understand the Status Code in a Notification message. To avoid backward compatibility issues this document specifies use of the LDP capability mechanism at session establishment time for informing a peer that an LDP speaker is capable of handling a Notification message that carries an unrecognized Status Code. Working Group Summary Nothing of note. Document Quality There are no implementations that we know of. We have polled the WG list but received no responses Personnel Loa Andersson (loa@pi.nu) is the Document Shepherd. Adrian Farrel (adrian.farrel@huawei.com) is the Responsible Area Director. From root@core3.amsl.com Thu Sep 3 15:00:01 2009 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3A0333A6948; Thu, 3 Sep 2009 15:00:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090903220001.3A0333A6948@core3.amsl.com> Date: Thu, 3 Sep 2009 15:00:01 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-tp-nm-req-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Sep 2009 22:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS TP Network Management Requirements Author(s) : E. Gray, S. Mansfield, K. Lam Filename : draft-ietf-mpls-tp-nm-req-04.txt Pages : 25 Date : 2009-9-3 This document specifies the requirements for the management of equipment used in networks supporting an MPLS Transport Profile (MPLS-TP). The requirements are defined for specification of network management aspects of protocol mechanisms and procedures that constitute the building blocks out of which the MPLS transport profile is constructed. That is, these requirements indicate what management capabilities need to be available in MPLS for use in managing the MPLS-TP. This document is intended to identify essential network management capabilities, not to specify what functions any particular MPLS implementation supports. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-nm-req-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-tp-nm-req-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-9-3144826.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Sat Sep 5 17:45:01 2009 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 32A1B3A67F7; Sat, 5 Sep 2009 17:45:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090906004501.32A1B3A67F7@core3.amsl.com> Date: Sat, 5 Sep 2009 17:45:01 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-ldp-typed-wildcard-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Sep 2009 00:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : LDP Typed Wildcard FEC Author(s) : I. Minei, et al. Filename : draft-ietf-mpls-ldp-typed-wildcard-04.txt Pages : 10 Date : 2009-09-05 The LDP specification [RFC5036] for the Wildcard FEC element has several deficiencies. This document corrects those deficiencies. In addition, it specifies the Typed Wildcard FEC for the Prefix FEC Element Type defined in RFC5036. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-typed-wildcard-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-ldp-typed-wildcard-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-05173117.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Wed Sep 9 00:45:01 2009 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B7DF93A692F; Wed, 9 Sep 2009 00:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090909074501.B7DF93A692F@core3.amsl.com> Date: Wed, 9 Sep 2009 00:45:01 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-process-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 07:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Joint IETF and ITU-T Multi-Protocol Label Switching (MPLS) Transport Profile process Author(s) : L. Andersson, et al. Filename : draft-ietf-mpls-tp-process-00.txt Pages : 21 Date : 2009-09-08 The decision to develop a Multiprotocol Label Switching (MPLS) Transport Profile in cooperation between IETF and ITU-T does not fully define and document processes for development of the required RFCs. This document complements the processes documented in the JWT decision with a few separate elements; it: o provides an adaptation of the IETF working group process, o identifies the expected participation in the process by the ITU-T, o clarifies the decision rules regarding MPLS-TP documents. This document is not intended to specify any ITU-T process; to the extent necessary ITU-T activities will be done according to ITU-T process/rules. Nor is this document is intended to specify the IETF working group process, it is limited to the temporary adaptations of that process that is the result of that IETF and ITU-T accepted the proposal in the JWT report to jointly develop the MPLS Transport Profile. In general it may be said that these adaptations are introduced to ensure a good and consistent document review across the two organizations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-process-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-tp-process-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-09004208.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Wed Sep 9 03:45:01 2009 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4A59E28C1B0; Wed, 9 Sep 2009 03:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090909104501.4A59E28C1B0@core3.amsl.com> Date: Wed, 9 Sep 2009 03:45:01 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-process-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Sep 2009 10:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : IETF Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS-TP) Document Process Author(s) : L. Andersson, et al. Filename : draft-ietf-mpls-tp-process-01.txt Pages : 22 Date : 2009-09-09 The decision to develop a Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP) in cooperation between the IETF and the ITU-T is document in RFC 5317 as the decision of the Joint Working Team on MPLS-TP. This document provides additional detail of the processes for the development of IETF RFCs on MPLS-TP. It provides an adaptation of the IETF working group process; identifies the expected participation in the process by the ITU-T; and clarifies the rules and conventions regarding MPLS-TP documents. This document doe not specify any ITU-T process; ITU-T activities will be done according to ITU-T process/rules. This document does not specify or modify the normal IETF working group process. It is limited to the specific adaptations of that process to facilitate the cooperation agreement between the IETF and the ITU-T on MPLS-TP, and to ensure a good and consistent document review across the two organizations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-process-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-tp-process-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-09033336.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Thu Sep 10 05:15:01 2009 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B0D5128C12D; Thu, 10 Sep 2009 05:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090910121501.B0D5128C12D@core3.amsl.com> Date: Thu, 10 Sep 2009 05:15:01 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-gmpls-lsp-reroute-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 12:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : PathErr Message Triggered MPLS and GMPLS LSP Reroute Author(s) : L. Berger, et al. Filename : draft-ietf-mpls-gmpls-lsp-reroute-05.txt Pages : 12 Date : 2009-09-10 This document describes how Resource ReserVation Protocol (RSVP) PathErr Messages may be used to trigger rerouting of Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) point-to-point Traffic Engineering (TE) Label Switched Paths (LSPs) without first removing LSP state or resources. Such LSP rerouting may be desirable in a number of cases including, for example, soft-preemption and graceful shutdown. This document describes the usage of existing Standards Track mechanisms to support LSP rerouting. In this case, it relies on mechanisms already defined as part of RSVP-TE and simply describes a sequence of actions to be executed. While existing protocol definition can be used to support reroute applications, this document also defines a new reroute-specific error code to allow for the future definition of reroute application-specific error values. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-gmpls-lsp-reroute-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-gmpls-lsp-reroute-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-10051252.I-D@ietf.org> --NextPart-- From lberger@labn.net Thu Sep 10 05:21:33 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 693FE3A6A0F for ; Thu, 10 Sep 2009 05:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.023 X-Spam-Level: X-Spam-Status: No, score=-2.023 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b8tC5W7ABdV0 for ; Thu, 10 Sep 2009 05:21:32 -0700 (PDT) Received: from outbound-mail-09.bluehost.com (outbound-mail-09.bluehost.com [69.89.17.209]) by core3.amsl.com (Postfix) with SMTP id 6CA563A6A79 for ; Thu, 10 Sep 2009 05:21:32 -0700 (PDT) Received: (qmail 32263 invoked by uid 0); 10 Sep 2009 12:22:07 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by outboundproxy1.bluehost.com with SMTP; 10 Sep 2009 12:22:07 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=xzoT5yvT3CnLTD5soF4VSRN4rE1O8nBVKg/l8FqtyYyvxR7J3B3kL7oirlLVZAHeGW9fUxRk8SoJq8F6CIVbjMEoYho9Uj+rA5Og34+HvXKkp3QrK3bh3yTxa9PmWWh5; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1Mlif8-0000BM-T7; Thu, 10 Sep 2009 06:22:07 -0600 Message-ID: <4AA8EF7B.3010504@labn.net> Date: Thu, 10 Sep 2009 08:22:19 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090408 Eudora/3.0b2 MIME-Version: 1.0 To: mpls@ietf.org X-Enigmail-Version: 0.96a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: Francis Dupont , Jari Arkko , Adrian Farrel Subject: [mpls] [Fwd: I-D Action:draft-ietf-mpls-gmpls-lsp-reroute-05.txt] X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Sep 2009 12:21:33 -0000 FYI This update addresses editorial issues reported by IESG (Jari Arkko) and GEN-ART (Francis Dupont) review. Lou -------- Original Message -------- Subject: [mpls] I-D Action:draft-ietf-mpls-gmpls-lsp-reroute-05.txt Date: Thu, 10 Sep 2009 05:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org CC: mpls@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : PathErr Message Triggered MPLS and GMPLS LSP Reroute Author(s) : L. Berger, et al. Filename : draft-ietf-mpls-gmpls-lsp-reroute-05.txt Pages : 12 Date : 2009-09-10 This document describes how Resource ReserVation Protocol (RSVP) PathErr Messages may be used to trigger rerouting of Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) point-to-point Traffic Engineering (TE) Label Switched Paths (LSPs) without first removing LSP state or resources. Such LSP rerouting may be desirable in a number of cases including, for example, soft-preemption and graceful shutdown. This document describes the usage of existing Standards Track mechanisms to support LSP rerouting. In this case, it relies on mechanisms already defined as part of RSVP-TE and simply describes a sequence of actions to be executed. While existing protocol definition can be used to support reroute applications, this document also defines a new reroute-specific error code to allow for the future definition of reroute application-specific error values. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-gmpls-lsp-reroute-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From charliek@microsoft.com Fri Sep 4 13:51:09 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FFC53A68D0; Fri, 4 Sep 2009 13:51:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRvGFyRUexPv; Fri, 4 Sep 2009 13:51:05 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id BFF0A3A69BF; Fri, 4 Sep 2009 13:51:05 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 4 Sep 2009 13:51:19 -0700 Received: from TK5EX14MBXC119.redmond.corp.microsoft.com ([169.254.10.174]) by TK5EX14MLTC104.redmond.corp.microsoft.com ([157.54.79.159]) with mapi; Fri, 4 Sep 2009 13:51:19 -0700 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "jpv@cisco.com" , "swallow@cisco.com" , "ina@juniper.net" , "loa@pi.nu" , "mpls@ietf.org" Thread-Topic: Secdir review of draft-ietf-mpls-3209-patherr-05.txt Thread-Index: AcotoXN3v+1I0FP3SHuZTBolqUexgA== Date: Fri, 4 Sep 2009 20:51:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_D80EDFF2AD83E648BD1164257B9B09121C413CTK5EX14MBXC119red_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 11 Sep 2009 03:17:31 -0700 Subject: [mpls] Secdir review of draft-ietf-mpls-3209-patherr-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Sep 2009 20:51:09 -0000 --_000_D80EDFF2AD83E648BD1164257B9B09121C413CTK5EX14MBXC119red_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I am reviewing this document as part of the security directorate's ongoing = effort to review all IETF documents being processed by the IESG. These com= ments were written primarily for the benefit of the security area directors= . Document editors and WG chairs should treat these comments just like any= other last call comments. Feel free to forward to any appropriate forum. This document specifies a relatively minor clarification to RFC 3209, and a= s far as I can tell that clarification has no security consequences (unless= you call non-interoperability because of different interpretations of the = spec a security issue). Typos (maybe): In sections 2.1 and 2.1, I found 2 "must"s, 2 "must not"s, 2 "should"s, and= one "may" that I believe should have been all caps per RFC 2119. I've neve= r been very good at that distinction, however, so the authors MIGHT have it= right ;-) --_000_D80EDFF2AD83E648BD1164257B9B09121C413CTK5EX14MBXC119red_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am reviewing this document as part of t= he security directorate's ongoing effort to review all IETF documents being= processed by the IESG.  These comments were written primarily for the= benefit of the security area directors.  Document editors and WG chai= rs should treat these comments just like any other last call comments. Feel= free to forward to any appropriate forum.

 

This document specifies= a relatively minor clarification to RFC 3209, and as far as I can tell tha= t clarification has no security consequences (unless you call non-interoper= ability because of different interpretations of the spec a security issue).=

 

Typos (maybe):

 

<= p class=3DMsoNormal>In sections 2.1 and 2.1, I found 2 “must”s,= 2 “must not”s, 2 “should”s, and one “mayR= 21; that I believe should have been all caps per RFC 2119. I’ve never= been very good at that distinction, however, so the authors MIGHT have it = right ;-)

 

 

= --_000_D80EDFF2AD83E648BD1164257B9B09121C413CTK5EX14MBXC119red_-- From root@core3.amsl.com Fri Sep 11 08:45:01 2009 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5BF3428C0FF; Fri, 11 Sep 2009 08:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090911154501.5BF3428C0FF@core3.amsl.com> Date: Fri, 11 Sep 2009 08:45:01 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-framework-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Sep 2009 15:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : A Framework for MPLS in Transport Networks Author(s) : M. Bocci, et al. Filename : draft-ietf-mpls-tp-framework-04.txt Pages : 41 Date : 2009-09-11 This document specifies an architectural framework for the application of Multi Protocol Label Switching (MPLS) in transport networks, by enabling the construction of packet switched equivalents to traditional circuit switched carrier networks. It describes a common set of protocol functions--the MPLS Transport Profile (MPLS- TP)--that supports the operational models and capabilities typical of such networks, including signaled or explicitly provisioned bi- directional connection-oriented paths, protection and restoration mechanisms, comprehensive Operations, Administration and Maintenance (OAM) functions, and network operation in the absence of a dynamic control plane or IP forwarding support. Some of these functions exist in existing MPLS specifications, while others require extensions to existing specifications to meet the requirements of the MPLS-TP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-framework-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-tp-framework-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-11084215.I-D@ietf.org> --NextPart-- From liu.guoman@zte.com.cn Sun Sep 13 20:52:24 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B1F03A6988; Sun, 13 Sep 2009 20:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.738 X-Spam-Level: X-Spam-Status: No, score=-95.738 tagged_above=-999 required=5 tests=[AWL=-0.562, BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_83=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gEmCcExETD4K; Sun, 13 Sep 2009 20:52:23 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id C2B0E3A67CF; Sun, 13 Sep 2009 20:52:22 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 111641570495873; Mon, 14 Sep 2009 11:30:21 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.100] with StormMail ESMTP id 56182.1570495873; Mon, 14 Sep 2009 11:41:24 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n8E3p85H047324; Mon, 14 Sep 2009 11:51:08 +0800 (CST) (envelope-from liu.guoman@zte.com.cn) In-Reply-To: <20090914032210.372E63A685F@core3.amsl.com> To: mpls-tp@ietf.org, mpls@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Mon, 14 Sep 2009 11:50:56 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-09-14 11:51:01, Serialize complete at 2009-09-14 11:51:01 Content-Type: multipart/alternative; boundary="=_alternative 001528EF48257631_=" X-MAIL: mse1.zte.com.cn n8E3p85H047324 Subject: Re: [mpls] New Version Notification for draft-liu-mpls-tp-ring-protection-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2009 03:52:24 -0000 This is a multipart message in MIME format. --=_alternative 001528EF48257631_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksIGZlbGxvdyBhbmQgYWxsDQogaGVyZSBJIHByb3ZpZGUgYSBkcmFmdCBvZiBNUExTLVRQIHJp bmcgcHJvdGVjdGlvbiwgdGhlcmUgYXJlIHR3byANCnNvbHV0aW9ucyBvZiByaW5nIHByb3RlY3Rp b24sIHRoZXkgYm90aCBmdWxmaWwgdGhlIHJlcXVpcmVtZW50cyBvZiBtcGxzLXRwIA0KZnJhbWV3 b3JrIGFuZCBzdXJ2aXZlIHByb3RlY3Rpb25zLiBidXQgdGhlcmUgbWF5YmUgYSBmZXcgcXVlc3Rp b25zIHdoaWNoIEkgDQptYXkgbm90IGJlIGNvbnNpZGVyZWQsIHNvIGhlcmUgSSBhbSBwbGVhc3Vy ZWQgdG8gcmVjZWl2ZSAgZ29vZCBhZHZpY2UgYW5kIA0Kc3VnZ2VzdGlvbnMgZnJvbSBhbGwgZmVs bG93cy4NCg0KdGhhbmsgeW91ICB2ZXJ5IG11Y2guDQoNCmJlc3QgcmVnYXJkcw0KbGl1DQoNCg0K DQoNCg0KDQoNCg0KSUVURiBJLUQgU3VibWlzc2lvbiBUb29sIDxpZHN1Ym1pc3Npb25AaWV0Zi5v cmc+IA0KMjAwOS0wOS0xNCAxMToyMg0KDQrK1bz+yMsNCmxpdS5ndW9tYW5AenRlLmNvbS5jbg0K s63LzQ0KeWFuZ19qaWFuQHp0ZS5jb20uY24sIGppYW5nLmxpbGlAenRlLmNvbS5jbiwgZGFpLnh1 aWh1aUB6dGUuY29tLmNuDQrW98ziDQpOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yICAgICAg ICAgIGRyYWZ0LWxpdS1tcGxzLXRwLXJpbmctcHJvdGVjdGlvbi0wMA0KDQoNCg0KDQoNCg0KDQpB IG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGl1LW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uLTAw LnR4dCBoYXMgYmVlbiANCnN1Y2Nlc3NmdWx5IHN1Ym1pdHRlZCBieSBHdW9tYW4gTGl1IGFuZCBw b3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6ICAgICAgICAgICAgICAg ICBkcmFmdC1saXUtbXBscy10cC1yaW5nLXByb3RlY3Rpb24NClJldmlzaW9uOiAgICAgICAgICAg ICAgICAgMDANClRpdGxlOiAgICAgICAgICAgICAgICAgICAgICAgICAgICBNdWx0aXByb3RvY29s IExhYmVsIFN3aXRjaGluZyBUcmFuc3BvcnQgDQpQcm9maWxlIFJpbmcgUHJvdGVjdGlvbg0KQ3Jl YXRpb25fZGF0ZTogICAgICAgICAgICAyMDA5LTA5LTE0DQpXRyBJRDogICAgICAgICAgICAgICAg ICAgICAgICAgICAgSW5kZXBlbmRlbnQgU3VibWlzc2lvbg0KTnVtYmVyX29mX3BhZ2VzOiAxMw0K DQpBYnN0cmFjdDoNCmFjY29yZGluZyB0byBNUExTLVRQIFJlcXVpcmVtZW50IGRyYWZ0LCB0aGVy ZSBhcmUgdHdvIHJlcXVpcmVtZW50cyA6DQpyZXF1aXJlbWVudCA1Ni5CIFJlY292ZXJ5IHRlY2hu aXF1ZXMgdXNlZCBmb3IgUDJQIGFuZCBQMk1QIHNob3VsZCBiZQ0KaWRlbnRpY2FsIHRvIHNpbXBs aWZ5IGltcGxlbWVudGF0aW9uIGFuZCBvcGVyYXRpb24uYW5vdGhlciByZXF1aXJlIGFzDQpzZWN0 aW9uIDIuNS42LjEgZGVzY3JpYmxlczogd2l0aGluIHRoZSBjb250ZXh0IG9mIHJlY292ZXJ5IGlu IE1QTFMtVFANCm5ldHdvcmtzLHRoZSBvcHRpbWl6YXRpb24gY3JpdGVyaWEgY29uc2lkZXJlZCBp biByaW5nIHRvcG9sb2dpZXMgYXJlDQphcyBmb2xsb3dzOiAxIG1pbmltaXplIHRoZSBudW1iZXIg b2YgT0FNIGVudGl0aWVzIHRoYXQgYXJlIG5lZWRlZCB0bw0KdHJpZ2dlciB0aGUgcmVjb3Zlcnkg b3BlcmF0aW9uOyAyIE1pbmltaXplIHRoZSBudW1iZXIgb2YgZWxlbWVudHMgb2YNCnJlY292ZXJ5 IGluIHRoZSByaW5nOyAzIE1pbmltaXplIHRoZSBudW1iZXIgb2YgbGFiZWxzIHJlcXVpcmVkIGZv cg0KdGhlIHByb3RlY3Rpb24gcGF0aHMgYWNyb3NzIHRoZSByaW5nOyA0IG1pbmltaXplIHRoZSBh bW91bnQgb2YNCmNvbnRyb2wgYW5kIG1hbmFnZW1lbnQgcGxhbmUgdHJhbnNhY3Rpb25zIGR1cmlu ZyBhIG1haW50ZW5hbmNlDQpvcGVyYXRpb24uIHRoaXMgZGVjdW1lbnQgd2lsbCBkZXNjcmlibGUg YW5kIHByb3ZpZGUgdHdvIHR5cGVzIG9mIHJpbmcNCnByb3RlY3Rpb24gc29sdXRpb25zLiBib3Ro IHNvbHV0aW9ucyBjYW4gc2F0aXNmeSB0aGVzZSByZXF1aXJlbWVudHMNCm9mIHJlY292ZXJ5IGlu IG1wbHMtdHAgcmluZyBuZXR3b3JrLg0KICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdC4NCg0K DQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2Vu ZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRp YWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNy ZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhp cyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFu c21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3Ig dGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRy ZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5v dGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBp biB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMg bWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRp LVNwYW0gc3lzdGVtLg0K --=_alternative 001528EF48257631_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCBmZWxsb3cgYW5kIGFsbDwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7aGVyZSBJIHBy b3ZpZGUgYSBkcmFmdCBvZiBNUExTLVRQDQpyaW5nIHByb3RlY3Rpb24sIHRoZXJlIGFyZSB0d28g c29sdXRpb25zIG9mIHJpbmcgcHJvdGVjdGlvbiwgdGhleSBib3RoDQpmdWxmaWwgdGhlIHJlcXVp cmVtZW50cyBvZiBtcGxzLXRwIGZyYW1ld29yayBhbmQgc3Vydml2ZSBwcm90ZWN0aW9ucy4gYnV0 DQp0aGVyZSBtYXliZSBhIGZldyBxdWVzdGlvbnMgd2hpY2ggSSBtYXkgbm90IGJlIGNvbnNpZGVy ZWQsIHNvIGhlcmUgSSBhbQ0KcGxlYXN1cmVkIHRvIHJlY2VpdmUgJm5ic3A7Z29vZCBhZHZpY2Ug YW5kIHN1Z2dlc3Rpb25zIGZyb20gYWxsIGZlbGxvd3MuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj50aGFuayB5b3UgJm5ic3A7dmVyeSBtdWNoLjwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+YmVzdCByZWdhcmRz PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5saXU8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCjwvZm9udD4NCjx0YWJsZT4N Cjx0cj4NCjx0ZD4NCjxkaXYgYWxpZ249Y2VudGVyPjwvZGl2Pg0KPHRkPjwvdGFibGU+DQo8YnI+ DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0K PHRkIHdpZHRoPTI2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+SUVURiBJLUQg U3VibWlzc2lvbiBUb29sDQombHQ7aWRzdWJtaXNzaW9uQGlldGYub3JnJmd0OzwvYj4gPC9mb250 Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMDktMDktMTQgMTE6MjI8L2Zv bnQ+DQo8dGQgd2lkdGg9NzMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrV vP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+bGl1 Lmd1b21hbkB6dGUuY29tLmNuPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2 Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj55YW5nX2ppYW5AenRlLmNvbS5j biwgamlhbmcubGlsaUB6dGUuY29tLmNuLA0KZGFpLnh1aWh1aUB6dGUuY29tLmNuPC9mb250Pg0K PHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj5OZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yICZuYnNwOw0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ZHJhZnQtbGl1LW1wbHMtdHAtcmluZy1wcm90ZWN0aW9uLTAwPC9m b250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48 L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD48 YnI+DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGl1LW1wbHMtdHAtcmluZy1wcm90ZWN0 aW9uLTAwLnR4dCBoYXMgYmVlbg0Kc3VjY2Vzc2Z1bHkgc3VibWl0dGVkIGJ5IEd1b21hbiBMaXUg YW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Ljxicj4NCjxicj4NCkZpbGVuYW1lOiAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQom bmJzcDtkcmFmdC1saXUtbXBscy10cC1yaW5nLXByb3RlY3Rpb248YnI+DQpSZXZpc2lvbjogJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7MDA8YnI+DQpUaXRsZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCk11bHRpcHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nIFRy YW5zcG9ydCBQcm9maWxlIFJpbmcgUHJvdGVjdGlvbjxicj4NCkNyZWF0aW9uX2RhdGU6ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNw OzIwMDktMDktMTQ8YnI+DQpXRyBJRDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCkluZGVwZW5kZW50IFN1Ym1pc3Npb248YnI+ DQpOdW1iZXJfb2ZfcGFnZXM6IDEzPGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KYWNjb3JkaW5n IHRvIE1QTFMtVFAgUmVxdWlyZW1lbnQgZHJhZnQsIHRoZXJlIGFyZSB0d28gcmVxdWlyZW1lbnRz IDo8YnI+DQpyZXF1aXJlbWVudCA1Ni5CIFJlY292ZXJ5IHRlY2huaXF1ZXMgdXNlZCBmb3IgUDJQ IGFuZCBQMk1QIHNob3VsZCBiZTxicj4NCmlkZW50aWNhbCB0byBzaW1wbGlmeSBpbXBsZW1lbnRh dGlvbiBhbmQgb3BlcmF0aW9uLmFub3RoZXIgcmVxdWlyZSBhczxicj4NCnNlY3Rpb24gMi41LjYu MSBkZXNjcmlibGVzOiB3aXRoaW4gdGhlIGNvbnRleHQgb2YgcmVjb3ZlcnkgaW4gTVBMUy1UUDxi cj4NCm5ldHdvcmtzLHRoZSBvcHRpbWl6YXRpb24gY3JpdGVyaWEgY29uc2lkZXJlZCBpbiByaW5n IHRvcG9sb2dpZXMgYXJlPGJyPg0KYXMgZm9sbG93czogMSBtaW5pbWl6ZSB0aGUgbnVtYmVyIG9m IE9BTSBlbnRpdGllcyB0aGF0IGFyZSBuZWVkZWQgdG88YnI+DQp0cmlnZ2VyIHRoZSByZWNvdmVy eSBvcGVyYXRpb247IDIgTWluaW1pemUgdGhlIG51bWJlciBvZiBlbGVtZW50cyBvZjxicj4NCnJl Y292ZXJ5IGluIHRoZSByaW5nOyAzIE1pbmltaXplIHRoZSBudW1iZXIgb2YgbGFiZWxzIHJlcXVp cmVkIGZvcjxicj4NCnRoZSBwcm90ZWN0aW9uIHBhdGhzIGFjcm9zcyB0aGUgcmluZzsgNCBtaW5p bWl6ZSB0aGUgYW1vdW50IG9mPGJyPg0KY29udHJvbCBhbmQgbWFuYWdlbWVudCBwbGFuZSB0cmFu c2FjdGlvbnMgZHVyaW5nIGEgbWFpbnRlbmFuY2U8YnI+DQpvcGVyYXRpb24uIHRoaXMgZGVjdW1l bnQgd2lsbCBkZXNjcmlibGUgYW5kIHByb3ZpZGUgdHdvIHR5cGVzIG9mIHJpbmc8YnI+DQpwcm90 ZWN0aW9uIHNvbHV0aW9ucy4gYm90aCBzb2x1dGlvbnMgY2FuIHNhdGlzZnkgdGhlc2UgcmVxdWly ZW1lbnRzPGJyPg0Kb2YgcmVjb3ZlcnkgaW4gbXBscy10cCByaW5nIG5ldHdvcmsuPGJyPg0KICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDs8YnI+DQo8YnI+DQo8YnI+DQpUaGUgSUVURiBTZWNyZXRhcmlhdC48YnI+DQo8YnI+DQo8YnI+ DQo8YnI+DQo8L3R0PjwvZm9udD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0 aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24m bmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtz b2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtv cmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7 aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJv dmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2Vj cmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5i c3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNw O2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNw O2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7 aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNw O3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7 aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhl eSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJz cDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtw bGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0 aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7 aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJz cDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJz cDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDth bmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0u DQo8L3ByZT4= --=_alternative 001528EF48257631_=-- From wwwrun@core3.amsl.com Wed Sep 16 10:54:54 2009 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 2A5DB3A6B09; Wed, 16 Sep 2009 10:54:54 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090916175454.2A5DB3A6B09@core3.amsl.com> Date: Wed, 16 Sep 2009 10:54:54 -0700 (PDT) Cc: mpls mailing list , mpls chair , Internet Architecture Board , RFC Editor Subject: [mpls] Protocol Action: 'MPLS Traffic Engineering Soft Preemption' to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 17:54:54 -0000 The IESG has approved the following document: - 'MPLS Traffic Engineering Soft Preemption ' as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-soft-preemption-18.txt Technical Summary This document specifies MPLS-TE soft preemption through a number of protocol extensions. The goal is to reduce/eliminate traffic disruption on preempted TE LSPs. MPLS RSVP-TE is defined up to this point supported only immediate TE LSP displacement upon preemption. This document defines a reroute request notification which more gracefully mitigates the reroute process of the preempted TE LSP. This may lead to a sitution of under-provioning while soft preemption is executed. For this reason, the feature is primarily of interest in MPLS enabled IP networks with Differentiated Services and Traffic Engineering capabilities. Working Group Summary This document has been around for along time with a number of contentious issues. There have been several attempts to resolve the issues that gave rise to the creation of draft-ietf-mpls-3209-patherr and draft-ietf-mpls-gmpls-lsp-reroute to cover all issues. There were several major issues: - There were poor base definitions of the "normal" behavior. This meant that there was debate about whether these extensions were needed. - There was no clear definition of sot and hard preemption. This led to debate about exactly what was required and what was already available. - Existing specification for MPLS and GMPLS were not totally in synch. This led to debate over which of the potential ways forward that already existed was correct. After lengthy debate on the mailing list and in face-to-face meetings, this document was revised and the other two documents were produced. This led to WG consensus. Document Quality There are no known implementations of this document, but given the strength of support from one vendor and two carriers we may expect implementation soon. Personnel Loa Andersson is the Document Shepherd. Adrian Farrel is the Responsible Area Director. RFC Editor Note --- Section 1 para 1 OLD Understandably desirable features like ingress (Label Edge Router) LER automated (Traffic Engineering (TE) reservation adjustments are less palatable when preemption is intrusive and high network stability levels are a concern. NEW Understandably, desirable features like ingress Label Edge Router (LER) automated Traffic Engineering (TE) reservation adjustments are less palatable when preemption is intrusive and high network stability levels are a concern. --- Section 10 OLD This document does not introduce new security issues. The security considerations pertaining to the original RSVP protocol [RFC3209] remain relevant. NEW This document does not introduce new security issues. The security considerations pertaining to the original RSVP protocol [RFC3209] remain relevant. Further details about MPLS security considerations can be found in [I-D.ietf-mpls-mpls-and-gmpls-security]. As noted in Section 6.1, soft preemption may result in temporary link under provisioning condition while the soft preempted TE LSPs are rerouted by their respective head-end LSRs. Although this is a less serious condition than false hard preemption, and despite the mitigation procedures described in Section 6.1, network operators should be aware of the risk to their network should the soft preemption processes be subverted, and should apply the relevant MPLS control plane security techniques to protect against attacks. --- Section 13.2 ADD [I-D.ietf-mpls-mpls-and-gmpls-security] Fang, L. Ed., "Security Framework for MPLS and GMPLS Networks", draft-ietf-mpls- mpls-and-gmpls-security-framework-06.txt, work in progress. --- From web-usrn@ISI.EDU Wed Sep 16 11:04:17 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A2163A6B5A for ; Wed, 16 Sep 2009 11:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.874 X-Spam-Level: X-Spam-Status: No, score=-16.874 tagged_above=-999 required=5 tests=[AWL=0.725, BAYES_00=-2.599, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C-ncpt7KaOmd for ; Wed, 16 Sep 2009 11:04:15 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id E2B433A6A02 for ; Wed, 16 Sep 2009 11:04:15 -0700 (PDT) Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id n8GI4GL9022874; Wed, 16 Sep 2009 11:04:17 -0700 (PDT) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n8GI4E8H022845; Wed, 16 Sep 2009 11:04:14 -0700 (PDT) Date: Wed, 16 Sep 2009 11:04:14 -0700 (PDT) Message-Id: <200909161804.n8GI4E8H022845@boreas.isi.edu> To: tnadeau@cisco.com, jcucchiara@mindspring.com, rcallon@juniper.net, adrian.farrel@huawei.com, swallow@cisco.com, loa@pi.nu From: RFC Errata System X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: web-usrn@boreas.isi.edu Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] [Editorial Errata Reported] RFC3811 (1882) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Sep 2009 18:04:17 -0000 The following errata report has been submitted for RFC3811, "Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3811&eid=1882 -------------------------------------- Type: Editorial Reported by: Vishwas Manral Section: MplsLabel Original Text ------------- MplsLabel ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This value represents an MPLS label as defined in [RFC3031], [RFC3032], [RFC3034], [RFC3035] and [RFC3471]. The label contents are specific to the label being represented, such as: * The label carried in an MPLS shim header (for LDP this is the Generic Label) is a 20-bit number represented by 4 octets. Bits 0-19 contain a label or a reserved label value. Bits 20-31 MUST be zero. The following is quoted directly from [RFC3032]. There are several reserved label values: i. A value of 0 represents the 'IPv4 Explicit NULL Label'. This label value is only legal at the bottom of the label stack. It indicates that the label stack must be popped, and the forwarding of the packet must then be based on the Nadeau & Cucchiara Standards Track [Page 5] RFC 3811 MPLS TC MIB June 2004 IPv4 header. ii. A value of 1 represents the 'Router Alert Label'. This label value is legal anywhere in the label stack except at the bottom. When a received packet contains this label value at the top of the label stack, it is delivered to a local software module for processing. The actual forwarding of the packet is determined by the label beneath it in the stack. However, if the packet is forwarded further, the Router Alert Label should be pushed back onto the label stack before forwarding. The use of this label is analogous to the use of the 'Router Alert Option' in IP packets [RFC2113]. Since this label cannot occur at the bottom of the stack, it is not associated with a particular network layer protocol. iii. A value of 2 represents the 'IPv6 Explicit NULL Label'. This label value is only legal at the bottom of the label stack. It indicates that the label stack must be popped, and the forwarding of the packet must then be based on the IPv6 header. iv. A value of 3 represents the 'Implicit NULL Label'. This is a label that an LSR may assign and distribute, but which never actually appears in the encapsulation. When an LSR would otherwise replace the label at the top of the stack with a new label, but the new label is 'Implicit NULL', the LSR will pop the stack instead of doing the replacement. Although this value may never appear in the encapsulation, it needs to be specified in the Label Distribution Protocol, so a value is reserved. v. Values 4-15 are reserved. * The frame relay label can be either 10-bits or 23-bits depending on the DLCI field size and the upper 22-bits or upper 9-bits must be zero, respectively. * For an ATM label the lower 16-bits represents the VCI, the next 12-bits represents the VPI and the remaining bits MUST be zero. * The Generalized-MPLS (GMPLS) label contains a value greater than 2^24-1 and used in GMPLS as defined in [RFC3471]." REFERENCE "Multiprotocol Label Switching Architecture, RFC3031. MPLS Label Stack Encoding, [RFC3032]. Use of Label Switching on Frame Relay Networks, RFC3034. MPLS using LDP and ATM VC Switching, RFC3035. Generalized Multiprotocol Label Switching (GMPLS) Architecture, [RFC3471]." SYNTAX Unsigned32 (0..4294967295) Corrected Text -------------- MplsLabel ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "This value represents an MPLS label as defined in [RFC3031], [RFC3032], [RFC3034] and [RFC3035]. The label contents are specific to the label being represented, such as: * The label carried in an MPLS shim header (for LDP this is the Generic Label) is a 20-bit number represented by 4 octets. Bits 0-19 contain a label or a reserved label value. Bits 20-31 MUST be zero. The following is quoted directly from [RFC3032]. There are several reserved label values: i. A value of 0 represents the 'IPv4 Explicit NULL Label'. This label value is only legal at the bottom of the label stack. It indicates that the label stack must be popped, and the forwarding of the packet must then be based on the IPv4 header. ii. A value of 1 represents the 'Router Alert Label'. This label value is legal anywhere in the label stack except at the bottom. When a received packet contains this label value at the top of the label stack, it is delivered to a local software module for processing. The actual forwarding of the packet is determined by the label beneath it in the stack. However, if the packet is forwarded further, the Router Alert Label should be pushed back onto the label stack before forwarding. The use of this label is analogous to the use of the 'Router Alert Option' in IP packets [RFC2113]. Since this label cannot occur at the bottom of the stack, it is not associated with a particular network layer protocol. iii. A value of 2 represents the 'IPv6 Explicit NULL Label'. This label value is only legal at the bottom of the label stack. It indicates that the label stack must be popped, and the forwarding of the packet must then be based on the IPv6 header. iv. A value of 3 represents the 'Implicit NULL Label'. This is a label that an LSR may assign and distribute, but which never actually appears in the encapsulation. When an LSR would otherwise replace the label at the top of the stack with a new label, but the new label is 'Implicit NULL', the LSR will pop the stack instead of doing the replacement. Although this value may never appear in the encapsulation, it needs to be specified in the Label Distribution Protocol, so a value is reserved. v. Values 4-15 are reserved. * The frame relay label can be either 10-bits or 23-bits depending on the DLCI field size and the upper 22-bits or upper 9-bits must be zero, respectively. * For an ATM label the lower 16-bits represents the VCI, the next 12-bits represents the VPI and the remaining bits MUST be zero." REFERENCE "Multiprotocol Label Switching Architecture, RFC3031. MPLS Label Stack Encoding, [RFC3032]. Use of Label Switching on Frame Relay Networks, RFC3034. MPLS using LDP and ATM VC Switching, RFC3035." SYNTAX Unsigned32 (0..4294967295) Notes ----- The entire talk of having GMPLS label greater than (2^24 - 1)does not make sense at all. Removed the references to GMPLS in the MplsLabel TC. The same labels as MPLS labels can be signaled using MPLS or GMPLS signaling. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3811 (draft-ietf-mpls-tc-mib-10) -------------------------------------- Title : Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management Publication Date : June 2004 Author(s) : T. Nadeau, Ed., J. Cucchiara, Ed. Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From loa@pi.nu Fri Sep 18 00:20:59 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA69C3A687E; Fri, 18 Sep 2009 00:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.191 X-Spam-Level: X-Spam-Status: No, score=-1.191 tagged_above=-999 required=5 tests=[AWL=-1.006, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ozJoYIi7eGE; Fri, 18 Sep 2009 00:20:59 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id D94CC3A684B; Fri, 18 Sep 2009 00:20:58 -0700 (PDT) Received: from [192.168.0.100] (h133n2fls33o883.telia.com [217.208.62.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id BEF58D4048; Fri, 18 Sep 2009 09:21:48 +0200 (CEST) Message-ID: <4AB33508.9070105@pi.nu> Date: Fri, 18 Sep 2009 09:21:44 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "mpls-tp@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, ccamp@ietf.org, pwe3@ietf.org Subject: [mpls] wg last call on the mpls-tp-gach- gal draft ended. X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 07:20:59 -0000 All, the working group last call on draft-ietf-mpls-tp-gach-dcn-05.txt has ended and we have received comments from ITU-T (see https://datatracker.ietf.org/liaison/581/). Could the authors please address teh comments and re-publish the draft. /Loa -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From ice@cisco.com Fri Sep 18 01:52:23 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1E603A692F; Fri, 18 Sep 2009 01:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5dbEu77y-yC3; Fri, 18 Sep 2009 01:52:23 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id B500B3A6922; Fri, 18 Sep 2009 01:52:22 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n8I869dO005169; Fri, 18 Sep 2009 10:06:09 +0200 (CEST) Received: from ams-iwijnand-8715.cisco.com (ams-iwijnand-8715.cisco.com [10.55.191.150]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n8I8691w016703; Fri, 18 Sep 2009 10:06:09 +0200 (CEST) Message-Id: From: IJsbrand Wijnands To: mpls@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 18 Sep 2009 10:06:08 +0200 X-Mailer: Apple Mail (2.935.3) Cc: l3vpn@ietf.org Subject: [mpls] Regarding draft-wijnands-mpls-mldp-csc-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 08:52:23 -0000 Dear WG, I like to get some input from the WG regarding draft-wijnands-mpls- mldp-csc-01. I presented this draft in MPLS WG at IETF in Stockholm and got the comments from Yakov that this document contains work that belongs in L3VPN. It was suggested this document should be split in 2 different drafts, a non-L3VPN specific draft and a L3VPN specific draft. Considering how small the draft is and how close the non-L3VPN and L3VPN procedures are, I would prefer to keep this one draft. We can do a last call in both WG's and present it in L3VPN, but we do the work in MPLS. I would appreciate if you voice your opinion, after reading the draft :-) Thx, Ice. Appendix: This is small explanation on why procedures in section 3.1, 3.2 are considered to be L3VPN. The draft describes a procedure to use a Recursive Opaque encoding to help an mLDP LSP traverse a MPLS core that does not have reachability to the root of an LSP. Using the recursive Opaque encoding you temporarily replace the original FEC with a new FEC that has a root that is reachable. This procedure is useful in the VPN context and in the non-VPN context. The only difference is that you add an RD to the encoding for LSP's are that originated in the VPN context. From uwe@ujo.de Fri Sep 18 03:20:13 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B7FB3A6946; Fri, 18 Sep 2009 03:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAG7McaEOSBs; Fri, 18 Sep 2009 03:20:12 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id 320623A68D4; Fri, 18 Sep 2009 03:20:11 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id 16so386331fgg.13 for ; Fri, 18 Sep 2009 03:21:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.235.14 with SMTP id i14mr1599449fgh.52.1253269262459; Fri, 18 Sep 2009 03:21:02 -0700 (PDT) In-Reply-To: References: Date: Fri, 18 Sep 2009 12:21:02 +0200 Message-ID: <9475bb520909180321l51b0de41oae68a3520bfbd040@mail.gmail.com> From: Uwe Joorde To: IJsbrand Wijnands Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Fri, 18 Sep 2009 12:51:02 -0700 Cc: mpls@ietf.org, l3vpn@ietf.org Subject: Re: [mpls] Regarding draft-wijnands-mpls-mldp-csc-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 10:20:13 -0000 Ice, I fully agree with you, keeping the draft together. In my opinion a splitting would separate the draft in parts, which belong together and would slow down the process to get a working group document. This doesen't mean, that I don't accept Yakov's concerns regarding the draft at the Stockholm IEFT meeting, but I would vote to keep the draft as a whole for simplyfication. Cheers, Uwe Joorde 2009/9/18 IJsbrand Wijnands : > Dear WG, > > I like to get some input from the WG regarding > draft-wijnands-mpls-mldp-csc-01. > > I presented this draft in MPLS WG at IETF in Stockholm and got the comments > from Yakov that this document contains work that belongs in L3VPN. It was > suggested this document should be split in 2 different drafts, a non-L3VPN > specific draft and a L3VPN specific draft. > > Considering how small the draft is and how close the non-L3VPN and L3VPN > procedures are, I would prefer to keep this one draft. We can do a last call > in both WG's and present it in L3VPN, but we do the work in MPLS. > > I would appreciate if you voice your opinion, after reading the draft :-) > > Thx, > > Ice. > > Appendix: > > This is small explanation on why procedures in section 3.1, 3.2 are > considered to be L3VPN. The draft describes a procedure to use a Recursive > Opaque encoding to help an mLDP LSP traverse a MPLS core that does not have > reachability to the root of an LSP. Using the recursive Opaque encoding you > temporarily replace the original FEC with a new FEC that has a root that is > reachable. This procedure is useful in the VPN context and in the non-VPN > context. The only difference is that you add an RD to the encoding for LSP's > are that originated in the VPN context. > > > > From root@core3.amsl.com Fri Sep 18 15:15:01 2009 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 588913A695A; Fri, 18 Sep 2009 15:15:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090918221501.588913A695A@core3.amsl.com> Date: Fri, 18 Sep 2009 15:15:01 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-tp-nm-req-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Sep 2009 22:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS TP Network Management Requirements Author(s) : E. Gray, S. Mansfield, K. Lam Filename : draft-ietf-mpls-tp-nm-req-05.txt Pages : 25 Date : 2009-9-18 This document specifies the requirements for the management of equipment used in networks supporting an MPLS Transport Profile (MPLS-TP). The requirements are defined for specification of network management aspects of protocol mechanisms and procedures that constitute the building blocks out of which the MPLS transport profile is constructed. That is, these requirements indicate what management capabilities need to be available in MPLS for use in managing the MPLS-TP. This document is intended to identify essential network management capabilities, not to specify what functions any particular MPLS implementation supports. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-nm-req-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-tp-nm-req-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-9-18150359.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Fri Sep 18 17:00:04 2009 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 623653A6942; Fri, 18 Sep 2009 17:00:04 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090919000004.623653A6942@core3.amsl.com> Date: Fri, 18 Sep 2009 17:00:04 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-gach-dcn-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2009 00:00:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : An Inband Data Communication Network For the MPLS Transport Profile Author(s) : D. Beller, A. Farrel Filename : draft-ietf-mpls-tp-gach-dcn-06.txt Pages : 8 Date : 2009-09-18 The Generic Associated Channel (G-ACh) has been defined as a generalization of the pseudowire (PW) associated control channel to enable the realization of a control/communication channel associated with Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs), MPLS PWs, MPLS LSP segments, and MPLS sections between adjacent MPLS-capable devices. The MPLS Transport Profile (MPLS-TP) is a profile of the MPLS architecture that identifies elements of the MPLS toolkit that may be combined to build a carrier grade packet transport network based on MPLS packet switching technology. This document describes how the G-ACh may be used to provide the infrastructure that forms part of the Management Communication Network (MCN) and a Signaling Communication Network (SCN). Collectively, the MCN and SCN may be referred to as the Data Communication Network (DCN). This document explains how MCN and SCN messages are encapsulated, carried on the G-ACh, and demultiplexed A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-gach-dcn-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-tp-gach-dcn-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-18164955.I-D@ietf.org> --NextPart-- From loa@pi.nu Sat Sep 19 03:43:41 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0619F3A6946; Sat, 19 Sep 2009 03:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.386 X-Spam-Level: X-Spam-Status: No, score=-2.386 tagged_above=-999 required=5 tests=[AWL=0.213, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vL9qZCiIURtR; Sat, 19 Sep 2009 03:43:39 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id A06353A6883; Sat, 19 Sep 2009 03:43:38 -0700 (PDT) Received: from [192.168.0.100] (h133n2fls33o883.telia.com [217.208.62.133]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 34994D4048; Sat, 19 Sep 2009 12:44:33 +0200 (CEST) Message-ID: <4AB4B60E.8050800@pi.nu> Date: Sat, 19 Sep 2009 12:44:30 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "mpls-tp@ietf.org" Content-Type: multipart/mixed; boundary="------------080203070604050803030307" Cc: mpls@ietf.org, ccamp@ietf.org, pwe3@ietf.org Subject: [mpls] publication requested for draft-ietf-mpls-tp-nm-req-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2009 10:43:41 -0000 This is a multi-part message in MIME format. --------------080203070604050803030307 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, We requested publication of draft-ietf-mpls-tp-nm-req-05.txt as an RFC on te standards track. The shepherd write-up is included. /Loa -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 --------------080203070604050803030307 Content-Type: text/plain; name="mpls-tp-nm-req-A.txt" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="mpls-tp-nm-req-A.txt" VGhlIE1QTFMgV0cgcmVxdWVzdHMgdGhhdDoNCiAgIE1QTFMgVFAgTmV0d29yayBNYW5hZ2Vt ZW50IFJlcXVpcmVtZW50cw0KICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1tcGxzLXRwLW5tLXJlcS0wNA0KaXMgcHVibGlzaGVkIGFzIGFuIFJGQyBvbiB0aGUg c3RhbmRhcmRzIHRyYWNrLg0KDQpOb3RlIHRoYXQgdGhpcyBkb2N1bWVudCBpcyBhIHJlcXVp cmVtZW50IGRvY3VtZW50LiBGb3IgcmVhc29ucyB0aGF0DQpoYXZlIHRvIGRvIHdpdGggaG93 IHRoZSBJVFUtVCBjYW4gcmVmZXJlbmNlIFJGQ3Mgd2UgaGF2ZSBvcHRlZCB0byBwdXQNCml0 IG9uIHRoZSBTdGFuZGFyZHMgVHJhY2suDQoNCj4gKDEuYSkgV2hvIGlzIHRoZSBEb2N1bWVu dCBTaGVwaGVyZCBmb3IgdGhpcyBkb2N1bWVudD8gSGFzIHRoZQ0KPiAgICAgICBEb2N1bWVu dCBTaGVwaGVyZCBwZXJzb25hbGx5IHJldmlld2VkIHRoaXMgdmVyc2lvbiBvZiB0aGUNCj4g ICAgICAgZG9jdW1lbnQgYW5kLCBpbiBwYXJ0aWN1bGFyLCBkb2VzIGhlIG9yIHNoZSBiZWxp ZXZlIHRoaXMNCj4gICAgICAgdmVyc2lvbiBpcyByZWFkeSBmb3IgZm9yd2FyZGluZyB0byB0 aGUgSUVTRyBmb3IgcHVibGljYXRpb24/DQoNCkxvYSBBbmRlcnNzb24gaXMgdGhlIERvY3Vt ZW50IFNoZXBoZXJkLg0KSGUgaGFzIHJldmlld2VkIHRoZSBjb2R1bWVudCBhbmQgYmVsaWV2 ZXMgaXQgaXMgcmVhZHkgdG8gYmUNCmZvcndhcmRlZCB0byB0aGUgSUVTRyBmb3IgcHVibGlj YXRpb24uDQoNCj4gKDEuYikgSGFzIHRoZSBkb2N1bWVudCBoYWQgYWRlcXVhdGUgcmV2aWV3 IGJvdGggZnJvbSBrZXkgV0cgbWVtYmVycw0KPiAgICAgICBhbmQgZnJvbSBrZXkgbm9uLVdH IG1lbWJlcnM/IERvZXMgdGhlIERvY3VtZW50IFNoZXBoZXJkIGhhdmUNCj4gICAgICAgYW55 IGNvbmNlcm5zIGFib3V0IHRoZSBkZXB0aCBvciBicmVhZHRoIG9mIHRoZSByZXZpZXdzIHRo YXQNCj4gICAgICAgaGF2ZSBiZWVuIHBlcmZvcm1lZD8NCg0KVGhlIHJldmlldyBoYXMgYmVl biBzdWJzdGFudGlhbC4NCkNvbnNpZGVyYWJsZSBpbnB1dCB0byBlYXJseSByZXZpc2lvbnMg d2FzIHJlY2VpdmVkIGZyb20gTVBMUyBXRw0KcGFydGljaXBhbnRzIGFuZCBmcm9tIGEgZGV0 YWlsZWQgcmV2aWV3IGJ5IG1lbWJlcnMgb2YgSVRVLVQgU3R1ZHkNCkdyb3VwIDE1Lg0KDQpU aGUgV0cgbGFzdCBjYWxsIHdhcyBsaWFpc2VkIHRvIHRoZSBJVFUtVCBhbmQgcmVjZWl2ZWQg YSBudW1iZXIgb2YNCmNvbW1lbnRzIHRoYXQgd2VyZSBhZGRyZXNzZWQgaW4gdGhlIGZpbmFs IHJldmlzaW9uIHRoYXQgd2FzIGFwcHJvdmVkDQpieSB0aGUgSVRVLVQgaW4gYSBsaWFpc29u Lg0KDQpUaGUgV0cgbGFzdCBjYWxsIHdhcyBub3RpZmllZCB0byB0aGUgUFdFMyBhbmQgQ0NB TVAgd29ya2luZyBncm91cHMuDQoNCj4gKDEuYykgRG9lcyB0aGUgRG9jdW1lbnQgU2hlcGhl cmQgaGF2ZSBjb25jZXJucyB0aGF0IHRoZSBkb2N1bWVudA0KPiAgICAgICBuZWVkcyBtb3Jl IHJldmlldyBmcm9tIGEgcGFydGljdWxhciBvciBicm9hZGVyIHBlcnNwZWN0aXZlLA0KPiAg ICAgICBlLmcuLCBzZWN1cml0eSwgb3BlcmF0aW9uYWwgY29tcGxleGl0eSwgc29tZW9uZSBm YW1pbGlhciB3aXRoDQo+ICAgICAgIEFBQSwgaW50ZXJuYXRpb25hbGl6YXRpb24gb3IgWE1M Pw0KDQpOby4gVGhlIGRvY3VtZW50IGluY2x1ZGVzIGRldGFpbHMgb2YgbmV0d29yayBtYW5h Z2VtZW50IGZlYXR1cmVzLCBidXQNCndhcyBhdXRob3JlZCBhbmQgcmV2aWV3ZWQgYnkgbWFu eSBwZW9wbGUgYWN0aXZlIGluIHRoZSBPcGVyYXRpb25zIEFyZWEuDQoNCj4gKDEuZCkgRG9l cyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQgaGF2ZSBhbnkgc3BlY2lmaWMgY29uY2VybnMgb3IN Cj4gICAgICAgaXNzdWVzIHdpdGggdGhpcyBkb2N1bWVudCB0aGF0IHRoZSBSZXNwb25zaWJs ZSBBcmVhIERpcmVjdG9yDQo+ICAgICAgIGFuZC9vciB0aGUgSUVTRyBzaG91bGQgYmUgYXdh cmUgb2Y/IEZvciBleGFtcGxlLCBwZXJoYXBzIGhlDQo+ICAgICAgIG9yIHNoZSBpcyB1bmNv bWZvcnRhYmxlIHdpdGggY2VydGFpbiBwYXJ0cyBvZiB0aGUgZG9jdW1lbnQsIG9yDQo+ICAg ICAgIGhhcyBjb25jZXJucyB3aGV0aGVyIHRoZXJlIHJlYWxseSBpcyBhIG5lZWQgZm9yIGl0 LiBJbiBhbnkNCj4gICAgICAgZXZlbnQsIGlmIHRoZSBXRyBoYXMgZGlzY3Vzc2VkIHRob3Nl IGlzc3VlcyBhbmQgaGFzIGluZGljYXRlZA0KPiAgICAgICB0aGF0IGl0IHN0aWxsIHdpc2hl cyB0byBhZHZhbmNlIHRoZSBkb2N1bWVudCwgZGV0YWlsIHRob3NlDQo+ICAgICAgIGNvbmNl cm5zIGhlcmUuIEhhcyBhbiBJUFIgZGlzY2xvc3VyZSByZWxhdGVkIHRvIHRoaXMgZG9jdW1l bnQNCj4gICAgICAgYmVlbiBmaWxlZD8gSWYgc28sIHBsZWFzZSBpbmNsdWRlIGEgcmVmZXJl bmNlIHRvIHRoZQ0KPiAgICAgICBkaXNjbG9zdXJlIGFuZCBzdW1tYXJpemUgdGhlIFdHIGRp c2N1c3Npb24gYW5kIGNvbmNsdXNpb24gb24NCj4gICAgICAgdGhpcyBpc3N1ZS4NCg0KT25l IG9mZi1saW5lIGNvbW1lbnQgdGhhdCBoYXMgYmVlbiBmb3J3YXJkZWQgdG8gdGhlIHNoZXBo ZXJkIGlzIHRoYXQNCnRoZSBzdHlsZSBvZiB0aGUgZG9jdW1lbnQgaXMgdG9vIG11Y2ggb2Yg YW4gSVRVLVQgZG9jdW1lbnQuIFRoaXMNCmNvbW1lbnQgd2FzIG5vdCByYWlzZWQgb24gdGhl IGxpc3QgYW5kIHNlZW1zIG1vcmUgcmVsYXRlZCB0byB0aGUgZmFjdA0KdGhhdCB0aGUgSUVU RiBpcyBub3QgZmFtaWxpYXIgd2l0aCByZXF1aXJlbWVudHMgZG9jdW1lbnRzIHRoYW4gYmFz ZWQNCmluIGFueSBzcGVjaWZpYyBvYmplY3Rpb25zLg0KDQo+ICgxLmUpIEhvdyBzb2xpZCBp cyB0aGUgV0cgY29uc2Vuc3VzIGJlaGluZCB0aGlzIGRvY3VtZW50PyBEb2VzIGl0DQo+ICAg ICAgIHJlcHJlc2VudCB0aGUgc3Ryb25nIGNvbmN1cnJlbmNlIG9mIGEgZmV3IGluZGl2aWR1 YWxzLCB3aXRoDQo+ICAgICAgIG90aGVycyBiZWluZyBzaWxlbnQsIG9yIGRvZXMgdGhlIFdH IGFzIGEgd2hvbGUgdW5kZXJzdGFuZCBhbmQNCj4gICAgICAgYWdyZWUgd2l0aCBpdD8NCg0K RGV2ZWxvcG1lbnQgb2YgdGhlIGRvY3VtZW50IHdhcyBwZXJmb3JtZWQgd2l0aGluIHRoZSBN UExTLVRQIGRlc2lnbg0KdGVhbSAoYy4gMjAgcGVvcGxlKSB0aGF0IHN0cm9uZ2x5IHN1cHBv cnRzIHRoZSB3b3JrLiBUaGVyZSBoYXMgYWxzbw0KYmVlbiBzb21lIGRpc2N1c3Npb24gb24g dGhlIE1QTFMtVFAgKG9wZW4pIG1haWxpbmcgbGlzdCwgYW5kIHRoZXJlDQp3ZXJlIG5vIG9i amVjdGlvbnMgcmFpc2VkLg0KDQo+ICgxLmYpIEhhcyBhbnlvbmUgdGhyZWF0ZW5lZCBhbiBh cHBlYWwgb3Igb3RoZXJ3aXNlIGluZGljYXRlZCBleHRyZW1lDQo+ICAgICAgIGRpc2NvbnRl bnQ/IElmIHNvLCBwbGVhc2Ugc3VtbWFyaXNlIHRoZSBhcmVhcyBvZiBjb25mbGljdCBpbg0K PiAgICAgICBzZXBhcmF0ZSBlbWFpbCBtZXNzYWdlcyB0byB0aGUgUmVzcG9uc2libGUgQXJl YSBEaXJlY3Rvci4gKEl0DQo+ICAgICAgIHNob3VsZCBiZSBpbiBhIHNlcGFyYXRlIGVtYWls IGJlY2F1c2UgdGhpcyBxdWVzdGlvbm5haXJlIGlzDQo+ICAgICAgIGVudGVyZWQgaW50byB0 aGUgSUQgVHJhY2tlci4pDQoNCk5vIHRocmVhdHMgb3IgZXh0cmVtZSBkaXNjb250ZW50Lg0K DQo+ICgxLmcpIEhhcyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQgcGVyc29uYWxseSB2ZXJpZmll ZCB0aGF0IHRoZQ0KPiAgICAgICBkb2N1bWVudCBzYXRpc2ZpZXMgYWxsIElEIG5pdHM/IChT ZWUgdGhlIEludGVybmV0LURyYWZ0cyBDaGVja2xpc3QNCj4gICAgICAgYW5kIGh0dHA6Ly90 b29scy5pZXRmLm9yZy90b29scy9pZG5pdHMvKS4gQm9pbGVycGxhdGUgY2hlY2tzIGFyZQ0K PiAgICAgICBub3QgZW5vdWdoOyB0aGlzIGNoZWNrIG5lZWRzIHRvIGJlIHRob3JvdWdoLiBI YXMgdGhlIGRvY3VtZW50DQo+ICAgICAgIG1ldCBhbGwgZm9ybWFsIHJldmlldyBjcml0ZXJp YSBpdCBuZWVkcyB0bywgc3VjaCBhcyB0aGUgTUlCDQo+ICAgICAgIERvY3RvciwgbWVkaWEg dHlwZSBhbmQgVVJJIHR5cGUgcmV2aWV3cz8NCg0KQWxsIGNoZWNrcyBhcmUgY2xlYW4uDQoN Cj4gKDEuaCkgSGFzIHRoZSBkb2N1bWVudCBzcGxpdCBpdHMgcmVmZXJlbmNlcyBpbnRvIG5v cm1hdGl2ZSBhbmQNCj4gICAgICAgaW5mb3JtYXRpdmU/IEFyZSB0aGVyZSBub3JtYXRpdmUg cmVmZXJlbmNlcyB0byBkb2N1bWVudHMgdGhhdA0KPiAgICAgICBhcmUgbm90IHJlYWR5IGZv ciBhZHZhbmNlbWVudCBvciBhcmUgb3RoZXJ3aXNlIGluIGFuIHVuY2xlYXINCj4gICAgICAg c3RhdGU/IElmIHN1Y2ggbm9ybWF0aXZlIHJlZmVyZW5jZXMgZXhpc3QsIHdoYXQgaXMgdGhl DQo+ICAgICAgIHN0cmF0ZWd5IGZvciB0aGVpciBjb21wbGV0aW9uPyBBcmUgdGhlcmUgbm9y bWF0aXZlIHJlZmVyZW5jZXMNCj4gICAgICAgdGhhdCBhcmUgZG93bndhcmQgcmVmZXJlbmNl cywgYXMgZGVzY3JpYmVkIGluIFtSRkMzOTY3XT8gSWYNCj4gICAgICAgc28sIGxpc3QgdGhl c2UgZG93bndhcmQgcmVmZXJlbmNlcyB0byBzdXBwb3J0IHRoZSBBcmVhDQo+ICAgICAgIERp cmVjdG9yIGluIHRoZSBMYXN0IENhbGwgcHJvY2VkdXJlIGZvciB0aGVtIFtSRkMzOTY3XS4N Cg0KUmVmZXJlbmNlcyBhcmUgY29ycmVjdGx5IHNwbGl0Lg0KDQpUaGVyZSBhcmUgdHdvIG5v cm1hdGl2ZSByZWZlcmVuY2VzIHRvIEktRHMuDQoNCmRyYWZ0LWlldGYtbXBscy10cC1vYW0t cmVxdWlyZW1lbnRzIGhhcyBjb21wbGV0ZWQgV0cgbGFzdCBjYWxsIGFuZCB3aWxsDQpiZSBy ZWFkeSBmb3IgYWR2YW5jZW1lbnQgc29vbi4NCg0KZHJhZnQtaWV0Zi1tcGxzLXRwLXJlcXVp cmVtZW50cyBpcyBvbiB0aGUgUkZDIEVkaXRvcidzIFF1ZXVlLg0KDQpUaGVyZSBhcmUgdHdv IGRvd25yZWZzLiBUaGVzZSBhcmUgZGVsaWJlcmF0ZS4NCg0KUkZDIDQzNzcgT3BlcmF0aW9u cyBhbmQgTWFuYWdlbWVudCAoT0FNKSBSZXF1aXJlbWVudHMgZm9yIE11bHRpLVByb3RvY29s DQogICAgICAgICBMYWJlbCBTd2l0Y2hlZCAoTVBMUykgTmV0d29ya3MNCg0KUkZDIDM4NzEg T3BlcmF0aW9uYWwgU2VjdXJpdHkgUmVxdWlyZW1lbnRzIGZvciBMYXJnZSBJbnRlcm5ldCBT ZXJ2aWNlDQogICAgICAgICBQcm92aWRlciAoSVNQKSBJUCBOZXR3b3JrIEluZnJhc3RydWN0 dXJlDQoNClJlZmVyZW5jZXMgdG8gSW5mb3JtYXRpb25hbCBSRkMncyA0Mzc3IGFuZCAzODcx IGhhdmUgdG8gYmUgbWFkZSBleHBsaWNpdA0KaW4gdGhlIElFVEYgbGFzdCBjYWxsLg0KDQo+ ICgxLmkpIEhhcyB0aGUgRG9jdW1lbnQgU2hlcGhlcmQgdmVyaWZpZWQgdGhhdCB0aGUgZG9j dW1lbnQgSUFOQQ0KPiAgICAgICBjb25zaWRlcmF0aW9uIHNlY3Rpb24gZXhpc3RzIGFuZCBp cyBjb25zaXN0ZW50IHdpdGggdGhlIGJvZHkNCj4gICAgICAgb2YgdGhlIGRvY3VtZW50PyBJ ZiB0aGUgZG9jdW1lbnQgc3BlY2lmaWVzIHByb3RvY29sDQo+ICAgICAgIGV4dGVuc2lvbnMs IGFyZSByZXNlcnZhdGlvbnMgcmVxdWVzdGVkIGluIGFwcHJvcHJpYXRlIElBTkENCj4gICAg ICAgcmVnaXN0cmllcz8gQXJlIHRoZSBJQU5BIHJlZ2lzdHJpZXMgY2xlYXJseSBpZGVudGlm aWVkPyBJZg0KPiAgICAgICB0aGUgZG9jdW1lbnQgY3JlYXRlcyBhIG5ldyByZWdpc3RyeSwg ZG9lcyBpdCBkZWZpbmUgdGhlDQo+ICAgICAgIHByb3Bvc2VkIGluaXRpYWwgY29udGVudHMg b2YgdGhlIHJlZ2lzdHJ5IGFuZCBhbiBhbGxvY2F0aW9uDQo+ICAgICAgIHByb2NlZHVyZSBm b3IgZnV0dXJlIHJlZ2lzdHJhdGlvbnM/IERvZXMgaXQgc3VnZ2VzdCBhDQo+ICAgICAgIHJl YXNvbmFibGUgbmFtZSBmb3IgdGhlIG5ldyByZWdpc3RyeT8gU2VlIFtSRkM1MjI2XS4gSWYg dGhlDQo+ICAgICAgIGRvY3VtZW50IGRlc2NyaWJlcyBhbiBFeHBlcnQgUmV2aWV3IHByb2Nl c3MgaGFzIFNoZXBoZXJkDQo+ICAgICAgIGNvbmZlcnJlZCB3aXRoIHRoZSBSZXNwb25zaWJs ZSBBcmVhIERpcmVjdG9yIHNvIHRoYXQgdGhlIElFU0cNCj4gICAgICAgY2FuIGFwcG9pbnQg dGhlIG5lZWRlZCBFeHBlcnQgZHVyaW5nIHRoZSBJRVNHIEV2YWx1YXRpb24/DQoNClRoZXJl IGFyZSBubyBJQU5BIGFjdGlvbnMgYXNzb2NpYXRlZCB3aXRoIHRoaXMgZG9jdW1lbnQuDQoN CkEgbnVsbCBJQU5BIHNlY3Rpb24gaXMgcHJlc2VudC4NCg0KDQo+ICgxLmopIEhhcyB0aGUg RG9jdW1lbnQgU2hlcGhlcmQgdmVyaWZpZWQgdGhhdCBzZWN0aW9ucyBvZiB0aGUNCj4gICAg ICAgZG9jdW1lbnQgdGhhdCBhcmUgd3JpdHRlbiBpbiBhIGZvcm1hbCBsYW5ndWFnZSwgc3Vj aCBhcyBYTUwNCj4gICAgICAgY29kZSwgQk5GIHJ1bGVzLCBNSUIgZGVmaW5pdGlvbnMsIGV0 Yy4sIHZhbGlkYXRlIGNvcnJlY3RseSBpbg0KPiAgICAgICBhbiBhdXRvbWF0ZWQgY2hlY2tl cj8NCg0KTm8gc3VjaCBmb3JtYWwgbGFuZ3VhZ2UuDQoNCj4gKDEuaykgVGhlIElFU0cgYXBw cm92YWwgYW5ub3VuY2VtZW50IGluY2x1ZGVzIGEgRG9jdW1lbnQNCj4gICAgICAgQW5ub3Vu Y2VtZW50IFdyaXRlLVVwLiBQbGVhc2UgcHJvdmlkZSBzdWNoIGEgRG9jdW1lbnQNCj4gICAg ICAgQW5ub3VuY2VtZW50IFdyaXRlLVVwPyBSZWNlbnQgZXhhbXBsZXMgY2FuIGJlIGZvdW5k IGluIHRoZQ0KPiAgICAgICAiQWN0aW9uIiBhbm5vdW5jZW1lbnRzIGZvciBhcHByb3ZlZCBk b2N1bWVudHMuIFRoZSBhcHByb3ZhbA0KPiAgICAgICBhbm5vdW5jZW1lbnQgY29udGFpbnMg dGhlIGZvbGxvd2luZyBzZWN0aW9uczoNCg0KVGVjaG5pY2FsIFN1bW1hcnkNCg0KICBUaGlz IGRvY3VtZW50IHNwZWNpZmllcyB0aGUgcmVxdWlyZW1lbnRzIGZvciB0aGUgbWFuYWdlbWVu dCBvZg0KICBlcXVpcG1lbnQgdXNlZCBpbiBuZXR3b3JrcyBzdXBwb3J0aW5nIGFuIE1QTFMg VHJhbnNwb3J0IFByb2ZpbGUNCiAgKE1QTFMtVFApLiBUaGUgcmVxdWlyZW1lbnRzIGFyZSBk ZWZpbmVkIGZvciBzcGVjaWZpY2F0aW9uIG9mDQogIG5ldHdvcmsgbWFuYWdlbWVudCBhc3Bl Y3RzIG9mIHByb3RvY29sIG1lY2hhbmlzbXMgYW5kIHByb2NlZHVyZXMNCiAgdGhhdCBjb25z dGl0dXRlIHRoZSBidWlsZGluZyBibG9ja3Mgb3V0IG9mIHdoaWNoIHRoZSBNUExTDQogIHRy YW5zcG9ydCBwcm9maWxlIGlzIGNvbnN0cnVjdGVkLiAgVGhhdCBpcywgdGhlc2UgcmVxdWly ZW1lbnRzDQogIGluZGljYXRlIHdoYXQgbWFuYWdlbWVudCBjYXBhYmlsaXRpZXMgbmVlZCB0 byBiZSBhdmFpbGFibGUgaW4NCiAgTVBMUyBmb3IgdXNlIGluIG1hbmFnaW5nIHRoZSBNUExT LVRQLiBUaGlzIGRvY3VtZW50IGlzIGludGVuZGVkDQogIHRvIGlkZW50aWZ5IGVzc2VudGlh bCBuZXR3b3JrIG1hbmFnZW1lbnQgY2FwYWJpbGl0aWVzLCBub3QgdG8NCiAgc3BlY2lmeSB3 aGF0IGZ1bmN0aW9ucyBhbnkgcGFydGljdWxhciBNUExTIGltcGxlbWVudGF0aW9uDQogIHN1 cHBvcnRzLg0KDQoNCldvcmtpbmcgR3JvdXAgU3VtbWFyeQ0KDQogIFRoZSBkb2N1bWVudCBp cyBwYXJ0IG9mIHRoZSBNUExTLVRQIHByb2plY3QsIHRoZSBjb29wZXJhdGlvbg0KICBiZXR3 ZWVuIElFVEYgYW5kIElUVS1UIHRvIHNwZWNpZnkgYW4gTVBMUyB0cmFuc3BvcnQgcHJvZmls ZS4NCiAgVGhlcmUgYXJlIG5vIG91dHN0YW5kaW5nIGlzc3Vlcy4gSXQgaXMgcHV0IG9uIHRo ZSBzdGFuZGFyZHMNCiAgdHJhY2sgdG8gcmVzb2x2ZSBpc3N1ZXMgYXJvdW5kIGhvdyB0aGUg SVRVLVQgcmVmZXJlbmNlcyBJRVRGDQogIGRvY3VtZW50cy4NCg0KRG9jdW1lbnQgUXVhbGl0 eQ0KDQogIFRoZSBkb2N1bWVudCBpcyBhIHJlcXVpcmVtZW50cyBzcGVjaWZpY2F0aW9uIGFu ZCB3aWxsIG1haW5seQ0KICBiZSB1c2VkIGFzIGlucHV0IHRvIHRoZSBuZXR3b3JrIG1hbmFn ZW1lbnQgc29sdXRpb25zIHNwZWNpZmljYXRpb25zDQogIHRoYXQgd2lsbCBiZSBwdWJsaXNo ZWQgc2hvcnRseS4= --------------080203070604050803030307-- From root@core3.amsl.com Sat Sep 19 15:30:02 2009 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1A39B3A68C6; Sat, 19 Sep 2009 15:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090919223002.1A39B3A68C6@core3.amsl.com> Date: Sat, 19 Sep 2009 15:30:01 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-process-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Sep 2009 22:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : IETF Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS-TP) Document Process Author(s) : L. Andersson, et al. Filename : draft-ietf-mpls-tp-process-02.txt Pages : 22 Date : 2009-09-19 The decision to develop a Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP) in cooperation between the IETF and the ITU-T is document in RFC 5317 as the decision of the Joint Working Team on MPLS-TP. This document provides additional detail of the processes for the development of IETF RFCs on MPLS-TP. It provides an adaptation of the IETF working group process; identifies the expected participation in the process by the ITU-T; and clarifies the rules and conventions regarding MPLS-TP documents. This document doe not specify any ITU-T process; ITU-T activities will be done according to ITU-T process/rules. This document does not specify or modify the normal IETF working group process. It is limited to the specific adaptations of that process to facilitate the cooperation agreement between the IETF and the ITU-T on MPLS-TP, and to ensure a good and consistent document review across the two organizations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-process-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-tp-process-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-19152930.I-D@ietf.org> --NextPart-- From N.Leymann@telekom.de Mon Sep 21 01:06:33 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CC133A687A; Mon, 21 Sep 2009 01:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.648 X-Spam-Level: X-Spam-Status: No, score=-2.648 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZJjokGw4J-y; Mon, 21 Sep 2009 01:06:32 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 7E78F3A67EC; Mon, 21 Sep 2009 01:06:27 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail81.telekom.de with ESMTP; 21 Sep 2009 10:06:17 +0200 Received: from S4DE9JSAAIB.ost.t-com.de ([10.125.177.167]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Sep 2009 10:06:17 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA3A92.652AFEC4" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 21 Sep 2009 10:06:19 +0200 Message-ID: <4395962A7C18D84191B205AD70896983051F0EEA@S4DE9JSAAIB.ost.t-com.de> In-Reply-To: <32ee8b4c0909201952g5fa6deedt946d83576dc9f205@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Regarding draft-wijnands-mpls-mldp-csc-01 Thread-Index: Aco6ZpcgiROcvtzeTvGTd9CGEU01owAK1hBA References: <32ee8b4c0909201952g5fa6deedt946d83576dc9f205@mail.gmail.com> From: To: , X-OriginalArrivalTime: 21 Sep 2009 08:06:17.0510 (UTC) FILETIME=[65723460:01CA3A92] Cc: mpls@ietf.org, l3vpn@ietf.org Subject: Re: [mpls] Regarding draft-wijnands-mpls-mldp-csc-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 08:06:33 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA3A92.652AFEC4 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, =20 I'm also in favor of keeping the work in a single draft. The draft is quiete=20 small (and simple) and I think it's a good idea to keep the procedures in line in a single document. =20 regards =20 Nic ________________________________ Von: l3vpn-bounces@ietf.org [mailto:l3vpn-bounces@ietf.org] Im Auftrag von Fil Dickinson Gesendet: Montag, 21. September 2009 04:52 An: IJsbrand Wijnands Cc: mpls@ietf.org; l3vpn@ietf.org Betreff: Re: Regarding draft-wijnands-mpls-mldp-csc-01 Hi Ice, I agree with Yakov that the VPN method belongs in the L3VPN WG, however I am happy to support your suggestion (of maintaining a single document across the groups and developing within the MPLS WG) if the following is true: 1) There are no alternatives that provide a better outcome to provide the same functionality for the L3VPN case. 2) Prior to last call across the WG's, all significant work developed in the MPLS WG on the L3VPN solution is presented and robustly discussed with the L3VPN WG so that things do not get delayed late in the process. =20 On the draft itself, personally I like the simplicity of the proposal and think that keeping the solution to both non-L3 and L3 aligned is a good thing. =20 Cheers On Fri, Sep 18, 2009 at 6:06 PM, IJsbrand Wijnands wrote: Dear WG, =09 I like to get some input from the WG regarding draft-wijnands-mpls-mldp-csc-01. =09 I presented this draft in MPLS WG at IETF in Stockholm and got the comments from Yakov that this document contains work that belongs in L3VPN. It was suggested this document should be split in 2 different drafts, a non-L3VPN specific draft and a L3VPN specific draft. =09 Considering how small the draft is and how close the non-L3VPN and L3VPN procedures are, I would prefer to keep this one draft. We can do a last call in both WG's and present it in L3VPN, but we do the work in MPLS. =09 I would appreciate if you voice your opinion, after reading the draft :-) =09 Thx, =09 Ice. =09 Appendix: =09 This is small explanation on why procedures in section 3.1, 3.2 are considered to be L3VPN. The draft describes a procedure to use a Recursive Opaque encoding to help an mLDP LSP traverse a MPLS core that does not have reachability to the root of an LSP. Using the recursive Opaque encoding you temporarily replace the original FEC with a new FEC that has a root that is reachable. This procedure is useful in the VPN context and in the non-VPN context. The only difference is that you add an RD to the encoding for LSP's are that originated in the VPN context. =09 =09 =09 =09 ------_=_NextPart_001_01CA3A92.652AFEC4 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I'm also in favor of keeping the work in a = single draft.=20 The draft is quiete
small (and simple) and I think it's a  = good idea to=20 keep the procedures
in line in a single = document.
 
  regards
 
    Nic

Von: l3vpn-bounces@ietf.org=20 [mailto:l3vpn-bounces@ietf.org] Im Auftrag von Fil=20 Dickinson
Gesendet: Montag, 21. September 2009 = 04:52
An:=20 IJsbrand Wijnands
Cc: mpls@ietf.org; = l3vpn@ietf.org
Betreff:=20 Re: Regarding draft-wijnands-mpls-mldp-csc-01

Hi Ice,
I agree with Yakov that the VPN method belongs in the L3VPN WG, = however I=20 am happy to support your suggestion (of maintaining a single document = across the=20 groups and developing within the MPLS WG) if the following is = true:
1) There are no alternatives that provide a better outcome to = provide the=20 same functionality for the L3VPN case.
2) Prior to last call across the WG's, all significant work = developed in=20 the MPLS WG on the L3VPN solution is presented and robustly discussed = with the=20 L3VPN WG so that things do not get delayed late in the process.
 
On the draft itself, personally I like the simplicity of the = proposal and=20 think that keeping the solution to both non-L3 and L3 aligned is a good=20 thing.
 
Cheers

On Fri, Sep 18, 2009 at 6:06 PM, IJsbrand = Wijnands <ice@cisco.com>=20 wrote:
Dear=20 WG,

I like to get some input from the WG regarding=20 draft-wijnands-mpls-mldp-csc-01.

I presented this draft in MPLS = WG at=20 IETF in Stockholm and got the comments from Yakov that this document = contains=20 work that belongs in L3VPN. It was suggested this document should be = split in=20 2 different drafts, a non-L3VPN specific draft and a L3VPN specific=20 draft.

Considering how small the draft is and how close the = non-L3VPN=20 and L3VPN procedures are, I would prefer to keep this one draft. We = can do a=20 last call in both WG's and present it in L3VPN, but we do the work in=20 MPLS.

I would appreciate if you voice your opinion, after = reading the=20 draft :-)

Thx,

Ice.

Appendix:

This is = small=20 explanation on why procedures in section 3.1, 3.2 are considered to be = L3VPN.=20 The draft describes a procedure to use a Recursive Opaque encoding to = help an=20 mLDP LSP traverse a MPLS core that does not have reachability to the = root of=20 an LSP. Using the recursive Opaque encoding you temporarily replace = the=20 original FEC with a new FEC that has a root that is reachable. This = procedure=20 is useful in the VPN context and in the non-VPN context. The only = difference=20 is that you add an RD to the encoding for LSP's are that originated in = the VPN=20 context.




------_=_NextPart_001_01CA3A92.652AFEC4-- From fil.dickinson@gmail.com Sun Sep 20 19:51:27 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F2113A6985; Sun, 20 Sep 2009 19:51:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D1R8dAPJOjV9; Sun, 20 Sep 2009 19:51:26 -0700 (PDT) Received: from mail-px0-f177.google.com (mail-px0-f177.google.com [209.85.216.177]) by core3.amsl.com (Postfix) with ESMTP id 5848F3A695C; Sun, 20 Sep 2009 19:51:26 -0700 (PDT) Received: by pxi7 with SMTP id 7so2072169pxi.18 for ; Sun, 20 Sep 2009 19:52:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=h3vmRMkO4FZxK9B/L3qLrTy0YoDP8az1t++YtwNDiKQ=; b=ZWnjCoGrApvGAGuSh3E2kj2lAeJLrKhqVLGbC26aMaxrUwh7ujVhbhHuh0Ntci+n7A avXbPpfZ/6m5vS+KINpCXiB1yN390HLDsoTiblF4qV38u/Ux+9t4T+qfw+7Pj+CRuS8z Nh2sgtLY7Ee0dxPAe4CLRq88PJB8vUU5Tn/bg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=lxqvPBJ1nEIQ7QnGtX5ia65HjHaeG1adIappB1hadIygZy8tHQQkiZJKwibuP7+bHr iMzKMLNBzAQW796BlB0JrjpFKa9HXbpAfi94tF3oufLyHy8rxLY5Ic0we9kbDK6IPLwm zxASnkXPm3bRjVq6fL3aVrejpen1dAFYjG9vI= MIME-Version: 1.0 Received: by 10.140.177.3 with SMTP id z3mr212303rve.127.1253501543955; Sun, 20 Sep 2009 19:52:23 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 Sep 2009 12:52:23 +1000 Message-ID: <32ee8b4c0909201952g5fa6deedt946d83576dc9f205@mail.gmail.com> From: Fil Dickinson To: IJsbrand Wijnands Content-Type: multipart/alternative; boundary=000e0cd1a62040be9304740d926d X-Mailman-Approved-At: Mon, 21 Sep 2009 05:36:58 -0700 Cc: mpls@ietf.org, l3vpn@ietf.org Subject: Re: [mpls] Regarding draft-wijnands-mpls-mldp-csc-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 02:51:27 -0000 --000e0cd1a62040be9304740d926d Content-Type: text/plain; charset=ISO-8859-1 Hi Ice, I agree with Yakov that the VPN method belongs in the L3VPN WG, however I am happy to support your suggestion (of maintaining a single document across the groups and developing within the MPLS WG) if the following is true: 1) There are no alternatives that provide a better outcome to provide the same functionality for the L3VPN case. 2) Prior to last call across the WG's, all significant work developed in the MPLS WG on the L3VPN solution is presented and robustly discussed with the L3VPN WG so that things do not get delayed late in the process. On the draft itself, personally I like the simplicity of the proposal and think that keeping the solution to both non-L3 and L3 aligned is a good thing. Cheers On Fri, Sep 18, 2009 at 6:06 PM, IJsbrand Wijnands wrote: > Dear WG, > > I like to get some input from the WG regarding > draft-wijnands-mpls-mldp-csc-01. > > I presented this draft in MPLS WG at IETF in Stockholm and got the comments > from Yakov that this document contains work that belongs in L3VPN. It was > suggested this document should be split in 2 different drafts, a non-L3VPN > specific draft and a L3VPN specific draft. > > Considering how small the draft is and how close the non-L3VPN and L3VPN > procedures are, I would prefer to keep this one draft. We can do a last call > in both WG's and present it in L3VPN, but we do the work in MPLS. > > I would appreciate if you voice your opinion, after reading the draft :-) > > Thx, > > Ice. > > Appendix: > > This is small explanation on why procedures in section 3.1, 3.2 are > considered to be L3VPN. The draft describes a procedure to use a Recursive > Opaque encoding to help an mLDP LSP traverse a MPLS core that does not have > reachability to the root of an LSP. Using the recursive Opaque encoding you > temporarily replace the original FEC with a new FEC that has a root that is > reachable. This procedure is useful in the VPN context and in the non-VPN > context. The only difference is that you add an RD to the encoding for LSP's > are that originated in the VPN context. > > > > --000e0cd1a62040be9304740d926d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Ice,
I agree with Yakov that the VPN method belongs in the L3VPN WG, howeve= r I am happy to support your suggestion (of maintaining a single document a= cross the groups and developing within the MPLS WG) if the following is tru= e:
1) There are no alternatives that provide a better outcome to provide = the same functionality for the L3VPN case.
2) Prior to last call across the WG's, all significant work develo= ped in the MPLS WG on the L3VPN solution is presented and robustly discusse= d with the L3VPN WG so that things do not get delayed late in the process.<= /div>
=A0
On the draft itself, personally I like the simplicity of the proposal = and think that keeping the solution to both non-L3 and L3 aligned is a good= thing.
=A0
Cheers

On Fri, Sep 18, 2009 at 6:06 PM, IJsbrand Wijnan= ds <ice@cisco.com= > wrote:
Dear WG,

I like to get so= me input from the WG regarding draft-wijnands-mpls-mldp-csc-01.

I pr= esented this draft in MPLS WG at IETF in Stockholm and got the comments fro= m Yakov that this document contains work that belongs in L3VPN. It was sugg= ested this document should be split in 2 different drafts, a non-L3VPN spec= ific draft and a L3VPN specific draft.

Considering how small the draft is and how close the non-L3VPN and L3VP= N procedures are, I would prefer to keep this one draft. We can do a last c= all in both WG's and present it in L3VPN, but we do the work in MPLS.
I would appreciate if you voice your opinion, after reading the draft := -)

Thx,

Ice.

Appendix:

This is small explanatio= n on why procedures in section 3.1, 3.2 are considered to be L3VPN. The dra= ft describes a procedure to use a Recursive Opaque encoding to help an mLDP= LSP traverse a MPLS core that does not have reachability to the root of an= LSP. Using the recursive Opaque encoding you temporarily replace the origi= nal FEC with a new FEC that has a root that is reachable. This procedure is= useful in the VPN context and in the non-VPN context. The only difference = is that you add an RD to the encoding for LSP's are that originated in = the VPN context.




--000e0cd1a62040be9304740d926d-- From yakov@juniper.net Mon Sep 21 06:40:22 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14AB63A6A19; Mon, 21 Sep 2009 06:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.117 X-Spam-Level: X-Spam-Status: No, score=-6.117 tagged_above=-999 required=5 tests=[AWL=-0.118, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-Qj9LVmh0Mr; Mon, 21 Sep 2009 06:40:21 -0700 (PDT) Received: from exprod7og113.obsmtp.com (exprod7og113.obsmtp.com [64.18.2.179]) by core3.amsl.com (Postfix) with ESMTP id 1005A3A68E1; Mon, 21 Sep 2009 06:40:20 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob113.postini.com ([64.18.6.12]) with SMTP ID DSNKSreCgcyOoE2JNgjkeKow0YmxIX3DqmYo@postini.com; Mon, 21 Sep 2009 06:41:23 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Mon, 21 Sep 2009 06:27:35 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Sep 2009 06:27:35 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Sep 2009 06:27:34 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Sep 2009 06:27:34 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n8LDRXj23484; Mon, 21 Sep 2009 06:27:33 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <200909211327.n8LDRXj23484@magenta.juniper.net> To: IJsbrand Wijnands In-Reply-To: References: X-MH-In-Reply-To: IJsbrand Wijnands message dated "Fri, 18 Sep 2009 10:06:08 +0200." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <85924.1253539653.1@juniper.net> Date: Mon, 21 Sep 2009 06:27:33 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 21 Sep 2009 13:27:34.0318 (UTC) FILETIME=[4751ACE0:01CA3ABF] Cc: mpls@ietf.org, l3vpn@ietf.org Subject: Re: [mpls] Regarding draft-wijnands-mpls-mldp-csc-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 13:40:22 -0000 Ice, > Dear WG, > > I like to get some input from the WG regarding draft-wijnands-mpls- > mldp-csc-01. > > I presented this draft in MPLS WG at IETF in Stockholm and got the > comments from Yakov that this document contains work that belongs in > L3VPN. It was suggested this document should be split in 2 different > drafts, a non-L3VPN specific draft and a L3VPN specific draft. > > Considering how small the draft is and how close the non-L3VPN and > L3VPN procedures are, I would prefer to keep this one draft. We can do > a last call in both WG's and present it in L3VPN, but we do the work > in MPLS. > > I would appreciate if you voice your opinion, after reading the > draft :-) The size of the document does not change the fact that section 3 of the document is completely outside the scope of MPLS WG. That is precisely why I proposed to remove section 3 from the document, and progress the revised document in MPLS WG. Yakov. From yakov@juniper.net Mon Sep 21 06:45:21 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B1623A6900; Mon, 21 Sep 2009 06:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.95 X-Spam-Level: X-Spam-Status: No, score=-4.95 tagged_above=-999 required=5 tests=[AWL=-1.252, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, MANGLED_FROM=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tqIG66SYWVNe; Mon, 21 Sep 2009 06:45:20 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with ESMTP id 173083A63EC; Mon, 21 Sep 2009 06:45:19 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKSreDpUqNDru7I8ukPoWdviqDj98YtA99@postini.com; Mon, 21 Sep 2009 06:46:22 PDT Received: from p-emfe01-sac.jnpr.net (66.129.254.72) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server id 8.1.375.2; Mon, 21 Sep 2009 06:31:51 -0700 Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emfe01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Sep 2009 06:31:51 -0700 Received: from emailsmtp55.jnpr.net ([172.24.18.132]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Sep 2009 06:31:50 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 21 Sep 2009 06:31:50 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id n8LDVoj28173; Mon, 21 Sep 2009 06:31:50 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <200909211331.n8LDVoj28173@magenta.juniper.net> To: Fil Dickinson In-Reply-To: <32ee8b4c0909201952g5fa6deedt946d83576dc9f205@mail.gmail.com> References: <32ee8b4c0909201952g5fa6deedt946d83576dc9f205@mail.gmail.com> X-MH-In-Reply-To: Fil Dickinson message dated "Mon, 21 Sep 2009 12:52:23 +1000." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <86289.1253539910.1@juniper.net> Date: Mon, 21 Sep 2009 06:31:50 -0700 From: Yakov Rekhter X-OriginalArrivalTime: 21 Sep 2009 13:31:50.0457 (UTC) FILETIME=[DFFD6290:01CA3ABF] Cc: mpls@ietf.org, IJsbrand Wijnands , l3vpn@ietf.org Subject: Re: [mpls] Regarding draft-wijnands-mpls-mldp-csc-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 13:45:21 -0000 Fil, > Hi Ice, > I agree with Yakov that the VPN method belongs in the L3VPN WG, however I am > happy to support your suggestion (of maintaining a single document across > the groups and developing within the MPLS WG) if the following is true: > 1) There are no alternatives that provide a better outcome to provide the > same functionality for the L3VPN case. There was no discussion in L3VPN WG on this topic. > 2) Prior to last call across the WG's, all significant work developed in the > MPLS WG on the L3VPN solution is presented and robustly discussed with the > L3VPN WG so that things do not get delayed late in the process. > > On the draft itself, personally I like the simplicity of the proposal and > think that keeping the solution to both non-L3 and L3 aligned is a good > thing. There is nothing to prevent the alignment if Section 3 (the VPN related stuff) will be placed in a separate document. Yakov. > > Cheers > > On Fri, Sep 18, 2009 at 6:06 PM, IJsbrand Wijnands wrote: > > > Dear WG, > > > > I like to get some input from the WG regarding > > draft-wijnands-mpls-mldp-csc-01. > > > > I presented this draft in MPLS WG at IETF in Stockholm and got the comments > > from Yakov that this document contains work that belongs in L3VPN. It was > > suggested this document should be split in 2 different drafts, a non-L3VPN > > specific draft and a L3VPN specific draft. > > > > Considering how small the draft is and how close the non-L3VPN and L3VPN > > procedures are, I would prefer to keep this one draft. We can do a last cal l > > in both WG's and present it in L3VPN, but we do the work in MPLS. > > > > I would appreciate if you voice your opinion, after reading the draft :-) > > > > Thx, > > > > Ice. > > > > Appendix: > > > > This is small explanation on why procedures in section 3.1, 3.2 are > > considered to be L3VPN. The draft describes a procedure to use a Recursive > > Opaque encoding to help an mLDP LSP traverse a MPLS core that does not have > > reachability to the root of an LSP. Using the recursive Opaque encoding you > > temporarily replace the original FEC with a new FEC that has a root that is > > reachable. This procedure is useful in the VPN context and in the non-VPN > > context. The only difference is that you add an RD to the encoding for LSP' s > > are that originated in the VPN context. > > > > > > > > > > --000e0cd1a62040be9304740d926d > Content-Type: text/html; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > >
Hi Ice,
>
I agree with Yakov that the VPN method belongs in the L3VPN WG, howeve= > r I am happy to support your suggestion (of maintaining a single document a= > cross the groups and developing within the MPLS WG) if the following is tru= > e:
> >
1) There are no alternatives that provide a better outcome to provide = > the same functionality for the L3VPN case.
>
2) Prior to last call across the WG's, all significant work develo= > ped in the MPLS WG on the L3VPN solution is presented and robustly discusse= > d with the L3VPN WG so that things do not get delayed late in the process.<= > /div> > >
=A0
>
On the draft itself, personally I like the simplicity of the proposal = > and think that keeping the solution to both non-L3 and L3 aligned is a good= > thing.
>
=A0
>
Cheers

>
On Fri, Sep 18, 2009 at 6:06 PM, IJsbrand Wijnan= > ds <ice@cisco.com= > > wrote:
>
px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Dear WG,

I like to get so= > me input from the WG regarding draft-wijnands-mpls-mldp-csc-01.

I pr= > esented this draft in MPLS WG at IETF in Stockholm and got the comments fro= > m Yakov that this document contains work that belongs in L3VPN. It was sugg= > ested this document should be split in 2 different drafts, a non-L3VPN spec= > ific draft and a L3VPN specific draft.
>
Considering how small the draft is and how close the non-L3VPN and L3VP= > N procedures are, I would prefer to keep this one draft. We can do a last c= > all in both WG's and present it in L3VPN, but we do the work in MPLS. r> >
I would appreciate if you voice your opinion, after reading the draft := > -)

Thx,

Ice.

Appendix:

This is small explanatio= > n on why procedures in section 3.1, 3.2 are considered to be L3VPN. The dra= > ft describes a procedure to use a Recursive Opaque encoding to help an mLDP= > LSP traverse a MPLS core that does not have reachability to the root of an= > LSP. Using the recursive Opaque encoding you temporarily replace the origi= > nal FEC with a new FEC that has a root that is reachable. This procedure is= > useful in the VPN context and in the non-VPN context. The only difference = > is that you add an RD to the encoding for LSP's are that originated in = > the VPN context.
>



> > --000e0cd1a62040be9304740d926d-- From wwwrun@core3.amsl.com Mon Sep 21 07:31:25 2009 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id CE6D328C148; Mon, 21 Sep 2009 07:31:25 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090921143125.CE6D328C148@core3.amsl.com> Date: Mon, 21 Sep 2009 07:31:25 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] Last Call: draft-ietf-mpls-tp-oam-requirements (Requirements for OAM in MPLS Transport Networks) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 14:31:25 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Requirements for OAM in MPLS Transport Networks ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-10-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-requirements-03.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18036&rfc_flag=0 From erosen@cisco.com Mon Sep 21 08:23:08 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5FE83A6AB3; Mon, 21 Sep 2009 08:23:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TvEboaWQHsyJ; Mon, 21 Sep 2009 08:23:08 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B57653A63EC; Mon, 21 Sep 2009 08:23:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.44,424,1249257600"; d="scan'208";a="59155946" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 21 Sep 2009 15:24:08 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n8LFO8h5014810; Mon, 21 Sep 2009 11:24:08 -0400 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8LFO8nh001261; Mon, 21 Sep 2009 15:24:08 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.1/8.13.1) with ESMTP id n8LFO82N009518; Mon, 21 Sep 2009 11:24:08 -0400 To: IJsbrand Wijnands In-reply-to: Your message of Fri, 18 Sep 2009 10:06:08 +0200. Date: Mon, 21 Sep 2009 11:24:08 -0400 Message-ID: <9517.1253546648@erosen-linux> From: Eric Rosen DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=374; t=1253546648; x=1254410648; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=erosen@cisco.com; z=From:=20Eric=20Rosen=20 |Subject:=20Re=3A=20Regarding=20draft-wijnands-mpls-mldp-cs c-01=20 |Sender:=20 |To:=20IJsbrand=20Wijnands=20; bh=nCdl4FBhYhSNmj2MdqiEgKpBUHMv+TD71kQejkbHOSw=; b=H66wJ+qmfkVdoC7959Vy1suiNQA99il/sZrbdTzlSZmnuiW1evQj4JeKym 1fJCipa2dUM0Ex3OmcXuPM6dvFMkvmxdkHrIOXqEM+p9ns3iqMlFvj2GfA+I dmhN5jQXZN; Authentication-Results: rtp-dkim-2; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: mpls@ietf.org, l3vpn@ietf.org Subject: Re: [mpls] Regarding draft-wijnands-mpls-mldp-csc-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 15:23:08 -0000 Keeping all the procedures in one document, and having it presented to and last called in both WGs, is the best procedure. This does not violate any IETF process rules, but it does reduce the overhead involved in preparing, reviewing, submitting, and publishing the document. Most importantly, it makes it easier for future implementers to find the specifications. From ice@cisco.com Mon Sep 21 09:50:37 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BEFA3A6AAA; Mon, 21 Sep 2009 09:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_13=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jEhSfdHGiU9h; Mon, 21 Sep 2009 09:50:36 -0700 (PDT) Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by core3.amsl.com (Postfix) with ESMTP id F04613A6AAC; Mon, 21 Sep 2009 09:50:35 -0700 (PDT) X-TACSUNS: Virus Scanned Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n8LGpaa7014363; Mon, 21 Sep 2009 18:51:36 +0200 (CEST) Received: from ams-iwijnand-8712.cisco.com (ams-iwijnand-8712.cisco.com [10.55.191.147]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id n8LGpZD9013965; Mon, 21 Sep 2009 18:51:36 +0200 (CEST) Message-Id: <773A8C04-18C3-4279-8919-F9193CF893C6@cisco.com> From: IJsbrand Wijnands To: Yakov Rekhter In-Reply-To: <200909211327.n8LDRXj23484@magenta.juniper.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 21 Sep 2009 18:51:35 +0200 References: <200909211327.n8LDRXj23484@magenta.juniper.net> X-Mailer: Apple Mail (2.935.3) Cc: mpls@ietf.org, l3vpn@ietf.org Subject: Re: [mpls] Regarding draft-wijnands-mpls-mldp-csc-01 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 16:50:37 -0000 Yakov, > The size of the document does not change the fact that section 3 > of the document is completely outside the scope of MPLS WG. That > is precisely why I proposed to remove section 3 from the document, > and progress the revised document in MPLS WG. The discussion is not about whether or not there is a L3VPN component to it. The general procedures are very close for both L3 and non-L3 procedures, so its seems to make sense to keep this one draft. Thx, Ice. From wwwrun@core3.amsl.com Mon Sep 21 15:53:27 2009 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 9E1F728C13A; Mon, 21 Sep 2009 15:53:27 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090921225327.9E1F728C13A@core3.amsl.com> Date: Mon, 21 Sep 2009 15:53:27 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] Last Call: draft-ietf-mpls-tp-gach-dcn (An Inband Data Communication Network For the MPLS Transport Profile) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 22:53:27 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'An Inband Data Communication Network For the MPLS Transport Profile ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-10-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-gach-dcn-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18450&rfc_flag=0 From wwwrun@core3.amsl.com Mon Sep 21 15:54:16 2009 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 3274728C1A8; Mon, 21 Sep 2009 15:54:15 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20090921225416.3274728C1A8@core3.amsl.com> Date: Mon, 21 Sep 2009 15:54:16 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] Last Call: draft-ietf-mpls-tp-nm-req (MPLS TP Network Management Requirements) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 22:54:16 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS TP Network Management Requirements ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-10-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-nm-req-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18244&rfc_flag=0 From davari@broadcom.com Mon Sep 21 16:23:40 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1BAC3A693F; Mon, 21 Sep 2009 16:23:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.403 X-Spam-Level: X-Spam-Status: No, score=-2.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlpaxL8Z3fU7; Mon, 21 Sep 2009 16:23:39 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id 3809D3A67B8; Mon, 21 Sep 2009 16:23:39 -0700 (PDT) Received: from [10.16.192.224] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 21 Sep 2009 16:24:26 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Mon, 21 Sep 2009 16:24:27 -0700 From: "Shahram Davari" To: "ietf@ietf.org" , IETF-Announce Date: Mon, 21 Sep 2009 16:24:25 -0700 Thread-Topic: [mpls] Last Call: draft-ietf-mpls-tp-nm-req (MPLS TP Network Management Requirements) to Proposed Standard Thread-Index: Aco7Dw5iy6i+rob1SduleYEPTiGX/AAA1N1w Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6815751C363@SJEXCHCCR02.corp.ad.broadcom.com> References: <20090921225416.3274728C1A8@core3.amsl.com> In-Reply-To: <20090921225416.3274728C1A8@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 66A6D4A039G24425639-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-nm-req (MPLS TP Network Management Requirements) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 23:23:40 -0000 Hi, Just for clarification, does this draft require using a PID for BFD and LSP= -ping? If not how are the various OAM types identified? Thanks, Shahram -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of The= IESG Sent: Monday, September 21, 2009 3:54 PM To: IETF-Announce Cc: mpls@ietf.org Subject: [mpls] Last Call: draft-ietf-mpls-tp-nm-req (MPLS TP Network Manag= ement Requirements) to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching WG=20 (mpls) to consider the following document: - 'MPLS TP Network Management Requirements ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-10-05. Exceptionally,=20 comments may be sent to iesg@ietf.org instead. In either case, please=20 retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-nm-req-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D18244&rfc_flag=3D0 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From benjamin.niven-jenkins@bt.com Mon Sep 21 16:34:39 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97C053A67F0; Mon, 21 Sep 2009 16:34:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.553 X-Spam-Level: X-Spam-Status: No, score=-1.553 tagged_above=-999 required=5 tests=[AWL=0.493, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Al5Kw5YDrk4c; Mon, 21 Sep 2009 16:34:38 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by core3.amsl.com (Postfix) with ESMTP id 8298D3A6919; Mon, 21 Sep 2009 16:34:38 -0700 (PDT) Received: from RDW083A010HT62.domain1.systemhost.net (10.187.59.13) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 22 Sep 2009 00:35:40 +0100 Received: from RDW083V001RVA1.domain1.systemhost.net ([10.187.59.10]) by RDW083A010HT62.domain1.systemhost.net ([10.187.59.13]) with mapi; Tue, 22 Sep 2009 00:35:29 +0100 From: To: , , Date: Tue, 22 Sep 2009 00:32:22 +0100 Thread-Topic: [mpls] Last Call: draft-ietf-mpls-tp-nm-req (MPLS TP Network Management Requirements) to Proposed Standard Thread-Index: Aco7Dw5iy6i+rob1SduleYEPTiGX/AAA1N1wAABYpno= Message-ID: <9C31FA6F6F10D641B0B16A91BC374187B3213243F3@RDW083V001RVA1.domain1.systemhost.net> References: <20090921225416.3274728C1A8@core3.amsl.com>, <2C2F1EBA8050E74EA81502D5740B4BD6815751C363@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6815751C363@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-nm-req (MPLS TP Network Management Requirements) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 23:34:39 -0000 Sharam, The draft describes network management requirements and at most states that= OAM must be configurable by network management. It presupposes nothing abo= ut the OAM mechanism used or now the individual network elements (LSRs) rec= ognise the OAM packets themselves. So I don't understand your question in r= egards to the draft as the question you ask is not relevant within the scop= e of the draft. Ben ________________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Shahram Da= vari [davari@broadcom.com] Sent: Tuesday, September 22, 2009 12:24 AM To: ietf@ietf.org; IETF-Announce Cc: mpls@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-nm-req (MPLS TP Network M= anagement Requirements) to Proposed Standard Hi, Just for clarification, does this draft require using a PID for BFD and LSP= -ping? If not how are the various OAM types identified? Thanks, Shahram -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of The= IESG Sent: Monday, September 21, 2009 3:54 PM To: IETF-Announce Cc: mpls@ietf.org Subject: [mpls] Last Call: draft-ietf-mpls-tp-nm-req (MPLS TP Network Manag= ement Requirements) to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS TP Network Management Requirements ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-10-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-nm-req-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D18244&rfc_flag=3D0 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From davari@broadcom.com Mon Sep 21 16:38:30 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EEA93A67F0; Mon, 21 Sep 2009 16:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.41 X-Spam-Level: X-Spam-Status: No, score=-2.41 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oe6F49mQeRf6; Mon, 21 Sep 2009 16:38:29 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id 556DF3A63C9; Mon, 21 Sep 2009 16:38:29 -0700 (PDT) Received: from [10.16.192.224] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 21 Sep 2009 16:39:23 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Mon, 21 Sep 2009 16:39:24 -0700 From: "Shahram Davari" To: "benjamin.niven-jenkins@bt.com" , "ietf@ietf.org" , "ietf-announce@ietf.org" Date: Mon, 21 Sep 2009 16:39:23 -0700 Thread-Topic: [mpls] Last Call: draft-ietf-mpls-tp-nm-req (MPLS TP Network Management Requirements) to Proposed Standard Thread-Index: Aco7Dw5iy6i+rob1SduleYEPTiGX/AAA1N1wAABYpnoAADD7wA== Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6815751C367@SJEXCHCCR02.corp.ad.broadcom.com> References: <20090921225416.3274728C1A8@core3.amsl.com>, <2C2F1EBA8050E74EA81502D5740B4BD6815751C363@SJEXCHCCR02.corp.ad.broadcom.com> <9C31FA6F6F10D641B0B16A91BC374187B3213243F3@RDW083V001RVA1.domain1.systemhost.net> In-Reply-To: <9C31FA6F6F10D641B0B16A91BC374187B3213243F3@RDW083V001RVA1.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 66A6D1215S415582390-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-nm-req (MPLS TP Network Management Requirements) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 23:38:30 -0000 Hi Ben, Basically I want to understand whether PID is required for OAM or not? Also= is OAM a type of MCC traffic? Thanks, Shahram=20 -----Original Message----- From: benjamin.niven-jenkins@bt.com [mailto:benjamin.niven-jenkins@bt.com]= =20 Sent: Monday, September 21, 2009 4:32 PM To: Shahram Davari; ietf@ietf.org; ietf-announce@ietf.org Cc: mpls@ietf.org Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-nm-req (MPLS TP Network M= anagement Requirements) to Proposed Standard Sharam, The draft describes network management requirements and at most states that= OAM must be configurable by network management. It presupposes nothing abo= ut the OAM mechanism used or now the individual network elements (LSRs) rec= ognise the OAM packets themselves. So I don't understand your question in r= egards to the draft as the question you ask is not relevant within the scop= e of the draft. Ben ________________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Shahram Da= vari [davari@broadcom.com] Sent: Tuesday, September 22, 2009 12:24 AM To: ietf@ietf.org; IETF-Announce Cc: mpls@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-nm-req (MPLS TP Network M= anagement Requirements) to Proposed Standard Hi, Just for clarification, does this draft require using a PID for BFD and LSP= -ping? If not how are the various OAM types identified? Thanks, Shahram -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of The= IESG Sent: Monday, September 21, 2009 3:54 PM To: IETF-Announce Cc: mpls@ietf.org Subject: [mpls] Last Call: draft-ietf-mpls-tp-nm-req (MPLS TP Network Manag= ement Requirements) to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS TP Network Management Requirements ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-10-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-nm-req-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D18244&rfc_flag=3D0 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From benjamin.niven-jenkins@bt.com Mon Sep 21 17:30:11 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 229CF3A696C for ; Mon, 21 Sep 2009 17:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.574 X-Spam-Level: X-Spam-Status: No, score=-1.574 tagged_above=-999 required=5 tests=[AWL=0.472, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iyt-FI50YQJu for ; Mon, 21 Sep 2009 17:30:10 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp61.intersmtp.COM [62.239.224.234]) by core3.amsl.com (Postfix) with ESMTP id 132733A68B7 for ; Mon, 21 Sep 2009 17:30:09 -0700 (PDT) Received: from RDW083A009HT61.domain1.systemhost.net (10.187.59.12) by RDW083A005ED61.smtp-e1.hygiene.service (10.187.98.10) with Microsoft SMTP Server (TLS) id 8.1.393.1; Tue, 22 Sep 2009 01:31:11 +0100 Received: from RDW083V001RVA1.domain1.systemhost.net ([10.187.59.9]) by RDW083A009HT61.domain1.systemhost.net ([10.187.59.12]) with mapi; Tue, 22 Sep 2009 01:31:11 +0100 From: To: Date: Tue, 22 Sep 2009 01:31:10 +0100 Thread-Topic: [mpls] Last Call: draft-ietf-mpls-tp-nm-req (MPLS TP Network Management Requirements) to Proposed Standard Thread-Index: Aco7Dw5iy6i+rob1SduleYEPTiGX/AAA1N1wAABYpnoAADD7wAABp8Y6 Message-ID: <9C31FA6F6F10D641B0B16A91BC374187B321CA29D1@RDW083V001RVA1.domain1.systemhost.net> References: <20090921225416.3274728C1A8@core3.amsl.com>, <2C2F1EBA8050E74EA81502D5740B4BD6815751C363@SJEXCHCCR02.corp.ad.broadcom.com> <9C31FA6F6F10D641B0B16A91BC374187B3213243F3@RDW083V001RVA1.domain1.systemhost.net>, <2C2F1EBA8050E74EA81502D5740B4BD6815751C367@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6815751C367@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: mpls@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-nm-req (MPLS TP Network Management Requirements) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 00:30:11 -0000 Sharam, Which is a fine question to ask but IMO is not relevant in the context of t= he NM requirements draft. Within the OAM requirements it is relevant as it is a requirement to be abl= e to distinguish between OAM traffic and data traffic. Within the solutions drafts it is relevant as they should define the mechan= ism by which OAM packets are identified. A MCC may run OAM but your question is still not relevant in the context of= the NM requirements draft as the OAM requirements for the MCC should inher= it from the OAM requirements draft and the OAM solutions themselves. Ben ________________________________________ From: Shahram Davari [davari@broadcom.com] Sent: Tuesday, September 22, 2009 12:39 AM To: Niven-jenkins,B,Ben,DMF R; ietf@ietf.org; ietf-announce@ietf.org Cc: mpls@ietf.org Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-nm-req (MPLS TP Network M= anagement Requirements) to Proposed Standard Hi Ben, Basically I want to understand whether PID is required for OAM or not? Also= is OAM a type of MCC traffic? Thanks, Shahram -----Original Message----- From: benjamin.niven-jenkins@bt.com [mailto:benjamin.niven-jenkins@bt.com] Sent: Monday, September 21, 2009 4:32 PM To: Shahram Davari; ietf@ietf.org; ietf-announce@ietf.org Cc: mpls@ietf.org Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-nm-req (MPLS TP Network M= anagement Requirements) to Proposed Standard Sharam, The draft describes network management requirements and at most states that= OAM must be configurable by network management. It presupposes nothing abo= ut the OAM mechanism used or now the individual network elements (LSRs) rec= ognise the OAM packets themselves. So I don't understand your question in r= egards to the draft as the question you ask is not relevant within the scop= e of the draft. Ben ________________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Shahram Da= vari [davari@broadcom.com] Sent: Tuesday, September 22, 2009 12:24 AM To: ietf@ietf.org; IETF-Announce Cc: mpls@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-nm-req (MPLS TP Network M= anagement Requirements) to Proposed Standard Hi, Just for clarification, does this draft require using a PID for BFD and LSP= -ping? If not how are the various OAM types identified? Thanks, Shahram -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of The= IESG Sent: Monday, September 21, 2009 3:54 PM To: IETF-Announce Cc: mpls@ietf.org Subject: [mpls] Last Call: draft-ietf-mpls-tp-nm-req (MPLS TP Network Manag= ement Requirements) to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS TP Network Management Requirements ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-10-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-nm-req-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D18244&rfc_flag=3D0 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From davari@broadcom.com Mon Sep 21 17:41:36 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AA113A68B5 for ; Mon, 21 Sep 2009 17:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.416 X-Spam-Level: X-Spam-Status: No, score=-2.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bHHhf30kHeQA for ; Mon, 21 Sep 2009 17:41:33 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id 82DD13A69D7 for ; Mon, 21 Sep 2009 17:41:32 -0700 (PDT) Received: from [10.16.192.232] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 21 Sep 2009 17:42:22 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Mon, 21 Sep 2009 17:42:22 -0700 From: "Shahram Davari" To: "benjamin.niven-jenkins@bt.com" Date: Mon, 21 Sep 2009 17:42:22 -0700 Thread-Topic: [mpls] Last Call: draft-ietf-mpls-tp-nm-req (MPLS TP Network Management Requirements) to Proposed Standard Thread-Index: Aco7Dw5iy6i+rob1SduleYEPTiGX/AAA1N1wAABYpnoAADD7wAABp8Y6AACHRnA= Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6815751C376@SJEXCHCCR02.corp.ad.broadcom.com> References: <20090921225416.3274728C1A8@core3.amsl.com>, <2C2F1EBA8050E74EA81502D5740B4BD6815751C363@SJEXCHCCR02.corp.ad.broadcom.com> <9C31FA6F6F10D641B0B16A91BC374187B3213243F3@RDW083V001RVA1.domain1.systemhost.net>, <2C2F1EBA8050E74EA81502D5740B4BD6815751C367@SJEXCHCCR02.corp.ad.broadcom.com> <9C31FA6F6F10D641B0B16A91BC374187B321CA29D1@RDW083V001RVA1.domain1.systemhost.net> In-Reply-To: <9C31FA6F6F10D641B0B16A91BC374187B321CA29D1@RDW083V001RVA1.domain1.systemhost.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 66A6C2E439G24521737-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-nm-req (MPLS TP Network Management Requirements) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 00:41:37 -0000 Ben, OK let me put it in another way: Is PID always required after the G-ACH Channel type or it depends on the Ch= annel Type? I think this question is very relevant to this draft. Thanks, Shahram=20 -----Original Message----- From: benjamin.niven-jenkins@bt.com [mailto:benjamin.niven-jenkins@bt.com]= =20 Sent: Monday, September 21, 2009 5:31 PM To: Shahram Davari Cc: mpls@ietf.org Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-nm-req (MPLS TP Network M= anagement Requirements) to Proposed Standard Sharam, Which is a fine question to ask but IMO is not relevant in the context of t= he NM requirements draft. Within the OAM requirements it is relevant as it is a requirement to be abl= e to distinguish between OAM traffic and data traffic. Within the solutions drafts it is relevant as they should define the mechan= ism by which OAM packets are identified. A MCC may run OAM but your question is still not relevant in the context of= the NM requirements draft as the OAM requirements for the MCC should inher= it from the OAM requirements draft and the OAM solutions themselves. Ben ________________________________________ From: Shahram Davari [davari@broadcom.com] Sent: Tuesday, September 22, 2009 12:39 AM To: Niven-jenkins,B,Ben,DMF R; ietf@ietf.org; ietf-announce@ietf.org Cc: mpls@ietf.org Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-nm-req (MPLS TP Network M= anagement Requirements) to Proposed Standard Hi Ben, Basically I want to understand whether PID is required for OAM or not? Also= is OAM a type of MCC traffic? Thanks, Shahram -----Original Message----- From: benjamin.niven-jenkins@bt.com [mailto:benjamin.niven-jenkins@bt.com] Sent: Monday, September 21, 2009 4:32 PM To: Shahram Davari; ietf@ietf.org; ietf-announce@ietf.org Cc: mpls@ietf.org Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-nm-req (MPLS TP Network M= anagement Requirements) to Proposed Standard Sharam, The draft describes network management requirements and at most states that= OAM must be configurable by network management. It presupposes nothing abo= ut the OAM mechanism used or now the individual network elements (LSRs) rec= ognise the OAM packets themselves. So I don't understand your question in r= egards to the draft as the question you ask is not relevant within the scop= e of the draft. Ben ________________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf Of Shahram Da= vari [davari@broadcom.com] Sent: Tuesday, September 22, 2009 12:24 AM To: ietf@ietf.org; IETF-Announce Cc: mpls@ietf.org Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-nm-req (MPLS TP Network M= anagement Requirements) to Proposed Standard Hi, Just for clarification, does this draft require using a PID for BFD and LSP= -ping? If not how are the various OAM types identified? Thanks, Shahram -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of The= IESG Sent: Monday, September 21, 2009 3:54 PM To: IETF-Announce Cc: mpls@ietf.org Subject: [mpls] Last Call: draft-ietf-mpls-tp-nm-req (MPLS TP Network Manag= ement Requirements) to Proposed Standard The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'MPLS TP Network Management Requirements ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2009-10-05. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-nm-req-05.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag= =3D18244&rfc_flag=3D0 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From Italo.Busi@alcatel-lucent.it Tue Sep 22 09:45:18 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B82328C0FB for ; Tue, 22 Sep 2009 09:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.604 X-Spam-Level: X-Spam-Status: No, score=-5.604 tagged_above=-999 required=5 tests=[AWL=0.645, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UB6Dr2CzLF+U for ; Tue, 22 Sep 2009 09:45:16 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id A8AE93A69FE for ; Tue, 22 Sep 2009 09:45:15 -0700 (PDT) Received: from FRVELSBHS04.ad2.ad.alcatel.com (frvelsbhs04.dc-m.alcatel-lucent.com [155.132.6.76]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n8MGkEwx008289; Tue, 22 Sep 2009 18:46:14 +0200 Received: from FRVELSMBS21.ad2.ad.alcatel.com ([155.132.6.55]) by FRVELSBHS04.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Sep 2009 18:46:14 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Sep 2009 18:46:13 +0200 Message-ID: <6FD21B53861BF44AA90A288402036AB402897190@FRVELSMBS21.ad2.ad.alcatel.com> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD6815751C376@SJEXCHCCR02.corp.ad.broadcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ACH architecture (was RE: [mpls] Last Call: draft-ietf-mpls-tp-nm-req (MPLS TP Network Management Requirements) to Proposed Standard) Thread-Index: Aco7Dw5iy6i+rob1SduleYEPTiGX/AAA1N1wAABYpnoAADD7wAABp8Y6AACHRnAAF9TYsA== References: <20090921225416.3274728C1A8@core3.amsl.com>, <2C2F1EBA8050E74EA81502D5740B4BD6815751C363@SJEXCHCCR02.corp.ad.broadcom.com><9C31FA6F6F10D641B0B16A91BC374187B3213243F3@RDW083V001RVA1.domain1.systemhost.net>, <2C2F1EBA8050E74EA81502D5740B4BD6815751C367@SJEXCHCCR02.corp.ad.broadcom.com><9C31FA6F6F10D641B0B16A91BC374187B321CA29D1@RDW083V001RVA1.domain1.systemhost.net> <2C2F1EBA8050E74EA81502D5740B4BD6815751C376@SJEXCHCCR02.corp.ad.broadcom.com> From: "BUSI ITALO" To: "Shahram Davari" , X-OriginalArrivalTime: 22 Sep 2009 16:46:14.0379 (UTC) FILETIME=[32A463B0:01CA3BA4] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: mpls@ietf.org Subject: [mpls] ACH architecture (was RE: Last Call: draft-ietf-mpls-tp-nm-req (MPLS TP Network Management Requirements) to Proposed Standard) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2009 16:45:18 -0000 Shahram, I have changed the title of the mail as I think that both of you are correct: - Ben is right in claiming your question outside the scope of NM Requirements draft - you are right in asking additional clarification about the ACH architecture The main idea of RFC 5586 is that the ACH channel type identifies the type of G-ACh message that follows and whether or not the ACH is followed by an ACH TLV header. Each draft/RFC defining a protocol to be carried within the ACH will require IANA to allocate a specific value for the Channel Type and define the exact structure of the G-ACh message following the ACH including whether or not an ACH TLV header follows the ACH. In this context, draft-ietf-mpls-tp-gach-dcn-06, defines the protocol solution for SCC and MCC packets. According to this draft the ACH channel type xx identifies an MCC packet while the ACH channel type yy identifies an SCC packet. In both cases, there is no ACH TLV header following the ACH and a PID field is inserted, within the G-ACh message, to identify the specific L3 PDU following the PID (IPv4 or IPv6 or OSI packet). This structure is specific to the MCC and SCC solution and do not necessarily apply to BFD or other OAM protocols. For BFD there are some drafts which are going to be merged. According to the presentation we had at the IETF 75, we can foresee two ACH channel types: - 0x07 (as defined in vccv bfd) to indicate that the G-ACh message contains a BFD packet w/o the ACH TLV header (and w/o any PID field) - a new TBD value to indicate that the G-ACh message containing a BFD packet with the ACH TLV header (and w/o any PID field) In both cases there will be no PID field in a packet carrying BFD. Work still needs to be done for other OAM tools but I do not foresee any need to encode a PID field in other OAM tools. I hope this helps clarifying the issue. Italo > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > Behalf Of Shahram Davari > Sent: Tuesday, September 22, 2009 2:42 AM > To: benjamin.niven-jenkins@bt.com > Cc: mpls@ietf.org > Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-nm-req=20 > (MPLS TP Network Management Requirements) to Proposed Standard >=20 > Ben, >=20 > OK let me put it in another way: >=20 > Is PID always required after the G-ACH Channel type or it=20 > depends on the Channel Type? I think this question is very=20 > relevant to this draft. >=20 > Thanks, > Shahram=20 >=20 > -----Original Message----- > From: benjamin.niven-jenkins@bt.com=20 > [mailto:benjamin.niven-jenkins@bt.com]=20 > Sent: Monday, September 21, 2009 5:31 PM > To: Shahram Davari > Cc: mpls@ietf.org > Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-nm-req=20 > (MPLS TP Network Management Requirements) to Proposed Standard >=20 > Sharam, >=20 > Which is a fine question to ask but IMO is not relevant in=20 > the context of the NM requirements draft. >=20 > Within the OAM requirements it is relevant as it is a=20 > requirement to be able to distinguish between OAM traffic and=20 > data traffic. >=20 > Within the solutions drafts it is relevant as they should=20 > define the mechanism by which OAM packets are identified. >=20 > A MCC may run OAM but your question is still not relevant in=20 > the context of the NM requirements draft as the OAM=20 > requirements for the MCC should inherit from the OAM=20 > requirements draft and the OAM solutions themselves. >=20 > Ben > ________________________________________ > From: Shahram Davari [davari@broadcom.com] > Sent: Tuesday, September 22, 2009 12:39 AM > To: Niven-jenkins,B,Ben,DMF R; ietf@ietf.org; ietf-announce@ietf.org > Cc: mpls@ietf.org > Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-nm-req=20 > (MPLS TP Network Management Requirements) to Proposed Standard >=20 > Hi Ben, >=20 > Basically I want to understand whether PID is required for=20 > OAM or not? Also is OAM a type of MCC traffic? >=20 > Thanks, > Shahram >=20 > -----Original Message----- > From: benjamin.niven-jenkins@bt.com=20 > [mailto:benjamin.niven-jenkins@bt.com] > Sent: Monday, September 21, 2009 4:32 PM > To: Shahram Davari; ietf@ietf.org; ietf-announce@ietf.org > Cc: mpls@ietf.org > Subject: RE: [mpls] Last Call: draft-ietf-mpls-tp-nm-req=20 > (MPLS TP Network Management Requirements) to Proposed Standard >=20 > Sharam, >=20 > The draft describes network management requirements and at=20 > most states that OAM must be configurable by network=20 > management. It presupposes nothing about the OAM mechanism=20 > used or now the individual network elements (LSRs) recognise=20 > the OAM packets themselves. So I don't understand your=20 > question in regards to the draft as the question you ask is=20 > not relevant within the scope of the draft. >=20 > Ben >=20 > ________________________________________ > From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] On Behalf=20 > Of Shahram Davari [davari@broadcom.com] > Sent: Tuesday, September 22, 2009 12:24 AM > To: ietf@ietf.org; IETF-Announce > Cc: mpls@ietf.org > Subject: Re: [mpls] Last Call: draft-ietf-mpls-tp-nm-req=20 > (MPLS TP Network Management Requirements) to Proposed Standard >=20 > Hi, >=20 > Just for clarification, does this draft require using a PID=20 > for BFD and LSP-ping? If not how are the various OAM types identified? >=20 > Thanks, > Shahram >=20 > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On=20 > Behalf Of The IESG > Sent: Monday, September 21, 2009 3:54 PM > To: IETF-Announce > Cc: mpls@ietf.org > Subject: [mpls] Last Call: draft-ietf-mpls-tp-nm-req (MPLS TP=20 > Network Management Requirements) to Proposed Standard >=20 > The IESG has received a request from the Multiprotocol Label=20 > Switching WG > (mpls) to consider the following document: >=20 > - 'MPLS TP Network Management Requirements ' > as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive=20 > comments to the > ietf@ietf.org mailing lists by 2009-10-05. Exceptionally, > comments may be sent to iesg@ietf.org instead. In either case, please > retain the beginning of the Subject line to allow automated sorting. >=20 > The file can be obtained via > http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-nm-req-05.txt >=20 >=20 > IESG discussion can be tracked via > https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dvie > w_id&dTag=3D18244&rfc_flag=3D0 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From root@core3.amsl.com Thu Sep 24 04:00:02 2009 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 175393A694D; Thu, 24 Sep 2009 04:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090924110002.175393A694D@core3.amsl.com> Date: Thu, 24 Sep 2009 04:00:02 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-gmpls-lsp-reroute-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 11:00:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : PathErr Message Triggered MPLS and GMPLS LSP Reroute Author(s) : L. Berger, et al. Filename : draft-ietf-mpls-gmpls-lsp-reroute-06.txt Pages : 12 Date : 2009-09-24 This document describes how Resource ReserVation Protocol (RSVP) PathErr Messages may be used to trigger rerouting of Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) point-to-point Traffic Engineering (TE) Label Switched Paths (LSPs) without first removing LSP state or resources. Such LSP rerouting may be desirable in a number of cases including, for example, soft-preemption and graceful shutdown. This document describes the usage of existing Standards Track mechanisms to support LSP rerouting. In this case, it relies on mechanisms already defined as part of RSVP-TE and simply describes a sequence of actions to be executed. While existing protocol definition can be used to support reroute applications, this document also defines a new reroute-specific error code to allow for the future definition of reroute application-specific error values. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-gmpls-lsp-reroute-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-gmpls-lsp-reroute-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-24035909.I-D@ietf.org> --NextPart-- From rfc-editor@rfc-editor.org Thu Sep 24 15:53:19 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54FF13A6862; Thu, 24 Sep 2009 15:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.603 X-Spam-Level: X-Spam-Status: No, score=-16.603 tagged_above=-999 required=5 tests=[AWL=0.396, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHIYtge-gdjD; Thu, 24 Sep 2009 15:53:18 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id 7C6A83A6846; Thu, 24 Sep 2009 15:53:18 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id 8D08F32CFA2; Thu, 24 Sep 2009 15:53:58 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20090924225358.8D08F32CFA2@bosco.isi.edu> Date: Thu, 24 Sep 2009 15:53:58 -0700 (PDT) Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 5654 on Requirements of an MPLS Transport Profile X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Sep 2009 22:53:19 -0000 A new Request for Comments is now available in online RFC libraries. RFC 5654 Title: Requirements of an MPLS Transport Profile Author: B. Niven-Jenkins, Ed., D. Brungard, Ed., M. Betts, Ed., N. Sprecher, S. Ueno Status: Standards Track Date: September 2009 Mailbox: benjamin.niven-jenkins@bt.com, dbrungard@att.com, malcolm.betts@huawei.com, nurit.sprecher@nsn.com, satoshi.ueno@ntt.com Pages: 31 Characters: 69999 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-tp-requirements-10.txt URL: http://www.rfc-editor.org/rfc/rfc5654.txt This document specifies the requirements of an MPLS Transport Profile (MPLS-TP). This document is a product of a joint effort of the International Telecommunications Union (ITU) and IETF to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by International Telecommunications Union - Telecommunications Standardization Sector (ITU-T). This work is based on two sources of requirements: MPLS and PWE3 architectures as defined by IETF, and packet transport networks as defined by ITU-T. The requirements expressed in this document are for the behavior of the protocol mechanisms and procedures that constitute building blocks out of which the MPLS Transport Profile is constructed. The requirements are not implementation requirements. [STANDARDS TRACK] This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute From loa@pi.nu Fri Sep 25 03:20:59 2009 Return-Path: X-Original-To: mpls@core3.amsl.com Delivered-To: mpls@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04E063A691E; Fri, 25 Sep 2009 03:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjuljQ+MJ8FE; Fri, 25 Sep 2009 03:20:58 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 2F22B3A68A5; Fri, 25 Sep 2009 03:20:58 -0700 (PDT) Received: from [192.36.158.110] (wdhcp-158-110.verkstad.net [192.36.158.110]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 99DBCD4052; Fri, 25 Sep 2009 12:22:06 +0200 (CEST) Message-ID: <4ABC99CC.5080602@pi.nu> Date: Fri, 25 Sep 2009 12:22:04 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: "mpls-tp@ietf.org" , mpls@ietf.org, pwe3@ietf.org, ccamp@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] RFC5654 "MPLS-TP Requirements" has been published X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 10:20:59 -0000 All, RFC5654 "MPLS-TP Requirements" has now been published. Please join me in congratulating the authors and editor to a very good job. /Loa -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From wwwrun@core3.amsl.com Fri Sep 25 08:07:36 2009 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 03B7528C121; Fri, 25 Sep 2009 08:07:35 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20090925150736.03B7528C121@core3.amsl.com> Date: Fri, 25 Sep 2009 08:07:36 -0700 (PDT) Cc: mpls mailing list , mpls chair , Internet Architecture Board , RFC Editor Subject: [mpls] Protocol Action: 'PathErr Message Triggered MPLS and GMPLS LSP Reroute' to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 15:07:36 -0000 The IESG has approved the following document: - 'PathErr Message Triggered MPLS and GMPLS LSP Reroute ' as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Ross Callon. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-gmpls-lsp-reroute-06.txt Technical Summary This document describes how RSVP PathErr Messages may be used to trigger rerouting of MPLS and GMPLS point-to-point TE-LSPs without first removing LSP state or resources. There are a number of cases where such rerouting is beneficial, e.g. soft-preemption and graceful shutdown. This document defines a new reroute-specific error code to allow for future definition of reroute application-specific error values. Working Group Summary This document was produced by the WG to help resolve issues with draft-ietf-mpls-soft-preemption. There was a fair degree of support for the concepts of soft preemption and graceful shutdown, so the common pieces were removed from draft-ietf-mpls-soft-preemption and added to this document. Document Quality There are currently no implementations of this work. We may assume from the level of interest in graceful shutdown and soft preemption that implementations are likely soon. Personnel Loa Andersson is the Document Shepherd. Adrian Farrel is the Responsible Area Director. From root@core3.amsl.com Fri Sep 25 09:15:01 2009 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8FAD03A6850; Fri, 25 Sep 2009 09:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090925161501.8FAD03A6850@core3.amsl.com> Date: Fri, 25 Sep 2009 09:15:01 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-framework-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Sep 2009 16:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : A Framework for MPLS in Transport Networks Author(s) : M. Bocci, et al. Filename : draft-ietf-mpls-tp-framework-05.txt Pages : 40 Date : 2009-09-25 This document specifies an architectural framework for the application of Multi Protocol Label Switching (MPLS) in transport networks, by enabling the construction of packet switched equivalents to traditional circuit switched carrier networks. It describes a common set of protocol functions--the MPLS Transport Profile (MPLS- TP)--that supports the operational models and capabilities typical of such networks, including signaled or explicitly provisioned bi- directional connection-oriented paths, protection and restoration mechanisms, comprehensive Operations, Administration and Maintenance (OAM) functions, and network operation in the absence of a dynamic control plane or IP forwarding support. Some of these functions exist in existing MPLS specifications, while others require extensions to existing specifications to meet the requirements of the MPLS-TP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-framework-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-tp-framework-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-25091129.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Sep 28 04:00:01 2009 Return-Path: X-Original-To: mpls@ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 3953B3A6822; Mon, 28 Sep 2009 04:00:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090928110001.3953B3A6822@core3.amsl.com> Date: Mon, 28 Sep 2009 04:00:01 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-3209-patherr-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Sep 2009 11:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : Node behavior upon originating and receiving Resource ReserVation Protocol (RSVP) Path Error message Author(s) : J. Vasseur, et al. Filename : draft-ietf-mpls-3209-patherr-06.txt Pages : 7 Date : 2009-09-28 The aim of this document is to describe a common practice with regard to the behavior of a node sending a Resource ReserVation Protocol (RSVP) Traffic Engineering (TE) Path Error message and to the behavior of a node receiving an RSVP Path Error message for a preempted Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Path (TE LSP). This document does not define any new protocol extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-3209-patherr-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-3209-patherr-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-09-28034643.I-D@ietf.org> --NextPart--