From loa@pi.nu Sun Oct 4 22:38:50 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 2F69E3A6996; Sun, 4 Oct 2009 22:38:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, 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 FX2AmCLE4s9p; Sun, 4 Oct 2009 22:38:49 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 495D23A6995; Sun, 4 Oct 2009 22:38:49 -0700 (PDT) Received: from [192.168.12.236] (unknown [195.65.225.94]) (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 9134DD404F; Mon, 5 Oct 2009 07:40:21 +0200 (CEST) Message-ID: <4AC986C4.4040106@pi.nu> Date: Mon, 05 Oct 2009 07:40:20 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mpls@ietf.org, ccamp@ietf.org, pwe3@ietf.org, "mpls-tp@ietf.org" , 'MPLS-TP ad hoc' Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Closing the IETF MEAD team 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, 05 Oct 2009 05:38:50 -0000 Dear all, The main MPLS-TP requirements work has been published as RFC 5654, and the two subsidiary requirements documents (NM and OAM) are close to publication with IETF last call ending later this week. The other key documents (the framework documents) have been adopted as MPLS working group documents and their text is substantially in place. Furthermore, a large number of the necessary solutions documents have been started and have good foundations. With this in mind, we think that the MEAD team has successfully delivered on its objectives. In view of the need to ensure that the MPLS-TP work is fully open to participation by everyone in the IETF community, and with the desire to "normalise" the process of document production and evolution, we have decided to close the MEAD team with immediate effect. All MPLS-TP work will now follow the usual IETF working group process with the MPLS working group being the lead working group, but with work being coordinated across other working groups (e.g. PWE3, CCAMP, Ops Area WG) as appropriate. We would like to take this opportunity to thank everyone who contributed to the work of the MEAD team, and hope that they will continue to participate in this effort within the IETF with the additional participation of all their colleagues. Best regards, Loa and Adrian -- 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 mtylenda@isocore.com Thu Oct 8 14:20: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 A189C3A6906 for ; Thu, 8 Oct 2009 14:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.704 X-Spam-Level: **** X-Spam-Status: No, score=4.704 tagged_above=-999 required=5 tests=[BAYES_80=2, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_102=0.6, RDNS_NONE=0.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 ChUNAlIw-QvE for ; Thu, 8 Oct 2009 14:20:22 -0700 (PDT) Received: from ns1.cpanel.btnaccess.com (unknown [205.177.121.254]) by core3.amsl.com (Postfix) with ESMTP id 064363A68FF for ; Thu, 8 Oct 2009 14:20:21 -0700 (PDT) Received: from [65.213.193.47] (helo=[127.0.0.1]) by ns1.cpanel.btnaccess.com with esmtpa (Exim 4.69) (envelope-from ) id 1Mw0R4-0007VJ-51 for mpls@ietf.org; Thu, 08 Oct 2009 17:22:06 -0400 Message-ID: <4ACE57EF.2050702@isocore.com> Date: Thu, 08 Oct 2009 17:21:51 -0400 From: Matt Tylenda User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com Subject: [mpls] MPLS2009 International Conference: Register Now! 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, 08 Oct 2009 21:20:22 -0000 The 12th annual MPLS 2009 is set to open on October 25, 2009 in Washington,DC The technical program details and sponsors list is available at www.mpls2009.com Registration is still open - http://www.isocore.com/mpls2009/registration/attendees.htm We look forward to seeing you at the show! -Matt From web-usrn@ISI.EDU Tue Oct 13 00:32:01 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 A6F873A67B1 for ; Tue, 13 Oct 2009 00:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.539 X-Spam-Level: X-Spam-Status: No, score=-17.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 ExVB1XVH0qDb for ; Tue, 13 Oct 2009 00:32:00 -0700 (PDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id BFE873A679F for ; Tue, 13 Oct 2009 00:32:00 -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 n9D7V7is029292; Tue, 13 Oct 2009 00:31:08 -0700 (PDT) Received: (from web-usrn@localhost) by boreas.isi.edu (8.13.8/8.13.8/Submit) id n9D7V2IF029257; Tue, 13 Oct 2009 00:31:02 -0700 (PDT) Date: Tue, 13 Oct 2009 00:31:02 -0700 (PDT) Message-Id: <200910130731.n9D7V2IF029257@boreas.isi.edu> To: flefauch@cisco.com, liwwu@cisco.com, bsd@cisco.com, davari@ieee.org, pasi.vaananen@nokia.com, ram@axiowave.com, pierrick.cheval@space.alcatel.fr, jh@song.fi, 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, flefauch@cisco.com, rfc-editor@rfc-editor.org Subject: [mpls] [Editorial Errata Reported] RFC3270 (1910) 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, 13 Oct 2009 07:32:01 -0000 The following errata report has been submitted for RFC3270, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3270&eid=1910 -------------------------------------- Type: Editorial Reported by: Francois Le Faucheur Section: 5.2.1 Original Text ------------- MAPnb : 4 bits Indicates the number of MAP entries included in the DIFFSERV Object. This can be set to any value from 0 to 8. Corrected Text -------------- MAPnb : 4 bits Indicates the number of MAP entries included in the DIFFSERV Object. This can be set to any value from 0 to 7. Notes ----- This errata was reported by Colors Springfield on 13 October 2009. 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. -------------------------------------- RFC3270 (draft-ietf-mpls-diff-ext-09) -------------------------------------- Title : Multi-Protocol Label Switching (MPLS) Support of Differentiated Services Publication Date : May 2002 Author(s) : F. Le Faucheur, L. Wu, B. Davie, S. Davari, P. Vaananen, R. Krishnan, P. Cheval, J. Heinanen Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From fanshaojun@huawei.com Tue Oct 13 18:34:55 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 1015728C147 for ; Tue, 13 Oct 2009 18:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 FXSjPMDHEkoN for ; Tue, 13 Oct 2009 18:34:54 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id C85003A68C4 for ; Tue, 13 Oct 2009 18:34:53 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRH005HDDQ5MZ@szxga04-in.huawei.com> for mpls@ietf.org; Wed, 14 Oct 2009 09:34:53 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRH00BRUDQ5FO@szxga04-in.huawei.com> for mpls@ietf.org; Wed, 14 Oct 2009 09:34:53 +0800 (CST) Received: from f62882A ([10.112.28.114]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRH0089PDQ4AJ@szxml04-in.huawei.com> for mpls@ietf.org; Wed, 14 Oct 2009 09:34:53 +0800 (CST) Date: Wed, 14 Oct 2009 09:34:52 +0800 From: fanshaojun In-reply-to: <200910130731.n9D7V2IF029257@boreas.isi.edu> To: 'RFC Errata System' , flefauch@cisco.com, liwwu@cisco.com, bsd@cisco.com, davari@ieee.org, pasi.vaananen@nokia.com, ram@axiowave.com, pierrick.cheval@space.alcatel.fr, jh@song.fi, rcallon@juniper.net, Adrian.Farrel@huawei.com, swallow@cisco.com, loa@pi.nu Message-id: <000801ca4c6e$874f86d0$a800a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcpMaAmD46o8xjx9SL+1SZ7CtbcRawABmcqQ Cc: mpls@ietf.org, flefauch@cisco.com Subject: Re: [mpls] [Editorial Errata Reported] RFC3270 (1910) 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, 14 Oct 2009 01:34:55 -0000 Dear ALL: This MAPnb column occupied 4 bits in the object. So it can be set to any value from 0 to 15. Corrected Text will be -------------- MAPnb : 4 bits Indicates the number of MAP entries included in the DIFFSERV Object. This can be set to any value from 0 to 15. -----Original Message----- From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] Sent: Tuesday, October 13, 2009 3:31 PM To: flefauch@cisco.com; liwwu@cisco.com; bsd@cisco.com; davari@ieee.org; pasi.vaananen@nokia.com; ram@axiowave.com; pierrick.cheval@space.alcatel.fr; jh@song.fi; rcallon@juniper.net; adrian.farrel@huawei.com; swallow@cisco.com; loa@pi.nu Cc: mpls@ietf.org; flefauch@cisco.com; rfc-editor@rfc-editor.org Subject: [mpls] [Editorial Errata Reported] RFC3270 (1910) The following errata report has been submitted for RFC3270, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3270&eid=1910 -------------------------------------- Type: Editorial Reported by: Francois Le Faucheur Section: 5.2.1 Original Text ------------- MAPnb : 4 bits Indicates the number of MAP entries included in the DIFFSERV Object. This can be set to any value from 0 to 8. Corrected Text -------------- MAPnb : 4 bits Indicates the number of MAP entries included in the DIFFSERV Object. This can be set to any value from 0 to 7. Notes ----- This errata was reported by Colors Springfield on 13 October 2009. 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. -------------------------------------- RFC3270 (draft-ietf-mpls-diff-ext-09) -------------------------------------- Title : Multi-Protocol Label Switching (MPLS) Support of Differentiated Services Publication Date : May 2002 Author(s) : F. Le Faucheur, L. Wu, B. Davie, S. Davari, P. Vaananen, R. Krishnan, P. Cheval, J. Heinanen Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From flefauch@cisco.com Wed Oct 14 04:36:51 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 84B883A67C2 for ; Wed, 14 Oct 2009 04:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.555 X-Spam-Level: X-Spam-Status: No, score=-10.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, 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 KkiLSlKXDQrX for ; Wed, 14 Oct 2009 04:36:50 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id D555D3A6974 for ; Wed, 14 Oct 2009 04:36:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=flefauch@cisco.com; l=3350; q=dns/txt; s=amsiport01001; t=1255520212; x=1256729812; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Francois=20Le=20Faucheur=20 |Subject:=20Re:=20[mpls]=20[Editorial=20Errata=20Reported ]=20RFC3270=20(1910)|Date:=20Wed,=2014=20Oct=202009=2013: 36:47=20+0200|Message-Id:=20<62010218-5D0F-46F6-B1A6-DB7F 4D58B61F@cisco.com>|To:=20fanshaojun=20|Cc:=20Le=20Faucheur=20Francois=20,=0D=0A=20=20=20=20=20=20=20=20RFC=20Errata=20System=20 ,=20liwwu@cisco.com,=0D=0A=20 =20=20=20=20=20=20=20Bruce=20Davie=20,=20d avari@ieee.org,=20pasi.vaananen@nokia.com,=0D=0A=20=20=20 =20=20=20=20=20ram@axiowave.com,=20pierrick.cheval@space. alcatel.fr,=20jh@song.fi,=0D=0A=20=20=20=20=20=20=20=20Ro ss=20Callon=20,=0D=0A=20=20=20=20=20 =20=20=20Adrian=20Farrel=20,=0D =0A=20=20=20=20=20=20=20=20George=20Swallow=20,=20Loa=20Andersson=20,=0D=0A=20=20=20 =20=20=20=20=20mpls@ietf.org,=20springfield=20colors=20|Mime-Version:=201.0=20(Apple =20Message=20framework=20v1076) |Content-Transfer-Encoding:=207bit|In-Reply-To:=20<000801 ca4c6e$874f86d0$a800a8c0@china.huawei.com>|References:=20 <000801ca4c6e$874f86d0$a800a8c0@china.huawei.com>; bh=LfvlI7dC1PavYj/13JoKZ6Gx1NV4r6qvxyyx9KbdsRQ=; b=XRE1DW10UF9K4GtJPc4EDTXum26wFemEuMXEQNOqu9wAjbT0+GGWVJgX xbDEihBROnYFS4Gz6TTM5rx+B4MuNNbI4G2dz//AzS71/mecXKMlfjkUw aYUPer6F4bChQARCDtmRx+TJ3NgxsrWjzwVmYLrAtholC1DZUKqJfhBrB 8=; Authentication-Results: ams-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,557,1249257600"; d="scan'208";a="51759031" Received: from ams-core-1.cisco.com ([144.254.224.150]) by ams-iport-1.cisco.com with ESMTP; 14 Oct 2009 11:36:51 +0000 Received: from ams-flefauch-8716.cisco.com (ams-flefauch-8716.cisco.com [10.55.161.199]) by ams-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9EBamRR000939; Wed, 14 Oct 2009 11:36:49 GMT References: <000801ca4c6e$874f86d0$a800a8c0@china.huawei.com> In-Reply-To: <000801ca4c6e$874f86d0$a800a8c0@china.huawei.com> Mime-Version: 1.0 (Apple Message framework v1076) Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Message-Id: <62010218-5D0F-46F6-B1A6-DB7F4D58B61F@cisco.com> Content-Transfer-Encoding: 7bit From: Francois Le Faucheur Date: Wed, 14 Oct 2009 13:36:47 +0200 To: fanshaojun X-Mailer: Apple Mail (2.1076) Cc: mpls@ietf.org, Le Faucheur Francois , jh@song.fi, Bruce Davie , liwwu@cisco.com, ram@axiowave.com, pierrick.cheval@space.alcatel.fr, springfield colors , Ross Callon , pasi.vaananen@nokia.com, Adrian Farrel , davari@ieee.org, RFC Errata System Subject: Re: [mpls] [Editorial Errata Reported] RFC3270 (1910) 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, 14 Oct 2009 11:36:51 -0000 Hello, Just looked back at RFC3270: MAPnb defines the number of MAP entries carried inside the DIFFSERV object. Each MAP entry defines the mapping between one EXP (now "COS") field value and one PHB. Since there is only 8 possible EXP values, I think: * MAPnb should actually be encoded over 3 bits, and not 4 bits * value range should be 0-7. Does that sound right? If yes, I can update the errata with appropraite required changes. Francois On 14 Oct 2009, at 03:34, fanshaojun wrote: > Dear ALL: > > This MAPnb column occupied 4 bits in the object. So it can be set to > any > value from 0 to 15. > > Corrected Text will be > -------------- > MAPnb : 4 bits > Indicates the number of MAP entries included in the DIFFSERV > Object. This can be set to any value from 0 to 15. > > > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: Tuesday, October 13, 2009 3:31 PM > To: flefauch@cisco.com; liwwu@cisco.com; bsd@cisco.com; davari@ieee.org > ; > pasi.vaananen@nokia.com; ram@axiowave.com; pierrick.cheval@space.alcatel.fr > ; > jh@song.fi; rcallon@juniper.net; adrian.farrel@huawei.com; > swallow@cisco.com; loa@pi.nu > Cc: mpls@ietf.org; flefauch@cisco.com; rfc-editor@rfc-editor.org > Subject: [mpls] [Editorial Errata Reported] RFC3270 (1910) > > > The following errata report has been submitted for RFC3270, > "Multi-Protocol Label Switching (MPLS) Support of Differentiated > Services". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3270&eid=1910 > > -------------------------------------- > Type: Editorial > Reported by: Francois Le Faucheur > > Section: 5.2.1 > > Original Text > ------------- > MAPnb : 4 bits > Indicates the number of MAP entries included in the DIFFSERV > Object. This can be set to any value from 0 to 8. > > Corrected Text > -------------- > MAPnb : 4 bits > Indicates the number of MAP entries included in the DIFFSERV > Object. This can be set to any value from 0 to 7. > > Notes > ----- > This errata was reported by Colors Springfield > > on 13 October 2009. > > 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. > > -------------------------------------- > RFC3270 (draft-ietf-mpls-diff-ext-09) > -------------------------------------- > Title : Multi-Protocol Label Switching (MPLS) Support of > Differentiated Services > Publication Date : May 2002 > Author(s) : F. Le Faucheur, L. Wu, B. Davie, S. Davari, P. > Vaananen, R. Krishnan, P. Cheval, J. Heinanen > Category : PROPOSED STANDARD > Source : Multiprotocol Label Switching > Area : Routing > Stream : IETF > Verifying Party : IESG > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From davari@broadcom.com Wed Oct 14 09:10:29 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 37E3428C146 for ; Wed, 14 Oct 2009 09:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 288Bdvf4PCv7 for ; Wed, 14 Oct 2009 09:10:28 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id 4363E3A6867 for ; Wed, 14 Oct 2009 09:10:28 -0700 (PDT) Received: from [10.16.192.232] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Wed, 14 Oct 2009 09:09:46 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Wed, 14 Oct 2009 09:09:46 -0700 From: "Shahram Davari" To: "Francois Le Faucheur" , fanshaojun Date: Wed, 14 Oct 2009 09:09:44 -0700 Thread-Topic: [mpls] [Editorial Errata Reported] RFC3270 (1910) Thread-Index: AcpMwrD4g4o2n3emQq2tkDpAyDzVIwAJe08w Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD681576831C9@SJEXCHCCR02.corp.ad.broadcom.com> References: <000801ca4c6e$874f86d0$a800a8c0@china.huawei.com> <62010218-5D0F-46F6-B1A6-DB7F4D58B61F@cisco.com> In-Reply-To: <62010218-5D0F-46F6-B1A6-DB7F4D58B61F@cisco.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: 66CB28405S448448247-02-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" , "jh@song.fi" , Bruce Davie , "liwwu@cisco.com" , "ram@axiowave.com" , "pierrick.cheval@space.alcatel.fr" , springfield colors , "davari@ieee.org" , "pasi.vaananen@nokia.com" , Adrian Farrel , Ross Callon , RFC Errata System Subject: Re: [mpls] [Editorial Errata Reported] RFC3270 (1910) 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, 14 Oct 2009 16:10:29 -0000 Hi Francois and co-authors, I think you are correct. So I have no objection in changing that in the Err= ata. Regards, Shahram=20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Fra= ncois Le Faucheur Sent: Wednesday, October 14, 2009 4:37 AM To: fanshaojun Cc: mpls@ietf.org; Le Faucheur Francois; jh@song.fi; Bruce Davie; liwwu@cis= co.com; ram@axiowave.com; pierrick.cheval@space.alcatel.fr; springfield col= ors; Ross Callon; pasi.vaananen@nokia.com; Adrian Farrel; davari@ieee.org; = RFC Errata System Subject: Re: [mpls] [Editorial Errata Reported] RFC3270 (1910) Hello, Just looked back at RFC3270: MAPnb defines the number of MAP entries carried inside the DIFFSERV =20 object. Each MAP entry defines the mapping between one EXP (now "COS") field =20 value and one PHB. Since there is only 8 possible EXP values, I think: * MAPnb should actually be encoded over 3 bits, and not 4 bits * value range should be 0-7. Does that sound right? If yes, I can update the errata with appropraite required changes. Francois On 14 Oct 2009, at 03:34, fanshaojun wrote: > Dear ALL: > > This MAPnb column occupied 4 bits in the object. So it can be set to =20 > any > value from 0 to 15. > > Corrected Text will be > -------------- > MAPnb : 4 bits > Indicates the number of MAP entries included in the DIFFSERV > Object. This can be set to any value from 0 to 15. > > > -----Original Message----- > From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] > Sent: Tuesday, October 13, 2009 3:31 PM > To: flefauch@cisco.com; liwwu@cisco.com; bsd@cisco.com; davari@ieee.org=20 > ; > pasi.vaananen@nokia.com; ram@axiowave.com; pierrick.cheval@space.alcatel.= fr=20 > ; > jh@song.fi; rcallon@juniper.net; adrian.farrel@huawei.com; > swallow@cisco.com; loa@pi.nu > Cc: mpls@ietf.org; flefauch@cisco.com; rfc-editor@rfc-editor.org > Subject: [mpls] [Editorial Errata Reported] RFC3270 (1910) > > > The following errata report has been submitted for RFC3270, > "Multi-Protocol Label Switching (MPLS) Support of Differentiated =20 > Services". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D3270&eid=3D1910 > > -------------------------------------- > Type: Editorial > Reported by: Francois Le Faucheur > > Section: 5.2.1 > > Original Text > ------------- > MAPnb : 4 bits > Indicates the number of MAP entries included in the DIFFSERV > Object. This can be set to any value from 0 to 8. > > Corrected Text > -------------- > MAPnb : 4 bits > Indicates the number of MAP entries included in the DIFFSERV > Object. This can be set to any value from 0 to 7. > > Notes > ----- > This errata was reported by Colors Springfield > > on 13 October 2009. > > 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. > > -------------------------------------- > RFC3270 (draft-ietf-mpls-diff-ext-09) > -------------------------------------- > Title : Multi-Protocol Label Switching (MPLS) Support of > Differentiated Services > Publication Date : May 2002 > Author(s) : F. Le Faucheur, L. Wu, B. Davie, S. Davari, P. > Vaananen, R. Krishnan, P. Cheval, J. Heinanen > Category : PROPOSED STANDARD > Source : Multiprotocol Label Switching > Area : Routing > Stream : IETF > Verifying Party : IESG > > > _______________________________________________ > 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 Adrian.Farrel@huawei.com Thu Oct 15 07:56:50 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 3DA963A69E9 for ; Thu, 15 Oct 2009 07:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.893 X-Spam-Level: X-Spam-Status: No, score=-1.893 tagged_above=-999 required=5 tests=[AWL=0.705, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] 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 nTuKVXgncBbs for ; Thu, 15 Oct 2009 07:56:48 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 98E383A67B8 for ; Thu, 15 Oct 2009 07:56:48 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRK00JX49IRHE@usaga01-in.huawei.com> for mpls@ietf.org; Thu, 15 Oct 2009 07:56:51 -0700 (PDT) Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRK00J939IME1@usaga01-in.huawei.com> for mpls@ietf.org; Thu, 15 Oct 2009 07:56:51 -0700 (PDT) Date: Thu, 15 Oct 2009 15:56:40 +0100 From: Adrian Farrel To: Shahram Davari , Francois Le Faucheur , fanshaojun Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <000801ca4c6e$874f86d0$a800a8c0@china.huawei.com> <62010218-5D0F-46F6-B1A6-DB7F4D58B61F@cisco.com> <2C2F1EBA8050E74EA81502D5740B4BD681576831C9@SJEXCHCCR02.corp.ad.broadcom.com> Cc: mpls@ietf.org, jh@song.fi, Bruce Davie , liwwu@cisco.com, ram@axiowave.com, pierrick.cheval@space.alcatel.fr, springfield colors , Ross Callon , pasi.vaananen@nokia.com, davari@ieee.org, RFC Errata System Subject: Re: [mpls] [Editorial Errata Reported] RFC3270 (1910) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2009 14:56:50 -0000 Hi, Note that, per RFC5462, the EXP bits are renamed to the TC (Traffic Class) field. Not the "COS field". Cheers, Adrian ----- Original Message ----- From: "Shahram Davari" To: "Francois Le Faucheur" ; "fanshaojun" Cc: ; ; "Bruce Davie" ; ; ; ; "springfield colors" ; ; ; "Adrian Farrel" ; "Ross Callon" ; "RFC Errata System" Sent: Wednesday, October 14, 2009 5:09 PM Subject: Re: [mpls] [Editorial Errata Reported] RFC3270 (1910) > Hi Francois and co-authors, > > I think you are correct. So I have no objection in changing that in the > Errata. > > Regards, > Shahram > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Francois Le Faucheur > Sent: Wednesday, October 14, 2009 4:37 AM > To: fanshaojun > Cc: mpls@ietf.org; Le Faucheur Francois; jh@song.fi; Bruce Davie; > liwwu@cisco.com; ram@axiowave.com; pierrick.cheval@space.alcatel.fr; > springfield colors; Ross Callon; pasi.vaananen@nokia.com; Adrian Farrel; > davari@ieee.org; RFC Errata System > Subject: Re: [mpls] [Editorial Errata Reported] RFC3270 (1910) > > Hello, > > Just looked back at RFC3270: > MAPnb defines the number of MAP entries carried inside the DIFFSERV > object. > Each MAP entry defines the mapping between one EXP (now "COS") field > value and one PHB. > Since there is only 8 possible EXP values, I think: > * MAPnb should actually be encoded over 3 bits, and not 4 bits > * value range should be 0-7. > Does that sound right? > > If yes, I can update the errata with appropraite required changes. > > Francois > > On 14 Oct 2009, at 03:34, fanshaojun wrote: > >> Dear ALL: >> >> This MAPnb column occupied 4 bits in the object. So it can be set to >> any >> value from 0 to 15. >> >> Corrected Text will be >> -------------- >> MAPnb : 4 bits >> Indicates the number of MAP entries included in the DIFFSERV >> Object. This can be set to any value from 0 to 15. >> >> >> -----Original Message----- >> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >> Sent: Tuesday, October 13, 2009 3:31 PM >> To: flefauch@cisco.com; liwwu@cisco.com; bsd@cisco.com; davari@ieee.org >> ; >> pasi.vaananen@nokia.com; ram@axiowave.com; >> pierrick.cheval@space.alcatel.fr >> ; >> jh@song.fi; rcallon@juniper.net; adrian.farrel@huawei.com; >> swallow@cisco.com; loa@pi.nu >> Cc: mpls@ietf.org; flefauch@cisco.com; rfc-editor@rfc-editor.org >> Subject: [mpls] [Editorial Errata Reported] RFC3270 (1910) >> >> >> The following errata report has been submitted for RFC3270, >> "Multi-Protocol Label Switching (MPLS) Support of Differentiated >> Services". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3270&eid=1910 >> >> -------------------------------------- >> Type: Editorial >> Reported by: Francois Le Faucheur >> >> Section: 5.2.1 >> >> Original Text >> ------------- >> MAPnb : 4 bits >> Indicates the number of MAP entries included in the DIFFSERV >> Object. This can be set to any value from 0 to 8. >> >> Corrected Text >> -------------- >> MAPnb : 4 bits >> Indicates the number of MAP entries included in the DIFFSERV >> Object. This can be set to any value from 0 to 7. >> >> Notes >> ----- >> This errata was reported by Colors Springfield >> > > >> on 13 October 2009. >> >> 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. >> >> -------------------------------------- >> RFC3270 (draft-ietf-mpls-diff-ext-09) >> -------------------------------------- >> Title : Multi-Protocol Label Switching (MPLS) Support of >> Differentiated Services >> Publication Date : May 2002 >> Author(s) : F. Le Faucheur, L. Wu, B. Davie, S. Davari, P. >> Vaananen, R. Krishnan, P. Cheval, J. Heinanen >> Category : PROPOSED STANDARD >> Source : Multiprotocol Label Switching >> Area : Routing >> Stream : IETF >> Verifying Party : IESG >> >> >> _______________________________________________ >> 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 > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From root@core3.amsl.com Fri Oct 16 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 547A128C106; Fri, 16 Oct 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: <20091016161501.547A128C106@core3.amsl.com> Date: Fri, 16 Oct 2009 09:15:01 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-framework-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: Fri, 16 Oct 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-06.txt Pages : 42 Date : 2009-10-16 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 for point-to-point paths, 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-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-framework-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-16090631.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Fri Oct 16 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 2ACB03A67AF; Fri, 16 Oct 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: <20091016220001.2ACB03A67AF@core3.amsl.com> Date: Fri, 16 Oct 2009 15:00:01 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-process-03.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, 16 Oct 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 : IETF Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS-TP) Document Process Author(s) : L. Andersson, et al. Filename : draft-ietf-mpls-tp-process-03.txt Pages : 21 Date : 2009-10-16 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 does 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-03.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-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-16145745.I-D@ietf.org> --NextPart-- From Adrian.Farrel@huawei.com Fri Oct 16 15:03:38 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 D8A793A6884; Fri, 16 Oct 2009 15:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.345 X-Spam-Level: X-Spam-Status: No, score=-1.345 tagged_above=-999 required=5 tests=[AWL=1.253, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] 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 0Dq72ctgOl0j; Fri, 16 Oct 2009 15:03:38 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 212E13A67F4; Fri, 16 Oct 2009 15:03:38 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KRM00IVTNY35U@usaga03-in.huawei.com>; Fri, 16 Oct 2009 17:03:39 -0500 (CDT) Received: from your029b8cecfe (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KRM005HSNY1DK@usaga03-in.huawei.com>; Fri, 16 Oct 2009 17:03:39 -0500 (CDT) Date: Fri, 16 Oct 2009 23:03:31 +0100 From: Adrian Farrel To: mpls-tp@ietf.org Message-id: <98ADC33985FC4742B35FCD677A5DEFF1@your029b8cecfe> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Mailer: Microsoft Outlook Express 6.00.2900.5843 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=original Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20091016220001.2ACB03A67AF@core3.amsl.com> Cc: mpls@ietf.org Subject: Re: [mpls] I-D Action:draft-ietf-mpls-tp-process-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Oct 2009 22:03:38 -0000 Hi, I have updated this draft to: - reflect the closure of the MEAD team - include the comments that will be liaised to us from SG15 (in a liaison statement coming out of the Geneva meeting last week) - note the guidance being given to ITU-T rapporteurs by the ITU-T on how to handle liaisons received during WG last call - include nits and typos found by Malcolm. Thanks, Adrian ----- Original Message ----- From: To: Cc: Sent: Friday, October 16, 2009 11:00 PM Subject: [mpls] I-D Action:draft-ietf-mpls-tp-process-03.txt >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-03.txt > Pages : 21 > Date : 2009-10-16 > > 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 does 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-03.txt From Martin.Vigoureux@alcatel-lucent.com Sat Oct 17 11:19:25 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 C91863A6892; Sat, 17 Oct 2009 11:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.351 X-Spam-Level: X-Spam-Status: No, score=0.351 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35] 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 8wB7CNnZ0imT; Sat, 17 Oct 2009 11:19:25 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id E80CD3A67B0; Sat, 17 Oct 2009 11:19:24 -0700 (PDT) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail6.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n9HIJRMJ000616; Sat, 17 Oct 2009 20:19:27 +0200 Received: from [135.244.20.167] ([135.244.20.167]) by FRVELSBHS05.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Sat, 17 Oct 2009 20:19:26 +0200 Message-ID: <4ADA0A95.9070206@alcatel-lucent.com> Date: Sat, 17 Oct 2009 20:19:01 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Oct 2009 18:19:27.0283 (UTC) FILETIME=[5C999030:01CA4F56] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.84 Cc: mpls-tp@ietf.org Subject: [mpls] Slots requests for MPLS sessions - IETF76 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, 17 Oct 2009 18:19:25 -0000 all, this is a call for presentation slots for mpls sessions. We will have two meeting sessions and will split the overall duration in two parts - mpls and mpls-tp. Please send me the requests, with Loa & George in copy The IETF meeting agenda is subject to change. MPLS Session 1 (2.5 hours) Monday, Afternoon 1740-1940 ---------------------------------------------- MPLS Session 2 (2.5 hours) Wednesday, 0900-1015 ---------------------------------------------- regards, martin From loa@pi.nu Mon Oct 19 03:21: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 9360C3A6961 for ; Mon, 19 Oct 2009 03:21:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 A8THXtyWIc2S for ; Mon, 19 Oct 2009 03:21:17 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id A9E5F3A691F for ; Mon, 19 Oct 2009 03:21:17 -0700 (PDT) Received: from [192.36.158.106] (wdhcp-158-106.verkstad.net [192.36.158.106]) (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 DB0CDD404F for ; Mon, 19 Oct 2009 12:21:21 +0200 (CEST) Message-ID: <4ADC3D9D.3030002@pi.nu> Date: Mon, 19 Oct 2009 12:21:17 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] [Fwd: [mpls-tp] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft] 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, 19 Oct 2009 10:21:18 -0000 Working Group, by mistake I sent this tot the mpls-tp list twice, and not to the mpls mailing list. It is intended for mpls working group also. /Loa -------- Original Message -------- Subject: [mpls-tp] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft Date: Sun, 18 Oct 2009 19:49:03 +0200 From: Loa Andersson To: mpls-tp@ietf.org , mpls-tp@ietf.org , pwe3@ietf.org, ccamp@ietf.org Working Group, the authors of draft-sprecher-mpls-tp-oam-analysis-07.txt have asked that the draft is adopted as an mpls working group document. This mail starts a two week poll on making the draft a working group document. Send a mail to the mpls-tp@ietf.org mailing list, indicating "yes/support" or "no/do not support". Comments on the content should be sent to the same mailing list with a different subject line. The poll ends Fri Oct 30. Loa and George MPLS working group co-chairs -- 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 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp -- 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 loa@pi.nu Mon Oct 19 03:42:26 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 373B83A67A3 for ; Mon, 19 Oct 2009 03:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 URLew71K7CrF for ; Mon, 19 Oct 2009 03:42:25 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 000BA3A67E9 for ; Mon, 19 Oct 2009 03:42:24 -0700 (PDT) Received: from [192.36.158.106] (wdhcp-158-106.verkstad.net [192.36.158.106]) (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 45A8DD4056 for ; Mon, 19 Oct 2009 12:42:28 +0200 (CEST) Message-ID: <4ADC4291.7000602@pi.nu> Date: Mon, 19 Oct 2009 12:42:25 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] wg last call on ldp and rsvp-te drafts on upstream label allocation 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, 19 Oct 2009 10:42:26 -0000 Working group, this mail starts a two week working group last call on draft-ietf-mpls-ldp-upstream-04 draft-ietf-mpls-rsvp-upstream-04 The working gorup last call ends on Mon Nov 2 - 2009. Please send your comments to the mpls working group mailing list (mpls@ietf.org). Loa and George PS we are aware of that the IETF nits tool generates a couple of errors warnings and comments. There is no need to re-report those, will be taken care of when then document is updated. -- 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 Alexander.Vainshtein@ecitele.com Mon Oct 19 09:03:53 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 A2F2A3A6778; Mon, 19 Oct 2009 09:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 CS1n3WcmDO0I; Mon, 19 Oct 2009 09:03:52 -0700 (PDT) Received: from ilptiron01.ecitele.com (ilptiron01.ecitele.com [147.234.242.161]) by core3.amsl.com (Postfix) with ESMTP id 1D6113A687B; Mon, 19 Oct 2009 09:03:51 -0700 (PDT) Received: from ilptexfe.ecitele.com (HELO ILPTEXCH02.ecitele.com) ([147.234.245.181]) by ilptiron01.ecitele.com with ESMTP; 19 Oct 2009 17:55:14 +0200 Received: from ILPTMAIL02.ecitele.com ([147.234.244.213]) by ILPTEXCH02.ecitele.com ([147.234.245.181]) with mapi; Mon, 19 Oct 2009 18:03:58 +0200 From: Alexander Vainshtein To: Adrian Farrel Date: Mon, 19 Oct 2009 18:03:57 +0200 Thread-Topic: [mpls-tp] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft Thread-Index: AcpQziRY6EhAOfd8TUCZVo1cCmlYNQAAo3ZQ Message-ID: References: <4ADB550F.8080507@pi.nu> <787be2780910181838x2bd76bd4va451344bb69cbc05@mail.gmail.com> <4ADC3F12.60401@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft 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, 19 Oct 2009 16:03:53 -0000 Adrian, I fully agree with you regarding "four questions" that should be answered = when we decide whether an individual draft=20 should - or should not - be adopted as a WG draft. And I do not have any problem with answering "yes" to the first two: - the draft belongs to MPLS-TP and, as such, is within the scope of the MPL= S WG - MPLS-TP is of some interest to the MPLS WG (or at least to me). BTW, I've= added mpls@ietf.org to the CC list. My problems start with the remaining two questions: - Does the WG to work on a draft that covers the subject material? The answer is far from obvious, since the specific subject of the draft i= s analysis (sometimes inaccurate) of existing OAM tools vs. documented MPLS-TP OAM requirements, with some recommendations as to how = to develop specific OAM tools. We may, of course, continue to work on the analysis (e.g., by fixing the = errors in the document) and update some recommendations. However, this would not replace actual work on the new OAM tools or exten= sion of the existing ones. - Is this draft a good enough starting point for further work? =20 This question assumes that we understand which "further work" we have in = mind. And this is completely not clear to me, especially when looking at Loa's = explanation. At least, the usual understanding of "further work" at IETF - to deliver = an RFC - seems to be not applicable. We have examples of work items that have been adopted as WG documents and= eventually published as=20 Informational RFCs while documenting certain status rather than defining = some protocols (e.g., 5037 and 5038), but I am not sure if this analogy really holds. =20 If the objective is to preserve the design team notes, this can be done i= n many other ways. Just to remind you that the "Martini drafts" have never been adopted as WG drafts. This did = not prevent Luca from periodically updating them in parallel with working on the PWE3 WG documents... And eventually = they have been published as Historical RFCs. I will provide my analysis of specific issues with the draft later in a sep= arate email. Regards, Sasha > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Monday, October 19, 2009 5:09 PM > To: Satoru Matsushima; Loa Andersson > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] poll on=20 > makingdraft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft >=20 > Hi Satoru, >=20 > I didn't see anyone else answer, so I'll jump in. >=20 > > I'm trying to understand what the purpose of this poll. > > > > Does this poll to make decision of MPLS-TP OAM solution, or > > to make sure a current status of mpls-tp oam considerations? >=20 > Neither of these. >=20 > This poll is to decide whether the MPLS working group wants=20 > to adopt this=20 > draft as a work in progress to be developed further under the=20 > care of the=20 > MPLS working group. >=20 > The material questions are: > - is this within the scope of the MPLS working group? > - is there sufficient interest in the broader topic (MPLS-TP)? > - does the working group want to work on a draft that covers > this subject material? > - is this draft a good starting point for further work? >=20 > Thanks, > Adrian >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > = From nurit.sprecher@nsn.com Mon Oct 19 09:38:35 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 90F9A3A68AC; Mon, 19 Oct 2009 09:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 U30+zs68XQV1; Mon, 19 Oct 2009 09:38:34 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id 827773A69C9; Mon, 19 Oct 2009 09:38:17 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n9JGcIiN006668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Oct 2009 18:38:18 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n9JGcIp3013587; Mon, 19 Oct 2009 18:38:18 +0200 Received: from DEMUEXC014.nsn-intra.net ([10.150.128.25]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Oct 2009 18:38:18 +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: Mon, 19 Oct 2009 18:38:16 +0200 Message-ID: <077E41CFFD002C4CAB7DFA4386A53264016B2610@DEMUEXC014.nsn-intra.net> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls-tp] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft Thread-Index: AcpQziRY6EhAOfd8TUCZVo1cCmlYNQAAo3ZQAAFUaBA= References: <4ADB550F.8080507@pi.nu> <787be2780910181838x2bd76bd4va451344bb69cbc05@mail.gmail.com><4ADC3F12.60401@pi.nu> From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" To: "ext Alexander Vainshtein" , "Adrian Farrel" X-OriginalArrivalTime: 19 Oct 2009 16:38:18.0634 (UTC) FILETIME=[903AB6A0:01CA50DA] Cc: mpls@ietf.org, mpls-tp@ietf.org Subject: Re: [mpls] [mpls-tp] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft 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, 19 Oct 2009 16:38:35 -0000 Dear Sasha, I'll appreciate if you can refer to what you believe are errors in the document. We of course would like to fix them. That is the reason we solicited many times the group to review and comment.=20 The draft gives an overview on the existing mechanisms and tries to analyze whether they can apply to the requirements, or can be enhanced to apply to the requirements. It also summarizes the agreements we reached in the discussions in the design team and the considerations.=20 We also know that there are further requirements on the table that are under discussions and if agreed we will need to extend the document and analyze them as well. I hope you can support the adoption of the draft as a WG document/.=20 Best regards, Nurit. -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf Of ext Alexander Vainshtein Sent: Monday, October 19, 2009 6:04 PM To: Adrian Farrel Cc: mpls@ietf.org; mpls-tp@ietf.org Subject: Re: [mpls-tp] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft Adrian, I fully agree with you regarding "four questions" that should be answered when we decide whether an individual draft=20 should - or should not - be adopted as a WG draft. And I do not have any problem with answering "yes" to the first two: - the draft belongs to MPLS-TP and, as such, is within the scope of the MPLS WG - MPLS-TP is of some interest to the MPLS WG (or at least to me). BTW, I've added mpls@ietf.org to the CC list. My problems start with the remaining two questions: - Does the WG to work on a draft that covers the subject material? The answer is far from obvious, since the specific subject of the draft is analysis (sometimes inaccurate) of existing OAM tools vs. documented MPLS-TP OAM requirements, with some recommendations as to how to develop specific OAM tools. We may, of course, continue to work on the analysis (e.g., by fixing the errors in the document) and update some recommendations. However, this would not replace actual work on the new OAM tools or extension of the existing ones. - Is this draft a good enough starting point for further work? =20 This question assumes that we understand which "further work" we have in mind. And this is completely not clear to me, especially when looking at Loa's explanation. At least, the usual understanding of "further work" at IETF - to deliver an RFC - seems to be not applicable. We have examples of work items that have been adopted as WG documents and eventually published as=20 Informational RFCs while documenting certain status rather than defining some protocols (e.g., 5037 and 5038), but I am not sure if this analogy really holds. =20 If the objective is to preserve the design team notes, this can be done in many other ways. Just to remind you that the "Martini drafts" have never been adopted as WG drafts. This did not prevent Luca from periodically updating them in parallel with working on the PWE3 WG documents... And eventually they have been published as Historical RFCs. I will provide my analysis of specific issues with the draft later in a separate email. Regards, Sasha > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Adrian Farrel > Sent: Monday, October 19, 2009 5:09 PM > To: Satoru Matsushima; Loa Andersson > Cc: mpls-tp@ietf.org > Subject: Re: [mpls-tp] poll on=20 > makingdraft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft >=20 > Hi Satoru, >=20 > I didn't see anyone else answer, so I'll jump in. >=20 > > I'm trying to understand what the purpose of this poll. > > > > Does this poll to make decision of MPLS-TP OAM solution, or > > to make sure a current status of mpls-tp oam considerations? >=20 > Neither of these. >=20 > This poll is to decide whether the MPLS working group wants=20 > to adopt this=20 > draft as a work in progress to be developed further under the=20 > care of the=20 > MPLS working group. >=20 > The material questions are: > - is this within the scope of the MPLS working group? > - is there sufficient interest in the broader topic (MPLS-TP)? > - does the working group want to work on a draft that covers > this subject material? > - is this draft a good starting point for further work? >=20 > Thanks, > Adrian >=20 > _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp >=20 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From davari@broadcom.com Mon Oct 19 15:40:02 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 A32BC28C0E5 for ; Mon, 19 Oct 2009 15:40:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 KAzuTL+kc32V for ; Mon, 19 Oct 2009 15:40:01 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id CAB103A67D2 for ; Mon, 19 Oct 2009 15:40:01 -0700 (PDT) Received: from [10.16.192.232] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 19 Oct 2009 15:39:58 -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, 19 Oct 2009 15:39:58 -0700 From: "Shahram Davari" To: "mpls@ietf.org" Date: Mon, 19 Oct 2009 15:39:56 -0700 Thread-Topic: [mpls] [Fwd: [mpls-tp] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft] Thread-Index: AcpQpfLsaOqjx/DQRo+s6tRkOlS+0QAZn7uA Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD68157683515@SJEXCHCCR02.corp.ad.broadcom.com> References: <4ADC3D9D.3030002@pi.nu> In-Reply-To: <4ADC3D9D.3030002@pi.nu> 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: 66C235345KG24739705-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [mpls] [Fwd: [mpls-tp] poll on making draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft] 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, 19 Oct 2009 22:40:02 -0000 Support.=20 -Shahram -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Monday, October 19, 2009 3:21 AM To: mpls@ietf.org Subject: [mpls] [Fwd: [mpls-tp] poll on making draft-sprecher-mpls-tp-oam-a= nalysis-07.txt a working group draft] Working Group, by mistake I sent this tot the mpls-tp list twice, and not to the mpls mailing list. It is intended for mpls working group also. /Loa -------- Original Message -------- Subject: [mpls-tp] poll on making=20 draft-sprecher-mpls-tp-oam-analysis-07.txt a working group draft Date: Sun, 18 Oct 2009 19:49:03 +0200 From: Loa Andersson To: mpls-tp@ietf.org , mpls-tp@ietf.org=20 , pwe3@ietf.org, ccamp@ietf.org Working Group, the authors of draft-sprecher-mpls-tp-oam-analysis-07.txt have asked that the draft is adopted as an mpls working group document. This mail starts a two week poll on making the draft a working group document. Send a mail to the mpls-tp@ietf.org mailing list, indicating "yes/support" or "no/do not support". Comments on the content should be sent to the same mailing list with a different subject line. The poll ends Fri Oct 30. Loa and George MPLS working group co-chairs --=20 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 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp --=20 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 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From loa@pi.nu Wed Oct 21 02:13:20 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 C002B3A69E1 for ; Wed, 21 Oct 2009 02:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, 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 u1OYJR6vNnJ8 for ; Wed, 21 Oct 2009 02:13:20 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id F1A913A69CC for ; Wed, 21 Oct 2009 02:13:19 -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 6E2EDD404F; Wed, 21 Oct 2009 11:13:26 +0200 (CEST) Message-ID: <4ADED0B3.2070106@pi.nu> Date: Wed, 21 Oct 2009 11:13:23 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] poll on making draft-lu-ldp-igp-sync-bcast-01an mpls wg document 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, 21 Oct 2009 09:13:20 -0000 Working Group, the authors of draft-lu-ldp-igp-sync-bcast-01.txt has requested that the document is accepted as a working group document. This mail starts a two week poll on making the draft a working group document. Send a mail to the mpls@ietf.org mailing list, indicating "yes/support" or "no/do not support". Comments on the content should be sent to the same mailing list with a different subject line. The poll ends Fri Nov 6. /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 gregory.cauchie@orange-ftgroup.com Wed Oct 21 09:05: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 98BC73A69AA for ; Wed, 21 Oct 2009 09:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 IsArJQ-pe5ha for ; Wed, 21 Oct 2009 09:05:32 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 4FFBD3A69A8 for ; Wed, 21 Oct 2009 09:05:32 -0700 (PDT) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Oct 2009 18:05:40 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 21 Oct 2009 18:05:04 +0200 Message-ID: <9ECCF01B52E7AB408A7EB85352642141A6D499@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4ADED0B3.2070106@pi.nu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] poll on making draft-lu-ldp-igp-sync-bcast-01an mpls wgdocument Thread-Index: AcpSLsjkoQdDs1xQQkKRMplIPUxrEQAOWF4A References: <4ADED0B3.2070106@pi.nu> From: To: X-OriginalArrivalTime: 21 Oct 2009 16:05:40.0455 (UTC) FILETIME=[55E3CF70:01CA5268] Subject: Re: [mpls] poll on making draft-lu-ldp-igp-sync-bcast-01an mpls wgdocument 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, 21 Oct 2009 16:05:33 -0000 "yes/support" -- Greg=20 > -----Message d'origine----- > De : mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] De=20 > la part de Loa Andersson > Envoy=E9 : mercredi 21 octobre 2009 11:13 > =C0 : mpls@ietf.org > Objet : [mpls] poll on making=20 > draft-lu-ldp-igp-sync-bcast-01an mpls wgdocument >=20 > Working Group, >=20 > the authors of draft-lu-ldp-igp-sync-bcast-01.txt has=20 > requested that the document is accepted as a working group document. >=20 > This mail starts a two week poll on making the draft a=20 > working group document. Send a mail to the mpls@ietf.org=20 > mailing list, indicating "yes/support" or "no/do not support". >=20 > Comments on the content should be sent to the same mailing=20 > list with a different subject line. >=20 > The poll ends Fri Nov 6. >=20 > /Loa >=20 > --=20 >=20 >=20 > Loa Andersson email:=20 > loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92=20 > 13 _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From root@core3.amsl.com Thu Oct 22 10:30:03 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 7B97528B797; Thu, 22 Oct 2009 10:30: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: <20091022173003.7B97528B797@core3.amsl.com> Date: Thu, 22 Oct 2009 10:30:01 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-nm-req-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, 22 Oct 2009 17:30: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 : MPLS TP Network Management Requirements Author(s) : S. Mansfield, K. Lam Filename : draft-ietf-mpls-tp-nm-req-06.txt Pages : 25 Date : 2009-10-22 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. Gray, et al Expires April, 2010 [page 1] Internet-Draft MPLS-TP NM Requirements October, 2009 A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-nm-req-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-nm-req-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-22101901.I-D@ietf.org> --NextPart-- From davari@broadcom.com Thu Oct 22 10:37:06 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 9C8633A6990 for ; Thu, 22 Oct 2009 10:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 L+BkNDhm2Ijz for ; Thu, 22 Oct 2009 10:37:05 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id C137F3A6994 for ; Thu, 22 Oct 2009 10:37:05 -0700 (PDT) Received: from [10.16.192.232] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 22 Oct 2009 10:37:04 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Thu, 22 Oct 2009 10:37:04 -0700 From: "Shahram Davari" To: "mpls@ietf.org" Date: Thu, 22 Oct 2009 10:37:03 -0700 Thread-Topic: Question about 0x8848 Ethertype Thread-Index: AcpTPkQqPOLzLzS1RKq/F/isNc+5ZQ== Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6815768387B@SJEXCHCCR02.corp.ad.broadcom.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: 66FE47B50UC23549803-01-01 Content-Type: multipart/alternative; boundary=_000_2C2F1EBA8050E74EA81502D5740B4BD6815768387BSJEXCHCCR02co_ Subject: [mpls] Question about 0x8848 Ethertype 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, 22 Oct 2009 17:37:06 -0000 --_000_2C2F1EBA8050E74EA81502D5740B4BD6815768387BSJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi, RFC 5332 says: "Ethertype 0x8848, formerly known as the "MPLS multicast codepoint", is to = be used only when an MPLS packet whose top label is upstream- assigned is c= arried in a multicast Ethernet frame." It also says: "It is expected that the LSR will follow the procedures of [RFC5331], pushi= ng on two labels, with the topmost label being a "context label" that is th= e same for all MPLS packets being transmitted by the LSR onto the Ethernet,= but with the second label being different for different LSPs" And RFC 5331 defines context label as: "A "context label" is one that identifies a label table in which the label = immediately below the context label should be looked up. A context label ca= rried as an outermost label over a particular multi-access subnet/tunnel MU= ST be unique within the scope of that subnet/tunnel." Considering the above statements we can conclude that: "Multicast MPLS packets with upstream assigned labels encapsulated in Multi= cast Ethernet frames in a Multi-access media (LAN) require to use 0x8848 as= Ethertype and require to use a context label that is unique over that medi= a to identify the label space for the Multicast MPLS packet" The question is since a context label is unique in a LAN and can be immedia= tely identified as an upstream label, then why do we need 0x8847 Ethertype?= Looks like we could just use the context label. Am I missing something? Regards, Shahram --_000_2C2F1EBA8050E74EA81502D5740B4BD6815768387BSJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable
Hi,
 
RFC 5332= =20 says:
 
"Ethertype 0x8848, formerly known as the "MPLS multicast codepoint= ", is=20 to be used only when an MPLS packet whose top label is upstream- assigned i= s=20 carried in a multicast Ethernet frame."
 
It=20 also says:
 
"It is expected that the LSR will follow the procedures of [RFC533= 1],=20 pushing on two labels, with the topmost label being a "context label" that = is=20 the same for all MPLS packets being transmitted by the LSR onto the Etherne= t,=20 but with the second label being different for different=20 LSPs"
 
And RFC 5331 defines context label as:
 
"A "context label" is one that identifies a label= table in=20 which the label immediately below the context label should be looked up. A= =20 context label carried as an outermost label over a particular multi-access= =20 subnet/tunnel MUST be unique within the scope of that=20 subnet/tunnel."
 
Considering the above statements we can conclude= =20 that:
 
"Multicast MPLS packets with upstream assigned la= bels=20 encapsulated in Multicast Ethernet frames in a Multi-access media (LAN= )=20 require to use 0x8848 as Ethertype and require to use a context label that = is=20 unique over that media to identify the label space for the Multicast MPLS=20 packet"
 
The question is since a context label is unique i= n a LAN=20 and can be immediately identified as an upstream label, then why do we need= =20 0x8847 Ethertype? Looks like we could just use the context label.=20
 
Am I missing something?=20
 
Regards,
Shahram
 
 
--_000_2C2F1EBA8050E74EA81502D5740B4BD6815768387BSJEXCHCCR02co_-- From nitinb@juniper.net Thu Oct 22 11:12: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 CD3813A68E4 for ; Thu, 22 Oct 2009 11:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 M84N5+viigCR for ; Thu, 22 Oct 2009 11:12:29 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by core3.amsl.com (Postfix) with ESMTP id 439633A677D for ; Thu, 22 Oct 2009 11:12:29 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKSuCglijA9PawU2Y7KXttvsJb0SXjcGwA@postini.com; Thu, 22 Oct 2009 11:12:39 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Thu, 22 Oct 2009 11:12:06 -0700 From: Nitin Bahadur To: Shahram Davari , "mpls@ietf.org" Date: Thu, 22 Oct 2009 11:10:17 -0700 Thread-Topic: [mpls] Question about 0x8848 Ethertype Thread-Index: AcpTQuirT3A0Be73qEitNRFoGv6VKA== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] Question about 0x8848 Ethertype 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, 22 Oct 2009 18:12:31 -0000 See NB> below... On 10/22/09 10:37 AM, "Shahram Davari" wrote: Hi, RFC 5332 says: "Ethertype 0x8848, formerly known as the "MPLS multicast codepoint", is to = be used only when an MPLS packet whose top label is upstream- assigned is c= arried in a multicast Ethernet frame." It also says: "It is expected that the LSR will follow the procedures of [RFC5331], pushi= ng on two labels, with the topmost label being a "context label" that is th= e same for all MPLS packets being transmitted by the LSR onto the Ethernet,= but with the second label being different for different LSPs" And RFC 5331 defines context label as: "A "context label" is one that identifies a label table in which the label = immediately below the context label should be looked up. A context label ca= rried as an outermost label over a particular multi-access subnet/tunnel MU= ST be unique within the scope of that subnet/tunnel." Considering the above statements we can conclude that: "Multicast MPLS packets with upstream assigned labels encapsulated in Multi= cast Ethernet frames in a Multi-access media (LAN) require to use 0x8848 as= Ethertype and require to use a context label that is unique over that medi= a to identify the label space for the Multicast MPLS packet" The question is since a context label is unique in a LAN and can be immedia= tely identified as an upstream label, then why do we need 0x8848 Ethertype?= Looks like we could just use the context label. Am I missing something? NB> The question is "how to identify that this is an upstream label". Consi= der label 100. This label could have been allocated by upstream P1 router a= s an upstream label and distributed to downstream router PE. The same label= could have been allocated by PE router and distributed to router P1. So no= w, when PE receives a packet over the LAN (from P1) with label 100, it does not whethe= r to look it up as an upstream label or as a downstream label.. Ethertype 0x8848 allows PE to perform lookups in context of P1 and not in c= ontext of labels distributed by PE. Thanks Nitin From davari@broadcom.com Thu Oct 22 11:17:54 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 831A528C176 for ; Thu, 22 Oct 2009 11:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 2wOxLWn7j9fO for ; Thu, 22 Oct 2009 11:17:53 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id A1BDD28C0FB for ; Thu, 22 Oct 2009 11:17:53 -0700 (PDT) Received: from [10.16.192.232] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 22 Oct 2009 11:17:57 -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; Thu, 22 Oct 2009 11:17:57 -0700 From: "Shahram Davari" To: "Nitin Bahadur" , "mpls@ietf.org" Date: Thu, 22 Oct 2009 11:17:55 -0700 Thread-Topic: [mpls] Question about 0x8848 Ethertype Thread-Index: AcpTQuirT3A0Be73qEitNRFoGv6VKAAAJLBg Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD68157683884@SJEXCHCCR02.corp.ad.broadcom.com> References: In-Reply-To: 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: 66FE7E5F5KG27954123-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [mpls] Question about 0x8848 Ethertype 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, 22 Oct 2009 18:17:54 -0000 Hi Nitin, Thanks for your answer. But RFC 5332 requires the use of unique "context la= bel" at the top of the label stack which can't be used as downstream-assign= ed label on the multi-access media. So the mere presence of a "context labe= l" should be enough and we don't need a dedicated Ethertype to tell us that= the context label is upstream assigned. =20 Do you agree? Regards, Shahram -----Original Message----- From: Nitin Bahadur [mailto:nitinb@juniper.net]=20 Sent: Thursday, October 22, 2009 11:10 AM To: Shahram Davari; mpls@ietf.org Subject: Re: [mpls] Question about 0x8848 Ethertype See NB> below... On 10/22/09 10:37 AM, "Shahram Davari" wrote: Hi, RFC 5332 says: "Ethertype 0x8848, formerly known as the "MPLS multicast codepoint", is to = be used only when an MPLS packet whose top label is upstream- assigned is c= arried in a multicast Ethernet frame." It also says: "It is expected that the LSR will follow the procedures of [RFC5331], pushi= ng on two labels, with the topmost label being a "context label" that is th= e same for all MPLS packets being transmitted by the LSR onto the Ethernet,= but with the second label being different for different LSPs" And RFC 5331 defines context label as: "A "context label" is one that identifies a label table in which the label = immediately below the context label should be looked up. A context label ca= rried as an outermost label over a particular multi-access subnet/tunnel MU= ST be unique within the scope of that subnet/tunnel." Considering the above statements we can conclude that: "Multicast MPLS packets with upstream assigned labels encapsulated in Multi= cast Ethernet frames in a Multi-access media (LAN) require to use 0x8848 as= Ethertype and require to use a context label that is unique over that medi= a to identify the label space for the Multicast MPLS packet" The question is since a context label is unique in a LAN and can be immedia= tely identified as an upstream label, then why do we need 0x8848 Ethertype?= Looks like we could just use the context label. Am I missing something? NB> The question is "how to identify that this is an upstream label". Consi= der label 100. This label could have been allocated by upstream P1 router a= s an upstream label and distributed to downstream router PE. The same label= could have been allocated by PE router and distributed to router P1. So no= w, when PE receives a packet over the LAN (from P1) with label 100, it does not whethe= r to look it up as an upstream label or as a downstream label.. Ethertype 0x8848 allows PE to perform lookups in context of P1 and not in c= ontext of labels distributed by PE. Thanks Nitin From nitinb@juniper.net Thu Oct 22 11:31: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 7CB6D3A6853 for ; Thu, 22 Oct 2009 11:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 QKZVDd-YcS0k for ; Thu, 22 Oct 2009 11:31:26 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id 635063A677D for ; Thu, 22 Oct 2009 11:31:26 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKSuClB7khnJNcrB/BcITK7V6Fr8KLJZHn@postini.com; Thu, 22 Oct 2009 11:31:36 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Thu, 22 Oct 2009 11:29:42 -0700 From: Nitin Bahadur To: Shahram Davari , "mpls@ietf.org" Date: Thu, 22 Oct 2009 11:27:54 -0700 Thread-Topic: [mpls] Question about 0x8848 Ethertype Thread-Index: AcpTQuirT3A0Be73qEitNRFoGv6VKAAAJLBgAAB40aI= Message-ID: In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD68157683884@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] Question about 0x8848 Ethertype 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, 22 Oct 2009 18:31:27 -0000 I'm not 100% sure if your interpretation is correct. The RFC I think tries to say that the context-label must be unique. In othe= r words both P1 and P2 cannot use the same label to denote their context . In other words, upstream distributed labels must be = unique when using ether-type 0x8848. I don't think the intention of the RFC was that both upstream and downstrea= m allocated labels must be unique. Nitin On 10/22/09 11:17 AM, "Shahram Davari" wrote: Hi Nitin, Thanks for your answer. But RFC 5332 requires the use of unique "context la= bel" at the top of the label stack which can't be used as downstream-assign= ed label on the multi-access media. So the mere presence of a "context labe= l" should be enough and we don't need a dedicated Ethertype to tell us that= the context label is upstream assigned. Do you agree? Regards, Shahram -----Original Message----- From: Nitin Bahadur [mailto:nitinb@juniper.net] Sent: Thursday, October 22, 2009 11:10 AM To: Shahram Davari; mpls@ietf.org Subject: Re: [mpls] Question about 0x8848 Ethertype See NB> below... On 10/22/09 10:37 AM, "Shahram Davari" wrote: Hi, RFC 5332 says: "Ethertype 0x8848, formerly known as the "MPLS multicast codepoint", is to = be used only when an MPLS packet whose top label is upstream- assigned is c= arried in a multicast Ethernet frame." It also says: "It is expected that the LSR will follow the procedures of [RFC5331], pushi= ng on two labels, with the topmost label being a "context label" that is th= e same for all MPLS packets being transmitted by the LSR onto the Ethernet,= but with the second label being different for different LSPs" And RFC 5331 defines context label as: "A "context label" is one that identifies a label table in which the label = immediately below the context label should be looked up. A context label ca= rried as an outermost label over a particular multi-access subnet/tunnel MU= ST be unique within the scope of that subnet/tunnel." Considering the above statements we can conclude that: "Multicast MPLS packets with upstream assigned labels encapsulated in Multi= cast Ethernet frames in a Multi-access media (LAN) require to use 0x8848 as= Ethertype and require to use a context label that is unique over that medi= a to identify the label space for the Multicast MPLS packet" The question is since a context label is unique in a LAN and can be immedia= tely identified as an upstream label, then why do we need 0x8848 Ethertype?= Looks like we could just use the context label. Am I missing something? NB> The question is "how to identify that this is an upstream label". Consi= der label 100. This label could have been allocated by upstream P1 router a= s an upstream label and distributed to downstream router PE. The same label= could have been allocated by PE router and distributed to router P1. So no= w, when PE receives a packet over the LAN (from P1) with label 100, it does not whethe= r to look it up as an upstream label or as a downstream label.. Ethertype 0x8848 allows PE to perform lookups in context of P1 and not in c= ontext of labels distributed by PE. Thanks Nitin From davari@broadcom.com Thu Oct 22 11:37: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 76A0428C178 for ; Thu, 22 Oct 2009 11:37:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 ZooT9MVKABFF for ; Thu, 22 Oct 2009 11:37:32 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id 9544428C0EF for ; Thu, 22 Oct 2009 11:37:32 -0700 (PDT) Received: from [10.16.192.232] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 22 Oct 2009 11:37:34 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Thu, 22 Oct 2009 11:37:34 -0700 From: "Shahram Davari" To: "Nitin Bahadur" , "mpls@ietf.org" Date: Thu, 22 Oct 2009 11:37:33 -0700 Thread-Topic: [mpls] Question about 0x8848 Ethertype Thread-Index: AcpTQuirT3A0Be73qEitNRFoGv6VKAAAJLBgAAB40aIAADYOwA== Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD68157683889@SJEXCHCCR02.corp.ad.broadcom.com> References: <2C2F1EBA8050E74EA81502D5740B4BD68157683884@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: 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: 66FE79E75S457347127-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [mpls] Question about 0x8848 Ethertype 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, 22 Oct 2009 18:37:33 -0000 Hi Nitin, If we assume your interpretation of the RFC that the context label is uniqu= e only if it is used as upstream label, meaning that the same context label= can be used as downsteam-assigned label on that LAN, then the question is = what about unicast packets in a LAN? How will a node receiving a unicast pa= cket can identify whether the top label is upstream assigned or downstream = assigned? Thanks, Shahram=20 -----Original Message----- From: Nitin Bahadur [mailto:nitinb@juniper.net]=20 Sent: Thursday, October 22, 2009 11:28 AM To: Shahram Davari; mpls@ietf.org Subject: Re: [mpls] Question about 0x8848 Ethertype I'm not 100% sure if your interpretation is correct. The RFC I think tries to say that the context-label must be unique. In othe= r words both P1 and P2 cannot use the same label to denote their context . In other words, upstream distributed labels must be = unique when using ether-type 0x8848. I don't think the intention of the RFC was that both upstream and downstrea= m allocated labels must be unique. Nitin On 10/22/09 11:17 AM, "Shahram Davari" wrote: Hi Nitin, Thanks for your answer. But RFC 5332 requires the use of unique "context la= bel" at the top of the label stack which can't be used as downstream-assign= ed label on the multi-access media. So the mere presence of a "context labe= l" should be enough and we don't need a dedicated Ethertype to tell us that= the context label is upstream assigned. Do you agree? Regards, Shahram -----Original Message----- From: Nitin Bahadur [mailto:nitinb@juniper.net] Sent: Thursday, October 22, 2009 11:10 AM To: Shahram Davari; mpls@ietf.org Subject: Re: [mpls] Question about 0x8848 Ethertype See NB> below... On 10/22/09 10:37 AM, "Shahram Davari" wrote: Hi, RFC 5332 says: "Ethertype 0x8848, formerly known as the "MPLS multicast codepoint", is to = be used only when an MPLS packet whose top label is upstream- assigned is c= arried in a multicast Ethernet frame." It also says: "It is expected that the LSR will follow the procedures of [RFC5331], pushi= ng on two labels, with the topmost label being a "context label" that is th= e same for all MPLS packets being transmitted by the LSR onto the Ethernet,= but with the second label being different for different LSPs" And RFC 5331 defines context label as: "A "context label" is one that identifies a label table in which the label = immediately below the context label should be looked up. A context label ca= rried as an outermost label over a particular multi-access subnet/tunnel MU= ST be unique within the scope of that subnet/tunnel." Considering the above statements we can conclude that: "Multicast MPLS packets with upstream assigned labels encapsulated in Multi= cast Ethernet frames in a Multi-access media (LAN) require to use 0x8848 as= Ethertype and require to use a context label that is unique over that medi= a to identify the label space for the Multicast MPLS packet" The question is since a context label is unique in a LAN and can be immedia= tely identified as an upstream label, then why do we need 0x8848 Ethertype?= Looks like we could just use the context label. Am I missing something? NB> The question is "how to identify that this is an upstream label". Consi= der label 100. This label could have been allocated by upstream P1 router a= s an upstream label and distributed to downstream router PE. The same label= could have been allocated by PE router and distributed to router P1. So no= w, when PE receives a packet over the LAN (from P1) with label 100, it does not whethe= r to look it up as an upstream label or as a downstream label.. Ethertype 0x8848 allows PE to perform lookups in context of P1 and not in c= ontext of labels distributed by PE. Thanks Nitin From nitinb@juniper.net Thu Oct 22 12:09:14 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 25F5728C176 for ; Thu, 22 Oct 2009 12:09:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 2Lki60Glj3RW for ; Thu, 22 Oct 2009 12:09:13 -0700 (PDT) Received: from exprod7og122.obsmtp.com (exprod7og122.obsmtp.com [64.18.2.22]) by core3.amsl.com (Postfix) with ESMTP id 0256A28C136 for ; Thu, 22 Oct 2009 12:09:12 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob122.postini.com ([64.18.6.12]) with SMTP ID DSNKSuCt4nnN3qw6nlTovWzNR2pN1NZF21VU@postini.com; Thu, 22 Oct 2009 12:09:23 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 22 Oct 2009 12:04:10 -0700 From: Nitin Bahadur To: 'Shahram Davari' , "mpls@ietf.org" Date: Thu, 22 Oct 2009 12:04:09 -0700 Thread-Topic: [mpls] Question about 0x8848 Ethertype Thread-Index: AcpTQuirT3A0Be73qEitNRFoGv6VKAAAJLBgAAB40aIAADYOwAABB0XQ Message-ID: <05542EC42316164383B5180707A489EE1CFEBA4181@EMBX02-HQ.jnpr.net> References: <2C2F1EBA8050E74EA81502D5740B4BD68157683884@SJEXCHCCR02.corp.ad.broadcom.com> <2C2F1EBA8050E74EA81502D5740B4BD68157683889@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <2C2F1EBA8050E74EA81502D5740B4BD68157683889@SJEXCHCCR02.corp.ad.broadcom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] Question about 0x8848 Ethertype 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, 22 Oct 2009 19:09:14 -0000 > If we assume your interpretation of the RFC that the context label is > unique only if it is used as upstream label, meaning that the same contex= t > label can be used as downsteam-assigned label on that LAN, then the > question is what about unicast packets in a LAN?=20 > How will a node receiving > a unicast packet can identify whether the top label is upstream assigned > or downstream assigned? Using ether-type...0x8848 will indicate upstream assigned. > Thanks, > Shahram >=20 > -----Original Message----- > From: Nitin Bahadur [mailto:nitinb@juniper.net] > Sent: Thursday, October 22, 2009 11:28 AM > To: Shahram Davari; mpls@ietf.org > Subject: Re: [mpls] Question about 0x8848 Ethertype >=20 >=20 > I'm not 100% sure if your interpretation is correct. >=20 > The RFC I think tries to say that the context-label must be unique. In > other words both P1 and P2 cannot use the same label to > denote their context . In other words, upstream distributed labels must b= e > unique when using ether-type 0x8848. >=20 > I don't think the intention of the RFC was that both upstream and > downstream allocated labels must be unique. >=20 > Nitin >=20 > On 10/22/09 11:17 AM, "Shahram Davari" wrote: >=20 > Hi Nitin, >=20 > Thanks for your answer. But RFC 5332 requires the use of unique "context > label" at the top of the label stack which can't be used as downstream- > assigned label on the multi-access media. So the mere presence of a > "context label" should be enough and we don't need a dedicated Ethertype > to tell us that the context label is upstream assigned. >=20 > Do you agree? >=20 > Regards, > Shahram >=20 > -----Original Message----- > From: Nitin Bahadur [mailto:nitinb@juniper.net] > Sent: Thursday, October 22, 2009 11:10 AM > To: Shahram Davari; mpls@ietf.org > Subject: Re: [mpls] Question about 0x8848 Ethertype >=20 >=20 > See NB> below... >=20 > On 10/22/09 10:37 AM, "Shahram Davari" wrote: >=20 > Hi, >=20 > RFC 5332 says: >=20 > "Ethertype 0x8848, formerly known as the "MPLS multicast codepoint", is t= o > be used only when an MPLS packet whose top label is upstream- assigned is > carried in a multicast Ethernet frame." >=20 > It also says: >=20 > "It is expected that the LSR will follow the procedures of [RFC5331], > pushing on two labels, with the topmost label being a "context label" tha= t > is the same for all MPLS packets being transmitted by the LSR onto the > Ethernet, but with the second label being different for different LSPs" >=20 > And RFC 5331 defines context label as: >=20 > "A "context label" is one that identifies a label table in which the labe= l > immediately below the context label should be looked up. A context label > carried as an outermost label over a particular multi-access subnet/tunne= l > MUST be unique within the scope of that subnet/tunnel." >=20 > Considering the above statements we can conclude that: >=20 > "Multicast MPLS packets with upstream assigned labels encapsulated in > Multicast Ethernet frames in a Multi-access media (LAN) require to use > 0x8848 as Ethertype and require to use a context label that is unique ove= r > that media to identify the label space for the Multicast MPLS packet" >=20 > The question is since a context label is unique in a LAN and can be > immediately identified as an upstream label, then why do we need 0x8848 > Ethertype? Looks like we could just use the context label. >=20 > Am I missing something? >=20 > NB> The question is "how to identify that this is an upstream label". > Consider label 100. This label could have been allocated by upstream P1 > router as an upstream label and distributed to downstream router PE. The > same label could have been allocated by PE router and distributed to > router P1. So now, when PE > receives a packet over the LAN (from P1) with label 100, it does not > whether to look it up as an upstream label or as a downstream label.. >=20 > Ethertype 0x8848 allows PE to perform lookups in context of P1 and not in > context of labels distributed by PE. >=20 > Thanks > Nitin >=20 >=20 >=20 >=20 From davari@broadcom.com Thu Oct 22 12:12: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 E57043A6994 for ; Thu, 22 Oct 2009 12:12:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 CV2XboeNWcMt for ; Thu, 22 Oct 2009 12:12:59 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id 082063A659B for ; Thu, 22 Oct 2009 12:12:58 -0700 (PDT) Received: from [10.16.192.232] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 22 Oct 2009 12:13:01 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Thu, 22 Oct 2009 12:13:01 -0700 From: "Shahram Davari" To: "Nitin Bahadur" , "mpls@ietf.org" Date: Thu, 22 Oct 2009 12:12:59 -0700 Thread-Topic: [mpls] Question about 0x8848 Ethertype Thread-Index: AcpTQuirT3A0Be73qEitNRFoGv6VKAAAJLBgAAB40aIAADYOwAABB0XQAABFJ/A= Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6815768389A@SJEXCHCCR02.corp.ad.broadcom.com> References: <2C2F1EBA8050E74EA81502D5740B4BD68157683884@SJEXCHCCR02.corp.ad.broadcom.com> <2C2F1EBA8050E74EA81502D5740B4BD68157683889@SJEXCHCCR02.corp.ad.broadcom.com> <05542EC42316164383B5180707A489EE1CFEBA4181@EMBX02-HQ.jnpr.net> In-Reply-To: <05542EC42316164383B5180707A489EE1CFEBA4181@EMBX02-HQ.jnpr.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: 66FE71370UC23644527-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [mpls] Question about 0x8848 Ethertype 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, 22 Oct 2009 19:13:00 -0000 Nitin, But RFC5332 explicitly says "Ethertype 0x8847 is used whenever a unicast et= hernet frame carries an MPLS packet".=20 So we can't use 0x884 for unicast frames. Can we? If so then RFC 5332 has a= problem. Regards, Shahram -----Original Message----- From: Nitin Bahadur [mailto:nitinb@juniper.net]=20 Sent: Thursday, October 22, 2009 12:04 PM To: Shahram Davari; mpls@ietf.org Subject: RE: [mpls] Question about 0x8848 Ethertype > If we assume your interpretation of the RFC that the context label is > unique only if it is used as upstream label, meaning that the same contex= t > label can be used as downsteam-assigned label on that LAN, then the > question is what about unicast packets in a LAN?=20 > How will a node receiving > a unicast packet can identify whether the top label is upstream assigned > or downstream assigned? Using ether-type...0x8848 will indicate upstream assigned. > Thanks, > Shahram >=20 > -----Original Message----- > From: Nitin Bahadur [mailto:nitinb@juniper.net] > Sent: Thursday, October 22, 2009 11:28 AM > To: Shahram Davari; mpls@ietf.org > Subject: Re: [mpls] Question about 0x8848 Ethertype >=20 >=20 > I'm not 100% sure if your interpretation is correct. >=20 > The RFC I think tries to say that the context-label must be unique. In > other words both P1 and P2 cannot use the same label to > denote their context . In other words, upstream distributed labels must b= e > unique when using ether-type 0x8848. >=20 > I don't think the intention of the RFC was that both upstream and > downstream allocated labels must be unique. >=20 > Nitin >=20 > On 10/22/09 11:17 AM, "Shahram Davari" wrote: >=20 > Hi Nitin, >=20 > Thanks for your answer. But RFC 5332 requires the use of unique "context > label" at the top of the label stack which can't be used as downstream- > assigned label on the multi-access media. So the mere presence of a > "context label" should be enough and we don't need a dedicated Ethertype > to tell us that the context label is upstream assigned. >=20 > Do you agree? >=20 > Regards, > Shahram >=20 > -----Original Message----- > From: Nitin Bahadur [mailto:nitinb@juniper.net] > Sent: Thursday, October 22, 2009 11:10 AM > To: Shahram Davari; mpls@ietf.org > Subject: Re: [mpls] Question about 0x8848 Ethertype >=20 >=20 > See NB> below... >=20 > On 10/22/09 10:37 AM, "Shahram Davari" wrote: >=20 > Hi, >=20 > RFC 5332 says: >=20 > "Ethertype 0x8848, formerly known as the "MPLS multicast codepoint", is t= o > be used only when an MPLS packet whose top label is upstream- assigned is > carried in a multicast Ethernet frame." >=20 > It also says: >=20 > "It is expected that the LSR will follow the procedures of [RFC5331], > pushing on two labels, with the topmost label being a "context label" tha= t > is the same for all MPLS packets being transmitted by the LSR onto the > Ethernet, but with the second label being different for different LSPs" >=20 > And RFC 5331 defines context label as: >=20 > "A "context label" is one that identifies a label table in which the labe= l > immediately below the context label should be looked up. A context label > carried as an outermost label over a particular multi-access subnet/tunne= l > MUST be unique within the scope of that subnet/tunnel." >=20 > Considering the above statements we can conclude that: >=20 > "Multicast MPLS packets with upstream assigned labels encapsulated in > Multicast Ethernet frames in a Multi-access media (LAN) require to use > 0x8848 as Ethertype and require to use a context label that is unique ove= r > that media to identify the label space for the Multicast MPLS packet" >=20 > The question is since a context label is unique in a LAN and can be > immediately identified as an upstream label, then why do we need 0x8848 > Ethertype? Looks like we could just use the context label. >=20 > Am I missing something? >=20 > NB> The question is "how to identify that this is an upstream label". > Consider label 100. This label could have been allocated by upstream P1 > router as an upstream label and distributed to downstream router PE. The > same label could have been allocated by PE router and distributed to > router P1. So now, when PE > receives a packet over the LAN (from P1) with label 100, it does not > whether to look it up as an upstream label or as a downstream label.. >=20 > Ethertype 0x8848 allows PE to perform lookups in context of P1 and not in > context of labels distributed by PE. >=20 > Thanks > Nitin >=20 >=20 >=20 >=20 From erblichs@earthlink.net Thu Oct 22 12:16:26 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 2BC553A69D6 for ; Thu, 22 Oct 2009 12:16:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 5w5Ht4TTYU+w for ; Thu, 22 Oct 2009 12:16:25 -0700 (PDT) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by core3.amsl.com (Postfix) with ESMTP id 123B53A659B for ; Thu, 22 Oct 2009 12:16:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=earthlink.net; b=Zr9jKF1NirXRPvbCRYAH+Ds14wMKtXO9eUNeYZntoML5NDa27t59mPQcvptTb7aY; h=Received:Cc:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [76.103.57.3] (helo=[192.168.1.102]) by elasmtp-kukur.atl.sa.earthlink.net with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.67) (envelope-from ) id 1N139G-0006C0-G8; Thu, 22 Oct 2009 15:16:34 -0400 Message-Id: From: Mitchell Erblich To: Nitin Bahadur In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 22 Oct 2009 12:16:32 -0700 References: X-Mailer: Apple Mail (2.936) X-ELNK-Trace: 074f60c55517ea841aa676d7e74259b7b3291a7d08dfec79d30e19a95401e4a16f416f2fe63957b0350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 76.103.57.3 Cc: "mpls@ietf.org" Subject: Re: [mpls] Question about 0x8848 Ethertype 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, 22 Oct 2009 19:16:26 -0000 Nitin Bahadur, Are you you asking for uniqueness wrt only upstream or only downstream or both? I think it is the latter, last one. Mitchell Erblich ===================== On Oct 22, 2009, at 11:27 AM, Nitin Bahadur wrote: > > I'm not 100% sure if your interpretation is correct. > > The RFC I think tries to say that the context-label must be unique. > In other words both P1 and P2 cannot use the same label to > denote their context . In other words, upstream distributed labels > must be unique when using ether-type 0x8848. > > I don't think the intention of the RFC was that both upstream and > downstream allocated labels must be unique. > > Nitin > > On 10/22/09 11:17 AM, "Shahram Davari" wrote: > > Hi Nitin, > > Thanks for your answer. But RFC 5332 requires the use of unique > "context label" at the top of the label stack which can't be used as > downstream-assigned label on the multi-access media. So the mere > presence of a "context label" should be enough and we don't need a > dedicated Ethertype to tell us that the context label is upstream > assigned. > > Do you agree? > > Regards, > Shahram > > -----Original Message----- > From: Nitin Bahadur [mailto:nitinb@juniper.net] > Sent: Thursday, October 22, 2009 11:10 AM > To: Shahram Davari; mpls@ietf.org > Subject: Re: [mpls] Question about 0x8848 Ethertype > > > See NB> below... > > On 10/22/09 10:37 AM, "Shahram Davari" wrote: > > Hi, > > RFC 5332 says: > > "Ethertype 0x8848, formerly known as the "MPLS multicast codepoint", > is to be used only when an MPLS packet whose top label is upstream- > assigned is carried in a multicast Ethernet frame." > > It also says: > > "It is expected that the LSR will follow the procedures of > [RFC5331], pushing on two labels, with the topmost label being a > "context label" that is the same for all MPLS packets being > transmitted by the LSR onto the Ethernet, but with the second label > being different for different LSPs" > > And RFC 5331 defines context label as: > > "A "context label" is one that identifies a label table in which the > label immediately below the context label should be looked up. A > context label carried as an outermost label over a particular multi- > access subnet/tunnel MUST be unique within the scope of that subnet/ > tunnel." > > Considering the above statements we can conclude that: > > "Multicast MPLS packets with upstream assigned labels encapsulated > in Multicast Ethernet frames in a Multi-access media (LAN) require > to use 0x8848 as Ethertype and require to use a context label that > is unique over that media to identify the label space for the > Multicast MPLS packet" > > The question is since a context label is unique in a LAN and can be > immediately identified as an upstream label, then why do we need > 0x8848 Ethertype? Looks like we could just use the context label. > > Am I missing something? > > NB> The question is "how to identify that this is an upstream > label". Consider label 100. This label could have been allocated by > upstream P1 router as an upstream label and distributed to > downstream router PE. The same label could have been allocated by PE > router and distributed to router P1. So now, when PE > receives a packet over the LAN (from P1) with label 100, it does not > whether to look it up as an upstream label or as a downstream label.. > > Ethertype 0x8848 allows PE to perform lookups in context of P1 and > not in context of labels distributed by PE. > > Thanks > Nitin > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From erosen@cisco.com Thu Oct 22 12:20: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 27F983A6A09 for ; Thu, 22 Oct 2009 12:20:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 MiTKHghygtLV for ; Thu, 22 Oct 2009 12:20:32 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 31C6328C0F5 for ; Thu, 22 Oct 2009 12:20:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=erosen@cisco.com; l=1101; q=dns/txt; s=rtpiport01001; t=1256239241; x=1257448841; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Eric=20Rosen=20|Reply-To:=20er osen@cisco.com|Subject:=20Re:=20[mpls]=20Question=20about =200x8848=20Ethertype=20|Date:=20Thu,=2022=20Oct=202009 =2015:20:39=20-0400|Message-ID:=20<1876.1256239239@erosen -linux>|To:=20"Shahram=20Davari"=20 |cc:=20"Nitin=20Bahadur"=20,=20"mpls@ ietf.org"=20|In-reply-to:=20Your=20message =20of=20Thu,=2022=20Oct=202009=2011:37:33=20-0700.=0D=0A =20=20=20=20=20=20=20=20=20=20=20=20=20<2C2F1EBA8050E74EA 81502D5740B4BD68157683889@SJEXCHCCR02.corp.ad.broadcom.co m>=20; bh=eb9WWzba0KVEJwBDMgB7hBokHkChGrSQknMlHKdrzpM=; b=citkja6wZM3FH7PxKnQnZwwWicmZCAqz5ULeWJFW7GWpiM+WQFPyC/J1 K5aasx+EaDIiYoPmbFXnwW18KwAy1aKHRRUl1S087N16ahGNwGgncM9yd pfni2l0cgcf36LVPVZJVj8uKPikJscDmVjdNqMu4g+QJFAiEerqASmWc9 E=; Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,606,1249257600"; d="scan'208";a="64407442" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 22 Oct 2009 19:20:40 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9MJKeN6028548; Thu, 22 Oct 2009 19:20:40 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 n9MJKeI9001877; Thu, 22 Oct 2009 15:20:40 -0400 To: "Shahram Davari" In-reply-to: Your message of Thu, 22 Oct 2009 11:37:33 -0700. <2C2F1EBA8050E74EA81502D5740B4BD68157683889@SJEXCHCCR02.corp.ad.broadcom.com> Date: Thu, 22 Oct 2009 15:20:39 -0400 Message-ID: <1876.1256239239@erosen-linux> From: Eric Rosen Cc: "mpls@ietf.org" Subject: Re: [mpls] Question about 0x8848 Ethertype 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: Thu, 22 Oct 2009 19:20:33 -0000 Nitin's interpretation matches the intention of the text. If the ethertype of an ethernet frame is 8848: - The top label is to be looked up an interface-specific label space that is populated by the context labels in use on the LAN. Each such label must uniquely correspond to an LSR on the LAN. - As a result of making this lookup, you identify a second label space, one that is specific to the LSR that transmitted the frame. This label space is populated by the labels that have been upstream-assigned by that LSR. If the ethertype is 8847, the top label is an ordinary downstream-assigned label, looked up in a label space populated by the downstream-assigned labels of the LSR that receives the frame. The above mentions three different label spaces; all label uniqueness requirements are relative to a particular label space. > How will a node receiving a unicast packet can identify whether the top > label is upstream assigned or downstream assigned? Per the standards, there is no way of using upstream-assigned labels in unicast ethernet frames. From davari@broadcom.com Thu Oct 22 12:28:10 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 ECD843A6841 for ; Thu, 22 Oct 2009 12:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 3o3uaf67a7aG for ; Thu, 22 Oct 2009 12:28:10 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id 32EEB3A659B for ; Thu, 22 Oct 2009 12:28:10 -0700 (PDT) Received: from [10.16.192.224] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 22 Oct 2009 12:28:02 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Thu, 22 Oct 2009 12:28:02 -0700 From: "Shahram Davari" To: "erosen@cisco.com" Date: Thu, 22 Oct 2009 12:28:00 -0700 Thread-Topic: [mpls] Question about 0x8848 Ethertype Thread-Index: AcpTTMTCveGk5PfqQsOXFa9BEUOI1wAAJaZA Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD6815768389F@SJEXCHCCR02.corp.ad.broadcom.com> References: Your message of Thu, 22 Oct 2009 11:37:33 -0700. <2C2F1EBA8050E74EA81502D5740B4BD68157683889@SJEXCHCCR02.corp.ad.broadcom.com> <1876.1256239239@erosen-linux> In-Reply-To: <1876.1256239239@erosen-linux> 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: 66FE6DC80UC23658360-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "mpls@ietf.org" Subject: Re: [mpls] Question about 0x8848 Ethertype 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, 22 Oct 2009 19:28:11 -0000 Hi Eric, Thanks for your clarifications. Regards, Shahram=20 -----Original Message----- From: Eric Rosen [mailto:erosen@cisco.com]=20 Sent: Thursday, October 22, 2009 12:21 PM To: Shahram Davari Cc: Nitin Bahadur; mpls@ietf.org Subject: Re: [mpls] Question about 0x8848 Ethertype Nitin's interpretation matches the intention of the text. If the ethertype of an ethernet frame is 8848: - The top label is to be looked up an interface-specific label space that i= s populated by the context labels in use on the LAN. Each such label must uniquely correspond to an LSR on the LAN. - As a result of making this lookup, you identify a second label space, one that is specific to the LSR that transmitted the frame. This label space is populated by the labels that have been upstream-assigned by that LSR. If the ethertype is 8847, the top label is an ordinary downstream-assigned label, looked up in a label space populated by the downstream-assigned labels of the LSR that receives the frame. The above mentions three different label spaces; all label uniqueness requirements are relative to a particular label space. > How will a node receiving a unicast packet can identify whether the top > label is upstream assigned or downstream assigned? Per the standards, there is no way of using upstream-assigned labels in unicast ethernet frames. =20 From wwwrun@core3.amsl.com Thu Oct 22 14:19:43 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 D063B3A6894; Thu, 22 Oct 2009 14:19:43 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20091022211943.D063B3A6894@core3.amsl.com> Date: Thu, 22 Oct 2009 14:19:43 -0700 (PDT) Cc: mpls mailing list , mpls chair , Internet Architecture Board , RFC Editor Subject: [mpls] Protocol Action: 'Node behavior upon originating and receiving Resource ReserVation Protocol (RSVP) Path Error message' to BCP 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, 22 Oct 2009 21:19:43 -0000 The IESG has approved the following document: - 'Node behavior upon originating and receiving Resource ReserVation Protocol (RSVP) Path Error message ' as a BCP 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-3209-patherr-06.txt Technical Summary This ID describes a common practice when a node sends or receives an RSVP Path Error message for a preempted MPLS-TE LSP. This document does not define any new protocol extensions. Working Group Summary This document was produced by the WG to help resolve issues with draft-ietf-mpls-soft-preemption. Great care was taken within the WG to make sure that the work represented consensus of all existing implementers. Document Quality This document represents a description of existing implementations. Personnel Loa Andersson is the document shepherd. Adrian Farrel is the Responsible Area Director. RFC Editor Note Please add "Updates RFC3209" to the document header. From davari@broadcom.com Fri Oct 23 10:08: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 552F63A6935 for ; Fri, 23 Oct 2009 10:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 elBIfgCtJs49 for ; Fri, 23 Oct 2009 10:08:39 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id 901343A6784 for ; Fri, 23 Oct 2009 10:08:39 -0700 (PDT) Received: from [10.16.192.224] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 23 Oct 2009 10:08:40 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Fri, 23 Oct 2009 10:08:40 -0700 From: "Shahram Davari" To: "Shahram Davari" , "'erosen@cisco.com'" Date: Fri, 23 Oct 2009 10:08:38 -0700 Thread-Topic: [mpls] Question about 0x8848 Ethertype Thread-Index: AcpTTMTCveGk5PfqQsOXFa9BEUOI1wAAJaZAAC1zDuA= Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD681576839A8@SJEXCHCCR02.corp.ad.broadcom.com> References: Your message of Thu, 22 Oct 2009 11:37:33 -0700. <2C2F1EBA8050E74EA81502D5740B4BD68157683889@SJEXCHCCR02.corp.ad.broadcom.com> <1876.1256239239@erosen-linux> In-Reply-To: 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: 66FF3C920UC24615388-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "'mpls@ietf.org'" Subject: Re: [mpls] Question about 0x8848 Ethertype 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, 23 Oct 2009 17:08:40 -0000 Hi Eric, Do you know why such restriction for unicast exist? Why didn't the standard= let unicast Ethernet carrying upstream-assigned label also use 0x8848?=20 What should a system that receives a Unicast Ethernet frame with Ethertype = 0x8848 do? Should the packet be dropped? Regards, Shahram -----Original Message----- From: Shahram Davari=20 Sent: Thursday, October 22, 2009 12:28 PM To: erosen@cisco.com Cc: Nitin Bahadur; mpls@ietf.org Subject: RE: [mpls] Question about 0x8848 Ethertype Hi Eric, Thanks for your clarifications. Regards, Shahram=20 -----Original Message----- From: Eric Rosen [mailto:erosen@cisco.com]=20 Sent: Thursday, October 22, 2009 12:21 PM To: Shahram Davari Cc: Nitin Bahadur; mpls@ietf.org Subject: Re: [mpls] Question about 0x8848 Ethertype Nitin's interpretation matches the intention of the text. If the ethertype of an ethernet frame is 8848: - The top label is to be looked up an interface-specific label space that i= s populated by the context labels in use on the LAN. Each such label must uniquely correspond to an LSR on the LAN. - As a result of making this lookup, you identify a second label space, one that is specific to the LSR that transmitted the frame. This label space is populated by the labels that have been upstream-assigned by that LSR. If the ethertype is 8847, the top label is an ordinary downstream-assigned label, looked up in a label space populated by the downstream-assigned labels of the LSR that receives the frame. The above mentions three different label spaces; all label uniqueness requirements are relative to a particular label space. > How will a node receiving a unicast packet can identify whether the top > label is upstream assigned or downstream assigned? Per the standards, there is no way of using upstream-assigned labels in unicast ethernet frames. =20 From root@core3.amsl.com Fri Oct 23 12:15: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 91FC63A6970; Fri, 23 Oct 2009 12:15:02 -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: <20091023191502.91FC63A6970@core3.amsl.com> Date: Fri, 23 Oct 2009 12:15:02 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-nm-framework-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: Fri, 23 Oct 2009 19: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 : MPLS-TP Network Management Framework Author(s) : S. Mansfield, et al. Filename : draft-ietf-mpls-tp-nm-framework-01.txt Pages : 16 Date : 2009-10-23 This document provides the network management framework for the Transport Profile for Multi-Protocol Label Switching (MPLS-TP). This framework relies on the management terminology from the ITU-T to describe the management architecture that could be used for an MPLS-TP management network. The management of the MPLS-TP network could be based on multi-tiered distributed management systems. This document provides a description of the network and element management architectures that could be applied and also describes heuristics associated with fault, configuration, and performance aspects of the management system. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-nm-framework-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-nm-framework-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-23120503.I-D@ietf.org> --NextPart-- From wwwrun@core3.amsl.com Fri Oct 23 16:53:03 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 6A88828C0FF; Fri, 23 Oct 2009 16:53:03 -0700 (PDT) From: IESG Secretary To: IETF Announcement list Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20091023235303.6A88828C0FF@core3.amsl.com> Date: Fri, 23 Oct 2009 16:53:03 -0700 (PDT) Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, iab@iab.org, rfc-editor@rfc-editor.org Subject: [mpls] CORRECTION: Protocol Action: 'Node behavior upon originating and receiving Resource ReserVation Protocol (RSVP) Path Error message' 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, 23 Oct 2009 23:53:03 -0000 The IESG has approved the following document: - 'Node behavior upon originating and receiving Resource ReserVation Protocol (RSVP) Path Error message ' 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-3209-patherr-06.txt Technical Summary This ID describes a common practice when a node sends or receives an RSVP Path Error message for a preempted MPLS-TE LSP. This document does not define any new protocol extensions. Working Group Summary This document was produced by the WG to help resolve issues with draft-ietf-mpls-soft-preemption. Great care was taken within the WG to make sure that the work represented consensus of all existing implementers. Document Quality This document represents a description of existing implementations. Personnel Loa Andersson is the document shepherd. Adrian Farrel is the Responsible Area Director. RFC Editor Note Please add "Updates RFC3209" to the document header. From root@core3.amsl.com Fri Oct 23 18:15: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 F34CF3A67C2; Fri, 23 Oct 2009 18: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: <20091024011501.F34CF3A67C2@core3.amsl.com> Date: Fri, 23 Oct 2009 18:15:01 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-lsp-ping-enhanced-dsmap-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: Sat, 24 Oct 2009 01: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 : Mechanism for performing LSP-Ping over MPLS tunnels Author(s) : N. Bahadur, et al. Filename : draft-ietf-mpls-lsp-ping-enhanced-dsmap-04.txt Pages : 21 Date : 2009-10-23 This document describes methods for performing lsp-ping traceroute over mpls tunnels and for traceroute of stitched mpls LSPs. The techniques outlined in RFC 4379 are insufficient to perform traceroute FEC validation and path discovery for a LSP that goes over other mpls tunnels or for a stitched LSP. This document describes enhancements to the downstream-mapping TLV (defined in RFC 4379). These enhancements along with other procedures outlined in this document can be used to trace such LSPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-lsp-ping-enhanced-dsmap-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-lsp-ping-enhanced-dsmap-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-23181205.I-D@ietf.org> --NextPart-- From loa@pi.nu Sat Oct 24 13:20: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 DD3683A682A; Sat, 24 Oct 2009 13:20:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.02 X-Spam-Level: X-Spam-Status: No, score=-1.02 tagged_above=-999 required=5 tests=[AWL=-0.835, 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 H+Q2GE1UCjWL; Sat, 24 Oct 2009 13:20:08 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 095743A66B4; Sat, 24 Oct 2009 13:20:07 -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 AE36FD404F; Sat, 24 Oct 2009 22:20:16 +0200 (CEST) Message-ID: <4AE3617D.3010008@pi.nu> Date: Sat, 24 Oct 2009 22:20:13 +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] mpls-tp slots in Hiroshima 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, 24 Oct 2009 20:20:09 -0000 All, I've been asked what mpls, mpls-tp and pwe3 meetings that are planned for Hiroshima. Earlier we have had problems completing the "classical" mpls and mpls-tp in two sessions. Given that the there are no changes in the agenda as i looks today that effect working groups that do mpls-tp work the following is the plan: 1. Monday 17.40 - 19.20 Orchid Centre Multiprotocol Label Switching WG This meeting will start with the mpls drafts, but is likely to address some mpls-tp drafts towards the end 2. Wednesday 09.00 - 11.30 Orchid East Multiprotocol Label Switching WG This meeting is planned to address mpls-tp drafts only The agenda says that there is a morning break at 10.15 but we will ignore that and a 2.5 hours meeting. 3. Thursday 13.00 - 15.00 Orchid West Pseudowire Emulation Edge to Edge WG This meeting will address classical pwe3 drafts 4. Friday 09.00 - 11.30 Acacia West Pseudowire Emulation Edge to Edge WG This meeting is intended to address mpls-tp drafts There are also some mpls-tp drafts that will be discussed in the ccamp working group, mostly control plane related. /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 root@core3.amsl.com Sun Oct 25 14: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 9803B3A69E6; Sun, 25 Oct 2009 14: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: <20091025214501.9803B3A69E6@core3.amsl.com> Date: Sun, 25 Oct 2009 14:45:01 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-mpls-and-gmpls-security-framework-07.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, 25 Oct 2009 21: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 : Security Framework for MPLS and GMPLS Networks Author(s) : L. Fang, M. Behringer Filename : draft-ietf-mpls-mpls-and-gmpls-security-framework-07.txt Pages : 60 Date : 2009-10-25 This document provides a security framework for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks. This document addresses the security aspects that are relevant in the context of MPLS and GMPLS. It describes the security threats, the related defensive techniques, and the mechanisms for detection and reporting. This document emphasizes RSVP-TE and LDP security considerations, as well as Inter-AS and Inter-provider security considerations for building and maintaining MPLS and GMPLS networks across different domains or different Service Providers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-mpls-and-gmpls-security-framework-07.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-mpls-and-gmpls-security-framework-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-25144425.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Sun Oct 25 15:15: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 0AD853A6946; Sun, 25 Oct 2009 15: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: <20091025221502.0AD853A6946@core3.amsl.com> Date: Sun, 25 Oct 2009 15:15:02 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-survive-fwk-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: Sun, 25 Oct 2009 22: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 : Multiprotocol Label Switching Transport Profile Survivability Framework Author(s) : N. Sprecher, A. Farrel Filename : draft-ietf-mpls-tp-survive-fwk-01.txt Pages : 48 Date : 2009-10-25 Network survivability is the network's ability to restore traffic delivery following failure of network resources or an attack on the network. It plays a critical role in the delivery of guaranteed services in transport networks to meet the requirements expressed in Service Level Agreements (SLAs). The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet transport technology based on the MPLS data plane and re-using many aspects of the MPLS management and control planes. This document provides a framework for the provision of survivability functions in the data plane of an MPLS-TP network using tools provided by the management plane and the control plane as well as techniques inherent in the data plane itself. This document is a product of a joint International Telecommunications Union (ITU)-IETF effort 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). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-survive-fwk-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-survive-fwk-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-25150925.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Sun Oct 25 15:30: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 8F4843A6946; Sun, 25 Oct 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: <20091025223001.8F4843A6946@core3.amsl.com> Date: Sun, 25 Oct 2009 15:30:01 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-tp-survive-fwk-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: Sun, 25 Oct 2009 22:30: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 : Multiprotocol Label Switching Transport Profile Survivability Framework Author(s) : N. Sprecher, A. Farrel Filename : draft-ietf-mpls-tp-survive-fwk-02.txt Pages : 48 Date : 2009-10-25 Network survivability is the network's ability to restore traffic delivery following failure of network resources or an attack on the network. It plays a critical role in the delivery of guaranteed services in transport networks to meet the requirements expressed in Service Level Agreements (SLAs). The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet transport technology based on the MPLS data plane and re-using many aspects of the MPLS management and control planes. This document provides a framework for the provision of survivability functions in the data plane of an MPLS-TP network using tools provided by the management plane and the control plane as well as techniques inherent in the data plane itself. This document is a product of a joint International Telecommunications Union (ITU)-IETF effort 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). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-survive-fwk-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-survive-fwk-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-25151842.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 26 01: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 7039E3A68F7; Mon, 26 Oct 2009 01: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: <20091026081501.7039E3A68F7@core3.amsl.com> Date: Mon, 26 Oct 2009 01:15:01 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-ldp-p2mp-08.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, 26 Oct 2009 08: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 : Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths Author(s) : I. Minei, et al. Filename : draft-ietf-mpls-ldp-p2mp-08.txt Pages : 37 Date : 2009-10-26 This document describes extensions to the Label Distribution Protocol (LDP) for the setup of point to multi-point (P2MP) and multipoint-to- multipoint (MP2MP) Label Switched Paths (LSPs) in Multi-Protocol Label Switching (MPLS) networks. These extensions are also referred to as mLDP Multicast LDP. mLDP constructs the P2MP or MP2MP LSPs without interacting with or relying upon any other multicast tree construction protocol. Protocol elements and procedures for this solution are described for building such LSPs in a receiver-initiated manner. There can be various applications for P2MP/MP2MP LSPs, for example IP multicast or support for multicast in BGP/MPLS L3VPNs. Specification of how such applications can use a LDP signaled P2MP/ MP2MP LSP is outside the scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-p2mp-08.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-p2mp-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26010846.I-D@ietf.org> --NextPart-- From wwwrun@core3.amsl.com Mon Oct 26 08:02:46 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 5CE433A6A93; Mon, 26 Oct 2009 08:02:46 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20091026150246.5CE433A6A93@core3.amsl.com> Date: Mon, 26 Oct 2009 08:02:46 -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, 26 Oct 2009 15:02:46 -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 This is a 2nd last call on this document. The first last call should have pointed explicitly to the normative references to two Informational RFCs: - RFC 3871 "Operational Security Requirements for Large Internet Service Provider (ISP) IP Network Infrastructure", and - RFC 4377 "Operations and Management (OAM) Requirements for Multi- Protocol Label Switched (MPLS) Networks". This last call is focused solely on whether these downrefs are appropriate in this document. These downrefs are not intended to create a precedent and there is no plan to add the referenced RFCs to the downref registry. 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-11-09. 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-06.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=18244&rfc_flag=0 From erosen@cisco.com Mon Oct 26 08:07: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 AFCE03A6A91 for ; Mon, 26 Oct 2009 08:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 LkqqRCYSnG13 for ; Mon, 26 Oct 2009 08:07:32 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 546603A69F0 for ; Mon, 26 Oct 2009 08:07:32 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,626,1249257600"; d="scan'208";a="217872799" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by sj-iport-2.cisco.com with ESMTP; 26 Oct 2009 15:07:40 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9QF7d4H018760; Mon, 26 Oct 2009 15:07:39 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 n9QF7YQm030526; Mon, 26 Oct 2009 11:07:34 -0400 To: "Shahram Davari" In-reply-to: Your message of Fri, 23 Oct 2009 10:08:38 -0700. <2C2F1EBA8050E74EA81502D5740B4BD681576839A8@SJEXCHCCR02.corp.ad.broadcom.com> Date: Mon, 26 Oct 2009 11:07:34 -0400 Message-ID: <30525.1256569654@erosen-linux> From: Eric Rosen Cc: "'mpls@ietf.org'" Subject: Re: [mpls] Question about 0x8848 Ethertype 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, 26 Oct 2009 15:07:33 -0000 > Why didn't the standard let unicast Ethernet carrying upstream-assigned > label also use 0x8848? Unicast was considered to be out of scope of RFCs 5331/5332. From wwwrun@core3.amsl.com Mon Oct 26 10:12:07 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 2FB223A68C9; Mon, 26 Oct 2009 10:12:07 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20091026171207.2FB223A68C9@core3.amsl.com> Date: Mon, 26 Oct 2009 10:12:07 -0700 (PDT) Cc: mpls mailing list , mpls chair , Internet Architecture Board , RFC Editor Subject: [mpls] Protocol Action: '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 List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2009 17:12:07 -0000 The IESG has approved the following document: - 'An Inband Data Communication Network For the MPLS Transport Profile ' as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Ross Callon and Adrian Farrel. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-gach-dcn-06.txt Technical Summary 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. 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 for delivery to the management or signaling/routing control plane components on an MPLS-TP node. It should be noted that the use of the G-ACh to provide connectivity for the DCN is intended for use only where the MPLS-TP network is not capable of encapsulating or delivering native DCN messages. Working Group Summary The document is part of the MPLS-TP project, the cooperation between IETF and ITU-T to specify an MPLS transport profile. The working group has consensus on the document, and the ITU-T has indicated that it supports the publication. Document Quality We have seen test implementations of the G-ACh and received feedback, but we know of no current implementations of the MCC or SCC. We have been informed by two vendors of their intent to implement soon. The document review has been substantial. Considerable input to early revisions was received from MPLS WG participants, from participants in the MPLS-TP project. The WG last call was liaised to the ITU-T, and the final revision (including resolution to WG last call comments) was supported by the ITU-T in a liaison.(see PROTO writeup by Loa Andersson in the ID tracker). Personnel Loa Andersson is the Document Shepherd. Ross Callon is the responsible area director. RFC Editor Note Section 4 OLD The G-ACh provides a virtual link between MPLS-TP nodes and might be used to induce many forms of security attack. Protocols that operate over the MCN or SCN are REQUIRED to include adequate security mechanisms and implementations MUST allow operators to configure the use of those mechanisms. NEW The G-ACh provides a virtual link between MPLS-TP nodes and might be used to induce many forms of security attack. The MPLS data plane does not include any security mechanisms of its own, therefore it is important that protocols using the DCN apply their own security. Protocols that operate over the MCN or SCN are REQUIRED to include adequate security mechanisms and implementations MUST allow operators to configure the use of those mechanisms. END From root@core3.amsl.com Mon Oct 26 10:30:03 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 F12BE3A6867; Mon, 26 Oct 2009 10:30:02 -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: <20091026173002.F12BE3A6867@core3.amsl.com> Date: Mon, 26 Oct 2009 10:30:02 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-rsvp-te-no-php-oob-mapping-03.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, 26 Oct 2009 17:30:03 -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 : Non PHP Behavior and out-of-band mapping for RSVP-TE LSPs Author(s) : Z. Ali, G. Swallow Filename : draft-ietf-mpls-rsvp-te-no-php-oob-mapping-03.txt Pages : 9 Date : 2009-10-26 There are many deployment scenarios which require Egress LSR to receive binding of the RSVP-TE LSP to an application, and payload identification, using some "out-of-band" (OOB) mechanism. This document proposes protocol mechanisms to address this requirement. The procedures described in this document are equally applicable for point-to-point (P2P) and point-to- multipoint (P2MP) LSPs. Conventions used in this document In examples, "C:" and "S:" indicate lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 0. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-te-no-php-oob-mapping-03.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-rsvp-te-no-php-oob-mapping-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26102248.I-D@ietf.org> --NextPart-- From root@core3.amsl.com Mon Oct 26 10: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 CAF323A6ABD; Mon, 26 Oct 2009 10: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: <20091026174501.CAF323A6ABD@core3.amsl.com> Date: Mon, 26 Oct 2009 10:45:01 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-tp-rosetta-stone-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: Mon, 26 Oct 2009 17: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 Thesaurus for the Terminology used in Multiprotocol Label Switching Transport Profile (MPLS-TP) drafts/RFCs and ITU-T's Transport Network Recommendations Author(s) : H. Helvoort, L. Andersson, N. Sprecher Filename : draft-ietf-mpls-tp-rosetta-stone-01.txt Pages : 21 Date : 2009-10-26 MPLS-TP is based on a profile of the MPLS and PW procedures as specified in the MPLS-TE and (MS-)PW architectures developed by the IETF. The ITU-T has specified a Transport Network architecture. This document provides a thesaurus for the interpretation of MPLS-TP terminology within the context of the ITU-T Transport Network recommendations. It is important to note that MPLS-TP is applicable in a wider set of contexts than just Transport Networks. The definitions presented in this document do not provide exclusive nor complete interpretations of MPLS-TP concepts. This document simply allows the MPLS-TP terms to be applied within the Transport Network context. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-rosetta-stone-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-rosetta-stone-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26103342.I-D@ietf.org> --NextPart-- From loa@pi.nu Mon Oct 26 13:49:47 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 6E3663A67CC; Mon, 26 Oct 2009 13:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] 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 xXlAejU9pMzU; Mon, 26 Oct 2009 13:49:46 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 959F13A6781; Mon, 26 Oct 2009 13:49:46 -0700 (PDT) Received: from [38.109.153.43] (unknown [38.109.153.43]) (using SSLv3 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 0E0CED404F; Mon, 26 Oct 2009 21:49:56 +0100 (CET) Message-ID: <4AE60B70.6090603@pi.nu> Date: Mon, 26 Oct 2009 21:49:52 +0100 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] poll on draft-swallow-mpls-tp-identifiers-02.txt for wg draft 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, 26 Oct 2009 20:49:47 -0000 All, this is to start a two week poll in making draft-swallow-mpls-tp-identifiers-02.txt an MPLS working group document. Send a mail to the mpls-tp@ietf.org mailing list, indicating "yes/support" or "no/do not support". Comments on the content of the draft should be sent to the same mailing list with a different subject line. The poll ends Sun Nov 8. /Loa MPLS WG co-chair -- 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 llevrau@alcatel-lucent.com Mon Oct 26 14:22:00 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 D97EB28C28B; Mon, 26 Oct 2009 14:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 Tq087QrzmYTG; Mon, 26 Oct 2009 14:21:59 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 8BA2428C181; Mon, 26 Oct 2009 14:21:58 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n9QLMAGg008363 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 26 Oct 2009 22:22:10 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 26 Oct 2009 22:22:10 +0100 From: "LEVRAU, LIEVEN (LIEVEN)" To: Loa Andersson , "mpls-tp@ietf.org" , "mpls@ietf.org" , "pwe3@ietf.org" , "ccamp@ietf.org" Date: Mon, 26 Oct 2009 22:22:26 +0100 Thread-Topic: [mpls-tp] poll on draft-swallow-mpls-tp-identifiers-02.txt for wg draft Thread-Index: AcpWfeuB1DAoQZ3GTT6PxAgvXRRyqwABFHEA Message-ID: References: <4AE60B70.6090603@pi.nu> In-Reply-To: <4AE60B70.6090603@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Subject: Re: [mpls] [mpls-tp] poll on draft-swallow-mpls-tp-identifiers-02.txt for wg draft 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, 26 Oct 2009 21:22:00 -0000 Yes support. ./ Lieven -----Original Message----- From: mpls-tp-bounces@ietf.org [mailto:mpls-tp-bounces@ietf.org] On Behalf = Of Loa Andersson Sent: 26 October 2009 21:50 To: mpls-tp@ietf.org; mpls@ietf.org; pwe3@ietf.org; ccamp@ietf.org Subject: [mpls-tp] poll on draft-swallow-mpls-tp-identifiers-02.txt for wg = draft All, this is to start a two week poll in making draft-swallow-mpls-tp-identifiers-02.txt an MPLS working group document. Send a mail to the mpls-tp@ietf.org mailing list, indicating "yes/support" or "no/do not support". Comments on the content of the draft should be sent to the same mailing list with a different subject line. The poll ends Sun Nov 8. /Loa MPLS WG co-chair --=20 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 _______________________________________________ mpls-tp mailing list mpls-tp@ietf.org https://www.ietf.org/mailman/listinfo/mpls-tp From root@core3.amsl.com Mon Oct 26 15: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 E48A43A67A6; Mon, 26 Oct 2009 15: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: <20091026224501.E48A43A67A6@core3.amsl.com> Date: Mon, 26 Oct 2009 15:45:01 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-tp-oam-framework-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: Mon, 26 Oct 2009 22:45: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 : MPLS-TP OAM Framework Author(s) : D. Allan, I. Busi, B. Niven-Jenkins Filename : draft-ietf-mpls-tp-oam-framework-02.txt Pages : 46 Date : 2009-10-26 Multi-Protocol Label Switching (MPLS) Transport Profile (MPLS-TP) is based on a profile of the MPLS and pseudowire (PW) procedures as specified in the MPLS Traffic Engineering (MPLS-TE), pseudowire (PW) and multi-segment PW (MS-PW) architectures complemented with additional Operations, Administration and Maintenance (OAM) procedures for fault, performance and protection-switching management for packet transport applications that do not rely on the presence of a control plane. This document describes a framework to support a comprehensive set of OAM procedures that fulfills the MPLS-TP OAM requirements [12]. This document provides a framework that supports a comprehensive set of OAM procedures that fulfills the MPLS-TP OAM requirements [11]. This document provides a framework that supports a comprehensive set of OAM procedures that fulfills the MPLS-TP OAM requirements [11]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-oam-framework-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-oam-framework-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-10-26153250.I-D@ietf.org> --NextPart-- From zali@cisco.com Mon Oct 26 15:58:12 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 D43A13A690C; Mon, 26 Oct 2009 15:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 2tyL2o2PZlid; Mon, 26 Oct 2009 15:58:12 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id ECC4C3A6838; Mon, 26 Oct 2009 15:58:11 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAFfG5UqrRN+K/2dsb2JhbADBYZdRAoQ9BIFe X-IronPort-AV: E=Sophos;i="4.44,628,1249257600"; d="scan'208";a="418374408" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 26 Oct 2009 22:58:25 +0000 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n9QMwPxf000333; Mon, 26 Oct 2009 22:58:25 GMT Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Oct 2009 18:58:25 -0400 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: Mon, 26 Oct 2009 18:57:33 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] [mpls-tp] poll on draft-swallow-mpls-tp-identifiers-02.txt for wg draft Thread-Index: AcpWfeuB1DAoQZ3GTT6PxAgvXRRyqwABFHEAAANTFeA= References: <4AE60B70.6090603@pi.nu> From: "Zafar Ali (zali)" To: "Loa Andersson" , , , , X-OriginalArrivalTime: 26 Oct 2009 22:58:25.0371 (UTC) FILETIME=[D2FEDAB0:01CA568F] Subject: Re: [mpls] [CCAMP] [mpls-tp] poll on draft-swallow-mpls-tp-identifiers-02.txt for wg draft 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, 26 Oct 2009 22:58:12 -0000 yes/ support.=20 Thanks Regards... Zafar=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: 26 October 2009 21:50 > To: mpls-tp@ietf.org; mpls@ietf.org; pwe3@ietf.org; ccamp@ietf.org > Subject: [mpls-tp] poll on=20 > draft-swallow-mpls-tp-identifiers-02.txt for wg draft >=20 > All, >=20 > this is to start a two week poll in making >=20 > draft-swallow-mpls-tp-identifiers-02.txt >=20 > an MPLS working group document. >=20 > Send a mail to the mpls-tp@ietf.org mailing list, indicating=20 > "yes/support" or "no/do not support". >=20 > Comments on the content of the draft should be sent to the=20 > same mailing list with a different subject line. >=20 > The poll ends Sun Nov 8. >=20 > /Loa >=20 > MPLS WG co-chair >=20 >=20 > --=20 >=20 >=20 > Loa Andersson email:=20 > loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92=20 > 13 _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 From mach@huawei.com Mon Oct 26 18:43:51 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 E728A3A6818; Mon, 26 Oct 2009 18:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.494 X-Spam-Level: X-Spam-Status: No, score=-0.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] 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 ohbQK84EczK2; Mon, 26 Oct 2009 18:43:51 -0700 (PDT) Received: from szxga02-in.huawei.com (unknown [119.145.14.65]) by core3.amsl.com (Postfix) with ESMTP id 21EC63A67FF; Mon, 26 Oct 2009 18:43:51 -0700 (PDT) Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KS500IQEGSYQV@szxga02-in.huawei.com>; Tue, 27 Oct 2009 09:43:46 +0800 (CST) Received: from m55527c ([10.111.12.100]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KS50096RGSYV5@szxga02-in.huawei.com>; Tue, 27 Oct 2009 09:43:46 +0800 (CST) Date: Tue, 27 Oct 2009 09:43:46 +0800 From: Mach Chen To: mpls@ietf.org, mpls-tp@ietf.org Message-id: <7341D0C48CCC420CAF7AC0782D7DE0D4@m55527c> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 Content-type: text/plain; format=flowed; charset=gb2312; reply-type=original Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal Subject: [mpls] New draft notification: draft-chen-mpls-return-path-specified-lsp-ping-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: Tue, 27 Oct 2009 01:43:52 -0000 Hi all, We have just submitted a update of the "Return Path Specified LSP Ping" draft, here is the link: http://tools.ietf.org/id/draft-chen-mpls-return-path-specified-lsp-ping-01.txt. This draft defines extensions to the "LSP Ping" [RFC4379] that allow selection of the LSP to use for the echo reply return path. Enforcing a specific return path can be used to verify bidirectional connectivity and also increase LSP ping robustness. It may also be used by BFD for MPLS bootstrap signaling thereby making BFD for MPLS more robust. This draft was present at last IETF meeting, at and after that meeting we received many comments and suggestion to this draft, this version has resolved the comments and added some new functions according to the suggestion. The mainly changes include: 1. Resolved the comments raised from the last IETF meeting and the list, 2. Two new sub-TLVs(IPv4/IPv6 Tunnel sub-TLVs) added: 1) enable that a general tunnel FEC could be specified as the return path when specifying a particular LSP is inconvenient, and 2) they could also be used by "BFD for MPLS" session bootstrap signaling in end-end protection scenario, 3. Partial text rework, hence to make it more readable. Any comments and suggestions are appreciated! Best regards, Mach From mach@huawei.com Mon Oct 26 18:44:57 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 0DE963A6824; Mon, 26 Oct 2009 18:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.546 X-Spam-Level: X-Spam-Status: No, score=-1.546 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001] 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 Ps5NZqp+bICv; Mon, 26 Oct 2009 18:44:56 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id 186423A6894; Mon, 26 Oct 2009 18:44:52 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KS500E3TGV4X2@szxga01-in.huawei.com>; Tue, 27 Oct 2009 09:45:04 +0800 (CST) Received: from m55527c ([10.111.12.100]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KS5008D6GV3QG@szxga01-in.huawei.com>; Tue, 27 Oct 2009 09:45:04 +0800 (CST) Date: Tue, 27 Oct 2009 09:45:04 +0800 From: Mach Chen To: mpls@ietf.org, mpls-tp@ietf.org, rtg-bfd@ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 Content-type: text/plain; format=flowed; charset=gb2312; reply-type=original Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal Subject: [mpls] New draft notification: draft-chen-mpls-bfd-enhancement-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: Tue, 27 Oct 2009 01:44:57 -0000 Hi all, We just sumbitted a new draft that defines some enhancments to "BFD for MPLS". This is the link: http://tools.ietf.org/id/draft-chen-mpls-bfd-enhancement-00.txt The enhancement defined in this draft can be used to specify the return path of BFD control packets for a specific BFD session. Specifying the return path increases the robustness of BFD failure detection and reduces false positives. This draft also defines a way to avoid duplicate BFD sessions currently encountered with co-routed bidirectional LSPs and associated bidirectional LSP. The enhancement halves the number of BFD sessions over those LSPs, and allows a co-routed bidirectional LSP, an associated bidirectional LSP or even a pair of unidirectional LSPs to be protected and switched as a single entity. Any comments and suggestions are welcomed! Best regards, Mach From davari@broadcom.com Mon Oct 26 18:45:34 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 4236B3A6890; Mon, 26 Oct 2009 18:45:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 1nrM0TVKCRY8; Mon, 26 Oct 2009 18:45:33 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id 968363A6818; Mon, 26 Oct 2009 18:45:32 -0700 (PDT) Received: from [10.16.192.232] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 26 Oct 2009 18:44:06 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Mon, 26 Oct 2009 18:44:06 -0700 From: "Shahram Davari" To: "Loa Andersson" , "mpls-tp@ietf.org" , "mpls@ietf.org" , "pwe3@ietf.org" , "ccamp@ietf.org" Date: Mon, 26 Oct 2009 18:44:04 -0700 Thread-Topic: [CCAMP] [mpls-tp] poll on draft-swallow-mpls-tp-identifiers-02.txt for wg draft Thread-Index: AcpWfeuB1DAoQZ3GTT6PxAgvXRRyqwABFHEAAANTFeAABdf2MA== Message-ID: <2C2F1EBA8050E74EA81502D5740B4BD68157683B81@SJEXCHCCR02.corp.ad.broadcom.com> References: <4AE60B70.6090603@pi.nu> In-Reply-To: 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: 66F88FEC0UC27937264-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [mpls] [CCAMP] [mpls-tp] poll on draft-swallow-mpls-tp-identifiers-02.txt for wg draft 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, 27 Oct 2009 01:45:34 -0000 Support. -Shahram > -----Original Message----- > From: mpls-tp-bounces@ietf.org=20 > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: 26 October 2009 21:50 > To: mpls-tp@ietf.org; mpls@ietf.org; pwe3@ietf.org; ccamp@ietf.org > Subject: [mpls-tp] poll on=20 > draft-swallow-mpls-tp-identifiers-02.txt for wg draft >=20 > All, >=20 > this is to start a two week poll in making >=20 > draft-swallow-mpls-tp-identifiers-02.txt >=20 > an MPLS working group document. >=20 > Send a mail to the mpls-tp@ietf.org mailing list, indicating=20 > "yes/support" or "no/do not support". >=20 > Comments on the content of the draft should be sent to the=20 > same mailing list with a different subject line. >=20 > The poll ends Sun Nov 8. >=20 > /Loa >=20 > MPLS WG co-chair >=20 >=20 > --=20 >=20 >=20 > Loa Andersson email:=20 > loa.andersson@ericsson.com > Sr Strategy and Standards Manager loa@pi.nu > Ericsson Inc phone: +46 10 717 52 13 > +46 767 72 92=20 > 13 _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From zhang.fei3@zte.com.cn Mon Oct 26 18:48: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 350D528C17F; Mon, 26 Oct 2009 18:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.776 X-Spam-Level: X-Spam-Status: No, score=-95.776 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, 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 r6zUwmDCl2c0; Mon, 26 Oct 2009 18:48:38 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 6108428C151; Mon, 26 Oct 2009 18:48:37 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 111644429685300; Tue, 27 Oct 2009 09:22:17 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.100] with StormMail ESMTP id 14630.4803937422; Tue, 27 Oct 2009 09:36:55 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n9R1mfZA033807; Tue, 27 Oct 2009 09:48:41 +0800 (CST) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <4AE60B70.6090603@pi.nu> To: Loa Andersson MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: zhang.fei3@zte.com.cn Date: Tue, 27 Oct 2009 09:48:39 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-10-27 09:48:37, Serialize complete at 2009-10-27 09:48:37 Content-Type: multipart/alternative; boundary="=_alternative 000A48124825765C_=" X-MAIL: mse2.zte.com.cn n9R1mfZA033807 Cc: mpls@ietf.org, ccamp@ietf.org, pwe3@ietf.org, ccamp-bounces@ietf.org, "mpls-tp@ietf.org" Subject: Re: [mpls] [CCAMP] poll on draft-swallow-mpls-tp-identifiers-02.txt for wg draft 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, 27 Oct 2009 01:48:39 -0000 This is a multipart message in MIME format. --=_alternative 000A48124825765C_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 U3VwcG9ydKOho6GjoQ0KDQpGZWkNCg0Ko7qjqQ0KDQoNCg0KTG9hIEFuZGVyc3NvbiA8bG9hQHBp Lm51PiANCreivP7IyzogIGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMDktMTAtMjcgMDQ6NDkN Cg0KytW8/sjLDQoibXBscy10cEBpZXRmLm9yZyIgPG1wbHMtdHBAaWV0Zi5vcmc+LCBtcGxzQGll dGYub3JnLCBwd2UzQGlldGYub3JnLCANCmNjYW1wQGlldGYub3JnDQqzrcvNDQoNCtb3zOINCltD Q0FNUF0gcG9sbCBvbiBkcmFmdC1zd2FsbG93LW1wbHMtdHAtaWRlbnRpZmllcnMtMDIudHh0IGZv ciB3ZyBkcmFmdA0KDQoNCg0KDQoNCg0KQWxsLA0KDQp0aGlzIGlzIHRvIHN0YXJ0IGEgdHdvIHdl ZWsgcG9sbCBpbiBtYWtpbmcNCg0KZHJhZnQtc3dhbGxvdy1tcGxzLXRwLWlkZW50aWZpZXJzLTAy LnR4dA0KDQphbiBNUExTIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuDQoNClNlbmQgYSBtYWlsIHRv IHRoZSBtcGxzLXRwQGlldGYub3JnIG1haWxpbmcgbGlzdCwgaW5kaWNhdGluZw0KInllcy9zdXBw b3J0IiBvciAibm8vZG8gbm90IHN1cHBvcnQiLg0KDQpDb21tZW50cyBvbiB0aGUgY29udGVudCBv ZiB0aGUgZHJhZnQgc2hvdWxkIGJlIHNlbnQgdG8gdGhlIHNhbWUNCm1haWxpbmcgbGlzdCB3aXRo IGEgZGlmZmVyZW50IHN1YmplY3QgbGluZS4NCg0KVGhlIHBvbGwgZW5kcyBTdW4gTm92IDguDQoN Ci9Mb2ENCg0KTVBMUyBXRyBjby1jaGFpcg0KDQoNCi0tIA0KDQoNCkxvYSBBbmRlcnNzb24gICAg ICAgICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYS5hbmRlcnNzb25AZXJpY3Nzb24uY29tDQpT ciBTdHJhdGVneSBhbmQgU3RhbmRhcmRzIE1hbmFnZXIgICAgICAgICAgICBsb2FAcGkubnUNCkVy aWNzc29uIEluYyAgICAgICAgICAgICAgICAgICAgICAgICAgcGhvbmU6ICs0NiAxMCA3MTcgNTIg MTMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICArNDYgNzY3 IDcyIDkyIDEzDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KQ0NBTVAgbWFpbGluZyBsaXN0DQpDQ0FNUEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KDQoNCg0K --=_alternative 000A48124825765C_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlN1cHBvcnSjoaOho6E8L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkZlaTwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+o7qjqTwvZm9udD4NCjxicj4N Cjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lk dGg9MjYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5Mb2EgQW5kZXJzc29uICZs dDtsb2FAcGkubnUmZ3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj63orz+yMs6ICZuYnNwO2NjYW1wLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAwOS0xMC0yNyAwNDo0OTwvZm9udD4NCjx0 ZCB3aWR0aD03MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9m b250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4mcXVvdDttcGxz LXRwQGlldGYub3JnJnF1b3Q7ICZsdDttcGxzLXRwQGlldGYub3JnJmd0OywNCm1wbHNAaWV0Zi5v cmcsIHB3ZTNAaWV0Zi5vcmcsIGNjYW1wQGlldGYub3JnPC9mb250Pg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6z rcvNPC9mb250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWdu PXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0K PHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5bQ0NBTVBdIHBvbGwgb24gZHJhZnQt c3dhbGxvdy1tcGxzLXRwLWlkZW50aWZpZXJzLTAyLnR4dA0KZm9yIHdnICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwO2RyYWZ0PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yPjx0dD5BbGwsPGJyPg0KPGJyPg0KdGhpcyBpcyB0byBzdGFydCBhIHR3 byB3ZWVrIHBvbGwgaW4gbWFraW5nPGJyPg0KPGJyPg0KZHJhZnQtc3dhbGxvdy1tcGxzLXRwLWlk ZW50aWZpZXJzLTAyLnR4dDxicj4NCjxicj4NCmFuIE1QTFMgd29ya2luZyBncm91cCBkb2N1bWVu dC48YnI+DQo8YnI+DQpTZW5kIGEgbWFpbCB0byB0aGUgbXBscy10cEBpZXRmLm9yZyBtYWlsaW5n IGxpc3QsIGluZGljYXRpbmc8YnI+DQomcXVvdDt5ZXMvc3VwcG9ydCZxdW90OyBvciAmcXVvdDtu by9kbyBub3Qgc3VwcG9ydCZxdW90Oy48YnI+DQo8YnI+DQpDb21tZW50cyBvbiB0aGUgY29udGVu dCBvZiB0aGUgZHJhZnQgc2hvdWxkIGJlIHNlbnQgdG8gdGhlIHNhbWU8YnI+DQptYWlsaW5nIGxp c3Qgd2l0aCBhIGRpZmZlcmVudCBzdWJqZWN0IGxpbmUuPGJyPg0KPGJyPg0KVGhlIHBvbGwgZW5k cyBTdW4gTm92IDguPGJyPg0KPGJyPg0KL0xvYTxicj4NCjxicj4NCk1QTFMgV0cgY28tY2hhaXI8 YnI+DQo8YnI+DQo8YnI+DQotLSA8YnI+DQo8YnI+DQo8YnI+DQpMb2EgQW5kZXJzc29uICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 DQombmJzcDsgJm5ic3A7ICZuYnNwOyBlbWFpbDogbG9hLmFuZGVyc3NvbkBlcmljc3Nvbi5jb208 YnI+DQpTciBTdHJhdGVneSBhbmQgU3RhbmRhcmRzIE1hbmFnZXIgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtsb2FAcGkubnU8YnI+DQpFcmljc3NvbiBJbmMgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsN CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3Bob25lOiArNDYgMTAgNzE3IDUyIDEzPGJyPg0K ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOys0NiA3Njcg NzIgOTIgMTM8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXzxicj4NCkNDQU1QIG1haWxpbmcgbGlzdDxicj4NCkNDQU1QQGlldGYub3JnPGJyPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcDxicj4NCjxicj4NCjwvdHQ+ PC9mb250Pg0KPGJyPg0K --=_alternative 000A48124825765C_=-- From lufang@cisco.com Mon Oct 26 21:19:15 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 254E43A69F4; Mon, 26 Oct 2009 21:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 wcYtsKBCaQdb; Mon, 26 Oct 2009 21:19:14 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 345853A63EB; Mon, 26 Oct 2009 21:19:14 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABsR5kqrR7H+/2dsb2JhbADAM5gEAoQ9BIFf X-IronPort-AV: E=Sophos;i="4.44,630,1249257600"; d="scan'208";a="261856076" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 27 Oct 2009 04:19:28 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n9R4JRIN004553; Tue, 27 Oct 2009 04:19:28 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 00:19:27 -0400 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, 27 Oct 2009 00:19:27 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] [CCAMP] [mpls-tp] poll ondraft-swallow-mpls-tp-identifiers-02.txt for wg draft Thread-Index: AcpWfeuB1DAoQZ3GTT6PxAgvXRRyqwABFHEAAANTFeAAC0Id8A== References: <4AE60B70.6090603@pi.nu> From: "Luyuan Fang (lufang)" To: "Loa Andersson" , , , , X-OriginalArrivalTime: 27 Oct 2009 04:19:27.0840 (UTC) FILETIME=[AC525E00:01CA56BC] Subject: Re: [mpls] [CCAMP] [mpls-tp] poll ondraft-swallow-mpls-tp-identifiers-02.txt for wg draft 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, 27 Oct 2009 04:19:15 -0000 Support. Luyuan > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: 26 October 2009 21:50 > To: mpls-tp@ietf.org; mpls@ietf.org; pwe3@ietf.org; ccamp@ietf.org > Subject: [mpls-tp] poll on > draft-swallow-mpls-tp-identifiers-02.txt for wg draft >=20 > All, >=20 > this is to start a two week poll in making >=20 > draft-swallow-mpls-tp-identifiers-02.txt >=20 > an MPLS working group document. >=20 > Send a mail to the mpls-tp@ietf.org mailing list, indicating=20 > "yes/support" or "no/do not support". >=20 > Comments on the content of the draft should be sent to the same=20 > mailing list with a different subject line. >=20 > The poll ends Sun Nov 8. >=20 > /Loa >=20 > MPLS WG co-chair >=20 >=20 > -- >=20 >=20 > Loa Andersson email:=20 > 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 _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From lufang@cisco.com Mon Oct 26 21:21: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 920BE3A67D2; Mon, 26 Oct 2009 21:21:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 nAMwiW7CrXlQ; Mon, 26 Oct 2009 21:21:18 -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 24F593A680C; Mon, 26 Oct 2009 21:21:18 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIQS5kpAZnwM/2dsb2JhbADAOJgDAoQ9BIFf X-IronPort-AV: E=Sophos;i="4.44,630,1249257600"; d="scan'208";a="65053650" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 27 Oct 2009 04:21:31 +0000 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n9R4LViY024210; Tue, 27 Oct 2009 04:21:31 GMT Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 00:21:31 -0400 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, 27 Oct 2009 00:21:30 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] [CCAMP] [mpls-tp] poll ondraft-swallow-mpls-tp-identifiers-02.txt for wg draft Thread-Index: AcpWfeuB1DAoQZ3GTT6PxAgvXRRyqwABFHEAAANTFeAAC0Id8AAAFYUg References: <4AE60B70.6090603@pi.nu> From: "Luyuan Fang (lufang)" To: "Loa Andersson" , , , , X-OriginalArrivalTime: 27 Oct 2009 04:21:31.0311 (UTC) FILETIME=[F5EA8BF0:01CA56BC] Subject: Re: [mpls] [CCAMP] [mpls-tp] poll ondraft-swallow-mpls-tp-identifiers-02.txt for wg draft 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, 27 Oct 2009 04:21:19 -0000 yes/support. Luyuan=20 > -----Original Message----- > From: mpls-tp-bounces@ietf.org > [mailto:mpls-tp-bounces@ietf.org] On Behalf Of Loa Andersson > Sent: 26 October 2009 21:50 > To: mpls-tp@ietf.org; mpls@ietf.org; pwe3@ietf.org; ccamp@ietf.org > Subject: [mpls-tp] poll on > draft-swallow-mpls-tp-identifiers-02.txt for wg draft >=20 > All, >=20 > this is to start a two week poll in making >=20 > draft-swallow-mpls-tp-identifiers-02.txt >=20 > an MPLS working group document. >=20 > Send a mail to the mpls-tp@ietf.org mailing list, indicating=20 > "yes/support" or "no/do not support". >=20 > Comments on the content of the draft should be sent to the same=20 > mailing list with a different subject line. >=20 > The poll ends Sun Nov 8. >=20 > /Loa >=20 > MPLS WG co-chair >=20 >=20 > -- >=20 >=20 > Loa Andersson email:=20 > 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 _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp >=20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From Martin.Vigoureux@alcatel-lucent.com Tue Oct 27 01:57:46 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 204D13A6878; Tue, 27 Oct 2009 01:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 NJrm62HcCZOQ; Tue, 27 Oct 2009 01:57:45 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 2D6113A679C; Tue, 27 Oct 2009 01:57:44 -0700 (PDT) Received: from FRVELSBHS05.ad2.ad.alcatel.com (frvelsbhs05.dc-m.alcatel-lucent.com [155.132.6.77]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n9R8u7g9015234; Tue, 27 Oct 2009 09:57:55 +0100 Received: from [172.27.205.213] ([172.27.205.213]) by FRVELSBHS05.ad2.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Tue, 27 Oct 2009 09:57:20 +0100 Message-ID: <4AE6B5F0.8080000@alcatel-lucent.com> Date: Tue, 27 Oct 2009 09:57:20 +0100 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: mpls@ietf.org References: <4ADA0A95.9070206@alcatel-lucent.com> In-Reply-To: <4ADA0A95.9070206@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 27 Oct 2009 08:57:20.0702 (UTC) FILETIME=[7E1F35E0:01CA56E3] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: mpls-tp@ietf.org Subject: [mpls] REMINDER - Re: Slots requests for MPLS sessions - IETF76 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, 27 Oct 2009 08:57:46 -0000 All, kind reminder following yesterday's submission cut-off. -m Martin Vigoureux a écrit : > all, > > this is a call for presentation slots for mpls sessions. > > We will have two meeting sessions and will split the > overall duration in two parts - mpls and mpls-tp. > > Please send me the requests, with Loa & George in copy > > The IETF meeting agenda is subject to change. > > MPLS Session 1 (2.5 hours) > Monday, Afternoon 1740-1940 > ---------------------------------------------- > MPLS Session 2 (2.5 hours) > Wednesday, 0900-1015 > ---------------------------------------------- > > regards, > martin > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From gregimirsky@gmail.com Tue Oct 27 03:48: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 65C3D3A67E6; Tue, 27 Oct 2009 03:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 DTfBBHXoyKnO; Tue, 27 Oct 2009 03:48:08 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id BF60D3A6774; Tue, 27 Oct 2009 03:48:07 -0700 (PDT) Received: by fxm18 with SMTP id 18so6272fxm.37 for ; Tue, 27 Oct 2009 03:48:17 -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=qBTu+shPZ4I2ELlaRnQGDFySxMCWeBg/OJiP9diFY2Q=; b=lZtErd8mqam9Ct1BmcyObG7SL8xDwNRqHm98qLpsyL9/rC/pCXu09MY/hRuA8UQX+U RjQKPY8zVU6f4arkqK2D3sfyLos3QRR30JF/0DrTtMP8NaN0mdgdM7ryK5o9EYvWwlI6 Nn3yhon3/OQoRoPlDhk5Tb8m6JIfAK8vQM9rM= 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=LQD7Rr7/MNuH/yxSYRWNzO9/9g6QQ9khVuDjk30in7aKyWs7Bdl63Ek3ugBU2zN23Q LVRGq0AoB8oZFpIYxXxVL3jwBRa+fMya4oET8xfFtM8/oPfLdH/VApzDc+nyArDTpohq ykgJjAC6EIhkD42wbN1WsxBbUOPqtIMIUbZzM= MIME-Version: 1.0 Received: by 10.204.154.144 with SMTP id o16mr6535851bkw.213.1256640496861; Tue, 27 Oct 2009 03:48:16 -0700 (PDT) In-Reply-To: <4AE60B70.6090603@pi.nu> References: <4AE60B70.6090603@pi.nu> Date: Tue, 27 Oct 2009 03:48:16 -0700 Message-ID: <787be2780910270348wc847789jf7683ed613782605@mail.gmail.com> From: Greg Mirsky To: Loa Andersson Content-Type: multipart/alternative; boundary=0015175cb40a6d01880476e86a84 Cc: mpls@ietf.org, ccamp@ietf.org, pwe3@ietf.org, "mpls-tp@ietf.org" Subject: Re: [mpls] [CCAMP] poll on draft-swallow-mpls-tp-identifiers-02.txt for wg draft 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, 27 Oct 2009 10:48:09 -0000 --0015175cb40a6d01880476e86a84 Content-Type: text/plain; charset=ISO-8859-1 Yes+support Regards, Greg On Mon, Oct 26, 2009 at 1:49 PM, Loa Andersson wrote: > All, > > this is to start a two week poll in making > > draft-swallow-mpls-tp-identifiers-02.txt > > an MPLS working group document. > > Send a mail to the mpls-tp@ietf.org mailing list, indicating > "yes/support" or "no/do not support". > > Comments on the content of the draft should be sent to the same > mailing list with a different subject line. > > The poll ends Sun Nov 8. > > /Loa > > MPLS WG co-chair > > > -- > > > 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 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > --0015175cb40a6d01880476e86a84 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes+support
Regards,
Greg

