From mpls-bounces@ietf.org Wed Jul 2 08:35:53 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 41E533A6916; Wed, 2 Jul 2008 08:35:53 -0700 (PDT) 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 D64103A6916; Wed, 2 Jul 2008 08:35:51 -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 4llzFDFwSua0; Wed, 2 Jul 2008 08:35:51 -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 E32AE3A687E; Wed, 2 Jul 2008 08:35:50 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,738,1204502400"; d="scan'208";a="12987614" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 02 Jul 2008 15:36:00 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m62Fa07C023360; Wed, 2 Jul 2008 11:36:00 -0400 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m62Fa08N022073; Wed, 2 Jul 2008 15:36:00 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 m62FZxoi021540; Wed, 2 Jul 2008 11:35:59 -0400 To: iesg@ietf.org In-reply-to: Your message of Tue, 01 Jul 2008 13:45:01 -0700. <20080701204501.E853C3A6BB5@core3.amsl.com> Date: Wed, 02 Jul 2008 11:35:59 -0400 Message-ID: <21539.1215012959@erosen-linux> From: Eric Rosen DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=291; t=1215012960; x=1215876960; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=erosen@cisco.com; z=From:=20Eric=20Rosen=20 |Subject:=20Re=3A=20WG=20Review=3A=20Recharter=20of=20Multi protocol=20Label=20Switching=20(mpls)=20 |Sender:=20 |To:=20iesg@ietf.org; bh=PR1B3Ub6cPUItCKPzwwUVIWj1fHdsjya+bvOdi53B3A=; b=euhJ2W6+7PRaJEtqr5CCbZF5I3frjXSxCeHA+5amYDycZgiBkdPU+7e8OX L6R6QB5PeE21LdjyGcervtYvSdMJg3hUF5xm6+zm9g1q8c9iA9saSwQKmGQK +YMyJ58O3P; Authentication-Results: rtp-dkim-1; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: mpls@ietf.org Subject: Re: [mpls] WG Review: Recharter of Multiprotocol Label Switching (mpls) 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org > - Define requirements, mechanisms and protocol extensions for > point-to-multipoint (P2MP) MPLS Should be P2MP and MP2MP (multipoint-to-multipoint) MPLS; we wouldn't want to suddenly find out that half of draft-ietf-mpls-ldp-p2mp is "out of charter" ;-) _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Jul 2 09:58:34 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A8073A6916; Wed, 2 Jul 2008 09:58:34 -0700 (PDT) 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 941523A6916 for ; Wed, 2 Jul 2008 09:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 2oOURwfV6gak for ; Wed, 2 Jul 2008 09:58:31 -0700 (PDT) Received: from av10-2-sn2.hy.skanova.net (av10-2-sn2.hy.skanova.net [81.228.8.182]) by core3.amsl.com (Postfix) with ESMTP id A0FE13A684B for ; Wed, 2 Jul 2008 09:58:31 -0700 (PDT) Received: by av10-2-sn2.hy.skanova.net (Postfix, from userid 502) id 9910338037; Wed, 2 Jul 2008 18:40:57 +0200 (CEST) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av10-2-sn2.hy.skanova.net (Postfix) with ESMTP id 5E38638037; Wed, 2 Jul 2008 18:40:57 +0200 (CEST) Received: from [127.0.0.1] (h133n2fls33o883.telia.com [217.208.62.133]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 33D9537E45; Wed, 2 Jul 2008 18:40:57 +0200 (CEST) Message-ID: <486BAF8A.1010706@pi.nu> Date: Wed, 02 Jul 2008 18:40:42 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: ietf , mpls@ietf.org Subject: [mpls] [ Re: WG Review: Recharter of Multiprotocol Label Switching (mpls)] 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Eric, Eric Rosen wrote: >> - Define requirements, mechanisms and protocol extensions for >> point-to-multipoint (P2MP) MPLS > > Should be P2MP and MP2MP (multipoint-to-multipoint) MPLS; we wouldn't want > to suddenly find out that half of draft-ietf-mpls-ldp-p2mp is "out of > charter" ;-) What I (with the wg chair hat on) think this is about is to add the piece about mpls-tp to the mpls wg charter. We've discussed in the wg and have wg consensus to do that. A couple of milestones are also being changed. Having said that, I'm also of the opinion that we need a major revision of the mpls wg charter, e.g. for the reasons Eric discusses above. However, that process needs to start in the working and have wg consensus when we ask the IESG for the update. I can see that it will be necessary to start process during the autumn. /Loa > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.nu loa@pi.nu _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Jul 3 11:15:03 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7249B3A6CFD; Thu, 3 Jul 2008 11:15:03 -0700 (PDT) X-Original-To: mpls@lists.ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9318D3A6AB5; Thu, 3 Jul 2008 11: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: <20080703181501.9318D3A6AB5@core3.amsl.com> Date: Thu, 3 Jul 2008 11:15:01 -0700 (PDT) Cc: mpls@lists.ietf.org Subject: [mpls] I-D ACTION:draft-ietf-mpls-fastreroute-mib-09.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: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org --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 (MPLS) Traffic Engineering Management Information Base for Fast Reroute Author(s) : R. Cetin, T. Nadeau, K. Koushik Filename : draft-ietf-mpls-fastreroute-mib-09.txt Pages : 45 Date : 2008-6-27 This memo defines a portion of the Management Information Base for use with network management protocols in the Internet community. In particular, it describes managed objects used to support two fast reroute (FRR) methods for Multiprotocol Label Switching (MPLS) based traffic engineering (TE). The two methods are one-to-one backup method and facility backup method. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-fastreroute-mib-09.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-fastreroute-mib-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-7-3110624.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@ietf.org Fri Jul 4 04:45:03 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFBCC3A6929; Fri, 4 Jul 2008 04:45:03 -0700 (PDT) X-Original-To: mpls@lists.ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 5E6383A6929; Fri, 4 Jul 2008 04:45: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: <20080704114502.5E6383A6929@core3.amsl.com> Date: Fri, 4 Jul 2008 04:45:02 -0700 (PDT) Cc: mpls@lists.ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-cosfield-def-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: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org --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 : "EXP field" renamed to "CoS Field" Author(s) : L. Andersson Filename : draft-ietf-mpls-cosfield-def-03.txt Pages : 16 Date : 2008-07-04 The early MPLS documents defined the form of the MPLS Label Stack entry. This include a three bit field called the "EXP field". The exact use of this field was not defined by these documents, except to state that it was to be "reserved for experimental use". Although the intended use of the EXP field was as a "Class of Service" field, it was not named the "Class of Service" (CoS) field by these early documents because the use of such a CoS field was not considered to be sufficiently defined. Today a number of standards documents define its usage as a CoS field. . To avoid misunderstanding about how this field may be used, this document changes the name of the field to the "CoS field". In doing so it also updates documents that define the current use of the EXP this field. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-cosfield-def-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-cosfield-def-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-04043305.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@ietf.org Fri Jul 4 05:06:56 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3002A3A6CEA; Fri, 4 Jul 2008 05:06:56 -0700 (PDT) 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 1351E3A69A4 for ; Fri, 4 Jul 2008 05:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 B6yE45AnXjZa for ; Fri, 4 Jul 2008 05:06:54 -0700 (PDT) Received: from av9-1-sn2.hy.skanova.net (av9-1-sn2.hy.skanova.net [81.228.8.179]) by core3.amsl.com (Postfix) with ESMTP id 2D7A13A6CE5 for ; Fri, 4 Jul 2008 05:06:53 -0700 (PDT) Received: by av9-1-sn2.hy.skanova.net (Postfix, from userid 502) id 17BAE38224; Fri, 4 Jul 2008 14:07:01 +0200 (CEST) Received: from smtp4-1-sn2.hy.skanova.net (smtp4-1-sn2.hy.skanova.net [81.228.8.92]) by av9-1-sn2.hy.skanova.net (Postfix) with ESMTP id D23AC381FA for ; Fri, 4 Jul 2008 14:07:00 +0200 (CEST) Received: from [127.0.0.1] (h133n2fls33o883.telia.com [217.208.62.133]) by smtp4-1-sn2.hy.skanova.net (Postfix) with ESMTP id 8BD6537E45 for ; Fri, 4 Jul 2008 14:06:59 +0200 (CEST) Message-ID: <486E1253.9020100@pi.nu> Date: Fri, 04 Jul 2008 14:06:43 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: mpls@ietf.org Subject: [mpls] the version of draft-ietf-mpls-cosfield-def-03 that just has been updated ... 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org ... addresses all the last call comments. - I've added new test that explicitly updates the Figure 1 in rfc 3032 - I've added an updates field in the header (didn't know that that was possible for IDs), but worked just fine - added the three RFCs that are explicitly changed by this document to the update tag - also added all the RFC that I could find that reference the EXP filed (thanks Adrian to help finding them) - added a "blanket paragraph" that says that any RFCs the earlier been referencing the EXP field form now on will be referencing the CoS field With that I think this is ready to become a RFC on the standards track. Could my co-chair please fill in the right information in the right form and send it to the IESG for review. /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.nu _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Sun Jul 6 16:45:29 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCF1A3A6964; Sun, 6 Jul 2008 16:45:13 -0700 (PDT) X-Original-To: mpls@lists.ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6B7A33A690F; Sun, 6 Jul 2008 16: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: <20080706234501.6B7A33A690F@core3.amsl.com> Date: Sun, 6 Jul 2008 16:45:01 -0700 (PDT) Cc: mpls@lists.ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-explicit-resource-control-bundle-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: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org --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 : Component Link Recording and Resource Control for TE Link Bundles Author(s) : I. Property Filename : draft-ietf-mpls-explicit-resource-control-bundle-04.txt Pages : 12 Date : 2008-07-06 Record Route is a useful administrative tool that has been used extensively by the service providers. However, when TE links are bundled, identification of label resource in Record Route Object (RRO) is not enough for the administrative purpose. Network service A.Zamfir et al. - Expires Janury 2009 [page 1] Component Link Record. & Resource Control for TE Link Bundles Jul.2008 providers would like to know the component link within a TE link that is being used by a given LSP. In other words, when link bundling is used, resource recording requires mechanisms to specify the component link identifier, along with the TE link identifier and Label. As it is not possible to record component link in the RRO, this draft defines the extensions to RSVP-TE [RFC3209] and [RFC3473] to specify component link identifiers for resource recording purposes. This draft also defines the Explicit Route Object (ERO) counterpart of the RRO extension. The ERO extensions are needed to perform explicit label/ resource control over bundled TE link. Hence, this document defines the extensions to RSVP-TE [RFC3209] and [RFC3473] to specify component link identifiers for explicit resource control and recording over TE link bundles. Conventions used in this document 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 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-explicit-resource-control-bundle-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-explicit-resource-control-bundle-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-06163024.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@ietf.org Sun Jul 6 22:30:03 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA7A53A69BF; Sun, 6 Jul 2008 22:30:03 -0700 (PDT) X-Original-To: mpls@lists.ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id B1A8D3A69E5; Sun, 6 Jul 2008 22: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: <20080707053001.B1A8D3A69E5@core3.amsl.com> Date: Sun, 6 Jul 2008 22:30:01 -0700 (PDT) Cc: mpls@lists.ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-ldp-end-of-lib-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : LDP End-of-LIB Author(s) : R. Asati, et al. Filename : draft-ietf-mpls-ldp-end-of-lib-00.txt Pages : 11 Date : 2008-07-06 There are situations following LDP session establishment where it would be useful for an LDP speaker to know when its peer has advertised all of its labels. These include session establishment when LDP-IGP sync is in use, as well as session re-establishment following loss of an LDP session when LDP graceful restart is in use. The LDP specification [RFC5036] provides no mechanism for an LDP speaker to notify a peer when it has completed its initial label advertisements to that peer. This document specifies means for an LDP speaker to signal completion of its initial label advertisements following session establishment. 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 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-end-of-lib-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-mpls-ldp-end-of-lib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-06221805.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@ietf.org Mon Jul 7 01:40:25 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47F0E3A680A; Mon, 7 Jul 2008 01:40:25 -0700 (PDT) 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 D080D3A680A for ; Mon, 7 Jul 2008 01:40:23 -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 YDAGH7cKcpMd for ; Mon, 7 Jul 2008 01:40:23 -0700 (PDT) Received: from neo.viciousnest.net (neo.viciousnest.net [192.71.80.124]) by core3.amsl.com (Postfix) with ESMTP id BA59F3A67E6 for ; Mon, 7 Jul 2008 01:40:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by neo.viciousnest.net (Postfix) with ESMTP id E887D2857A; Mon, 7 Jul 2008 10:40:27 +0200 (CEST) Received: from neo.viciousnest.net ([127.0.0.1]) by localhost (neo [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07117-09; Mon, 7 Jul 2008 10:40:24 +0200 (CEST) Received: from [127.0.0.1] (pat.acreo.se [217.151.195.214]) by neo.viciousnest.net (Postfix) with ESMTP id 25BD228577; Mon, 7 Jul 2008 10:40:24 +0200 (CEST) Message-ID: <4871D66E.20609@pi.nu> Date: Mon, 07 Jul 2008 10:40:14 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: mpls@ietf.org, George Swallow References: <486E1253.9020100@pi.nu> In-Reply-To: <486E1253.9020100@pi.nu> X-Virus-Scanned: by amavisd-new at viciousnest.net Subject: Re: [mpls] the version of draft-ietf-mpls-cosfield-def-03 that just has been updated ... 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org All, a couple of things happened that effects this document - I received a number of good comments after the last call, I will update and republish - I talked to one of the tsvwg chairs and we agreed that it was a good idea to last call it in the tsvwg also, since we update their RFCs - our ADs included this as one of the mpls-tp documents, so I will treat accordingly, thus the last call will include mpls ccamp, pwe3 and l2vpn in the IETF and some group on the ITU-T side (need to confirm where to send it). - this document will be a test case on including ITU-T in wg last calls. They are supposed to respond with a liaison as an organization, but we might also see individual ITU-T participants respond to our mailing-lists. /Loa Loa Andersson wrote: > > ... addresses all the last call comments. > > - I've added new test that explicitly updates the Figure 1 in rfc 3032 > - I've added an updates field in the header (didn't know that that was > possible for IDs), but worked just fine > - added the three RFCs that are explicitly changed by this document to > the update tag > - also added all the RFC that I could find that reference the EXP filed > (thanks Adrian to help finding them) > - added a "blanket paragraph" that says that any RFCs the earlier been > referencing the EXP field form now on will be referencing the > CoS field > > > With that I think this is ready to become a RFC on the standards track. > > Could my co-chair please fill in the right information in the right > form and send it to the IESG for review. > > /Loa > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.nu _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Jul 7 08:28:48 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 189733A68DD; Mon, 7 Jul 2008 08:28:48 -0700 (PDT) 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 29F1E3A68DD for ; Mon, 7 Jul 2008 08:28:47 -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 DjYfBviDB2np for ; Mon, 7 Jul 2008 08:28:46 -0700 (PDT) Received: from smtp2.dataconnection.com (smtp2.dataconnection.com [192.91.191.8]) by core3.amsl.com (Postfix) with ESMTP id 265D83A6816 for ; Mon, 7 Jul 2008 08:28:45 -0700 (PDT) Received: from enfimail2.datcon.co.uk ([172.18.10.19]) by smtp2.dataconnection.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Jul 2008 16:28:51 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 7 Jul 2008 16:28:50 +0100 Message-ID: <8AC1AD08D396174DBC4E6D44EFACCFB105D6C6AE@enfimail2.datcon.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 4875 problems thread-index: AcjgRihgfmLbj7bAR/aZmy/hW7J4BQ== From: "Nic Neate" To: X-OriginalArrivalTime: 07 Jul 2008 15:28:51.0767 (UTC) FILETIME=[28D88470:01C8E046] Subject: [mpls] RFC 4875 problems 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Hi all, We've just kicked off development of P2MP LSPs in our portable RSVP stack. I'm about to fire off four emails raising queries and possible issues in the RFC 4875 protocol specification. They cover the subjects listed below. See following emails for a proper discussion of each. 1) The P2MP re-merge logic can be triggered by sub-group re-optimization, resulting in data loss. 2) Notify address re-writing at transit LSRs in P2MP LSPs makes Notify messages ineffective for reporting LSR failure. 3) Queries on one-to-one fast reroute behavior for P2MP protected LSPs. - Backup path identifiers are not clear - I can read two non-interoperating interpretations. - Not clear whether P2MP backup LSPs are allowed. - Not clear whether sub-group re-optimization for protected LSPs is allowed. 4) Explicit routing queries. - Explicit labels may require two S2L sub-LSPs to use different labels over parallel hops, with complexities in ERO compression and Resv signaling. - ERO/SERO compression details are ambiguous, some interpretations would not interwork. If anyone has answers to these problems, or an interest in solving them, please let me know. I should be there in Dublin if anyone would like to discuss them. Thanks, Nic Neate Data Connection Ltd. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Jul 7 08:31:28 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B049F3A6A3C; Mon, 7 Jul 2008 08:31:28 -0700 (PDT) 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 7EBEF3A6915 for ; Mon, 7 Jul 2008 08:31:27 -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 GrVPEC9yo2hY for ; Mon, 7 Jul 2008 08:31:26 -0700 (PDT) Received: from smtp2.dataconnection.com (smtp2.dataconnection.com [192.91.191.8]) by core3.amsl.com (Postfix) with ESMTP id 4A4043A6816 for ; Mon, 7 Jul 2008 08:31:26 -0700 (PDT) Received: from enfimail2.datcon.co.uk ([172.18.10.19]) by smtp2.dataconnection.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Jul 2008 16:31:32 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 7 Jul 2008 16:31:31 +0100 Message-ID: <8AC1AD08D396174DBC4E6D44EFACCFB105D6C6BB@enfimail2.datcon.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 4875 re-merge procedures (section 18) thread-index: AcjgRogINfBEuGVLScusuh+t/1eyTQ== From: "Nic Neate" To: X-OriginalArrivalTime: 07 Jul 2008 15:31:32.0107 (UTC) FILETIME=[886A75B0:01C8E046] Subject: [mpls] RFC 4875 re-merge procedures (section 18) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Hi all, Section 18 the RFC 4875 (http://tools.ietf.org/html/rfc4875#section-18) defines the procedures for an LSR that receives multiple Path messages for the same P2MP LSP from different PHOPs. The intention is to prevent data duplication in that scenario. I think the procedures in the RFC are insufficient for the following reasons. The key point here is that an LSR following the procedures defined in the RFC may cause data loss during sub-group re-optimization. - Section 18 discusses dynamic reroute and make-before-break but not sub-group re-optimization. The latter (defined in section 14.2) is another case where an LSR could receive multiple Path messages for the same P2MP LSP from different PHOPs. - LSRs are told to differentiate re-merge and cross-over cases from dynamic reroute by checking whether the sets of S2L sub-LSPs in the upstream Path messages overlap. If they do not then it is re-merge/cross-over (see section 18.1 paragraph 2). However, both dynamic reroute and sub-group re-optimization could cause an LSR to receive a new Path message containing a set of S2L sub-LSPs that does not overlap with its existing path state. Consider the case where re-optimization causes an LSR to become on the path for one S2L sub-LSP and be removed from the path of another S2L sub-LSP. - Having falsely identified a sub-group re-optimization (or dynamic reroute) as a re-merge, an LSR may (if so configured) send a PathErr for its existing path state with the Path_State_Removed flag set (section 18.1.1). That will cause data loss if the new, re-optimized sub-tree has not yet been fully set up. - Finally, as a separate point, it's worth noting that if the downstream interfaces for two Path messages are the same, but the downstream labels are not, then that is cross-over rather than re-merge and needs to be handled as such. That case is omitted by the RFC, which only discusses downstream interfaces (section 18.1 paragraph 3). I'd appreciate comments on whether this is indeed a problem that needs solving. (If it is then I have some ideas on how that might be achieved.) Thanks, Nic Neate Data Connection Ltd. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Jul 7 08:32:25 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E287B3A6A35; Mon, 7 Jul 2008 08:32:24 -0700 (PDT) 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 8D1623A6A35 for ; Mon, 7 Jul 2008 08:32:24 -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 idbrAcwbxMxv for ; Mon, 7 Jul 2008 08:32:23 -0700 (PDT) Received: from smtp2.dataconnection.com (smtp2.dataconnection.com [192.91.191.8]) by core3.amsl.com (Postfix) with ESMTP id 185053A690A for ; Mon, 7 Jul 2008 08:32:22 -0700 (PDT) Received: from enfimail2.datcon.co.uk ([172.18.10.19]) by smtp2.dataconnection.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Jul 2008 16:32:28 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 7 Jul 2008 16:32:28 +0100 Message-ID: <8AC1AD08D396174DBC4E6D44EFACCFB105D6C6C0@enfimail2.datcon.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 4875 Notify forwarding by transit LSRs (section 8.1) thread-index: AcjgRqoGNfexs2GtRey52AvwH8BWbQ== From: "Nic Neate" To: X-OriginalArrivalTime: 07 Jul 2008 15:32:28.0887 (UTC) FILETIME=[AA426670:01C8E046] Subject: [mpls] RFC 4875 Notify forwarding by transit LSRs (section 8.1) 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: , Content-Type: multipart/mixed; boundary="===============0769876036==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org This is a multi-part message in MIME format. --===============0769876036== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8E046.AA3C3250" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8E046.AA3C3250 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, This is the second potential problem in RFC 4875 I'd like to raise. Please let me know if this is a concern for anyone, or if I've misunderstood something. Section 8.1 (http://tools.ietf.org/html/rfc4875#section-8.1) defines the rules for handling Notify messages for P2MP LSPs. They include the following. - All LSRs which change the sub-group originator ID in a Path message need to intercept both upstream and downstream Notifies so that they can re-write the sub-group identifiers in them then forward them on to the original Notify requestor. They achieve this by re-writing the Notify node address in the NOTIFY_REQUEST object. - All branch LSRs which receive muliple NOTIFY_REQUESTs in Resvs on different downstream branches need to intercept Notifies being sent downstream, duplicate them, and send a copy to all downstream Notify requestors. Again, they achieve this by re-writing the Notify node address. As a result, Notify messages for a P2MP LSP are likely to travel via a number of transit LSRs rather than being sent directly to the original Notify requestor. The purpose of the Notify message is to enable "expedited notification of failures and other events to nodes responsible for restoring failed LSPs" (RFC 3473 section 4). For example, the Notify message is used by GMPLS end-to-end protection (RFC 4872) for communicating LSP failures between ingress and egress LSRs and co-ordinating protection switching to a recovery LSP. The requirement to have Notify messages forwarded by transit LSRs for P2MP LSPs is going to make them much less useful. For example, if an LSR which has re-written the sub-group originator IDs fails, causing a data plane fault in the P2MP LSP, it will be impossible to use Notifies to quickly communicate that failure between source and leaf LSRs. I think this is a significant degradation to the usefulness of Notify messages that is worth addressing. Arguably this is a wider issue that also applies LSPs traversing NNIs between different domains, where the border routers also intercept Notifies. However, it may still be worth considering a solution to just the P2MP LSP problem for now, to facilitate the use of existing protection techniques for P2MP LSPs. Is anyone else interested in addressing this? Thanks, Nic Neate Data Connection Ltd. ------_=_NextPart_001_01C8E046.AA3C3250 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RFC 4875 Notify forwarding by transit LSRs (section 8.1)

Hi all,

This is the second potential = problem in RFC 4875 I'd like to raise.  Please let me know if this = is a concern for anyone, or if I've misunderstood something.

Section 8.1 (http://tools.ietf.org/html/rfc4875#section-8.1) defines the rules for handling Notify = messages for P2MP LSPs.  They include the following.

-  All LSRs which change the = sub-group originator ID in a Path message need to intercept both = upstream and downstream Notifies so that they can re-write the sub-group = identifiers in them then forward them on to the original Notify = requestor.  They achieve this by re-writing the Notify node address = in the NOTIFY_REQUEST object.

-  All branch LSRs which = receive muliple NOTIFY_REQUESTs in Resvs on different downstream = branches need to intercept Notifies being sent downstream, duplicate = them, and send a copy to all downstream Notify requestors.  Again, = they achieve this by re-writing the Notify node address.

As a result, Notify messages for = a P2MP LSP are likely to travel via a number of transit LSRs rather than = being sent directly to the original Notify requestor.

The purpose of the Notify message = is to enable "expedited notification of failures and other events = to nodes responsible for restoring failed LSPs" (RFC 3473 section = 4).  For example, the Notify message is used by GMPLS end-to-end = protection (RFC 4872) for communicating LSP failures between ingress and = egress LSRs and co-ordinating protection switching to a recovery = LSP.

The requirement to have Notify = messages forwarded by transit LSRs for P2MP LSPs is going to make them = much less useful.  For example, if an LSR which has re-written the = sub-group originator IDs fails, causing a data plane fault in the P2MP = LSP, it will be impossible to use Notifies to quickly communicate that = failure between source and leaf LSRs.

I think this is a significant = degradation to the usefulness of Notify messages that is worth = addressing.  Arguably this is a wider issue that also applies LSPs = traversing NNIs between different domains, where the border routers also = intercept Notifies.  However, it may still be worth considering a = solution to just the P2MP LSP problem for now, to facilitate the use of = existing protection techniques for P2MP LSPs.

Is anyone else interested in = addressing this?

Thanks,


Nic Neate
Data Connection Ltd.

------_=_NextPart_001_01C8E046.AA3C3250-- --===============0769876036== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --===============0769876036==-- From mpls-bounces@ietf.org Mon Jul 7 08:33:39 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E03FE3A6A63; Mon, 7 Jul 2008 08:33:38 -0700 (PDT) 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 B06A83A6A63 for ; Mon, 7 Jul 2008 08:33:37 -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 ZL9fdQA479t3 for ; Mon, 7 Jul 2008 08:33:36 -0700 (PDT) Received: from smtp.dataconnection.com (smtp.dataconnection.com [192.91.191.4]) by core3.amsl.com (Postfix) with ESMTP id 823693A6A53 for ; Mon, 7 Jul 2008 08:33:36 -0700 (PDT) Received: from enfimail2.datcon.co.uk ([172.18.10.19]) by smtp.dataconnection.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Jul 2008 16:33:42 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 7 Jul 2008 16:33:41 +0100 Message-ID: <8AC1AD08D396174DBC4E6D44EFACCFB105D6C6CA@enfimail2.datcon.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 4875 one-to-one fast reroute procedures (section 15.2) thread-index: AcjgRtWaRPA6WnI3QAmR+WdWF1CJyg== From: "Nic Neate" To: X-OriginalArrivalTime: 07 Jul 2008 15:33:42.0728 (UTC) FILETIME=[D645A480:01C8E046] Subject: [mpls] RFC 4875 one-to-one fast reroute procedures (section 15.2) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Hi all, RFC 4875 section 15.2 (http://tools.ietf.org/html/rfc4875#section-15.2) defines one-to-one fast reroute procedures for P2MP LSPs. I've got a few questions on some fairly high level aspects of this behaviour. I'd appreciate it if anyone could clarify these points for me, or let me know how your implementation interprets them. (1) Backup path state identifiers This is complicated by the fact that a PLR may initiate multiple backups protecting the same next hop, each for a different S2L sub-LSP. Ordinary P2MP LSP path state is uniquely identified by the SESSION and SENDER_TEMPLATE objects, including the sub-group identifiers (section 10 of the RFC). In P2P fast reroute, with Path-specific signaling, the DETOUR object is used as a further identifier for backup path state. However, that is insufficent for backups to P2MP LSPs because a PLR may originate multiple backups for different S2L sub-LSPs with identical DETOUR objects. It's unclear how that path state should be differentiated. Using S2L_SUB_LSP objects as path state identifiers would be inconsistent with normal P2MP LSP processing, and might lead to problems if an S2L_SUB_LSP is moved to a different sub-group (it would be considered new backup path state rather than a re-optimization). The alternative would be for the PLR to always use different sub-group identifiers for the different backups it originates, however the RFC does not state that it must do that. Which behavior is correct? (2) P2MP backups It is not explicitly stated whether P2MP backups are supported. The implication of backups being for individual S2L sub-LSPs is that backups are P2P. However, it is stated that there can be multiple S2L_SUB_LSP objects in a single backup Path message, meaning that they do make up a P2MP backup LSP. Clearly P2MP backups would be benefical (in the same way as P2MP bypass LSPs). In particular, they would avoid the need to send multiple copies of data down the same link following a failure of the protected LSP. If they are allowed then it would be helpful to also state the merge rules. A single LSR could be a merge point for some S2L backups, a branch point for others, and a cross-over for still others, with complex mappings from upstream to downstream path state. (3) Sub-group re-optimization RFC 4090 fast reroute procedures are only applicable to explicitly routed LSPs, not those that dynamically change their routes (RFC 4090 section 1 paragraph 2). Sub-group re-optimization is a form of rerouting for P2MP LSPs. However, it changes the LSP identifiers (the sub-group IDs in the SENDER_TEMPLATE) for signaling the new route. I think it should therefore be compatible with fast reroute procedures, and allowable for protected P2MP LSPs. Furthermore, it would be useful function to allow an ASBR to re-optimize a P2MP protected LSP that had suffered one or more failure/repair. RFC 4875 doesn't state whether or not sub-group re-optimization is allowed for fast reroute protected P2MP LSPs. Is it? Thanks, Nic Neate Data Connection Ltd. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Jul 7 08:34:38 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC4A83A6A68; Mon, 7 Jul 2008 08:34:38 -0700 (PDT) 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 454F63A6A68 for ; Mon, 7 Jul 2008 08:34:37 -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 4-fDjn04aRir for ; Mon, 7 Jul 2008 08:34:36 -0700 (PDT) Received: from smtp.dataconnection.com (smtp.dataconnection.com [192.91.191.4]) by core3.amsl.com (Postfix) with ESMTP id 1F2FB3A690A for ; Mon, 7 Jul 2008 08:34:35 -0700 (PDT) Received: from enfimail2.datcon.co.uk ([172.18.10.19]) by smtp.dataconnection.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Jul 2008 16:34:42 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 7 Jul 2008 16:34:41 +0100 Message-ID: <8AC1AD08D396174DBC4E6D44EFACCFB105D6C6CC@enfimail2.datcon.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 4875 ERO processing details thread-index: AcjgRvlRkS/JsS8JS6OSaRqe7f60Zw== From: "Nic Neate" To: X-OriginalArrivalTime: 07 Jul 2008 15:34:42.0337 (UTC) FILETIME=[F9CD4110:01C8E046] Subject: [mpls] RFC 4875 ERO processing details 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Hi all, This is the last of four emails querying P2MP LSP behavior in RFC 4875. Could someone please help me with the following questions on ERO processing? (1) Explicit label processing details Explicit labels could be included in an ERO/SERO to specify two S2L sub-LSPs with the same next hop but different labels (for example, in an optical network where different wavelengths are required to reach different leaf nodes). Both S2L sub-LSPs could be signaled in a single Path message (although ERO compression for the next hop would not be possible). In the reverse direction, separate Resv messages must be used for each S2L sub-LSPs because a single Resv MUST use the same label in all filterspecs for the same P2MP LSP (section 6.2). Is it therefore allowed for S2L sub-LSPs in the same sub-group to be signaled in different Resvs with different labels, or should the upstream LSR signal them in different sub-groups, and therefore different Path messages? (2) ERO compression details (section 4.5) Last paragraph in section 4.5 of the RFC states the following: All LSRs need to process the ERO corresponding to the first S2L sub-LSP. An LSR needs to process an S2L sub-LSP descriptor for a subsequent S2L sub-LSP only if the first hop in the corresponding SERO is a local address of that LSR. The branch LSR that is the first hop of an SERO propagates the corresponding S2L sub-LSP downstream. I think that implies the following ERO compression technique. - In Path messages sent by the source, all SEROs are specified right from the first branch point in the P2MP LSP. - At each branch point, SERO hops that come before the next branch point are stripped off before Path messages are forwarded. Thus, at any point in the P2MP tree, the hops to the next branch point are only specified once in the ERO, but thereafter all SEROs are fully specified even if they have large sections in common. That is not the ERO compression technique described in the example earlier in section 4.5, and also not optimal for RSVP Path message size. That suggests that the statement that "An LSR needs to process an S2L sub-LSP descriptor for a subsequent S2L sub-LSP only if the first hop in the corresponding SERO is a local address of that LSR" is inaccurate. Instead - each LSR needs to check the first hop of all SEROs - if an LSR is the first hop of any SERO then it is a branch point - a branch point needs to further analyze all SEROs to determine which branch each S2L sub-LSPs belongs to. Further, failure to do that could lead to routing errors. Is that understanding correct? Thanks, Nic Neate Data Connection Ltd. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Jul 7 09:00:04 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3ED2C3A6A5C; Mon, 7 Jul 2008 09:00:04 -0700 (PDT) X-Original-To: mpls@lists.ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4F9003A68B9; Mon, 7 Jul 2008 09:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080707160001.4F9003A68B9@core3.amsl.com> Date: Mon, 7 Jul 2008 09:00:01 -0700 (PDT) Cc: mpls@lists.ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-cosfield-def-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: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org --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 : "EXP field" renamed to "CoS Field" Author(s) : L. Andersson Filename : draft-ietf-mpls-cosfield-def-04.txt Pages : 16 Date : 2008-07-07 The early MPLS documents defined the form of the MPLS Label Stack entry. This include a three bit field called the "EXP field". The exact use of this field was not defined by these documents, except to state that it was to be "reserved for experimental use". Although the intended use of the EXP field was as a "Class of Service" field, it was not named the "Class of Service" (CoS) field by these early documents because the use of such a CoS field was not considered to be sufficiently defined. Today a number of standards documents define its usage as a CoS field. . To avoid misunderstanding about how this field may be used, this document changes the name of the field to the "CoS field". In doing so it also updates documents that define the current use of the EXP this field. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-cosfield-def-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-cosfield-def-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-07085307.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@ietf.org Mon Jul 7 18:09:01 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7849728C1FB; Mon, 7 Jul 2008 18:09:01 -0700 (PDT) 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 0813028C1FB for ; Mon, 7 Jul 2008 18:09:00 -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 UqEqAHReiI6L for ; Mon, 7 Jul 2008 18:08:59 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 4F11128C14D for ; Mon, 7 Jul 2008 18:08:58 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Mon, 07 Jul 2008 18:08:11 PDT Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp02.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Jul 2008 18:08:13 -0700 Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Jul 2008 18:08:13 -0700 Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Jul 2008 18:01:36 -0700 Received: from sapphire.juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id m6811bx42418; Mon, 7 Jul 2008 18:01:37 -0700 (PDT) (envelope-from rahul@juniper.net) Date: Mon, 7 Jul 2008 18:01:36 -0700 (PDT) From: Rahul Aggarwal To: Nic Neate In-Reply-To: <8AC1AD08D396174DBC4E6D44EFACCFB105D6C6CC@enfimail2.datcon.co.uk> Message-ID: <20080707175847.P73691@sapphire.juniper.net> References: <8AC1AD08D396174DBC4E6D44EFACCFB105D6C6CC@enfimail2.datcon.co.uk> MIME-Version: 1.0 X-OriginalArrivalTime: 08 Jul 2008 01:01:36.0986 (UTC) FILETIME=[2C1CCBA0:01C8E096] Cc: mpls@ietf.org Subject: Re: [mpls] RFC 4875 ERO processing details 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Hi Nic, On Mon, 7 Jul 2008, Nic Neate wrote: > Hi all, > > This is the last of four emails querying P2MP LSP behavior in RFC 4875. > Could someone please help me with the following questions on ERO > processing? > > > (1) Explicit label processing details > > Explicit labels could be included in an ERO/SERO to specify two S2L > sub-LSPs with the same next hop but different labels (for example, in an > optical network where different wavelengths are required to reach > different leaf nodes). In this case is it not the responsibility of the branch LSR to replicate the incoming label onto two different outgoing labels? rahul Both S2L sub-LSPs could be signaled in a single > Path message (although ERO compression for the next hop would not be > possible). > > In the reverse direction, separate Resv messages must be used for each > S2L sub-LSPs because a single Resv MUST use the same label in all > filterspecs for the same P2MP LSP (section 6.2). > > Is it therefore allowed for S2L sub-LSPs in the same sub-group to be > signaled in different Resvs with different labels, or should the > upstream LSR signal them in different sub-groups, and therefore > different Path messages? > > > (2) ERO compression details (section 4.5) > > Last paragraph in section 4.5 of the RFC states the following: > > All LSRs need to > process the ERO corresponding to the first S2L sub-LSP. An LSR needs > to process an S2L sub-LSP descriptor for a subsequent S2L sub-LSP > only if the first hop in the corresponding SERO is a local address of > that LSR. The branch LSR that is the first hop of an SERO propagates > the corresponding S2L sub-LSP downstream. > > I think that implies the following ERO compression technique. > - In Path messages sent by the source, all SEROs are specified right > from the first branch point in the P2MP LSP. > - At each branch point, SERO hops that come before the next branch > point are stripped off before Path messages are forwarded. > > Thus, at any point in the P2MP tree, the hops to the next branch point > are only specified once in the ERO, but thereafter all SEROs are fully > specified even if they have large sections in common. > > That is not the ERO compression technique described in the example > earlier in section 4.5, and also not optimal for RSVP Path message size. > That suggests that the statement that "An LSR needs to process an S2L > sub-LSP descriptor for a subsequent S2L sub-LSP only if the first hop in > the corresponding SERO is a local address of that LSR" is inaccurate. > Instead > - each LSR needs to check the first hop of all SEROs > - if an LSR is the first hop of any SERO then it is a branch point > - a branch point needs to further analyze all SEROs to determine which > branch each S2L sub-LSPs belongs to. > > Further, failure to do that could lead to routing errors. Is that > understanding correct? > > > Thanks, > > > Nic Neate > Data Connection Ltd. > _______________________________________________ > 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 lmzln@herzeleid.net Mon Jul 7 21:41:46 2008 Return-Path: X-Original-To: ietfarch-mpls-archive@core3.amsl.com Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 287413A681B; Mon, 7 Jul 2008 21:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.888 X-Spam-Level: *** X-Spam-Status: No, score=3.888 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RDNS_NONE=0.1, UNPARSEABLE_RELAY=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 jWEWwieQLFmW; Mon, 7 Jul 2008 21:41:45 -0700 (PDT) Received: from proxyrouter1.eatontownpolice.com (unknown [81.214.33.221]) by core3.amsl.com (Postfix) with SMTP id 1AB093A6405; Mon, 7 Jul 2008 21:41:38 -0700 (PDT) Received: from 67.72.346.50 (mta060.bestcountryfan.com) (67.72.346.50) by rly96.mail.masterwinemaker.com with ESMTP; Mon, 07 Jul 2008 21:41:47 -0800 Received: (qmail 3338 invoked by alias); Mon, 07 Jul 2008 21:41:47 -0800 Domainkey-Signature: a=zzb-srg1; q=dns; c=avoaw; s=s8127; d=z2c.net; b=in7PlxTzxLq8PAXP4MYLtkdaSo7vDl1pf5Tbm5wZKhhX544YWQ/jIVUvqXekIxQ9IOIUQemV4DH3tsmzKQcjNNvH4LOfpvdHylSJTrMJb2rV5zU2TXc0Y8UJl+XdWNynYsRRHksVTHg7B6Q7kI52Hwcx= Message-ID: <998754968163663drv3fyw5nh5.5602138009921.Mail.news@condition.enla8.com> Date: Mon, 07 Jul 2008 21:41:47 -0800 (PDT) From: "christy" To: ltru@lists.ietf.org Subject: is it you? christy here Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-mpm: 998754968163663drv3fyw5nh5 hello, I am pretty russian girl, bored tonight. would you like to chat with me and see my pics? if so then email me at echristy32@hugdr.info From suzyisaac49@gmail.com Tue Jul 8 04:15:46 2008 Return-Path: X-Original-To: ietfarch-mpls-archive@core3.amsl.com Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E3D13A6875 for ; Tue, 8 Jul 2008 04:15:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 CNK+psLl1TO9 for ; Tue, 8 Jul 2008 04:15:42 -0700 (PDT) Received: from qb-out-0506.google.com (qb-out-0506.google.com [72.14.204.232]) by core3.amsl.com (Postfix) with ESMTP id A31C53A6845 for ; Tue, 8 Jul 2008 04:15:42 -0700 (PDT) Received: by qb-out-0506.google.com with SMTP id z8so6738744qbc.29 for ; Tue, 08 Jul 2008 04:15:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:reply-to :to:subject:mime-version:content-type; bh=8OwzMoqdc5BGyEcutoU8VB6jlOyA2f6aOlWL9YI0AX0=; b=Y8xMdXAoev+/ALfC3BfPy3+hlQc7B7UFa2bpDNZbMJmVQTBbrnGpe4Xl9KGRWwe4pu 6yJq5XWeG0As6S9TrlqqFtPYyJvkdHU3cinS1W5JkM+E3vaQaVUV6PyYw14xmyc2AUJj sBkTiBDzfmXcPDwTwVScHwLTVhs7Ctq/iHmEM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:to:subject:mime-version:content-type; b=f7akDZEAL0H3Db4kbVEOFfo5Ge9MGK+al6kZf3Ng5muL6HrdwWOG21qzQc92PP913I 9UTshlV3GhP7tcwqT+2Zr/epwEykb6li4rlw419P0uw1y38SoHrYln9bXtONhEIgQcCV 555RLFFzExxCyXM+2gn428IzyWxNFbaEn16bs= Received: by 10.125.121.14 with SMTP id y14mr1271480mkm.174.1215515731810; Tue, 08 Jul 2008 04:15:31 -0700 (PDT) Received: by 10.125.86.8 with HTTP; Tue, 8 Jul 2008 04:15:31 -0700 (PDT) Message-ID: <2a16b08e0807080415k3cf899c3y3e87553e9a0ba7f0@mail.gmail.com> Date: Tue, 8 Jul 2008 13:15:31 +0200 From: "suzy isaac" Reply-To: suzyisaac2008@yahoo.co.in To: suzyisaac49@gmail.com Subject: Intrested in you. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_17404_16140431.1215515731716" ------=_Part_17404_16140431.1215515731716 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Intrested in you. I'm Miss Suzy Isaac, i slim in staure above all i like being honesty,trusted, sincere. I have gonne through your porfiles, it interest me to know you more, and I hope to use this opportunity to explain myself a little about me, i am fair in complexsion,5.9fit tall, 44kg. I wish you to write me through id (suzyisaac2008@yahoo.co.in). also i will send you my picture after hearing from you. Somethings I like to do in my spare time are gardening, home improvement projects, camping, bicycling in the park, backyard bar-b-ques, moon-lite walks on the beach, preparing candle-lite dinners for someone special, sending flowers to someone special for some reasons, sitting and watching the sun set with someone special, and cuddling in front of a fire with someone special. I enjoy cooking, gardening, playing billards, darts, dinning out, going to the cinama, traveling and site-seeing, museums, and concerts. I like almost any kind of music, but I think my favourite is instrumental jazz. i will tell you more about myself again in my next mail dear and hope to hear from you soon. Love From, Mis Suzy Isaac, ------=_Part_17404_16140431.1215515731716 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Intrested in you.
I'm Miss Suzy Isaac, i slim in staure above all i = like being honesty,trusted, sincere. I have gonne through your porfiles, it= interest me to know you more, and I hope to use this opportunity to explai= n myself a little about me, i am  fair in complexsion,5.9fit tall, 44k= g. I wish you to write me through id (suzyisaac2008@yahoo.co.in). also i will send you my picture aft= er hearing from you. Somethings I like to do in my spare time are gardening= , home improvement projects, camping, bicycling in the park, backyard bar-b= -ques, moon-lite walks on the beach, preparing candle-lite dinners for some= one special, sending flowers to someone special for some reasons, sitting a= nd watching the sun set with someone special, and cuddling in front of a fi= re with someone special. I enjoy cooking, gardening, playing billards, dart= s, dinning out, going to the cinama, traveling and site-seeing, museums, an= d concerts. I like almost any kind of music, but I think my favourite is in= strumental jazz. i will tell you more about myself again in my next mail de= ar and hope to hear from you soon.
Love From,
Mis Suzy Isaac,=20 ------=_Part_17404_16140431.1215515731716-- From mpls-bounces@ietf.org Tue Jul 8 04:16:45 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6920928C0DD; Tue, 8 Jul 2008 04:16:45 -0700 (PDT) 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 D303028C0DD for ; Tue, 8 Jul 2008 04:16:44 -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 PsA6vesR6fFJ for ; Tue, 8 Jul 2008 04:16:43 -0700 (PDT) Received: from smtp.dataconnection.com (smtp.dataconnection.com [192.91.191.4]) by core3.amsl.com (Postfix) with ESMTP id 9E4C93A6875 for ; Tue, 8 Jul 2008 04:16:43 -0700 (PDT) Received: from enfimail2.datcon.co.uk ([172.18.10.19]) by smtp.dataconnection.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 8 Jul 2008 12:16:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 8 Jul 2008 12:16:38 +0100 Message-ID: <8AC1AD08D396174DBC4E6D44EFACCFB105DA61C1@enfimail2.datcon.co.uk> In-Reply-To: <20080707175847.P73691@sapphire.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] RFC 4875 ERO processing details thread-index: Acjgl0ON9VFFYJiWR6S/1A4JNhqlxAAUxv9g References: <8AC1AD08D396174DBC4E6D44EFACCFB105D6C6CC@enfimail2.datcon.co.uk> <20080707175847.P73691@sapphire.juniper.net> From: "Nic Neate" To: "Rahul Aggarwal" X-OriginalArrivalTime: 08 Jul 2008 11:16:39.0516 (UTC) FILETIME=[17BC01C0:01C8E0EC] Cc: mpls@lists.ietf.org Subject: Re: [mpls] RFC 4875 ERO processing details 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Hi Rahul, > > > > (1) Explicit label processing details > > > > Explicit labels could be included in an ERO/SERO to specify two S2L > > sub-LSPs with the same next hop but different labels (for > example, in > > an optical network where different wavelengths are required > to reach > > different leaf nodes). > > In this case is it not the responsibility of the branch LSR > to replicate the incoming label onto two different outgoing labels? > > rahul > Sure, this is definitely a branch point in the data plane. My question is whether it also needs to be a branch point in the control plane. Do the S2L sub-LSPs need to be signaled in different Path messages, given that their next hop is the same? My reading of section 6.2 of the RFC is that it is not necessary. If a single Path message is used then the downstream LSR can still use different Resvs for each S2L sub-LSP to signal the different labels even though both S2L sub-LSPs are in the same sub-group. On the other hand, the RFC states that the downstream LSR SHOULD use the same label across multiple Resv messages for the same P2MP LSP - which is not possible in this case. What do you think the correct way to signal this is? Do you have an opinion on the ERO compression question below as well? Thanks, Nic > Both S2L sub-LSPs could be signaled in a single > > Path message (although ERO compression for the next hop > would not be > > possible). > > > > In the reverse direction, separate Resv messages must be > used for each > > S2L sub-LSPs because a single Resv MUST use the same label in all > > filterspecs for the same P2MP LSP (section 6.2). > > > > Is it therefore allowed for S2L sub-LSPs in the same > sub-group to be > > signaled in different Resvs with different labels, or should the > > upstream LSR signal them in different sub-groups, and therefore > > different Path messages? > > > > > > (2) ERO compression details (section 4.5) > > > > Last paragraph in section 4.5 of the RFC states the following: > > > > All > LSRs need to > > process the ERO corresponding to the first S2L sub-LSP. > An LSR needs > > to process an S2L sub-LSP descriptor for a subsequent S2L sub-LSP > > only if the first hop in the corresponding SERO is a > local address of > > that LSR. The branch LSR that is the first hop of an > SERO propagates > > the corresponding S2L sub-LSP downstream. > > > > I think that implies the following ERO compression technique. > > - In Path messages sent by the source, all SEROs are > specified right > > from the first branch point in the P2MP LSP. > > - At each branch point, SERO hops that come before the next branch > > point are stripped off before Path messages are forwarded. > > > > Thus, at any point in the P2MP tree, the hops to the next > branch point > > are only specified once in the ERO, but thereafter all > SEROs are fully > > specified even if they have large sections in common. > > > > That is not the ERO compression technique described in the example > > earlier in section 4.5, and also not optimal for RSVP Path > message size. > > That suggests that the statement that "An LSR needs to > process an S2L > > sub-LSP descriptor for a subsequent S2L sub-LSP only if the > first hop > > in the corresponding SERO is a local address of that LSR" > is inaccurate. > > Instead > > - each LSR needs to check the first hop of all SEROs > > - if an LSR is the first hop of any SERO then it is a branch point > > - a branch point needs to further analyze all SEROs to determine > > which branch each S2L sub-LSPs belongs to. > > > > Further, failure to do that could lead to routing errors. Is that > > understanding correct? > > > > > > Thanks, > > > > > > Nic Neate > > Data Connection Ltd. > > _______________________________________________ > > 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 mpls-bounces@ietf.org Tue Jul 8 16:45:04 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF1B128C216; Tue, 8 Jul 2008 16:45:03 -0700 (PDT) X-Original-To: mpls@lists.ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BF29A28C1CA; Tue, 8 Jul 2008 16: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: <20080708234501.BF29A28C1CA@core3.amsl.com> Date: Tue, 8 Jul 2008 16:45:01 -0700 (PDT) Cc: mpls@lists.ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-rsvp-upstream-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: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org --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 Upstream Label Assignment for RSVP-TE Author(s) : R. Aggarwal, J. Le Roux Filename : draft-ietf-mpls-rsvp-upstream-03.txt Pages : 9 Date : 2008-07-08 This document describes procedures for distributing upstream-assigned labels for Resource Reservation Protocol - Traffic Engineering (RSVP- TE). It also describes how these procedures can be used for avoiding branch LSR traffic replication on a LAN for RSVP-TE point-to- multipoint (P2MP)LSPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-rsvp-upstream-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-upstream-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-08164103.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@ietf.org Tue Jul 8 17:00:05 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12C453A6B52; Tue, 8 Jul 2008 17:00:05 -0700 (PDT) X-Original-To: mpls@lists.ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 99DEB3A6AB4; Tue, 8 Jul 2008 17:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080709000001.99DEB3A6AB4@core3.amsl.com> Date: Tue, 8 Jul 2008 17:00:01 -0700 (PDT) Cc: mpls@lists.ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-ldp-upstream-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: , Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org --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 Upstream Label Assignment for LDP Author(s) : R. Aggarwal, J. Le Roux Filename : draft-ietf-mpls-ldp-upstream-03.txt Pages : 11 Date : 2008-07-08 This document describes procedures for distributing upstream-assigned labels for Label Distribution Protocol (LDP). It also describes how these procedures can be used for avoiding branch LSR traffic replication on a LAN for LDP point-to-multipoint (P2MP)LSPs. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-upstream-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-ldp-upstream-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-08165302.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@ietf.org Wed Jul 9 04:07:07 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3F1F3A67D8; Wed, 9 Jul 2008 04:07:07 -0700 (PDT) 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 913253A67D8 for ; Wed, 9 Jul 2008 04:07:06 -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 sq3M4m5r32LH for ; Wed, 9 Jul 2008 04:07:05 -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 EAA7F3A67A6 for ; Wed, 9 Jul 2008 04:07:04 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,331,1212364800"; d="scan'208";a="13883327" Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 09 Jul 2008 11:07:13 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m69B7DPl015228; Wed, 9 Jul 2008 13:07:13 +0200 Received: from stewart-bryants-computer.local (dhcp-10-61-97-220.cisco.com [10.61.97.220]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m69B7CRq026066; Wed, 9 Jul 2008 11:07:13 GMT Message-ID: <48749BE0.5020404@cisco.com> Date: Wed, 09 Jul 2008 12:07:12 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Kireeti Kompella , Shane Amante , Clarence Filsfils DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5199; t=1215601633; x=1216465633; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Some=20comments=20on=20draft-kompella-mpls-entr opy-lables |Sender:=20; bh=DwBWmgatiYoNxXJ2jvkVhzRyh77vaq1hl6Ig4Y0nf6U=; b=lb2r6yra4iWmTVp23ogDwJzc/cjf+I/+8OQgtYNi4+VG4Ku04nv9SUhAfa CaVNtz8UP2PzstjL7dlnqaFclr9TaWPq57S9js3E7IphxNiJ/V5dWSn4lfwv +pmA2r0QTr; Authentication-Results: ams-dkim-2; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); Cc: mpls@ietf.org Subject: [mpls] Some comments on draft-kompella-mpls-entropy-lables X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org The Use of Entropy Labels in MPLS Forwarding draft-kompella-mpls-entropy-lables 1. Introduction Load balancing, or multi-pathing, is an attempt to balance traffic across a network by allowing the traffic to use several paths, not just a single shortest path. Load balancing has several benefits: it eases capacity planning; it can help absorb traffic surges by spreading them across several links; it allow better resilience by offering alternate paths should a link or node fail. SB> This last point is not correct as it stands. When a link or SB> note fails, it is good to have another high capacity path SB> and if it's ECMP you can use it for FRR, but the path SB> itself will blackhole until you take action. There are three key reasons why this is beneficial: 1. at the ingress of the LSP, MPLS encapsulation hasn't yet occurred, so deep inspection is not necessary; SB> Sure it's less deep, but it's still the standard tuple and SB> most folks would call that DPI. However I agree that it SB> is less deep. 1.1. Motivation Currently, each MPLS LSR along a given path needs to individually infer the underlying protocol within a MPLS packet in order to then extract appropriate keys from the payload. Those keys are then used as input into a hash algorithm to determine the specific output interface on a LSR that is used for that given "microflow". Unfortunately, if the MPLS LSR is unable to infer the MPLS packet's payload (as is often the case), they typically will resort to using the topmost MPLS labels in the MPLS stack as keys to the load-hashing SB> Do you mean top or bottom? algorithm. The result is an extremely inequitable distribution of traffic across multiple equal-cost paths exiting that node, simply because the topmost MPLS labels are very coarse-grained forwarding labels that typically describe a next-hop, or provide some other type of mux/demux forwarding function, and do not describe the granularity of the underlying traffic. 2. Approaches 3. Entropy Labels An entropy label (as used here) is a label: 1. that is not used for forwarding; 2. that is not signaled; and 3. whose only purpose in the label stack is to provide "entropy" to improve load balancing. Entropy labels are generated by an ingress LSR, based entirely on load balancing information. However, they MUST not have values in the reserved label space (0-15). Entropy labels MUST be at the bottom of the label stack, and thus the "end-of-stack" bit in the label should be set. To ensure that they are not used inadvertently SB> MUST be set for forwarding, entropy labels SHOULD have a TTL of 0. SB> That is a good idea, we will put it in the PW draft. Since entropy labels are generated by the ingress LSR, an egress LSR MUST be able to tell unambiguously that a given label is an entropy label. This of course depends on the underlying application. If any ambiguity is possible, the label above the entropy label MUST be an "entropy label indicator" (ELI), which says that the following label is an entropy label. The ELI may be signaled, or may be a reserved label reserved specifically for this purpose. Fortunately, for many applications, the use of entropy labels is unambiguous, and does not need an ELI. SB> I would be worried about using a reserved label for this. SB> I don't think its actually needed and they are in short supply. SB> We are going to need a forwarding path that gets context from a SB> signaled label and discards the following label for a number of the SB> cases, so we should try to use that method everywhere. 4. Forwarding and Load Balancing Behaviors for Entropy Labels Thus, transit LSRs are almost unaffected by the use of entropy labels. If transit LSRs were programmed to use a subset of the label stack, they may have to be reconfigured to use the full stack. But otherwise, no changes are needed. SB> Surely they just need to use the bottom of stack? 4.3. Egress LSRs SB> Should you consider PHP of entropy labels. 6. Security Considerations Having security is a Good Thing. SB> Firstly it's worth noting in the Security section that care is needed not SB> to make this label some sort of covert channel. SB> SB> Secondly kind of the opposite of the above. You called it an entropy SB> label and we (who independently thought this up) called it a load SB> balance label. We should pick on or the other. However that causes SB> to wonder if there is some other use that we will find for that 20 SB> bits? If so perhaps we should call it a context label? SB> I put that remark down here because it flys in the face of my SB> first comment about covert channels. 7. Acknowledgments We wish to thank Ulrich Drafz for his contributions, as well as the entire "hash label" team for their valuable comments and discussion. SB> There are so few of us we could probably be named :) _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Jul 9 05:47:14 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 284123A69AA; Wed, 9 Jul 2008 05:47:14 -0700 (PDT) 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 48B353A69D2 for ; Wed, 9 Jul 2008 05:47:12 -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 pHQybzU8zv-t for ; Wed, 9 Jul 2008 05:47:11 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.175]) by core3.amsl.com (Postfix) with ESMTP id C6E2A3A6A9B for ; Wed, 9 Jul 2008 05:47:08 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 27so3168390wfd.31 for ; Wed, 09 Jul 2008 05:47:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=UriTdmr8XC5nd5Ompxy+yyQ44yE6Scx1jb2igAuUnec=; b=Wkfmr5nH1OOq5lEzv3aslT6HmAGBUP/nzQUdvGDNEbbmDRg0Nx9pPBVHxuPCdZ++n6 shfgZrBag/H5S7bn/XvzuMsmMufiwG3vg1RwUfdh5t6xtBM5lewc8IsZVOXMpDTanCzd nDl4Wcg1nqQ/aRM4HN8gEvqleb/dh/oGpUD98= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=T7rd4JnxigSbbqWgILmKTpsWFxH56Rvg4RLcmsQNnXFs6v8b8Nk8lCyDjsrgku0Bf0 5Bb4D81twerDV2PUZg/wECDuyIgKp5SCrmColoCq1w0TCJcM8GPpr0j8zCAIfraPmIbq XSzC12lHYBOwLtb1sRbD5yxcUhajKm0WDNjpE= Received: by 10.142.125.9 with SMTP id x9mr2261337wfc.123.1215607640784; Wed, 09 Jul 2008 05:47:20 -0700 (PDT) Received: by 10.143.9.18 with HTTP; Wed, 9 Jul 2008 05:47:20 -0700 (PDT) Message-ID: <77ead0ec0807090547j7ee5a967v5c7487650534c180@mail.gmail.com> Date: Wed, 9 Jul 2008 05:47:20 -0700 From: "Vishwas Manral" To: stbryant@cisco.com In-Reply-To: <48749BE0.5020404@cisco.com> MIME-Version: 1.0 Content-Disposition: inline References: <48749BE0.5020404@cisco.com> Cc: Clarence Filsfils , mpls@ietf.org Subject: Re: [mpls] Some comments on draft-kompella-mpls-entropy-lables 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Hi Stewart/ Kireeti, I personally find the draft very helpful though I cannot find link to the draft, this is the exact point I raised on the other drafts too, the idea of Flow labels being used. http://www.ietf.org/mail-archive/web/mpls/current/msg02080.html Kireeti, there are other advantages of flow labels I had mentioned in my earlier mail, besides ECMP. You may want to include that in your draft too. Having worked on middle boxes these are very real issues. Some other things to consider are, reserved labels not being the bottom of stack always and deriving information of the bottom of stack from the last label, and deriving information like the packet protocol (IPv4 or IPv6 based on that label). Thanks, Vishwas On Wed, Jul 9, 2008 at 4:07 AM, Stewart Bryant wrote: > > The Use of Entropy Labels in MPLS Forwarding > draft-kompella-mpls-entropy-lables > > > 1. Introduction > > Load balancing, or multi-pathing, is an attempt to balance traffic > across a network by allowing the traffic to use several paths, not > just a single shortest path. Load balancing has several benefits: it > eases capacity planning; it can help absorb traffic surges by > spreading them across several links; it allow better resilience by > offering alternate paths should a link or node fail. > > SB> This last point is not correct as it stands. When a link or > SB> note fails, it is good to have another high capacity path > SB> and if it's ECMP you can use it for FRR, but the path > SB> itself will blackhole until you take action. > > > There are three key > reasons why this is beneficial: > > 1. at the ingress of the LSP, MPLS encapsulation hasn't yet > occurred, so deep inspection is not necessary; > > SB> Sure it's less deep, but it's still the standard tuple and > SB> most folks would call that DPI. However I agree that it > SB> is less deep. > > 1.1. Motivation > > Currently, each MPLS LSR along a given path needs to individually > infer the underlying protocol within a MPLS packet in order to then > extract appropriate keys from the payload. Those keys are then used > as input into a hash algorithm to determine the specific output > interface on a LSR that is used for that given "microflow". > Unfortunately, if the MPLS LSR is unable to infer the MPLS packet's > payload (as is often the case), they typically will resort to using > the topmost MPLS labels in the MPLS stack as keys to the load-hashing > SB> Do you mean top or bottom? > > algorithm. The result is an extremely inequitable distribution of > traffic across multiple equal-cost paths exiting that node, simply > because the topmost MPLS labels are very coarse-grained forwarding > labels that typically describe a next-hop, or provide some other type > of mux/demux forwarding function, and do not describe the granularity > of the underlying traffic. > > 2. Approaches > > > 3. Entropy Labels > > An entropy label (as used here) is a label: > > 1. that is not used for forwarding; > > 2. that is not signaled; and > > 3. whose only purpose in the label stack is to provide "entropy" to > improve load balancing. > > Entropy labels are generated by an ingress LSR, based entirely on > load balancing information. However, they MUST not have values in > the reserved label space (0-15). Entropy labels MUST be at the > bottom of the label stack, and thus the "end-of-stack" bit in the > label should be set. To ensure that they are not used inadvertently > SB> MUST be set > for forwarding, entropy labels SHOULD have a TTL of 0. > SB> That is a good idea, we will put it in the PW draft. > > Since entropy labels are generated by the ingress LSR, an egress LSR > MUST be able to tell unambiguously that a given label is an entropy > label. This of course depends on the underlying application. If any > ambiguity is possible, the label above the entropy label MUST be an > "entropy label indicator" (ELI), which says that the following label > is an entropy label. The ELI may be signaled, or may be a reserved > label reserved specifically for this purpose. Fortunately, for many > applications, the use of entropy labels is unambiguous, and does not > need an ELI. > > SB> I would be worried about using a reserved label for this. > SB> I don't think its actually needed and they are in short supply. > SB> We are going to need a forwarding path that gets context from a > SB> signaled label and discards the following label for a number of the > SB> cases, so we should try to use that method everywhere. > > 4. Forwarding and Load Balancing Behaviors for Entropy Labels > > > Thus, transit LSRs are almost unaffected by the use of entropy > labels. If transit LSRs were programmed to use a subset of the label > stack, they may have to be reconfigured to use the full stack. But > otherwise, no changes are needed. > > SB> Surely they just need to use the bottom of stack? > > > 4.3. Egress LSRs > > SB> Should you consider PHP of entropy labels. > > > > 6. Security Considerations > > Having security is a Good Thing. > > SB> Firstly it's worth noting in the Security section that care is needed > not > SB> to make this label some sort of covert channel. > SB> > SB> Secondly kind of the opposite of the above. You called it an entropy > SB> label and we (who independently thought this up) called it a load > SB> balance label. We should pick on or the other. However that causes > SB> to wonder if there is some other use that we will find for that 20 > SB> bits? If so perhaps we should call it a context label? > SB> I put that remark down here because it flys in the face of my > SB> first comment about covert channels. > > > 7. Acknowledgments > > We wish to thank Ulrich Drafz for his contributions, as well as the > entire "hash label" team for their valuable comments and discussion. > > SB> There are so few of us we could probably be named :) > > > > > _______________________________________________ > 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 mpls-bounces@ietf.org Wed Jul 9 06:05:51 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0F663A6AA0; Wed, 9 Jul 2008 06:05:51 -0700 (PDT) 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 3240128C12E for ; Wed, 9 Jul 2008 06:05:51 -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 ZihxcoXD1iR9 for ; Wed, 9 Jul 2008 06:05: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 8024628C0FF for ; Wed, 9 Jul 2008 06:05:44 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,331,1212364800"; d="scan'208";a="13900164" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 09 Jul 2008 13:05:55 +0000 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m69D5tss023404; Wed, 9 Jul 2008 15:05:55 +0200 Received: from stewart-bryants-computer.local (dhcp-10-61-97-220.cisco.com [10.61.97.220]) by ams-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m69D5sIs021346; Wed, 9 Jul 2008 13:05:54 GMT Message-ID: <4874B7B2.9020702@cisco.com> Date: Wed, 09 Jul 2008 14:05:54 +0100 From: Stewart Bryant User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: HENDERICKX Wim References: <48749BE0.5020404@cisco.com> In-Reply-To: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1965; t=1215608755; x=1216472755; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=stbryant@cisco.com; z=From:=20Stewart=20Bryant=20 |Subject:=20Re=3A=20[mpls]=20Some=20comments=20on=20draft-k ompella-mpls-entropy-lables |Sender:=20; bh=fr6vvmZM4qDXma3mb/LMn40JHIaYnbtZDXH3IPLvjZs=; b=hYpukljsCKj4b4W6yC8R03y9uMg8lls9iJjdJXGbiOVTmWKxuqIGuG6bMx z8aByjWra07+TM0XYy0vd84taNQ0ff+VmohrbmC7pLmcHQS183cJX0GMFVu7 oUgl89Dq2i; Authentication-Results: ams-dkim-1; header.From=stbryant@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: Clarence Filsfils , mpls@ietf.org Subject: Re: [mpls] Some comments on draft-kompella-mpls-entropy-lables X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Wim > > Entropy labels are generated by an ingress LSR, based entirely on > load balancing information. However, they MUST not have values in > the reserved label space (0-15). Entropy labels MUST be at the > bottom of the label stack, and thus the "end-of-stack" bit in the > label should be set. To ensure that they are not used inadvertently > SB> MUST be set > for forwarding, entropy labels SHOULD have a TTL of 0. > SB> That is a good idea, we will put it in the PW draft. > > WH> If we use TTL=0 and we use PHP on the egress LER with BGP shortcuts, > the packet on the egress LER will be received with TTL=0. The egress LER > will drop this packet normally. > > I see 3 options for this: > 1. Either use TTL=1 for the entropy label > 2. Do something different for BGP shortcuts, introduce a service label > like is done for 6PE e.g., but this requires changes from today's > implementations and is always hard. > 3. Avoid PHP with entropy label , but this changes again current > deployment models which is always though. > > For me option 1 seems the best, unless I miss something. > > Since entropy labels are generated by the ingress LSR, an egress LSR > MUST be able to tell unambiguously that a given label is an entropy > label. This of course depends on the underlying application. If any > ambiguity is possible, the label above the entropy label MUST be an > "entropy label indicator" (ELI), which says that the following label > is an entropy label. The ELI may be signaled, or may be a reserved > label reserved specifically for this purpose. Fortunately, for many > applications, the use of entropy labels is unambiguous, and does not > need an ELI. > > That is a good point. In the case of PWE3 TTL=0 would work because we still have the PW label after PHP of the PE delivery label. However PWE3 should adopt the same policy as MPLS. Stewart _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Jul 9 08:03:02 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B1D83A68FB; Wed, 9 Jul 2008 08:03:02 -0700 (PDT) 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 E65E53A67CF for ; Wed, 9 Jul 2008 08:03:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.117 X-Spam-Level: X-Spam-Status: No, score=-1.117 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] 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 sT6Hj1qlu0mK for ; Wed, 9 Jul 2008 08:02:59 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id E690E3A68FB for ; Wed, 9 Jul 2008 08:02:55 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id 47B642684EA; Wed, 9 Jul 2008 09:03:08 -0600 (MDT) Received: from [127.0.0.1] (dog.tcb.net [64.78.150.133]) (authenticated-user smtp) (TLSv1/SSLv3 DHE-RSA-AES256-SHA 256/256) by dog.tcb.net with SMTP; Wed, 09 Jul 2008 09:03:08 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=64.78.150.133; client-port=58514; data-bytes=0 Message-ID: <4874D32B.1070003@castlepoint.net> Date: Wed, 09 Jul 2008 09:03:07 -0600 From: Shane Amante User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: stbryant@cisco.com References: <48749BE0.5020404@cisco.com> In-Reply-To: <48749BE0.5020404@cisco.com> Cc: mpls@ietf.org, Clarence Filsfils Subject: Re: [mpls] Some comments on draft-kompella-mpls-entropy-lables 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Stewart, Stewart Bryant wrote: > > The Use of Entropy Labels in MPLS Forwarding > draft-kompella-mpls-entropy-lables > > > 1. Introduction > > Load balancing, or multi-pathing, is an attempt to balance traffic > across a network by allowing the traffic to use several paths, not > just a single shortest path. Load balancing has several benefits: it > eases capacity planning; it can help absorb traffic surges by > spreading them across several links; it allow better resilience by > offering alternate paths should a link or node fail. > > SB> This last point is not correct as it stands. When a link or > SB> note fails, it is good to have another high capacity path > SB> and if it's ECMP you can use it for FRR, but the path > SB> itself will blackhole until you take action. Actually, I believe the point is correct. Specifically, in operation of a network, it has been observed that as the number of component-links in a link-bundle increases, one tends to experience a higher rate of failure of individual component-link members, generally due to subtle transmission errors. Rather than have just 1 component-link (experiencing only a momentary transmission problem) taking down a very large link-bundle, operators may over-build paths with an extra component-link to absorb a [brief] failure of any individual member. This tends to be significantly less disruptive to traffic overall. Second, with respect to node failure, once a failure is detected (either through Loss of Light or, perhaps, BFD) it is *automatically* propagated via the IGP throughout the network. Thus, the network should recover automatically in a very short period of time. Finally, operators are typically aware that if they are load-balancing traffic over an ECMP path to alleviate capacity constraints of a single path, they could have (big) problems when one of the multiple paths fails. Therefore, they may plan to load-balance over, say, 3x ECMP paths in order that if any one path fails there is only a reduction of 33% of capacity, which may be adequate to continue forwarding without any traffic loss. > There are three key > reasons why this is beneficial: > > 1. at the ingress of the LSP, MPLS encapsulation hasn't yet > occurred, so deep inspection is not necessary; > > SB> Sure it's less deep, but it's still the standard tuple and > SB> most folks would call that DPI. However I agree that it > SB> is less deep. Although it may be a "standard tuple", the larger problem is *where to find it* or how deep in a packet you're going to have to search to find something that adequately and accurately describes a "microflow". For example, consider the following very brief list of encapsulations: IPv4/GRE/IPv4 IPv6/IPv4 (IP-in-IP) IPv4/Ethernet(Untagged)/MPLS IPv4/Ethernet(NxVLAN Tags)/MPLS ... > 1.1. Motivation > > Currently, each MPLS LSR along a given path needs to individually > infer the underlying protocol within a MPLS packet in order to then > extract appropriate keys from the payload. Those keys are then used > as input into a hash algorithm to determine the specific output > interface on a LSR that is used for that given "microflow". > Unfortunately, if the MPLS LSR is unable to infer the MPLS packet's > payload (as is often the case), they typically will resort to using > the topmost MPLS labels in the MPLS stack as keys to the load-hashing > SB> Do you mean top or bottom? Perhaps we should remove 'topmost' from that sentence, since implementations are free to do as they wish, just as long as they are self-consistent. However, even if they are using the bottomost labels, which is better, it still ultimately resorts in "macroflows". > algorithm. The result is an extremely inequitable distribution of > traffic across multiple equal-cost paths exiting that node, simply > because the topmost MPLS labels are very coarse-grained forwarding > labels that typically describe a next-hop, or provide some other type > of mux/demux forwarding function, and do not describe the granularity > of the underlying traffic. > > 2. Approaches > > > 3. Entropy Labels > > An entropy label (as used here) is a label: > > 1. that is not used for forwarding; > > 2. that is not signaled; and > > 3. whose only purpose in the label stack is to provide "entropy" to > improve load balancing. > > Entropy labels are generated by an ingress LSR, based entirely on > load balancing information. However, they MUST not have values in > the reserved label space (0-15). Entropy labels MUST be at the > bottom of the label stack, and thus the "end-of-stack" bit in the > label should be set. To ensure that they are not used inadvertently > SB> MUST be set > for forwarding, entropy labels SHOULD have a TTL of 0. > SB> That is a good idea, we will put it in the PW draft. I will follow-up on this in the separate thread that spawned after this e-mail. > Since entropy labels are generated by the ingress LSR, an egress LSR > MUST be able to tell unambiguously that a given label is an entropy > label. This of course depends on the underlying application. If any > ambiguity is possible, the label above the entropy label MUST be an > "entropy label indicator" (ELI), which says that the following label > is an entropy label. The ELI may be signaled, or may be a reserved > label reserved specifically for this purpose. Fortunately, for many > applications, the use of entropy labels is unambiguous, and does not > need an ELI. > > SB> I would be worried about using a reserved label for this. > SB> I don't think its actually needed and they are in short supply. > SB> We are going to need a forwarding path that gets context from a > SB> signaled label and discards the following label for a number of the > SB> cases, so we should try to use that method everywhere. We should discuss this further. I agree reserved labels are in short-supply, however having a reserved label for an ELI would seem to be a good use case. A reserved label could have the advantage that HW would be able to quickly recognize it and not attempt to use it for a FIB look-up for forwarding. (There's less that can go wrong with forwarding if an ELI is not dynamically signaled). I'll follow-up on the rest later. -shane > 4. Forwarding and Load Balancing Behaviors for Entropy Labels > > > Thus, transit LSRs are almost unaffected by the use of entropy > labels. If transit LSRs were programmed to use a subset of the label > stack, they may have to be reconfigured to use the full stack. But > otherwise, no changes are needed. > > SB> Surely they just need to use the bottom of stack? > > > 4.3. Egress LSRs > > SB> Should you consider PHP of entropy labels. > > > > 6. Security Considerations > > Having security is a Good Thing. > > SB> Firstly it's worth noting in the Security section that care is > needed not > SB> to make this label some sort of covert channel. > SB> > SB> Secondly kind of the opposite of the above. You called it an entropy > SB> label and we (who independently thought this up) called it a load > SB> balance label. We should pick on or the other. However that causes > SB> to wonder if there is some other use that we will find for that 20 > SB> bits? If so perhaps we should call it a context label? > SB> I put that remark down here because it flys in the face of my > SB> first comment about covert channels. > > > 7. Acknowledgments > > We wish to thank Ulrich Drafz for his contributions, as well as the > entire "hash label" team for their valuable comments and discussion. > > SB> There are so few of us we could probably be named :) > > > > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Jul 9 14:51:06 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68A8928C31B; Wed, 9 Jul 2008 14:51:06 -0700 (PDT) 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 C20B328C31B for ; Wed, 9 Jul 2008 14:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.202 X-Spam-Level: X-Spam-Status: No, score=-5.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 SzLmaiIeaUwh for ; Wed, 9 Jul 2008 14:51:04 -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 C4F6D28C312 for ; Wed, 9 Jul 2008 14:51:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.30,333,1212364800"; d="scan'208,217";a="13740636" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 09 Jul 2008 21:50:14 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m69LoES1029582; Wed, 9 Jul 2008 17:50:14 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m69LoE6t006991; Wed, 9 Jul 2008 21:50:14 GMT Received: from xmb-rtp-206.amer.cisco.com ([64.102.31.32]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 Jul 2008 17:50:14 -0400 Received: from 10.98.32.174 ([10.98.32.174]) by xmb-rtp-206.amer.cisco.com ([64.102.31.32]) with Microsoft Exchange Server HTTP-DAV ; Wed, 9 Jul 2008 21:50:13 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Wed, 09 Jul 2008 17:50:13 -0400 From: George Swallow To: Shane Amante , "Stewart Bryant (stbryant)" Message-ID: Thread-Topic: [mpls] Some comments on draft-kompella-mpls-entropy-lables Thread-Index: Acjh1QRR8BwJA2ZNQFu/J52T8qoHIAAOL+hj In-Reply-To: <4874D32B.1070003@castlepoint.net> Mime-version: 1.0 X-OriginalArrivalTime: 09 Jul 2008 21:50:14.0169 (UTC) FILETIME=[C4A57890:01C8E20D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3472; t=1215640214; x=1216504214; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=swallow@cisco.com; z=From:=20George=20Swallow=20 |Subject:=20Re=3A=20[mpls]=20Some=20comments=20on=20draft-k ompella-mpls-entropy-lables |Sender:=20 |To:=20Shane=20Amante=20,=0A=20=20=2 0=20=20=20=20=20=22Stewart=20Bryant=20(stbryant)=22=20; bh=E7SI7nL82XolU1pJRh5ox+jXIqxyFPNYXp7e7VskRio=; b=ggpYZ1ng+Y9KO4WfX1M2RCgaoG5exGlCZJRMy/WdPB7KHuhXpYzonLTc5Z WxL4QJarzqcvgDd0nHrM4yGH91/MUCa2hs+QCRa6OFaBnMaLruEeQXsBz7iH wZhGO1cbqe; Authentication-Results: rtp-dkim-1; header.From=swallow@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: mpls@ietf.org, "Clarence Filsfils \(cfilsfil\)" Subject: Re: [mpls] Some comments on draft-kompella-mpls-entropy-lables 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: , Content-Type: multipart/mixed; boundary="===============1555097017==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1555097017== Content-type: multipart/alternative; boundary="B_3298470613_41350234" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3298470613_41350234 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit I disagree with the text below. It is my understanding that a lot of equipment does ECMP by looking for EOS, checking the first nibble for 0100b and if true running the usual IPv4 load-balancing. Only if it is not 0100b (and maybe 0110b) does it actual use some portion of the label stack. This is why in PW, the first nibble of the CW is 0000b. It seems to me the only way to be sure that this will work is to define a new FEC in LDP. This would be equivalent to an IP FEC, but say that you must load balance on the label stack only. ...George 4.2. Transit LSR Transit LSRs have no change in forwarding behavior. For load balancing, transit LSRs SHOULD use the whole label stack (e.g., for computing the load balance hash). Transit LSRs MAY choose to look beyond the label stack for further load balancing information; however, if entropy labels are being used, this may not be very useful. In a mixed environment (or for backward compatibility), this is the simplest approach. Thus, transit LSRs are almost unaffected by the use of entropy labels. If transit LSRs were programmed to use a subset of the label stack, they may have to be reconfigured to use the full stack. But otherwise, no changes are needed. --B_3298470613_41350234 Content-type: text/html; charset="US-ASCII" Content-transfer-encoding: quoted-printable Re: [mpls] Some comments on draft-kompella-mpls-entropy-lables</TITL= E> </HEAD> <BODY> <FONT FACE=3D"Monaco, Courier New"><SPAN STYLE=3D'font-size:14pt'>I disagree wi= th the text below.  It is my understanding that a lot of equipment does= ECMP by looking for EOS, checking the first nibble for 0100b and if true ru= nning the usual IPv4 load-balancing.  Only if it is not 0100b (and mayb= e 0110b) does it actual use some portion of the label stack.  This is w= hy in PW, the first nibble of the CW is 0000b.<BR> <BR> It seems to me the only way to be sure that this will work is to define a n= ew FEC in LDP. This would be equivalent to an IP FEC, but say that you must = load balance on the label stack only.<BR> <BR> ...George<BR> <BR> 4.2.  Transit LSR<BR> <BR>    Transit LSRs have no change in forwarding behavior.  = ;For load<BR>    balancing, transit LSRs SHOULD use the whole label stack = (e.g., for<BR>    computing the load balance hash).  Transit LSRs MAY = choose to look<BR>    beyond the label stack for further load balancing informa= tion;<BR>    however, if entropy labels are being used, this may not b= e very<BR>    useful.  In a mixed environment (or for backward com= patibility), this<BR>    is the simplest approach.<BR> <BR>    Thus, transit LSRs are almost unaffected by the use of en= tropy<BR>    labels.  If transit LSRs were programmed to use a su= bset of the label<BR>    stack, they may have to be reconfigured to use the full s= tack.  But<BR>    otherwise, no changes are needed.<BR> </SPAN></FONT> </BODY> </HTML> --B_3298470613_41350234-- --===============1555097017== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --===============1555097017==-- From mpls-bounces@ietf.org Thu Jul 10 04:41:59 2008 Return-Path: <mpls-bounces@ietf.org> X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F7DC28C0F9; Thu, 10 Jul 2008 04:41:59 -0700 (PDT) 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 5EB163A695B; Thu, 10 Jul 2008 04:41:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[AWL=0.397, 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 kBhppm7ohXv4; Thu, 10 Jul 2008 04:41:57 -0700 (PDT) Received: from neo.viciousnest.net (neo.viciousnest.net [192.71.80.124]) by core3.amsl.com (Postfix) with ESMTP id E482D3A68D0; Thu, 10 Jul 2008 04:41:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by neo.viciousnest.net (Postfix) with ESMTP id 7ED4E1C2C0; Thu, 10 Jul 2008 13:42:07 +0200 (CEST) Received: from neo.viciousnest.net ([127.0.0.1]) by localhost (neo [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17172-10; Thu, 10 Jul 2008 13:42:02 +0200 (CEST) Received: from [127.0.0.1] (pat.acreo.se [217.151.195.214]) by neo.viciousnest.net (Postfix) with ESMTP id 0C7B61C2BB; Thu, 10 Jul 2008 13:42:02 +0200 (CEST) Message-ID: <4875F57C.4040002@pi.nu> Date: Thu, 10 Jul 2008 13:41:48 +0200 From: Loa Andersson <loa@pi.nu> User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: mpls@ietf.org, mpls-tp@ietf.org, MEAD team <mpls-interop@ietf.org>, jwt@testbed.se, ahtmpls@itu.int, ccamp <ccamp@ops.ietf.org>, pwe3 <pwe3@ietf.org>, L2VPN <l2vpn@ietf.org> X-Virus-Scanned: by amavisd-new at viciousnest.net Subject: [mpls] First version of the first MPLS-TP documents X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <https://www.ietf.org/mailman/private/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org All, the MPLS-TP work that started after the ITU-T acceptance of the JWT advice to work with the iETF, using IETF processes, to create a MPLS Transport Profile (MPLS-TP) within the IETF MPLS architecture. This effort has now produced a set of documents available in their first versions. In IETF terminology the documents are still "individual drafts", but will after discussion, review and updates hopefully become working groups documents. First I'd like to thank all the people that has put in efforts to make this possible, we are actually a bit better of than we planned. Thanks to all editors and contributing authors! When accepting documents as working group documents there are two criteria that working groups are looking at: - is this document addressing a problem that needs to be solved - is this document a good starting point in solving this problem The MPLS-TP documents are in some aspects special with respect to the IETF process, the JWT produced guidelines on which documents that needs to be included in the MPLS-TP. The MEAD team has since "improved and extended" the document list. This makes us pretty sure that the documents address problems that needs to be solved. However it is usually beneficial to have documents reviewed early in order to create a the starting point needed for solving the problem. We therefore now invite both IETF working groups (CCAMP, MPLS, L2VPN and PWE3), the MPLS Interoperability (MEAD) team, the JWT and the ITU-T Ad Hoc MPLS group to participate in this review. The newly produced documents are: 1. A Framework for MPLS in Transport Networks <draft-blb-mpls-tp-framework-00.txt> 2. MPLS Generic Associated Channel <draft-bocci-pwe3-mpls-tp-ge-ach-00.txt> 3. MPLS TP Network Management Requirements <draft-gray-mpls-tp-nm-req-00.txt> 4. MPLS-TP Requirements <draft-jenkins-mpls-mpls-tp-requirements-00.txt> 5. MPLS-TP OAM Analysis <draft-sprecher-mpls-tp-oam-analysis-00.txt> 6. Multiprotocol Label Switching Transport Profile Survivability Framework <draft-sprecher-mpls-tp-survive-fwk-00.txt> 7. Assignment of the Generic Associated Channel Header Label (GAL) <draft-vigoureux-mpls-tp-gal-00.txt> 8. Requirements for OAM in MPLS Transport Networks <draft-vigoureux-mpls-tp-oam-requirements-00.txt> 9. JWT Report on MPLS Architectural Considerations for a Transport Profile <draft-bryant-mpls-tp-jwt-report-00.txt> Note: This is a document is created to an easily referencable and permanent storage for the JWT conclusions and advice. The major part of the document are the JWT slides, since it is not possible to change the slides it is only the commentary part of the document that is possible to comment on. It is always possible to to send comments on these documents to the MPLS working group mailing list, for document #2 (The Generic MPLS Associated Channel) comments could also go to the PWE3 mailing list. However, we are setting up a dedicated mailing list for the MPLS-TP discussions: mpls-tp@ietf.org To subscribe to this list send a mail to mpls-tp-request@ietf.org, and confirm by replying or visiting the indicated web-page. The easiest way to find all the MPLS-TP documents is to use the IETF ID Tracker: https://datatracker.ietf.org/idtracker/ and put "mpls-tp" in the filename field. There is also a 10th document that people from the JWT has pointed out to us would be beneficial if it did go through the same review process. 10. "EXP field" renamed to "CoS Field" <draft-ietf-mpls-cosfield-def-04.txt> The document has been progressed within the IETF as a normal MPLS document, and has passed MPLS working group last call. However, we need to run it through working group last call in the working groups with RFCs that is updated by this document. The ITU-T Ad Hoc MPLS group will be invited to participate in this wg last call. A mail will go out shortly with details of this working group last call. The process in the future will be that when a MPLS-TP document is published or updated a note will be sent to the relevant working group (this is an automated IETF process), this note will also be forwarded to the ITU-T Ad Hoc MPLS group. Receiving such a note indicates that it is time to review and comment on the document. When a document goes into working group last call the mail initiating the last call will also be sent to the ITU-T Ad Hoc MPLS group. Receiving such a last call REQUIRES, as per the agreement within the JWT, that the ITU-T respond formally, indicating either that the document is accepted or indicating necessary changes. To test this process we'd appreciate very much if the ITU-T treated the upcoming last call on this document the same way. /Loa (chair of the MEAD team) -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.nu _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Jul 10 04:59:33 2008 Return-Path: <mpls-bounces@ietf.org> X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EEBC3A6A1D; Thu, 10 Jul 2008 04:59:33 -0700 (PDT) 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 0FF2E3A6932; Thu, 10 Jul 2008 04:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, 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 Ky+loTHdXEpF; Thu, 10 Jul 2008 04:59:31 -0700 (PDT) Received: from neo.viciousnest.net (neo.viciousnest.net [192.71.80.124]) by core3.amsl.com (Postfix) with ESMTP id F08203A69E0; Thu, 10 Jul 2008 04:59:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by neo.viciousnest.net (Postfix) with ESMTP id C39E81C2C5; Thu, 10 Jul 2008 13:59:44 +0200 (CEST) Received: from neo.viciousnest.net ([127.0.0.1]) by localhost (neo [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22062-01; Thu, 10 Jul 2008 13:59:43 +0200 (CEST) Received: from [127.0.0.1] (pat.acreo.se [217.151.195.214]) by neo.viciousnest.net (Postfix) with ESMTP id 0FA7F1C2BC; Thu, 10 Jul 2008 13:59:43 +0200 (CEST) Message-ID: <4875F9A1.5070408@pi.nu> Date: Thu, 10 Jul 2008 13:59:29 +0200 From: Loa Andersson <loa@pi.nu> User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: tsvwg@ietf.org, ahtmpls@itu.int, ccamp <ccamp@ops.ietf.org>, L2VPN <l2vpn@ietf.org>, pwe3 <pwe3@ietf.org>, mpls@ietf.org X-Virus-Scanned: by amavisd-new at viciousnest.net Subject: [mpls] multiple-working group last call on draft-ietf-mpls-cosfield-def-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <https://www.ietf.org/mailman/private/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org All, this mail initiates a two week multiple-working group last call on draft-ietf-mpls-cosfield-def-04.txt Background: The name "EXP field" of a three bit field in the MPLS shim header, and the statement in RFC3032 "For experimental use" has led other SDOs to believe that this field could be used for any type of experiments. The field has however from the start been intended to carry Class of Service (CoS) information. The draft therefore renames the field "Class of Service (CoS) Field". This is an update of RFC3032, and also of drafts that builds on RFC3032. This multiple-working group last call is therefore sent to working groups with RFCs that has been updated. The document has been through wg last call in the mpls working group, which I don't think will stop that wg producing new comments now, nor should it :) . This working group last call is for CCAMP, L2VPN, PWE3 and TSVWG. Since this is also of interest in the work we started on a Transport Profile for MPLS (MPLS-TP) we are also sending it to the Ad HoC Team on MPLS in the ITU-T. Please review and send comments to the mpls wg mailing list, or to the mailing list for mpls-tp discussion that just been set up: mpls-tp@ietf.org or directly to the mpls wg co-chairs before e.o.b. July 24. /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.nu _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Thu Jul 10 15:45:32 2008 Return-Path: <mpls-bounces@ietf.org> X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D3FC3A6AB3; Thu, 10 Jul 2008 15:45:32 -0700 (PDT) X-Original-To: mpls@lists.ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id F3E423A6A22; Thu, 10 Jul 2008 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: <20080710224501.F3E423A6A22@core3.amsl.com> Date: Thu, 10 Jul 2008 15:45:01 -0700 (PDT) Cc: mpls@lists.ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-upstream-label-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <https://www.ietf.org/mailman/private/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org --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 Upstream Label Assignment and Context-Specific Label Space Author(s) : R. Aggarwal, et al. Filename : draft-ietf-mpls-upstream-label-07.txt Pages : 13 Date : 2008-07-10 RFC 3031 limits the MPLS architecture to downstream-assigned MPLS labels. This document introduces the notion of upstream-assigned MPLS labels. It describes the procedures for upstream MPLS label assignment and introduces the concept of a "Context-Specific Label Space". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-upstream-label-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-upstream-label-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-10153730.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@ietf.org Fri Jul 11 09:39:31 2008 Return-Path: <mpls-bounces@ietf.org> X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCF7228C232; Fri, 11 Jul 2008 09:39:31 -0700 (PDT) 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 1319328C102 for <mpls@core3.amsl.com>; Wed, 9 Jul 2008 05:53:59 -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 m4aMjBa1udHJ for <mpls@core3.amsl.com>; Wed, 9 Jul 2008 05:53:57 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 72E1228C0FF for <mpls@ietf.org>; Wed, 9 Jul 2008 05:53:57 -0700 (PDT) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m69CrLPo002729; Wed, 9 Jul 2008 14:53:21 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 9 Jul 2008 14:53:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 14:53:38 +0200 Message-ID: <B128F666D4C8BD4FBF56CEAFB2DB66D702DD6EB8@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <48749BE0.5020404@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Some comments on draft-kompella-mpls-entropy-lables Thread-Index: AcjhtAJ6l39lIJ+VRg+9ehphnybqgAADdOkQ References: <48749BE0.5020404@cisco.com> From: "HENDERICKX Wim" <wim.henderickx@alcatel-lucent.be> To: <stbryant@cisco.com>, "Kireeti Kompella" <kireeti@juniper.net>, "Shane Amante" <shane@castlepoint.net>, "Clarence Filsfils" <cfilsfil@cisco.com> X-OriginalArrivalTime: 09 Jul 2008 12:53:21.0385 (UTC) FILETIME=[C454B590:01C8E1C2] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 X-Mailman-Approved-At: Fri, 11 Jul 2008 09:39:30 -0700 Cc: mpls@ietf.org Subject: Re: [mpls] Some comments on draft-kompella-mpls-entropy-lables X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <https://www.ietf.org/mailman/private/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Kireeti/Steward Some remarks in-line regarding TTL=0 for the entropy label Cheers, Wim -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Stewart Bryant Sent: woensdag 9 juli 2008 13:07 To: Kireeti Kompella; Shane Amante; Clarence Filsfils Cc: mpls@ietf.org Subject: [mpls] Some comments on draft-kompella-mpls-entropy-lables The Use of Entropy Labels in MPLS Forwarding draft-kompella-mpls-entropy-lables 1. Introduction Load balancing, or multi-pathing, is an attempt to balance traffic across a network by allowing the traffic to use several paths, not just a single shortest path. Load balancing has several benefits: it eases capacity planning; it can help absorb traffic surges by spreading them across several links; it allow better resilience by offering alternate paths should a link or node fail. SB> This last point is not correct as it stands. When a link or note SB> fails, it is good to have another high capacity path and if it's SB> ECMP you can use it for FRR, but the path itself will blackhole SB> until you take action. There are three key reasons why this is beneficial: 1. at the ingress of the LSP, MPLS encapsulation hasn't yet occurred, so deep inspection is not necessary; SB> Sure it's less deep, but it's still the standard tuple and most SB> folks would call that DPI. However I agree that it is less deep. 1.1. Motivation Currently, each MPLS LSR along a given path needs to individually infer the underlying protocol within a MPLS packet in order to then extract appropriate keys from the payload. Those keys are then used as input into a hash algorithm to determine the specific output interface on a LSR that is used for that given "microflow". Unfortunately, if the MPLS LSR is unable to infer the MPLS packet's payload (as is often the case), they typically will resort to using the topmost MPLS labels in the MPLS stack as keys to the load-hashing SB> Do you mean top or bottom? algorithm. The result is an extremely inequitable distribution of traffic across multiple equal-cost paths exiting that node, simply because the topmost MPLS labels are very coarse-grained forwarding labels that typically describe a next-hop, or provide some other type of mux/demux forwarding function, and do not describe the granularity of the underlying traffic. 2. Approaches 3. Entropy Labels An entropy label (as used here) is a label: 1. that is not used for forwarding; 2. that is not signaled; and 3. whose only purpose in the label stack is to provide "entropy" to improve load balancing. Entropy labels are generated by an ingress LSR, based entirely on load balancing information. However, they MUST not have values in the reserved label space (0-15). Entropy labels MUST be at the bottom of the label stack, and thus the "end-of-stack" bit in the label should be set. To ensure that they are not used inadvertently SB> MUST be set for forwarding, entropy labels SHOULD have a TTL of 0. SB> That is a good idea, we will put it in the PW draft. WH> If we use TTL=0 and we use PHP on the egress LER with BGP shortcuts, the packet on the egress LER will be received with TTL=0. The egress LER will drop this packet normally. I see 3 options for this: 1. Either use TTL=1 for the entropy label 2. Do something different for BGP shortcuts, introduce a service label like is done for 6PE e.g., but this requires changes from today's implementations and is always hard. 3. Avoid PHP with entropy label , but this changes again current deployment models which is always though. For me option 1 seems the best, unless I miss something. Since entropy labels are generated by the ingress LSR, an egress LSR MUST be able to tell unambiguously that a given label is an entropy label. This of course depends on the underlying application. If any ambiguity is possible, the label above the entropy label MUST be an "entropy label indicator" (ELI), which says that the following label is an entropy label. The ELI may be signaled, or may be a reserved label reserved specifically for this purpose. Fortunately, for many applications, the use of entropy labels is unambiguous, and does not need an ELI. SB> I would be worried about using a reserved label for this. SB> I don't think its actually needed and they are in short supply. SB> We are going to need a forwarding path that gets context from a SB> signaled label and discards the following label for a number of the SB> cases, so we should try to use that method everywhere. 4. Forwarding and Load Balancing Behaviors for Entropy Labels Thus, transit LSRs are almost unaffected by the use of entropy labels. If transit LSRs were programmed to use a subset of the label stack, they may have to be reconfigured to use the full stack. But otherwise, no changes are needed. SB> Surely they just need to use the bottom of stack? 4.3. Egress LSRs SB> Should you consider PHP of entropy labels. 6. Security Considerations Having security is a Good Thing. SB> Firstly it's worth noting in the Security section that care is needed not SB> to make this label some sort of covert channel. SB> SB> Secondly kind of the opposite of the above. You called it an entropy SB> label and we (who independently thought this up) called it a load SB> balance label. We should pick on or the other. However that causes SB> to wonder if there is some other use that we will find for that 20 SB> bits? If so perhaps we should call it a context label? SB> I put that remark down here because it flys in the face of my first SB> comment about covert channels. 7. Acknowledgments We wish to thank Ulrich Drafz for his contributions, as well as the entire "hash label" team for their valuable comments and discussion. SB> There are so few of us we could probably be named :) _______________________________________________ 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 mpls-bounces@ietf.org Fri Jul 11 09:39:32 2008 Return-Path: <mpls-bounces@ietf.org> X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83F2828C244; Fri, 11 Jul 2008 09:39:32 -0700 (PDT) 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 3E0D13A693E for <mpls@core3.amsl.com>; Wed, 9 Jul 2008 06:12:01 -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 4jrG5g8qTP6G for <mpls@core3.amsl.com>; Wed, 9 Jul 2008 06:12:00 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by core3.amsl.com (Postfix) with ESMTP id 11FE83A68E7 for <mpls@ietf.org>; Wed, 9 Jul 2008 06:11:59 -0700 (PDT) Received: from FRVELSBHS06.ad2.ad.alcatel.com (frvelsbhs06.ad2.ad.alcatel.com [155.132.6.78]) by smail5.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id m69DBLOk016173; Wed, 9 Jul 2008 15:11:21 +0200 Received: from FRVELSMBS22.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS06.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.2499); Wed, 9 Jul 2008 15:11:21 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 9 Jul 2008 15:11:39 +0200 Message-ID: <B128F666D4C8BD4FBF56CEAFB2DB66D702DD6EDC@FRVELSMBS22.ad2.ad.alcatel.com> In-Reply-To: <4874B7B2.9020702@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] Some comments on draft-kompella-mpls-entropy-lables Thread-Index: AcjhxIhfMUtJdYB7SzCT14K1nn0uCwAAHwpw References: <48749BE0.5020404@cisco.com> <B128F666D4C8BD4FBF56CEAFB2DB66D702DD6EB8@FRVELSMBS22.ad2.ad.alcatel.com> <4874B7B2.9020702@cisco.com> From: "HENDERICKX Wim" <wim.henderickx@alcatel-lucent.be> To: <stbryant@cisco.com> X-OriginalArrivalTime: 09 Jul 2008 13:11:21.0912 (UTC) FILETIME=[48600B80:01C8E1C5] X-Scanned-By: MIMEDefang 2.57 on 155.132.188.13 X-Mailman-Approved-At: Fri, 11 Jul 2008 09:39:30 -0700 Cc: Clarence Filsfils <cfilsfil@cisco.com>, mpls@ietf.org Subject: Re: [mpls] Some comments on draft-kompella-mpls-entropy-lables X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <https://www.ietf.org/mailman/private/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Steward, Agreed, we should define one architecture which works in all scenarios according to me. PWE is the priority though, but we should architect it for IP-VPN and BGP shortcuts, etc. Are you in favor of TTL=1? The other options might be to much impact for existing deployments according to me. Cheers, Wim -----Original Message----- From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: woensdag 9 juli 2008 15:06 To: HENDERICKX Wim Cc: Kireeti Kompella; Shane Amante; Clarence Filsfils; mpls@ietf.org Subject: Re: [mpls] Some comments on draft-kompella-mpls-entropy-lables Wim > > Entropy labels are generated by an ingress LSR, based entirely on > load balancing information. However, they MUST not have values in > the reserved label space (0-15). Entropy labels MUST be at the > bottom of the label stack, and thus the "end-of-stack" bit in the > label should be set. To ensure that they are not used > inadvertently > SB> MUST be set > for forwarding, entropy labels SHOULD have a TTL of 0. > SB> That is a good idea, we will put it in the PW draft. > > WH> If we use TTL=0 and we use PHP on the egress LER with BGP > WH> shortcuts, > the packet on the egress LER will be received with TTL=0. The egress > LER will drop this packet normally. > > I see 3 options for this: > 1. Either use TTL=1 for the entropy label 2. Do something different > for BGP shortcuts, introduce a service label like is done for 6PE > e.g., but this requires changes from today's implementations and is > always hard. > 3. Avoid PHP with entropy label , but this changes again current > deployment models which is always though. > > For me option 1 seems the best, unless I miss something. > > Since entropy labels are generated by the ingress LSR, an egress LSR > MUST be able to tell unambiguously that a given label is an entropy > label. This of course depends on the underlying application. If any > ambiguity is possible, the label above the entropy label MUST be an > "entropy label indicator" (ELI), which says that the following label > is an entropy label. The ELI may be signaled, or may be a reserved > label reserved specifically for this purpose. Fortunately, for many > applications, the use of entropy labels is unambiguous, and does not > need an ELI. > > That is a good point. In the case of PWE3 TTL=0 would work because we still have the PW label after PHP of the PE delivery label. However PWE3 should adopt the same policy as MPLS. Stewart _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Fri Jul 11 09:58:19 2008 Return-Path: <mpls-bounces@ietf.org> X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5F6F28C243; Fri, 11 Jul 2008 09:58:19 -0700 (PDT) X-Original-To: mpls@lists.ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 5D9163A6B84; Fri, 11 Jul 2008 09:58:17 -0700 (PDT) X-idtracker: yes From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> Message-Id: <20080711165818.5D9163A6B84@core3.amsl.com> Date: Fri, 11 Jul 2008 09:58:18 -0700 (PDT) Cc: mpls mailing list <mpls@lists.ietf.org>, mpls chair <mpls-chairs@tools.ietf.org>, Internet Architecture Board <iab@iab.org>, RFC Editor <rfc-editor@rfc-editor.org> Subject: [mpls] Protocol Action: 'MPLS Upstream Label Assignment and Context-Specific Label Space' to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <https://www.ietf.org/mailman/private/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org The IESG has approved the following document: - 'MPLS Upstream Label Assignment and Context-Specific Label Space ' <draft-ietf-mpls-upstream-label-07.txt> as a Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Ross Callon and David Ward. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-upstream-label-07.txt Technical Summary RFC 3031 limits the MPLS architecture to downstream-assigned MPLS labels. This document introduces the notion of upstream-assigned MPLS labels. It describes the procedures for upstream MPLS label assignment and introduces the concept of a "Context-Specific Label Space". Note that upstream label assignment is specifically useful for supporting multicast MPLS across multicast LANs. Working Group Summary This document, along with one other (draft-ietf-mpls-multicast- encaps) are the forerunners on a set of multicast documents that are being worked on and have been widely discussed in the working group and will be submitted to the IESG once these two documents are approved. Document Quality Upstream label assignment is not something that you implement on its own, but rather something that is used by other documents (specifically other documents related to MPLS multicast). This is the basis for other documents that will be submitted in the near (?) future. Personnel Loa Andersson is the document shepherd, however both WG chairs (Loa and George) have reviewed the document. Ross Callon is the responsible AD. There are no IANA actions required for this document (as specified in the Null IANA section). _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Sun Jul 13 20:48:20 2008 Return-Path: <mpls-bounces@ietf.org> X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C58A3A67CC; Sun, 13 Jul 2008 20:48:20 -0700 (PDT) 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 89AE43A67CC for <mpls@core3.amsl.com>; Sun, 13 Jul 2008 20:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.817 X-Spam-Level: X-Spam-Status: No, score=-0.817 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] 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 Ku70HuDcPXRl for <mpls@core3.amsl.com>; Sun, 13 Jul 2008 20:48:17 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id CABE03A67B5 for <mpls@ietf.org>; Sun, 13 Jul 2008 20:48:17 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id DBB3F268677; Sun, 13 Jul 2008 21:48:42 -0600 (MDT) Received: from pmac.castlepoint.net (71-218-99-114.hlrn.qwest.net [71.218.99.114]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Sun, 13 Jul 2008 21:48:42 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=71.218.99.114; client-port=3557; syn-fingerprint=65535:55:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Message-Id: <D9DA6050-BD2E-43B9-8E59-998FE5B7C7C2@castlepoint.net> From: Shane Amante <shane@castlepoint.net> To: George Swallow <swallow@cisco.com> In-Reply-To: <C49AAAD5.4372%swallow@cisco.com> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Sun, 13 Jul 2008 21:48:24 -0600 References: <C49AAAD5.4372%swallow@cisco.com> X-Mailer: Apple Mail (2.928.1) Cc: mpls@ietf.org, "Clarence Filsfils \(cfilsfil\)" <cfilsfil@cisco.com>, "Stewart Bryant \(stbryant\)" <stbryant@cisco.com> Subject: Re: [mpls] Some comments on draft-kompella-mpls-entropy-lables X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <https://www.ietf.org/mailman/private/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org George, On Jul 9, 2008, at 3:50 PM, George Swallow wrote: > I disagree with the text below. It is my understanding that a lot > of equipment does ECMP by looking for EOS, checking the first nibble > for 0100b and if true running the usual IPv4 load-balancing. Only > if it is not 0100b (and maybe 0110b) does it actual use some portion > of the label stack. This is why in PW, the first nibble of the CW > is 0000b. > > It seems to me the only way to be sure that this will work is to > define a new FEC in LDP. This would be equivalent to an IP FEC, but > say that you must load balance on the label stack only. Although an operator could, at the appropriate point in time, (manually) configure the transit LSR's to only pay attention to the label stack for load-balancing, this suggestion is likely better for backwards compatibility, so we'll take it under advisement. Thanks, -shane > ...George > > 4.2. Transit LSR > > Transit LSRs have no change in forwarding behavior. For load > balancing, transit LSRs SHOULD use the whole label stack (e.g., for > computing the load balance hash). Transit LSRs MAY choose to look > beyond the label stack for further load balancing information; > however, if entropy labels are being used, this may not be very > useful. In a mixed environment (or for backward compatibility), > this > is the simplest approach. > > Thus, transit LSRs are almost unaffected by the use of entropy > labels. If transit LSRs were programmed to use a subset of the > label > stack, they may have to be reconfigured to use the full stack. But > otherwise, no changes are needed. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Sun Jul 13 21:21:10 2008 Return-Path: <mpls-bounces@ietf.org> X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 284233A684C; Sun, 13 Jul 2008 21:21:10 -0700 (PDT) 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 9328F3A684C for <mpls@core3.amsl.com>; Sun, 13 Jul 2008 21:21:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.967 X-Spam-Level: X-Spam-Status: No, score=-0.967 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482] 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 Ivr51MZ4v8-w for <mpls@core3.amsl.com>; Sun, 13 Jul 2008 21:21:07 -0700 (PDT) Received: from dog.tcb.net (dog.tcb.net [64.78.150.133]) by core3.amsl.com (Postfix) with ESMTP id C33B63A6781 for <mpls@ietf.org>; Sun, 13 Jul 2008 21:21:07 -0700 (PDT) Received: by dog.tcb.net (Postfix, from userid 0) id DCAA0268677; Sun, 13 Jul 2008 22:21:32 -0600 (MDT) Received: from pmac.castlepoint.net (71-218-99-114.hlrn.qwest.net [71.218.99.114]) (authenticated-user smtp) (TLSv1/SSLv3 AES128-SHA 128/128) by dog.tcb.net with SMTP; Sun, 13 Jul 2008 22:21:32 -0600 (MDT) (envelope-from shane@castlepoint.net) X-Avenger: version=0.7.8; receiver=dog.tcb.net; client-ip=71.218.99.114; client-port=3434; syn-fingerprint=65535:55:1:64:M1460,N,W3,N,N,T,S MacOS 10.4.8; data-bytes=0 Message-Id: <80558879-52B9-4946-8490-06A9678A9C8A@castlepoint.net> From: Shane Amante <shane@castlepoint.net> To: stbryant@cisco.com In-Reply-To: <48749BE0.5020404@cisco.com> Mime-Version: 1.0 (Apple Message framework v928.1) Date: Sun, 13 Jul 2008 22:21:17 -0600 References: <48749BE0.5020404@cisco.com> X-Mailer: Apple Mail (2.928.1) Cc: mpls@ietf.org, Clarence Filsfils <cfilsfil@cisco.com> Subject: Re: [mpls] Some comments on draft-kompella-mpls-entropy-lables X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <https://www.ietf.org/mailman/private/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Stewart, Finishing the second half of this e-mail. Apologies for the delay. On Jul 9, 2008, at 5:07 AM, Stewart Bryant wrote: > 6. Security Considerations > > Having security is a Good Thing. > > SB> Firstly it's worth noting in the Security section that care is > needed not > SB> to make this label some sort of covert channel. I'm not sure I understand why you think an entropy label could become a 'covert channel'. Do you mean for the purposes of quickly identifying a microflow? If so, that risk already exists today, (by looking for EOS + 0100b, etc.). > SB> Secondly kind of the opposite of the above. You called it an > entropy > SB> label and we (who independently thought this up) called it a load > SB> balance label. We should pick on or the other. However that causes I understand where you're coming from, but one advantage of calling this an entropy label is that it's at the Tunnel Label level vs. the Load-Balance Label, which is at the PW level. While "entropy label" might not be the coolest name, perhaps it's worth keeping them different to avoid confusion down the road? > SB> to wonder if there is some other use that we will find for that 20 > SB> bits? If so perhaps we should call it a context label? > SB> I put that remark down here because it flys in the face of my > SB> first comment about covert channels. I would advocate a more narrow definition of a entropy-label, unless you can think of some actual use cases where we would re-use these 20- bits. > 7. Acknowledgments > > We wish to thank Ulrich Drafz for his contributions, as well as the > entire "hash label" team for their valuable comments and discussion. > > SB> There are so few of us we could probably be named :) We will do that in the next rev. Thanks, -shane _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Jul 14 00:00:04 2008 Return-Path: <mpls-bounces@ietf.org> X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D2043A6AC3; Mon, 14 Jul 2008 00:00:04 -0700 (PDT) X-Original-To: mpls@lists.ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4C78E3A6A98; Mon, 14 Jul 2008 00:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20080714070001.4C78E3A6A98@core3.amsl.com> Date: Mon, 14 Jul 2008 00:00:01 -0700 (PDT) Cc: mpls@lists.ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-mpls-and-gmpls-security-framework-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <https://www.ietf.org/mailman/private/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org --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-03.txt Pages : 57 Date : 2008-07-13 This document provides a security framework for Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) Networks (MPLS and GMPLS are described in [RFC3031] and [RFC3945]). 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 Fang, et al. Informational [page 1] MPLS/GMPLS Security framework July 2008 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-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-mpls-and-gmpls-security-framework-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-13234943.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --NextPart-- From mpls-bounces@ietf.org Mon Jul 14 05:59:13 2008 Return-Path: <mpls-bounces@ietf.org> X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC1A928C248; Mon, 14 Jul 2008 05:59:13 -0700 (PDT) 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 C4E093A69B9; Mon, 14 Jul 2008 05:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.22 X-Spam-Level: X-Spam-Status: No, score=-2.22 tagged_above=-999 required=5 tests=[AWL=0.379, 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 rTmHasv+g0hl; Mon, 14 Jul 2008 05:59:10 -0700 (PDT) Received: from neo.viciousnest.net (neo.viciousnest.net [192.71.80.124]) by core3.amsl.com (Postfix) with ESMTP id C5AED3A6943; Mon, 14 Jul 2008 05:59:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by neo.viciousnest.net (Postfix) with ESMTP id 948A9285E6; Mon, 14 Jul 2008 14:59:33 +0200 (CEST) Received: from neo.viciousnest.net ([127.0.0.1]) by localhost (neo [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08118-07; Mon, 14 Jul 2008 14:59:30 +0200 (CEST) Received: from [127.0.0.1] (pat.acreo.se [217.151.195.214]) by neo.viciousnest.net (Postfix) with ESMTP id 21B97285CB; Mon, 14 Jul 2008 14:59:30 +0200 (CEST) Message-ID: <487B4DAC.5050306@pi.nu> Date: Mon, 14 Jul 2008 14:59:24 +0200 From: Loa Andersson <loa@pi.nu> User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: mpls@ietf.org, L2VPN <l2vpn@ietf.org>, ccamp <ccamp@ops.ietf.org>, pwe3 <pwe3@ietf.org> X-Virus-Scanned: by amavisd-new at viciousnest.net Subject: [mpls] mpls wg agenda for Dublin X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <https://www.ietf.org/mailman/private/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org All, I've just uploaded a preliminary agenda for the MPLS wg meeting in Dublin. First: I've a strong feeling that I dropped one request for an agenda slot, so could all of you who have requested slots check if it got on the the agenda. Second: Pleas note that the agenda covers both MPLS wg meetings in Dublin, Monday morning (the "traditional" wg meeting) and Wednesday (the meeting on MPLS-TP). Though this meeting is formally a MPLS wg meeting, since the focus is MPLS-TP it is from very important aspects a joint meeting with pwe3, ccamp and l2vpn, this mails is therefore sent to these working groups as well. The agenda is available at; http://www.ietf.org/proceedings/08jul/agenda/mpls.txt /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.nu _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Jul 14 06:48:38 2008 Return-Path: <mpls-bounces@ietf.org> X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3185228C15A; Mon, 14 Jul 2008 06:48:38 -0700 (PDT) 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 2E4F328C15A for <mpls@core3.amsl.com>; Mon, 14 Jul 2008 06:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.938 X-Spam-Level: X-Spam-Status: No, score=-1.938 tagged_above=-999 required=5 tests=[AWL=0.660, 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 LobXHJ8P8gMV for <mpls@core3.amsl.com>; Mon, 14 Jul 2008 06:48:36 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 944E628C13D for <mpls@ietf.org>; Mon, 14 Jul 2008 06:48:35 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m6EDmsBV006618; Mon, 14 Jul 2008 14:48:54 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m6EDmqrW006540; Mon, 14 Jul 2008 14:48:54 +0100 Message-ID: <00b301c8e5b8$59a4e0e0$0200a8c0@your029b8cecfe> From: "Adrian Farrel" <adrian@olddog.co.uk> To: "Nic Neate" <Nic.Neate@dataconnection.com>, "Rahul Aggarwal" <rahul@juniper.net> References: <8AC1AD08D396174DBC4E6D44EFACCFB105D6C6CC@enfimail2.datcon.co.uk><20080707175847.P73691@sapphire.juniper.net> <8AC1AD08D396174DBC4E6D44EFACCFB105DA61C1@enfimail2.datcon.co.uk> Date: Mon, 14 Jul 2008 14:48:47 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Cc: mpls@ietf.org Subject: Re: [mpls] RFC 4875 ERO processing details X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel <adrian@olddog.co.uk> List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <https://www.ietf.org/mailman/private/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Hi Nic, I think I was driving this function with some support from Igor when the RFC was still a draft. As you observe, the point at which one label splits into two labels (even with the same outgoing interface) is a branch in the data plane. You are also correct that two Resv messages will be required because each can carry just one Label object. Now, if the node that is the branch in the data plane wishes to control which label is used on the two downstream segments, it must signal this to its neighbor. This would certainly be the case in the example you cite, where the labels are included in the ERO/SERO. But, the way that the label is conveyed from an upstream node to its neighbor is in a Label_Set or Suggested_Label object and you will observe that we only allow one of these on a Path message. QED you need two Path messages from the branch point. Cheers, Adrian ----- Original Message ----- From: "Nic Neate" <Nic.Neate@dataconnection.com> To: "Rahul Aggarwal" <rahul@juniper.net> Cc: <mpls@ietf.org> Sent: Tuesday, July 08, 2008 12:16 PM Subject: Re: [mpls] RFC 4875 ERO processing details > Hi Rahul, > >> > >> > (1) Explicit label processing details >> > >> > Explicit labels could be included in an ERO/SERO to specify two S2L >> > sub-LSPs with the same next hop but different labels (for >> example, in >> > an optical network where different wavelengths are required >> to reach >> > different leaf nodes). >> >> In this case is it not the responsibility of the branch LSR >> to replicate the incoming label onto two different outgoing labels? >> >> rahul >> > > Sure, this is definitely a branch point in the data plane. My question > is whether it also needs to be a branch point in the control plane. Do > the S2L sub-LSPs need to be signaled in different Path messages, given > that their next hop is the same? > > My reading of section 6.2 of the RFC is that it is not necessary. If a > single Path message is used then the downstream LSR can still use > different Resvs for each S2L sub-LSP to signal the different labels even > though both S2L sub-LSPs are in the same sub-group. > > On the other hand, the RFC states that the downstream LSR SHOULD use the > same label across multiple Resv messages for the same P2MP LSP - which > is not possible in this case. > > What do you think the correct way to signal this is? > > Do you have an opinion on the ERO compression question below as well? > > Thanks, > > Nic > > >> Both S2L sub-LSPs could be signaled in a single >> > Path message (although ERO compression for the next hop >> would not be >> > possible). >> > >> > In the reverse direction, separate Resv messages must be >> used for each >> > S2L sub-LSPs because a single Resv MUST use the same label in all >> > filterspecs for the same P2MP LSP (section 6.2). >> > >> > Is it therefore allowed for S2L sub-LSPs in the same >> sub-group to be >> > signaled in different Resvs with different labels, or should the >> > upstream LSR signal them in different sub-groups, and therefore >> > different Path messages? >> > >> > >> > (2) ERO compression details (section 4.5) >> > >> > Last paragraph in section 4.5 of the RFC states the following: >> > >> > All >> LSRs need to >> > process the ERO corresponding to the first S2L sub-LSP. >> An LSR needs >> > to process an S2L sub-LSP descriptor for a subsequent S2L sub-LSP >> > only if the first hop in the corresponding SERO is a >> local address of >> > that LSR. The branch LSR that is the first hop of an >> SERO propagates >> > the corresponding S2L sub-LSP downstream. >> > >> > I think that implies the following ERO compression technique. >> > - In Path messages sent by the source, all SEROs are >> specified right >> > from the first branch point in the P2MP LSP. >> > - At each branch point, SERO hops that come before the next branch >> > point are stripped off before Path messages are forwarded. >> > >> > Thus, at any point in the P2MP tree, the hops to the next >> branch point >> > are only specified once in the ERO, but thereafter all >> SEROs are fully >> > specified even if they have large sections in common. >> > >> > That is not the ERO compression technique described in the example >> > earlier in section 4.5, and also not optimal for RSVP Path >> message size. >> > That suggests that the statement that "An LSR needs to >> process an S2L >> > sub-LSP descriptor for a subsequent S2L sub-LSP only if the >> first hop >> > in the corresponding SERO is a local address of that LSR" >> is inaccurate. >> > Instead >> > - each LSR needs to check the first hop of all SEROs >> > - if an LSR is the first hop of any SERO then it is a branch point >> > - a branch point needs to further analyze all SEROs to determine >> > which branch each S2L sub-LSPs belongs to. >> > >> > Further, failure to do that could lead to routing errors. Is that >> > understanding correct? >> > >> > >> > Thanks, >> > >> > >> > Nic Neate >> > Data Connection Ltd. >> > _______________________________________________ >> > 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 > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Jul 14 07:03:38 2008 Return-Path: <mpls-bounces@ietf.org> X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DD8F3A68C9; Mon, 14 Jul 2008 07:03:38 -0700 (PDT) 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 ACA243A686B for <mpls@core3.amsl.com>; Mon, 14 Jul 2008 07:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=0.495, 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 RAeOp-W5YCha for <mpls@core3.amsl.com>; Mon, 14 Jul 2008 07:03:36 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by core3.amsl.com (Postfix) with ESMTP id 5C6A03A6903 for <mpls@ietf.org>; Mon, 14 Jul 2008 07:03:36 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m6EE3x3C016469; Mon, 14 Jul 2008 15:04:00 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m6EE3sn2016367; Mon, 14 Jul 2008 15:03:59 +0100 Message-ID: <00c201c8e5ba$752fe510$0200a8c0@your029b8cecfe> From: "Adrian Farrel" <adrian@olddog.co.uk> To: "Nic Neate" <Nic.Neate@dataconnection.com>, <mpls@ietf.org> References: <8AC1AD08D396174DBC4E6D44EFACCFB105D6C6CC@enfimail2.datcon.co.uk> Date: Mon, 14 Jul 2008 14:57:37 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [mpls] RFC 4875 ERO processing details X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel <adrian@olddog.co.uk> List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <https://www.ietf.org/mailman/private/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Nic, > (2) ERO compression details (section 4.5) > > Last paragraph in section 4.5 of the RFC states the following: > > All LSRs need to > process the ERO corresponding to the first S2L sub-LSP. An LSR needs > to process an S2L sub-LSP descriptor for a subsequent S2L sub-LSP > only if the first hop in the corresponding SERO is a local address of > that LSR. The branch LSR that is the first hop of an SERO propagates > the corresponding S2L sub-LSP downstream. > > I think that implies the following ERO compression technique. > - In Path messages sent by the source, all SEROs are specified right > from the first branch point in the P2MP LSP. > - At each branch point, SERO hops that come before the next branch > point are stripped off before Path messages are forwarded. I think you should re-read the example in the RFC. Each SERO runs from a branch point to a leaf. Compressed SEROs do not share any hops when the S2L LSPs they describe share resources. if two S2L LSPs follow the same path from some branch point LSR-A, and diverge downstream at LSR-B, one of the SEROs will begin at LSR-A and the other at LSR-B. Thus, there is no stripping of SEROs to be performed. > Thus, at any point in the P2MP tree, the hops to the next branch point > are only specified once in the ERO, but thereafter all SEROs are fully > specified even if they have large sections in common. As above. Look at the example in the RFC. I don't see any contradiction with the section 4.5 text. > That is not the ERO compression technique described in the example > earlier in section 4.5, and also not optimal for RSVP Path message size. > That suggests that the statement that "An LSR needs to process an S2L > sub-LSP descriptor for a subsequent S2L sub-LSP only if the first hop in > the corresponding SERO is a local address of that LSR" is inaccurate. > Instead > - each LSR needs to check the first hop of all SEROs > - if an LSR is the first hop of any SERO then it is a branch point > - a branch point needs to further analyze all SEROs to determine which > branch each S2L sub-LSPs belongs to. > > Further, failure to do that could lead to routing errors. Is that > understanding correct? Adrian _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Jul 14 07:13:23 2008 Return-Path: <mpls-bounces@ietf.org> X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C75A33A6809; Mon, 14 Jul 2008 07:13:23 -0700 (PDT) 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 408E13A6809 for <mpls@core3.amsl.com>; Mon, 14 Jul 2008 07:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[AWL=0.396, 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 IThy85FvP28o for <mpls@core3.amsl.com>; Mon, 14 Jul 2008 07:13:21 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 0D0F03A67EE for <mpls@ietf.org>; Mon, 14 Jul 2008 07:13:20 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m6EEDgr0022129; Mon, 14 Jul 2008 15:13:42 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m6EEDerv022095; Mon, 14 Jul 2008 15:13:42 +0100 Message-ID: <00d901c8e5bb$d064a140$0200a8c0@your029b8cecfe> From: "Adrian Farrel" <adrian@olddog.co.uk> To: "Nic Neate" <Nic.Neate@dataconnection.com>, <mpls@ietf.org> References: <8AC1AD08D396174DBC4E6D44EFACCFB105D6C6C0@enfimail2.datcon.co.uk> Date: Mon, 14 Jul 2008 15:13:17 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [mpls] RFC 4875 Notify forwarding by transit LSRs (section 8.1) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel <adrian@olddog.co.uk> List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <https://www.ietf.org/mailman/private/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Nic, The problem you describe applies to many protection domain problems (such as segment protection). It is solved by the concept of "nested" Notify Requesters. See RFC4873. Adrian ----- Original Message ----- From: "Nic Neate" <Nic.Neate@dataconnection.com> To: <mpls@ietf.org> Sent: Monday, July 07, 2008 4:32 PM Subject: [mpls] RFC 4875 Notify forwarding by transit LSRs (section 8.1) Hi all, This is the second potential problem in RFC 4875 I'd like to raise. Please let me know if this is a concern for anyone, or if I've misunderstood something. Section 8.1 (http://tools.ietf.org/html/rfc4875#section-8.1) defines the rules for handling Notify messages for P2MP LSPs. They include the following. - All LSRs which change the sub-group originator ID in a Path message need to intercept both upstream and downstream Notifies so that they can re-write the sub-group identifiers in them then forward them on to the original Notify requestor. They achieve this by re-writing the Notify node address in the NOTIFY_REQUEST object. - All branch LSRs which receive muliple NOTIFY_REQUESTs in Resvs on different downstream branches need to intercept Notifies being sent downstream, duplicate them, and send a copy to all downstream Notify requestors. Again, they achieve this by re-writing the Notify node address. As a result, Notify messages for a P2MP LSP are likely to travel via a number of transit LSRs rather than being sent directly to the original Notify requestor. The purpose of the Notify message is to enable "expedited notification of failures and other events to nodes responsible for restoring failed LSPs" (RFC 3473 section 4). For example, the Notify message is used by GMPLS end-to-end protection (RFC 4872) for communicating LSP failures between ingress and egress LSRs and co-ordinating protection switching to a recovery LSP. The requirement to have Notify messages forwarded by transit LSRs for P2MP LSPs is going to make them much less useful. For example, if an LSR which has re-written the sub-group originator IDs fails, causing a data plane fault in the P2MP LSP, it will be impossible to use Notifies to quickly communicate that failure between source and leaf LSRs. I think this is a significant degradation to the usefulness of Notify messages that is worth addressing. Arguably this is a wider issue that also applies LSPs traversing NNIs between different domains, where the border routers also intercept Notifies. However, it may still be worth considering a solution to just the P2MP LSP problem for now, to facilitate the use of existing protection techniques for P2MP LSPs. Is anyone else interested in addressing this? Thanks, Nic Neate Data Connection Ltd. -------------------------------------------------------------------------------- > _______________________________________________ > 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 mpls-bounces@ietf.org Mon Jul 14 07:57:03 2008 Return-Path: <mpls-bounces@ietf.org> X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 093193A6AC5; Mon, 14 Jul 2008 07:57:03 -0700 (PDT) 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 3E0923A6ABD for <mpls@core3.amsl.com>; Mon, 14 Jul 2008 07:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.268 X-Spam-Level: X-Spam-Status: No, score=-2.268 tagged_above=-999 required=5 tests=[AWL=0.330, 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 YEf6yE31MD1C for <mpls@core3.amsl.com>; Mon, 14 Jul 2008 07:57:01 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 1614F3A6AC4 for <mpls@ietf.org>; Mon, 14 Jul 2008 07:57:00 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m6EEDgxn022109; Mon, 14 Jul 2008 15:13:42 +0100 Received: from your029b8cecfe (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m6EEDeru022095; Mon, 14 Jul 2008 15:13:42 +0100 Message-ID: <00d801c8e5bb$d03294c0$0200a8c0@your029b8cecfe> From: "Adrian Farrel" <adrian@olddog.co.uk> To: "Nic Neate" <Nic.Neate@dataconnection.com>, <mpls@ietf.org> References: <8AC1AD08D396174DBC4E6D44EFACCFB105D6C6BB@enfimail2.datcon.co.uk> Date: Mon, 14 Jul 2008 15:07:34 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [mpls] RFC 4875 re-merge procedures (section 18) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel <adrian@olddog.co.uk> List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <https://www.ietf.org/mailman/private/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Nic, again. > Section 18 the RFC 4875 (http://tools.ietf.org/html/rfc4875#section-18) > defines the procedures for an LSR that receives multiple Path messages > for the same P2MP LSP from different PHOPs. The intention is to prevent > data duplication in that scenario. > > I think the procedures in the RFC are insufficient for the following > reasons. The key point here is that an LSR following the procedures > defined in the RFC may cause data loss during sub-group re-optimization. > > - Section 18 discusses dynamic reroute and make-before-break but not > sub-group re-optimization. The latter (defined in section 14.2) is > another case where an LSR could receive multiple Path messages for the > same P2MP LSP from different PHOPs. > > - LSRs are told to differentiate re-merge and cross-over cases from > dynamic reroute by checking whether the sets of S2L sub-LSPs in the > upstream Path messages overlap. If they do not then it is > re-merge/cross-over (see section 18.1 paragraph 2). However, both > dynamic reroute and sub-group re-optimization could cause an LSR to > receive a new Path message containing a set of S2L sub-LSPs that does > not overlap with its existing path state. Consider the case where > re-optimization causes an LSR to become on the path for one S2L sub-LSP > and be removed from the path of another S2L sub-LSP. > > - Having falsely identified a sub-group re-optimization (or dynamic > reroute) as a re-merge, an LSR may (if so configured) send a PathErr for > its existing path state with the Path_State_Removed flag set (section > 18.1.1). That will cause data loss if the new, re-optimized sub-tree > has not yet been fully set up. No, I don't think that responding to a Path message with a PathErr will cause data loss as no Resv has yet flowed. Note that a little thought by the node performing the reoptimization makes sure that this situation does not arrise. > - Finally, as a separate point, it's worth noting that if the > downstream interfaces for two Path messages are the same, but the > downstream labels are not, then that is cross-over rather than re-merge > and needs to be handled as such. That case is omitted by the RFC, which > only discusses downstream interfaces (section 18.1 paragraph 3). > > I'd appreciate comments on whether this is indeed a problem that needs > solving. (If it is then I have some ideas on how that might be > achieved.) I don't believe there is a problem here. Adrian _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Jul 14 15:15:03 2008 Return-Path: <mpls-bounces@ietf.org> X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BB2E28C308; Mon, 14 Jul 2008 15:15:03 -0700 (PDT) X-Original-To: mpls@lists.ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id DFD713A68D9; Mon, 14 Jul 2008 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: <20080714221501.DFD713A68D9@core3.amsl.com> Date: Mon, 14 Jul 2008 15:15:01 -0700 (PDT) Cc: mpls@lists.ietf.org Subject: [mpls] I-D Action:draft-ietf-mpls-remote-lsp-ping-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <https://www.ietf.org/mailman/private/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org --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 : Proxy LSP Ping Author(s) : G. Swallow, et al. Filename : draft-ietf-mpls-remote-lsp-ping-02.txt Pages : 20 Date : 2008-07-14 This document defines a means of remotely initiating Multiprocal Label Switched Protocol Pings on Label Switched Paths. A proxy ping request is sent to any Label Switching Routers along a Label Switched Path. The primary motivations for this facility are first to limit the number of messages and related processing when using LSP Ping in large Point-to-Multipoint LSPs, and second to enable leaf to root tracing.Contents A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mpls-remote-lsp-ping-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-remote-lsp-ping-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2008-07-14150447.I-D@ietf.org> --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --NextPart-- From cacuman@antide.com Mon Jul 14 19:44:52 2008 Return-Path: <cacuman@antide.com> X-Original-To: ietfarch-mpls-archive@core3.amsl.com Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AF0228C0DC; Mon, 14 Jul 2008 19:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.955 X-Spam-Level: **** X-Spam-Status: No, score=4.955 tagged_above=-999 required=5 tests=[BAYES_80=2, FB_QUALITY_REPLICA=10.357, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, FM_DDDD_TIMES_2=1.999, FS_REPLICA=0.994, FS_REPLICAWATCH=10.357, GB_ROLEX=5, HELO_DYNAMIC_IPADDR2=4.395, HELO_EQ_DSL=1.129, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_SPEC_REPLICA_OBFU=1.812, SARE_SPEC_ROLEX=1.666, SARE_SPEC_ROLEX_HIQLT=1.666, SARE_SPEC_ROLEX_NOV5A=1.062, SARE_SPEC_ROLEX_NOV5F=0.666, SARE_SPEC_ROLEX_REP=1.666, TVD_RCVD_IP=1.931, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, 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 oQ0rbhoWwlgs; Mon, 14 Jul 2008 19:44:52 -0700 (PDT) Received: from 190-95-86-124.bk21-dsl.surnet.cl (190-95-86-124.bk21-dsl.surnet.cl [190.95.86.124]) by core3.amsl.com (Postfix) with SMTP id 7110128C152; Mon, 14 Jul 2008 19:44:37 -0700 (PDT) X-Originating-IP: 121.208.20.156 by smtp.190.95.86.124; Mon, 14 Jul 2008 22:45:11 -0500 Message-ID: <llhtrhDGDXDmip6@ietf.org> From: "Parker Dyer" <mip6@ietf.org> Reply-To: "Parker Dyer" <mip6@ietf.org> To: mip6@ietf.org Subject: Qualitative Breitling watches at Prestige Replicas Date: Mon, 14 Jul 2008 22:45:11 -0500 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit Have you always wanted a Rolex, but don't want to pay high prices for a brand name watch? Then you need to visit Prestige Replicas, a website dedicated exclusively to high quality replicas, with the most extensive inventory on the web and a proven track record of satisfied customers. http://www.wellsoe.com/ Prestige Replicas offers hundreds of Rolex replica watches starting just above $100, and during this spring season, their already low prices have been slashed by 15 percent if you buy two or more watches! No matter which model Rolex you choose, their 15% discount applies to them all! But don't let this limited time offer go by... spring is ending and it's time to impress your friends with a realistic, high quality Rolex replica watch, that will look and perform just like the real deal! http://www.wellsoe.com/ From mpls-bounces@ietf.org Wed Jul 16 05:10:31 2008 Return-Path: <mpls-bounces@ietf.org> X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55E773A69A9; Wed, 16 Jul 2008 05:10:31 -0700 (PDT) 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 84B9D3A69A9 for <mpls@core3.amsl.com>; Wed, 16 Jul 2008 05:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ao2JxNj0hL9x for <mpls@core3.amsl.com>; Wed, 16 Jul 2008 05:10:28 -0700 (PDT) Received: from av6-1-sn3.vrr.skanova.net (av6-1-sn3.vrr.skanova.net [81.228.9.179]) by core3.amsl.com (Postfix) with ESMTP id B49FB3A6982 for <mpls@ietf.org>; Wed, 16 Jul 2008 05:10:28 -0700 (PDT) Received: by av6-1-sn3.vrr.skanova.net (Postfix, from userid 502) id C494C37F6D; Wed, 16 Jul 2008 14:10:56 +0200 (CEST) Received: from smtp3-1-sn3.vrr.skanova.net (smtp3-1-sn3.vrr.skanova.net [81.228.9.101]) by av6-1-sn3.vrr.skanova.net (Postfix) with ESMTP id ADFD537E6C; Wed, 16 Jul 2008 14:10:56 +0200 (CEST) Received: from [127.0.0.1] (h133n2fls33o883.telia.com [217.208.62.133]) by smtp3-1-sn3.vrr.skanova.net (Postfix) with ESMTP id 4546537E42; Wed, 16 Jul 2008 14:10:56 +0200 (CEST) Message-ID: <487DE54A.70408@pi.nu> Date: Wed, 16 Jul 2008 14:10:50 +0200 From: Loa Andersson <loa@pi.nu> User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Adrian Farrel <adrian@olddog.co.uk>, mpls@ietf.org References: <487DBFFC.3060607@pi.nu> <006001c8e72e$020987b0$0200a8c0@your029b8cecfe> In-Reply-To: <006001c8e72e$020987b0$0200a8c0@your029b8cecfe> Subject: Re: [mpls] MPLS agenda X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <https://www.ietf.org/mailman/private/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org All, sent me this question - and it would seem that he is right. I did the same for self at the beginning of the MPLS-TP agenda: 3. MPLS-TP document processing (0 min) Loa What is intended here is that we got one time slot but with two items that I want minutes capture separately and with a hook to hang the slides. Meaning is that Zafar and I managed the timing ourselves :) Sorry if I caused confusion. /Loa Adrian Farrel wrote: > Hi Loa, > >> 12. Signaling RSVP-TE P2MP LSPs in an Inter-domain Environment (0 min) >> <draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-00.txt >> Zafar > > Isn't "0 min" a bit harsh? > > A > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.nu _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From lottoff2@gmail.com Thu Jul 17 06:16:52 2008 Return-Path: <lottoff2@gmail.com> X-Original-To: ietfarch-mpls-archive@core3.amsl.com Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9728028B56A for <ietfarch-mpls-archive@core3.amsl.com>; Thu, 17 Jul 2008 06:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.576 X-Spam-Level: ** X-Spam-Status: No, score=2.576 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HTML_MESSAGE=0.001, SARE_SUB_WINNING_NOT=0.683, SUBJ_ALL_CAPS=2.077] 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 XVujBGLrEs4q for <ietfarch-mpls-archive@core3.amsl.com>; Thu, 17 Jul 2008 06:16:51 -0700 (PDT) Received: from hu-out-0506.google.com (hu-out-0506.google.com [72.14.214.230]) by core3.amsl.com (Postfix) with ESMTP id DDACF3A6924 for <mpls-archive@lists.ietf.org>; Thu, 17 Jul 2008 06:16:50 -0700 (PDT) Received: by hu-out-0506.google.com with SMTP id 34so3608878hui.6 for <mpls-archive@lists.ietf.org>; Thu, 17 Jul 2008 06:17:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:subject :mime-version:content-type; bh=zuwd7zWGR8CBB+ofm+1XqBjy7rvv2Brw0ytX4uyIp50=; b=oycSJ/E9GRPphfifYgsSqvRGWV9O8f3hPjsD1xyBdKCt7G5qHvtfR8hxGyR8YCcdkP X1xLUZVUXxViiCQ6huk9XXEotHF+MF+8IGzoLF1n6xDgLWNNSQVorRqdj/v2KaiqMVFN KCzRjDyAw5fOr2apu4sFZ29cdu+u0aTwT6kPs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:subject:mime-version:content-type; b=YGH683zloj5Xsn30vUWo/wn5t3KAHw/8CPuJf+vnjjl37zoU6lK2q2/vQJWUCPe+/g ITVnqNtf/YoP083a+j3i9ZNH2ZP7npoB4GjDV9DZPKM21Hi+mwUV6vHg+PI5/tew74DY Kjr/M3RdDKB3tSf4gCOi5l6DoLzOLJlTiLUCs= Received: by 10.210.16.17 with SMTP id 17mr1120532ebp.127.1216300611116; Thu, 17 Jul 2008 06:16:51 -0700 (PDT) Received: by 10.210.77.12 with HTTP; Thu, 17 Jul 2008 06:16:50 -0700 (PDT) Message-ID: <aabfd4d70807170616g6807249ejf2b88ef87e7cb9b7@mail.gmail.com> Date: Thu, 17 Jul 2008 15:16:50 +0200 From: "ilo bf" <lottoff2@gmail.com> Subject: CHECK YOUR ATTACHMENT TO VIEW YOUR WINNING NOTIFICATION MESSAGE MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_25532_28131194.1216300611113" To: undisclosed-recipients:; ------=_Part_25532_28131194.1216300611113 Content-Type: multipart/alternative; boundary="----=_Part_25533_10301538.1216300611113" ------=_Part_25533_10301538.1216300611113 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline CHECK YOUR ATTACHMENT TO VIEW YOUR WINNING NOTIFICATION MESSAGE ------=_Part_25533_10301538.1216300611113 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline CHECK YOUR ATTACHMENT TO VIEW YOUR  WINNING NOTIFICATION MESSAGE ------=_Part_25533_10301538.1216300611113-- ------=_Part_25532_28131194.1216300611113 Content-Type: application/msword; name="RESULT OF THE INTERNATIONAL POOLS LOTTERY.doc" Content-Transfer-Encoding: base64 X-Attachment-Id: f_firdy5ty Content-Disposition: attachment; filename="RESULT OF THE INTERNATIONAL POOLS LOTTERY.doc" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAMgAAAAAAAAAA EAAANAAAAAEAAAD+////AAAAADEAAAD///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAcWAJBAAA8BK/AAAAAAAAEAAAAAAABgAAXyAAAA4AYmpianFQcVAAAAAAAAAAAAAAAAAAAAAA AAAMBBYALiIAABM6AQATOgEARwsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAKQAAAAAAKgDAAAAAAAAqAMAAKgD AAAAAAAAqAMAAAAAAACoAwAAAAAAAKgDAAAAAAAAqAMAABQAAAAAAAAAAAAAALwDAAAAAAAABBMA AAAAAAAEEwAAAAAAAAQTAAAAAAAABBMAABQAAAAYEwAAHAAAALwDAAAAAAAAhhgAALYAAABAEwAA AAAAAEATAAAAAAAAQBMAAAAAAABAEwAAAAAAAEATAAAAAAAAQBMAAAAAAABAEwAAAAAAAEATAAAA AAAA4RcAAAIAAADjFwAAAAAAAOMXAAAAAAAA4xcAAAAAAADjFwAAAAAAAOMXAAAAAAAA4xcAACQA AAA8GQAAaAIAAKQbAACUAAAABxgAADkAAAAAAAAAAAAAAAAAAAAAAAAAqAMAAAAAAAAtFAAAAAAA AAAAAAAAAAAAAAAAAAAAAABAEwAAAAAAAEATAAAAAAAALRQAAAAAAAAtFAAAAAAAAAcYAAAAAAAA AAAAAAAAAACoAwAAAAAAAKgDAAAAAAAAQBMAAAAAAAAAAAAAAAAAAEATAAAAAAAAQBgAABYAAACj FwAAAAAAAKMXAAAAAAAAoxcAAAAAAAAtFAAAegIAAKgDAAAAAAAAQBMAAAAAAACoAwAAAAAAAEAT AAAAAAAA4RcAAAAAAAAAAAAAAAAAAKMXAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAALRQAAAAAAADhFwAAAAAAAAAAAAAAAAAAoxcAAAAAAAAAAAAA AAAAAKMXAAAAAAAAqAMAAAAAAACoAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoxcAAAAAAABAEwAAAAAAADQTAAAMAAAA4AnPkZTn yAEAAAAAAAAAAAQTAAAAAAAApxYAANwAAACjFwAAAAAAAAAAAAAAAAAA4RcAAAAAAABWGAAAMAAA AIYYAAAAAAAAoxcAAAAAAAA4HAAAAAAAAIMXAAAWAAAAOBwAAAAAAACjFwAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACj FwAAIgAAADgcAAAAAAAAAAAAAAAAAACoAwAAAAAAAMUXAAAcAAAAQBMAACIAAABiEwAAGAAAAKMX AAAAAAAAehMAABQAAACOEwAAnwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQBMA AAAAAABAEwAAAAAAAEATAAAAAAAABxgAAAAAAAAHGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAmRcAAAoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEATAAAA AAAAQBMAAAAAAABAEwAAAAAAAIYYAAAAAAAALRQAAAAAAAAtFAAAAAAAAC0UAAAAAAAALRQAAAAA AAAAAAAAAAAAALwDAAAAAAAAvAMAAAAAAAC8AwAApAcAAGALAACkBwAAvAMAAAAAAAC8AwAAAAAA ALwDAAAAAAAAYAsAAAAAAAC8AwAAAAAAALwDAAAAAAAAvAMAAAAAAACoAwAAAAAAAKgDAAAAAAAA qAMAAAAAAACoAwAAAAAAAKgDAAAAAAAAqAMAAAAAAAD/////AAAAAAIADAEAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFJFU1VM VCBPRiBUSEUgSU5URVJOQVRJT05BTCBQT09MUyBMT1RURVJZLg1GUk9NOklOVEVSTkFUSU9OQUwg TE9UVEVSWSBQUk9NT1RJT05TDUFWRU5VRSBOS1JVTUFIIEtXQU1FIFNFQ1RPUiwxNE9VQUdBIDAx IEJQLg1CVVJLSU5BIEZBU08uDaANoERlYXIgbHVja3kgd2lubmVyLA2gDVdlIGFyZSBwbGVhc2Vk IHRvIGluZm9ybSB5b3UgdGhhdCB5b3VyIGVtYWlsIGFkZHJlc3Mgd2FzIHNlbGVjdGVkIGluIG91 ciBFTUFJTCBSQUZGTEUgRFJBVy5BbiBJbnRlcm5hdGlvbmFsIHByb2dyYW0gaGVsZCBvbiB0aGUg MTJ0aCBvZiBKdW5lLDIwMDgsoCBZb3VyIGUtbWFpbCBhZGRyZXNzIHdhcyBhdHRhY2hlZCB0byA6 DaANVGlja2V0IG51bWJlciA6ODg1Njc5NTQ3VA1TZXJpYWwgbnVtYmVyOiA1OTYxMjM3ODk5DURy ZXcgbHVja3kgbnVtYmVyOjIyODk1Njc0NTMNoA13aGljaCBjb25zZXF1ZW50bHkgd29uIGluIHRo ZSAybmQgY2F0ZWdvcnkuDVlvdSBhcmUgdGhlcmVmb3JlIGJlZW4gYXBwcm92ZWQgb2YgYQAgAGwA dQBtAHAAIABzAHUAbQAgAHAAcgBpAHoAZQAgAG8AZgANAKwgIAA4ADUAMAAsADAAMAAwAC4AMAAw ACAAKABFAGkAZwBoAHQAIABIAHUAbgBkAHIAZQBkACAAYQBuAGQAIABmAGkAZgB0AHkAIABUAGgA bwB1AHMAYQBuAGQAIAAoAEUAdQByAG8AcwApAC4ADQBDAE8ATgBHAFIAQQBUAFUATABBAFQASQBP AE4ADQCgAA0ASQBNAFAATwBSAFQAQQBOAFQAIABOAE8AVABJAEYASQBDAEEAVABJAE8ATgA6AA0A oAANAEQAdQBlACAAdABvACAAbQBpAHgAIAB1AHAAIABvAGYAIABzAG8AbQBlACAAbgB1AG0AYgBl AHIAcwAgAGEAbgBkACAAbgBhAG0AZQBzACwAIAB3AGUAIABhAHMAawAgAHQAaABhAHQAIAB5AG8A dQAgAGsAZQBlAHAAIAB5AG8AdQByACAAdwBpAG4AbgBpAG4AZwAgAGkAbgBmAG8AcgBtAGEAdABp AG8AbgAgAGMAbwBuAGYAaQBkAGUAbgB0AGkAYQBsACAAdQBuAHQAaQBsAGwAIAB5AG8AdQByACAA YwBsAGEAaQBtACAAaABhAHMAIABiAGUAZQBuACAAcAByAG8AYwBlAHMAcwBlAGQAIABhbmQgeW91 ciBtb25leSBSZW1pdHRlZCB0byB5b3UuDaANVGhpcyBpcyBwYXJ0IG9mIG91ciBzZWN1cml0eSBw cm90b2NvbHMgdG8gYXZvaWQgZG91YmxlIGNsYWltaW5nIGFuZHVud2FycmFudGVkIGFidXNlIG9m IHRoaXMgcHJvZ3JhbSBieSBzb21lIHBhcnRpY2lwYW50cy4NoA1BbGwgcGFydGljaXBhbnRzIHdl cmUgc2VsZWN0ZWQgdGhyb3VnaCBhIGNvbXB1dGVyIHJhZmZsZSBzeXN0ZW0NZHJhd24gZnJvbSBv dmVyIDIwLDAwMCBjb21wYW55IGFuZCAzMCwwMDAsMDAwIGluZGl2aWR1YWwncyBlbWFpbCBhZGRy ZXNzZXMgZnJvbSBhbGwgb3ZlciB0aGUgd29ybGQuDaANVGhpcyBwcm9tb3Rpb25hbCBwcm9ncmFt IHRha2VzIHBsYWNlIGV2ZXJ5IHllYXIuVGhpcyBsb3R0ZXJ5IHdhcyBwcm9tb3RlZCBhbmQgc3Bv bnNvcmVkIGJ5VGhlIEludGVybmF0aW9uYWwgU29mdHdhcmUgT3JnYW5pc2F0aW9uIENvbW1pdHRl LHdlIGhvcGUgYXMgYSBsdWNreSB3aW5uZXIseW91IHdpbGwgYmUgcGFydCBvZiBvdXIgbmV4dCB5 ZWFyICggMSBtaWxsaW9uIEV1cm8pIExvdHRlcnkgQm9uYW56YS4NoA1UbyBmaWxlIHlvdXIgY2xh aW0sIHBsZWFzZSBjb250YWN0IG91ciBjbGFpbSBhZ2VudCBuYW1lZDogT2ZmaWNlciBTQUxJRiBC RUtPIHRvIG9idGFpbiB5b3VyIHdpbm5pbmcgRm9ybSBhbmQgdGhloCBDb3VydKAgQ2xlYXJhbmNl IGZvciB5b3VyIHdvbiBwcml6ZSB0byBiZSByZWxlYXNlZCBhbmQgdHJhbnNmZXJlZCB0byB5b3Uu DaANRW1haWwgQWRkcmVzczoNU0FMSUYgQkVLTw1CdXJlYXVkZWNsYWltX2lsb0B5YWhvby5mcg1U RUxFUEhPTkU6ICgwMDIyNikgNzYgMjYgODQgMDUNoA1DT05HUkFUVUxBVElPTlMgISENoA1Db250 YWN0IHlvdXIgY2xhaW0gb2ZmaWNlciBmb3IgZHVlIHByb2Nlc3NpbmcgYW5kIHJlbWl0dGFuY2Ug b2YgeW91ciBwcml6ZSBtb25leSB0byBhIGRlc2lnbmF0ZWQgYWNjb3VudCBvZiB5b3VyIGNob2lj ZS4NoA0iUmVtZW1iZXIiIHRoYXQgeW91IG11c3QgY29udGFjdCB5b3VyIGNsYWltcyBvZmZpY2Vy IHRocm91Z2ggdGhlIGVtYWlsIGFkZHJlc3MgYXMgd3JpdHRlbiBhYm92ZSB0byBvYnRhaW4geW91 ciB3aW5uaW5nIGZvcm0gYW5kIENvdXJ0IGNsZWFyYW5jZS4NoA1Zb3VyIHdpbm5pbmcgY2VydGlm aWNhdGUgc2hhbGwgYmUgZ2l2ZW4gdG8geW91IGZvciB0aGUgZW5kb3JzZW1lbnQgb2YgeW91ciB3 aW5uaW5nIGNoZXF1ZSB3aGljaCBzaGFsbCBiZSBwYWlkIGJ5IG91ciBjb3JyZXNwb25kaW5nIGJh bmsgdG8geW91ciBkZXNpZ25hdGVkIGJhbmsgYWNjb3VudC4NoA1XZSBhc3N1cmUgb3VyIHdpbm5l cnMgdXRtb3N0IHNlY3VyaXR5IG9mIHRoZWlyIHByaXplcyB3aXRob3V0IG5vIGhpdGNoIGZvbGxv d2luZyBvdXIgUHJvdG9jb2wgdG8gcmVsZWFzZSB0aGUgcHJpemUgdG8gdGhlIGJvbmFmaWRlIHdp bm5lcnMuDaANV2lubmVyIGFyZSB0aGVyZWZvcmUgbm90aWZ5IHRoYXQgdGhlIEF3YXJkIEdpdmlu ZyBEYXkgaXMgb24gdGhlIDI2dGggb2YgSnVseSwyMDA4LCBXaW5uZXIncyBmaWxlIHNob3VsZCBi ZSBjb21wbGV0ZWQgYW5kIGZvcndhcmRlZCB0byB0aGUgcGF5bWVudCBkZXBhcnRtZW50IGJlZm9y ZSB0aGlzIGRhdGUuDaANSW4gb3JkZXIgdG8gYXZvaWQgdW5uZWNlc3NhcnkgZGVsYXkgYW5kIGNv bXBsaWNhdGlvbnMsIHBsZWFzZSByZW1lbWJlciB0byAiUVVPVEUiIHlvdXIgd2lubmluZyByZWZl cmVuY2VzIHRvIHlvdXIgY2xhaW0gYWdlbnQgb24gdGVsZXBob25lLHRoYXQgaXM6DaANU2VyaWFs IG51bWJlcg1EcmV3IEx1Y2t5IE51bWJlcg1UaWNrZXQgTnVtYmVyDaANU2hvdWxkIHRoZXJlIGJl IGFueSBjaGFuZ2Ugb2YgeW91ciBhZGRyZXNzLCBkbyBpbmZvcm0geW91ciBjbGFpbSBvZmZpY2Vy IGFzIHNvb24gYXMgcG9zc2libGUuDaANQ29uZ3JhdHVsYXRpb25zIG9uY2UgYWdhaW4gZnJvbSB0 aGUgc3RhZmYgb2YgdGhpcyBPcmdhbmlzYXRpb24sd2UgdGhhbmsgeW91IGZvciBiZWluZyBwYXJ0 IG9mIHRoaXMgeWVhciBwcm9tb3RpbwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAqCAAAKwgA AFAIAABRCAAAewgAAHwIAACJCAAAiggAAIsIAACMCAAAnwgAAKAIAAChCAAAoggAAFsJAABcCQAA XQkAAF4JAAB3CQAAeAkAAJEJAACSCQAArgkAAK8JAACwCQAAsQkAANwJAADdCQAAJgoAACgKAACW CgAAmAoAALQKAAC2CgAAuAoAALoKAADoCgAA6goAAOwKAADuCgAAHwwAACAMAAAhDAAAIgwAAJwM AACdDAAAngwAAJ8MAADeDAAA3wwAAEINAABDDQAARA0AAEUNAAAuDgAALw4AADAOAAAxDgAA7A4A AO0OAADuDgAA7w4AAP0OAAD+DgAACA8AAAkPAAAjDwAAJA8AAEIPAABDDwAARA8AAEUPAABXDwAA WA8AAFkPAABaDwAA0g8AANMPAADUDwAA1Q8AAGUQAABmEAAA8+Tz5PPk8+Tz5PPk8+Tz5PPk2OTY 5Njk8+Tz5PPk8+Tz5PPk8+Tz5PPk8+Tz5PPk8+Tz5PPk8+Tz5PPk8+Tz5PPk8+Tz0PPQ89Dz0PPk 8+Tz5AAADxZoxlLBAEIqAXBoAAAAABcWaMZSwQBCKgFtSAkEcGgzMzMAc0gJBB0VaMZSwQAWaMZS wQBCKgFtSAkIcGgAAAAAc0gJCBcWaMZSwQBCKgFtSAkIcGgzMzMAc0gJCABSAAYAACsIAABRCAAA fAgAAIoIAACMCAAAoAgAAKIIAABcCQAAXgkAAHgJAACSCQAArwkAALEJAADdCQAAKAoAAJgKAAC2 CgAAugoAAOoKAADuCgAAIAwAACIMAACdDAAAnwwAAN8MAABDDQAARQ0AAO8AAAAAAAAAAAAAAADv AAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAA AAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAA AADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAA AAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAA AAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA 7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAABAAABJkIAEAAC1EAAFNxgoAAAD/////AAAAZ2TGUsEAABsABgAAXyAAAP4AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgEBAUUNAAAvDgAAMQ4AAO0O AADvDgAA/g4AAAkPAAAkDwAAQw8AAEUPAABYDwAAWg8AANMPAADVDwAAZhAAAGgQAAAREQAAExEA AJ8RAAChEQAAUBIAAFISAADmEgAA6BIAAPYSAAAIEwAAFhMAABgTAADvAAAAAAAAAAAAAAAA7wAA AAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAA AAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA 7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAA AAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAA AAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8A AAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAQAAASZCABAAAtRAABTcYKAAAA/////wAAAGdkxlLBAAAbZhAAAGcQAABoEAAAEBEA ABERAAASEQAAExEAAJ4RAACfEQAAoBEAAKERAABPEgAAUBIAAFESAABSEgAA5RIAAOYSAADnEgAA 6BIAAPUSAAD2EgAABxMAAAgTAAAVEwAAFhMAABcTAAAYEwAAdRMAAHYTAAB3EwAAeBMAAOgTAAAA IAAAMiAAADMgAAA0IAAANSAAAEMgAABEIAAAXSAAAF4gAABfIAAA8+Tz5PPk8+Tz5PPk8+Tz5PPk 8+Tz5PPk8+Tz5PPk8+Lz5PPk8+Tz5NcAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABQVaMZSwQAWaMZSwQBtSAkIc0gJCAADVQgBHRVoxlLBABZoxlLBAEIq AW1ICQhwaAAAAABzSAkIFxZoxlLBAEIqAW1ICQhwaDMzMwBzSAkIACkYEwAAdhMAAHgTAAAzIAAA NSAAAEQgAABeIAAAXyAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8A AAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO0AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAQAAEAAAEmQgAQAALUQAAU3GCgAAAP////8AAABnZMZSwQAAB24gcHJvZ3JhbSBhbmQgd2lz aCB5b3UgYSBjb250aW51aW5nIGdvb2QgZm9ydHVuZXMuDaANTVIgQklMTCBMTE9ZRUQNMjAwOCBS QUZGTEUgQ08tT1JESU5BVE9SLg0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALAAxkGgBH7CCLiCwxkEhsIkF IrCJBSOQiQUkkIkFJbAAABewxAIYsMQCDJDEAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACGAg8AEgABAJwADwAEAAAAAAAA AAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AABAAABA8f8CAEAADAQAAAAAAAAAAAYATgBvAHIAbQBhAGwAAAACAAAAGABDShgAX0gBBGFKGABt SAwEc0gMBHRIDAQAAAAAAAAAAAAAAAAAAAAAAAA6AEFA8v+hADoADAUAAAAAAAAAABEAUABvAGwA aQBjAGUAIABwAGEAcgAgAGQA6QBmAGEAdQB0AAAAAABWAGlA8/+zAFYADAUAAAAAAAAAAA4AVABh AGIAbABlAGEAdQAgAE4AbwByAG0AYQBsAAAAHAAX9gMAADTWBgABCgNsADTWBgABBQMAAGH2AwAA AgALAAAAMgBrQPT/wQAyAAAFAAAAAAAAAAAMAEEAdQBjAHUAbgBlACAAbABpAHMAdABlAAAAAgAA AAAAAAAAAAAARwsAAAQAACIAAAAA/////wAAAAArAAAAUQAAAHwAAACKAAAAjAAAAKAAAACiAAAA XAEAAF4BAAB4AQAAkgEAAK8BAACxAQAA3QEAABQCAABMAgAAWwIAAF0CAAB1AgAAdwIAACADAAAi AwAAnQMAAJ8DAADfAwAAQwQAAEUEAAAvBQAAMQUAAO0FAADvBQAA/gUAAAkGAAAkBgAAQwYAAEUG AABYBgAAWgYAANMGAADVBgAAZgcAAGgHAAARCAAAEwgAAJ8IAAChCAAAUAkAAFIJAADmCQAA6AkA APYJAAAICgAAFgoAABgKAAB2CgAAeAoAABsLAAAdCwAALAsAAEYLAABJCwAAScgAMAAAAAAAAAAA AQAAAAAAAAAAAAAAAACAAUnIADABAAAAAAAAAAEAAAADAAAAAAAAAAAAgAFJyAAwAQAAAAAAAAAB AAAAAwAAAAAAAAAAAIABScgAMAEAAAAAAAAAAQAAAAMAAAAAAAAAAACAAUnIADABAAAAAAAAAAEA AAADAAAAAAAAAAAAgAFJyAAwAQAAAAAAAAABAAAAAwAAAAAAAAAAAIABScgAMAEAAAAAAAAAAQAA AAMAAAAAAAAAAACAAUnIADABAAAAAAAAAAEAAAADAAAAAAAAAAAAgAFJyAAwAQAAAAAAAAABAAAA AwAAAAAAAAAAAIABScgAMAEAAAAAAAAAAQAAAAMAAAAAAAAAAACAAUnIADABAAAAAAAAAAEAAAAD AAAAAAAAAAAAgAFJyAAwAQAAAAAAAAABAAAAAwAAAAAAAAAAAIABScgAMAEAAAAAAAAAAQAAAAMA AAAAAAAAAACAAUnIADABAAAAAAAAAAEAAAADAAAAAAAAAAAAgAFJyAAwAQAAAAAAAAABAAAAAwAA AAAAAAAAAIABScgAMAEAAAAAAAAAAQAAAAMAAAAAAAAAAACAAUnIADABAAAAAAAAAAEAAAADAAAA AAAAAAAAgAFJyAAwAQAAAAAAAAABAAAAAwAAAAAAAAAAAIABScgAMAEAAAAAAAAAAQAAAAMAAAAA AAAAAACAAUnIADABAAAAAAAAAAEAAAADAAAAAAAAAAAAgAFJyAAwAQAAAAAAAAABAAAAAwAAAAAA AAAAAIABScgAMAEAAAAAAAAAAQAAAAMAAAAAAAAAAACAAUnIADABAAAAAAAAAAEAAAADAAAAAAAA AAAAgAFJyAAwAQAAAAAAAAABAAAAAwAAAAAAAAAAAIABScgAMAEAAAAAAAAAAQAAAAMAAAAAAAAA AACAAUnIADABAAAAAAAAAAEAAAADAAAAAAAAAAAAgAFJyAAwAQAAAAAAAAABAAAAAwAAAAAAAAAA AIABScgAMAEAAAAAAAAAAQAAAAMAAAAAAAAAAACAAUnIADABAAAAAAAAAAEAAAADAAAAAAAAAAAA gAFJyAAwAQAAAAAAAAABAAAAAwAAAAAAAAAAAIABScgAMAEAAAAAAAAAAQAAAAMAAAAAAAAAAACA AUnIADABAAAAAAAAAAEAAAADAAAAAAAAAAAAgAFJyAAwAQAAAAAAAAABAAAAAwAAAAAAAAAAAIAB ScgAMAEAAAAAAAAAAQAAAAMAAAAAAAAAAACAAUnIADABAAAAAAAAAAEAAAADAAAAAAAAAAAAgAFJ yAAwAQAAAAAAAAABAAAAAwAAAAAAAAAAAIABScgAMAEAAAAAAAAAAQAAAAMAAAAAAAAAAACAAUnI ADABAAAAAAAAAAEAAAADAAAAAAAAAAAAgAFJyAAwAQAAAAAAAAABAAAAAwAAAAAAAAAAAIABScgA MAEAAAAAAAAAAQAAAAMAAAAAAAAAAACAAUnIADABAAAAAAAAAAEAAAADAAAAAAAAAAAAgAFJyAAw AQAAAAAAAAABAAAAAwAAAAAAAAAAAIABScgAMAEAAAAAAAAAAQAAAAMAAAAAAAAAAACAAUnIADAB AAAAAAAAAAEAAAADAAAAAAAAAAAAgAFJyAAwAQAAAAAAAAABAAAAAwAAAAAAAAAAAIABScgAMAEA AAAAAAAAAQAAAAMAAAAAAAAAAACAAUnIADABAAAAAAAAAAEAAAADAAAAAAAAAAAAgAFJyAAwAQAA AAAAAAABAAAAAwAAAAAAAAAAAIABScgAMAEAAAAAAAAAAQAAAAMAAAAAAAAAAACAAUnIADABAAAA AAAAAAEAAAADAAAAAAAAAAAAgAFJyAAwAQAAAAAAAAABAAAAAwAAAAAAAAAAAIABScgAMAEAAAAA AAAAAQAAAAMAAAAAAAAAAACAAUnIADABAAAAAAAAAAEAAAADAAAAAAAAAAAAgAFJyAAwAQAAAAAA AAABAAAAAwAAAAAAAAAAAIABScgAMAEAAAAAAAAAAQAAAAMAAAAAAAAAAACAAUnIADABAAAAAAAA AAEAAAADAAAAAAAAAAAAgAFJyAAwAQAAAAAAAAABAAAAAwAAAAAAAAAAAIABScgAMAEAAAAAAAAA AQAAAAMAAAAAAAAAAACAAUnIADABAAAAAAAAAAEAAAADAAAAAAAAAAAAgAFJyAAwAQAAAAAAAAAC AAAAAQAAAAAAAAAAAIABScgAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAACAAQAAAAArAAAAUQAAAHwA AACKAAAAjAAAAKAAAACiAAAAXAEAAF4BAAB4AQAAkgEAAK8BAACxAQAA3QEAABQCAABMAgAAWwIA AF0CAAB1AgAAdwIAACADAAAiAwAAnQMAAJ8DAADfAwAAQwQAAEUEAAAvBQAAMQUAAO0FAADvBQAA /gUAAAkGAAAkBgAAQwYAAEUGAABYBgAAWgYAANMGAADVBgAAZgcAAGgHAAARCAAAEwgAAJ8IAACh CAAAUAkAAFIJAADmCQAA6AkAAPYJAAAICgAAFgoAABgKAAB2CgAAeAoAABsLAAAdCwAALAsAAEYL AABJCwAAS8gAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAAC2A0nIADAAAAAAAAAAAAEAAAAAAAAAAAAA AAAAtgNJyAAwAAAAAAAAAAABAAAAAAAAAAAAAAAAALYDScgAMAAAAAAAAAAAAQAAAAAAAAAAAAAA AAC2A0nIADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAtgNJyAAwAAAAAAAAAAABAAAAAAAAAAAAAAAA ALYDScgAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAAC2A0nIADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAA tgNJyAAwAAAAAAAAAAABAAAAAAAAAAAAAAAAALYDScgAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAAC2 A0nIADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAtgNJyAAwAAAAAAAAAAABAAAAAAAAAAAAAAAAALYD ScgAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAAC2A0nIADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAtgNJ yAAwAAAAAAAAAAABAAAAAAAAAAAAAAAAALYDScgAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAAC2A0nI ADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAtgNJyAAwAAAAAAAAAAABAAAAAAAAAAAAAAAAALYDScgA MAAAAAAAAAAAAQAAAAAAAAAAAAAAAAC2A0nIADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAtgNJyAAw AAAAAAAAAAABAAAAAAAAAAAAAAAAALYDScgAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAAC2A0nIADAA AAAAAAAAAAEAAAAAAAAAAAAAAAAAtgNJyAAwAAAAAAAAAAABAAAAAAAAAAAAAAAAALYDScgAMAAA AAAAAAAAAQAAAAAAAAAAAAAAAAC2A0nIADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAtgNJyAAwAAAA AAAAAAABAAAAAAAAAAAAAAAAALYDScgAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAAC2A0nIADAAAAAA AAAAAAEAAAAAAAAAAAAAAAAAtgNJyAAwAAAAAAAAAAABAAAAAAAAAAAAAAAAALYDScgAMAAAAAAA AAAAAQAAAAAAAAAAAAAAAAC2A0nIADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAtgNJyAAwAAAAAAAA AAABAAAAAAAAAAAAAAAAALYDScgAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAAC2A0nIADAAAAAAAAAA AAEAAAAAAAAAAAAAAAAAtgNJyAAwAAAAAAAAAAABAAAAAAAAAAAAAAAAALYDScgAMAAAAAAAAAAA AQAAAAAAAAAAAAAAAAC2A0nIADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAtgNJyAAwAAAAAAAAAAAB AAAAAAAAAAAAAAAAALYDScgAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAAC2A0nIADAAAAAAAAAAAAEA AAAAAAAAAAAAAAAAtgNJyAAwAAAAAAAAAAABAAAAAAAAAAAAAAAAALYDScgAMAAAAAAAAAAAAQAA AAAAAAAAAAAAAAC2A0nIADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAtgNJyAAwAAAAAAAAAAABAAAA AAAAAAAAAAAAALYDScgAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAAC2A0nIADAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAtgNJyAAwAAAAAAAAAAABAAAAAAAAAAAAAAAAALYDScgAMAAAAAAAAAAAAQAAAAAA AAAAAAAAAAC2A0nIADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAtgNJyAAwAAAAAAAAAAABAAAAAAAA AAAAAAAAALYDScgAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAAC2A0nIADAAAAAAAAAAAAEAAAAAAAAA AAAAAAAAtgNJyAAwAAAAAAAAAAABAAAAAAAAAAAAAAAAALYDScgAMAAAAAAAAAAAAQAAAAAAAAAA AAAAAAC2A0nIADAAAAAAAAAAAAEAAAAAAAAAAAAAAAAAtgNJyAAwAAAAAAAAAAABAAAAAAAAAAAA AAAAALYDScgAMAAAAAAAAAAAAQAAAAAAAAAAAAAAAACAAUnIADAAAAAAAAAAAAEAAAAAAAAAAAAA AAAAgAFJyAAwAAAAAAAAAAABAAAAAAAAAAAAAAAAAIABCAAAAAAAAAAAAAAAAAAAAAAAAAAACAAA AAAAAQAGAABmEAAAXyAAAAoAAAAOAAAAAAYAAEUNAAAYEwAAXyAAAAsAAAANAAAADwAAAAAGAABf IAAADAAAAP//AgAAAAYAMUVwAxAAAQBcxx0ABgAyRXADEQABAIyeWwV8AAAAfAAAAEkLAAAAAAAA AgABAAAAAgCIAAAAiAAAAEkLAAAAAAAAAQAAAAIAAABCAAAAAQAAACqAdXJuOnNjaGVtYXMtbWlj cm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzDoBjb3VudHJ5LXJlZ2lvbgCAOQAAAAIAAAAqgHVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncwWAcGxhY2UAgAwAAAGwV/sG AAAAAAIAAAAAAAEAAAAAAAAAAABQAAAAUQAAAHsAAAB8AAAAiQAAAIoAAACLAAAAjAAAAJ8AAACg AAAAoQAAAKIAAAD4AAAA/wAAAHcBAAB4AQAAkQEAAJIBAACuAQAArwEAANwBAADdAQAAEwIAABQC AABaAgAAWwIAAHQCAAB1AgAA2wIAAOECAAAfAwAAIAMAAGIDAABwAwAAnAMAAJ0DAADeAwAA3wMA AEIEAABDBAAAcAQAAHkEAACdBAAAogQAAMcEAADSBAAA4wQAAO0EAAAuBQAALwUAANoFAADkBQAA 7AUAAO0FAAD9BQAA/gUAAAgGAAAJBgAAIwYAACQGAADSBgAA0wYAABUHAABlBwAAZgcAAGcHAABo BwAADwgAABMIAAAVCAAAFggAAJ0IAAChCAAApwgAAKgIAABOCQAAUgkAAFQJAABVCQAA5AkAAOgJ AADuCQAA7wkAAPUJAAD2CQAA+gkAAPsJAAAACgAAAQoAAAcKAAAICgAADgoAAA8KAAAVCgAAGAoA AHQKAAB4CgAAhwoAAIgKAAAZCwAAHQsAAB8LAAAgCwAAJQsAAEkLAAAHAAQABwAEAAcABAAHAAQA BwAEAAcABAAHABwABwAEAAcABAAHAAQABwAEAAcABAAHAAQABwAEAAcAHAAHAAQABwAcAAcABAAH AAQABwAEAAcAHAAHABwABwAcAAcAHAAHAAQABwAcAAcABAAHAAQABwAEAAcABAAHAAQABwADAAQA AwAEAAMABwADAAcAAwAHAAMABwADAAcAAwAHAAMABwADAAcAAwAHAAMABwADAAcAAwAHAAMABwAD AAcAAwAHAAMABwADAAcAAwAHAAMABwAAAAAAKgAAAC8AAAA9AAAAbAAAAHQAAAAuAQAAMwEAAGUB AAB3AQAAowEAAK4BAACxAQAAtgEAABQCAABLAgAA3wMAAOQDAAChBQAAqAUAAEUGAABXBgAAUQgA AFMIAADtCAAA8ggAANwJAADhCQAAeAoAABoLAAAbCwAAHAsAAB0LAAArCwAALAsAAEULAABJCwAA MwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAzAAcAMwAHADMABwAD AAQAAwAEAAMABAADAAQAAAAAACQGAABaBgAASQsAAAcABQAHAAAAAABJCwAABwACAFxOkSYjK7E0 AAAAAAAAIyuxNAAAAAAAAAAAAAECAAIAAQAAAAQAAAAIAAAA5QAAAAAAAAAAAAAAxlLBAP9AA4AB AEYLAABGCwAA9B9AAQEAAQBGCwAAAAAAAEYLAAAAAAAAAjQAAAAAAAAAAAIAAAADAADoCgAARwsA AEAAABAAQAAAQAAACgAAAABAAAAYAEAAAEAAAEAAQAAA//8BAAAABwBVAG4AawBuAG8AdwBuAP// AQAIAAAAAAAAAAAAAAD//wEAAAAAAP//AAACAP//AAAAAP//AAACAP//AAAAAAMAAABHFpABAAAC AgYDBQQFAgMEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8A bQBhAG4AAAA1FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBv AGwAAAAzJpABAAACCwYEAgICAgIEh3oAIAAAAIAIAAAAAAAAAP8BAAAAAAAAQQByAGkAYQBsAAAA IgAEADEIiBgA8MQCAACpAQAAAAAjiMeGJYjHhgAAAAABAAIAAAC8AQAAiwkAAAEABQAAAAQAAxAU AAAAvAEAAIsJAAABAAUAAAAUAAAAAAAAAFkCAPAQAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AIkFiQW0ALQAgYESNAAAAAAAAAAAAAAAAAAAQgsAAEILAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAATKDEQDwEAAI AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIWAAAAAAp8P8PAQABPwAA5AQAAP///3////9/ ////f////3////9/////f////3/GUsEAAAAAADIAAAAAAAAAAAAAAAAAAAAAAP//EgAAAAAAAAAp AFIARQBTAFUATABUACAATwBGACAAVABIAEUAIABJAE4AVABFAFIATgBBAFQASQBPAE4AQQBMACAA UABPAE8ATABTACAATABPAFQAVABFAFIAWQAAAAAAAAAGAFAATwBTAFQARQAzAAYAUABPAFMAVABF ADMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABQECAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlP aBCrkQgAKyez2TAAAACQAQAAEQAAAAEAAACQAAAAAgAAAJgAAAADAAAAzAAAAAQAAADYAAAABQAA AOgAAAAGAAAA9AAAAAcAAAAAAQAACAAAABABAAAJAAAAIAEAABIAAAAsAQAACgAAAEwBAAAMAAAA WAEAAA0AAABkAQAADgAAAHABAAAPAAAAeAEAABAAAACAAQAAEwAAAIgBAAACAAAA5AQAAB4AAAAs AAAAUkVTVUxUIE9GIFRIRSBJTlRFUk5BVElPTkFMIFBPT0xTIExPVFRFUlkAAAAeAAAABAAAAAAA AAAeAAAACAAAAFBPU1RFMwAAHgAAAAQAAAAAAAAAHgAAAAQAAAAAAAAAHgAAAAgAAABOb3JtYWwA AB4AAAAIAAAAUE9TVEUzAAAeAAAABAAAADEAAAAeAAAAGAAAAE1pY3Jvc29mdCBPZmZpY2UgV29y ZAAAAEAAAAAAjIZHAAAAAEAAAAAAAmsulOfIAUAAAAAAjvF1lOfIAQMAAAABAAAAAwAAALwBAAAD AAAAiwkAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA/v8AAAUBAgAAAAAAAAAAAAAAAAAAAAAAAQAAAALVzdWcLhsQk5cIACss +a4wAAAAEAEAAAwAAAABAAAAaAAAAA8AAABwAAAABQAAAHwAAAAGAAAAhAAAABEAAACMAAAAFwAA AJQAAAALAAAAnAAAABAAAACkAAAAEwAAAKwAAAAWAAAAtAAAAA0AAAC8AAAADAAAAPIAAAACAAAA 5AQAAB4AAAAEAAAAAAAAAAMAAAAUAAAAAwAAAAUAAAADAAAAQgsAAAMAAADmFQsACwAAAAAAAAAL AAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAACoAAABSRVNVTFQgT0YgVEhFIElOVEVSTkFU SU9OQUwgUE9PTFMgTE9UVEVSWQAMEAAAAgAAAB4AAAAGAAAAVGl0cmUAAwAAAAEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0A AAAOAAAADwAAABAAAAARAAAA/v///xMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAA ABwAAAAdAAAAHgAAAB8AAAAgAAAA/v///yIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgAAAD+//// KgAAACsAAAAsAAAALQAAAC4AAAAvAAAAMAAAAP7////9////MwAAAP7////+/////v////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAAAAAAAAAAAA kCHpkZTnyAE1AAAAgAAAAAAAAAAxAFQAYQBiAGwAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgACAf////8FAAAA/////wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAAA4HAAAAAAAAFcAbwByAGQARABvAGMAdQBtAGUAbgB0 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIBAQAAAP////////// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC4iAAAAAAAABQBTAHUAbQBt AGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgA AgECAAAABAAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhAAAAABAA AAAAAAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8A bgAAAAAAAAAAAAAAOAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAACkAAAAAEAAAAAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIA////////////////AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAEAAAD+//////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////AQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAARh8AAABEb2N1bWVudCBNaWNyb3NvZnQgT2Zm aWNlIFdvcmQACgAAAE1TV29yZERvYwAQAAAAV29yZC5Eb2N1bWVudC44APQ5snEAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAA= ------=_Part_25532_28131194.1216300611113-- From mpls-bounces@ietf.org Fri Jul 18 03:42:34 2008 Return-Path: <mpls-bounces@ietf.org> X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE3853A68DC; Fri, 18 Jul 2008 03:42:33 -0700 (PDT) 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 E5E473A6869 for <mpls@core3.amsl.com>; Fri, 18 Jul 2008 03:42:31 -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 IPh-SM5CTk4b for <mpls@core3.amsl.com>; Fri, 18 Jul 2008 03:42:30 -0700 (PDT) Received: from smtp.dataconnection.com (smtp.dataconnection.com [192.91.191.4]) by core3.amsl.com (Postfix) with ESMTP id 5F1093A67A5 for <mpls@ietf.org>; Fri, 18 Jul 2008 03:42:30 -0700 (PDT) Received: from enfimail2.datcon.co.uk ([172.18.10.19]) by smtp.dataconnection.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Jul 2008 11:43:02 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 18 Jul 2008 11:43:01 +0100 Message-ID: <8AC1AD08D396174DBC4E6D44EFACCFB105EE2FA7@enfimail2.datcon.co.uk> In-Reply-To: <00d801c8e5bb$d03294c0$0200a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] RFC 4875 re-merge procedures (section 18) thread-index: Acjlwfk9J/wnWqAbTxalODPUUOuB0QBaWVlg References: <8AC1AD08D396174DBC4E6D44EFACCFB105D6C6BB@enfimail2.datcon.co.uk> <00d801c8e5bb$d03294c0$0200a8c0@your029b8cecfe> From: "Nic Neate" <Nic.Neate@dataconnection.com> To: "Aria - Adrian Farrel Personal" <adrian@olddog.co.uk>, <mpls@ietf.org> X-OriginalArrivalTime: 18 Jul 2008 10:43:02.0816 (UTC) FILETIME=[0DD18200:01C8E8C3] Subject: Re: [mpls] RFC 4875 re-merge procedures (section 18) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <https://www.ietf.org/mailman/private/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Hi Adrian, Thanks for your emails. I agree that data loss can be prevented by a thinking re-merge node. However, the re-merge node is still sabotaging an upstream LSR's re-optimization attempt by removing path state. So there is a protocol bug here: - An upstream LSR on the P2MP LSP wants to re-optimize the path of a sub-tree passing through it. It does this using sub-group based re-optimization (RFC section 14.2) and sends a new Path message for the S2L sub-LSPs it is re-optimizing in a new sub-group with a new ERO. - At some point downstream, an LSR that is already on the P2MP LSP receives a new Path message for the re-optimized route. It arrives on a new incoming interface and describes S2L sub-LSPs that it does not have any existing state for. Following the rules in section 18 of the RFC, the LSR mistakes this for a re-merge. Wishing to correct the re-merge, it responds to the Path with a PathErr. - The re-optimization attempt has now failed. The upstream LSR will receive the re-merge PathErr message. You suggest that this could be fixed by "a little thought by the node performing the re-optimization". That may not be possible if the ERO contains loose hops, and could prevent re-optimization in some topologies. My preference would be for LSRs to be forbidden from sending re-merge PathErr messages at all. That would fix this flaw in the re-optimization mechanism. Upstream LSRs could still detect and correct re-merge conditions by analyzing RROs and rerouting. Given that the RFC already mandates that LSRs have a configuration option to disable the re-merge PathErr processing, I don't think this would be a major protocol change. Nic -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Aria - Adrian Farrel Personal Sent: 14 July 2008 15:08 To: Nic Neate; mpls@ietf.org Subject: Re: [mpls] RFC 4875 re-merge procedures (section 18) Nic, again. > Section 18 the RFC 4875 > (http://tools.ietf.org/html/rfc4875#section-18) > defines the procedures for an LSR that receives multiple Path messages > for the same P2MP LSP from different PHOPs. The intention is to > prevent data duplication in that scenario. > > I think the procedures in the RFC are insufficient for the following > reasons. The key point here is that an LSR following the procedures > defined in the RFC may cause data loss during sub-group re-optimization. > > - Section 18 discusses dynamic reroute and make-before-break but not > sub-group re-optimization. The latter (defined in section 14.2) is > another case where an LSR could receive multiple Path messages for the > same P2MP LSP from different PHOPs. > > - LSRs are told to differentiate re-merge and cross-over cases from > dynamic reroute by checking whether the sets of S2L sub-LSPs in the > upstream Path messages overlap. If they do not then it is > re-merge/cross-over (see section 18.1 paragraph 2). However, both > dynamic reroute and sub-group re-optimization could cause an LSR to > receive a new Path message containing a set of S2L sub-LSPs that does > not overlap with its existing path state. Consider the case where > re-optimization causes an LSR to become on the path for one S2L > sub-LSP and be removed from the path of another S2L sub-LSP. > > - Having falsely identified a sub-group re-optimization (or dynamic > reroute) as a re-merge, an LSR may (if so configured) send a PathErr > for its existing path state with the Path_State_Removed flag set > (section 18.1.1). That will cause data loss if the new, re-optimized > sub-tree has not yet been fully set up. No, I don't think that responding to a Path message with a PathErr will cause data loss as no Resv has yet flowed. Note that a little thought by the node performing the reoptimization makes sure that this situation does not arrise. > - Finally, as a separate point, it's worth noting that if the > downstream interfaces for two Path messages are the same, but the > downstream labels are not, then that is cross-over rather than > re-merge and needs to be handled as such. That case is omitted by the > RFC, which only discusses downstream interfaces (section 18.1 paragraph 3). > > I'd appreciate comments on whether this is indeed a problem that needs > solving. (If it is then I have some ideas on how that might be > achieved.) I don't believe there is a problem here. Adrian _______________________________________________ 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 mpls-bounces@ietf.org Fri Jul 18 03:44:45 2008 Return-Path: <mpls-bounces@ietf.org> X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99DA93A69C2; Fri, 18 Jul 2008 03:44:45 -0700 (PDT) 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 7810E3A69C7 for <mpls@core3.amsl.com>; Fri, 18 Jul 2008 03:44:43 -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 W6GlT3U+mB73 for <mpls@core3.amsl.com>; Fri, 18 Jul 2008 03:44:42 -0700 (PDT) Received: from smtp2.dataconnection.com (smtp2.dataconnection.com [192.91.191.8]) by core3.amsl.com (Postfix) with ESMTP id 2E7B13A6977 for <mpls@ietf.org>; Fri, 18 Jul 2008 03:44:42 -0700 (PDT) Received: from enfimail2.datcon.co.uk ([172.18.10.19]) by smtp2.dataconnection.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Jul 2008 11:45:14 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 18 Jul 2008 11:45:13 +0100 Message-ID: <8AC1AD08D396174DBC4E6D44EFACCFB105EE2FB2@enfimail2.datcon.co.uk> In-Reply-To: <00d901c8e5bb$d064a140$0200a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] RFC 4875 Notify forwarding by transit LSRs (section 8.1) thread-index: Acjlu+B4F5X06iayT2iXrGjKmgcTOQBbGrwQ References: <8AC1AD08D396174DBC4E6D44EFACCFB105D6C6C0@enfimail2.datcon.co.uk> <00d901c8e5bb$d064a140$0200a8c0@your029b8cecfe> From: "Nic Neate" <Nic.Neate@dataconnection.com> To: "Aria - Adrian Farrel Personal" <adrian@olddog.co.uk>, <mpls@ietf.org> X-OriginalArrivalTime: 18 Jul 2008 10:45:14.0916 (UTC) FILETIME=[5C8E5E40:01C8E8C3] Subject: Re: [mpls] RFC 4875 Notify forwarding by transit LSRs (section 8.1) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <https://www.ietf.org/mailman/private/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Hi Adrian, I agree that nested Notify Requesters are a good solution here, but that does require changes to RFC 4875 along the following lines. - When processing a NOTIFY_REQUEST object, transit and branch LSRs MUST NOT change the Notify node address. Further, branch LSRs MUST forward all NOTIFY_REQUEST objects received in Resvs from different downstream branches. - Notify messages for P2MP LSPs MUST be sent to the Notify node addresses from all NOTIFY_REQUEST objects received in Resvs, as they may be on different downstream branches. (This is different to the procedures for multiple Notify Requesters in RFC 4873, which specifies that a single Notify is sent to the address in the first NOTIFY_REQUEST object. Interactions with segment protection will need to be thought through.) - When processing a received Notify message, the sub-group identifiers in SENDER_TEMPLATE and FILTER_SPEC objects MUST be ignored, and MUST NOT be used in matching the Notify to local LSP state. Do you think a draft to formalize that would be appropriate? Nic -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Aria - Adrian Farrel Personal Sent: 14 July 2008 15:13 To: Nic Neate; mpls@ietf.org Subject: Re: [mpls] RFC 4875 Notify forwarding by transit LSRs (section 8.1) Nic, The problem you describe applies to many protection domain problems (such as segment protection). It is solved by the concept of "nested" Notify Requesters. See RFC4873. Adrian ----- Original Message ----- From: "Nic Neate" <Nic.Neate@dataconnection.com> To: <mpls@ietf.org> Sent: Monday, July 07, 2008 4:32 PM Subject: [mpls] RFC 4875 Notify forwarding by transit LSRs (section 8.1) Hi all, This is the second potential problem in RFC 4875 I'd like to raise. Please let me know if this is a concern for anyone, or if I've misunderstood something. Section 8.1 (http://tools.ietf.org/html/rfc4875#section-8.1) defines the rules for handling Notify messages for P2MP LSPs. They include the following. - All LSRs which change the sub-group originator ID in a Path message need to intercept both upstream and downstream Notifies so that they can re-write the sub-group identifiers in them then forward them on to the original Notify requestor. They achieve this by re-writing the Notify node address in the NOTIFY_REQUEST object. - All branch LSRs which receive muliple NOTIFY_REQUESTs in Resvs on different downstream branches need to intercept Notifies being sent downstream, duplicate them, and send a copy to all downstream Notify requestors. Again, they achieve this by re-writing the Notify node address. As a result, Notify messages for a P2MP LSP are likely to travel via a number of transit LSRs rather than being sent directly to the original Notify requestor. The purpose of the Notify message is to enable "expedited notification of failures and other events to nodes responsible for restoring failed LSPs" (RFC 3473 section 4). For example, the Notify message is used by GMPLS end-to-end protection (RFC 4872) for communicating LSP failures between ingress and egress LSRs and co-ordinating protection switching to a recovery LSP. The requirement to have Notify messages forwarded by transit LSRs for P2MP LSPs is going to make them much less useful. For example, if an LSR which has re-written the sub-group originator IDs fails, causing a data plane fault in the P2MP LSP, it will be impossible to use Notifies to quickly communicate that failure between source and leaf LSRs. I think this is a significant degradation to the usefulness of Notify messages that is worth addressing. Arguably this is a wider issue that also applies LSPs traversing NNIs between different domains, where the border routers also intercept Notifies. However, it may still be worth considering a solution to just the P2MP LSP problem for now, to facilitate the use of existing protection techniques for P2MP LSPs. Is anyone else interested in addressing this? Thanks, Nic Neate Data Connection Ltd. ------------------------------------------------------------------------ -------- > _______________________________________________ > 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 mpls-bounces@ietf.org Fri Jul 18 03:45:42 2008 Return-Path: <mpls-bounces@ietf.org> X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 035693A69E4; Fri, 18 Jul 2008 03:45:42 -0700 (PDT) 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 E90033A69BA for <mpls@core3.amsl.com>; Fri, 18 Jul 2008 03:45:24 -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 Lmk212BHSYu7 for <mpls@core3.amsl.com>; Fri, 18 Jul 2008 03:45:17 -0700 (PDT) Received: from smtp.dataconnection.com (smtp.dataconnection.com [192.91.191.4]) by core3.amsl.com (Postfix) with ESMTP id 2F1493A69D8 for <mpls@ietf.org>; Fri, 18 Jul 2008 03:45:08 -0700 (PDT) Received: from enfimail2.datcon.co.uk ([172.18.10.19]) by smtp.dataconnection.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Jul 2008 11:45:40 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 18 Jul 2008 11:45:39 +0100 Message-ID: <8AC1AD08D396174DBC4E6D44EFACCFB105EE2FB5@enfimail2.datcon.co.uk> In-Reply-To: <00c201c8e5ba$752fe510$0200a8c0@your029b8cecfe> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] RFC 4875 ERO processing details thread-index: AcjluzflthUkyCSyR+mVGXQFBoFvPgBbC3vg References: <8AC1AD08D396174DBC4E6D44EFACCFB105D6C6CC@enfimail2.datcon.co.uk> <00c201c8e5ba$752fe510$0200a8c0@your029b8cecfe> From: "Nic Neate" <Nic.Neate@dataconnection.com> To: "Aria - Adrian Farrel Personal" <adrian@olddog.co.uk>, <mpls@ietf.org> X-OriginalArrivalTime: 18 Jul 2008 10:45:40.0863 (UTC) FILETIME=[6C0590F0:01C8E8C3] Subject: Re: [mpls] RFC 4875 ERO processing details X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <https://www.ietf.org/mailman/private/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Hi Adrian, You've clarified what the correct interpretation of ERO compression in section 4.5 is, thanks. I think that means you agree with my SERO processing rules: > - each LSR needs to check the first hop of all SEROs > - if an LSR is the first hop of any SERO then it is a branch point > - a branch point needs to further analyze all SEROs to determine which branch each S2L sub-LSPs belongs to. That is contradictory to the statement in the RFC that "An LSR needs to process an S2L sub-LSP descriptor for a subsequent S2L sub-LSP only if the first hop in the corresponding SERO is a local address of that LSR". A branch point C might be faced with SEROs C-D-E, C-F and E-G-H. It needs to look at all the hops here, not just the first ones, to establish that the first and third S2L sub-LSPs are in one branch and the second is in another. Nic -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Aria - Adrian Farrel Personal Sent: 14 July 2008 14:58 To: Nic Neate; mpls@ietf.org Subject: Re: [mpls] RFC 4875 ERO processing details Nic, > (2) ERO compression details (section 4.5) > > Last paragraph in section 4.5 of the RFC states the following: > > All LSRs need to > process the ERO corresponding to the first S2L sub-LSP. An LSR needs > to process an S2L sub-LSP descriptor for a subsequent S2L sub-LSP > only if the first hop in the corresponding SERO is a local address of > that LSR. The branch LSR that is the first hop of an SERO propagates > the corresponding S2L sub-LSP downstream. > > I think that implies the following ERO compression technique. > - In Path messages sent by the source, all SEROs are specified right > from the first branch point in the P2MP LSP. > - At each branch point, SERO hops that come before the next branch > point are stripped off before Path messages are forwarded. I think you should re-read the example in the RFC. Each SERO runs from a branch point to a leaf. Compressed SEROs do not share any hops when the S2L LSPs they describe share resources. if two S2L LSPs follow the same path from some branch point LSR-A, and diverge downstream at LSR-B, one of the SEROs will begin at LSR-A and the other at LSR-B. Thus, there is no stripping of SEROs to be performed. > Thus, at any point in the P2MP tree, the hops to the next branch point > are only specified once in the ERO, but thereafter all SEROs are fully > specified even if they have large sections in common. As above. Look at the example in the RFC. I don't see any contradiction with the section 4.5 text. > That is not the ERO compression technique described in the example > earlier in section 4.5, and also not optimal for RSVP Path message size. > That suggests that the statement that "An LSR needs to process an S2L > sub-LSP descriptor for a subsequent S2L sub-LSP only if the first hop > in the corresponding SERO is a local address of that LSR" is inaccurate. > Instead > - each LSR needs to check the first hop of all SEROs > - if an LSR is the first hop of any SERO then it is a branch point > - a branch point needs to further analyze all SEROs to determine > which branch each S2L sub-LSPs belongs to. > > Further, failure to do that could lead to routing errors. Is that > understanding correct? Adrian _______________________________________________ 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 mpls-bounces@ietf.org Fri Jul 18 09:22:08 2008 Return-Path: <mpls-bounces@ietf.org> X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0A953A6A24; Fri, 18 Jul 2008 09:22:08 -0700 (PDT) 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 DFE8328C143 for <mpls@core3.amsl.com>; Fri, 18 Jul 2008 09:22:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.371 X-Spam-Level: X-Spam-Status: No, score=0.371 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HTML_MESSAGE=0.001, MISSING_SUBJECT=1.762] 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 bIgojZrevoGH for <mpls@core3.amsl.com>; Fri, 18 Jul 2008 09:22:03 -0700 (PDT) Received: from mx4.tellabs.com (mx4.tellabs.com [204.154.129.57]) by core3.amsl.com (Postfix) with ESMTP id 9C2913A6839 for <mpls@lists.ietf.org>; Fri, 18 Jul 2008 09:22:03 -0700 (PDT) X-SBRS: None X-IronPort-AV: E=Sophos;i="4.31,211,1215388800"; d="scan'208,217";a="1251553862" Received: from usnvwwms2c.hq.tellabs.com (HELO USNVEX3.tellabs-west.tellabsinc.net) ([172.23.216.105]) by mx4-priv.tellabs.com with ESMTP; 18 Jul 2008 16:22:30 +0000 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 18 Jul 2008 11:22:30 -0500 Message-ID: <E167ED46776D284B893BE52E888B69BC0AB820B1@USNVEX3.tellabs-west.tellabsinc.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Index: Acjo8nno1HRmnM9dSnmmJ3I3reKePw== From: "Verschoore de la Houssaye, Jerry" <Jerry.VerschooreDeLaHoussaye@tellabs.com> To: <mpls@lists.ietf.org> Subject: [mpls] (no subject) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <https://www.ietf.org/mailman/private/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> Content-Type: multipart/mixed; boundary="===============2000232415==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org This is a multi-part message in MIME format. --===============2000232415== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8E8F2.7A13953B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8E8F2.7A13953B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" unsubscribe =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D ------_=_NextPart_001_01C8E8F2.7A13953B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc= hemas-microsoft-com:office:word" xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> <style> <!-- /* Font Definitions */ @font-face {font-family:"Trebuchet MS"; panose-1:2 11 6 3 2 2 2 2 2 4;} @font-face {font-family:"Century Gothic"; panose-1:2 11 5 2 2 2 2 2 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0cm; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Trebuchet MS";} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:purple; text-decoration:underline;} span.EmailStyle17 {mso-style-type:personal-compose; font-family:"Century Gothic"; color:windowtext; font-weight:normal; font-style:italic; text-decoration:none none;} @page Section1 {size:595.3pt 841.9pt; margin:70.85pt 70.85pt 70.85pt 70.85pt;} div.Section1 {page:Section1;} --> </style> </head> <body lang=3DFR link=3Dblue vlink=3Dpurple> <div class=3DSection1> <p class=3DMsoNormal><i><font size=3D2 face=3D"Century Gothic"><span style=3D'font-size:11.0pt;font-family:"Century Gothic";font-style:italic'>u= nsubscribe<o:p></o:p></span></font></i></p> <p class=3DMsoNormal><i><font size=3D2 face=3D"Century Gothic"><span style=3D'font-size:11.0pt;font-family:"Century Gothic";font-style:italic'><= o:p> </o:p></span></font></i></p> </div> <pre>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The information contained in this message may be privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any reproduction, dissemination or distribution of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank you. Tellabs =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D </pre></body> </html> ------_=_NextPart_001_01C8E8F2.7A13953B-- --===============2000232415== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --===============2000232415==-- From mpls-bounces@ietf.org Mon Jul 21 01:37:25 2008 Return-Path: <mpls-bounces@ietf.org> X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ECE5B3A68DC; Mon, 21 Jul 2008 01:37:24 -0700 (PDT) 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 C54EF3A688C; Mon, 21 Jul 2008 01:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.924 X-Spam-Level: X-Spam-Status: No, score=-1.924 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, J_CHICKENPOX_57=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJ2OpThGH1Wp; Mon, 21 Jul 2008 01:37:21 -0700 (PDT) Received: from neo.viciousnest.net (neo.viciousnest.net [192.71.80.124]) by core3.amsl.com (Postfix) with ESMTP id 6EFB23A684B; Mon, 21 Jul 2008 01:37:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by neo.viciousnest.net (Postfix) with ESMTP id E99BF3F27E; Mon, 21 Jul 2008 10:37:54 +0200 (CEST) Received: from neo.viciousnest.net ([127.0.0.1]) by localhost (neo [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29377-03; Mon, 21 Jul 2008 10:37:50 +0200 (CEST) Received: from [127.0.0.1] (pat.acreo.se [217.151.195.214]) by neo.viciousnest.net (Postfix) with ESMTP id 962343F25D; Mon, 21 Jul 2008 10:37:49 +0200 (CEST) Message-ID: <48844AD7.8050305@pi.nu> Date: Mon, 21 Jul 2008 10:37:43 +0200 From: Loa Andersson <loa@pi.nu> User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Bob Briscoe <rbriscoe@jungle.bt.co.uk> References: <4875F9A1.5070408@pi.nu> <200807171916.m6HJGOFJ012556@bagheera.jungle.bt.co.uk> In-Reply-To: <200807171916.m6HJGOFJ012556@bagheera.jungle.bt.co.uk> X-Virus-Scanned: by amavisd-new at viciousnest.net Cc: L2VPN <l2vpn@ietf.org>, mpls@ietf.org, tsvwg@ietf.org, ccamp <ccamp@ops.ietf.org>, pwe3 <pwe3@ietf.org>, ahtmpls@itu.int Subject: Re: [mpls] [Tsvwg] multiple-working group last call on draft-ietf-mpls-cosfield-def-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <https://www.ietf.org/mailman/private/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Bob, thanks for useful comments :) Bob Briscoe wrote: > Loa, > > I believe this draft has no technical effect. However there is some > truth in the idea that names are important. > > So, let's set aside a few clock cycles to consider this... > > 1/ Is CoS a good description of ECN? Given RFC5129 (Using the EXP field > for ECN in MPLS), is it really appropriate now to call this a CoS field? > > Thinking out loud... > - CoS is a signal from an ingress to the interior (a request for a > certain class of service), > - whereas ECN is a signal from the interior forwarding plane to the > egress (a response from the interior saying whether the class of service > requested was congested). > > The way 5129 was done, two (or more) EXP codepoints can be designated as > the same CoS, but one can be used to say "this packet experienced > congestion when using this CoS", while the other says "it didn't". So, I > guess I could live with this field being called CoS, even though it's > not strictly correct. I can't think of anything better. We had the same discussion when we started to discuss this draft, we wanted to find a name the covered both cases. We just couldn't come with a better name, so we said "Let us call it 'CoS Field'" and change it someone comes up with something better. I'm still open to do that change, but time is kind of running out, the latest point in time we can do this change is an RFC editor note, when the IESG has approved the document. > > > 2/ BTW, Thanks for pointing out that the RFC Index doesn't identify > RFC5129 or RFC3270 as updates to RFC3032. > > According to a recent discussion on TSVWG with Bob Braden, the > annotation of the RFC Index is the responsibility of the RFC Editor, and > doesn't need to be driven by text in RFCs. So we can send an email to > the RFC Editor at any time asking for annotation to be added to the index. > > If no-one objects on this thread, will you be doing that? If not, I can. I'll do it. > > But does 5129 UPDATE 3270? I don't believe it does. 5129 deliberately > doesn't change or contradict anything in 3270. It complements it. I tend to agree, but have a problem how to capture this. We have obsoletes obsoleted by updates updated by Would the following change to the paragraph in the ID suffice: "We recommend this scheme, which we call `per-domain ECT checking', and define it more precisely in the following section. Its chief drawback is that it can cause packets to be forwarded after encountering congestion only to be dropped at the egress of the MPLS domain. The rationale for this decision is given in Section 8.1. This scheme is an update to RFC 3032 [RFC3032] and RFC 3270 [RFC3270] is extended to allow for CoS Field code points to encode ECN information." and - yes if you agree and could improve on grammar that would be great. "The problem" I have is that even with the changed version this is an "updates/updated by" the way it is used by the RFC Editor. We want to point to this extension from 3270 to give implementation context. /Loa PS you helped me pick another nit alos 5219 should be 5129 > > > Thoughts? > > > Bob > > At 12:59 10/07/2008, Loa Andersson wrote: >> All, >> >> this mail initiates a two week multiple-working group last call on >> >> draft-ietf-mpls-cosfield-def-04.txt >> >> Background: >> >> The name "EXP field" of a three bit field in the MPLS shim header, >> and the statement in RFC3032 "For experimental use" has led other >> SDOs to believe that this field could be used for any type of >> experiments. The field has however from the start been intended to >> carry Class of Service (CoS) information. >> >> The draft therefore renames the field "Class of Service (CoS) Field". >> >> This is an update of RFC3032, and also of drafts that builds on >> RFC3032. This multiple-working group last call is therefore sent to >> working groups with RFCs that has been updated. >> >> The document has been through wg last call in the mpls working group, >> which I don't think will stop that wg producing new comments now, >> nor should it :) . >> >> This working group last call is for CCAMP, L2VPN, PWE3 and TSVWG. >> >> Since this is also of interest in the work we started on a >> Transport Profile for MPLS (MPLS-TP) we are also sending it to the >> Ad HoC Team on MPLS in the ITU-T. >> >> Please review and send comments to the mpls wg mailing list, or to >> the mailing list for mpls-tp discussion that just been set up: >> >> mpls-tp@ietf.org >> >> or directly to the mpls wg co-chairs before e.o.b. July 24. >> >> /Loa >> >> -- >> Loa Andersson >> >> Principal Networking Architect >> Acreo AB phone: +46 8 632 77 14 >> Isafjordsgatan 22 mobile: +46 739 81 21 64 >> Kista, Sweden email: loa.andersson@acreo.se >> loa@pi.nu > > ____________________________________________________________________________ > > Notice: This contribution is the personal view of the author and does > not necessarily reflect the technical nor commercial direction of BT plc. > ____________________________________________________________________________ > > Bob Briscoe, Networks Research Centre, BT > Research > B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 > 645196 > -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.nu _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Jul 21 07:06:51 2008 Return-Path: <mpls-bounces@ietf.org> X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A8AC28C10E; Mon, 21 Jul 2008 07:06:51 -0700 (PDT) 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 C4DB43A6910; Mon, 21 Jul 2008 07:06:49 -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 C41YJCyBHUpl; Mon, 21 Jul 2008 07:06:49 -0700 (PDT) Received: from a2s13.a2hosting.com (a2s13.a2hosting.com [69.39.88.160]) by core3.amsl.com (Postfix) with ESMTP id D06583A6846; Mon, 21 Jul 2008 07:06:48 -0700 (PDT) Received: from adsl-76-242-40-69.dsl.sbndin.sbcglobal.net ([76.242.40.69] helo=[192.168.1.113]) by a2s13.a2hosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <johnkenney@alumni.nd.edu>) id 1KKw2p-0006T9-5d; Mon, 21 Jul 2008 10:07:19 -0400 Message-ID: <48849819.3000808@alumni.nd.edu> Date: Mon, 21 Jul 2008 10:07:21 -0400 From: John Kenney <johnkenney@alumni.nd.edu> User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Loa Andersson <loa@pi.nu> References: <4875F9A1.5070408@pi.nu> <200807171916.m6HJGOFJ012556@bagheera.jungle.bt.co.uk> <48844AD7.8050305@pi.nu> In-Reply-To: <48844AD7.8050305@pi.nu> X-Enigmail-Version: 0.95.6 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - a2s13.a2hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - alumni.nd.edu X-Source: X-Source-Args: X-Source-Dir: Cc: L2VPN <l2vpn@ietf.org>, mpls@ietf.org, tsvwg@ietf.org, Bob Briscoe <rbriscoe@jungle.bt.co.uk>, ccamp <ccamp@ops.ietf.org>, pwe3 <pwe3@ietf.org>, ahtmpls@itu.int Subject: Re: [mpls] [Tsvwg] multiple-working group last call on draft-ietf-mpls-cosfield-def-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <https://www.ietf.org/mailman/private/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Hi Loa, This is a good draft. It's time to rename the EXP field. While CoS Field may have been a good choice at one time, we've now heard from many who think it is too narrow for current usage of this field. I suggest "Traffic Management Field". Traffic management is a common, generic, and concise term. It covers all current uses of the field: scheduling class, drop priority, and congestion notification. CoS really only covers the first. Traffic management is well-scoped to this purpose, and clearly preferable to CoS in my opinion. In terms of the draft, I think a simple global substitution of "traffic management" for "class of service" and of "TM" for "CoS" should suffice. I think in the long run we'll be glad if we bite the bullet now and make this change. Best Regards, John Loa Andersson wrote: > > Bob, > > thanks for useful comments :) > > Bob Briscoe wrote: >> Loa, >> >> I believe this draft has no technical effect. However there is some >> truth in the idea that names are important. >> >> So, let's set aside a few clock cycles to consider this... >> >> 1/ Is CoS a good description of ECN? Given RFC5129 (Using the EXP >> field for ECN in MPLS), is it really appropriate now to call this a >> CoS field? >> >> Thinking out loud... >> - CoS is a signal from an ingress to the interior (a request for a >> certain class of service), >> - whereas ECN is a signal from the interior forwarding plane to the >> egress (a response from the interior saying whether the class of >> service requested was congested). >> >> The way 5129 was done, two (or more) EXP codepoints can be designated >> as the same CoS, but one can be used to say "this packet experienced >> congestion when using this CoS", while the other says "it didn't". >> So, I guess I could live with this field being called CoS, even >> though it's not strictly correct. I can't think of anything better. > > We had the same discussion when we started to discuss this draft, we > wanted to find a name the covered both cases. We just couldn't come > with a better name, so we said "Let us call it 'CoS Field'" and change > it someone comes up with something better. > > I'm still open to do that change, but time is kind of running out, the > latest point in time we can do this change is an RFC editor note, when > the IESG has approved the document. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Jul 21 08:14:11 2008 Return-Path: <mpls-bounces@ietf.org> X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A3CB3A6928; Mon, 21 Jul 2008 08:14:11 -0700 (PDT) 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 302203A67F3; Mon, 21 Jul 2008 08:14:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[AWL=0.814, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tp5aOaFgyStf; Mon, 21 Jul 2008 08:14:08 -0700 (PDT) Received: from smtp4.smtp.bt.com (smtp4.smtp.bt.com [217.32.164.151]) by core3.amsl.com (Postfix) with ESMTP id 012C03A689C; Mon, 21 Jul 2008 08:14:07 -0700 (PDT) Received: from E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.109]) by smtp4.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 21 Jul 2008 16:14:46 +0100 Received: from 10.215.40.109 ([10.215.40.109]) by E03MVB3-UKBR.domain1.systemhost.net ([193.113.197.60]) via Exchange Front-End Server mail.bt.com ([193.113.197.32]) with Microsoft Exchange Server HTTP-DAV ; Mon, 21 Jul 2008 15:14:45 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Mon, 21 Jul 2008 16:14:43 +0100 From: Ben Niven-Jenkins <benjamin.niven-jenkins@bt.com> To: John Kenney <johnkenney@alumni.nd.edu>, Loa Andersson <loa@pi.nu> Message-ID: <C4AA6673.892F%benjamin.niven-jenkins@bt.com> Thread-Topic: [mpls] [Tsvwg] multiple-working group last call on draft-ietf-mpls-cosfield-def-04.txt Thread-Index: AcjrRIC5+eyB+rhTFUGGUR5GYPN9AA== In-Reply-To: <48849819.3000808@alumni.nd.edu> Mime-version: 1.0 X-OriginalArrivalTime: 21 Jul 2008 15:14:46.0534 (UTC) FILETIME=[82D4B260:01C8EB44] Cc: L2VPN <l2vpn@ietf.org>, mpls@ietf.org, tsvwg@ietf.org, Bob Briscoe <rbriscoe@jungle.bt.co.uk>, ccamp <ccamp@ops.ietf.org>, pwe3 <pwe3@ietf.org>, ahtmpls@itu.int Subject: Re: [mpls] [Tsvwg] multiple-working group last call on draft-ietf-mpls-cosfield-def-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <https://www.ietf.org/mailman/private/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org I'm not precious about which term we use but if we use Traffic Management I think a paragraph should be added explaining what is meant to put it in context. Ben On 21/07/2008 15:07, "John Kenney" <johnkenney@alumni.nd.edu> wrote: > Hi Loa, > > This is a good draft. It's time to rename the EXP field. While CoS > Field may have been a good choice at one time, we've now heard from many > who think it is too narrow for current usage of this field. > > I suggest "Traffic Management Field". > > Traffic management is a common, generic, and concise term. It covers > all current uses of the field: scheduling class, drop priority, and > congestion notification. CoS really only covers the first. Traffic > management is well-scoped to this purpose, and clearly preferable to CoS > in my opinion. > > In terms of the draft, I think a simple global substitution of "traffic > management" for "class of service" and of "TM" for "CoS" should suffice. > > I think in the long run we'll be glad if we bite the bullet now and make > this change. > > Best Regards, > John > > > Loa Andersson wrote: >> >> Bob, >> >> thanks for useful comments :) >> >> Bob Briscoe wrote: >>> Loa, >>> >>> I believe this draft has no technical effect. However there is some >>> truth in the idea that names are important. >>> >>> So, let's set aside a few clock cycles to consider this... >>> >>> 1/ Is CoS a good description of ECN? Given RFC5129 (Using the EXP >>> field for ECN in MPLS), is it really appropriate now to call this a >>> CoS field? >>> >>> Thinking out loud... >>> - CoS is a signal from an ingress to the interior (a request for a >>> certain class of service), >>> - whereas ECN is a signal from the interior forwarding plane to the >>> egress (a response from the interior saying whether the class of >>> service requested was congested). >>> >>> The way 5129 was done, two (or more) EXP codepoints can be designated >>> as the same CoS, but one can be used to say "this packet experienced >>> congestion when using this CoS", while the other says "it didn't". >>> So, I guess I could live with this field being called CoS, even >>> though it's not strictly correct. I can't think of anything better. >> >> We had the same discussion when we started to discuss this draft, we >> wanted to find a name the covered both cases. We just couldn't come >> with a better name, so we said "Let us call it 'CoS Field'" and change >> it someone comes up with something better. >> >> I'm still open to do that change, but time is kind of running out, the >> latest point in time we can do this change is an RFC editor note, when >> the IESG has approved the document. > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Jul 21 09:57:40 2008 Return-Path: <mpls-bounces@ietf.org> X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BBBD3A6A6F; Mon, 21 Jul 2008 09:57:40 -0700 (PDT) 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 9367A28C0DE for <mpls@core3.amsl.com>; Thu, 17 Jul 2008 12:16:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.48 X-Spam-Level: X-Spam-Status: No, score=-1.48 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, DNS_FROM_RFC_BOGUSMX=1.482, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-753+hoA5bU for <mpls@core3.amsl.com>; Thu, 17 Jul 2008 12:16:10 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id 218D33A6ACA for <mpls@ietf.org>; Thu, 17 Jul 2008 12:16:09 -0700 (PDT) Received: from i2kc06-ukbr.domain1.systemhost.net ([193.113.197.70]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jul 2008 20:16:39 +0100 Received: from cbibipnt05.iuser.iroot.adidom.com ([147.149.196.177]) by i2kc06-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Jul 2008 20:16:39 +0100 Received: From bagheera.jungle.bt.co.uk ([132.146.168.158]) by cbibipnt05.iuser.iroot.adidom.com (WebShield SMTP v4.5 MR1a P0803.399); id 1216322196801; Thu, 17 Jul 2008 20:16:36 +0100 Received: from mut.jungle.bt.co.uk ([10.73.81.228]) by bagheera.jungle.bt.co.uk (8.13.5/8.12.8) with ESMTP id m6HJGOFJ012556; Thu, 17 Jul 2008 20:16:33 +0100 Message-Id: <200807171916.m6HJGOFJ012556@bagheera.jungle.bt.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 17 Jul 2008 20:16:24 +0100 To: Loa Andersson <loa@pi.nu> From: Bob Briscoe <rbriscoe@jungle.bt.co.uk> In-Reply-To: <4875F9A1.5070408@pi.nu> References: <4875F9A1.5070408@pi.nu> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.56 on 132.146.168.158 X-OriginalArrivalTime: 17 Jul 2008 19:16:39.0150 (UTC) FILETIME=[A35F28E0:01C8E841] X-Mailman-Approved-At: Mon, 21 Jul 2008 09:57:39 -0700 Cc: L2VPN <l2vpn@ietf.org>, mpls@ietf.org, tsvwg@ietf.org, ccamp <ccamp@ops.ietf.org>, pwe3 <pwe3@ietf.org>, ahtmpls@itu.int Subject: Re: [mpls] [Tsvwg] multiple-working group last call on draft-ietf-mpls-cosfield-def-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <https://www.ietf.org/mailman/private/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Loa, I believe this draft has no technical effect. However there is some truth in the idea that names are important. So, let's set aside a few clock cycles to consider this... 1/ Is CoS a good description of ECN? Given RFC5129 (Using the EXP field for ECN in MPLS), is it really appropriate now to call this a CoS field? Thinking out loud... - CoS is a signal from an ingress to the interior (a request for a certain class of service), - whereas ECN is a signal from the interior forwarding plane to the egress (a response from the interior saying whether the class of service requested was congested). The way 5129 was done, two (or more) EXP codepoints can be designated as the same CoS, but one can be used to say "this packet experienced congestion when using this CoS", while the other says "it didn't". So, I guess I could live with this field being called CoS, even though it's not strictly correct. I can't think of anything better. 2/ BTW, Thanks for pointing out that the RFC Index doesn't identify RFC5129 or RFC3270 as updates to RFC3032. According to a recent discussion on TSVWG with Bob Braden, the annotation of the RFC Index is the responsibility of the RFC Editor, and doesn't need to be driven by text in RFCs. So we can send an email to the RFC Editor at any time asking for annotation to be added to the index. If no-one objects on this thread, will you be doing that? If not, I can. But does 5129 UPDATE 3270? I don't believe it does. 5129 deliberately doesn't change or contradict anything in 3270. It complements it. Thoughts? Bob At 12:59 10/07/2008, Loa Andersson wrote: >All, > >this mail initiates a two week multiple-working group last call on > >draft-ietf-mpls-cosfield-def-04.txt > >Background: > >The name "EXP field" of a three bit field in the MPLS shim header, >and the statement in RFC3032 "For experimental use" has led other >SDOs to believe that this field could be used for any type of >experiments. The field has however from the start been intended to >carry Class of Service (CoS) information. > >The draft therefore renames the field "Class of Service (CoS) Field". > >This is an update of RFC3032, and also of drafts that builds on >RFC3032. This multiple-working group last call is therefore sent to >working groups with RFCs that has been updated. > >The document has been through wg last call in the mpls working group, >which I don't think will stop that wg producing new comments now, >nor should it :) . > >This working group last call is for CCAMP, L2VPN, PWE3 and TSVWG. > >Since this is also of interest in the work we started on a >Transport Profile for MPLS (MPLS-TP) we are also sending it to the >Ad HoC Team on MPLS in the ITU-T. > >Please review and send comments to the mpls wg mailing list, or to >the mailing list for mpls-tp discussion that just been set up: > >mpls-tp@ietf.org > >or directly to the mpls wg co-chairs before e.o.b. July 24. > >/Loa > >-- >Loa Andersson > >Principal Networking Architect >Acreo AB phone: +46 8 632 77 14 >Isafjordsgatan 22 mobile: +46 739 81 21 64 >Kista, Sweden email: loa.andersson@acreo.se > loa@pi.nu ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Jul 21 09:57:40 2008 Return-Path: <mpls-bounces@ietf.org> X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA21A3A6ACC; Mon, 21 Jul 2008 09:57:40 -0700 (PDT) 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 1E0EE3A68AB; Mon, 21 Jul 2008 00:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_57=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Bzn7xHGYJ3v; Mon, 21 Jul 2008 00:23:37 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id E2D3C3A6806; Mon, 21 Jul 2008 00:23:36 -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 <0K4C002S0HWDTJ@szxga01-in.huawei.com>; Mon, 21 Jul 2008 15:24:13 +0800 (CST) Received: from huawei.com ([172.24.1.18]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0K4C008CHHWDAD@szxga01-in.huawei.com>; Mon, 21 Jul 2008 15:24:13 +0800 (CST) Received: from M00900002 ([10.47.95.249]) by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0K4C00MB8HVZB5@szxml03-in.huawei.com>; Mon, 21 Jul 2008 15:24:13 +0800 (CST) Date: Mon, 21 Jul 2008 09:24:02 +0200 From: Maarten Vissers <maarten.vissers@huawei.com> In-reply-to: <200807171916.m6HJGOFJ012556@bagheera.jungle.bt.co.uk> To: 'Bob Briscoe' <rbriscoe@jungle.bt.co.uk>, 'Loa Andersson' <loa@pi.nu> Message-id: <001201c8eb02$c32f5460$f95f2f0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Mailer: Microsoft Office Outlook 11 Thread-index: AcjqhLMDkrxTKH/TRL+HDl3R88PKvgAe/IRw X-Mailman-Approved-At: Mon, 21 Jul 2008 09:57:39 -0700 Cc: 'L2VPN' <l2vpn@ietf.org>, mpls@ietf.org, tsvwg@ietf.org, 'ccamp' <ccamp@ops.ietf.org>, 'pwe3' <pwe3@ietf.org>, ahtmpls@itu.int Subject: Re: [mpls] [Tsvwg] multiple-working group last call ondraft-ietf-mpls-cosfield-def-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org> List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe> List-Archive: <https://www.ietf.org/mailman/private/mpls> List-Post: <mailto:mpls@ietf.org> List-Help: <mailto:mpls-request@ietf.org?subject=help> List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe> Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Bob, Loa, I expect that the EXP bits carry 'Priority' and 'Drop Eligible' information. Is the term 'Class of Service' representing both elements? For the case of VPLS, the 'PW label stack entry header' replaces the 'VLAN Tag' and carries the 'vlan_identifier', 'priority' and 'drop_eligible' parameter information of the 802.1Q (E)M_UNITDATA primitive signals. The EXP field in this PW label stack entry then carries the Priority Code Point (PCP) information as specified in clause 6.7.3/802.1ad. I refer to this EXP field often as M-PCP field, and to the PW label stack entry header as 'MPLS label stack entry based VLAN (M-VLAN) Tag'. The 20-bit PW label field carries a 20-bit M-VID. Regards, Maarten -----Original Message----- From: l2vpn-bounces@ietf.org [mailto:l2vpn-bounces@ietf.org] On Behalf Of Bob Briscoe Sent: 17 July 2008 21:16 To: Loa Andersson Cc: L2VPN; mpls@ietf.org; tsvwg@ietf.org; ccamp; pwe3; ahtmpls@itu.int Subject: Re: [Tsvwg] multiple-working group last call ondraft-ietf-mpls-cosfield-def-04.txt Loa, I believe this draft has no technical effect. However there is some truth in the idea that names are important. So, let's set aside a few clock cycles to consider this... 1/ Is CoS a good description of ECN? Given RFC5129 (Using the EXP field for ECN in MPLS), is it really appropriate now to call this a CoS field? Thinking out loud... - CoS is a signal from an ingress to the interior (a request for a certain class of service), - whereas ECN is a signal from the interior forwarding plane to the egress (a response from the interior saying whether the class of service requested was congested). The way 5129 was done, two (or more) EXP codepoints can be designated as the same CoS, but one can be used to say "this packet experienced congestion when using this CoS", while the other says "it didn't". So, I guess I could live with this field being called CoS, even though it's not strictly correct. I can't think of anything better. 2/ BTW, Thanks for pointing out that the RFC Index doesn't identify RFC5129 or RFC3270 as updates to RFC3032. According to a recent discussion on TSVWG with Bob Braden, the annotation of the RFC Index is the responsibility of the RFC Editor, and doesn't need to be driven by text in RFCs. So we can send an email to the RFC Editor at any time asking for annotation to be added to the index. If no-one objects on this thread, will you be doing that? If not, I can. But does 5129 UPDATE 3270? I don't believe it does. 5129 deliberately doesn't change or contradict anything in 3270. It complements it. Thoughts? Bob At 12:59 10/07/2008, Loa Andersson wrote: >All, > >this mail initiates a two week multiple-working group last call on > >draft-ietf-mpls-cosfield-def-04.txt > >Background: > >The name "EXP field" of a three bit field in the MPLS shim header, >and the statement in RFC3032 "For experimental use" has led other >SDOs to believe that this field could be used for any type of >experiments. The field has however from the start been intended to >carry Class of Service (CoS) information. > >The draft therefore renames the field "Class of Service (CoS) Field". > >This is an update of RFC3032, and also of drafts that builds on >RFC3032. This multiple-working group last call is therefore sent to >working groups with RFCs that has been updated. > >The document has been through wg last call in the mpls working group, >which I don't think will stop that wg producing new comments now, >nor should it :) . > >This working group last call is for CCAMP, L2VPN, PWE3 and TSVWG. > >Since this is also of interest in the work we started on a >Transport Profile for MPLS (MPLS-TP) we are also sending it to the >Ad HoC Team on MPLS in the ITU-T. > >Please review and send comments to the mpls wg mailing list, or to >the mailing list for mpls-tp discussion that just been set up: > >mpls-tp@ietf.org > >or directly to the mpls wg co-chairs before e.o.b. July 24. > >/Loa > >-- >Loa Andersson > >Principal Networking Architect >Acreo AB phone: +46 8 632 77 14 >Isafjordsgatan 22 mobile: +46 739 81 21 64 >Kista, Sweden email: loa.andersson@acreo.se > loa@pi.nu ____________________________________________________________________________ Notice: This contribution is the personal view of the author and does not necessarily reflect the technical nor commercial direction of BT plc. ____________________________________________________________________________ Bob Briscoe, Networks Research Centre, BT Research B54/77 Adastral Park,Martlesham Heath,Ipswich,IP5 3RE,UK. +44 1473 645196 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mployment@itctransco.com Mon Jul 21 14:54:03 2008 Return-Path: <mployment@itctransco.com> X-Original-To: ietfarch-mpls-archive@core3.amsl.com Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A2973A68C6 for <ietfarch-mpls-archive@core3.amsl.com>; Mon, 21 Jul 2008 14:54:03 -0700 (PDT) X-Quarantine-ID: <WdABhgjOUhLN> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): From: VIAGRA \256 Official Site [...] X-Spam-Flag: NO X-Spam-Score: -15.809 X-Spam-Level: X-Spam-Status: No, score=-15.809 tagged_above=-999 required=5 tests=[BAYES_60=1, GB_I_LETTER=-2, GB_PHARMACY=1, HELO_EQ_DSL=1.129, HELO_EQ_PL=1.135, HOST_EQ_PL=1.95, HTML_FONT_FACE_BAD=0.884, HTML_IMAGE_RATIO_04=0.172, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, MONEY_BACK=0.001, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_PBL=0.905, SARE_FROM_DRUGS=1.666, SARE_UNI=0.591, URIBL_AB_SURBL=10, URIBL_BLACK=20, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 WdABhgjOUhLN for <ietfarch-mpls-archive@core3.amsl.com>; Mon, 21 Jul 2008 14:54:02 -0700 (PDT) Received: from aebk132.neoplus.adsl.tpnet.pl (aebk132.neoplus.adsl.tpnet.pl [79.186.36.132]) by core3.amsl.com (Postfix) with SMTP id 495423A6802 for <mpls-archive@ietf.org>; Mon, 21 Jul 2008 14:54:00 -0700 (PDT) Content-Return: allowed X-Mailer: CME-V6.5.4.3; MSN Received: (qmail 15761 by uid 513); Mon, 21 Jul 2008 11:54:36 +0100 Message-Id: <20080721125436.15763.qmail@aebk132.neoplus.adsl.tpnet.pl> To: <mpls-archive@ietf.org> Subject: Three Days Only! Extra 25% Off. Details Inside. From: VIAGRA ® Official Site <mpls-archive@ietf.org> MIME-Version: 1.0 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Date: Mon, 21 Jul 2008 14:54:00 -0700 (PDT) <html> <head> <title>Victoria's Secret
Must-Have Looks For Summer. If you are unable to see the images in this email, please click here.
Catalogue Quick Order Forward to a Friend



SPECIAL OFFER DETAILS:
*Easy Monthly Payments *No Risk 30-Day Money Back Guarantee

This special offer is available for only 3 days. Discounts are included in final prices.


You are receiving this email because you have subscribed to the Pharmacy® newsletter with the following address: mpls-archive@ietf.org.

Unsubscribe | Privacy policy | Contact us

© 2008 Pharmacy All rights reserved.
From mpls-bounces@ietf.org Tue Jul 22 07:00:04 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 88A603A6A21; Tue, 22 Jul 2008 07:00:04 -0700 (PDT) X-Original-To: mpls@lists.ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id BA3AC3A695D; Tue, 22 Jul 2008 07:00:01 -0700 (PDT) From: IESG Secretary To: ietf-announce@ietf.org Mime-Version: 1.0 Message-Id: <20080722140001.BA3AC3A695D@core3.amsl.com> Date: Tue, 22 Jul 2008 07:00:01 -0700 (PDT) Cc: mpls@lists.ietf.org Subject: [mpls] WG Action: RECHARTER: Multiprotocol Label Switching (mpls) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org The Multiprotocol Label Switching (mpls) working group in the Routing Area of the IETF has been rechartered. For additional information, please contact the Area Directors or the working group Chairs. Multiprotocol Label Switching (mpls) --------------------------------------------------- Current Status: Active Working Group Last Modified: 2008-07-21 Chairs: Chair(s): George Swallow Loa Andersson Routing Area Director(s): Ross Callon David Ward Routing Area Advisor: Ross Callon Mailing Lists: General Discussion: mpls@lists.ietf.org To Subscribe: https://www1.ietf.org/mailman/listinfo/mpls Archive: http://www.ietf.org/mail-archive/web/mpls/current/maillist.html Description of Working Group: The MPLS working group is responsible for standardizing a base technology for using label switching and for the implementation of label-switched paths over various packet based link-level technologies, such as Packet-over-Sonet, Frame Relay, ATM, and LAN technologies (e.g. all forms of Ethernet, Token Ring, etc.). This includes procedures and protocols for the distribution of labels between routers and encapsulation. The working group is also responsible for specifying the necessary management objects (e.g. as part of MIB modules) and OAM techniques for the functionality specified in the base MPLS technology. The first generation of the MPLS standards are largely complete, and the current WG work items are: - Define requirements, mechanisms and protocol extensions for point-to-multipoint (P2MP) MPLS - Define requirements, mechanisms and protocol extensions for traffic engineered point-to-multipoint (P2MP) MPLS, including soft preemption - Define requirements and mechanisms for MPLS OAM - Define an overall OAM framework for MPLS applications - MPLS-specific aspects of traffic engineering for multi-areas/multi-AS in cooperation with the CCAMP WG - Determine (with CCAMP) what procedures are appropriate for evaluating proposals to extend the MPLS and GMPLS protocols, and document these - Document current implementation practices for MPLS load sharing - Include extensions to the MPLS WG protocols and RFCs necessary to create an MPLS Transport Profile (MPLS TP). The work on the MPLS TP will be coordinated between the working groups (eg, MPLS, CCAMP, PWE3, and L2PVN) that are chartered to do MPLS TP work. The Working Group chairs tracking of the working group documents can be viewed at http://www.tla-group.com/~mpls/mpls-wg-docs.htm Goals and Milestones: Done Submit documents from original MPLS effort to IESG Done Framework for IP multicast over label-switched paths ready for advancement. Done LDP fault tolerance specification ready for advancement to Proposed Standard. Done Submit Definitions of Managed Objects for MultoiProtocol Label Switching, Label Distribution Protocol (LDP) to the IESG for publication as Proposed Standards Done Specification for MPLS-specific recovery ready for advancement. Done Submit Multiprotocol Label Switching (MPLS) Forward Equivalency Class-To-Next Hop Label Forwarding Entry Management Information Base to the IESG for publication as Proposed Standards Done Submit Multiprotocol Label Switching (MPLS) Label Switching Router (LSR), Management Information Base to the IESG for publication as Proposed Standards Done Submit Multiprotocol Label Switching (MPLS) Management Overview to the IESG for publication as Proposed Standards Done Submit Definitions of Textual Conventions for Multiprotocol Label Switching (MPLS) Management to the IESG for publication as Proposed Standards Done Submit Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base to the IESG for publication as Proposed Standards Done Submit the Traffic Engineering Link MIB to the IESG for as a Proposed Standard Done Submit a specification on Encapsulations to carry MPLS over IP and GRE to the IESG for as a Proposed Standard Done Submit specification on LSP Ping to the IESG for publication as a Proposed Standard Done Submit a document defining the scope, requirements, and issues to resolve for setup of P2MP TE LSPs (MPLS and GMPLS) Done Submit an OAM Framework Document to the IESG for publication as an Informational RFC Done Submit a BCP on MPLS load sharing to the IESG Done Submit specification on LSR Self Test to the IESG for publication as a Proposed Standard Done Submit document(s) specifying protocol extensions, enhancements and mechanisms for setup of P2MP TE LSPs Done Submit point to multipoint TE MIB to IESG as proposed standard Nov 2008 Submit EXP field clarification document to IESG as proposed standard Dec 2008 Submit a specification on Soft Pre-emption of LSP Tunnels to the IESG for publication as a Proposed Standard Jan 2009 Submit LDP extensions for P2MP LSPs Mar 2009 Submit MPLS security framework for publication as an informational RFC Jun 2009 Submit requirements for point-to-multipoint extensions to LDP _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Tue Jul 22 16:40:36 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B86533A6984; Tue, 22 Jul 2008 16:40:36 -0700 (PDT) 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 A235A3A6984; Tue, 22 Jul 2008 16:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.087 X-Spam-Level: X-Spam-Status: No, score=-17.087 tagged_above=-999 required=5 tests=[AWL=-0.088, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, USER_IN_DEF_WHITELIST=-15] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1oitkh3HC0a; Tue, 22 Jul 2008 16:40:34 -0700 (PDT) Received: from bosco.isi.edu (bosco.isi.edu [128.9.168.207]) by core3.amsl.com (Postfix) with ESMTP id C49CC3A6955; Tue, 22 Jul 2008 16:40:34 -0700 (PDT) Received: by bosco.isi.edu (Postfix, from userid 70) id CA0A614502D; Tue, 22 Jul 2008 16:41:16 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20080722234116.CA0A614502D@bosco.isi.edu> Date: Tue, 22 Jul 2008 16:41:16 -0700 (PDT) Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 5283 on LDP Extension for Inter-Area Label Switched Paths (LSPs) 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: , MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 5283 Title: LDP Extension for Inter-Area Label Switched Paths (LSPs) Author: B. Decraene, JL. Le Roux, I. Minei Status: Standards Track Date: July 2008 Mailbox: bruno.decraene@orange-ftgroup.com, jeanlouis.leroux@orange-ftgroup.com, ina@juniper.net Pages: 12 Characters: 26534 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-ldp-interarea-04.txt URL: http://www.rfc-editor.org/rfc/rfc5283.txt To facilitate the establishment of Label Switched Paths (LSPs) that would span multiple IGP areas in a given Autonomous System (AS), this document describes a new optional Longest-Match Label Mapping Procedure for the Label Distribution Protocol (LDP). This procedure allows the use of a label if the Forwarding Equivalence Class (FEC) Element matches an entry in the Routing Information Base (RIB). Matching is defined by an IP longest-match search and does not mandate an exact match. [STANDARDS TRACK] This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Jul 23 01:01:14 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C9E928C17C; Wed, 23 Jul 2008 01:01:14 -0700 (PDT) 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 BB6533A69FA; Wed, 23 Jul 2008 01:01:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.135 X-Spam-Level: X-Spam-Status: No, score=-0.135 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] 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 afLSWv9uMcWD; Wed, 23 Jul 2008 01:01:05 -0700 (PDT) Received: from smtp2.smtp.bt.com (smtp2.smtp.bt.com [217.32.164.150]) by core3.amsl.com (Postfix) with ESMTP id F3EC13A68EA; Wed, 23 Jul 2008 01:01:03 -0700 (PDT) Received: from E03MVA1-UKBR.domain1.systemhost.net ([193.113.197.102]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 23 Jul 2008 09:01:43 +0100 Received: from 217.32.164.184 ([217.32.164.184]) by E03MVA1-UKBR.domain1.systemhost.net ([193.113.197.53]) via Exchange Front-End Server mail.bt.com ([193.113.197.28]) with Microsoft Exchange Server HTTP-DAV ; Wed, 23 Jul 2008 08:01:42 +0000 User-Agent: Microsoft-Entourage/12.11.0.080522 Date: Wed, 23 Jul 2008 09:00:31 +0100 From: Raymond Zhang To: , Message-ID: Thread-Topic: MPLS 2008 to take place in October 19-22, 2008 in Washington, DC (www.mpls2008.com) Thread-Index: Acjsmi1ZcTCOR9YIgU6GIYhyd0qlyA== Mime-version: 1.0 X-OriginalArrivalTime: 23 Jul 2008 08:01:43.0150 (UTC) FILETIME=[585A70E0:01C8EC9A] Subject: [mpls] MPLS 2008 to take place in October 19-22, 2008 in Washington, DC (www.mpls2008.com) 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: , Content-Type: multipart/mixed; boundary="===============0622303422==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0622303422== Content-type: multipart/alternative; boundary="B_3299648432_27805867" > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3299648432_27805867 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable MPLS 2008 to take place in October 19-22, 2008 in Washington, DC (www.mpls2008.com ) MPLS2008, the 11th annual International Conference on MPLS and Related Technologies, and the major event in next generation Internet will be held October 19-22 in Washington, DC. This will be followed by a public Interop demo on October 23 at Isocore facilities. The full program is available at http://www.isocore.com/mpls2008/program/technical_sessions.htm . MPLS 2008 will include an extensive four day program that consists of tutorials, technical sessions, panels, and exhibits. The key topics to be discussed at this year=B9s conference include: MPLS applicability in transport, Carrier Ethernet deployments and experiences, IPv6 transition, Multicast over Ethernet and MPLS, Mobile and Wireless backhaul, Content Delivery, Resiliency, and OAM aspects. Registration for MPLS2008 is open now at http://www.isocore.com/mpls2008/registration/attendees.htm. The rooms are limited and hotel reservations can be made at: http://www.isocore.com/mpls2008/hotel.htm. A public interop demo is also scheduled with the conference - http://www.mpls2008.com/program/inter_op.ht= m We look forward to seeing at the conference! Regards, Raymond --B_3299648432_27805867 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable MPLS 2008 to take place in October 19-22, 2008 in Washington, DC (ww= w.mpls2008.com) MPLS = 2008 to take place in October 19-22, 2008 in Washington, DC (www.mpls2008.co= m <<= FONT COLOR=3D"#0000FF">http://www.mpls200= 8.com> )

MPLS2008, the 11th annual International Conference on MPLS and Relat= ed Technologies, and the major event in next generation Internet will be hel= d October 19-22 in Washington, DC.  This will be followed by a public I= nterop demo on October 23 at Isocore facilities. The full program is availab= le at http://www.isocore.com/mpls2008/program/technica= l_sessions.htm .  MPLS 2008 will include an extensive fo= ur day program that consists of tutorials, technical sessions, panels, and e= xhibits. The key topics to be discussed at this year’s conference incl= ude: MPLS applicability in transport, Carrier Ethernet deployments and exper= iences, IPv6 transition, Multicast over Ethernet and MPLS, Mobile and Wirele= ss backhaul, Content Delivery, Resiliency, and OAM aspects. Registration for= MPLS2008 is open now at http://www.isocore.com/mpls2008/r= egistration/attendees.htm. The rooms are limited and hotel re= servations can be made at: http://www.isocore.com/mpls2008/hotel.htm. A public interop demo is also scheduled with the co= nference - http://www.mpls2008.com/program/inter_op.htm
 <http://www.mpls2008.com/program/inter_op.htm>  <http://www.mpls2008.com/program/inter_op.htm<= /FONT>>
We look forward to seeing at the conference!


Regards,
Raymond
 --B_3299648432_27805867-- --===============0622303422== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --===============0622303422==-- From mployeeownerrelations@saic.com Wed Jul 23 16:09:29 2008 Return-Path: X-Original-To: ietfarch-mpls-archive@core3.amsl.com Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C8983A6809 for ; Wed, 23 Jul 2008 16:09:29 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, Non-encoded 8-bit data (char AE hex): From: VIAGRA \256 Official Site [...] X-Spam-Flag: NO X-Spam-Score: -36.913 X-Spam-Level: X-Spam-Status: No, score=-36.913 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DRUGS_ERECTILE=1, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, GB_PHARMACY=1, HELO_DYNAMIC_IPADDR=2.426, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.457, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E4_51_100=1.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_PBL=0.905, RCVD_IN_SORBS_DUL=0.877, RCVD_IN_XBL=3.033, RDNS_DYNAMIC=0.1, SARE_FROM_DRUGS=1.666, URIBL_JP_SURBL=10, URIBL_OB_SURBL=10, URIBL_SC_SURBL=10, URIBL_WS_SURBL=10, 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 zTC+Zow0dXwX for ; Wed, 23 Jul 2008 16:09:23 -0700 (PDT) Received: from c-76-120-79-11.hsd1.co.comcast.net (c-76-120-79-11.hsd1.co.comcast.net [76.120.79.11]) by core3.amsl.com (Postfix) with SMTP id 0ACE13A6768 for ; Wed, 23 Jul 2008 16:09:22 -0700 (PDT) Message-Id: <20080723-21003.133091.qmail@c-76-120-79-11.hsd1.co.comcast.net> To: Subject: Dear mpls-archive@ietf.org Sweet summer 2008: Only for You mpls-archive@ietf.org From: VIAGRA ® Official Site MIME-Version: 1.0 Content-Type: text/html Date: Wed, 23 Jul 2008 16:09:22 -0700 (PDT)
If you are having trouble viewing this email, please click here.

Privacy Policy Update Your Profile Unsubscribe

® 2008 Procter & Gamble
Viagra™ is a registered trademark of Pharmacy Company. Portions copyright Iconoculture, Inc.

P&G Privacy Team,

campaignid: trem5931


Message-Id: <20080722174644.5C00.342431-33118@web.vocalpoint.com>
From mpls-bounces@ietf.org Wed Jul 23 23:23:27 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8D603A68D9; Wed, 23 Jul 2008 23:23:27 -0700 (PDT) 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 6A2513A68D9 for ; Wed, 23 Jul 2008 23:23: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 vwGAOsN73AtN for ; Wed, 23 Jul 2008 23:23:25 -0700 (PDT) Received: from neo.viciousnest.net (neo.viciousnest.net [192.71.80.124]) by core3.amsl.com (Postfix) with ESMTP id 90CC13A68B7 for ; Wed, 23 Jul 2008 23:23:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by neo.viciousnest.net (Postfix) with ESMTP id 5E2683F2C4; Thu, 24 Jul 2008 08:24:08 +0200 (CEST) Received: from neo.viciousnest.net ([127.0.0.1]) by localhost (neo [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28450-02; Thu, 24 Jul 2008 08:24:06 +0200 (CEST) Received: from [127.0.0.1] (2.234.241.83.in-addr.dgcsystems.net [83.241.234.2]) by neo.viciousnest.net (Postfix) with ESMTP id 4B9D33F2B6; Thu, 24 Jul 2008 08:24:06 +0200 (CEST) Message-ID: <48881FFC.80602@pi.nu> Date: Thu, 24 Jul 2008 08:23:56 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: mpls@ietf.org, George Swallow X-Virus-Scanned: by amavisd-new at viciousnest.net Subject: [mpls] implementations of draft-ietf-mpls-ldp-typed-wildcard-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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org All, we are preparing to send draft-ietf-mpls-ldp-typed-wildcard-03.txt to the IESG to be reviewed as an RFC on the standards track. We would like to know if there are any implementations of this specification. Please respond to the wg chairs. Loa and George -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.nu _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From ecestjoe@ns.sympatico.ca Fri Jul 25 19:56:56 2008 Return-Path: X-Original-To: ietfarch-mpls-archive@core3.amsl.com Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4194F3A6870 for ; Fri, 25 Jul 2008 19:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.552 X-Spam-Level: * X-Spam-Status: No, score=1.552 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_SBL=1.551] 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 2kIoGgKefDf0 for ; Fri, 25 Jul 2008 19:56:55 -0700 (PDT) Received: from toq2-srv.bellnexxia.net (toq2-srv.bellnexxia.net [209.226.175.121]) by core3.amsl.com (Postfix) with ESMTP id 6A9323A66B4 for ; Fri, 25 Jul 2008 19:56:55 -0700 (PDT) Received: from toip40-bus.srvr.bell.ca ([67.69.240.41]) by tomts44-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20080726004614.UFE1584.tomts44-srv.bellnexxia.net@toip40-bus.srvr.bell.ca>; Fri, 25 Jul 2008 20:46:14 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuwRAAQPikjR4q+H/2dsb2JhbACBOIg/iVWXPQ Received: from tofep3.bellnexxia.net (HELO smtp.bellnexxia.net) ([209.226.175.135]) by toip40-bus.srvr.bell.ca with SMTP; 25 Jul 2008 20:46:01 -0400 X-Mailer: Openwave WebEngine, version 2.8.11 (webedge20-101-194-20030622) X-Originating-IP: [81.199.172.185] From: Mrs.Sarah Criswell Reply-To: anderson.moore@btinternet.com To: Subject: File For Claim Date: Fri, 25 Jul 2008 20:46:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <20080726004614.UFE1584.tomts44-srv.bellnexxia.net@toip40-bus.srvr.bell.ca> POWER BALL LOTTERY BOARD Contact:Mr.Anderson Moore for the claim of =A31,000,000 pounds whichyou h= ave won in POWER BALL PROMO.Provide your Names Address Age Occupation Tel Country Email:anderson.moore@btinternet.com Sincerely, POWER BALL LOTTERY BOARD From mpls-bounces@ietf.org Sun Jul 27 22:25:40 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 505D93A6A6E; Sun, 27 Jul 2008 22:25:40 -0700 (PDT) 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 DEC9B3A6A31; Sun, 27 Jul 2008 22:25:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 LB0WiVmA6+p5; Sun, 27 Jul 2008 22:25:37 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by core3.amsl.com (Postfix) with ESMTP id 19F203A6A76; Sun, 27 Jul 2008 22:25:37 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=USBixSBKtnng10SUkppC3uzQTKSwUbV5fhxpznGkhqG7S2ywDpT/YU77ArGnu9BT; h=Received:Message-ID:From:To:Cc:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MIMEOLE:X-ELNK-Trace:X-Originating-IP; Received: from [141.154.115.63] (helo=JoanPC) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1KNLC8-0007Rq-Qm; Mon, 28 Jul 2008 01:22:53 -0400 Message-ID: <00a801c8f071$a30c6b90$6601a8c0@JoanPC> From: "Joan Cucchiara" To: "Thomas D. Nadeau" , "Agrahara S Kiran Koushik" Date: Mon, 28 Jul 2008 01:20:23 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654ce41b85dfddf7bb14b7ee98306dd599aaf78f7fbf31ba7be350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 141.154.115.63 Cc: mpls@ietf.org, "MIB Doctors \(E-mail\)" Subject: [mpls] MIB Doctor review of draft-ietf-mpls-fastreroute-mib-09.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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Tom, et al., A great deal of work went into this latest draft. Thanks for that! The MIB compiler output is given, followed by Overall Comments and then specific comments. Thanks, Joan --- SMICNGPRO MIB Compiler Output ============================= MPLS-FRR-GENERAL-STD-MIB W: f(MPLS-FRR-GENERAL-STD-MIB), (5,8) "Integer32" imported but not used W: f(MPLS-FRR-GENERAL-STD-MIB), (6,8) "NOTIFICATION-TYPE" imported but not used W: f(MPLS-FRR-GENERAL-STD-MIB), (9,8) "NOTIFICATION-GROUP" imported but not used W: f(MPLS-FRR-GENERAL-STD-MIB), (11,8) "TruthValue" imported but not used W: f(MPLS-FRR-GENERAL-STD-MIB), (13,8) "InterfaceIndex" imported but not used MPLS-FRR-ONE2ONE-STD-MIB E: f(MPLS-FRR-ONE2ONE-STD-MIB), (74,35) Leading sub-Id "mplsOne2OneFrrMIB" is not known in current module E: f(MPLS-FRR-ONE2ONE-STD-MIB), (398,30) Item "mplsFrrScalarGroup" should be IMPORTed E: f(MPLS-FRR-ONE2ONE-STD-MIB), (399,30) Item "mplsFrrTunnelARHopGroup" should be IMPORTed E: f(MPLS-FRR-ONE2ONE-STD-MIB), (400,30) Item "mplsFrrConstraintsGroup" should be IMPORTed W: f(MPLS-FRR-ONE2ONE-STD-MIB), (5,19) "Unsigned32" imported but not used W: f(MPLS-FRR-ONE2ONE-STD-MIB), (6,8) "NOTIFICATION-TYPE" imported but not used W: f(MPLS-FRR-ONE2ONE-STD-MIB), (6,27) "Gauge32" imported but not used W: f(MPLS-FRR-ONE2ONE-STD-MIB), (9,8) "NOTIFICATION-GROUP" imported but not used W: f(MPLS-FRR-ONE2ONE-STD-MIB), (11,20) "RowStatus" imported but not used W: f(MPLS-FRR-ONE2ONE-STD-MIB), (11,31) "StorageType" imported but not used W: f(MPLS-FRR-ONE2ONE-STD-MIB), (13,8) "InterfaceIndex" imported but not used W: f(MPLS-FRR-ONE2ONE-STD-MIB), (13,24) "InterfaceIndexOrZero" imported but not used W: f(MPLS-FRR-ONE2ONE-STD-MIB), (14,8) "ifGeneralInformationGroup" imported but not used W: f(MPLS-FRR-ONE2ONE-STD-MIB), (15,8) "ifCounterDiscontinuityGroup" imported but not used W: f(MPLS-FRR-ONE2ONE-STD-MIB), (21,8) "mplsTunnelGroup" imported but not used W: f(MPLS-FRR-ONE2ONE-STD-MIB), (21,25) "mplsTunnelScalarGroup" imported but not used W: f(MPLS-FRR-ONE2ONE-STD-MIB), (22,8) "mplsTunnelARHopListIndex" imported but not used W: f(MPLS-FRR-ONE2ONE-STD-MIB), (22,34) "mplsTunnelARHopIndex" imported but not used MPLS-FRR-FACILITY-STD-MIB E: f(MPLS-FRR-FACILITY-STD-MIB), (497,30) Item "mplsFrrScalarGroup" should be IMPORTed E: f(MPLS-FRR-FACILITY-STD-MIB), (498,30) Item "mplsFrrTunnelARHopGroup" should be IMPORTed E: f(MPLS-FRR-FACILITY-STD-MIB), (499,30) Item "mplsFrrConstraintsGroup" should be IMPORTed W: f(MPLS-FRR-FACILITY-STD-MIB), (11,20) "RowStatus" imported but not used W: f(MPLS-FRR-FACILITY-STD-MIB), (11,31) "StorageType" imported but not used W: f(MPLS-FRR-FACILITY-STD-MIB), (13,24) "InterfaceIndexOrZero" imported but not used W: f(MPLS-FRR-FACILITY-STD-MIB), (14,8) "ifGeneralInformationGroup" imported but not used W: f(MPLS-FRR-FACILITY-STD-MIB), (15,8) "ifCounterDiscontinuityGroup" imported but not used W: f(MPLS-FRR-FACILITY-STD-MIB), (22,8) "MplsTunnelAffinity" imported but not used W: f(MPLS-FRR-FACILITY-STD-MIB), (24,8) "mplsTunnelGroup" imported but not used W: f(MPLS-FRR-FACILITY-STD-MIB), (24,25) "mplsTunnelScalarGroup" imported but not used W: f(MPLS-FRR-FACILITY-STD-MIB), (25,8) "mplsTunnelARHopListIndex" imported but not used W: f(MPLS-FRR-FACILITY-STD-MIB), (25,34) "mplsTunnelARHopIndex" imported but not used W: f(MPLS-FRR-FACILITY-STD-MIB), (27,8) "InetAddressType" imported but not used W: f(MPLS-FRR-FACILITY-STD-MIB), (27,25) "InetAddress" imported but not used W: f(MPLS-FRR-FACILITY-STD-MIB), (526,5) OBJECT-GROUP "mplsFrrFacilityScalarGroup" is not used in a MODULE-COMPLIANCE in current module SMILINT Validation report File: MPLS-FRR-GENERAL-STD-MIB Severity level requested: 6 Line Severity Problem 5 5 warning: identifier `Integer32' imported from module`SNMPv2-SMI' is never used 6 5 warning: identifier `NOTIFICATION-TYPE' imported from module `SNMPv2-SMI' is never used 9 5 warning: identifier `NOTIFICATION-GROUP' imported from module `SNMPv2-CONF' is never used 11 5 warning: identifier `TruthValue' imported from module `SNMPv2-TC' is never used 13 5 warning: identifier `InterfaceIndex' imported from module `IF-MIB' is never used --- File: MPLS-FRR-FACILITY-STD-MIB Severity level requested: 6 Line Severity Problem 11 5 warning: identifier `RowStatus' imported from module `SNMPv2-TC' is never used 11 5 warning: identifier `StorageType' imported from module `SNMPv2-TC' is never used 13 5 warning: identifier `InterfaceIndexOrZero' imported from module `IF-MIB' is never used 14 5 warning: identifier `ifGeneralInformationGroup' imported from module `IF-MIB' is never used 15 5 warning: identifier `ifCounterDiscontinuityGroup' imported from module `IF-MIB' is never used 22 5 warning: identifier `MplsTunnelAffinity' imported from module `MPLS-TC-STD-MIB' is never used 24 5 warning: identifier `mplsTunnelGroup' imported from module `MPLS-TE-STD-MIB' is never used 24 5 warning: identifier `mplsTunnelScalarGroup' imported from module `MPLS-TE-STD-MIB' is never used 25 5 warning: identifier `mplsTunnelARHopListIndex' imported from module `MPLS-TE-STD-MIB' is never used 25 5 warning: identifier `mplsTunnelARHopIndex' imported from module `MPLS-TE-STD-MIB' is never used 27 5 warning: identifier `InetAddressType' imported from module `INET-ADDRESS-MIB' is never used 27 5 warning: identifier `InetAddress' imported from module `INET-ADDRESS-MIB' is never used 526 5 warning: current group `mplsFrrFacilityScalarGroup' is not referenced in this module -- File: MPLS-FRR-ONE2ONE-STD-MIB Severity level requested: 6 Line Severity Problem 74 1 unknown object identifier label 'mplsOne2OneFrrMIB' Overall COMMENTs --------------- *) One general comment is that the key words from section 1.1 (MUST/MUST NOT/SHOULD, etc.) should be utilized. I've made some suggestions in a few places (see below in The "Specific Comments" area wrt 4.1, 4.1.1, 4.2.1, 4.2) but I did NOT make suggestions for every section, so please review the other sections. Basically, you need to give a clear understanding of which MIB Modules need to be deployed. *) The first 3 or 4 comments on the MPLS-FRR-GENERAL-STD-MIB also apply to the other 2 MIB Modules but these were not repeated. Please update all 3 MIB Modules. COMMENTS ON DOC (as they appear in the doc) --------------------------------------------- *) TOC Section 4., 4.1, 4.2, 4.3, 4.4 and 4.5 and possibly others are incorrect in the TOC. 4.1.1, 4.1.2, 4.2.1, 4.2.2, 4.3.1, (maybe others) are missing from the TOC. Please regenerate the TOC. *) 4. Overview of MIB Module s/Module/Modules Please update the TOC for this new title. *) 4.1. MPLS-FRR-GENERAL-STD-MIB Some verbage needs to be added to specify if/when this MIB Module MUST/SHOULD be implemented. e.g. (this is just an example) This MIB Module MUST be implemented if either fast reroute method is supported. *) 4.1.1 mplsFrrConstraintsTable (Similar comment to above...need to specify using MUST/SHOULD language if possible) So, the last paragraph in this section: This table is used at the ingress node of the protected TE tunnel instance to configure backup LSP setup constraints. should be updated (as an example) This table MUST (or SHOULD) be implemented at the ingress node of the protected TE tunnel instance to configure backup LSP setup contraints. *) 4.2.1 mplsFrrTunnelARHopTable First sentence need a comma, after "availability", Last paragraph (similar comment as above, need to use language MUST/SHOULD) (as an example): This table MUST be supported when the Record Route Object (RRO) is supported by the implementation. *) 4.2 MPLS-FRR-ONE2ONE-STD-MIB * Please add something like: This MIB Module MUST be supported when the one-to-one backup method is used. *) 4.2.1 and 4.2.2 *) I'm a little unclear as to the relationship between these tables (PLR, Detour and the mplsTunnelTable). For every protected LSP these could be N-1 detours, and each detour is a tunnel and thus, there is an entry in the mplsTunnelTable. Could you explain how one entry in the PLR table (which represents the protected LSP) could be related to more than one entry in the Detour table and further, how can I lookup the Detour in the mplsTunnelTable? Please give a concrete example using actual values for the indices (similar to what was done in rfc3812 section 9). It would be good if you could do this with one protected LSP and more than one detour. *) 4.3 *) 4.3.1 mplsFrrFacilityDBTable *) 5. Handling IPv6 Tunnels *) Please update the names of the objects to match the current names in the MIB Modules. *) 6 MPLS-FRR-GENERAL-STD-MIB *) LAST-UPDATED and REVISION s/May/June *) Please remove the REVISION/DESCRIPTION clauses except for the latest version of the MIB. The REVISION clause is typically used for RFC revisions (not draft revisions). *) DESCRIPTION: ...This MIB module is part of RFC 4327; see the RFC itself for full legal notices. needs to be changed to something like This version of this MIB module is part of RFC xxxx; See the RFC itself for full legal notices. -- RFC EDITOR: please replace xxxx with actual number -- and remove this note. *) Please see RFC4181 Appendices C and D. prefixes need to be consistent, so either use "mplsFrrGeneral" or "mplsFrr" Also, the OID layout is not as suggested in rfc418 (and also breaks with the other MPLS which does follow the suggested OID layout.) xxxMIB | +-- xxxNotifications(0) +-- xxxObjects(1) +-- xxxConformance(2) | +-- xxxCompliances(1) +-- xxxGroups(2) Currently, mplsFrrNotifications ::= { mplsFrrGeneralMIB 0 } <-- there aren't any notifications so don't need to define this mplsFrrObjects ::= { mplsFrrGeneralMIB 1} mplsFrrGeneralObjects ::= { mplsFrrObjects 1} mplsFrrConformance ::= { mplsFrrObjects 2} *) mplsFrrProtectionMethod Scalar Please add to the DESCRIPTION the error that would be returned if unknown(1) were to be set (would think inconsistentValue error?) For example: The value of unknown(1) is read-only and cannot be set. If the value of unknown(1) is set an inconsistentValue error MUST be returned. *) NEW for mplsFrrProtectedMethod Please include in the DESCRIPTION clause what error should be returned if the value of unknown(1) is set. *) mplsFrrSwitchover Should this be a Gauge32? DESCRIPTION is awkward. Seems like you are trying to say the following: The number of tunnel instances for either detour LSPs or bypass tunnels for which this LSR is the ingress. *) mplsFrrConstraintsTable *) mplsFrrConstraintsEntry s/however, in these cases,/however,/ *) mplsFrrConstraintsTunnelIndex s/for which/which/ Don't understand the last part of the last sentence "as must exist in the mplsTunnelTable". What is it that must exist in the mplsTunnelTable? *) mplsFrrConstraintsProtectionType Could a reference be added for this? *) mplsFrrConstraintsSetupPrio Could a more specific section be given to the REFERENCE? The reason is that there is also a SetupPriority in RFC4090 and this draft discusses supporting rfc4090 *) mplsFrrConstraintsHoldingPrio Same request as above, for a more specific section in the REFERENCE? *) NEW mplsFrrConstraintHopLimit According to RFC4090 this looks to be a byte, so why is there not a range on this? Same question wrt Reference is this 4090 section 4.1 ? *) mplsFrrTunnelARHopProtectType Where is path(0) described in rfc4090? Would it be possible to rename link to bandwidth to use the same terms as in 4090? *) NIT: mplsFrrConstraintsGroup not in the order they appear in the table. This is a NIT. 6.1 MPLS-FRR-ONE2ONE-STD-MIB Scalars need to be updated to reflect that they are relevant to one-to-one reroute method. *) mplsFrrOne2OneDetourMergedDetourInst Please spell out Instance (to be consistent) 6.3 MPLS-FRR-FACILITY-STD-MIB Scalars need to be updated to be relevant only to the FRR Facility method. Think that these scalars should be Gauge32, since the number of interfaces will be changing. *) mplsFrrActiveProtectedLSPs (should this be in the MPLS-FRR-ONE2ONE-STD-MIB? *) mplsFrrFacilityNotificationsEnabled. Why is this object needed? Please answer the question wrt RFC3413. *) mplsFrrFacilityNotificationsMaxRate Are there other objects which indicate if events are being thrown away due to this throttling? (Would that be useful?) NOT DONE. Please answer the question. I would think such an object (or objects) would be useful information if throttling is done. *) mplsFrrFacilityDBTable s/mplsFrrFacilityProtIfIdx/mplsFrrFacilityProtectedIfIndex/ *) mplsFrrFacilityDBNumProtectingTunnelOnIf s/speficied/specified/ *) mplsFrrFacilityFinalTunnelRestored Need to remove the verbage about if this is the Facility method at the end of the DESCRIPTION. *) 7. Security Considerations s/in this MIB module./in these MIB modules. *) 8 IANA Considerations Need section 8.2 and 8.3 for the other 2 MIB Modules. *) 10.1 Normative References [RFC4090] Pan, P., Swallow, G., Atlas, A., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC4090, May 2005. and A. Atlas, -- end-- _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Jul 28 03:14:04 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A30A228C186; Mon, 28 Jul 2008 03:14:04 -0700 (PDT) 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 011B328C167; Mon, 28 Jul 2008 03:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, 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 h60PTpAqnSKF; Mon, 28 Jul 2008 03:13:56 -0700 (PDT) Received: from nj300815-nj-outbound.avaya.com (nj300815-nj-outbound.net.avaya.com [198.152.12.100]) by core3.amsl.com (Postfix) with ESMTP id 340C23A6890; Mon, 28 Jul 2008 03:13:56 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.31,265,1215403200"; d="scan'208";a="128830155" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 28 Jul 2008 06:14:02 -0400 X-IronPort-AV: E=Sophos;i="4.31,265,1215403200"; d="scan'208";a="244064998" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by co300216-co-erhwest-out.avaya.com with ESMTP; 28 Jul 2008 06:14:01 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 28 Jul 2008 12:14:01 +0200 Message-ID: In-Reply-To: <00a801c8f071$a30c6b90$6601a8c0@JoanPC> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MIB-DOCTORS] MIB Doctor review ofdraft-ietf-mpls-fastreroute-mib-09.txt Thread-Index: AcjwcmepEeQ173ivRbSfZNIyGp9H1gAILfCg References: <00a801c8f071$a30c6b90$6601a8c0@JoanPC> From: "Romascanu, Dan (Dan)" To: "Joan Cucchiara" , "Thomas D. Nadeau" , "Agrahara S Kiran Koushik" Cc: mpls@ietf.org, "MIB Doctors \(E-mail\)" Subject: Re: [mpls] [MIB-DOCTORS] MIB Doctor review ofdraft-ietf-mpls-fastreroute-mib-09.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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Joan, Thank you for the review. Dan > -----Original Message----- > From: mib-doctors-bounces@ietf.org > [mailto:mib-doctors-bounces@ietf.org] On Behalf Of Joan Cucchiara > Sent: Monday, July 28, 2008 8:20 AM > To: Thomas D. Nadeau; Agrahara S Kiran Koushik > Cc: Swallow George; mpls@ietf.org; MIB Doctors (E-mail); Loa Andersson > Subject: [MIB-DOCTORS] MIB Doctor review > ofdraft-ietf-mpls-fastreroute-mib-09.txt > > > Tom, et al., > > > A great deal of work went into this latest draft. Thanks for that! > > The MIB compiler output is given, followed by Overall > Comments and then specific comments. > > Thanks, > Joan > > --- > > > SMICNGPRO MIB Compiler Output > ============================= > MPLS-FRR-GENERAL-STD-MIB > W: f(MPLS-FRR-GENERAL-STD-MIB), (5,8) "Integer32" imported > but not used > W: f(MPLS-FRR-GENERAL-STD-MIB), (6,8) "NOTIFICATION-TYPE" > imported but not used > W: f(MPLS-FRR-GENERAL-STD-MIB), (9,8) "NOTIFICATION-GROUP" > imported but not used > W: f(MPLS-FRR-GENERAL-STD-MIB), (11,8) "TruthValue" imported > but not used > W: f(MPLS-FRR-GENERAL-STD-MIB), (13,8) "InterfaceIndex" > imported but not used > > > MPLS-FRR-ONE2ONE-STD-MIB > > E: f(MPLS-FRR-ONE2ONE-STD-MIB), (74,35) Leading sub-Id > "mplsOne2OneFrrMIB" > is not known in current module > E: f(MPLS-FRR-ONE2ONE-STD-MIB), (398,30) Item > "mplsFrrScalarGroup" should be IMPORTed > E: f(MPLS-FRR-ONE2ONE-STD-MIB), (399,30) Item > "mplsFrrTunnelARHopGroup" > should be IMPORTed > E: f(MPLS-FRR-ONE2ONE-STD-MIB), (400,30) Item > "mplsFrrConstraintsGroup" > should be IMPORTed > W: f(MPLS-FRR-ONE2ONE-STD-MIB), (5,19) "Unsigned32" imported > but not used > W: f(MPLS-FRR-ONE2ONE-STD-MIB), (6,8) "NOTIFICATION-TYPE" > imported but not used > W: f(MPLS-FRR-ONE2ONE-STD-MIB), (6,27) "Gauge32" imported but not used > W: f(MPLS-FRR-ONE2ONE-STD-MIB), (9,8) "NOTIFICATION-GROUP" > imported but not used > W: f(MPLS-FRR-ONE2ONE-STD-MIB), (11,20) "RowStatus" imported > but not used > W: f(MPLS-FRR-ONE2ONE-STD-MIB), (11,31) "StorageType" > imported but not used > W: f(MPLS-FRR-ONE2ONE-STD-MIB), (13,8) "InterfaceIndex" > imported but not used > W: f(MPLS-FRR-ONE2ONE-STD-MIB), (13,24) > "InterfaceIndexOrZero" imported but not used > W: f(MPLS-FRR-ONE2ONE-STD-MIB), (14,8) > "ifGeneralInformationGroup" imported but not used > W: f(MPLS-FRR-ONE2ONE-STD-MIB), (15,8) "ifCounterDiscontinuityGroup" > imported but not used > W: f(MPLS-FRR-ONE2ONE-STD-MIB), (21,8) "mplsTunnelGroup" > imported but not used > W: f(MPLS-FRR-ONE2ONE-STD-MIB), (21,25) > "mplsTunnelScalarGroup" imported but not used > W: f(MPLS-FRR-ONE2ONE-STD-MIB), (22,8) > "mplsTunnelARHopListIndex" imported but not used > W: f(MPLS-FRR-ONE2ONE-STD-MIB), (22,34) > "mplsTunnelARHopIndex" imported but not used > > > > MPLS-FRR-FACILITY-STD-MIB > E: f(MPLS-FRR-FACILITY-STD-MIB), (497,30) Item > "mplsFrrScalarGroup" should be IMPORTed > E: f(MPLS-FRR-FACILITY-STD-MIB), (498,30) Item > "mplsFrrTunnelARHopGroup" > should be IMPORTed > E: f(MPLS-FRR-FACILITY-STD-MIB), (499,30) Item > "mplsFrrConstraintsGroup" > should be IMPORTed > W: f(MPLS-FRR-FACILITY-STD-MIB), (11,20) "RowStatus" imported > but not used > W: f(MPLS-FRR-FACILITY-STD-MIB), (11,31) "StorageType" > imported but not used > W: f(MPLS-FRR-FACILITY-STD-MIB), (13,24) > "InterfaceIndexOrZero" imported but not used > W: f(MPLS-FRR-FACILITY-STD-MIB), (14,8) > "ifGeneralInformationGroup" imported but not used > W: f(MPLS-FRR-FACILITY-STD-MIB), (15,8) "ifCounterDiscontinuityGroup" > imported but not used > W: f(MPLS-FRR-FACILITY-STD-MIB), (22,8) "MplsTunnelAffinity" > imported but not used > W: f(MPLS-FRR-FACILITY-STD-MIB), (24,8) "mplsTunnelGroup" > imported but not used > W: f(MPLS-FRR-FACILITY-STD-MIB), (24,25) > "mplsTunnelScalarGroup" imported but not used > W: f(MPLS-FRR-FACILITY-STD-MIB), (25,8) > "mplsTunnelARHopListIndex" imported but not used > W: f(MPLS-FRR-FACILITY-STD-MIB), (25,34) > "mplsTunnelARHopIndex" imported but not used > W: f(MPLS-FRR-FACILITY-STD-MIB), (27,8) "InetAddressType" > imported but not used > W: f(MPLS-FRR-FACILITY-STD-MIB), (27,25) "InetAddress" > imported but not used > W: f(MPLS-FRR-FACILITY-STD-MIB), (526,5) OBJECT-GROUP > "mplsFrrFacilityScalarGroup" > is not used in a MODULE-COMPLIANCE in current module > > > > > > > > SMILINT > > Validation report > > > File: MPLS-FRR-GENERAL-STD-MIB > Severity level requested: 6 > > Line Severity Problem > 5 5 warning: identifier `Integer32' imported from > module`SNMPv2-SMI' is never used > 6 5 warning: identifier `NOTIFICATION-TYPE' imported from > module `SNMPv2-SMI' is never used > 9 5 warning: identifier `NOTIFICATION-GROUP' imported from > module `SNMPv2-CONF' is never used > 11 5 warning: identifier `TruthValue' imported from module > `SNMPv2-TC' is never used > 13 5 warning: identifier `InterfaceIndex' imported from > module `IF-MIB' is never used > > --- > > File: MPLS-FRR-FACILITY-STD-MIB > Severity level requested: 6 > > Line Severity Problem > 11 5 warning: identifier `RowStatus' imported from module > `SNMPv2-TC' is never used > 11 5 warning: identifier `StorageType' imported from module > `SNMPv2-TC' is never used > 13 5 warning: identifier `InterfaceIndexOrZero' imported from > module `IF-MIB' is never used > 14 5 warning: identifier `ifGeneralInformationGroup' imported > from module `IF-MIB' is never used > 15 5 warning: identifier `ifCounterDiscontinuityGroup' > imported from module `IF-MIB' is never used > 22 5 warning: identifier `MplsTunnelAffinity' imported from > module `MPLS-TC-STD-MIB' is never used > 24 5 warning: identifier `mplsTunnelGroup' imported from > module `MPLS-TE-STD-MIB' is never used > 24 5 warning: identifier `mplsTunnelScalarGroup' imported > from module `MPLS-TE-STD-MIB' is never used > 25 5 warning: identifier `mplsTunnelARHopListIndex' imported > from module `MPLS-TE-STD-MIB' is never used > 25 5 warning: identifier `mplsTunnelARHopIndex' imported from > module `MPLS-TE-STD-MIB' is never used > 27 5 warning: identifier `InetAddressType' imported from > module `INET-ADDRESS-MIB' is never used > 27 5 warning: identifier `InetAddress' imported from module > `INET-ADDRESS-MIB' is never used > 526 5 warning: current group `mplsFrrFacilityScalarGroup' is > not referenced in this module > > -- > > File: MPLS-FRR-ONE2ONE-STD-MIB > Severity level requested: 6 > > Line Severity Problem > 74 1 unknown object identifier label 'mplsOne2OneFrrMIB' > > > Overall COMMENTs > --------------- > > > *) One general comment is that the key words from section 1.1 > (MUST/MUST NOT/SHOULD, etc.) should be utilized. I've made > some suggestions in a few places (see below in The "Specific Comments" > area wrt 4.1, 4.1.1, 4.2.1, 4.2) but I did NOT make > suggestions for every section, so please review the other > sections. Basically, you need to give a clear understanding > of which MIB Modules need to be deployed. > > > *) The first 3 or 4 comments on the MPLS-FRR-GENERAL-STD-MIB > also apply to the other 2 MIB Modules but these were not > repeated. Please update all 3 MIB Modules. > > > > > COMMENTS ON DOC (as they appear in the doc) > --------------------------------------------- > > *) TOC > > Section 4., 4.1, 4.2, 4.3, 4.4 and 4.5 > and possibly others are incorrect in the TOC. > > 4.1.1, 4.1.2, 4.2.1, 4.2.2, 4.3.1, > (maybe others) are missing from the TOC. > > Please regenerate the TOC. > > > *) 4. Overview of MIB Module > > s/Module/Modules > > Please update the TOC for this new title. > > > > *) 4.1. MPLS-FRR-GENERAL-STD-MIB > > Some verbage needs to be added to > specify if/when this MIB Module MUST/SHOULD be implemented. > > e.g. (this is just an example) > This MIB Module MUST be implemented if either fast reroute > method is supported. > > > > *) 4.1.1 mplsFrrConstraintsTable > > (Similar comment to above...need to specify using MUST/SHOULD > language if possible) > > So, the last paragraph in this section: > > This table is used at the ingress node of the protected TE > tunnel instance to configure backup LSP setup constraints. > > should be updated (as an example) > This table MUST (or SHOULD) be implemented at the > ingress node of the protected TE > tunnel instance to configure backup LSP setup contraints. > > > > *) 4.2.1 mplsFrrTunnelARHopTable > > First sentence need a comma, after "availability", > > Last paragraph (similar comment as above, need to use > language MUST/SHOULD) > > (as an example): > This table MUST be supported when the Record Route Object > (RRO) is supported > by the implementation. > > > > *) 4.2 MPLS-FRR-ONE2ONE-STD-MIB > > * Please add something like: > > This MIB Module MUST be supported when the one-to-one > backup method is > used. > > > *) 4.2.1 and 4.2.2 > > > *) I'm a little unclear as to the relationship between these tables > (PLR, Detour and the mplsTunnelTable). > > For every protected LSP these could be N-1 detours, and each detour is > a tunnel and thus, there is an entry in the mplsTunnelTable. > > Could you explain how one entry in the PLR table (which represents the > protected LSP) could be related to > more than one entry in the Detour table and further, how can I lookup > the Detour in the mplsTunnelTable? > > Please give a concrete example using actual values for the indices > (similar to what was done in rfc3812 section 9). It would be good > if you could do this with one protected LSP and more than one detour. > > > > *) 4.3 > > > *) 4.3.1 mplsFrrFacilityDBTable > > > *) 5. Handling IPv6 Tunnels > > > *) Please update the names of the objects to match the current > names in the MIB Modules. > > > > *) 6 MPLS-FRR-GENERAL-STD-MIB > > > *) LAST-UPDATED and REVISION > > s/May/June > > > > *) Please remove the REVISION/DESCRIPTION clauses > except for the latest version of the MIB. The REVISION > clause is typically used for RFC revisions (not draft > revisions). > > *) DESCRIPTION: > ...This MIB module is part of RFC 4327; > see the RFC itself for full legal notices. > > needs to be changed to something like > > This version of this MIB module is part of RFC xxxx; > See the RFC itself for full legal notices. > > -- RFC EDITOR: please replace xxxx with actual number > -- and remove this note. > > > > *) Please see RFC4181 Appendices C and D. > > prefixes need to be consistent, so either use > "mplsFrrGeneral" or "mplsFrr" > > Also, the OID layout is not as suggested in rfc418 (and also > breaks with > the other MPLS which does follow the suggested OID layout.) > > xxxMIB > | > +-- xxxNotifications(0) > +-- xxxObjects(1) > +-- xxxConformance(2) > | > +-- xxxCompliances(1) > +-- xxxGroups(2) > > Currently, > > mplsFrrNotifications ::= { mplsFrrGeneralMIB 0 } <-- there > aren't any > notifications > so > don't need to > define this > > mplsFrrObjects ::= { mplsFrrGeneralMIB 1} > mplsFrrGeneralObjects ::= { mplsFrrObjects 1} > mplsFrrConformance ::= { mplsFrrObjects 2} > > > > > *) mplsFrrProtectionMethod Scalar > > Please add to the DESCRIPTION the error that would be returned if > unknown(1) were to be set (would think inconsistentValue error?) > > For example: > > The value of unknown(1) is read-only and cannot be set. If the > value of unknown(1) is set an inconsistentValue error MUST be > returned. > > > > > > *) NEW for mplsFrrProtectedMethod > Please include in the DESCRIPTION clause what > error should be returned if the value of unknown(1) is > set. > > > *) mplsFrrSwitchover > Should this be a Gauge32? > > DESCRIPTION is awkward. > > Seems like you are trying to say the following: > > The number of tunnel instances for either detour LSPs or > bypass tunnels > for which this LSR is the ingress. > > > > > *) mplsFrrConstraintsTable > > > *) mplsFrrConstraintsEntry > > s/however, in these cases,/however,/ > > > *) mplsFrrConstraintsTunnelIndex > > s/for which/which/ > > > Don't understand the last part of the last sentence > "as must exist in the mplsTunnelTable". What is it that > must exist in the mplsTunnelTable? > > > *) mplsFrrConstraintsProtectionType > > Could a reference be added for this? > > > *) mplsFrrConstraintsSetupPrio > > Could a more specific section be given > to the REFERENCE? The reason is that there > is also a SetupPriority in RFC4090 and > this draft discusses supporting rfc4090 > > > > *) mplsFrrConstraintsHoldingPrio > > Same request as above, for a more specific section > in the REFERENCE? > > > > > > *) NEW mplsFrrConstraintHopLimit > According to RFC4090 this looks to be a byte, so > why is there not a range on this? > > Same question wrt Reference > is this 4090 section 4.1 ? > > > > *) mplsFrrTunnelARHopProtectType > > Where is path(0) described in rfc4090? > > Would it be possible to rename link to bandwidth to > use the same terms as in 4090? > > > *) NIT: mplsFrrConstraintsGroup not in the order > they appear in the table. This is a NIT. > > > 6.1 MPLS-FRR-ONE2ONE-STD-MIB > > Scalars need to be updated to reflect that they > are relevant to one-to-one reroute method. > > > > > *) mplsFrrOne2OneDetourMergedDetourInst > > Please spell out Instance (to be consistent) > > > 6.3 MPLS-FRR-FACILITY-STD-MIB > > > Scalars need to be updated to be relevant only > to the FRR Facility method. > > Think that these scalars should be Gauge32, since > the number of interfaces will be changing. > > > *) mplsFrrActiveProtectedLSPs (should this be in > the MPLS-FRR-ONE2ONE-STD-MIB? > > > > *) mplsFrrFacilityNotificationsEnabled. > Why is this object needed? > > Please answer the question wrt RFC3413. > > > > *) mplsFrrFacilityNotificationsMaxRate > Are there other objects which indicate > if events are being thrown away due to this > throttling? (Would that be useful?) > > NOT DONE. Please answer the question. I would > think such an object (or objects) would be useful > information if throttling is done. > > > > > *) mplsFrrFacilityDBTable > > s/mplsFrrFacilityProtIfIdx/mplsFrrFacilityProtectedIfIndex/ > > > *) mplsFrrFacilityDBNumProtectingTunnelOnIf > s/speficied/specified/ > > > *) mplsFrrFacilityFinalTunnelRestored > > Need to remove the verbage about if this is the Facility method > at the end of the DESCRIPTION. > > > > *) 7. Security Considerations > > s/in this MIB module./in these MIB modules. > > > *) 8 IANA Considerations > > Need section 8.2 and 8.3 for the other 2 MIB Modules. > > > > *) 10.1 Normative References > > > [RFC4090] Pan, P., Swallow, G., Atlas, A., "Fast Reroute > Extensions to RSVP-TE for LSP Tunnels", RFC4090, > May 2005. > > and A. Atlas, > > > > -- end-- > > _______________________________________________ > MIB-DOCTORS mailing list > MIB-DOCTORS@ietf.org > https://www.ietf.org/mailman/listinfo/mib-doctors > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Jul 28 05:50:25 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E209628C0D8; Mon, 28 Jul 2008 05:50:24 -0700 (PDT) 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 962623A6893; Mon, 28 Jul 2008 05:50:23 -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 sgWxeIoV6hTU; Mon, 28 Jul 2008 05:50:21 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by core3.amsl.com (Postfix) with ESMTP id 965693A67DB; Mon, 28 Jul 2008 05:50:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by lucidvision.com (Postfix) with ESMTP id B179352A70D; Mon, 28 Jul 2008 08:50:57 -0400 (EDT) Received: from lucidvision.com ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22828-05; Mon, 28 Jul 2008 08:50:28 -0400 (EDT) Received: from [10.186.150.51] (m2f5e36d0.tmodns.net [208.54.94.47]) by lucidvision.com (Postfix) with ESMTP id 3EBAA52A6DD; Mon, 28 Jul 2008 08:50:09 -0400 (EDT) References: <00a801c8f071$a30c6b90$6601a8c0@JoanPC> Message-Id: <396C6EF6-DFF0-49F9-A14C-CAA805EC5374@lucidvision.com> From: Thomas Nadeau To: "Romascanu, Dan (Dan)" In-Reply-To: X-Mailer: iPhone Mail (5A347) Mime-Version: 1.0 (iPhone Mail 5A347) Date: Mon, 28 Jul 2008 08:49:28 -0400 X-Virus-Scanned: by amavisd-new at lucidvision.com Cc: Agrahara S Kiran Koushik , "" , "MIB Doctors \(E-mail\)" Subject: Re: [mpls] [MIB-DOCTORS] MIB Doctor review ofdraft-ietf-mpls-fastreroute-mib-09.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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Sorry foe the mix up compiling. We are working on a revision to fix these now. Sent from my cracked/hacked/unlocked iPhone! On Jul 28, 2008, at 6:14 AM, "Romascanu, Dan (Dan)" wrote: > Joan, > > Thank you for the review. > > Dan > > >> -----Original Message----- >> From: mib-doctors-bounces@ietf.org >> [mailto:mib-doctors-bounces@ietf.org] On Behalf Of Joan Cucchiara >> Sent: Monday, July 28, 2008 8:20 AM >> To: Thomas D. Nadeau; Agrahara S Kiran Koushik >> Cc: Swallow George; mpls@ietf.org; MIB Doctors (E-mail); Loa >> Andersson >> Subject: [MIB-DOCTORS] MIB Doctor review >> ofdraft-ietf-mpls-fastreroute-mib-09.txt >> >> >> Tom, et al., >> >> >> A great deal of work went into this latest draft. Thanks for that! >> >> The MIB compiler output is given, followed by Overall >> Comments and then specific comments. >> >> Thanks, >> Joan >> >> --- >> >> >> SMICNGPRO MIB Compiler Output >> ============================= >> MPLS-FRR-GENERAL-STD-MIB >> W: f(MPLS-FRR-GENERAL-STD-MIB), (5,8) "Integer32" imported >> but not used >> W: f(MPLS-FRR-GENERAL-STD-MIB), (6,8) "NOTIFICATION-TYPE" >> imported but not used >> W: f(MPLS-FRR-GENERAL-STD-MIB), (9,8) "NOTIFICATION-GROUP" >> imported but not used >> W: f(MPLS-FRR-GENERAL-STD-MIB), (11,8) "TruthValue" imported >> but not used >> W: f(MPLS-FRR-GENERAL-STD-MIB), (13,8) "InterfaceIndex" >> imported but not used >> >> >> MPLS-FRR-ONE2ONE-STD-MIB >> >> E: f(MPLS-FRR-ONE2ONE-STD-MIB), (74,35) Leading sub-Id >> "mplsOne2OneFrrMIB" >> is not known in current module >> E: f(MPLS-FRR-ONE2ONE-STD-MIB), (398,30) Item >> "mplsFrrScalarGroup" should be IMPORTed >> E: f(MPLS-FRR-ONE2ONE-STD-MIB), (399,30) Item >> "mplsFrrTunnelARHopGroup" >> should be IMPORTed >> E: f(MPLS-FRR-ONE2ONE-STD-MIB), (400,30) Item >> "mplsFrrConstraintsGroup" >> should be IMPORTed >> W: f(MPLS-FRR-ONE2ONE-STD-MIB), (5,19) "Unsigned32" imported >> but not used >> W: f(MPLS-FRR-ONE2ONE-STD-MIB), (6,8) "NOTIFICATION-TYPE" >> imported but not used >> W: f(MPLS-FRR-ONE2ONE-STD-MIB), (6,27) "Gauge32" imported but not >> used >> W: f(MPLS-FRR-ONE2ONE-STD-MIB), (9,8) "NOTIFICATION-GROUP" >> imported but not used >> W: f(MPLS-FRR-ONE2ONE-STD-MIB), (11,20) "RowStatus" imported >> but not used >> W: f(MPLS-FRR-ONE2ONE-STD-MIB), (11,31) "StorageType" >> imported but not used >> W: f(MPLS-FRR-ONE2ONE-STD-MIB), (13,8) "InterfaceIndex" >> imported but not used >> W: f(MPLS-FRR-ONE2ONE-STD-MIB), (13,24) >> "InterfaceIndexOrZero" imported but not used >> W: f(MPLS-FRR-ONE2ONE-STD-MIB), (14,8) >> "ifGeneralInformationGroup" imported but not used >> W: f(MPLS-FRR-ONE2ONE-STD-MIB), (15,8) "ifCounterDiscontinuityGroup" >> imported but not used >> W: f(MPLS-FRR-ONE2ONE-STD-MIB), (21,8) "mplsTunnelGroup" >> imported but not used >> W: f(MPLS-FRR-ONE2ONE-STD-MIB), (21,25) >> "mplsTunnelScalarGroup" imported but not used >> W: f(MPLS-FRR-ONE2ONE-STD-MIB), (22,8) >> "mplsTunnelARHopListIndex" imported but not used >> W: f(MPLS-FRR-ONE2ONE-STD-MIB), (22,34) >> "mplsTunnelARHopIndex" imported but not used >> >> >> >> MPLS-FRR-FACILITY-STD-MIB >> E: f(MPLS-FRR-FACILITY-STD-MIB), (497,30) Item >> "mplsFrrScalarGroup" should be IMPORTed >> E: f(MPLS-FRR-FACILITY-STD-MIB), (498,30) Item >> "mplsFrrTunnelARHopGroup" >> should be IMPORTed >> E: f(MPLS-FRR-FACILITY-STD-MIB), (499,30) Item >> "mplsFrrConstraintsGroup" >> should be IMPORTed >> W: f(MPLS-FRR-FACILITY-STD-MIB), (11,20) "RowStatus" imported >> but not used >> W: f(MPLS-FRR-FACILITY-STD-MIB), (11,31) "StorageType" >> imported but not used >> W: f(MPLS-FRR-FACILITY-STD-MIB), (13,24) >> "InterfaceIndexOrZero" imported but not used >> W: f(MPLS-FRR-FACILITY-STD-MIB), (14,8) >> "ifGeneralInformationGroup" imported but not used >> W: f(MPLS-FRR-FACILITY-STD-MIB), (15,8) "ifCounterDiscontinuityGroup" >> imported but not used >> W: f(MPLS-FRR-FACILITY-STD-MIB), (22,8) "MplsTunnelAffinity" >> imported but not used >> W: f(MPLS-FRR-FACILITY-STD-MIB), (24,8) "mplsTunnelGroup" >> imported but not used >> W: f(MPLS-FRR-FACILITY-STD-MIB), (24,25) >> "mplsTunnelScalarGroup" imported but not used >> W: f(MPLS-FRR-FACILITY-STD-MIB), (25,8) >> "mplsTunnelARHopListIndex" imported but not used >> W: f(MPLS-FRR-FACILITY-STD-MIB), (25,34) >> "mplsTunnelARHopIndex" imported but not used >> W: f(MPLS-FRR-FACILITY-STD-MIB), (27,8) "InetAddressType" >> imported but not used >> W: f(MPLS-FRR-FACILITY-STD-MIB), (27,25) "InetAddress" >> imported but not used >> W: f(MPLS-FRR-FACILITY-STD-MIB), (526,5) OBJECT-GROUP >> "mplsFrrFacilityScalarGroup" >> is not used in a MODULE-COMPLIANCE in current module >> >> >> >> >> >> >> >> SMILINT >> >> Validation report >> >> >> File: MPLS-FRR-GENERAL-STD-MIB >> Severity level requested: 6 >> >> Line Severity Problem >> 5 5 warning: identifier `Integer32' imported from >> module`SNMPv2-SMI' is never used >> 6 5 warning: identifier `NOTIFICATION-TYPE' imported from >> module `SNMPv2-SMI' is never used >> 9 5 warning: identifier `NOTIFICATION-GROUP' imported from >> module `SNMPv2-CONF' is never used >> 11 5 warning: identifier `TruthValue' imported from module >> `SNMPv2-TC' is never used >> 13 5 warning: identifier `InterfaceIndex' imported from >> module `IF-MIB' is never used >> >> --- >> >> File: MPLS-FRR-FACILITY-STD-MIB >> Severity level requested: 6 >> >> Line Severity Problem >> 11 5 warning: identifier `RowStatus' imported from module >> `SNMPv2-TC' is never used >> 11 5 warning: identifier `StorageType' imported from module >> `SNMPv2-TC' is never used >> 13 5 warning: identifier `InterfaceIndexOrZero' imported from >> module `IF-MIB' is never used >> 14 5 warning: identifier `ifGeneralInformationGroup' imported >> from module `IF-MIB' is never used >> 15 5 warning: identifier `ifCounterDiscontinuityGroup' >> imported from module `IF-MIB' is never used >> 22 5 warning: identifier `MplsTunnelAffinity' imported from >> module `MPLS-TC-STD-MIB' is never used >> 24 5 warning: identifier `mplsTunnelGroup' imported from >> module `MPLS-TE-STD-MIB' is never used >> 24 5 warning: identifier `mplsTunnelScalarGroup' imported >> from module `MPLS-TE-STD-MIB' is never used >> 25 5 warning: identifier `mplsTunnelARHopListIndex' imported >> from module `MPLS-TE-STD-MIB' is never used >> 25 5 warning: identifier `mplsTunnelARHopIndex' imported from >> module `MPLS-TE-STD-MIB' is never used >> 27 5 warning: identifier `InetAddressType' imported from >> module `INET-ADDRESS-MIB' is never used >> 27 5 warning: identifier `InetAddress' imported from module >> `INET-ADDRESS-MIB' is never used >> 526 5 warning: current group `mplsFrrFacilityScalarGroup' is >> not referenced in this module >> >> -- >> >> File: MPLS-FRR-ONE2ONE-STD-MIB >> Severity level requested: 6 >> >> Line Severity Problem >> 74 1 unknown object identifier label 'mplsOne2OneFrrMIB' >> >> >> Overall COMMENTs >> --------------- >> >> >> *) One general comment is that the key words from section 1.1 >> (MUST/MUST NOT/SHOULD, etc.) should be utilized. I've made >> some suggestions in a few places (see below in The "Specific >> Comments" >> area wrt 4.1, 4.1.1, 4.2.1, 4.2) but I did NOT make >> suggestions for every section, so please review the other >> sections. Basically, you need to give a clear understanding >> of which MIB Modules need to be deployed. >> >> >> *) The first 3 or 4 comments on the MPLS-FRR-GENERAL-STD-MIB >> also apply to the other 2 MIB Modules but these were not >> repeated. Please update all 3 MIB Modules. >> >> >> >> >> COMMENTS ON DOC (as they appear in the doc) >> --------------------------------------------- >> >> *) TOC >> >> Section 4., 4.1, 4.2, 4.3, 4.4 and 4.5 >> and possibly others are incorrect in the TOC. >> >> 4.1.1, 4.1.2, 4.2.1, 4.2.2, 4.3.1, >> (maybe others) are missing from the TOC. >> >> Please regenerate the TOC. >> >> >> *) 4. Overview of MIB Module >> >> s/Module/Modules >> >> Please update the TOC for this new title. >> >> >> >> *) 4.1. MPLS-FRR-GENERAL-STD-MIB >> >> Some verbage needs to be added to >> specify if/when this MIB Module MUST/SHOULD be implemented. >> >> e.g. (this is just an example) >> This MIB Module MUST be implemented if either fast reroute >> method is supported. >> >> >> >> *) 4.1.1 mplsFrrConstraintsTable >> >> (Similar comment to above...need to specify using MUST/SHOULD >> language if possible) >> >> So, the last paragraph in this section: >> >> This table is used at the ingress node of the protected TE >> tunnel instance to configure backup LSP setup constraints. >> >> should be updated (as an example) >> This table MUST (or SHOULD) be implemented at the >> ingress node of the protected TE >> tunnel instance to configure backup LSP setup contraints. >> >> >> >> *) 4.2.1 mplsFrrTunnelARHopTable >> >> First sentence need a comma, after "availability", >> >> Last paragraph (similar comment as above, need to use >> language MUST/SHOULD) >> >> (as an example): >> This table MUST be supported when the Record Route Object >> (RRO) is supported >> by the implementation. >> >> >> >> *) 4.2 MPLS-FRR-ONE2ONE-STD-MIB >> >> * Please add something like: >> >> This MIB Module MUST be supported when the one-to-one >> backup method is >> used. >> >> >> *) 4.2.1 and 4.2.2 >> >> >> *) I'm a little unclear as to the relationship between these tables >> (PLR, Detour and the mplsTunnelTable). >> >> For every protected LSP these could be N-1 detours, and each detour >> is >> a tunnel and thus, there is an entry in the mplsTunnelTable. >> >> Could you explain how one entry in the PLR table (which represents >> the >> protected LSP) could be related to >> more than one entry in the Detour table and further, how can I lookup >> the Detour in the mplsTunnelTable? >> >> Please give a concrete example using actual values for the indices >> (similar to what was done in rfc3812 section 9). It would be good >> if you could do this with one protected LSP and more than one detour. >> >> >> >> *) 4.3 >> >> >> *) 4.3.1 mplsFrrFacilityDBTable >> >> >> *) 5. Handling IPv6 Tunnels >> >> >> *) Please update the names of the objects to match the current >> names in the MIB Modules. >> >> >> >> *) 6 MPLS-FRR-GENERAL-STD-MIB >> >> >> *) LAST-UPDATED and REVISION >> >> s/May/June >> >> >> >> *) Please remove the REVISION/DESCRIPTION clauses >> except for the latest version of the MIB. The REVISION >> clause is typically used for RFC revisions (not draft >> revisions). >> >> *) DESCRIPTION: >> ...This MIB module is part of RFC 4327; >> see the RFC itself for full legal notices. >> >> needs to be changed to something like >> >> This version of this MIB module is part of RFC xxxx; >> See the RFC itself for full legal notices. >> >> -- RFC EDITOR: please replace xxxx with actual number >> -- and remove this note. >> >> >> >> *) Please see RFC4181 Appendices C and D. >> >> prefixes need to be consistent, so either use >> "mplsFrrGeneral" or "mplsFrr" >> >> Also, the OID layout is not as suggested in rfc418 (and also >> breaks with >> the other MPLS which does follow the suggested OID layout.) >> >> xxxMIB >> | >> +-- xxxNotifications(0) >> +-- xxxObjects(1) >> +-- xxxConformance(2) >> | >> +-- xxxCompliances(1) >> +-- xxxGroups(2) >> >> Currently, >> >> mplsFrrNotifications ::= { mplsFrrGeneralMIB 0 } <-- there >> aren't any >> notifications >> so >> don't need to >> define this >> >> mplsFrrObjects ::= { mplsFrrGeneralMIB 1} >> mplsFrrGeneralObjects ::= { mplsFrrObjects 1} >> mplsFrrConformance ::= { mplsFrrObjects 2} >> >> >> >> >> *) mplsFrrProtectionMethod Scalar >> >> Please add to the DESCRIPTION the error that would be returned if >> unknown(1) were to be set (would think inconsistentValue error?) >> >> For example: >> >> The value of unknown(1) is read-only and cannot be set. If the >> value of unknown(1) is set an inconsistentValue error MUST be >> returned. >> >> >> >> >> >> *) NEW for mplsFrrProtectedMethod >> Please include in the DESCRIPTION clause what >> error should be returned if the value of unknown(1) is >> set. >> >> >> *) mplsFrrSwitchover >> Should this be a Gauge32? >> >> DESCRIPTION is awkward. >> >> Seems like you are trying to say the following: >> >> The number of tunnel instances for either detour LSPs or >> bypass tunnels >> for which this LSR is the ingress. >> >> >> >> >> *) mplsFrrConstraintsTable >> >> >> *) mplsFrrConstraintsEntry >> >> s/however, in these cases,/however,/ >> >> >> *) mplsFrrConstraintsTunnelIndex >> >> s/for which/which/ >> >> >> Don't understand the last part of the last sentence >> "as must exist in the mplsTunnelTable". What is it that >> must exist in the mplsTunnelTable? >> >> >> *) mplsFrrConstraintsProtectionType >> >> Could a reference be added for this? >> >> >> *) mplsFrrConstraintsSetupPrio >> >> Could a more specific section be given >> to the REFERENCE? The reason is that there >> is also a SetupPriority in RFC4090 and >> this draft discusses supporting rfc4090 >> >> >> >> *) mplsFrrConstraintsHoldingPrio >> >> Same request as above, for a more specific section >> in the REFERENCE? >> >> >> >> >> >> *) NEW mplsFrrConstraintHopLimit >> According to RFC4090 this looks to be a byte, so >> why is there not a range on this? >> >> Same question wrt Reference >> is this 4090 section 4.1 ? >> >> >> >> *) mplsFrrTunnelARHopProtectType >> >> Where is path(0) described in rfc4090? >> >> Would it be possible to rename link to bandwidth to >> use the same terms as in 4090? >> >> >> *) NIT: mplsFrrConstraintsGroup not in the order >> they appear in the table. This is a NIT. >> >> >> 6.1 MPLS-FRR-ONE2ONE-STD-MIB >> >> Scalars need to be updated to reflect that they >> are relevant to one-to-one reroute method. >> >> >> >> >> *) mplsFrrOne2OneDetourMergedDetourInst >> >> Please spell out Instance (to be consistent) >> >> >> 6.3 MPLS-FRR-FACILITY-STD-MIB >> >> >> Scalars need to be updated to be relevant only >> to the FRR Facility method. >> >> Think that these scalars should be Gauge32, since >> the number of interfaces will be changing. >> >> >> *) mplsFrrActiveProtectedLSPs (should this be in >> the MPLS-FRR-ONE2ONE-STD-MIB? >> >> >> >> *) mplsFrrFacilityNotificationsEnabled. >> Why is this object needed? >> >> Please answer the question wrt RFC3413. >> >> >> >> *) mplsFrrFacilityNotificationsMaxRate >> Are there other objects which indicate >> if events are being thrown away due to this >> throttling? (Would that be useful?) >> >> NOT DONE. Please answer the question. I would >> think such an object (or objects) would be useful >> information if throttling is done. >> >> >> >> >> *) mplsFrrFacilityDBTable >> >> s/mplsFrrFacilityProtIfIdx/mplsFrrFacilityProtectedIfIndex/ >> >> >> *) mplsFrrFacilityDBNumProtectingTunnelOnIf >> s/speficied/specified/ >> >> >> *) mplsFrrFacilityFinalTunnelRestored >> >> Need to remove the verbage about if this is the Facility method >> at the end of the DESCRIPTION. >> >> >> >> *) 7. Security Considerations >> >> s/in this MIB module./in these MIB modules. >> >> >> *) 8 IANA Considerations >> >> Need section 8.2 and 8.3 for the other 2 MIB Modules. >> >> >> >> *) 10.1 Normative References >> >> >> [RFC4090] Pan, P., Swallow, G., Atlas, A., "Fast Reroute >> Extensions to RSVP-TE for LSP Tunnels", RFC4090, >> May 2005. >> >> and A. Atlas, >> >> >> >> -- end-- >> >> _______________________________________________ >> MIB-DOCTORS mailing list >> MIB-DOCTORS@ietf.org >> https://www.ietf.org/mailman/listinfo/mib-doctors >> > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Mon Jul 28 08:26:07 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD4A428C197; Mon, 28 Jul 2008 08:26:07 -0700 (PDT) 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 7F23C28C183 for ; Mon, 28 Jul 2008 08:26: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=[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 dTbtT6+g4xVt for ; Mon, 28 Jul 2008 08:26:05 -0700 (PDT) Received: from neo.viciousnest.net (neo.viciousnest.net [192.71.80.124]) by core3.amsl.com (Postfix) with ESMTP id A7D8228C181 for ; Mon, 28 Jul 2008 08:26:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by neo.viciousnest.net (Postfix) with ESMTP id 978E33F32E for ; Mon, 28 Jul 2008 17:26:12 +0200 (CEST) Received: from neo.viciousnest.net ([127.0.0.1]) by localhost (neo [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02271-08 for ; Mon, 28 Jul 2008 17:26:10 +0200 (CEST) Received: from [127.0.0.1] (unknown [130.129.23.82]) by neo.viciousnest.net (Postfix) with ESMTP id 6A12E3F32A for ; Mon, 28 Jul 2008 17:26:10 +0200 (CEST) Message-ID: <488DE50E.9030501@pi.nu> Date: Mon, 28 Jul 2008 17:26:06 +0200 From: Loa Andersson User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: mpls@ietf.org X-Virus-Scanned: by amavisd-new at viciousnest.net Subject: [mpls] slides from todays meeting 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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org All, the slides from todays meeting will be found at: https://datatracker.ietf.org/meeting/72/materials.html /Loa -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.nu _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Tue Jul 29 03:41:47 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCCC93A6B5B; Tue, 29 Jul 2008 03:41:47 -0700 (PDT) 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 98A323A6B5B for ; Tue, 29 Jul 2008 03:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.602 X-Spam-Level: X-Spam-Status: No, score=-4.602 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, MIME_QP_LONG_LINE=1.396, 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 VMs-rq2V-0-a for ; Tue, 29 Jul 2008 03:41:45 -0700 (PDT) Received: from mail148.messagelabs.com (mail148.messagelabs.com [85.158.137.131]) by core3.amsl.com (Postfix) with SMTP id C982E3A6B5A for ; Tue, 29 Jul 2008 03:41:44 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Jonathan.Newton@cw.com X-Msg-Ref: server-3.tower-148.messagelabs.com!1217328104!10716601!9 X-StarScan-Version: 5.5.12.14.2; banners=cw.com,-,- X-Originating-IP: [213.216.141.96] Received: (qmail 6665 invoked from network); 29 Jul 2008 10:41:54 -0000 Received: from unknown (HELO GBCWSWIEC001.ad.plc.cwintra.com) (213.216.141.96) by server-3.tower-148.messagelabs.com with SMTP; 29 Jul 2008 10:41:54 -0000 Received: from gbcwswiem006.ad.plc.cwintra.com ([148.185.93.213]) by GBCWSWIEC001.ad.plc.cwintra.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 29 Jul 2008 11:41:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 29 Jul 2008 11:41:02 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-newton-mpls-te-dynamic-overbooking-00.txt Thread-Index: AcjxZ5iN4MdRWkRfQjyvNiJsNfD/LQ== From: "Newton, Jonathan" To: X-OriginalArrivalTime: 29 Jul 2008 10:41:49.0088 (UTC) FILETIME=[B46AC200:01C8F167] Subject: [mpls] draft-newton-mpls-te-dynamic-overbooking-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0286637667==" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org This is a multi-part message in MIME format. --===============0286637667== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8F167.A625990A" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8F167.A625990A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi=20all, We=20have=20a=20draft=20that=20defines=20an=20implementation=20model=20tha= t=20allows=20a Traffic=20Engineered=20network=20to=20dynamically=20alter=20link=20booking= =20factors during=20failure=20events.=20=20The=20rationale=20is=20to=20allow=20an=20o= perator=20to=20adopt different=20optimisation=20schemes=20depending=20upon=20the=20current=20fa= ilure=20state of=20the=20network. http://www.ietf.org/internet-drafts/draft-newton-mpls-te-dynamic-overboo king-00.txt This=20was=20presented=20on=20Monday=20and=20we=20received=20some=20good=20= feedback=20during the=20session,=20but=20would=20appreciate=20further=20comment=20from=20the= =20list. The=20intention=20is=20to=20ask=20for=20adoption=20as=20a=20WG=20document.= =20The=20status=20was going=20to=20be=20BCP,=20but=20the=20chairs=20have=20recommended=20that=20= it=20is=20more appropriate=20to=20Informational=20status.=20 Cheers, ~Jon. This=20e-mail=20has=20been=20scanned=20for=20viruses=20by=20the=20Cable=20= &=20Wireless=20e-mail=20security=20system=20-=20powered=20by=20MessageLabs= .=20For=20more=20information=20on=20a=20proactive=20managed=20e-mail=20sec= urity=20service,=20visit=20http://www.cw.com/uk/emailprotection/=20 The=20information=20contained=20in=20this=20e-mail=20is=20confidential=20a= nd=20may=20also=20be=20subject=20to=20legal=20privilege.=20It=20is=20inten= ded=20only=20for=20the=20recipient(s)=20named=20above.=20If=20you=20are=20= not=20named=20above=20as=20a=20recipient,=20you=20must=20not=20read,=20cop= y,=20disclose,=20forward=20or=20otherwise=20use=20the=20information=20cont= ained=20in=20this=20email.=20If=20you=20have=20received=20this=20e-mail=20= in=20error,=20please=20notify=20the=20sender=20(whose=20contact=20details=20= are=20above)=20immediately=20by=20reply=20e-mail=20and=20delete=20the=20me= ssage=20and=20any=20attachments=20without=20retaining=20any=20copies. =20 Cable=20and=20Wireless=20plc=20 Registered=20in=20England=20and=20Wales.Company=20Number=20238525=20 Registered=20office:=203rd=20Floor,=2026=20Red=20Lion=20Square,=20London=20= WC1R=204HQ ------_=_NextPart_001_01C8F167.A625990A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-newton-mpls-te-dynamic-overbooking-00.txt

Hi=20all,

We=20have=20a=20draft=20that=20define= s=20an=20implementation=20model=20that=20allows=20a=20Traffic=20Engineered= =20network=20to=20dynamically=20alter=20link=20booking=20factors=20during=20= failure=20events. =20The=20rationale=20is=20to=20allow=20an=20operato= r=20to=20adopt=20different=20optimisation=20schemes=20depending=20upon=20t= he=20current=20failure=20state=20of=20the=20network.

http://www.ietf.org/internet-drafts/draft-newton-mpls-te-dynamic-o= verbooking-00.txt

This=20was=20presented=20on=20Monday=20= and=20we=20received=20some=20good=20feedback=20during=20the=20session,=20b= ut=20would=20appreciate=20further=20comment=20from=20the=20list.

The=20intention=20is=20to=20ask=20for= =20adoption=20as=20a=20WG=20document.=20The=20status=20was=20going=20to=20= be=20BCP,=20but=20the=20chairs=20have=20recommended=20that=20it=20is=20mor= e=20appropriate=20to=20Informational=20status.=20

Cheers,
~Jon.


This=20e-mail=20has=20been=20scanned=20for=20viruses=20by=20the=20Cable=20= &=20Wireless=20e-mail=20security=20system=20-=20powered=20by=20MessageLabs= .=20For=20more=20information=20on=20a=20proactive=20managed=20e-mail=20sec= urity=20service,=20visit=20http://www.cw.com/uk/emailprotection/=20

The=20information=20contained=20in=20this=20e-mail=20is=20confidential=20a= nd=20may=20also=20be=20subject=20to=20legal=20privilege.=20It=20is=20inten= ded=20only=20for=20the=20recipient(s)=20named=20above.=20If=20you=20are=20= not=20named=20above=20as=20a=20recipient,=20you=20must=20not=20read,=20cop= y,=20disclose,=20forward=20or=20otherwise=20use=20the=20information=20cont= ained=20in=20this=20email.=20If=20you=20have=20received=20this=20e-mail=20= in=20error,=20please=20notify=20the=20sender=20(whose=20contact=20details=20= are=20above)=20immediately=20by=20reply=20e-mail=20and=20delete=20the=20me= ssage=20and=20any=20attachments=20without=20retaining=20any=20copies.
=20
Cable=20and=20Wireless=20plc=20
Registered=20in=20England=20and=20Wales.Company=20Number=20238525=20
Registered=20office:=203rd=20Floor,=2026=20Red=20Lion=20Square,=20London=20= WC1R=204HQ
------_=_NextPart_001_01C8F167.A625990A-- --===============0286637667== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --===============0286637667==-- From mpls-bounces@ietf.org Tue Jul 29 05:45:52 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4609C3A6B08; Tue, 29 Jul 2008 05:45:52 -0700 (PDT) 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 937153A6937 for ; Tue, 29 Jul 2008 05:45:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.44 X-Spam-Level: X-Spam-Status: No, score=-1.44 tagged_above=-999 required=5 tests=[AWL=0.558, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 RfEF1xuIGkYl for ; Tue, 29 Jul 2008 05:45:44 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 6981B3A67B6 for ; Tue, 29 Jul 2008 05:45:35 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.8) with ESMTP id m6TCjjfP027125; Tue, 29 Jul 2008 13:45:45 +0100 Received: from your029b8cecfe ([130.129.22.145]) (authenticated bits=0) by asmtp1.iomartmail.com (8.12.11.20060308/8.12.11) with ESMTP id m6TCjVd4026763; Tue, 29 Jul 2008 13:45:36 +0100 Message-ID: <00e401c8f178$fe5f5810$91168182@your029b8cecfe> From: "Adrian Farrel" To: "Newton, Jonathan" , References: Date: Tue, 29 Jul 2008 13:45:06 +0100 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 Subject: Re: [mpls] draft-newton-mpls-te-dynamic-overbooking-00.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: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Hi Jon, Comments from a quick skim of the draft. I think it would be helpful to synchronize section 3.1 with RFC3209 and the recent work in the MPLS and CCAMP WGs on: - draft-ietf-mpls-soft-preemption - draft-berger-mpls-gmpls-lsp-reroute - draft-ietf-mpls-3209-patherr - draft-ietf-ccamp-mpls-graceful-shutdown At the moment the section is hard to parse because of inconsistencies (for example, how does a head end receive a PathTear?). Although your immediate requirement is for MPLS-TE, I would prefer that your solution was applicable also to GMPLS. In this context, when you say that an LSP fault can be detected through control plane failure, I am quite worried that you are limiting your applicability to a specific subset of MPLS-TE and entirely ruling out GMPLS. In section 3.3 you need to clarify setup and holding priorities. Section 4.2.1 says that "all LSPs will be torn down." This seems to be in conflict with the subsequent discussion of FRR. The section also says that a PathErr will be used to report the use of FRR to the head end - please note that this behavior is a SHOULD in RFC4090 and that delivery of PathErr is not guaranteed. Your procedure needs to consider the time for IGP convergence. At the moment, you say that the error may be notified by the IGP, in which case the new path computation (please don't call it CSPF :-) will know about the failed link. But in the case of fault propagation through RSVP-TE simply invoking path computation will not be enough unless the IGP has already converged (unlikely). So you need to be able to invoke path computation either later or with an explicit exclusion. Now, from where do you get the information about which link failed? RFC2205 defines the Error-Spec as containing "The IP address of the node in which the error was detected." which does not necessarily tell you the interface that has failed (although implementations *could* use the interface address of the failed interface at the reporting node). I suspect that to properly perform exclusions (there may be node failures or link failures) you should look at the IF_ID Error-Spec object defined in RFC3473. You might also look at the work for error reporting in RFC4920. Some work needed, I think, before it is appropriate to bring this to WG status. Cheers, Adrian ----- Original Message ----- From: "Newton, Jonathan" To: Sent: Tuesday, July 29, 2008 11:41 AM Subject: [mpls] draft-newton-mpls-te-dynamic-overbooking-00.txt Hi all, We have a draft that defines an implementation model that allows a Traffic Engineered network to dynamically alter link booking factors during failure events. The rationale is to allow an operator to adopt different optimisation schemes depending upon the current failure state of the network. http://www.ietf.org/internet-drafts/draft-newton-mpls-te-dynamic-overboo king-00.txt This was presented on Monday and we received some good feedback during the session, but would appreciate further comment from the list. The intention is to ask for adoption as a WG document. The status was going to be BCP, but the chairs have recommended that it is more appropriate to Informational status. Cheers, ~Jon. This e-mail has been scanned for viruses by the Cable & Wireless e-mail security system - powered by MessageLabs. For more information on a proactive managed e-mail security service, visit http://www.cw.com/uk/emailprotection/ The information contained in this e-mail is confidential and may also be subject to legal privilege. It is intended only for the recipient(s) named above. If you are not named above as a recipient, you must not read, copy, disclose, forward or otherwise use the information contained in this email. If you have received this e-mail in error, please notify the sender (whose contact details are above) immediately by reply e-mail and delete the message and any attachments without retaining any copies. Cable and Wireless plc Registered in England and Wales.Company Number 238525 Registered office: 3rd Floor, 26 Red Lion Square, London WC1R 4HQ -------------------------------------------------------------------------------- > _______________________________________________ > 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 mpls-bounces@ietf.org Tue Jul 29 07:41:39 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A1EE28C321; Tue, 29 Jul 2008 07:41:39 -0700 (PDT) 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 6AE823A68CD; Tue, 22 Jul 2008 09:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aR3aoSg7zgc1; Tue, 22 Jul 2008 09:33:10 -0700 (PDT) Received: from smtp3.smtp.bt.com (smtp3.smtp.bt.com [217.32.164.138]) by core3.amsl.com (Postfix) with ESMTP id 35A453A68BE; Tue, 22 Jul 2008 09:33:10 -0700 (PDT) Received: from E03MVZ4-UKDY.domain1.systemhost.net ([193.113.30.64]) by smtp3.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 Jul 2008 17:33:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Jul 2008 17:33:57 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Tsvwg] [mpls] multiple-working group last call on draft-ietf-mpls-cosfield-def-04.txt Thread-Index: AcjrRIC5+eyB+rhTFUGGUR5GYPN9AAA0+3zg From: To: , , X-OriginalArrivalTime: 22 Jul 2008 16:33:50.0188 (UTC) FILETIME=[B8AE9AC0:01C8EC18] X-Mailman-Approved-At: Tue, 29 Jul 2008 07:41:38 -0700 Cc: l2vpn@ietf.org, mpls@ietf.org, tsvwg@ietf.org, ccamp@ops.ietf.org, pwe3@ietf.org, ahtmpls@itu.int Subject: Re: [mpls] [Tsvwg] multiple-working group last call on draft-ietf-mpls-cosfield-def-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org I tend to agree with Ben - in effect whatever we end up calling it there should be a clear explanation of what we think it actually means. If you are still open to new suggestions how about "traffic information field" as strictly using it for ECN still isn't traffic management. Or even "traffic signalling field" Toby ____________________________________________________________________ Toby Moncaster, Networks Research Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 > -----Original Message----- > From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] > On Behalf Of Ben Niven-Jenkins > Sent: 21 July 2008 16:15 > To: John Kenney; Loa Andersson > Cc: L2VPN; mpls@ietf.org; tsvwg@ietf.org; ccamp; pwe3; ahtmpls@itu.int > Subject: Re: [Tsvwg] [mpls] multiple-working group last call > on draft-ietf-mpls-cosfield-def-04.txt > > I'm not precious about which term we use but if we use > Traffic Management I > think a paragraph should be added explaining what is meant to > put it in > context. > > Ben > > > > On 21/07/2008 15:07, "John Kenney" wrote: > > > Hi Loa, > > > > This is a good draft. It's time to rename the EXP field. While CoS > > Field may have been a good choice at one time, we've now > heard from many > > who think it is too narrow for current usage of this field. > > > > I suggest "Traffic Management Field". > > > > Traffic management is a common, generic, and concise term. > It covers > > all current uses of the field: scheduling class, drop priority, and > > congestion notification. CoS really only covers the first. Traffic > > management is well-scoped to this purpose, and clearly > preferable to CoS > > in my opinion. > > > > In terms of the draft, I think a simple global substitution > of "traffic > > management" for "class of service" and of "TM" for "CoS" > should suffice. > > > > I think in the long run we'll be glad if we bite the bullet > now and make > > this change. > > > > Best Regards, > > John > > > > > > Loa Andersson wrote: > >> > >> Bob, > >> > >> thanks for useful comments :) > >> > >> Bob Briscoe wrote: > >>> Loa, > >>> > >>> I believe this draft has no technical effect. However > there is some > >>> truth in the idea that names are important. > >>> > >>> So, let's set aside a few clock cycles to consider this... > >>> > >>> 1/ Is CoS a good description of ECN? Given RFC5129 (Using the EXP > >>> field for ECN in MPLS), is it really appropriate now to > call this a > >>> CoS field? > >>> > >>> Thinking out loud... > >>> - CoS is a signal from an ingress to the interior (a request for a > >>> certain class of service), > >>> - whereas ECN is a signal from the interior forwarding > plane to the > >>> egress (a response from the interior saying whether the class of > >>> service requested was congested). > >>> > >>> The way 5129 was done, two (or more) EXP codepoints can > be designated > >>> as the same CoS, but one can be used to say "this packet > experienced > >>> congestion when using this CoS", while the other says "it didn't". > >>> So, I guess I could live with this field being called CoS, even > >>> though it's not strictly correct. I can't think of > anything better. > >> > >> We had the same discussion when we started to discuss this > draft, we > >> wanted to find a name the covered both cases. We just couldn't come > >> with a better name, so we said "Let us call it 'CoS > Field'" and change > >> it someone comes up with something better. > >> > >> I'm still open to do that change, but time is kind of > running out, the > >> latest point in time we can do this change is an RFC > editor note, when > >> the IESG has approved the document. > > > > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Tue Jul 29 07:41:40 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 20B7728C333; Tue, 29 Jul 2008 07:41:40 -0700 (PDT) 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 220153A6918; Tue, 22 Jul 2008 09:47:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.917 X-Spam-Level: X-Spam-Status: No, score=-5.917 tagged_above=-999 required=5 tests=[AWL=0.682, 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 iCMhKYUTDUqS; Tue, 22 Jul 2008 09:46:59 -0700 (PDT) Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by core3.amsl.com (Postfix) with ESMTP id E8F613A6909; Tue, 22 Jul 2008 09:46:58 -0700 (PDT) Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [130.247.48.231]) by slb-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m6MGl8HV027644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 22 Jul 2008 09:47:09 -0700 (PDT) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m6MGl8lg001709; Tue, 22 Jul 2008 09:47:08 -0700 (PDT) Received: from xch-swbh-11.sw.nos.boeing.com (xch-swbh-11.sw.nos.boeing.com [129.172.192.157]) by blv-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m6MGl8Ce001680; Tue, 22 Jul 2008 09:47:08 -0700 (PDT) Received: from XCH-SW-5V2.sw.nos.boeing.com ([129.172.193.50]) by xch-swbh-11.sw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 22 Jul 2008 09:47:08 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 22 Jul 2008 09:47:06 -0700 Message-ID: <51661468CBD1354294533DA79E85955AEFDDE3@XCH-SW-5V2.sw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Tsvwg] [mpls] multiple-working group last call ondraft-ietf-mpls-cosfield-def-04.txt Thread-Index: AcjrRIC5+eyB+rhTFUGGUR5GYPN9AAA0+3zgAACBXDA= References: From: "Drake, John E" To: , , , X-OriginalArrivalTime: 22 Jul 2008 16:47:08.0150 (UTC) FILETIME=[944DF160:01C8EC1A] X-Mailman-Approved-At: Tue, 29 Jul 2008 07:41:38 -0700 Cc: l2vpn@ietf.org, mpls@ietf.org, tsvwg@ietf.org, ccamp@ops.ietf.org, pwe3@ietf.org, ahtmpls@itu.int Subject: Re: [mpls] [Tsvwg] multiple-working group last call ondraft-ietf-mpls-cosfield-def-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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org What about 'CoS'? >-----Original Message----- >From: toby.moncaster@bt.com [mailto:toby.moncaster@bt.com] >Sent: Tuesday, July 22, 2008 9:34 AM >To: benjamin.niven-jenkins@bt.com; johnkenney@alumni.nd.edu; loa@pi.nu >Cc: l2vpn@ietf.org; mpls@ietf.org; tsvwg@ietf.org; >ccamp@ops.ietf.org; pwe3@ietf.org; ahtmpls@itu.int >Subject: Re: [Tsvwg] [mpls] multiple-working group last call >ondraft-ietf-mpls-cosfield-def-04.txt > >I tend to agree with Ben - in effect whatever we end up >calling it there should be a clear explanation of what we >think it actually means. > >If you are still open to new suggestions how about "traffic >information field" as strictly using it for ECN still isn't >traffic management. Or even "traffic signalling field" > >Toby > >____________________________________________________________________ >Toby Moncaster, Networks Research >Centre, BT B54/70 Adastral Park, Ipswich, IP53RE, UK. +44 1473 648734 > > >> -----Original Message----- >> From: tsvwg-bounces@ietf.org [mailto:tsvwg-bounces@ietf.org] >On Behalf >> Of Ben Niven-Jenkins >> Sent: 21 July 2008 16:15 >> To: John Kenney; Loa Andersson >> Cc: L2VPN; mpls@ietf.org; tsvwg@ietf.org; ccamp; pwe3; >ahtmpls@itu.int >> Subject: Re: [Tsvwg] [mpls] multiple-working group last call on >> draft-ietf-mpls-cosfield-def-04.txt >> >> I'm not precious about which term we use but if we use Traffic >> Management I think a paragraph should be added explaining what is >> meant to put it in context. >> >> Ben >> >> >> >> On 21/07/2008 15:07, "John Kenney" wrote: >> >> > Hi Loa, >> > >> > This is a good draft. It's time to rename the EXP field. >While CoS >> > Field may have been a good choice at one time, we've now >> heard from many >> > who think it is too narrow for current usage of this field. >> > >> > I suggest "Traffic Management Field". >> > >> > Traffic management is a common, generic, and concise term. >> It covers >> > all current uses of the field: scheduling class, drop >priority, and >> > congestion notification. CoS really only covers the first. > Traffic >> > management is well-scoped to this purpose, and clearly >> preferable to CoS >> > in my opinion. >> > >> > In terms of the draft, I think a simple global substitution >> of "traffic >> > management" for "class of service" and of "TM" for "CoS" >> should suffice. >> > >> > I think in the long run we'll be glad if we bite the bullet >> now and make >> > this change. >> > >> > Best Regards, >> > John >> > >> > >> > Loa Andersson wrote: >> >> >> >> Bob, >> >> >> >> thanks for useful comments :) >> >> >> >> Bob Briscoe wrote: >> >>> Loa, >> >>> >> >>> I believe this draft has no technical effect. However >> there is some >> >>> truth in the idea that names are important. >> >>> >> >>> So, let's set aside a few clock cycles to consider this... >> >>> >> >>> 1/ Is CoS a good description of ECN? Given RFC5129 >(Using the EXP >> >>> field for ECN in MPLS), is it really appropriate now to >> call this a >> >>> CoS field? >> >>> >> >>> Thinking out loud... >> >>> - CoS is a signal from an ingress to the interior (a >request for a >> >>> certain class of service), >> >>> - whereas ECN is a signal from the interior forwarding >> plane to the >> >>> egress (a response from the interior saying whether the class of >> >>> service requested was congested). >> >>> >> >>> The way 5129 was done, two (or more) EXP codepoints can >> be designated >> >>> as the same CoS, but one can be used to say "this packet >> experienced >> >>> congestion when using this CoS", while the other says >"it didn't". >> >>> So, I guess I could live with this field being called CoS, even >> >>> though it's not strictly correct. I can't think of >> anything better. >> >> >> >> We had the same discussion when we started to discuss this >> draft, we >> >> wanted to find a name the covered both cases. We just >couldn't come >> >> with a better name, so we said "Let us call it 'CoS >> Field'" and change >> >> it someone comes up with something better. >> >> >> >> I'm still open to do that change, but time is kind of >> running out, the >> >> latest point in time we can do this change is an RFC >> editor note, when >> >> the IESG has approved the document. >> > >> >> > _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Tue Jul 29 07:42:16 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0C8D28C31D; Tue, 29 Jul 2008 07:42:16 -0700 (PDT) X-Original-To: mpls@lists.ietf.org Delivered-To: mpls@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 8E8693A6912; Thu, 24 Jul 2008 02:51:09 -0700 (PDT) From: Greg Jones(ITU-T SG 15) To: swallow@cisco.com,loa@pi.nu Mime-Version: 1.0 Message-Id: <20080724095109.8E8693A6912@core3.amsl.com> Date: Thu, 24 Jul 2008 02:51:09 -0700 (PDT) X-Mailman-Approved-At: Tue, 29 Jul 2008 07:42:15 -0700 Cc: mpls@lists.ietf.org, sob@harvard.edu, yoichi.maeda@ntt-at.co.jp, dward@cisco.com, rcallon@juniper.net, tsbsg15@itu.int, betts01@nortel.com, stbryant@cisco.com Subject: [mpls] New Liaison Statement, "Review of draft-ietf-mpls-cosfield-def-04" 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Title: Review of draft-ietf-mpls-cosfield-def-04 Submission Date: 2008-07-24 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=465 From: Greg Jones(ITU-T SG 15) To: IETF MPLS WG(swallow@cisco.com,loa@pi.nu) Cc: sob@harvard.edu rcallon@juniper.net stbryant@cisco.com dward@cisco.com mpls@lists.ietf.org yoichi.maeda@ntt-at.co.jp sjtrowbridge@alcatel-lucent.com betts01@nortel.com tsbsg15@itu.int Reponse Contact: tsbsg15@itu.int Technical Contact: betts01@nortel.com Purpose: For information Body: Thank you for bringing draft-ietf-mpls-cosfield-def-04.txt to our attention. This draft was reviewed by correspondence and we have no comments. We will take the clarification of the definition of the EXP/CoS bits into account as we align the work in ITU-T with the work on MPLS-TP in the IETF. Attachment(s): Full liaison statement in pdf format (https://datatracker.ietf.org/documents/LIAISON/file571.pdf) _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From mpls-bounces@ietf.org Wed Jul 30 08:47:25 2008 Return-Path: X-Original-To: mpls-archive@megatron.ietf.org Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 82C0F3A6C0C; Wed, 30 Jul 2008 08:47:25 -0700 (PDT) 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 6AB513A6BFD for ; Wed, 30 Jul 2008 08:47:22 -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 RV2a0sdGBxuc for ; Wed, 30 Jul 2008 08:47:21 -0700 (PDT) Received: from exprod7og103.obsmtp.com (exprod7og103.obsmtp.com [64.18.2.159]) by core3.amsl.com (Postfix) with ESMTP id 9C6513A6C0B for ; Wed, 30 Jul 2008 08:47:20 -0700 (PDT) Received: from source ([66.129.228.6]) by exprod7ob103.postini.com ([64.18.6.12]) with SMTP; Wed, 30 Jul 2008 08:47:35 PDT Received: from p-emlb01-sac.jnpr.net ([66.129.254.46]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 08:47:20 -0700 Received: from emailwf1.jnpr.net ([10.10.2.33]) by p-emlb01-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 30 Jul 2008 08:47:20 -0700 Received: from proton.jnpr.net ([10.10.2.37]) by emailwf1.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Wed, 30 Jul 2008 11:47:17 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 30 Jul 2008 11:47:15 -0400 Message-ID: <1E8ACF422ADD1A458AAFFAD2E6FF70C81A20EA55@proton.jnpr.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 4561 clarification Thread-Index: AcjyW4pk0woafd8CSfKBxC3sqbw5Tg== From: "Harish Sitaraman" To: X-OriginalArrivalTime: 30 Jul 2008 15:47:17.0596 (UTC) FILETIME=[8B78E1C0:01C8F25B] Subject: [mpls] RFC 4561 clarification 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: mpls-bounces@ietf.org Errors-To: mpls-bounces@ietf.org Hi, Regarding RFC 4561: Definition of RRO Node-Id Sub-Object RFC 4561 does not seem to clearly specify certain details regarding the allowed formats in the RRO and how such information in the RRO could be parsed by a PLR. Would it be possible for somebody to provide some clarifications for the following issues ? -- For the purpose of this discussion, we would like to use the following symbols: N = node-id (node-id sub-object) I = interface-address (IPv4 sub-object) L = label | = marker distinguishing information from adjacent nodes < > = Order of RRO information from a single node 1. Section 3 seems to allow various formats in the RRO when adding the node-id sub-object. Its not clear whether points (1) and (2) list the set of formats that are allowed or if these just serve as examples of certain formats. From interpretation, it seems like the following are allowed: Point (1) example: ; , , , Point (2) example: though the order of the objects is not specified. If , and are allowed, then these are not compliant with RFC 3209 since only interface addresses seem to be allowed in the IPv4 sub-object and the IPv4 sub-object is pushed after pushing the label. Section 4.4.1.1. Subobject 1: IPv4 address: IPv4 address A 32-bit unicast, host address. Any network-reachable interface address is allowed here. Illegal addresses, such as certain loopback addresses, SHOULD NOT be used. Section 4.4.3: The newly added subobject MUST be this router's IP address. The address to be added SHOULD be the interface address of the outgoing Path messages. If there are multiple addresses to choose from, the decision is a local matter. However, it is RECOMMENDED that the same address be chosen consistently. The Label Record subobject is pushed onto the RECORD_ROUTE object prior to pushing on the node's IP address. A node MUST NOT push on a Label Record subobject without also pushing on an IPv4 or IPv6 subobject. RFC 3209 provides clear guidelines regarding the order in which objects are pushed on the stack. Such stacking guidelines when pushing a node-id sub-object are required. Considering the above (and since RFC 4561 does not update RFC 3209), it seems like the following formats should not be allowed: , , , 2. Section 1 provides the techniques that are used by a PLR in selecting a bypass (backup) tunnel. It seems like the description assumes the existence of a traffic-engineering database and that the IGP-TE extensions are enabled in the network. There are network scenarios where IGP-TE extensions are not enabled, yet LSPs are established using the information provided by the IGP. This makes it difficult for a PLR to accurately parse the RRO to find the MP address depending on the RRO formats added by downstream routers. The addresses added by a node can be incorrectly parsed as belonging to the next node. Few examples to illustrate the issue of an upstream node trying to differentiate between the formats just by parsing the received RRO: | | and | | and | | and | | and | | and | | As seen above, its not possible to clearly find the information added by a single node since there isn't any delimiter (label ?) in the RRO. This also serves to illustrate that allowing formats that include the label in between the addresses makes it difficult to parse the RRO. Using the traffic-engineering database to validate the addresses in the above formats to find the set of addresses that belong to a single node doesn't work in the inter-area/AS case (especially for node-protection), assuming a TE database exists. Thanks, Harish _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From capture@pei.sympatico.ca Thu Jul 31 08:53:06 2008 Return-Path: X-Original-To: ietfarch-mpls-archive@core3.amsl.com Delivered-To: ietfarch-mpls-archive@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0094F3A6949 for ; Thu, 31 Jul 2008 08:53:06 -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 Z6PqbIBW376d for ; Thu, 31 Jul 2008 08:53:05 -0700 (PDT) Received: from tomts35-srv.bellnexxia.net (tomts35.bellnexxia.net [209.226.175.109]) by core3.amsl.com (Postfix) with ESMTP id E4C4228C166 for ; Thu, 31 Jul 2008 08:53:04 -0700 (PDT) Received: from toip38-bus.srvr.bell.ca ([67.69.240.39]) by tomts35-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20080731155250.SEXD1729.tomts35-srv.bellnexxia.net@toip38-bus.srvr.bell.ca>; Thu, 31 Jul 2008 11:52:50 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArcvALl3kUjR4q+H/2dsb2JhbACJeolbmUs Received: from tofep3.bellnexxia.net (HELO smtp.bellnexxia.net) ([209.226.175.135]) by toip38-bus.srvr.bell.ca with SMTP; 31 Jul 2008 11:52:20 -0400 X-Mailer: Openwave WebEngine, version 2.8.11 (webedge20-101-194-20030622) X-Originating-IP: [66.198.41.11] From: Mrs Sara Criswell Reply-To: andersonmoore@btinternet.com To: Subject: File For Claim Date: Thu, 31 Jul 2008 11:52:20 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Message-Id: <20080731155250.SEXD1729.tomts35-srv.bellnexxia.net@toip38-bus.srvr.bell.ca> POWER BALL LOTTERY BOARD Contact:Mr.Anderson Moore for the claim of =A31,000,000 pounds whichyou h= ave won in POWER BALL PROMO.Provide your Names Address Age Occupation Tel Country Email:andersonmoore@btinternet.com Sincerely, POWER BALL LOTTERY BOARD