On Mon, O= ct 26, 2009 at 1:49 PM, Loa Andersson <loa@pi.nu> wrote:
All,

this is to start a two week poll in making

draft-swallow-mpls-tp-identifiers-02.txt

an MPLS working group document.

Send a mail to the mp= ls-tp@ietf.org mailing list, indicating
"yes/support" or "no/do not support".

Comments on the content of the draft should be sent to the same
mailing list with a different subject line.

The poll ends Sun Nov 8.

/Loa

MPLS WG co-chair


--


Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 email: loa.andersson@eri= csson.com
Sr Strategy and Standards Manager =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
Ericsson Inc =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0phone: +46 = 10 717 52 13
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 +46 767 72 92 13
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ccamp

--0015175cb40a6d01880476e86a84-- From wwwrun@core3.amsl.com Tue Oct 27 08:54: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 65B3B3A6822; Tue, 27 Oct 2009 08:54:27 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20091027155427.65B3B3A6822@core3.amsl.com> Date: Tue, 27 Oct 2009 08:54:27 -0700 (PDT) Cc: mpls@ietf.org Subject: [mpls] Last Call: draft-ietf-mpls-mpls-and-gmpls-security-framework (Security Framework for MPLS and GMPLS Networks) to Informational RFC 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: Tue, 27 Oct 2009 15:54:27 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Security Framework for MPLS and GMPLS Networks ' as an Informational RFC 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-11-18. This last call is extended to encomapss the period of the face-to-face IETF meeting. 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-mpls-and-gmpls-security-framework-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16441&rfc_flag=0 From wwwrun@core3.amsl.com Tue Oct 27 15:24:42 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 A73333A696C; Tue, 27 Oct 2009 15:24:42 -0700 (PDT) From: Greg Jones(ITU-T SG 15) To: stbryant@cisco.com Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20091027222442.A73333A696C@core3.amsl.com> Date: Tue, 27 Oct 2009 15:24:42 -0700 (PDT) Cc: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, malcolm.betts@huawei.com, yoichi.maeda@ntt-at.co.jp, paf@cisco.com, adrian.farrel@huawei.com, rcallon@juniper.net, tsbsg15@itu.int Subject: [mpls] New Liaison Statement, "LS94 - Comments on the MPLS-TP process document available (ref #05.002)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 22:24:42 -0000 Title: LS94 - Comments on the MPLS-TP process document available (ref #05.002) Submission Date: 2009-10-27 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=604 Please reply by 2009-11-30 From: Greg Jones(ITU-T SG 15) To: IETF MPLS liaison representative(stbryant@cisco.com) Cc: paf@cisco.com adrian.farrel@huawei.com rcallon@juniper.net mpls@ietf.org yoichi.maeda@ntt-at.co.jp sjtrowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: malcolm.betts@huawei.com Purpose: For comment Body: Attachment(s): LS94 - Comments on the MPLS-TP process document available (ref #05.002) - pdf (https://datatracker.ietf.org/documents/LIAISON/file720.pdf) From wwwrun@core3.amsl.com Tue Oct 27 15:41:52 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 F121228C0D6; Tue, 27 Oct 2009 15:41:51 -0700 (PDT) From: Greg Jones(ITU-T SG 15) To: dbrungard@att.com, lberger@labn.net, jpv@cisco.com, julien.meuric@orange-ftgroup.com, swallow@cisco.com, loa@pi.nu Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20091027224151.F121228C0D6@core3.amsl.com> Date: Tue, 27 Oct 2009 15:41:51 -0700 (PDT) Cc: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, ccamp@ietf.org, yoichi.maeda@ntt-at.co.jp, george_young@labs.att.com, pce@ietf.org, adrian.farrel@huawei.com, tsbsg15@itu.int, rcallon@juniper.net, paf@cisco.com Subject: [mpls] New Liaison Statement, "LS97 - SG15 OTNT Standardization Work Plan" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 22:41:52 -0000 Title: LS97 - SG15 OTNT Standardization Work Plan Submission Date: 2009-10-27 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=605 Please reply by 2010-04-30 From: Greg Jones(ITU-T SG 15) To: IETF (ccamp, pce and mpls WGs)(dbrungard@att.com,lberger@labn.net,jpv@cisco.com,julien.meuric@orange-ftgroup.com,swallow@cisco.com,loa@pi.nu) Cc: paf@cisco.com adrian.farrel@huawei.com rcallon@juniper.net ccamp@ietf.org pce@ietf.org mpls@ietf.org yoichi.maeda@ntt-at.co.jp sjtrowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: george_young@labs.att.com koike.yoshinori@lab.ntt.co.jp Purpose: For comment Body: Attachment(s): LS97 - SG15 OTNT Standardization Work Plan - pdf (https://datatracker.ietf.org/documents/LIAISON/file721.pdf) LS97 - Draft Revised Optical Transport Networks & Technologies Standardization Work Plan, Issue 12 - pdf (https://datatracker.ietf.org/documents/LIAISON/file722.pdf) From wwwrun@core3.amsl.com Tue Oct 27 15:59:15 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 5D2093A6856; Tue, 27 Oct 2009 15:59:15 -0700 (PDT) From: Greg Jones(ITU-T SG 15) To: swallow@cisco.com,loa@pi.nu Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20091027225915.5D2093A6856@core3.amsl.com> Date: Tue, 27 Oct 2009 15:59:15 -0700 (PDT) Cc: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, malcolm.betts@huawei.com, yoichi.maeda@ntt-at.co.jp, paf@cisco.com, adrian.farrel@huawei.com, rcallon@juniper.net, tsbsg15@itu.int Subject: [mpls] New Liaison Statement, "LS101 - Use of MIP and MEP for fault isolation (ref # 011.01)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Oct 2009 22:59:15 -0000 Title: LS101 - Use of MIP and MEP for fault isolation (ref # 011.01) Submission Date: 2009-10-27 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=607 Please reply by 2009-12-31 From: Greg Jones(ITU-T SG 15) To: IETF mpls Working Group(swallow@cisco.com,loa@pi.nu) Cc: paf@cisco.com adrian.farrel@huawei.com rcallon@juniper.net mpls@ietf.org yoichi.maeda@ntt-at.co.jp sjtrowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: malcolm.betts@huawei.com Purpose: For comment Body: Attachment(s): LS101 - Use of MIP and MEP for fault isolation (ref # 011.01) - pdf (https://datatracker.ietf.org/documents/LIAISON/file724.pdf) From michelg@upperside.fr Wed Oct 28 08:22:44 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 2CEAC3A672E for ; Wed, 28 Oct 2009 08:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.352 X-Spam-Level: X-Spam-Status: No, score=0.352 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] 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 vQ1YZNUXrP5g for ; Wed, 28 Oct 2009 08:22:40 -0700 (PDT) Received: from smtp20.orange.fr (smtp20.orange.fr [80.12.242.27]) by core3.amsl.com (Postfix) with ESMTP id 8815C3A684E for ; Wed, 28 Oct 2009 08:22:38 -0700 (PDT) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2008.orange.fr (SMTP Server) with ESMTP id 5A7D81C00099 for ; Wed, 28 Oct 2009 16:22:51 +0100 (CET) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2008.orange.fr (SMTP Server) with ESMTP id 3FEBA1C000A7 for ; Wed, 28 Oct 2009 16:22:51 +0100 (CET) Received: from nbMichelvst (AAubervilliers-752-1-19-251.w90-61.abo.wanadoo.fr [90.61.50.251]) by mwinf2008.orange.fr (SMTP Server) with ESMTP id D7F5E1C00099 for ; Wed, 28 Oct 2009 16:22:50 +0100 (CET) X-ME-UUID: 20091028152250884.D7F5E1C00099@mwinf2008.orange.fr From: "Michel Gosse" To: Date: Wed, 28 Oct 2009 16:17:33 +0100 Message-ID: <338B193738814CDD9AD20563908CAF0F@UPPERSIDECONFERENCES.COM> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01CA57EA.28106F90" X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6000.16669 Thread-Index: AcpX4cXO/Z966JmUTVuM/60qcwBKtQ== Subject: [mpls] MPLS & Ethernet World Congress 2010 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, 28 Oct 2009 15:22:44 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000F_01CA57EA.28106F90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The 12th edition, of the MPLS & Ethernet World Congress will be organized next February 9/12, 2010 in Paris, Marriott Rive Gauche. Particular attention will be paid this year to MPLS-TP, Aggregation, Multicast Issues and Data Center Interconnection. The continuing success of the MPLS & Ethernet World is largely due to the quality of the technical debates, lead for the last ten years by renowned experts in the fields of Internet and Ethernet broadband. The fourth edition of the Carrier Ethernet Workshop will discuss technological and implementation detailed issues in parallel with the traditional MPLS Tutorial. The workshop will be addressed by the MEF ambassadors for the standardization process review. A second conference called "Ethernet Wholesale" will be organised at the same time, same place and will mainly address mobile backhaul aspects. Get all details on: http://www.upperside.fr/mplsworld2010/mplsworld2010intro.htm ------=_NextPart_000_000F_01CA57EA.28106F90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The 12th edition, of the MPLS & Ethernet World Congress will be organized next February 9/12, = 2010 in Paris, = Marriott Rive Gauche.

Particular attention will be paid this year to = MPLS-TP, Aggregation, = Multicast Issues and Data Center Interconnection.

 

The continuing success of the MPLS & = Ethernet World is largely due to the quality of the technical debates, lead for = the last ten years by renowned experts in the fields of Internet and Ethernet = broadband.

 

The fourth edition of the Carrier Ethernet = Workshop will discuss technological and implementation detailed issues in = parallel with the traditional MPLS Tutorial.
The workshop will be addressed by the MEF ambassadors for the = standardization process review.

 

A second conference called “Ethernet Wholesale” will be = organised at the same time, same place and will mainly address mobile backhaul = aspects.

 

Get all details on: =

htt= p://www.upperside.fr/mplsworld2010/mplsworld2010intro.htm<= /span>

 

 

------=_NextPart_000_000F_01CA57EA.28106F90-- From lmartini@cisco.com Wed Oct 28 15:32: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 4BF933A6989; Wed, 28 Oct 2009 15:32:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[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 9L68KBwqTx7F; Wed, 28 Oct 2009 15:32:23 -0700 (PDT) Received: from napoleon.monoski.com (napoleon.monoski.com [67.41.208.110]) by core3.amsl.com (Postfix) with ESMTP id 7890A3A6809; Wed, 28 Oct 2009 15:32:23 -0700 (PDT) Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.13.8/8.13.8) with ESMTP id n9SMWZgX012840 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Oct 2009 16:32:35 -0600 (MDT) Message-ID: <4AE8C683.5010409@cisco.com> Date: Wed, 28 Oct 2009 16:32:35 -0600 From: Luca Martini User-Agent: Thunderbird 2.0.0.19 (X11/20081209) MIME-Version: 1.0 To: Loa Andersson References: <4AE60B70.6090603@pi.nu> In-Reply-To: <4AE60B70.6090603@pi.nu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.63 on 209.245.27.1 Cc: mpls@ietf.org, ccamp@ietf.org, pwe3@ietf.org, "mpls-tp@ietf.org" Subject: Re: [mpls] [mpls-tp] poll on draft-swallow-mpls-tp-identifiers-02.txt for wg draft 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, 28 Oct 2009 22:32:24 -0000 Yes/Support Luca Loa Andersson wrote: > All, > > this is to start a two week poll in making > > draft-swallow-mpls-tp-identifiers-02.txt > > an MPLS working group document. > > Send a mail to the mpls-tp@ietf.org mailing list, indicating > "yes/support" or "no/do not support". > > Comments on the content of the draft should be sent to the same > mailing list with a different subject line. > > The poll ends Sun Nov 8. > > /Loa > > MPLS WG co-chair > > From cfinss@dial.pipex.com Thu Oct 29 05:21:03 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 630CC28C0D0 for ; Thu, 29 Oct 2009 05:21:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[AWL=0.949, 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 UeQjxkr0cLR5 for ; Thu, 29 Oct 2009 05:21:02 -0700 (PDT) Received: from mk-outboundfilter-1.mail.uk.tiscali.com (mk-outboundfilter-1.mail.uk.tiscali.com [212.74.114.37]) by core3.amsl.com (Postfix) with ESMTP id 0C48928B23E for ; Thu, 29 Oct 2009 05:21:01 -0700 (PDT) X-Trace: 297829935/mk-outboundfilter-1.mail.uk.tiscali.com/PIPEX/$PIPEX-ACCEPTED/pipex-customers/62.188.100.78/None/cfinss@dial.pipex.com X-SBRS: None X-RemoteIP: 62.188.100.78 X-IP-MAIL-FROM: cfinss@dial.pipex.com X-SMTP-AUTH: X-MUA: Microsoft Outlook Express 6.00.2800.1106Produced By Microsoft MimeOLE V6.00.2800.1106 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuAEABcl6Uo+vGRO/2dsb2JhbACDIicaAo09rhmdJAqEMwQ X-IronPort-AV: E=Sophos;i="4.44,645,1249254000"; d="scan'208";a="297829935" X-IP-Direction: IN Received: from 1cust78.tnt1.lnd9.gbr.da.uu.net (HELO allison) ([62.188.100.78]) by smtp.pipex.tiscali.co.uk with SMTP; 29 Oct 2009 12:17:43 +0000 Message-ID: <000601ca5889$0d0e8660$0601a8c0@allison> From: "tom.petch" To: References: <20091027222442.A73333A696C@core3.amsl.com> Date: Thu, 29 Oct 2009 12:09:39 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Cc: mpls@ietf.org, adrian.farrel@huawei.com Subject: Re: [mpls] New Liaison Statement, "LS94 - Comments on the MPLS-TP process document available (ref #05.002)" X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "tom.petch" List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2009 12:21:03 -0000 Greg Fascinating little footnote in the middle of this liaison, one that I have not noticed before, to whit: " Attention: Some or all of the material attached to this liaison statement may be subject to ITU copyright. In such a case this will be indicated in the individual document. Such a copyright does not prevent the use of the material for its intended purpose, but it prevents the reproduction of all or part of it in a publication without the authorization of ITU." I see no such indication but if there ever were one, I think that this would stop us incorporating such material in an I-D, no matter which flavour of RFC5378/TLP text we include. (The IETF expects all Contributions in whatever format to be given with the Rights called for in RFC5378). I hope that this is purely a hypothetical situation. Tom Petch ----- Original Message ----- From: "Greg Jones (ITU-T SG 15)" To: Cc: ; ; ; ; ; ; ; ; Sent: Tuesday, October 27, 2009 11:24 PM Subject: [mpls] New Liaison Statement, "LS94 - Comments on the MPLS-TP process document available (ref #05.002)" > Title: LS94 - Comments on the MPLS-TP process document available (ref #05.002) > Submission Date: 2009-10-27 > URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=604 > Please reply by 2009-11-30 > > From: Greg Jones(ITU-T SG 15) > To: IETF MPLS liaison representative(stbryant@cisco.com) > Cc: paf@cisco.com;adrian.farrel@huawei.com;rcallon@juniper.net; > mpls@ietf.org;yoichi.maeda@ntt-at.co.jp;sjtrowbridge@alcatel-lucent.com > Reponse Contact: tsbsg15@itu.int;greg.jones@itu.int;hiroshi.ota@itu.int > > Technical Contact: malcolm.betts@huawei.com > Purpose: For comment > Body: > Attachment(s): > LS94 - Comments on the MPLS-TP process document available (ref #05.002) - pdf (https://datatracker.ietf.org/documents/LIAISON/file720.pdf) > > { file:///D:/Articles/file720.pdf } From david.charlap@ericsson.com Thu Oct 29 11:16:12 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 BD8DD3A6927 for ; Thu, 29 Oct 2009 11:16:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 zQDZNtEcsr0P for ; Thu, 29 Oct 2009 11:16:11 -0700 (PDT) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by core3.amsl.com (Postfix) with ESMTP id BAF263A67E2 for ; Thu, 29 Oct 2009 11:16:11 -0700 (PDT) Received: from eusrcmw751.eamcs.ericsson.se (eusrcmw751.exu.ericsson.se [138.85.77.51]) by imr2.ericy.com (8.13.1/8.13.1) with ESMTP id n9TIGR6Z022403 for ; Thu, 29 Oct 2009 13:16:27 -0500 Received: from eusrcmw750.eamcs.ericsson.se ([138.85.77.50]) by eusrcmw751.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 13:16:18 -0500 Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by eusrcmw750.eamcs.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Oct 2009 13:16:18 -0500 Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.35]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Thu, 29 Oct 2009 14:16:18 -0400 From: David Charlap To: IETF MPLS List Date: Thu, 29 Oct 2009 14:16:17 -0400 Thread-Topic: ECMP and RFC 4379 Thread-Index: AcpYw+gp3ORTOST1Qg6M/fEnrWEaaw== Message-ID: <6B5AD5FFF3CEE44BA14D9BEBC990CC2E0115013155@EUSAACMS0701.eamcs.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_6B5AD5FFF3CEE44BA14D9BEBC990CC2E0115013155EUSAACMS0701e_" MIME-Version: 1.0 X-OriginalArrivalTime: 29 Oct 2009 18:16:18.0609 (UTC) FILETIME=[E9193210:01CA58C3] Subject: [mpls] ECMP and RFC 4379 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, 29 Oct 2009 18:17:56 -0000 --_000_6B5AD5FFF3CEE44BA14D9BEBC990CC2E0115013155EUSAACMS0701e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In section 4.1 of RFC 4379, it discusses equal-cost multi-path (ECMP) in th= e context of MPLS. I am familiar with the concept of ECMP for a traditional IP forwarder - the= route table contains multiple next-hops for a prefix and the forwarder sel= ects one on a per-packet basis, using some kind of hash to ensure that indi= vidual flows follow a single path, to prevent out-of-order delivery as much= as possible. I don't remember any discussion of this within the context of MPLS. I am a= ware of the concept of point-to-multipoint LSPs, but these are multicast co= nstructs, not ECMP. When a cross-connect has multiple out-segments, matchi= ng traffic is forwarded on all of those out-segments. I don't know of any = situation where the forwarder would select only one out-segment for forward= ing. Ditto for signaling protocols. I'm aware of the RFCs for supporting multic= ast LSPs with RSVP-TE and LDP, but I am unaware of any work to implement EC= MP within a single LSP. The idea of using multiple LSPs (tunnel instances,= etc.) for load balancing is fairly straightforward, but that's not what EC= MP implies. So, my question is: What is section 4.1 of RFC 4379 really referring to? I= f it is talking about a single LSP following multiple paths with an MPLS fo= rwarder implementing ECMP behavior, are there any drafts or RFCs describing= this behavior or how signaling protocols are expected to support it? Thanks in advance. -- David --_000_6B5AD5FFF3CEE44BA14D9BEBC990CC2E0115013155EUSAACMS0701e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
In sectio= n 4.1 of=20 RFC 4379, it discusses equal-cost multi-path (ECMP) in the context of=20 MPLS.
 
I am fami= liar with=20 the concept of ECMP for a traditional IP forwarder - the route table contai= ns=20 multiple next-hops for a prefix and the forwarder selects one on a per-pack= et=20 basis, using some kind of hash to ensure that individual flows follow a sin= gle=20 path, to prevent out-of-order delivery as much as possible.
 
I don't r= emember any=20 discussion of this within the context of MPLS.  I am aware of the conc= ept=20 of point-to-multipoint LSPs, but these are multicast constructs, not ECMP.&= nbsp;=20 When a cross-connect has multiple out-segments, matching traffic is forward= ed on=20 all of those out-segments.  I don't know of any situation where the=20 forwarder would select only one out-segment for forwarding.
 
Ditto for= signaling=20 protocols.  I'm aware of the RFCs for supporting multicast LSPs with=20 RSVP-TE and LDP, but I am unaware of any work to implement ECMP within = ;a=20 single LSP.  The idea of using multiple LSPs (tunnel instances, etc.) = for=20 load balancing is fairly straightforward, but that's not what ECMP=20 implies.
 
So, my qu= estion is:=20 What is section 4.1 of RFC 4379 really referring to?  If it is talking= =20 about a single LSP following multiple paths with an MPLS forwarder implemen= ting=20 ECMP behavior, are there any drafts or RFCs describing this behavior or how= =20 signaling protocols are expected to support it?
 
Thanks in= =20 advance.
 
--=20 David
 
--_000_6B5AD5FFF3CEE44BA14D9BEBC990CC2E0115013155EUSAACMS0701e_-- From vishwas.ietf@gmail.com Thu Oct 29 11:26:34 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 EFDEF3A6A0F for ; Thu, 29 Oct 2009 11:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 11dTwojQO0km for ; Thu, 29 Oct 2009 11:26:32 -0700 (PDT) Received: from mail-gx0-f212.google.com (mail-gx0-f212.google.com [209.85.217.212]) by core3.amsl.com (Postfix) with ESMTP id 6C14F3A697C for ; Thu, 29 Oct 2009 11:26:32 -0700 (PDT) Received: by gxk4 with SMTP id 4so681653gxk.8 for ; Thu, 29 Oct 2009 11:26:45 -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 :content-transfer-encoding; bh=wHWyheSI+roO1ewSo0JTqtGv8G16fVHlq/EfiYUYEr0=; b=SqwXhKC5luFGST+bQw9cQDERNmV8pLt40++wBKpJ1C/RCE6sRVdvcgYXkN4WSzcUzY zP8I9wWRua1NCw0RDAlbKCQNKcQT/EyWKJly76GaYnUt1ftpnYCyQztNNWlvAQ4dJNph 2fe9CNj49a7qhg5XIEEU0dNjgOf3gM9K3egXA= 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:content-transfer-encoding; b=l8Y7fzaxgjNmHrBq6bbN1e0kTIoj/JJEvBapDfujOWH6bjqFUwhjQGZjNMatJOpb6J JAVHZ1JMdcyB+S6BAWHy8yees8f5NUwRtUgm4uYnECYGUa9BIjkpa1rYF2Cg+HPJxaEy Bktj0WUau/W3dsmtBFg+RxtmJBSvQ+r0M+QQA= MIME-Version: 1.0 Received: by 10.150.101.5 with SMTP id y5mr969277ybb.85.1256840805062; Thu, 29 Oct 2009 11:26:45 -0700 (PDT) In-Reply-To: <6B5AD5FFF3CEE44BA14D9BEBC990CC2E0115013155@EUSAACMS0701.eamcs.ericsson.se> References: <6B5AD5FFF3CEE44BA14D9BEBC990CC2E0115013155@EUSAACMS0701.eamcs.ericsson.se> Date: Thu, 29 Oct 2009 11:26:45 -0700 Message-ID: <77ead0ec0910291126p160566b0vf716385948d6f046@mail.gmail.com> From: Vishwas Manral To: David Charlap Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: IETF MPLS List Subject: Re: [mpls] ECMP and RFC 4379 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, 29 Oct 2009 18:26:34 -0000 Hi David, > When a cross-connect has multiple out-segments, > matching traffic is forwarded on all of those out-segments. I don't know= of > any situation where the forwarder would select only one out-segment for > forwarding. In the MPLS ECMP case, just like all other ECMP cases (IP ECMP etc) the packet is sent on one of the paths based on the fact that we do not reorder flows. There should be no change to LDP signalling for the same. I do not think there are any drafts for the same. Thanks, Vishwas On Thu, Oct 29, 2009 at 11:16 AM, David Charlap wrote: > In section 4.1 of RFC 4379, it discusses equal-cost multi-path (ECMP) in = the > context of MPLS. > > I am familiar with the concept of ECMP for a traditional IP forwarder - t= he > route table contains multiple next-hops for a prefix and the forwarder > selects one on a per-packet basis, using some kind of hash to ensure that > individual flows follow a single path, to prevent out-of-order delivery a= s > much as possible. > > I don't remember any discussion of this within the context of MPLS.=A0 I = am > aware of the concept of point-to-multipoint LSPs, but these are multicast > constructs, not ECMP.=A0 When a cross-connect has multiple out-segments, > matching traffic is forwarded on all of those out-segments.=A0 I don't kn= ow of > any situation where the forwarder would select only one out-segment for > forwarding. > > Ditto for signaling protocols.=A0 I'm aware of the RFCs for supporting > multicast LSPs with RSVP-TE and LDP, but I am unaware of any work to > implement ECMP within=A0a single LSP.=A0 The idea of using multiple LSPs = (tunnel > instances, etc.) for load balancing is fairly straightforward, but that's > not what ECMP implies. > > So, my question is: What is section 4.1 of RFC 4379 really referring to?= =A0 If > it is talking about a single LSP following multiple paths with an MPLS > forwarder implementing ECMP behavior, are there any drafts or RFCs > describing this behavior or how signaling protocols are expected to suppo= rt > it? > > Thanks in advance. > > -- David > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > From erosen@cisco.com Fri Oct 30 07:42:38 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 B08AA3A6AA2 for ; Fri, 30 Oct 2009 07:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[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 IfF3wAnPmHu2 for ; Fri, 30 Oct 2009 07:42:37 -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 60D783A69B9 for ; Fri, 30 Oct 2009 07:42:37 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.44,653,1249257600"; d="scan'208";a="65719538" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 30 Oct 2009 14:42:54 +0000 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 n9UEgsfc024747; Fri, 30 Oct 2009 14:42:54 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 n9UEgrYd019677; Fri, 30 Oct 2009 10:42:53 -0400 To: mpls@ietf.org Date: Fri, 30 Oct 2009 10:42:53 -0400 Message-ID: <19676.1256913773@erosen-linux> From: Eric Rosen Subject: [mpls] Last Call comments on ldp upstream label allocation 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: Fri, 30 Oct 2009 14:42:38 -0000 I have a couple of comments on draft-ietf-mpls-ldp-upstream-04. The draft has a normative reference to RFC 3472 "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Constraint-based Routed Label Distribution Protocol (CR-LDP) Extensions". I don't think this is allowable, as we do not want to take any action that prevents the deprecated CR-LDP documents from being reclassified as historic. Section 4.3 of RFC 3468 "The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols" says: Consequently we need to keep CR-LDP referenceable, i.e., on the standards track, for the foreseeable future. The implication of this is not that we need to progress it further, or need to undertake further work in the area. One implication however is that standards organizations which reference the document, need to be notified of our decision so that they (at their own pace) can change their references to more appropriate documents. I would interpret this as implying that the IETF should not be creating normative references to CR-LDP documents. (If we expect other organizations to be changing their references to the CR-LDP documents, we shouldn't be creating new references to them.) Note that RFC 3468 explicitly calls out RFC 3472 as one of the deprecated documents. The normative reference is due to the draft's reuse of the "Interface ID TLV" defined in RFC 3472. If this TLV is to be used, it would be better to define it in the ldp-upstream draft and to have IANA change the reference in the iana.org registry. However, it is questionable whether the Interface ID TLV is really the right TLV for ldp-upstream to use, as the interface ID TLV has fields that are do not appear to be needed in ldp-upstream (e.g., "next/previous hop", "logical inteface id"). One more comment: the "LDP Tunnel Identifiers" defined in section 5 of ldp-upstream do not appear to be exactly the same in all cases as the "PMSI Tunnel Attribute Tunnel Identifiers" defined in section 5 of draft-ietf- l3vpn-2547bis-mcast-bgp-08.txt. (E.g., the means of identification of RSVP-TE tunnels seems to be different.) Perhaps ldp-upstream should simply reference the PMSI tunnel attribute tunnel ids defined in the latter document.