From internet-drafts@ietf.org Wed May 1 00:11:23 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A3D21F8CDD; Wed, 1 May 2013 00:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tkkLtbTveLpr; Wed, 1 May 2013 00:11:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B31EE21F8C69; Wed, 1 May 2013 00:10:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130501071055.24904.71662.idtracker@ietfa.amsl.com> Date: Wed, 01 May 2013 00:10:55 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 07:11:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : "MPLS LSP Ping TLVs and sub-TLVs registry" Author(s) : Loa Andersson Mach(Guoyi) Chen Tom Petch Filename : draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-01.txt Pages : 17 Date : 2013-05-01 Abstract: This document addresses issues with the structure, allocation policies and clarity in the use of the "TLVs and sub-TLVs" of the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" in the "Multiprotocol Label Switching Architecture (MPLS)" name space. This document does not change any existing allocations and the new structure is backwards compatible with the existing registries. The policy for the allocation of TLVs is unchanged but future allocations of sub-TLVs will come from a single namespace, common to all TLVs of LSP Ping Parameters. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-= registry There's also a htmlized version available at: http://tools.ietf.org/html/draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-regist= ry-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-pac-mpls-lsp-ping-tlvs-and-sub-tlv= s-registry-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed May 1 00:45:16 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4458821F8E4C; Wed, 1 May 2013 00:45:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cJVT4PYmlPH; Wed, 1 May 2013 00:45:15 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5BB21F8B60; Wed, 1 May 2013 00:45:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130501074515.3547.25821.idtracker@ietfa.amsl.com> Date: Wed, 01 May 2013 00:45:15 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 07:45:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : "MPLS LSP Ping TLVs and sub-TLVs registry" Author(s) : Loa Andersson Mach(Guoyi) Chen Tom Petch Filename : draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02.txt Pages : 17 Date : 2013-05-01 Abstract: This document addresses issues with the structure, allocation policies and clarity in the use of the "TLVs and sub-TLVs" of the "Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" in the "Multiprotocol Label Switching Architecture (MPLS)" name space. This document does not change any existing allocations and the new structure is backwards compatible with the existing registries. The policy for the allocation of TLVs is unchanged but future allocations of sub-TLVs will come from a single namespace, common to all TLVs of LSP Ping Parameters. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-= registry There's also a htmlized version available at: http://tools.ietf.org/html/draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-regist= ry-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-pac-mpls-lsp-ping-tlvs-and-sub-tlv= s-registry-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Wed May 1 09:11:36 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4104321F93DE; Wed, 1 May 2013 09:11:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qIO6pSi+kvXh; Wed, 1 May 2013 09:11:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF94321F92FC; Wed, 1 May 2013 09:11:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130501161135.16357.62865.idtracker@ietfa.amsl.com> Date: Wed, 01 May 2013 09:11:35 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-use-cases-and-design-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 16:11:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : MPLS-TP Applicability; Use Cases and Design Author(s) : Luyuan Fang Nabil Bitar Raymond Zhang Masahiro Daikoku Ping Pan Filename : draft-ietf-mpls-tp-use-cases-and-design-08.txt Pages : 16 Date : 2013-05-01 Abstract: This document provides the applicability of Multiprotocol Label Switching Transport Profile (MPLS-TP) with use case studies and network design considerations. The use cases include Metro Ethernet access and aggregation transport, Mobile backhaul, and packet optical transport. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-use-cases-and-design There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-use-cases-and-design-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-use-cases-and-design-= 08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From eosborne@cisco.com Wed May 1 09:47:38 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D404921F9980 for ; Wed, 1 May 2013 09:47:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGkdORugH8Sb for ; Wed, 1 May 2013 09:47:34 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id F07D221F9992 for ; Wed, 1 May 2013 09:47:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2345; q=dns/txt; s=iport; t=1367426854; x=1368636454; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=u6iZBzvpps8T4mNAlGN14lvAIpfeHn+OMBdCjoML790=; b=GkBXmu3rKeSARqaybW6mV+bkfhyeEnFNwb0OQp3V0WXmS5irqu6BiRna 1RpLRxCm6/jMZDDmQKlI0H0ndJViHO/3OCliKLY/uOoHkNEckgvc8YM0c RqIiM8Shw04zwCoIjMCk7BtqVe3iaTWxk7tpqcm6DILtADqpBJ8MldA0E w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAKNGgVGtJV2Y/2dsb2JhbABSgwc3vxx8FnSCHwEBAQQBAQE3NBcEAgEIEQQBAQEKFAkHJwsUCQgBAQQBEgiIBAy/IQSOcTgGgmthA6hagw2BayQY X-IronPort-AV: E=Sophos;i="4.87,590,1363132800"; d="scan'208";a="202276579" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 01 May 2013 16:47:33 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r41GlXHs008675 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 1 May 2013 16:47:33 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.83]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Wed, 1 May 2013 11:47:33 -0500 From: "Eric Osborne (eosborne)" To: Yuji Tochio , "mpls@ietf.org" Thread-Topic: [mpls] PSC: draft-dj-mpls-tp-exer-psc Thread-Index: Ac47ZWRjRJBAvDu6T4ia+zSmFq3r6QJ+QPwAAEs9aQA= Date: Wed, 1 May 2013 16:47:32 +0000 Message-ID: <20ECF67871905846A80F77F8F4A275721015D2FF@xmb-rcd-x09.cisco.com> References: <20ECF67871905846A80F77F8F4A27572101502A9@xmb-rcd-x09.cisco.com> <517F078E.5030002@jp.fujitsu.com> In-Reply-To: <517F078E.5030002@jp.fujitsu.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.66.68] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] PSC: draft-dj-mpls-tp-exer-psc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 16:47:39 -0000 Hi Yuji- R84a says "84 It MUST be possible to test and validate any protection/ restoration mechanisms and protocols: A. Including the integrity of the protection/recovery transport path." To me, the 'transport path' is the set of links and nodes between the endpo= ints of a protection domain, and this function is best served by something = like CC/CV. Clearly we disagree here. Can you help me understand why EXER=20 a) meets the requirement in R84a AND b) is the best way to meet this requirement ? eric > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Yuji Tochio > Sent: Monday, April 29, 2013 7:52 PM > To: mpls@ietf.org > Subject: Re: [mpls] PSC: draft-dj-mpls-tp-exer-psc >=20 > Hi Eric O and all, >=20 > As to the first bullet to the question below, my opinion is YES. > The reason is it is align with #84 (84A) in RFC 5654. >=20 > Just my 2c, > Yuji >=20 > (2013/04/17 21:21), Eric Osborne (eosborne) wrote: > > This thread is for discussing draft-dj-mpls-tp-exer-psc. We started wi= th -00, > but there is now a -01. > > > > The draft proposes adding the EXER/RR commands found in some ITU linear > protection protocols to PSC. > > I have also posted an alternative approach, draft-osborne-mpls-psc-aliv= e-00. > > Briefly, EXER is a mechanism designed to check the responsiveness of th= e far- > end state machine. My proposal, ALIVE, is for a similar mechanism. It w= orks > differently and thus may be more or less acceptable. > > > > The big questions here are: > > > > - do we need any sort of EXER-type function at all? > > - if so, are either of the two proposals sufficient? Is there a better= way? > > - if not, is it possible to provide the same kind of testing and awaren= ess > through existing mechanisms? is this testing and awareness desirable or > necessary? > > > > but of course any and all discussion is welcome. > > > > > > > > > > > > eric > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From tochio@jp.fujitsu.com Wed May 1 16:32:44 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 068D421F9B73 for ; Wed, 1 May 2013 16:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.09 X-Spam-Level: X-Spam-Status: No, score=-104.09 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3PprcmcF8msv for ; Wed, 1 May 2013 16:32:39 -0700 (PDT) Received: from fgwmail5.fujitsu.co.jp (fgwmail5.fujitsu.co.jp [192.51.44.35]) by ietfa.amsl.com (Postfix) with ESMTP id 7B92421F9B75 for ; Wed, 1 May 2013 16:32:35 -0700 (PDT) Received: from m1.gw.fujitsu.co.jp (unknown [10.0.50.71]) by fgwmail5.fujitsu.co.jp (Postfix) with ESMTP id D33A53EE081; Thu, 2 May 2013 08:32:34 +0900 (JST) Received: from smail (m1 [127.0.0.1]) by outgoing.m1.gw.fujitsu.co.jp (Postfix) with ESMTP id C4D6245DE54; Thu, 2 May 2013 08:32:34 +0900 (JST) Received: from s1.gw.fujitsu.co.jp (s1.gw.fujitsu.co.jp [10.0.50.91]) by m1.gw.fujitsu.co.jp (Postfix) with ESMTP id A53CD45DE56; Thu, 2 May 2013 08:32:34 +0900 (JST) Received: from s1.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 996A41DB804D; Thu, 2 May 2013 08:32:34 +0900 (JST) Received: from flabmail.flab.fujitsu.co.jp (flabmail.flab.fujitsu.co.jp [10.25.192.37]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 4F7961DB804B; Thu, 2 May 2013 08:32:34 +0900 (JST) Received: from vskawa.flab.fujitsu.co.jp (vskawa.flab.fujitsu.co.jp [10.25.192.39]) by flabmail.flab.fujitsu.co.jp (8.14.4/8.14.4/110310-Fujitsu Labs. Domain Mail Master) with ESMTP id r41NWNaM013503; Thu, 2 May 2013 08:32:34 +0900 (JST) X-AuditID: 0a19c027-b7f866d00000132d-2e-5181a612d3ed Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp [10.25.192.105]) by vskawa.flab.fujitsu.co.jp (Symantec Messaging Gateway) with SMTP id B9.80.04909.216A1815; Thu, 2 May 2013 08:32:34 +0900 (JST) Received: from [127.0.0.1] (dhcp20.dream.flab.fujitsu.co.jp [10.25.144.235]) by dm.kawasaki.flab.fujitsu.co.jp (8.14.4/8.14.4/110311-Fujitsu Labs. Kawasaki Domain Mail Master) with ESMTP id r41NWQrM018877; Thu, 2 May 2013 08:32:34 +0900 (JST) X-SecurityPolicyCheck: OK by SHieldMailChecker v1.8.4 Message-ID: <5181A5EB.8080807@jp.fujitsu.com> Date: Thu, 02 May 2013 08:31:55 +0900 From: Yuji Tochio User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Eric Osborne (eosborne)" References: <20ECF67871905846A80F77F8F4A27572101502A9@xmb-rcd-x09.cisco.com> <517F078E.5030002@jp.fujitsu.com> <20ECF67871905846A80F77F8F4A275721015D2FF@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A275721015D2FF@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsXCJXkgU1doWWOgwfu1XBZNczYzWtxaupLV gcljyu+NrB5LlvxkCmCK4rJJSc3JLEst0rdL4MpYfWwVW8E+0YrHZ8oaGH8JdDFycEgImEic e2DdxcgJZIpJXLi3nq2LkYtDSOAxo8TNZQdYIZxvjBLHntxnhqgylZi47hkjiM0roCvxatIb MJtFQFXiwNpHbCA2m4CmxLWZd8DiogLBEj87pkLVC0qcnPmEBcQWETCS6N++nwnkCGYBZYlT d2VAwsJA4WlXNzJB7F3PKDFpYg/YXk4BX4krPS/A5jAD7b154iMThC0vsf3tHOYJjIKzkKyY haRsFpKyBYzMqxgly4qzE8sT9dJyEpP00kqzMkuKS/WS8/WyCjYxQoJWfQfjs0WahxgFOBiV eHhLDBsDhVgTy4orcw8xSnAwK4nw/pwGFOJNSaysSi3Kjy8qzUktPsTIxMEp1cCoJix0cuaE fWtCVHzmn1R9c7j3TJ3smddMUioKXw9+Crh2IuBgg7F6wf8uVaPdO8XW9N/jbKwr/2KkzRWs aVW99pXVhJTT3FtCj3ee+Tg74OMlffELjIHFSZFL1W+cjZjfk/rVLKslsq0pj8Ng3RnB6JW/ cos0PauvF3itnmG1bHeq/E+7e3uUWIozEg21mIuKEwFz7ilPOAIAAA== Cc: "mpls@ietf.org" Subject: Re: [mpls] PSC: draft-dj-mpls-tp-exer-psc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2013 23:32:44 -0000 Hi Eric I think we (Eric and me) have different opnions for item #3 in LS (...1234).. (2013/05/02 1:47), Eric Osborne (eosborne) wrote: > Hi Yuji- > > R84a says "84 It MUST be possible to test and validate any protection/ > restoration mechanisms and protocols: > > A. Including the integrity of the protection/recovery transport > path." > > > To me, the 'transport path' is the set of links and nodes between the endpoints of a protection domain, and this function is best served by something like CC/CV. Clearly we disagree here. So far, both without disturbing the transport path that includes the bahaviour of CC/CV and with validating the linear protection protocol, we have (need) EXR. # See 3.2.26 of G.870, please > > Can you help me understand why EXER > a) meets the requirement in R84a > AND > b) is the best way to meet this requirement > ? For b), Yes as in item#3 in the LS Regards, Yuji > > > > > eric > >> -----Original Message----- >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of >> Yuji Tochio >> Sent: Monday, April 29, 2013 7:52 PM >> To: mpls@ietf.org >> Subject: Re: [mpls] PSC: draft-dj-mpls-tp-exer-psc >> >> Hi Eric O and all, >> >> As to the first bullet to the question below, my opinion is YES. >> The reason is it is align with #84 (84A) in RFC 5654. >> >> Just my 2c, >> Yuji >> >> (2013/04/17 21:21), Eric Osborne (eosborne) wrote: >>> This thread is for discussing draft-dj-mpls-tp-exer-psc. We started with -00, >> but there is now a -01. >>> The draft proposes adding the EXER/RR commands found in some ITU linear >> protection protocols to PSC. >>> I have also posted an alternative approach, draft-osborne-mpls-psc-alive-00. >>> Briefly, EXER is a mechanism designed to check the responsiveness of the far- >> end state machine. My proposal, ALIVE, is for a similar mechanism. It works >> differently and thus may be more or less acceptable. >>> The big questions here are: >>> >>> - do we need any sort of EXER-type function at all? >>> - if so, are either of the two proposals sufficient? Is there a better way? >>> - if not, is it possible to provide the same kind of testing and awareness >> through existing mechanisms? is this testing and awareness desirable or >> necessary? >>> but of course any and all discussion is welcome. >>> >>> >>> >>> >>> >>> eric >>> _______________________________________________ >>> 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 iesg-secretary@ietf.org Thu May 2 06:51:29 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFBE21F89FD; Thu, 2 May 2013 06:51:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niHWjJ7Yjaxf; Thu, 2 May 2013 06:51:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 51C7421F89CF; Thu, 2 May 2013 06:51:28 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130502135128.11775.29584.idtracker@ietfa.amsl.com> Date: Thu, 02 May 2013 06:51:28 -0700 Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Document Action: 'MPLS-TP Applicability; Use Cases and Design' to Informational RFC (draft-ietf-mpls-tp-use-cases-and-design-08.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 13:51:29 -0000 The IESG has approved the following document: - 'MPLS-TP Applicability; Use Cases and Design' (draft-ietf-mpls-tp-use-cases-and-design-08.txt) as Informational RFC This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-use-cases-and-design/ Technical Summary This document provides applicability, use case studies and network design considerations for the Multiprotocol Label Switching Transport Profile (MPLS-TP). In the recent years, MPLS-TP has emerged as the technology of choice for the new generation of packet transport. Many service providers (SPs) are working to replace the legacy transport technologies, e.g. SONET/SDH, TDM, and ATM technologies, with MPLS-TP for packet transport, in order to achieve higher efficiency, lower operational cost, while maintaining transport characteristics. The use cases for MPLS-TP include Metro Ethernet access and aggregation, Mobile backhaul, and packet optical transport. The design considerations discussed in this document range from operational experience; standards compliance; technology maturity; end-to-end forwarding and OAM consistency; compatibility with IP/MPLS networks; multi-vendor interoperability; and optimization vs. simplicity design trade off discussion. The general design principle is to provide reliable, manageable, and scalable transport solutions. Working Group Summary This document has a strong support in the working group and has been well reviewed. The AD review resulted in significant restructuring of the document and revision of the text. The new document was taken back to the working group for discussion and a further last call. Document Quality This an informational document, it presents some use-cases and provides design guidelines, but it is not possible to say that there are implementations. The document has had the review that is needed, the working group last call was brought to the attention of SG15 in ITU-T. Personnel Loa Andersson is the document shepherd. Adrian Farrel is the responsible AD. From eosborne@cisco.com Thu May 2 07:30:51 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6C921F8A08 for ; Thu, 2 May 2013 07:30:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmzxKOOn8WdZ for ; Thu, 2 May 2013 07:30:47 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 0517321F8A0C for ; Thu, 2 May 2013 07:30:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5018; q=dns/txt; s=iport; t=1367505047; x=1368714647; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=841sHXf5Gs2YagI5mhuSyJykw4H/8ebZPzoB1ivZ4/g=; b=CW7ypx3Tn0H1HDyK2nhzOV9iaarueujn+01xZ22aDgwthr0TrZp8KDaf 1kWHkQp5PN38tSqgylaT1iPWnfLMh6+Szuxjodlb0HK0knOZL7r2HMzgB gHqmzzB243nv/Rn+JxaEE9PncPRtVH8+XfmmZ1vLgzAwA+MJdRRnfYk69 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFABl4glGtJXG+/2dsb2JhbABSgwc3vyN/FnSCHwEBAQQBAQE3NAsMBAIBCBEEAQEBChQJBycLFAkIAQEEDgUIiAQMwQkEjnUxBwaCbGEDqF2DDYFrJBg X-IronPort-AV: E=Sophos;i="4.87,597,1363132800"; d="scan'208";a="205626084" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 02 May 2013 14:30:46 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r42EUk1v014162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 2 May 2013 14:30:46 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.83]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Thu, 2 May 2013 09:30:45 -0500 From: "Eric Osborne (eosborne)" To: Yuji Tochio Thread-Topic: [mpls] PSC: draft-dj-mpls-tp-exer-psc Thread-Index: Ac47ZWRjRJBAvDu6T4ia+zSmFq3r6QJ+QPwAAEs9aQAAGKbsgAAUtKbQ Date: Thu, 2 May 2013 14:30:44 +0000 Message-ID: <20ECF67871905846A80F77F8F4A275721015DF3E@xmb-rcd-x09.cisco.com> References: <20ECF67871905846A80F77F8F4A27572101502A9@xmb-rcd-x09.cisco.com> <517F078E.5030002@jp.fujitsu.com> <20ECF67871905846A80F77F8F4A275721015D2FF@xmb-rcd-x09.cisco.com> <5181A5EB.8080807@jp.fujitsu.com> In-Reply-To: <5181A5EB.8080807@jp.fujitsu.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.66.70] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] PSC: draft-dj-mpls-tp-exer-psc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 14:30:52 -0000 Hi Yuji- Yes, I agree we have different opinons. I'd like to better understand yo= ur perspective on it. Please see inline. > -----Original Message----- > From: Yuji Tochio [mailto:tochio@jp.fujitsu.com] > Sent: Wednesday, May 01, 2013 7:32 PM > To: Eric Osborne (eosborne) > Cc: mpls@ietf.org > Subject: Re: [mpls] PSC: draft-dj-mpls-tp-exer-psc >=20 > Hi Eric >=20 > I think we (Eric and me) have different opnions for item #3 in LS (...123= 4).. >=20 >=20 > (2013/05/02 1:47), Eric Osborne (eosborne) wrote: > > Hi Yuji- > > > > R84a says "84 It MUST be possible to test and validate any protectio= n/ > > restoration mechanisms and protocols: > > > > A. Including the integrity of the protection/recovery transport > > path." > > > > > > To me, the 'transport path' is the set of links and nodes between the > endpoints of a protection domain, and this function is best served by som= ething > like CC/CV. Clearly we disagree here. >=20 > So far, both without disturbing the transport path that includes the baha= viour of > CC/CV and with validating the linear protection protocol, we have (need) = EXR. > # See 3.2.26 of G.870, please I looked at G.870 3.2.26. For those following along at home, the entire te= xt is: --- 3.2.26 exercise signal #i (EX): Issues an exercise request for that signal = (null signal, normal traffic signal, extra traffic signal) and checks responses on APS messages,= unless the protection transport entity is in use. The switch is not actually completed, i.e., the= selector is released by an exercise request. The exercise functionality is optional. --- None of that says that it checks the integrity of the protection/recovery t= ransport path, which is what R84a wants. As far as I can tell, EXER's job is to validate that the PSC state machine = is still running, and that it is able to respond correctly to a command. M= y understanding, gathered from conversations at the IETF and with others, i= s that EXER is run every so often (once a day?) as some sort of liveness me= chanism. Is that right? draft-dj-mpls-tp-exer-psc says=20 "More specifically, the Exercise is to test and validate the linear protection mechanism and PSC protocol including the aliveness of the Local Request logic, the PSC state machine and the PSC message generation and reception, and the integrity of the protection path, without triggering the actual traffic switching" I buy all of that except for the 'integrity of the protection path' bit. A= re you saying that if we had EXER we wouldn't need CC/CV? I have not commented on the two bits below because I want to make sure I un= derstand your interpretation of R84a before talking about whether EXER is t= he best and only way to address it. eric >=20 > > > > Can you help me understand why EXER > > a) meets the requirement in R84a > > AND > > b) is the best way to meet this requirement ? >=20 > For b), Yes as in item#3 in the LS >=20 > Regards, Yuji >=20 >=20 > > > > > > > > > > eric > > > >> -----Original Message----- > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > >> Of Yuji Tochio > >> Sent: Monday, April 29, 2013 7:52 PM > >> To: mpls@ietf.org > >> Subject: Re: [mpls] PSC: draft-dj-mpls-tp-exer-psc > >> > >> Hi Eric O and all, > >> > >> As to the first bullet to the question below, my opinion is YES. > >> The reason is it is align with #84 (84A) in RFC 5654. > >> > >> Just my 2c, > >> Yuji > >> > >> (2013/04/17 21:21), Eric Osborne (eosborne) wrote: > >>> This thread is for discussing draft-dj-mpls-tp-exer-psc. We started > >>> with -00, > >> but there is now a -01. > >>> The draft proposes adding the EXER/RR commands found in some ITU > >>> linear > >> protection protocols to PSC. > >>> I have also posted an alternative approach, draft-osborne-mpls-psc-al= ive- > 00. > >>> Briefly, EXER is a mechanism designed to check the responsiveness of > >>> the far- > >> end state machine. My proposal, ALIVE, is for a similar mechanism. > >> It works differently and thus may be more or less acceptable. > >>> The big questions here are: > >>> > >>> - do we need any sort of EXER-type function at all? > >>> - if so, are either of the two proposals sufficient? Is there a bett= er way? > >>> - if not, is it possible to provide the same kind of testing and > >>> awareness > >> through existing mechanisms? is this testing and awareness desirable > >> or necessary? > >>> but of course any and all discussion is welcome. > >>> > >>> > >>> > >>> > >>> > >>> eric > >>> _______________________________________________ > >>> 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 >=20 From wyaacov@gmail.com Thu May 2 12:41:40 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA40721F8D70 for ; Thu, 2 May 2013 12:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5aGqxsKxwcCo for ; Thu, 2 May 2013 12:41:39 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 7C35F21F8B64 for ; Thu, 2 May 2013 12:41:39 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hq12so59589wib.1 for ; Thu, 02 May 2013 12:41:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Pcrm2DjlmuORSO2mfjQuowaRSE8w4CFRQ8V/9wM2rkw=; b=R9snLWXDyRyt4I4ucWk9kYvEQXRjm+1FnHfBvXc/4JvuzYvl91XXqJfvsgVVPCLNuY ohdpsDes2NGkrqLqttj4RN/m+rlQtxmlTvBEESpKbSSaAcGCehNaRa8bkQSiZuzVUuKO sespfCKuCtaDo46VFpzKvieJoTyOVZA+cTPTpX3xZOO9u0S7TrW8uHB7tImleaPgL/LQ j7aamF9+WW0mZioSPH9BSzz1oidJG8+D6Lqcm5Yld7eBhSFGNDVAnID2KiNx1CSFaRBm K81vORCmRPWycbq3OXmxI266+z5WlN889fN2TyrkWB3k/B7vrnn+v6cLweUuXjR3APD1 b/Aw== MIME-Version: 1.0 X-Received: by 10.180.14.5 with SMTP id l5mr11385201wic.32.1367523698638; Thu, 02 May 2013 12:41:38 -0700 (PDT) Received: by 10.194.85.229 with HTTP; Thu, 2 May 2013 12:41:38 -0700 (PDT) In-Reply-To: <20ECF67871905846A80F77F8F4A275721015DF3E@xmb-rcd-x09.cisco.com> References: <20ECF67871905846A80F77F8F4A27572101502A9@xmb-rcd-x09.cisco.com> <517F078E.5030002@jp.fujitsu.com> <20ECF67871905846A80F77F8F4A275721015D2FF@xmb-rcd-x09.cisco.com> <5181A5EB.8080807@jp.fujitsu.com> <20ECF67871905846A80F77F8F4A275721015DF3E@xmb-rcd-x09.cisco.com> Date: Thu, 2 May 2013 22:41:38 +0300 Message-ID: From: Yaacov Weingarten To: "Eric Osborne (eosborne)" Content-Type: multipart/alternative; boundary=f46d040fa04c4788de04dbc16cbd Cc: "mpls@ietf.org" Subject: Re: [mpls] PSC: draft-dj-mpls-tp-exer-psc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 May 2013 19:41:41 -0000 --f46d040fa04c4788de04dbc16cbd Content-Type: text/plain; charset=ISO-8859-1 Hi, I would like to point out two things about the definition given in G.870 for the EXER function, as given in the text quoted by Eric - 1. The definition clearly states that EXER is optional! 2. It seems clear (at least to me) that the real reason for the command was to test the selectors that were present in the SDH hardware, (i.e. "switch is not actually completed, i.e., the selector is released by an exercise request") and therefore its relevance to packet switch networks seems questionable. just my 2c, yaacov On Thu, May 2, 2013 at 5:30 PM, Eric Osborne (eosborne) wrote: > Hi Yuji- > > Yes, I agree we have different opinons. I'd like to better understand > your perspective on it. Please see inline. > > > -----Original Message----- > > From: Yuji Tochio [mailto:tochio@jp.fujitsu.com] > > Sent: Wednesday, May 01, 2013 7:32 PM > > To: Eric Osborne (eosborne) > > Cc: mpls@ietf.org > > Subject: Re: [mpls] PSC: draft-dj-mpls-tp-exer-psc > > > > Hi Eric > > > > I think we (Eric and me) have different opnions for item #3 in LS > (...1234).. > > > > > > (2013/05/02 1:47), Eric Osborne (eosborne) wrote: > > > Hi Yuji- > > > > > > R84a says "84 It MUST be possible to test and validate any > protection/ > > > restoration mechanisms and protocols: > > > > > > A. Including the integrity of the protection/recovery transport > > > path." > > > > > > > > > To me, the 'transport path' is the set of links and nodes between the > > endpoints of a protection domain, and this function is best served by > something > > like CC/CV. Clearly we disagree here. > > > > So far, both without disturbing the transport path that includes the > bahaviour of > > CC/CV and with validating the linear protection protocol, we have (need) > EXR. > > # See 3.2.26 of G.870, please > > I looked at G.870 3.2.26. For those following along at home, the entire > text is: > > --- > 3.2.26 exercise signal #i (EX): Issues an exercise request for that signal > (null signal, normal > traffic signal, extra traffic signal) and checks responses on APS > messages, unless the protection > transport entity is in use. The switch is not actually completed, i.e., > the selector is released by an > exercise request. The exercise functionality is optional. > --- > > None of that says that it checks the integrity of the protection/recovery > transport path, which is what R84a wants. > > As far as I can tell, EXER's job is to validate that the PSC state machine > is still running, and that it is able to respond correctly to a command. > My understanding, gathered from conversations at the IETF and with others, > is that EXER is run every so often (once a day?) as some sort of liveness > mechanism. Is that right? > > draft-dj-mpls-tp-exer-psc says > "More specifically, the Exercise is to test and validate > the linear protection mechanism and PSC protocol including the > aliveness of the Local Request logic, the PSC state machine and the > PSC message generation and reception, and the integrity of the > protection path, without triggering the actual traffic switching" > > I buy all of that except for the 'integrity of the protection path' bit. > Are you saying that if we had EXER we wouldn't need CC/CV? > > I have not commented on the two bits below because I want to make sure I > understand your interpretation of R84a before talking about whether EXER is > the best and only way to address it. > > > > > eric > > > > > > > > > > Can you help me understand why EXER > > > a) meets the requirement in R84a > > > AND > > > b) is the best way to meet this requirement ? > > > > For b), Yes as in item#3 in the LS > > > > Regards, Yuji > > > > > > > > > > > > > > > > > > > eric > > > > > >> -----Original Message----- > > >> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > >> Of Yuji Tochio > > >> Sent: Monday, April 29, 2013 7:52 PM > > >> To: mpls@ietf.org > > >> Subject: Re: [mpls] PSC: draft-dj-mpls-tp-exer-psc > > >> > > >> Hi Eric O and all, > > >> > > >> As to the first bullet to the question below, my opinion is YES. > > >> The reason is it is align with #84 (84A) in RFC 5654. > > >> > > >> Just my 2c, > > >> Yuji > > >> > > >> (2013/04/17 21:21), Eric Osborne (eosborne) wrote: > > >>> This thread is for discussing draft-dj-mpls-tp-exer-psc. We started > > >>> with -00, > > >> but there is now a -01. > > >>> The draft proposes adding the EXER/RR commands found in some ITU > > >>> linear > > >> protection protocols to PSC. > > >>> I have also posted an alternative approach, > draft-osborne-mpls-psc-alive- > > 00. > > >>> Briefly, EXER is a mechanism designed to check the responsiveness of > > >>> the far- > > >> end state machine. My proposal, ALIVE, is for a similar mechanism. > > >> It works differently and thus may be more or less acceptable. > > >>> The big questions here are: > > >>> > > >>> - do we need any sort of EXER-type function at all? > > >>> - if so, are either of the two proposals sufficient? Is there a > better way? > > >>> - if not, is it possible to provide the same kind of testing and > > >>> awareness > > >> through existing mechanisms? is this testing and awareness desirable > > >> or necessary? > > >>> but of course any and all discussion is welcome. > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> eric > > >>> _______________________________________________ > > >>> 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 > -- Thanx and BR, yaacov *Still looking for new opportunity* --f46d040fa04c4788de04dbc16cbd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I would like to point out two= things about the definition given in G.870 for the EXER function, as given= in the text quoted by Eric -

1. The d= efinition clearly states that EXER is optional!
2. It seems clear (at least to me) that the real reason for the = command was to test the selectors that were present in the SDH hardware, (i= .e. "switc= h is not actually completed, i.e., the selector is released by an=A0= exercise reques= t") and therefore its relevance to packet switch networks seems questi= onable.

=
just my 2c,
yaacov


On Thu,= May 2, 2013 at 5:30 PM, Eric Osborne (eosborne) <eosborne@cisco.com&= gt; wrote:
Hi Yuji-

=A0 Yes, I agree we have different opinons. =A0I'd like to better under= stand your perspective on it. =A0Please see inline.

> -----Original Message-----
> From: Yuji Tochio [mailto:toc= hio@jp.fujitsu.com]
> Sent: Wednesday, May 01, 2013 7:32 PM
> To: Eric Osborne (eosborne)
> Cc: mpls@ietf.org
> Subject: Re: [mpls] PSC: draft-dj-mpls-tp-exer-psc
>
> Hi Eric
>
> I think we (Eric and me) have different opnion= s for item #3 in LS (...1234)..
>
>
> (2013/05/02 1:47), Eric Osborne (eosborne) wrote:
> > Hi Yuji-
> >
> > =A0 R84a says "84 =A0It MUST be possible to test and validat= e any protection/
> > =A0 =A0 =A0 =A0restoration mechanisms and protocols:
> >
> > =A0 =A0 =A0 =A0A. =A0Including the integrity of the protection/re= covery transport
> > =A0 =A0 =A0 =A0 =A0 =A0path."
> >
> >
> > To me, the 'transport path' is the set of links and nodes= between the
> endpoints of a protection domain, and this function is best served by = something
> like CC/CV. =A0Clearly we disagree here.
>
> So far, both without disturbing the transport path that includes the b= ahaviour of
> CC/CV and with validating the linear protection protocol, we have (nee= d) EXR.
> # See 3.2.26 of G.870, please

I looked at G.870 3.2.26. =A0For those following along at home, the e= ntire text is:

---
3.2.26 exercise signal #i (EX): Issues an exercise request for that signal = (null signal, normal
traffic signal, extra traffic signal) and checks responses on APS messages,= unless the protection
transport entity is in use. The switch is not actually completed, i.e., the= selector is released by an
exercise request. The exercise functionality is optional.
---

None of that says that it checks the integrity of the protection/recovery t= ransport path, which is what R84a wants.

As far as I can tell, EXER's job is to validate that the PSC state mach= ine is still running, and that it is able to respond correctly to a command= . =A0My understanding, gathered from conversations at the IETF and with oth= ers, is that EXER is run every so often (once a day?) as some sort of liven= ess mechanism. =A0Is that right?

draft-dj-mpls-tp-exer-psc says
"More specifically, the Exercise is to test and validate
=A0 =A0the linear protection mechanism and PSC protocol including the
=A0 =A0aliveness of the Local Request logic, the PSC state machine and the<= br> =A0 =A0PSC message generation and reception, and the integrity of the
=A0 =A0protection path, without triggering the actual traffic switching&quo= t;

I buy all of that except for the 'integrity of the protection path'= bit. =A0Are you saying that if we had EXER we wouldn't need CC/CV?

I have not commented on the two bits below because I want to make sure I un= derstand your interpretation of R84a before talking about whether EXER is t= he best and only way to address it.




eric


>
> >
> > Can you help me understand why EXER
> > =A0 a) meets the requirement in R84a
> > =A0AND
> > =A0b) is the best way to meet this requirement ?
>
> For b), Yes as in item#3 in the LS
>
> Regards, Yuji
>
>
> >
> >
> >
> >
> > eric
> >
> >> -----Original Message-----
> >> From: mpls-bounces@i= etf.org [mailto:mpls-bounces@i= etf.org] On Behalf
> >> Of Yuji Tochio
> >> Sent: Monday, April 29, 2013 7:52 PM
> >> To: mpls@ietf.org
> >> Subject: Re: [mpls] PSC: draft-dj-mpls-tp-exer-psc
> >>
> >> Hi Eric O and all,
> >>
> >> As to the first bullet to the question below, my opinion is Y= ES.
> >> The reason is it is align with #84 (84A) in RFC 5654.
> >>
> >> Just my 2c,
> >> Yuji
> >>
> >> (2013/04/17 21:21), Eric Osborne (eosborne) wrote:
> >>> This thread is for discussing draft-dj-mpls-tp-exer-psc. = =A0We started
> >>> with -00,
> >> but there is now a -01.
> >>> The draft proposes adding the EXER/RR commands found in s= ome ITU
> >>> linear
> >> protection protocols to PSC.
> >>> I have also posted an alternative approach, draft-osborne= -mpls-psc-alive-
> 00.
> >>> Briefly, EXER is a mechanism designed to check the respon= siveness of
> >>> the far-
> >> end state machine. =A0My proposal, ALIVE, is for a similar me= chanism.
> >> It works differently and thus may be more or less acceptable.=
> >>> The big questions here are:
> >>>
> >>> - do we need any sort of EXER-type function at all?
> >>> - if so, are either of the two proposals sufficient? =A0I= s there a better way?
> >>> - if not, is it possible to provide the same kind of test= ing and
> >>> awareness
> >> through existing mechanisms? =A0is this testing and awareness= desirable
> >> or necessary?
> >>> but of course any and all discussion is welcome.
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> eric
> >>> _______________________________________________
> >>> 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
ht= tps://www.ietf.org/mailman/listinfo/mpls



--
=
Thanx and BR,
yaacov

Still= looking for new opportunity
--f46d040fa04c4788de04dbc16cbd-- From loa@pi.nu Fri May 3 02:08:48 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBEE21F8574 for ; Fri, 3 May 2013 02:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QUIsv9QblFG5 for ; Fri, 3 May 2013 02:08:42 -0700 (PDT) Received: from pipi.pi.nu (unknown [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDB821F853A for ; Fri, 3 May 2013 02:08:42 -0700 (PDT) Received: from [192.168.1.104] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 4DC081802D34; Fri, 3 May 2013 11:08:40 +0200 (CEST) Message-ID: <51837E9A.7020709@pi.nu> Date: Fri, 03 May 2013 11:08:42 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , Martin Vigoureux , draft-ietf-mpls-ldp-ip-pw-capability@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Implementation poll on draft-ietf-mpls-ldp-ip-pw-capability X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 09:08:48 -0000 Working Group, draft-ietf-mpls-ldp-ip-pw-capability is in the process of being updated after working group last call. When the new version is posted, we will request publication of the document as an RFC on the Standards track. As part of the shepherd write-up, that is sent as part of the request for publication to the IESG, we need to know about existing or intended implementations of draft-ietf-mpls-ldp-ip-pw-capability. Please send mails to the mpls wg mailing list (mpls@ietf.org) or the working group chairs to inform us about implementations. /Loa (as wg co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From loa@pi.nu Fri May 3 04:20:00 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9369521F86BB for ; Fri, 3 May 2013 04:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9WMFS5mn4idD for ; Fri, 3 May 2013 04:19:54 -0700 (PDT) Received: from pipi.pi.nu (unknown [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id A11CF21F84B2 for ; Fri, 3 May 2013 04:19:54 -0700 (PDT) Received: from [192.168.1.104] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 107851802D34; Fri, 3 May 2013 13:19:53 +0200 (CEST) Message-ID: <51839D5B.5090108@pi.nu> Date: Fri, 03 May 2013 13:19:55 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: draft-ietf-mpls-ldp-ip-pw-capability@tools.ietf.org, "mpls@ietf.org" , Martin Vigoureux Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] IANA section of draft-ietf-mpls-ldp-ip-pw-capability X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 11:20:00 -0000 Authors, I should have done this before, IANA sections is always tricky and need to be precise, The IANA section of draft-ietf-mpls-ldp-ip-pw-capability-03.txt says: "8. IANA Considerations The document defines a new capability parameter TLV and requests following LDP TLV code point assignment by IANA from LDP "TLV Type Name Space" registry: o "Application Control Capability" TLV (requested codepoint: 0x50C)" This is basically correct, but a few details need to be added. I would like to have it re-written as: 8. IANA Considerations This document defines a new LDP cpability parameter. IANA is requested to assign a new LDP TLV code point from "TLV Type Name Space" in the "Label Distribution Protocol (LDP) Parameters" registry within "Label Distribution Protocol (LDP) Name Spaces". Range | Description | Reference | Notes/Registration Date ------+---------------------+---------------+--------------------------- tbd | Application Control | This document | | Capability | | ------+---------------------+---------------+--------------------------- Note 1: That naming structure is not good, I will talk to IANA to change it to something more intuitive. Note 2: "Range" is really "Value" or "Type", will check on the defining documents and talk to IANA to change it. -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From loa@pi.nu Fri May 3 05:56:29 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806A421F961C for ; Fri, 3 May 2013 05:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E16K7jULIPGS for ; Fri, 3 May 2013 05:56:21 -0700 (PDT) Received: from pipi.pi.nu (unknown [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3BD21F9642 for ; Fri, 3 May 2013 05:56:21 -0700 (PDT) Received: from [192.168.0.44] (81-229-83-126-no65.business.telia.com [81.229.83.126]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 59C5A1802D34; Fri, 3 May 2013 14:56:15 +0200 (CEST) References: <51839D5B.5090108@pi.nu> From: Loa Anderson Content-Type: text/plain; charset=us-ascii X-Mailer: iPad Mail (10B329) In-Reply-To: <51839D5B.5090108@pi.nu> Message-Id: <3999432F-4D33-4AA1-8E2C-57225461D016@pi.nu> Date: Fri, 3 May 2013 14:56:14 +0200 To: "draft-ietf-mpls-ldp-ip-pw-capability@tools.ietf.org" , "mpls@ietf.org" , Martin Vigoureux Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Subject: Re: [mpls] IANA section of draft-ietf-mpls-ldp-ip-pw-capability X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 12:56:29 -0000 Kerman, Hold this until I tell you go ahead. There is something I need to check first. /Loa Sent from my iPad On 3 maj 2013, at 13:19, Loa Andersson wrote: > Authors, > > > I should have done this before, IANA sections is always tricky > and need to be precise, > > The IANA section of draft-ietf-mpls-ldp-ip-pw-capability-03.txt > says: > > "8. IANA Considerations > > The document defines a new capability parameter TLV and requests > following LDP TLV code point assignment by IANA from LDP "TLV Type > Name Space" registry: > > o "Application Control Capability" TLV (requested codepoint: 0x50C)" > > This is basically correct, but a few details need to be > added. I would like to have it re-written as: > > 8. IANA Considerations > > This document defines a new LDP cpability parameter. IANA is > requested to assign a new LDP TLV code point from "TLV Type > Name Space" in the "Label Distribution Protocol (LDP) Parameters" > registry within "Label Distribution Protocol (LDP) Name Spaces". > > Range | Description | Reference | Notes/Registration Date > ------+---------------------+---------------+--------------------------- > tbd | Application Control | This document | > | Capability | | > ------+---------------------+---------------+--------------------------- > > > > Note 1: That naming structure is not good, I will talk to IANA to change it > to something more intuitive. > > Note 2: "Range" is really "Value" or "Type", will check on the defining > documents and talk to IANA to change it. > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From huubatwork@gmail.com Fri May 3 07:06:55 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B20421F9635 for ; Fri, 3 May 2013 07:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wEIYm8e7Rz5R for ; Fri, 3 May 2013 07:06:54 -0700 (PDT) Received: from mail-ea0-x233.google.com (mail-ea0-x233.google.com [IPv6:2a00:1450:4013:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id DB60B21F8A0C for ; Fri, 3 May 2013 07:06:43 -0700 (PDT) Received: by mail-ea0-f179.google.com with SMTP id h14so756476eaj.24 for ; Fri, 03 May 2013 07:06:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:disposition-notification-to:date:from :reply-to:user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=/P9vf53uulqqfWuoCA15QPk5pR4yRCJtKcDnyaCk+1o=; b=HN9n3L/kHUyKS50lgBHCnNjhINSM5os3AlPtkd754BRRR5t8/PeIEiTN/zzCNBPx9f m4g0Yg2KVzVzWZt1SFD5qSG0Pfk+tA2szTXU4ucIBik+QdLLBCXptYxTifVuRi5sid06 vua682E4dU+IlclXBY8PAq1HpCOQd49vB6t0xIafauEWOlS/ZvMcjXag89eym9l9RE/K QPmyIT4y048W/TyxKdfI57WsKrXBKY/X9rlHtvf4ipHP/qnFLZv6evLgCOfzyvCKZH6l 3A80fDOMUAw1hDruD6xxk2o3j6tgw45XX95/OTI+OcleUmtBHFQUL+4E6t07ezLj2lUy 3FTQ== X-Received: by 10.14.3.9 with SMTP id 9mr25503555eeg.33.1367590002999; Fri, 03 May 2013 07:06:42 -0700 (PDT) Received: from McAsterix.local (g215085.upc-g.chello.nl. [80.57.215.85]) by mx.google.com with ESMTPSA id c44sm12761413eeb.4.2013.05.03.07.06.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 03 May 2013 07:06:42 -0700 (PDT) Message-ID: <5183C475.3030909@gmail.com> Date: Fri, 03 May 2013 16:06:45 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mpls@ietf.org References: <20ECF67871905846A80F77F8F4A27572101502A9@xmb-rcd-x09.cisco.com> <517F078E.5030002@jp.fujitsu.com> <20ECF67871905846A80F77F8F4A275721015D2FF@xmb-rcd-x09.cisco.com> <5181A5EB.8080807@jp.fujitsu.com> <20ECF67871905846A80F77F8F4A275721015DF3E@xmb-rcd-x09.cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mpls] PSC: draft-dj-mpls-tp-exer-psc X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 14:06:55 -0000 Yaacov, hi, You wrote: > I would like to point out two things about the definition given in G.870 > for the EXER function, as given in the text quoted by Eric - > > 1. The definition clearly states that EXER is optional! I have talked to the editor of G.870, he confirmed that this statement is his interpretation of the following text in G.841 clause 7.1.2.1 (switch commands for MSP [Multiplex Section Protection]) "The exercise functionality may not exist in all MSP functions." This is from the 1998 version of G.841, and is applicable to MSP implementations that existed before 1998. All other protection schemes in G.841 do not mention this exception. Clause 7.2.4.1.2 even emphasizes the importance of EXER: "the exerciser function is even more essential" (for ring protection). > 2. It seems clear (at least to me) that the real reason for the command > was to test the selectors that were present in the SDH hardware, (i.e. > "switch is not actually completed, i.e., the selector is released by an > exercise request") and therefore its relevance to packet switch networks > seems questionable. When you were editor of G.8032 (Ethernet ring protection) the following text was written: "Exercise Signal – Exercise of the R-APS protocol. The signal is chosen so as not to modify the position of the blocked ring port." This makes again clear that the reason for the EXER signal is to exercise the protocol, without affecting traffic. Regards, Huub. -- ***************************************************************** 请记ä½ï¼Œä½ æ˜¯ç‹¬ä¸€æ— äºŒçš„，就åƒå…¶ä»–æ¯ä¸€ä¸ªäººä¸€æ · From loa@pi.nu Fri May 3 10:06:45 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB01321F9722 for ; Fri, 3 May 2013 10:06:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.449 X-Spam-Level: X-Spam-Status: No, score=-98.449 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWwMi8OFhVvr for ; Fri, 3 May 2013 10:06:39 -0700 (PDT) Received: from pipi.pi.nu (unknown [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6E12921F98A4 for ; Fri, 3 May 2013 09:50:54 -0700 (PDT) Received: from [192.168.1.104] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 4C8441802D36; Fri, 3 May 2013 18:50:53 +0200 (CEST) Message-ID: <5183EAEF.8020100@pi.nu> Date: Fri, 03 May 2013 18:50:55 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: draft-ietf-mpls-ldp-ip-pw-capability@tools.ietf.org, "mpls@ietf.org" , Martin Vigoureux References: <51839D5B.5090108@pi.nu> In-Reply-To: <51839D5B.5090108@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [mpls] IANA section of draft-ietf-mpls-ldp-ip-pw-capability X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 17:06:45 -0000 Folks, I would like to amend my proposal to say: 8. IANA Considerations This document defines a new LDP cpability parameter TLV. IANA is requested to assign the lowest available value after 0x0500 from "TLV Type Name Space" in the "Label Distribution Protocol (LDP) Parameters" registry within "Label Distribution Protocol (LDP) Name Spaces" as the new code point for the LDP TLV code point . Range | Description | Reference | Notes/Registration Date -------+---------------------+---------------+--------------------------- tbd | Application Control | This document | | Capability | | -------+---------------------+---------------+--------------------------- /Loa On 2013-05-03 13:19, Loa Andersson wrote: > Authors, > > > I should have done this before, IANA sections is always tricky > and need to be precise, > > The IANA section of draft-ietf-mpls-ldp-ip-pw-capability-03.txt > says: > > "8. IANA Considerations > > The document defines a new capability parameter TLV and requests > following LDP TLV code point assignment by IANA from LDP "TLV Type > Name Space" registry: > > o "Application Control Capability" TLV (requested codepoint: 0x50C)" > > This is basically correct, but a few details need to be > added. I would like to have it re-written as: > > 8. IANA Considerations > > This document defines a new LDP cpability parameter. IANA is > requested to assign a new LDP TLV code point from "TLV Type > Name Space" in the "Label Distribution Protocol (LDP) Parameters" > registry within "Label Distribution Protocol (LDP) Name Spaces". > > Range | Description | Reference | Notes/Registration Date > ------+---------------------+---------------+--------------------------- > tbd | Application Control | This document | > | Capability | | > ------+---------------------+---------------+--------------------------- > > > > Note 1: That naming structure is not good, I will talk to IANA to change it > to something more intuitive. > > Note 2: "Range" is really "Value" or "Type", will check on the defining > documents and talk to IANA to change it. -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From Alan.Davey@metaswitch.com Fri May 3 10:11:24 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5F821F8443 for ; Fri, 3 May 2013 10:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yPvORe+j3sr for ; Fri, 3 May 2013 10:11:10 -0700 (PDT) Received: from ENFICSETS1.metaswitch.com (enficsets1.metaswitch.com [192.91.191.38]) by ietfa.amsl.com (Postfix) with ESMTP id 177D421F8F2E for ; Fri, 3 May 2013 09:29:22 -0700 (PDT) Received: from ENFIRHMBX1.datcon.co.uk (172.18.74.36) by ENFICSETS1.metaswitch.com (172.18.4.18) with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 3 May 2013 17:28:32 +0100 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFIRHMBX1.datcon.co.uk ([fe80::b06d:4d13:5f63:3715%19]) with mapi id 14.02.0342.003; Fri, 3 May 2013 17:29:19 +0100 From: Alan Davey To: "rfc6428@tools.ietf.org" Thread-Topic: [MPLS] A doubt about RFC 6428 Thread-Index: Ac5IG1yAbZhW1zCyQtKJoj7oW461Ug== Date: Fri, 3 May 2013 16:29:19 +0000 Message-ID: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.71.124] Content-Type: multipart/alternative; boundary="_000_C2EE31C852049D499842B19FC01C0804C1A8C004ENFICSMBX1datco_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: [mpls] [MPLS] A doubt about RFC 6428 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 17:11:34 -0000 --_000_C2EE31C852049D499842B19FC01C0804C1A8C004ENFICSMBX1datco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Folks I have a doubt about RFC 6428. Could you please let me know what you think= of the following. Section 3.7.4.2., Exit from a Mis-Connectivity Defect, states that "Exit fr= om a mis-connectivity defect state occurs when no CV messages with mis-conn= ectivity defects have been received for a period of 3.5 seconds". However, the State Machines in section 3.7.5 have no input corresponding to= an "Exit from a Mis-Connectivity Defect" timer pop. (Although they do hav= e a MIS-CONNECTIVITY input added by RFC 6428.) If the State Machine is fol= lowed then Down state is exited as soon as the remote system signals Down s= tate. Should the State Machines be modified such that Down state following a MIS-= CONNECTIVITY input is only exited after an "Exit from a Mis-Connectivity De= fect" timer pop input or am I missing something? Regards Alan Davey Network Technologies Metaswitch Networks alan.davey@metaswitch.com +44 (0) 20 8366 1177 network-technologies.metaswitch.com --_000_C2EE31C852049D499842B19FC01C0804C1A8C004ENFICSMBX1datco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Folks

 

I have a doubt about RFC 6428.  Could you pleas= e let me know what you think of the following.

 

Section 3.7.4.2., Exit from a Mis-Connectivity Defec= t, states that “Exit from a mis-connectivity defect state occurs when= no CV messages with mis-connectivity defects have been received for a peri= od of 3.5 seconds”.

 

However, the State Machines in section 3.7.5 have no= input corresponding to an “Exit from a Mis-Connectivity Defect”= ; timer pop.  (Although they do have a MIS-CONNECTIVITY input added by= RFC 6428.)  If the State Machine is followed then Down state is exited as soon as the remote system signals Down state.=

 

Should the State Machines be modified such that Down= state following a MIS-CONNECTIVITY input is only exited after an “Ex= it from a Mis-Connectivity Defect” timer pop input or am I missing so= mething?

 

Regards

Alan Davey

 

Network = Technologies
Metaswitch Networks

 =

alan.davey@metaswitch.com
+44 (0) 20 8366 1177
network-technologies.metaswitch.com<= /a>

 

 

 

--_000_C2EE31C852049D499842B19FC01C0804C1A8C004ENFICSMBX1datco_-- From rcallon@juniper.net Fri May 3 10:23:30 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09CD921F8691 for ; Fri, 3 May 2013 10:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.674 X-Spam-Level: X-Spam-Status: No, score=-98.674 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.325, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jHCLiYCPzHH for ; Fri, 3 May 2013 10:23:16 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 11A2E21F969A for ; Fri, 3 May 2013 09:35:47 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKUYPnWnYuNslqTyhwZQNbiYe9mZt/gljI@postini.com; Fri, 03 May 2013 09:35:48 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 3 May 2013 09:25:48 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 3 May 2013 09:25:47 -0700 Received: from DB8EHSOBE037.bigfish.com (213.199.154.188) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 3 May 2013 09:29:12 -0700 Received: from mail108-db8-R.bigfish.com (10.174.8.228) by DB8EHSOBE037.bigfish.com (10.174.4.100) with Microsoft SMTP Server id 14.1.225.23; Fri, 3 May 2013 16:25:45 +0000 Received: from mail108-db8 (localhost [127.0.0.1]) by mail108-db8-R.bigfish.com (Postfix) with ESMTP id 5DA273A09B1 for ; Fri, 3 May 2013 16:25:45 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); (null); H:CH1PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -1 X-BigFish: PS-1(zzc85fh4015Izz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz17326ah18c673h8275bh8275dhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1155h) Received: from mail108-db8 (localhost.localdomain [127.0.0.1]) by mail108-db8 (MessageSwitch) id 1367598342886013_29136; Fri, 3 May 2013 16:25:42 +0000 (UTC) Received: from DB8EHSMHS012.bigfish.com (unknown [10.174.8.225]) by mail108-db8.bigfish.com (Postfix) with ESMTP id D4D2E2A0096; Fri, 3 May 2013 16:25:42 +0000 (UTC) Received: from CH1PRD0510HT004.namprd05.prod.outlook.com (157.56.244.213) by DB8EHSMHS012.bigfish.com (10.174.4.22) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 3 May 2013 16:25:37 +0000 Received: from CH1PRD0510MB355.namprd05.prod.outlook.com ([169.254.2.207]) by CH1PRD0510HT004.namprd05.prod.outlook.com ([10.255.150.39]) with mapi id 14.16.0305.001; Fri, 3 May 2013 16:25:25 +0000 From: Ross Callon To: Loa Andersson , "mach.chen@huawei.com" , "tomSecurity@network-engineer.co.uk" , "mpls@ietf.org" Thread-Topic: IPR poll on draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry Thread-Index: AQHOSBrQ/76fnpd7LECOnkcVwQ3G4Q== Date: Fri, 3 May 2013 16:25:24 +0000 Message-ID: <62CCD4C52ACDAD4481149BD5D8A72FD316C38BCF@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: multipart/alternative; boundary="_000_62CCD4C52ACDAD4481149BD5D8A72FD316C38BCFCH1PRD0510MB355_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%MAIL01.HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%HUAWEI.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%NETWORK-ENGINEER.CO.UK$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ALCATEL-LUCENT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] IPR poll on draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 17:23:30 -0000 --_000_62CCD4C52ACDAD4481149BD5D8A72FD316C38BCFCH1PRD0510MB355_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Working Group and authors; draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry is nearly ready to be ca= lled for potential WG adoption. Before the call for adoption, we would like to check whether there is IPR o= n the document that needs to be disclosed. Are you aware of any IPR that applies to draft-pac-mpls-lsp-ping-tlvs-and-s= ub-tlvs-registry? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to thi= s email regardless of whether or not you are aware of any relevant IPR. The respons= e needs to be sent to the MPLS wg mailing list. The documents will not advance to t= he next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Ross (as MPLS WG co-chair) --_000_62CCD4C52ACDAD4481149BD5D8A72FD316C38BCFCH1PRD0510MB355_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Working Group and authors;

 

draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry is nearly ready to be = called

for potential WG adoption.

 

Before the call for adoption, we would like to check whether there is IPR= on the

document that needs to be disclosed.

 

Are you aware of any IPR that applies to draft-pac-mpls-lsp-ping-tlvs-and= -sub-tlvs-registry?

If so, has this IPR been disclosed in compliance with IETF IPR rules

(see RFCs 3979, 4879, 3669 and 5378 for more details).<= /p>

 

If you are listed as a document author or contributor please respond to t= his email

regardless of whether or not you are aware of any relevant IPR. The respo= nse needs

to be sent to the MPLS wg mailing list. The documents will not advance to= the next

stage until a response has been received from each author and contributor= .

 

If you are on the MPLS WG email list but are not listed as an author or

contributor, then please explicitly respond only if you are aware of any

IPR that has not yet been disclosed in conformance with IETF rules.<= /o:p>

 

Thanks, Ross

(as MPLS WG co-chair)

 

 

--_000_62CCD4C52ACDAD4481149BD5D8A72FD316C38BCFCH1PRD0510MB355_-- From loa@pi.nu Fri May 3 10:32:33 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4571721F9671 for ; Fri, 3 May 2013 10:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.449 X-Spam-Level: X-Spam-Status: No, score=-98.449 tagged_above=-999 required=5 tests=[FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id If+j3KaMNN+r for ; Fri, 3 May 2013 10:32:27 -0700 (PDT) Received: from pipi.pi.nu (unknown [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4C09E21F9805 for ; Fri, 3 May 2013 09:32:29 -0700 (PDT) Received: from [192.168.1.104] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id E04611802D36; Fri, 3 May 2013 18:32:10 +0200 (CEST) Message-ID: <5183E68D.9040405@pi.nu> Date: Fri, 03 May 2013 18:32:13 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Ross Callon References: <62CCD4C52ACDAD4481149BD5D8A72FD316C38BCF@CH1PRD0510MB355.namprd05.prod.outlook.com> In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316C38BCF@CH1PRD0510MB355.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "tomSecurity@network-engineer.co.uk" , Loa Andersson , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 17:32:33 -0000 Ross, I'm a co-author and I'm not aware of any IPR that applies to this draft. /Loa On 2013-05-03 18:25, Ross Callon wrote: > Working Group and authors; > > draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry is nearly ready to be > called > > for potential WG adoption. > > Before the call for adoption, we would like to check whether there is > IPR on the > > document that needs to be disclosed. > > Are you aware of any IPR that applies to > draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > If you are listed as a document author or contributor please respond to > this email > > regardless of whether or not you are aware of any relevant IPR. The > response needs > > to be sent to the MPLS wg mailing list. The documents will not advance > to the next > > stage until a response has been received from each author and contributor. > > If you are on the MPLS WG email list but are not listed as an author or > > contributor, then please explicitly respond only if you are aware of any > > IPR that has not yet been disclosed in conformance with IETF rules. > > Thanks, Ross > > (as MPLS WG co-chair) > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From ietfc@btconnect.com Fri May 3 10:36:56 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9922721F96B2 for ; Fri, 3 May 2013 10:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[AWL=2.000, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-dYH0ztRSi4 for ; Fri, 3 May 2013 10:36:50 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBE721F8EB9 for ; Fri, 3 May 2013 10:16:41 -0700 (PDT) Received: from mail15-co9-R.bigfish.com (10.236.132.244) by CO9EHSOBE007.bigfish.com (10.236.130.70) with Microsoft SMTP Server id 14.1.225.23; Fri, 3 May 2013 17:16:40 +0000 Received: from mail15-co9 (localhost [127.0.0.1]) by mail15-co9-R.bigfish.com (Postfix) with ESMTP id CEDA82A0404; Fri, 3 May 2013 17:16:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.250.69; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0711HT001.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -14 X-BigFish: PS-14(zz9371I542I4015Izz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz8275bh8275dh8275ch1033ILz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh304l1d11m1155h) Received: from mail15-co9 (localhost.localdomain [127.0.0.1]) by mail15-co9 (MessageSwitch) id 136760139991702_23123; Fri, 3 May 2013 17:16:39 +0000 (UTC) Received: from CO9EHSMHS032.bigfish.com (unknown [10.236.132.254]) by mail15-co9.bigfish.com (Postfix) with ESMTP id 119C020163; Fri, 3 May 2013 17:16:39 +0000 (UTC) Received: from AMXPRD0711HT001.eurprd07.prod.outlook.com (157.56.250.69) by CO9EHSMHS032.bigfish.com (10.236.130.42) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 3 May 2013 17:16:37 +0000 Received: from AMXPRD0310HT002.eurprd03.prod.outlook.com (157.56.248.133) by pod51017.outlook.com (10.242.9.162) with Microsoft SMTP Server (TLS) id 14.16.305.3; Fri, 3 May 2013 17:16:02 +0000 Message-ID: <02ab01ce4821$2c77ea60$4001a8c0@gateway.2wire.net> From: t.petch To: Ross Callon , References: <62CCD4C52ACDAD4481149BD5D8A72FD316C38BCF@CH1PRD0510MB355.namprd05.prod.outlook.com> Date: Fri, 3 May 2013 18:10:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.248.133] X-FOPE-CRA-Verdict: 157.56.250.69$juniper.net%12218%4%btconnect.com%False%False%0$ X-OriginatorOrg: btconnect.com Cc: mpls-chairs@tools.ietf.org Subject: Re: [mpls] IPR poll on draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 17:36:56 -0000 Ross, I'm a co-author and I'm not aware of any IPR that applies to this draft. Tom Petch ----- Original Message ----- From: "Ross Callon" To: "Loa Andersson" ; ; ; Cc: ; "Martin Vigoureux" Sent: Friday, May 03, 2013 5:25 PM Subject: IPR poll on draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry Working Group and authors; draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry is nearly ready to be called for potential WG adoption. Before the call for adoption, we would like to check whether there is IPR on the document that needs to be disclosed. Are you aware of any IPR that applies to draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. The response needs to be sent to the MPLS wg mailing list. The documents will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Ross (as MPLS WG co-chair) From prvs=0835415576=david.i.allan@ericsson.com Fri May 3 10:41:36 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2750521F919D for ; Fri, 3 May 2013 10:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjk0NBTX6sCx for ; Fri, 3 May 2013 10:41:30 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id F0A9821F9026 for ; Fri, 3 May 2013 10:35:02 -0700 (PDT) X-AuditID: c618062d-b7ff46d000006709-33-5183f5465dcb Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 9D.6A.26377.645F3815; Fri, 3 May 2013 19:35:02 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0328.009; Fri, 3 May 2013 13:34:57 -0400 From: David Allan I To: Alan Davey , "rfc6428@tools.ietf.org" Thread-Topic: [MPLS] A doubt about RFC 6428 Thread-Index: Ac5IG1yAbZhW1zCyQtKJoj7oW461UgACNQsQ Date: Fri, 3 May 2013 17:34:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_E6C17D2345AC7A45B7D054D407AA205C097D0Aeusaamb105ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrILMWRmVeSWpSXmKPExsUyuXRPoK7b1+ZAgycftSyeTJvFZnFr6UpW i8knl7E6MHssWfKTyePozbnMHl8uf2YLYI7itklKLCkLzkzP07dL4M54eaqZpeCJXcXhr33s DYxN5l2MnBwSAiYS7//NZYOwxSQu3FsPZHNxCAkcZZT4fHwXE0hCSGAZo8T3m94gNpuAgcSe /18YQWwRgXiJ2Z+nA9VwcDALKEucuisDYgoLaEk8n1UCUaEtsWNqDxOEbSQxo+UhK4jNIqAi seRKDzuIzSvgLXHk3TuwKUICfhI7GvJATE4Bf4mHf/1BKhiBDvt+ag3YFGYBcYlbT+YzQRws ILFkz3lmCFtU4uXjf6wQtrLEkif7WSDq8yVa/zcwQWwSlDg58wnLBEbRWUhGzUJSNgtJGURc R2LB7k9sELa2xLKFr5lh7DMHHjMhiy9gZF/FyFFanFqWm25ksIkRGGPHJNh0dzDueWl5iFGa g0VJnDeKqzFQSCA9sSQ1OzW1ILUovqg0J7X4ECMTByeI4JJqYIz/yBbiUC5kwlB2rDe4qnHL nPdzT12RjtiZznclwWri9/BzyxpEZM0TDiqG3amuzS3J+RRjbHV+z5bJQjmmOX0L44Ms6kx0 Q2ceC7zz41aU9Jk9dSXJ375LrzCWaI5y2a4Sw7uwPtgs9kDSQq2jzJcddyhmt8Z7xq59GO2i 7uVxLKQGGNBKLMUZiYZazEXFiQCQokbWhAIAAA== Cc: "mpls@ietf.org" Subject: Re: [mpls] [MPLS] A doubt about RFC 6428 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 17:41:36 -0000 --_000_E6C17D2345AC7A45B7D054D407AA205C097D0Aeusaamb105ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Alan: It is kind of implied, as in "received DOWN while NOT in a misconnectivity = state". I'm not sure adding that to the state machine diagram would actuall= y improve the clarity....I'll let others comment. cheers Dave ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ala= n Davey Sent: Friday, May 03, 2013 9:29 AM To: rfc6428@tools.ietf.org Cc: mpls@ietf.org Subject: [mpls] [MPLS] A doubt about RFC 6428 Folks I have a doubt about RFC 6428. Could you please let me know what you think= of the following. Section 3.7.4.2., Exit from a Mis-Connectivity Defect, states that "Exit fr= om a mis-connectivity defect state occurs when no CV messages with mis-conn= ectivity defects have been received for a period of 3.5 seconds". However, the State Machines in section 3.7.5 have no input corresponding to= an "Exit from a Mis-Connectivity Defect" timer pop. (Although they do hav= e a MIS-CONNECTIVITY input added by RFC 6428.) If the State Machine is fol= lowed then Down state is exited as soon as the remote system signals Down s= tate. Should the State Machines be modified such that Down state following a MIS-= CONNECTIVITY input is only exited after an "Exit from a Mis-Connectivity De= fect" timer pop input or am I missing something? Regards Alan Davey Network Technologies Metaswitch Networks alan.davey@metaswitch.com +44 (0) 20 8366 1177 network-technologies.metaswitch.com --_000_E6C17D2345AC7A45B7D054D407AA205C097D0Aeusaamb105ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Alan:
 
It is kind of implied, as in "received D= OWN while NOT in a misconnectivity state". I'm not sure adding that to= the state machine diagram would actually improve the clarity....I'll let others comment.
 
cheers
Dave

From: mpls-bounces@ietf.org [mailto= :mpls-bounces@ietf.org] On Behalf Of Alan Davey
Sent: Friday, May 03, 2013 9:29 AM
To: rfc6428@tools.ietf.org
Cc: mpls@ietf.org
Subject: [mpls] [MPLS] A doubt about RFC 6428

Folks

 

I have a doubt about RFC 6428.  Could you pleas= e let me know what you think of the following.

 

Section 3.7.4.2., Exit from a Mis-Connectivity Defec= t, states that “Exit from a mis-connectivity defect state occurs when= no CV messages with mis-connectivity defects have been received for a peri= od of 3.5 seconds”.

 

However, the State Machines in section 3.7.5 have no= input corresponding to an “Exit from a Mis-Connectivity Defect”= ; timer pop.  (Although they do have a MIS-CONNECTIVITY input added by= RFC 6428.)  If the State Machine is followed then Down state is exited as soon as the remote system signals Down state.=

 

Should the State Machines be modified such that Down= state following a MIS-CONNECTIVITY input is only exited after an “Ex= it from a Mis-Connectivity Defect” timer pop input or am I missing so= mething?

 

Regards

Alan Davey

 

Network Technologies
Metaswitch Networks

 

alan.davey@metaswitch.com
+44 (0) 20 8366 1177
network-technologies.metaswitch.com

 

 

 

--_000_E6C17D2345AC7A45B7D054D407AA205C097D0Aeusaamb105ericsso_-- From mach.chen@huawei.com Sun May 5 17:53:14 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9118B21F9793 for ; Sun, 5 May 2013 17:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aM17Bg+ExAi2 for ; Sun, 5 May 2013 17:53:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3D79521F9792 for ; Sun, 5 May 2013 17:53:01 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASL82822; Mon, 06 May 2013 00:52:58 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 6 May 2013 01:52:49 +0100 Received: from SZXEML448-HUB.china.huawei.com (10.82.67.191) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 6 May 2013 01:52:52 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.134]) by szxeml448-hub.china.huawei.com ([10.82.67.191]) with mapi id 14.01.0323.007; Mon, 6 May 2013 08:52:47 +0800 From: Mach Chen To: Ross Callon , Loa Andersson , "tomSecurity@network-engineer.co.uk" , "mpls@ietf.org" Thread-Topic: IPR poll on draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry Thread-Index: AQHOSBrQ/76fnpd7LECOnkcVwQ3G4Zj3V5CA Date: Mon, 6 May 2013 00:52:46 +0000 Message-ID: References: <62CCD4C52ACDAD4481149BD5D8A72FD316C38BCF@CH1PRD0510MB355.namprd05.prod.outlook.com> In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316C38BCF@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255B81B31szxeml558mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 00:53:14 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255B81B31szxeml558mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ross, I'm not aware of any IPR that applies to this draft. Many thanks, Mach From: Ross Callon [mailto:rcallon@juniper.net] Sent: Saturday, May 04, 2013 12:25 AM To: Loa Andersson; Mach Chen; tomSecurity@network-engineer.co.uk; mpls@ietf= .org Cc: mpls-chairs@tools.ietf.org; Martin Vigoureux Subject: IPR poll on draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry Working Group and authors; draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry is nearly ready to be ca= lled for potential WG adoption. Before the call for adoption, we would like to check whether there is IPR o= n the document that needs to be disclosed. Are you aware of any IPR that applies to draft-pac-mpls-lsp-ping-tlvs-and-s= ub-tlvs-registry? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to thi= s email regardless of whether or not you are aware of any relevant IPR. The respons= e needs to be sent to the MPLS wg mailing list. The documents will not advance to t= he next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Ross (as MPLS WG co-chair) --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255B81B31szxeml558mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi Ross,=

=  

= I'm not aware of any IPR that app= lies to this draft.

=  

= Many thanks,

= Mach

=  

From: Ross Callon [mailto:rcallon@juniper.net]
Sent: Saturday, May 04, 2013= 12:25 AM
To: Loa Andersson; Mach Chen= ; tomSecurity@network-engineer.co.uk; mpls@ietf.org
Cc: mpls-chairs@tools.ietf.o= rg; Martin Vigoureux
Subject: IPR poll on draft-p= ac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry

 

Working Group and autho= rs;

 

draft-pac-mpls-lsp-ping= -tlvs-and-sub-tlvs-registry is nearly ready to be called

for potential WG adopti= on.

 

Before the call for ado= ption, we would like to check whether there is IPR on the

document that needs to = be disclosed.

 

Are you aware of any IP= R that applies to draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry?<= /o:p>

If so, has this IPR bee= n disclosed in compliance with IETF IPR rules

(see RFCs 3979, 4879, 3= 669 and 5378 for more details).

 

If you are listed as a = document author or contributor please respond to this email

regardless of whether o= r not you are aware of any relevant IPR. The response needs

to be sent to the MPLS = wg mailing list. The documents will not advance to the next

stage until a response = has been received from each author and contributor.=

 

If you are on the MPLS = WG email list but are not listed as an author or

contributor, then pleas= e explicitly respond only if you are aware of any

IPR that has not yet be= en disclosed in conformance with IETF rules.

 

Thanks, Ross=

(as MPLS WG co-chair)

 

 

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255B81B31szxeml558mbschi_-- From rcallon@juniper.net Sun May 5 19:55:33 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B85EC21F8900 for ; Sun, 5 May 2013 19:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.07 X-Spam-Level: X-Spam-Status: No, score=-100.07 tagged_above=-999 required=5 tests=[AWL=1.396, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5jfNtgsWX4G for ; Sun, 5 May 2013 19:55:27 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by ietfa.amsl.com (Postfix) with ESMTP id E07E221F877B for ; Sun, 5 May 2013 19:55:26 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKUYcbngbA1mrZX0iEeMM8+1vkkTTrhgB0@postini.com; Sun, 05 May 2013 19:55:26 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sun, 5 May 2013 19:53:27 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Sun, 5 May 2013 19:53:27 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.188) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sun, 5 May 2013 20:04:05 -0700 Received: from mail50-co1-R.bigfish.com (10.243.78.243) by CO1EHSOBE034.bigfish.com (10.243.66.99) with Microsoft SMTP Server id 14.1.225.23; Mon, 6 May 2013 02:53:19 +0000 Received: from mail50-co1 (localhost [127.0.0.1]) by mail50-co1-R.bigfish.com (Postfix) with ESMTP id 8C0FA5002B4 for ; Mon, 6 May 2013 02:53:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); (null); H:CH1PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -20 X-BigFish: PS-20(zzc85fhzz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz1033IL18c673h182cceh8275dhz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1155h) Received: from mail50-co1 (localhost.localdomain [127.0.0.1]) by mail50-co1 (MessageSwitch) id 1367808797675753_32091; Mon, 6 May 2013 02:53:17 +0000 (UTC) Received: from CO1EHSMHS008.bigfish.com (unknown [10.243.78.230]) by mail50-co1.bigfish.com (Postfix) with ESMTP id 981988C0089; Mon, 6 May 2013 02:53:17 +0000 (UTC) Received: from CH1PRD0510HT002.namprd05.prod.outlook.com (157.56.244.213) by CO1EHSMHS008.bigfish.com (10.243.66.18) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 6 May 2013 02:53:17 +0000 Received: from CH1PRD0510MB355.namprd05.prod.outlook.com ([169.254.2.207]) by CH1PRD0510HT002.namprd05.prod.outlook.com ([10.255.150.37]) with mapi id 14.16.0305.001; Mon, 6 May 2013 02:53:16 +0000 From: Ross Callon To: "mpls@ietf.org" , "draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org" Thread-Topic: Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 Thread-Index: Ac5KBNrRqy5GgTuxR1iRJSatXBuqdw== Date: Mon, 6 May 2013 02:53:16 +0000 Message-ID: <62CCD4C52ACDAD4481149BD5D8A72FD316C3ED09@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: multipart/alternative; boundary="_000_62CCD4C52ACDAD4481149BD5D8A72FD316C3ED09CH1PRD0510MB355_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ALCATEL-LUCENT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 02:55:33 -0000 --_000_62CCD4C52ACDAD4481149BD5D8A72FD316C3ED09CH1PRD0510MB355_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Working group, this is to start a "two week" poll on adopting draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end May 20th, 2013. Ross (as mpls wg co-chair) --_000_62CCD4C52ACDAD4481149BD5D8A72FD316C3ED09CH1PRD0510MB355_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Working group,
 
this is to start a "two week" poll on adopting
draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02
as an MPLS working group document.
 
Please send your comments (support/not support) to the mpls working
group mailing list (mpls@ietf.org).
 
This poll will end May 20th, 2013.
 
Ross
(as mpls wg co-chair)
&nbs= p;
&nbs= p;
 --_000_62CCD4C52ACDAD4481149BD5D8A72FD316C3ED09CH1PRD0510MB355_-- From loa@pi.nu Mon May 6 04:03:21 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D88521F8FA5 for ; Mon, 6 May 2013 04:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.182 X-Spam-Level: X-Spam-Status: No, score=-100.182 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7hVLFOGaB8I for ; Mon, 6 May 2013 04:03:15 -0700 (PDT) Received: from pipi.pi.nu (unknown [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7494321F9029 for ; Mon, 6 May 2013 04:03:15 -0700 (PDT) Received: from [192.168.1.104] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id C241A1802D26; Mon, 6 May 2013 13:03:13 +0200 (CEST) Message-ID: <51878DF2.4000205@pi.nu> Date: Mon, 06 May 2013 13:03:14 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , Martin Vigoureux , Adrian Farrel , "draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp@tools.ietf.org" References: <516952F8.4090407@pi.nu> In-Reply-To: <516952F8.4090407@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Closed - working group last call on draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 11:03:21 -0000 Working Group, This working group last call is closed! We have had no comments, but because of the good discussions we had on this draft earlier we interpret this as support for progressing the draft. /Loa for the wg-chairs On 2013-04-13 14:43, Loa Andersson wrote: > Working Group, > > this is to start a two week Working Group last call on > draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp-01.txt. > > Please send your comments to the mpls working group > mailing list (mpls@ietf.org). > > Please send both technical comments, and if you are happy > with the document as is also indications of support. > > There are no IPR claims against this draft. > > The co-authors have earlier stated that they are not aware > of any IPRs applicable to this draft. > > If anyone else in the working group are aware of IPRs claims against > this draft, the time to disclose that is now. > > This working group last call will end on April 29, 2013. > > /Loa > for the wg co-chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From loa@pi.nu Mon May 6 04:09:32 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8504D21F90D2 for ; Mon, 6 May 2013 04:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.398 X-Spam-Level: X-Spam-Status: No, score=-100.398 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LSjaYN+IEwGU for ; Mon, 6 May 2013 04:09:26 -0700 (PDT) Received: from pipi.pi.nu (unknown [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id A26AB21F90C1 for ; Mon, 6 May 2013 04:09:26 -0700 (PDT) Received: from [192.168.1.104] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id CFA0A1802D26; Mon, 6 May 2013 13:09:25 +0200 (CEST) Message-ID: <51878F66.6040206@pi.nu> Date: Mon, 06 May 2013 13:09:26 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "" , draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp@tools.ietf.org, Martin Vigoureux Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Implementations of draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 11:09:32 -0000 Working Group, draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp is through working group last call. The working group chairs we will request publication of the document as an RFC on the Standards track. As part of the shepherd write-up, that is sent as part of the request for publication to the IESG, we need to know about existing or intended implementations ofdraft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp. Please send mails to the mpls wg mailing list (mpls@ietf.org) or the working group chairs to inform us about implementations. /Loa (as wg co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From prvs=18387949c2=daniele.ceccarelli@ericsson.com Mon May 6 07:19:15 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E908121F9223 for ; Mon, 6 May 2013 07:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bxxqf1RgN9Qa for ; Mon, 6 May 2013 07:19:09 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id E6C9F21F9195 for ; Mon, 6 May 2013 07:19:05 -0700 (PDT) X-AuditID: c1b4fb30-b7f3a6d0000007a4-04-5187bbd38a76 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 0D.4F.01956.3DBB7815; Mon, 6 May 2013 16:18:59 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.55]) by ESESSHC017.ericsson.se ([153.88.183.69]) with mapi id 14.02.0328.009; Mon, 6 May 2013 16:18:59 +0200 From: Daniele Ceccarelli To: "rcallon@juniper.net" Thread-Topic: Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 Thread-Index: AQHOSlSBL3HNnDK6BUS9KekwODCguZj4NFaQ Date: Mon, 6 May 2013 14:18:58 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE480C3A7F@ESESSMB301.ericsson.se> References: <62CCD4C52ACDAD4481149BD5D8A72FD316C3ED09@CH1PRD0510MB355.namprd05.prod.outlook.com> <5187A0B5.40909@pi.nu> In-Reply-To: <5187A0B5.40909@pi.nu> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyM+Jvre7l3e2BBo/vy1t0H6+0uLPrC6vF 90tLWCxuLV3JavF3xRUWB1aP1md7WT2WLPnJ5HG96Sq7x5fLn9kCWKK4bZISS8qCM9Pz9O0S uDN2PuxiKtjMUXHk3Ty2BsbV7F2MnBwSAiYS7VOPQdliEhfurWfrYuTiEBI4zCjRcPwxC4Sz iFHi79v1TF2MHBxsAlYSTw75gDSICOhLLDmwjR2khllgOZNE+892JpCEsECsxJlNh9lA6kUE 4iS+PDCHqDeSuP2kkwXEZhFQkTj+fgPYYl4Bb4mHezaAxYUEKiXWnepnA7E5BZQllrd+ZQSx GQVkJSbsXgRmMwuIS9x6Mp8J4mgBiSV7zjND2KISLx//Y4WwFSV2nm1nhqjXkViw+xMbhK0t sWzha2aIvYISJ2c+YZnAKDYLydhZSFpmIWmZhaRlASPLKkb23MTMnPRy802MwKg6uOW3wQ7G TffFDjFKc7AoifMmczUGCgmkJ5akZqemFqQWxReV5qQWH2Jk4uAEEVxSDYzBBS3rXiT0ndsk oWt7cD/zt8vTdfrOVVcoLHK32OVX8VmOsfXDogcVp94kB4ltn1G8ROPNxs9T2jzyOvWjhWOc t8pWMv1cU2XiUROdsLjNeen8oANPDM4ECTHMSLeyj/r7o3dDlkhPrI/Rtz9+s3cEc/0N/3Pw kfAt13Xdn2cd3ZvlGTe7okSJpTgj0VCLuag4EQDfKdm8fQIAAA== Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org" Subject: Re: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 14:19:16 -0000 Yes/Support BR Daniele >-------- Original Message -------- >Subject: Poll for WG adoption for >draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 >Resent-To: loa@mail01.huawei.com, mach.chen@huawei.com, >tomsecurity@network-engineer.co.uk, swallow@cisco.com,=20 >loa@pi.nu, rcallon@juniper.net, >Date: Mon, 6 May 2013 02:53:16 +0000 >From: Ross Callon >To: mpls@ietf.org , >draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org > >CC: mpls-chairs@tools.ietf.org , Martin >Vigoureux > > > >Working group, >this is to start a "two week" poll on adopting >draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 >as an MPLS working group document. >Please send your comments (support/not support) to the mpls=20 >working group mailing list (_mpls@ietf.org_ ). >This poll will end May 20th, 2013. >Ross >(as mpls wg co-chair) > > >= From internet-drafts@ietf.org Mon May 6 08:57:10 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB51921F8C55; Mon, 6 May 2013 08:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.478 X-Spam-Level: X-Spam-Status: No, score=-102.478 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gu3FZN8qVEYH; Mon, 6 May 2013 08:57:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D6321F9239; Mon, 6 May 2013 08:56:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p5 Message-ID: <20130506155635.18519.91797.idtracker@ietfa.amsl.com> Date: Mon, 06 May 2013 08:56:35 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-multi-topology-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 May 2013 15:57:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : LDP Extensions for Multi Topology Routing Author(s) : Quintin Zhao Luyuan Fang Chao Zhou Lianyuan Li Kamran Raza Filename : draft-ietf-mpls-ldp-multi-topology-07.txt Pages : 18 Date : 2013-05-06 Abstract: Multi-Topology (MT) routing is supported in IP networks with the use of MT aware IGP protocols. In order to provide MT routing within Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) networks new extensions are required. This document updates RFC4379. This document describes the LDP protocol extensions required to support MT routing in an MPLS environment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-multi-topology There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-ldp-multi-topology-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Pontus.Skoldstrom@acreo.se Tue May 7 05:42:14 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 698E321F8F07 for ; Tue, 7 May 2013 05:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.748 X-Spam-Level: X-Spam-Status: No, score=-0.748 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IP5AgSjXf730 for ; Tue, 7 May 2013 05:42:01 -0700 (PDT) Received: from smtp9-outgoing.stejtech.net (smtp9.stejtech.net [IPv6:2001:16d8:c001:2073::aaa9]) by ietfa.amsl.com (Postfix) with ESMTP id 2541C21F8EFC for ; Tue, 7 May 2013 05:42:00 -0700 (PDT) Received: from mail.acreo.se (unknown [217.151.196.13]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp9.stejtech.net (Postfix) with ESMTPSA id 3C7F2134A7C8 for ; Tue, 7 May 2013 14:41:57 +0200 (CEST) Received: from ACREOEXC02.ad.acreo.se ([::1]) by ACREOEXC02.ad.acreo.se ([::1]) with mapi id 14.02.0328.009; Tue, 7 May 2013 14:41:57 +0200 From: =?Windows-1252?Q?Pontus_Sk=F6ldstr=F6m?= To: "mpls@ietf.org" Thread-Topic: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 Thread-Index: Ac5KBNrRqy5GgTuxR1iRJSatXBuqdwBG1ncQ Date: Tue, 7 May 2013 12:41:56 +0000 Message-ID: <2D8B43480583CF47B78E7F01B983EF8006A4C1@ACREOEXC02.ad.acreo.se> References: <62CCD4C52ACDAD4481149BD5D8A72FD316C3ED09@CH1PRD0510MB355.namprd05.prod.outlook.com> In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316C3ED09@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: en-US, sv-SE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [217.151.207.19] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 12:42:14 -0000 support Pontus Sk=F6ldstr=F6m, M.Sc. Research Scientist Netlab - Networking and Transmission Laboratory +46 8 632 7731 pontus.skoldstrom@acreo.se Acreo AB =96 Part of Swedish ICT Electrum 236, 164 40 Kista, Sweden www.acreo.se ________________________________________ From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] on behalf of Ross Callo= n [rcallon@juniper.net] Sent: Monday, May 06, 2013 04:53 To: mpls@ietf.org; draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools= .ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-s= ub-tlvs-registry-02 Working group, this is to start a "two week" poll on adopting draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end May 20th, 2013. Ross (as mpls wg co-chair) From lucy.yong@huawei.com Tue May 7 08:37:29 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8B521F8F32 for ; Tue, 7 May 2013 08:37:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a8OOS5rGBcnO for ; Tue, 7 May 2013 08:37:24 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 040E421F84D9 for ; Tue, 7 May 2013 08:37:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARD39781; Tue, 07 May 2013 15:37:20 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 7 May 2013 16:37:08 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 7 May 2013 16:37:16 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.204]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Tue, 7 May 2013 08:37:09 -0700 From: Lucy yong To: Ross Callon , "mpls@ietf.org" , "draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org" Thread-Topic: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 Thread-Index: Ac5KBNrRqy5GgTuxR1iRJSatXBuqdwBM9whw Date: Tue, 7 May 2013 15:37:09 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D45259899@dfweml509-mbx.china.huawei.com> References: <62CCD4C52ACDAD4481149BD5D8A72FD316C3ED09@CH1PRD0510MB355.namprd05.prod.outlook.com> In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316C3ED09@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.139.211] Content-Type: multipart/alternative; boundary="_000_2691CE0099834E4A9C5044EEC662BB9D45259899dfweml509mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 15:37:29 -0000 --_000_2691CE0099834E4A9C5044EEC662BB9D45259899dfweml509mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Support! Cheers, Lucy From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ros= s Callon Sent: Sunday, May 05, 2013 9:53 PM To: mpls@ietf.org; draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools= .ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-s= ub-tlvs-registry-02 Working group, this is to start a "two week" poll on adopting draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end May 20th, 2013. Ross (as mpls wg co-chair) --_000_2691CE0099834E4A9C5044EEC662BB9D45259899dfweml509mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Support!

Cheers,=

Lucy

 <= /p>

From: mpls-bou= nces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Sunday, May 05, 2013 9:53 PM
To: mpls@ietf.org; draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registr= y@tools.ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlv= s-and-sub-tlvs-registry-02

 

Working group,

 

this is to start a "two week" poll on adopting

draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02

as an MPLS working group document.

 

Please send your comments (support/not support) to the mpls working<= /o:p>

group mailing list (mpls@ietf.org).<= o:p>

 

This poll will end May 20th, 2013.

 

Ross

(as mpls wg co-chair)

 

 

--_000_2691CE0099834E4A9C5044EEC662BB9D45259899dfweml509mbxchi_-- From adrian@olddog.co.uk Tue May 7 10:08:45 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66CDD21F93DC; Tue, 7 May 2013 10:08:45 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TY6zBs4I7YKJ; Tue, 7 May 2013 10:08:40 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 7552F21F93B7; Tue, 7 May 2013 10:08:40 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r47H8d5H018460; Tue, 7 May 2013 18:08:39 +0100 Received: from 950129200 (no-reverse-dns.mlnet.ie [31.216.236.149] (may be forged)) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r47H8bOT018445 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 7 May 2013 18:08:37 +0100 From: "Adrian Farrel" To: Date: Tue, 7 May 2013 18:08:34 +0100 Message-ID: <002a01ce4b45$82e38ae0$88aaa0a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5LRX560irUVDlgRIKUWSY/7OcnkA== Content-Language: en-gb Subject: [mpls] Retiring ACH TLVs X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 17:08:45 -0000 Hi, ACH TLVs keep popping up and causing Stewart and me trouble. Mainly it = is about explaining why no-one actually wants to use them (i.e., when = each new ACH Type is defined and has a "No TLVs" written for it, we get = asked "why not?"). It seems to us that ACH TLVs are an idea that has been rejected. = Initially we thought they might be used (especially for identifiers), = but there seems to be good opinion that handling generic TLVs would be a = pain. Since I was heavily responsible for insisting that ACH TLVs were = included in RFC 5586, it seems reasonable that I do the work to fix it. The I-D below retires ACH TLVs and handles the necessary registry = changes. Note, of course, that structured data are still possible within = individual ACHs if the protocol spec for an individual ACH decides to = have them. We're directing this work to the MPLS working group because that is = where 5586 was written. I have BCC'ed PWE3, L2VPN, and BFD for = information.=20 Thanks for any comments. As humble WG contributors we would be enthusiastic to see early WG = adoption and last call :-) Thanks, Adrian > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: 07 May 2013 17:33 > To: Adrian Farrel; Stewart Bryant > Subject: New Version Notification for = draft-farbryantrel-mpls-retire-ach-tlv- > 00.txt >=20 >=20 > A new version of I-D, draft-farbryantrel-mpls-retire-ach-tlv-00.txt > has been successfully submitted by Adrian Farrel and posted to the > IETF repository. >=20 > Filename: draft-farbryantrel-mpls-retire-ach-tlv > Revision: 00 > Title: Retiring TLVs from the Associated Channel Header of the MPLS > Generic Associated Channel > Creation date: 2013-05-07 > Group: Individual Submission > Number of pages: 4 > URL: = http://www.ietf.org/internet-drafts/draft-farbryantrel-mpls-retire- > ach-tlv-00.txt > Status: = http://datatracker.ietf.org/doc/draft-farbryantrel-mpls-retire-ach-tlv > Htmlized: = http://tools.ietf.org/html/draft-farbryantrel-mpls-retire-ach-tlv-00 >=20 >=20 > Abstract: > The MPLS Generic Associated Channel (G-ACh) is a generalization of > the applicability of the Pseudowire (PW) Associated Channel Header > (ACH). RFC 5586 defines the concept of Type-Length-Variable (TLV) > constructs that can be carried in messages on the G-ACh by placing > them in the ACH. >=20 > No Associated Channel Type yet defined uses a TLV. Furthermore, it > is believed that handling TLVs in hardware introduces significant > problems to the fast-path, and since G-ACh messages are intended to > be processed substantially in hardware, the use of TLVs in > undesirable. >=20 > This document updates RFC 5586 by retiring ACH TLVs and removing = the > associated registry. >=20 >=20 >=20 >=20 > The IETF Secretariat From adrian@olddog.co.uk Tue May 7 10:09:26 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44FEE21F93B3 for ; Tue, 7 May 2013 10:09: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1pG6Ol3GalBH for ; Tue, 7 May 2013 10:09:20 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCDB21F938E for ; Tue, 7 May 2013 10:09:20 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r47H9I4E019300 for ; Tue, 7 May 2013 18:09:18 +0100 Received: from 950129200 (no-reverse-dns.mlnet.ie [31.216.236.149] (may be forged)) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r47H9Hb9019286 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 7 May 2013 18:09:18 +0100 From: "Adrian Farrel" To: Date: Tue, 7 May 2013 18:09:15 +0100 Message-ID: <002b01ce4b45$9aa7adf0$cff709d0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5LRZkRK4o4TD4VRgSo1PyJxnanEw== Content-Language: en-gb Subject: [mpls] No known IPR on draft-farbryantrel-mpls-retire-ach-tlv-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 17:09:26 -0000 Hi, Just to note that I am unaware of any IPR related to this new I-D. Thanks, Adrian From ningso@yahoo.com Tue May 7 12:06:19 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90FC221F901F for ; Tue, 7 May 2013 12:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.509 X-Spam-Level: X-Spam-Status: No, score=-0.509 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Mg0OIAxuMlP for ; Tue, 7 May 2013 12:06:14 -0700 (PDT) Received: from nm29-vm1.bullet.mail.ne1.yahoo.com (nm29-vm1.bullet.mail.ne1.yahoo.com [98.138.90.63]) by ietfa.amsl.com (Postfix) with ESMTP id 4412E21F8EAF for ; Tue, 7 May 2013 12:06:14 -0700 (PDT) Received: from [98.138.226.180] by nm29.bullet.mail.ne1.yahoo.com with NNFMP; 07 May 2013 19:06:13 -0000 Received: from [98.138.89.174] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 07 May 2013 19:06:13 -0000 Received: from [127.0.0.1] by omp1030.mail.ne1.yahoo.com with NNFMP; 07 May 2013 19:06:13 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 596056.41825.bm@omp1030.mail.ne1.yahoo.com Received: (qmail 27843 invoked by uid 60001); 7 May 2013 19:06:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1367953573; bh=iqgmKKg1G5SvEl1M3QSDD0jepY5C4pgpm2JlYMzyb/0=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=D3RwFgYx0r/9Uw/uSp2f25PDLF5mpFJLcEU+wZcnYL0MYj3tpEkO6msZMYNMLmd2MSF2rFilyS1+B/N34vpIY/qF9ANRy2+gKTjpFw/zP+v4groZVZ4HkQ7MVbUUQEyagk7W8+6wd4i6H59o659yTHSS2vV6xx5n3scrNvsqEXQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=IJJAoGCkvhLJ9YBOrG4m+xdRW0ojK4AKAz467w8pphe7Y5zRYqGntRJU12jP9ny0T+ddHikr9HjJIcUx6iggd+uQLKolT268YDGspNIil5CYfhtlGT7ekLLGslzyjiRoAWHWiKBjYpw0ouCuW5PQt6K1VTX9QBk+z7ZKUibh9JM=; X-YMail-OSG: 7fFlRbYVM1nZHe_a6X2BLddjoiBd15hjjgDeVJc6kSu6CEl ZKus0lVi5uJWP0hDycwNZQox4GTH_S2_4IsM.3INa90FoP.9ymyMq1V8JXrv qwEX2nUTLsTsA.RYDnJmA.VCoNG812U2hvPCT9w1x4hc7BykjAuqH5Nt0U6k J.MwojKLsOgzCGZBU9bnWJ.Y9eh8hW73IFvDKaBdDvbxLe2zSXXNw25Rgj.E SOeaeLYsqYXtwri4a5f_RySrztmSybwcpBKXpIKTQky2S..A2KZoHojG8v0o NXJykZGTlQVlAjDYnL7atIW3EjfjBLAlQxDchEjwJDsgWGqll55xhRWmqUfy sELQsJGkOE8gcnfR92zY7T4na3laDDbr_l0RgBsb7a.vSRGO8OD3E0ncLh5A lOX95CGtKQiaNydom92O36a8ZHV3OcOLdeu5rpbwx40O3zzvw0mrj9ftDYVH u7jMYvnCh8lJRFeqOe5N6.BQGgauAQyw2MfF7NmW4ZpSxZ_G9iS1hSRU6W.M _q8FFwwC6.jWHh_tnWloqpPvkXIrevLA8P.RIjM7sWxdsitX4Ed2oj4oqQvB W7AsNl08xAW5W9_YbR5jCkheisLbI7jVIcpKj Received: from [173.57.105.214] by web84502.mail.ne1.yahoo.com via HTTP; Tue, 07 May 2013 12:06:13 PDT X-Rocket-MIMEInfo: 002.001, CisxCgpOaW5nIFNvCgoKCgoKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQoKTWVzc2FnZTogMQpEYXRlOiBUdWUsIDcgTWF5IDIwMTMgMTI6NDE6NTYgKzAwMDAKRnJvbTogUG9udHVzIFNrP2xkc3RyP20gPFBvbnR1cy5Ta29sZHN0cm9tQGFjcmVvLnNlPgpUbzogIm1wbHNAaWV0Zi5vcmciIDxtcGxzQGlldGYub3JnPgpTdWJqZWN0OiBSZTogW21wbHNdIFBvbGwgZm9yIFdHIGFkb3B0aW9uIGZvcgrCoMKgwqAgZHJhZnQtcGFjLW0BMAEBAQE- X-Mailer: YahooMailWebService/0.8.141.536 References: Message-ID: <1367953573.27005.YahooMailNeo@web84502.mail.ne1.yahoo.com> Date: Tue, 7 May 2013 12:06:13 -0700 (PDT) From: Ning So To: "mpls@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="1508702382-1003055146-1367953573=:27005" Subject: Re: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Ning So List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 19:06:19 -0000 --1508702382-1003055146-1367953573=:27005 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable =0A+1=0A=0ANing So=0A=0A=0A=0A=0A=0A---------------------------------------= -------------------------------=0A=0AMessage: 1=0ADate: Tue, 7 May 2013 12:= 41:56 +0000=0AFrom: Pontus Sk?ldstr?m =0ATo: "m= pls@ietf.org" =0ASubject: Re: [mpls] Poll for WG adoption fo= r=0A=A0=A0=A0 draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02=0AMessa= ge-ID:=0A=A0=A0=A0 <2D8B43480583CF47B78E7F01B983EF8006A4C1@ACREOEXC02.ad.ac= reo.se>=0AContent-Type: text/plain; charset=3D"Windows-1252"=0A=0Asupport= =0A=0A=0APontus Sk?ldstr?m, M.Sc.=0AResearch Scientist=0ANetlab - Networkin= g and Transmission Laboratory=0A+46 8 632 7731=0Apontus.skoldstrom@acreo.se= =0A=0AAcreo AB ? Part of Swedish ICT=0AElectrum 236, 164 40 Kista, Sweden= =0Awww.acreo.se=0A________________________________________=0AFrom: mpls-bou= nces@ietf.org [mpls-bounces@ietf.org] on behalf of Ross Callon [rcallon@jun= iper.net]=0ASent: Monday, May 06, 2013 04:53=0ATo: mpls@ietf.org; draft-pac= -mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org=0ACc: mpls-chairs@= tools.ietf.org=0ASubject: [mpls] Poll for WG adoption for draft-pac-mpls-ls= p-ping-tlvs-and-sub-tlvs-registry-02=0A=0AWorking group,=0A=0Athis is to st= art a "two week" poll on adopting=0Adraft-pac-mpls-lsp-ping-tlvs-and-sub-tl= vs-registry-02=0Aas an MPLS working group document.=0A=0APlease send your c= omments (support/not support) to the mpls working=0Agroup mailing list (mpl= s@ietf.org).=0A=0AThis poll will end May 20th, 2013.= =0A=0ARoss=0A(as mpls wg co-chair)=0A=0A=0A=0A=0A--------------------------= ----=0A=0AMessage: 2=0ADate: Tue, 7 May 2013 15:37:09 +0000=0AFrom: Lucy yo= ng =0ATo: Ross Callon , "mpls@ie= tf.org"=0A=A0=A0=A0 ,=0A=A0=A0=A0 "draft-pac-mpls-lsp-ping-t= lvs-and-sub-tlvs-registry@tools.ietf.org"=0A=A0=A0=A0 =0ACc: "mpls-chairs@tools.iet= f.org" =0ASubject: Re: [mpls] Poll for WG adopt= ion for=0A=A0=A0=A0 draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02= =0AMessage-ID:=0A=A0=A0=A0 <2691CE0099834E4A9C5044EEC662BB9D45259899@dfweml= 509-mbx.china.huawei.com>=0A=A0=A0=A0 =0AContent-Type: text/plain; charset= =3D"us-ascii"=0A=0ASupport!=0ACheers,=0ALucy=0A=0AFrom: mpls-bounces@ietf.o= rg [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon=0ASent: Sunday, = May 05, 2013 9:53 PM=0ATo: mpls@ietf.org; draft-pac-mpls-lsp-ping-tlvs-and-= sub-tlvs-registry@tools.ietf.org=0ACc: mpls-chairs@tools.ietf.org=0ASubject= : [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs= -registry-02=0A=0AWorking group,=0A=0Athis is to start a "two week" poll on= adopting=0Adraft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02=0Aas an M= PLS working group document.=0A=0APlease send your comments (support/not sup= port) to the mpls working=0Agroup mailing list (mpls@ietf.org).=0A=0AThis poll will end May 20th, 2013.=0A=0ARoss=0A(as mpls wg = co-chair)=0A=0A=0A-------------- next part --------------=0AAn HTML attachm= ent was scrubbed...=0AURL: =0A=0A---=0A --1508702382-1003055146-1367953573=:27005 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

+1

Ning So




-----------------------------------------------------= -----------------

Message: 1
Date: Tue, 7 May 2013 12:41:56 +0000=
From: Pontus Sk?ldstr?m <Pontus.Skoldstrom@acreo.se= >
To: "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls] Poll for= WG adoption for
    draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02
Message-ID:
&n= bsp;   <2D8B43480583CF47B78E7F01B983EF8006A4C1@ACR= EOEXC02.ad.acreo.se>
Content-Type: text/plain; charset=3D"Windows= -1252"

support


Pontus Sk?ldstr?m, M.Sc.
Research Scien= tist
Netlab - Networking and Transmission Laboratory
+46 8 632 7731pontus.skoldstrom@acreo.se

Acreo AB ? Part of= Swedish ICT
Electrum 236, 164 40 Kista, Sweden
www.acreo.se
_____= ___________________________________
From: mpls-bounces@ietf.org [mpls-bounces@ietf.org] on behalf= of Ross Callon [rcallon@juniper.net]
Sent: Monday, May 06, 2013 = 04:53
To: mpls@ietf.org; draft-pac-mpls-lsp-ping-tlvs-and= -sub-tlvs-registry@tools.ietf.org
Cc: mpls-chairs@t= ools.ietf.org
Subject: [mpls] Poll for WG adoption for draft-pac-mpl= s-lsp-ping-tlvs-and-sub-tlvs-registry-02

Working group,

this = is to start a "two week" poll on adopting
draft-pac-mpls-lsp-ping-tlvs-a= nd-sub-tlvs-registry-02
as an MPLS working group document.

Please= send your comments (support/not support) to the mpls working
group mailing list (= mpls@ietf= .org<mailto:mpls@ietf.org>).

This poll will end May 20th, 2013.=

Ross
(as mpls wg co-chair)




------------------= ------------

Message: 2
Date: Tue, 7 May 2013 15:37:09 +0000
F= rom: Lucy yong <lucy.yong@huawei.com>
To: Ross Callon <= ;rcallon@juniper.net>, "mpls@ietf.org"
    <mpls@ietf.org= >,
    "draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.= ietf.org"
    <draft-pac-mpls-= lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org>
Cc: "mpls-chairs@tools.ietf.org" <mpls-chairs@t= ools.ietf.org>
Subject: Re: [mpls] Poll for WG adoption for
&n= bsp;   draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02
M= essage-ID:
    <2691CE0099834E4A9C5044EEC662BB9D45259899@dfwe= ml509-mbx.china.huawei.com>
   
Content-Type: = text/plain; charset=3D"us-ascii"

Support!
Cheers,
Lucy

= From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org= ] On Behalf Of Ross Callon
Sent: Sunday, May 05, 2013 9:53 PM
To:= mpls@iet= f.org; draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: [mpls= ] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-regist= ry-02

Working group,

this is to start a "two week" poll on ad= opting
draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02
as an MP= LS working group document.

Please send your comments (support/not su= pport) to the mpls working
group mailing list (mpls@ietf.org<mailto:mpls@ietf.org>).

This poll will end May 20th, 2013.

Ross
(as mpls = wg co-chair)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/mpls/attachments/20130507/f8ba2= 43c/attachment.htm>

---
--1508702382-1003055146-1367953573=:27005-- From alessandro.dalessandro@telecomitalia.it Tue May 7 12:27:02 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918D421F908B for ; Tue, 7 May 2013 12:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.881 X-Spam-Level: X-Spam-Status: No, score=0.881 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3krbbeyAo2Jl for ; Tue, 7 May 2013 12:26:58 -0700 (PDT) Received: from GRFEDG701RM001.telecomitalia.it (grfedg701rm001.telecomitalia.it [217.169.121.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF2E21F905F for ; Tue, 7 May 2013 12:26:57 -0700 (PDT) Received: from TELCAH004RM001.telecomitalia.local (10.19.10.108) by GRFEDG701RM001.telecomitalia.it (10.173.88.20) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 7 May 2013 21:26:56 +0200 Received: from TELMBB002RM001.telecomitalia.local ([169.254.3.100]) by TELCAH004RM001.telecomitalia.local ([10.19.10.108]) with mapi id 14.02.0328.009; Tue, 7 May 2013 21:26:56 +0200 From: D'Alessandro Alessandro Gerardo To: "Eric Osborne (eosborne)" , "mpls@ietf.org" Thread-Topic: PSC: draft-rhd-mpls-tp-psc-priority-00 Thread-Index: Ac47ZD1tB/jb+CaKQqOehjxMIOgzIgP835SQ Date: Tue, 7 May 2013 19:26:55 +0000 Message-ID: <22257C41A415324A984CD03D63344E270A4750F7@TELMBB002RM001.telecomitalia.local> References: <20ECF67871905846A80F77F8F4A2757210150296@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A2757210150296@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.10.81] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Morro Roberto , Allasia Andrea , Nervo Giacolino Subject: [mpls] R: PSC: draft-rhd-mpls-tp-psc-priority-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 19:27:02 -0000 Hi Eric, You wrote "is it appropriate to make this priority swap?" My answer is yes, it shall be done for the reasons explained in liaison 120= 5, bullet 1. You wrote "- what do we need to change? rfc5654? rfc4427? " No I don't believe it is required to change any RFC but RFC 6378 Best regards, Alessandro ------------------------------------------------------------------ Telecom Italia Alessandro Gerardo D'Alessandro Transport Innovation Via Reiss Romoli, 274 - 10148 Torino phone: +39 011 228 5887 mobile: +39 335 766 9607 fax: +39 06 418 639 07 -----Messaggio originale----- Da: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Per conto di Eric = Osborne (eosborne) Inviato: mercoled=EC 17 aprile 2013 14:16 A: mpls@ietf.org Oggetto: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00 This thread is for discussing draft-rhd-mpls-tp-psc-priority-00. In brief,= the draft proposes swapping the priorities between FS and SF-P (see sectio= n 4.3.2 of rfc6378). This proposed swap has a long history, dating back to= when PSC was an ID. For some history, see http://datatracker.ietf.org/liaison/1229/ and http://datatracker.ietf.org/liaison/1234/ The questions that I think are relevant here are: - is it appropriate to make this priority swap? - are there alternative approaches? - what do we need to change? rfc5654? rfc4427? - if we don't make the change, does this expose implementation to problems? - if we do make the change, how do we go about it? but of course any and all discussion is welcome. As with the other threads I'm going to leave my two cents out of this intro= ductory email but I'll chime in when discussion starts. eric _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From gregory.mirsky@ericsson.com Tue May 7 12:32:03 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96FB021F90B3 for ; Tue, 7 May 2013 12:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXIz2QkXyu2g for ; Tue, 7 May 2013 12:31:56 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB3E21F8FF1 for ; Tue, 7 May 2013 12:31:56 -0700 (PDT) X-AuditID: c618062d-b7ff46d000006709-9f-518956ab78d8 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 88.C9.26377.BA659815; Tue, 7 May 2013 21:31:56 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Tue, 7 May 2013 15:31:55 -0400 From: Gregory Mirsky To: "mpls@ietf.org" Thread-Topic: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 Thread-Index: Ac5KBNrRqy5GgTuxR1iRJSatXBuqdwBVJUkg Date: Tue, 7 May 2013 19:31:54 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B49712B@eusaamb103.ericsson.se> References: <62CCD4C52ACDAD4481149BD5D8A72FD316C3ED09@CH1PRD0510MB355.namprd05.prod.outlook.com> In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316C3ED09@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B49712Beusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyuXRPrO6asM5Ag0cLRCxuLV3J6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujPeTrAsey1Ss2zmVrYHxhGQXIyeHhICJRN/bp4wQtpjEhXvr 2boYuTiEBI4ySpw6s4YRwlnGKLHlcSdYFZuAkcSLjT3sILaIgLLEkYndrF2MHBzCAikSTW8k IMKpEkeuLYYqMZKYNm8pM4jNIqAicfHYXrByXgFfiY0PXUHCQgIJEhvXLwMr5xRIlFh25AgL iM0IdM/3U2uYQGxmAXGJW0/mM0HcKSCxZM95ZghbVOLl43+sELayxJIn+1kg6vMlLi1YCGbz CghKnJz5hGUCo8gsJKNmISmbhaQMIq4jsWD3JzYIW1ti2cLXzDD2mQOPmZDFFzCyr2LkKC1O LctNNzLYxAiMkmMSbLo7GPe8tDzEKM3BoiTOG8XVGCgkkJ5YkpqdmlqQWhRfVJqTWnyIkYmD U6qBkXGf/W6ONNbri2btFleaH/omqnOjY5JvbfUis5dbdO8mT973fdYyuVaDjdsP3snXnS/X KZFrKXyLy5xNil+U2Tfg2r3EyaZbq/9ZFYol9gdyr6702XtUZN2eExtmf+Kx2WXAL7dmntx+ tWjjXoc0uY9sMgWLbP+Hcm9TNTg26c+ByR5tSy09lFiKMxINtZiLihMBwwOnwmACAAA= Subject: Re: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 19:32:03 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B49712Beusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable support Regards, Greg ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ros= s Callon Sent: Sunday, May 05, 2013 7:53 PM To: mpls@ietf.org; draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools= .ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-s= ub-tlvs-registry-02 Working group, this is to start a "two week" poll on adopting draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end May 20th, 2013. Ross (as mpls wg co-chair) --_000_7347100B5761DC41A166AC17F22DF1121B49712Beusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
support
 
    Regards,
     &nb= sp;  Greg

From: mpls-bounces@ietf.org [mailto= :mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Sunday, May 05, 2013 7:53 PM
To: mpls@ietf.org; draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registr= y@tools.ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlv= s-and-sub-tlvs-registry-02

Working group,
 
this is to start a "two week" poll on adopting
draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02
as an MPLS working group document.
 
Please send your comments (support/not support) to the mpls working
group mailing list (mpls@ietf.org).
 
This poll will end May 20th, 2013.
 
Ross
(as mpls wg co-chair)
 
 
 --_000_7347100B5761DC41A166AC17F22DF1121B49712Beusaamb103erics_-- From internet-drafts@ietf.org Tue May 7 12:56:00 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7629A21F8618; Tue, 7 May 2013 12:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.351 X-Spam-Level: X-Spam-Status: No, score=-102.351 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GasZdwriT26t; Tue, 7 May 2013 12:55:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CAD821F866E; Tue, 7 May 2013 12:55:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p7 Message-ID: <20130507195558.5161.78009.idtracker@ietfa.amsl.com> Date: Tue, 07 May 2013 12:55:58 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-lim-mpls-proxy-lsp-ping-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 19:56:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Proxy MPLS Echo Request Author(s) : George Swallow Vanson Lim Sam Aldrin Filename : draft-lim-mpls-proxy-lsp-ping-02.txt Pages : 24 Date : 2013-05-07 Abstract: This document defines a means of remotely initiating Multiprotocol 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 leaf/ root tracing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-lim-mpls-proxy-lsp-ping There's also a htmlized version available at: http://tools.ietf.org/html/draft-lim-mpls-proxy-lsp-ping-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-lim-mpls-proxy-lsp-ping-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From stbryant@cisco.com Tue May 7 14:27:03 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B049021F905F for ; Tue, 7 May 2013 14:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LGiGqHuSRL8 for ; Tue, 7 May 2013 14:26:59 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id DD26121F8F33 for ; Tue, 7 May 2013 14:26:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=425; q=dns/txt; s=iport; t=1367962019; x=1369171619; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qNJeEP+XXBrQSwj1PgMcmMpJn43jFYegdgI1nr/iXLE=; b=P9tFJoXQSNFfOZafHWt1gbAk4v+4PFQEPimugSMLLIUixwYpFIiolIDq a+uMgJJzmpJQJsj5Wzm2VjBzBeIzrpXFJR3kfJAljMVNvMibf+DOtolf5 pxhk+OcwavJqMkteXJQi1F06HiHhCMiCqWIa3dia4iVbM94q81ZGbp4xo Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAOttiVGtJV2c/2dsb2JhbABQgwc3gnW8FYEKFnSCHwEBAQMBAQEBNzQLBQsCAQg2ECcLJQEBBA4FiAYGDLJyjnwEjzMHgnRhA5cvkTeDDg X-IronPort-AV: E=Sophos;i="4.87,629,1363132800"; d="scan'208";a="207367463" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 07 May 2013 21:26:58 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r47LQwlN028424 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 7 May 2013 21:26:58 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.77]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Tue, 7 May 2013 16:26:58 -0500 From: "Stewart Bryant (stbryant)" To: "" Thread-Topic: [mpls] No known IPR on draft-farbryantrel-mpls-retire-ach-tlv-00.txt Thread-Index: Ac5LRZkRK4o4TD4VRgSo1PyJxnanEwAJAFsY Date: Tue, 7 May 2013 21:26:57 +0000 Message-ID: <06A9DEDB-B193-4CB9-86F9-C040C63C9E11@cisco.com> References: <002b01ce4b45$9aa7adf0$cff709d0$@olddog.co.uk> In-Reply-To: <002b01ce4b45$9aa7adf0$cff709d0$@olddog.co.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] No known IPR on draft-farbryantrel-mpls-retire-ach-tlv-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 21:27:03 -0000 I am not aware of any IPR that would be applicable to this draft. Stewart Sent from my iPad On 7 May 2013, at 18:09, "Adrian Farrel" wrote: > Hi, >=20 > Just to note that I am unaware of any IPR related to this new I-D. >=20 > Thanks, > Adrian >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From alessandro.dalessandro@telecomitalia.it Tue May 7 14:32:54 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54E121F9079 for ; Tue, 7 May 2013 14:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.419 X-Spam-Level: X-Spam-Status: No, score=-0.419 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4JiVkbAKAn0g for ; Tue, 7 May 2013 14:32:50 -0700 (PDT) Received: from GRFEDG701RM001.telecomitalia.it (grfedg701rm001.telecomitalia.it [217.169.121.20]) by ietfa.amsl.com (Postfix) with ESMTP id 34FFA21F905F for ; Tue, 7 May 2013 14:32:49 -0700 (PDT) Received: from TELCAH003RM001.telecomitalia.local (10.19.10.106) by GRFEDG701RM001.telecomitalia.it (10.173.88.20) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 7 May 2013 23:32:39 +0200 Received: from TELMBB002RM001.telecomitalia.local ([169.254.3.100]) by TELCAH003RM001.telecomitalia.local ([10.19.10.106]) with mapi id 14.02.0328.009; Tue, 7 May 2013 23:32:39 +0200 From: D'Alessandro Alessandro Gerardo To: "Eric Osborne (eosborne)" , "mpls@ietf.org" Thread-Topic: PSC: draft-cdh-mpls-tp-psc-non-revertive-00 Thread-Index: Ac47ZsOxMP4Mlxa+RfSrBXzaGXDaFAQAj46A Date: Tue, 7 May 2013 21:32:38 +0000 Message-ID: <22257C41A415324A984CD03D63344E270A4751A0@TELMBB002RM001.telecomitalia.local> References: <20ECF67871905846A80F77F8F4A27572101502D8@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A27572101502D8@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.10.81] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mpls] R: PSC: draft-cdh-mpls-tp-psc-non-revertive-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 May 2013 21:32:54 -0000 Hi Eric, You wrote "- do we need MS-W and the associated state changes?" My answer is yes to preserve current operational practice. I believe the sa= me concept is expressed in the liaison 1205 from ITU-T SG15. You wrote "- if so, is the method proposed in the draft the correct one?" My answer is yes because it is the simplest and safest way to introduce suc= h enhancement being based on an approach that has been proved to work. Best regards, Alessandro ------------------------------------------------------------------ Telecom Italia Alessandro Gerardo D'Alessandro Transport Innovation Via Reiss Romoli, 274 - 10148 Torino phone: +39 011 228 5887 mobile: +39 335 766 9607 fax: +39 06 418 639 07 -----Messaggio originale----- Da: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Per conto di Eric = Osborne (eosborne) Inviato: mercoled=EC 17 aprile 2013 14:32 A: mpls@ietf.org Oggetto: [mpls] PSC: draft-cdh-mpls-tp-psc-non-revertive-00 This thread is for discussing draft-cdh-mpls-tp-psc-non-revertive-00. This= draft adds a MS-W (Manual Switch to Working) command and modifies the PSC = text and state machine to handle this new command. The proposed MS-W comma= nd is of equal priority to the existing MS-P command, and there is text to = handle the simultaneous or sequential occurrence of two equal-priority comm= ands. Relevant questions include: - do we need MS-W and the associated state changes? - PSC currently does not have any commands with equal priority. Should we = employ such a mechanism to address either this issue or future additions to= PSC? - if so, is the method proposed in the draft the correct one? - if not, do we need any additional mechanism to handle the issue this draf= t raises? but of course any and all discussion is welcome. eric _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From xuxiaohu@huawei.com Tue May 7 17:46:19 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29FE411E80D5 for ; Tue, 7 May 2013 17:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.395 X-Spam-Level: X-Spam-Status: No, score=-2.395 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYAN+iqa6C0d for ; Tue, 7 May 2013 17:46:14 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D0C6A21F899E for ; Tue, 7 May 2013 17:46:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASN64881; Wed, 08 May 2013 00:46:11 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 8 May 2013 01:46:04 +0100 Received: from nkgeml405-hub.china.huawei.com (10.98.56.36) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 8 May 2013 01:46:07 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.243]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.01.0323.007; Wed, 8 May 2013 08:46:04 +0800 From: Xuxiaohu To: Ross Callon , "mpls@ietf.org" , "draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org" Thread-Topic: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 Thread-Index: Ac5KBNrRqy5GgTuxR1iRJSatXBuqdwBgID6Q Date: Wed, 8 May 2013 00:46:04 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F66283@NKGEML512-MBS.china.huawei.com> References: <62CCD4C52ACDAD4481149BD5D8A72FD316C3ED09@CH1PRD0510MB355.namprd05.prod.outlook.com> In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316C3ED09@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F66283NKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 00:46:19 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F66283NKGEML512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 U3VwcG9ydC4NCg0KWGlhb2h1DQoNCreivP7IyzogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWls dG86bXBscy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFJvc3MgQ2FsbG9uDQq3osvNyrG85DogMjAx M8TqNdTCNsjVIDEwOjUzDQrK1bz+yMs6IG1wbHNAaWV0Zi5vcmc7IGRyYWZ0LXBhYy1tcGxzLWxz cC1waW5nLXRsdnMtYW5kLXN1Yi10bHZzLXJlZ2lzdHJ5QHRvb2xzLmlldGYub3JnDQqzrcvNOiBt cGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZw0K1vfM4jogW21wbHNdIFBvbGwgZm9yIFdHIGFkb3B0 aW9uIGZvciBkcmFmdC1wYWMtbXBscy1sc3AtcGluZy10bHZzLWFuZC1zdWItdGx2cy1yZWdpc3Ry eS0wMg0KDQpXb3JraW5nIGdyb3VwLA0KDQp0aGlzIGlzIHRvIHN0YXJ0IGEgInR3byB3ZWVrIiBw b2xsIG9uIGFkb3B0aW5nDQpkcmFmdC1wYWMtbXBscy1sc3AtcGluZy10bHZzLWFuZC1zdWItdGx2 cy1yZWdpc3RyeS0wMg0KYXMgYW4gTVBMUyB3b3JraW5nIGdyb3VwIGRvY3VtZW50Lg0KDQpQbGVh c2Ugc2VuZCB5b3VyIGNvbW1lbnRzIChzdXBwb3J0L25vdCBzdXBwb3J0KSB0byB0aGUgbXBscyB3 b3JraW5nDQpncm91cCBtYWlsaW5nIGxpc3QgKG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0 Zi5vcmc+KS4NCg0KVGhpcyBwb2xsIHdpbGwgZW5kIE1heSAyMHRoLCAyMDEzLg0KDQpSb3NzDQoo YXMgbXBscyB3ZyBjby1jaGFpcikNCg0KDQo= --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F66283NKGEML512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Support.

 = ;

Xiaohu

 = ;

=B7=A2=BC=FE=C8=CB: mpls-bounces@ietf.org= [mailto:mpls-bounces@ietf.org] =B4=FA=B1=ED = Ross Callon
=B7=A2=CB=CD= =CA=B1=BC=E4: 2013=C4=EA5=D4=C2<= span lang=3D"EN-US">6=C8=D5 10:53
=CA=D5=BC=FE=C8=CB: mpls@ietf.org; draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@t= ools.ietf.org
=B3=AD=CB=CD: mpls-chairs@tools.ietf.org
=D6=F7=CC=E2: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs= -registry-02

 

Working group,

 

this is to start a "two week" poll on adopting

draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02=

as an MPLS working group document.

 

Please send your comments (support/not support) to the mpl= s working

group mailing list (mpls@= ietf.org).

 

This poll will end May 20th, 2013.

 

Ross

(as mpls wg co-chair)

 

 

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F66283NKGEML512MBSchi_-- From loa@pi.nu Wed May 8 01:56:55 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 775FD21F87B1 for ; Wed, 8 May 2013 01:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnWjNEMkrDOx for ; Wed, 8 May 2013 01:56:49 -0700 (PDT) Received: from pipi.pi.nu (unknown [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7C40521F8F2E for ; Wed, 8 May 2013 01:56:47 -0700 (PDT) Received: from [192.168.1.104] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 2E010180287B; Wed, 8 May 2013 10:56:46 +0200 (CEST) Message-ID: <518A134E.8060907@pi.nu> Date: Wed, 08 May 2013 10:56:46 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "mpls@ietf.org" , "draft-lim-mpls-proxy-lsp-ping@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , Martin Vigoureux Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] IPR poll on draft-lim-mpls-proxy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 08:56:55 -0000 Working Group and authors; The authors of Working Group and authors; The authors of draft-lim-mpls-proxy-lsp-ping has indicated that the draft is ready to be adopted as a working group document. Before we start that poll we need to do an IPR poll on the draft, this mail starts that IPR poll. Are you aware of any IPR that applies to draft-lim-mpls-proxy-lsp-ping? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The documents will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Loa (as MPLS WG co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From jeff.tantsura@ericsson.com Wed May 8 02:41:53 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5783321F8FFB for ; Wed, 8 May 2013 02:41:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K-Z+Xnseajo2 for ; Wed, 8 May 2013 02:41:46 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 84DB321F8956 for ; Wed, 8 May 2013 02:41:46 -0700 (PDT) X-AuditID: c618062d-b7ff46d000006709-b7-518a1dd97cf0 Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 3D.0F.26377.9DD1A815; Wed, 8 May 2013 11:41:45 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0328.009; Wed, 8 May 2013 05:41:44 -0400 From: Jeff Tantsura To: "mpls@ietf.org" Thread-Topic: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 Thread-Index: Ac5KBNrRqy5GgTuxR1iRJSatXBuqdwBVJUkgABdq2IA= Date: Wed, 8 May 2013 09:41:43 +0000 Message-ID: <60DEDD93F5E54B4AB55647B8B6C7483935B546@eusaamb109.ericsson.se> In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B49712B@eusaamb103.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_60DEDD93F5E54B4AB55647B8B6C7483935B546eusaamb109ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrFLMWRmVeSWpSXmKPExsUyuXRPoO5N2a5Ag6UrrCxuLV3J6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujGOXtrAVPJar6Pj8h6mB8Zh0FyMnh4SAiUTr3x8sELaYxIV7 69m6GLk4hASOMkp0HvrPCuEsY5R41n4VrIpNwEDi/7fjYLaIgLLEkYndrCC2sECKxO6nu1kh 4qkSR64tZoewrSR2fXnP2MXIwcEioCLx8ooqSJhXwFui49M+VpAwp4CfRNskB5AwI9AN30+t YQKxmQXEJW49mc8EcZuAxJI955khbFGJl4//gW0SFdCTaDt2hh0iriyx5Ml+FojefIkrnyey QqwSlDg58wnLBEaRWUjGzkJSNgtJGURcR2LB7k9sELa2xLKFr5lh7DMHHkP1Wkucen2AHVnN AkaOVYwcpcWpZbnpRgabGIHxc0yCTXcH456XlocYpTlYlMR5o7gaA4UE0hNLUrNTUwtSi+KL SnNSiw8xMnFwSjUwbvOYP23PeY+6wPeBccsMn+l6v1J+GOi8V/7PV0ExjRdbhE5KN8tNcr3w ceou4aiCCd+NTiZUep6LSPKI+RFo6yDBbnqDd0b1y+V8im+vZmwweb3QXHb16YKXaw83LrG0 EP7+u8L515ff3avvxMqs9uI8KuSSyGgj5nngcvq36pj0rAv5Jss9lFiKMxINtZiLihMBX59H 9m0CAAA= Subject: Re: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 09:41:53 -0000 --_000_60DEDD93F5E54B4AB55647B8B6C7483935B546eusaamb109ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes/support Cheers, Jeff From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of Ross Callon Sent: Sunday, May 05, 2013 7:53 PM To: mpls@ietf.org; draft-pac-mpls-lsp-ping-tlvs-and-s= ub-tlvs-registry@tools.ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-s= ub-tlvs-registry-02 Working group, this is to start a "two week" poll on adopting draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end May 20th, 2013. Ross (as mpls wg co-chair) --_000_60DEDD93F5E54B4AB55647B8B6C7483935B546eusaamb109ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: <38789421E2A2DC4291310E6247E6029C@ericsson.com> Content-Transfer-Encoding: quoted-printable
Yes/support

Cheers,
Jeff

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Sunday, May 05, 2013 7:53 PM
To: mpls@ietf.org; draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org
Cc: mpls-chairs@tools.= ietf.org
Subject: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlv= s-and-sub-tlvs-registry-02

Working group,
 
this is to start a "two week" poll on adopting
draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02
as an MPLS working group document.
 
Please send your comments (support/not support) to the mpls working
group mailing list (mpls@ietf.org).
 
This poll will end May 20th, 2013.
 
Ross
(as mpls wg co-chair)
 
 
 --_000_60DEDD93F5E54B4AB55647B8B6C7483935B546eusaamb109ericsso_-- From wyaacov@gmail.com Wed May 8 03:50:52 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23D8721F85CB for ; Wed, 8 May 2013 03:50:52 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dcs0ieVOyxi7 for ; Wed, 8 May 2013 03:50:51 -0700 (PDT) Received: from mail-wg0-x236.google.com (mail-wg0-x236.google.com [IPv6:2a00:1450:400c:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id 362C221F855A for ; Wed, 8 May 2013 03:50:51 -0700 (PDT) Received: by mail-wg0-f54.google.com with SMTP id x12so1669130wgg.21 for ; Wed, 08 May 2013 03:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=IZb0OWXB3/nhLU9bOovjFv16EpxDqjJeBUNzIvbQR80=; b=M6fVr/wCVJAt1jmwAP4U7w2Sm1Wx7yJ5HLdU1zCzaNH7bSAubsYlchWzkVh6r3OVLg HVv0c5uk/9RaEw6RdTbIHZKwaMm1M9ZsVQ51IAkuwn4GbMmaTJ1ZOg4k7gn4k82WGcmM 0c+uEMXLEDVJpoDT6z9bQL6naHKLUA2VEqeEolCoKAOVNGgJmdjZSa4DYWsDwJnQbtcW Z6QzcfI0lcJvwl8F9UuCpHcmrDYPxiXYwiSa33cbk3S4a5yefGyhTZ+9tnVaXfB2Wy38 F77Cz84Fz0SjtB4teQQYwpNXwDWqrXhJLv40xRY2qKir9quRT9QxUMZTFTuGIt2kTXXc TQYQ== MIME-Version: 1.0 X-Received: by 10.180.212.3 with SMTP id ng3mr9458053wic.22.1368010250327; Wed, 08 May 2013 03:50:50 -0700 (PDT) Received: by 10.194.85.229 with HTTP; Wed, 8 May 2013 03:50:50 -0700 (PDT) In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316C3ED09@CH1PRD0510MB355.namprd05.prod.outlook.com> References: <62CCD4C52ACDAD4481149BD5D8A72FD316C3ED09@CH1PRD0510MB355.namprd05.prod.outlook.com> Date: Wed, 8 May 2013 13:50:50 +0300 Message-ID: From: Yaacov Weingarten To: Ross Callon Content-Type: multipart/alternative; boundary=001a11c356f4051c8a04dc32b516 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org" Subject: Re: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 10:50:52 -0000 --001a11c356f4051c8a04dc32b516 Content-Type: text/plain; charset=ISO-8859-1 Support BR, yaacov On Mon, May 6, 2013 at 5:53 AM, Ross Callon wrote: > Working group, > > this is to start a "two week" poll on adopting > draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 > as an MPLS working group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (*mpls@ietf.org* ). > > This poll will end May 20th, 2013. > > Ross > (as mpls wg co-chair) > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > -- Thanx and BR, yaacov *Still looking for new opportunity* --001a11c356f4051c8a04dc32b516 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Support
=A0
BR,
yaacov<= /div>


On= Mon, May 6, 2013 at 5:53 AM, Ross Callon <rcallon@juniper.net> wrote:
Working group,
=A0
this is to start a "two week" poll on adopting
draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02
as an MPLS working group document.
=A0
Please send your comments (support/not support) to the mpls working
group mailing list (mpls@ietf.org).
=A0
This poll will end May 20th, 2013.
=A0
Ross
(as mpls wg co-chair)
=A0
=A0

_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls




--
Th= anx and BR,
yaacov

Still looking for new op= portunity
--001a11c356f4051c8a04dc32b516-- From aldrin.ietf@gmail.com Wed May 8 08:09:41 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84A4321F8FB6 for ; Wed, 8 May 2013 08:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[AWL=-0.948, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YeKler-whXRP for ; Wed, 8 May 2013 08:09:35 -0700 (PDT) Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) by ietfa.amsl.com (Postfix) with ESMTP id C152D21F8F05 for ; Wed, 8 May 2013 08:09:35 -0700 (PDT) Received: by mail-pd0-f180.google.com with SMTP id t10so1304324pdi.39 for ; Wed, 08 May 2013 08:09:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=TL0uxtul5GOY1ZP7JljBSOtmx3FxuXTdea4htvG1l4o=; b=kmgv8APTme8lbOJLPocU0dr6kYHqc+jLOiJFWwxuQEtUAn4Cwjbu2gDaVgr2Y9qa6p aY3WBPSBWIvRM+NpKnFWHANkgWqGxmK+bFjuV+tu50NQFFrYWtvUD3Prq5JXLhi7ruQz /w7EOcsZvVvOUw16x7zpyxhlgznn2KUBMKSz8kXGTj7vguewti1r96tsREndTba4b1ws ROp3kED0i//+bUPxYTacNiZ/NelJN+wI2uBIDNFuhIxnGvw+C2m7Ohj2w+L5j1Xsb0KO zBaMG4POq4+VOmAFWyBuvgjwB7h+EnotHzemYtmiFvbQ3VFiej1RMKomApJzLMi2NICk 8cnQ== X-Received: by 10.68.164.226 with SMTP id yt2mr7924120pbb.203.1368025775505; Wed, 08 May 2013 08:09:35 -0700 (PDT) Received: from [192.168.1.4] (c-98-248-237-85.hsd1.ca.comcast.net. [98.248.237.85]) by mx.google.com with ESMTPSA id uv1sm1644671pbc.16.2013.05.08.08.09.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 May 2013 08:09:34 -0700 (PDT) References: <518A134E.8060907@pi.nu> Mime-Version: 1.0 (1.0) In-Reply-To: <518A134E.8060907@pi.nu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <60839230-F451-4535-9BAE-34DFCC1B7274@gmail.com> X-Mailer: iPad Mail (10B329) From: Sam Aldrin Date: Wed, 8 May 2013 08:09:35 -0700 To: Loa Andersson Cc: "mpls@ietf.org" , "draft-lim-mpls-proxy-lsp-ping@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-lim-mpls-proxy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 15:09:41 -0000 No IPR that I am aware off. Thanks Sam Sent from my iPad On May 8, 2013, at 1:56 AM, Loa Andersson wrote: > Working Group and authors; >=20 > The authors of Working Group and authors; >=20 > The authors of draft-lim-mpls-proxy-lsp-ping has indicated > that the draft is ready to be adopted as a working group document. >=20 > Before we start that poll we need to do an IPR poll on the draft, this mai= l starts that IPR poll. >=20 > Are you aware of any IPR that applies to draft-lim-mpls-proxy-lsp-ping? >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). >=20 > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The docu= ments will not advance to the next stage until a response > has been received from each author and contributor. >=20 > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. >=20 >=20 > Thanks, Loa > (as MPLS WG co-chair) >=20 > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From loa@pi.nu Wed May 8 08:32:32 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABCA521F9343 for ; Wed, 8 May 2013 08:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQVriQg-1Rfi for ; Wed, 8 May 2013 08:32:26 -0700 (PDT) Received: from pipi.pi.nu (unknown [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id BFC0021F901F for ; Wed, 8 May 2013 08:32:26 -0700 (PDT) Received: from [192.168.1.104] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 71ACE1802D26; Wed, 8 May 2013 17:32:25 +0200 (CEST) Message-ID: <518A7009.9090807@pi.nu> Date: Wed, 08 May 2013 17:32:25 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-tp-temporal-hitless-psm@tools.ietf.org Subject: [mpls] Implementations of draft-ietf-mpls-tp-temporal-hitless-psm X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 15:32:32 -0000 Working Group, draft-ietf-mpls-tp-temporal-hitless-psm is through working group last call and has been updated accoring to the comments. The working group chairs we will request publication of the document as an RFC on the Standards track. As part of the shepherd write-up, that is sent as part of the request for publication to the IESG, we need to know about existing or intended implementations ofdraft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp. Please send mails to the mpls wg mailing list (mpls@ietf.org) or the working group chairs to inform us about implementations. /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From swallow@cisco.com Wed May 8 09:17:39 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DF3221F958B for ; Wed, 8 May 2013 09:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UC-+v6B5REc for ; Wed, 8 May 2013 09:17:34 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD9F21F899E for ; Wed, 8 May 2013 09:17:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1955; q=dns/txt; s=iport; t=1368029854; x=1369239454; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=YE0huoqP9FQxvYuJyvoa84LC/+jUIeN/kUVthtn479Q=; b=Df1o4ucb1/Nt9w++h3b8841JKJIUu5BM+6rF3sebwOL3eXGgCyJVGDDN o7CmFPfjg4V0nsI9Ba4Kpemjpxm96KUH3qXElu6IC6ImlNtyibkFTQJw2 KLLQbY99V9Up6LuHVtjOI6LMGS10+KSWr8PGAxw57yTIvzMb11IY8fRMP M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhwFAHV5ilGtJV2a/2dsb2JhbABSgwc3vxN6FnSCIQEEOjEDBgUOBAEIIhQrFyUCBAENBQiIBAzCKgQEjWIQgQExB4J0YQOoYYMPgXI1 X-IronPort-AV: E=Sophos;i="4.87,635,1363132800"; d="scan'208";a="208015069" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 08 May 2013 16:17:34 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r48GHXUe002640 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 8 May 2013 16:17:33 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Wed, 8 May 2013 11:17:33 -0500 From: "George Swallow (swallow)" To: Loa Andersson , "mpls@ietf.org" , "draft-lim-mpls-proxy-lsp-ping@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , Martin Vigoureux Thread-Topic: IPR poll on draft-lim-mpls-proxy-lsp-ping Thread-Index: AQHOS8n9xdcqjNQUJU6U7HVWNpp7EZj7iEMA Date: Wed, 8 May 2013 16:17:32 +0000 Message-ID: <2FE467D3673DCE409A84D67EC2F607BB0FA6DA09@xmb-rcd-x10.cisco.com> In-Reply-To: <518A134E.8060907@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.98.56.166] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] IPR poll on draft-lim-mpls-proxy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 16:17:39 -0000 Loa - Cisco has IPR as disclosed in IPR that was submitted by cisco, and =20 =20 is related to =20 =20 draft-swallow-mpls-remote-lsp-ping, "Proxy LSP Ping," =20 =20 =20 =20 =20 =09 =09 2006-12-20 ID # 778 "Cisco's Statement about IPR claimed in draft-swallow-mpls-remote-lsp-ping-00.txt" This clearly needs to be updated to point at the current document. I will take care of that. George On 5/8/13 4:56 AM, "Loa Andersson" wrote: >Working Group and authors; > >The authors of Working Group and authors; > >The authors of draft-lim-mpls-proxy-lsp-ping has indicated >that the draft is ready to be adopted as a working group document. > >Before we start that poll we need to do an IPR poll on the draft, this >mail starts that IPR poll. > >Are you aware of any IPR that applies to draft-lim-mpls-proxy-lsp-ping? > >If so, has this IPR been disclosed in compliance with IETF IPR rules >(see RFCs 3979, 4879, 3669 and 5378 for more details). > >If you are listed as a document author or contributor please respond to >this email regardless of whether or not you are aware of any relevant >IPR. *The response needs to be sent to the MPLS wg mailing list.* The >documents will not advance to the next stage until a response >has been received from each author and contributor. > >If you are on the MPLS WG email list but are not listed as an author or >contributor, then please explicitly respond only if you are aware of any >IPR that has not yet been disclosed in conformance with IETF rules. > > >Thanks, Loa >(as MPLS WG co-chair) > >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 From jie.dong@huawei.com Wed May 8 09:18:34 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4480121F95EF for ; Wed, 8 May 2013 09:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FYDhUbe1Byxg for ; Wed, 8 May 2013 09:18:29 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3E48621F95EC for ; Wed, 8 May 2013 09:18:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARE33774; Wed, 08 May 2013 16:18:26 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 8 May 2013 17:18:18 +0100 Received: from NKGEML404-HUB.china.huawei.com (10.98.56.35) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 8 May 2013 17:18:23 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.76]) by nkgeml404-hub.china.huawei.com ([10.98.56.35]) with mapi id 14.01.0323.007; Thu, 9 May 2013 00:18:17 +0800 From: Jie Dong To: Ross Callon , "mpls@ietf.org" , "draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org" Thread-Topic: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 Thread-Index: Ac5KBNrRqy5GgTuxR1iRJSatXBuqdwCAq/Ug Date: Wed, 8 May 2013 16:18:16 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927331C4E3D@nkgeml512-mbx.china.huawei.com> References: <62CCD4C52ACDAD4481149BD5D8A72FD316C3ED09@CH1PRD0510MB355.namprd05.prod.outlook.com> In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316C3ED09@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.210.102] Content-Type: multipart/alternative; boundary="_000_76CD132C3ADEF848BD84D028D243C927331C4E3Dnkgeml512mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 16:18:34 -0000 --_000_76CD132C3ADEF848BD84D028D243C927331C4E3Dnkgeml512mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes/support. Best regards, Jie From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ros= s Callon Sent: Monday, May 06, 2013 5:53 AM To: mpls@ietf.org; draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools= .ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-s= ub-tlvs-registry-02 Working group, this is to start a "two week" poll on adopting draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end May 20th, 2013. Ross (as mpls wg co-chair) --_000_76CD132C3ADEF848BD84D028D243C927331C4E3Dnkgeml512mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes/suppor= t.

 = ;

Best regards,

Jie

 = ;

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Monday, May 06, 2013 5:53 AM
To: mpls@ietf.org; draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registr= y@tools.ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlv= s-and-sub-tlvs-registry-02

 

Working group,

 

this is to start a "two week" poll on adopting

draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02=

as an MPLS working group document.

 

Please send your comments (support/not support) to the mpl= s working

group mailing list (mpls@= ietf.org).

 

This poll will end May 20th, 2013.

 

Ross

(as mpls wg co-chair)

 

 

--_000_76CD132C3ADEF848BD84D028D243C927331C4E3Dnkgeml512mbxchi_-- From huubatwork@gmail.com Wed May 8 12:22:42 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B2B521F8A7B for ; Wed, 8 May 2013 12:22:41 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buYh0g1yK01T for ; Wed, 8 May 2013 12:22:40 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 8759521F89E2 for ; Wed, 8 May 2013 12:22:40 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id uk5so2060853obc.25 for ; Wed, 08 May 2013 12:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:disposition-notification-to:date:from :reply-to:user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=rTSFkhImZOQTDtjyjBWCvcW6xdX0IBLsr6IRbAs3ToQ=; b=xWYlXTgsK2L2NgHqw6G+/oGh2eW22PHbbDsS2EfcMeu3CgAd6fXQcRu+fsZxnIWqyj /37yB5UVHjjUp12Me+VfxliH/Ux0erhLGigWz7cN208RnLtayGcAegfGtY7GfbC9P8Z7 kFkt9sDmCIMp3ukSUClbP4yzAhrka4JiXZTQ9jD9vR9U2H6YBNqE2xlk/yVWnn1HVEzS 8Y8xHXTOvX9SW/9rVcwZVSQfy+pSqGpnWEzMv8notHFlIEuISGEQQJ1CpZG6VT4qVwg0 EQ2M4HmFUtVgIhjmS7mlvwRRLg5baATe46CL4cUwC5GvuwMCQAShCYte2yNO43UGIfQj x8xw== X-Received: by 10.182.242.42 with SMTP id wn10mr821720obc.37.1368040956504; Wed, 08 May 2013 12:22:36 -0700 (PDT) Received: from McAsterix.local ([129.192.185.164]) by mx.google.com with ESMTPSA id ns4sm7768489obc.2.2013.05.08.12.22.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 May 2013 12:22:35 -0700 (PDT) Message-ID: <518AA5FD.7030704@gmail.com> Date: Wed, 08 May 2013 21:22:37 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mpls@ietf.org References: <20ECF67871905846A80F77F8F4A2757210150296@xmb-rcd-x09.cisco.com> <22257C41A415324A984CD03D63344E270A4750F7@TELMBB002RM001.telecomitalia.local> In-Reply-To: <22257C41A415324A984CD03D63344E270A4750F7@TELMBB002RM001.telecomitalia.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mpls] R: PSC: draft-rhd-mpls-tp-psc-priority-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 19:22:42 -0000 Hi, > Hi Eric, > You wrote "is it appropriate to make this priority swap?" > My answer is yes, it shall be done for the reasons explained in liaison 1205, bullet 1. It should be mandatory to swap to provide consistent behaviour. > You wrote "- what do we need to change? rfc5654? rfc4427? " > No I don't believe it is required to change any RFC but RFC 6378 Indeed RFC6378 should be fixed. Regards, Huub. > -----Messaggio originale----- > Da: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Per conto di Eric Osborne (eosborne) > Inviato: mercoledì 17 aprile 2013 14:16 > A: mpls@ietf.org > Oggetto: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00 > > This thread is for discussing draft-rhd-mpls-tp-psc-priority-00. In brief, the draft proposes swapping the priorities between FS and SF-P (see section 4.3.2 of rfc6378). This proposed swap has a long history, dating back to when PSC was an ID. For some history, see > > http://datatracker.ietf.org/liaison/1229/ > and > http://datatracker.ietf.org/liaison/1234/ > > The questions that I think are relevant here are: > > - is it appropriate to make this priority swap? > - are there alternative approaches? > - what do we need to change? rfc5654? rfc4427? > - if we don't make the change, does this expose implementation to problems? > - if we do make the change, how do we go about it? > > but of course any and all discussion is welcome. > > As with the other threads I'm going to leave my two cents out of this introductory email but I'll chime in when discussion starts. > > > > > > eric > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- ***************************************************************** 请记ä½ï¼Œä½ æ˜¯ç‹¬ä¸€æ— äºŒçš„，就åƒå…¶ä»–æ¯ä¸€ä¸ªäººä¸€æ · From wyaacov@gmail.com Wed May 8 12:45:07 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C890D21F8F2E for ; Wed, 8 May 2013 12:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.666 X-Spam-Level: X-Spam-Status: No, score=0.666 tagged_above=-999 required=5 tests=[AWL=-3.265, BAYES_40=-0.185, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9RTpWdh0FpJ for ; Wed, 8 May 2013 12:45:07 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) by ietfa.amsl.com (Postfix) with ESMTP id 575C521F8F69 for ; Wed, 8 May 2013 12:45:02 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id m15so2321251wgh.5 for ; Wed, 08 May 2013 12:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=GkfCG44oHQGjoj76g/KeKdhSZRxGmU7ugca1XwDfMMM=; b=Jl8K2c/9/V7rAYT6/M4BZzXqLN6NQhsRMO0D2KXDnDYGkERN0rFTzaHPbW8gRFlksw zOAaPDTMCQ5x3PFj4nxnnaYh5qTgD+EGlwDPh1lsx/z3YBzGk92Vgo+FV4bBUCurRHpu ZffUCq66yWTTA4Yo7v2k2OxM7F5lBXaLq3q7WGxnnnhJ/1EPb7DFDF2LSvBtyNstHC7q lQ85oxKPxejSspFyN3BYlsBOGjhWqXcNjlqTrSpzHR8++biGKlHOXW3XdUFvLx/aDgR+ oit1k/upmwxZ4yLBTSsAK3uSgePfNBwDpmkPYSfvkTLkTpev/M0gQZe7cTaoOHtwQHTL RAOw== MIME-Version: 1.0 X-Received: by 10.180.14.5 with SMTP id l5mr24158287wic.32.1368042301306; Wed, 08 May 2013 12:45:01 -0700 (PDT) Received: by 10.194.85.229 with HTTP; Wed, 8 May 2013 12:45:01 -0700 (PDT) In-Reply-To: <518AA5FD.7030704@gmail.com> References: <20ECF67871905846A80F77F8F4A2757210150296@xmb-rcd-x09.cisco.com> <22257C41A415324A984CD03D63344E270A4750F7@TELMBB002RM001.telecomitalia.local> <518AA5FD.7030704@gmail.com> Date: Wed, 8 May 2013 22:45:01 +0300 Message-ID: From: Yaacov Weingarten To: huubatwork@gmail.com Content-Type: multipart/alternative; boundary=f46d040fa04c683ba604dc3a2b4c Cc: mpls@ietf.org Subject: Re: [mpls] R: PSC: draft-rhd-mpls-tp-psc-priority-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 19:45:07 -0000 --f46d040fa04c683ba604dc3a2b4c Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable Huub, hi Not sure how consistent your answers are in this email. You believe that the priority swap should be instituted "to provide consistent behavior", Yet you say that the change should be made to RFC6378, which would make the behavior inconsistent with RFC4427. So do we want to be consistent or inconsistent? BR, yaacov On Wed, May 8, 2013 at 10:22 PM, Huub van Helvoort wr= ote: > Hi, > > > Hi Eric, >> You wrote "is it appropriate to make this priority swap?" >> My answer is yes, it shall be done for the reasons explained in liaison >> 1205, bullet 1. >> > > It should be mandatory to swap to provide consistent behaviour. > > > You wrote "- what do we need to change? rfc5654? rfc4427? " >> No I don't believe it is required to change any RFC but RFC 6378 >> > > Indeed RFC6378 should be fixed. > > Regards, Huub. > > > > -----Messaggio originale----- >> Da: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Per conto di >> Eric Osborne (eosborne) >> Inviato: mercoled=A8=AC 17 aprile 2013 14:16 >> A: mpls@ietf.org >> Oggetto: [mpls] PSC: draft-rhd-mpls-tp-psc-**priority-00 >> >> This thread is for discussing draft-rhd-mpls-tp-psc-**priority-00. In >> brief, the draft proposes swapping the priorities between FS and SF-P (s= ee >> section 4.3.2 of rfc6378). This proposed swap has a long history, datin= g >> back to when PSC was an ID. For some history, see >> >> http://datatracker.ietf.org/**liaison/1229/ >> and >> http://datatracker.ietf.org/**liaison/1234/ >> >> The questions that I think are relevant here are: >> >> - is it appropriate to make this priority swap? >> - are there alternative approaches? >> - what do we need to change? rfc5654? rfc4427? >> - if we don't make the change, does this expose implementation to >> problems? >> - if we do make the change, how do we go about it? >> >> but of course any and all discussion is welcome. >> >> As with the other threads I'm going to leave my two cents out of this >> introductory email but I'll chime in when discussion starts. >> >> >> >> >> >> eric >> ______________________________**_________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/**listinfo/mpls >> >> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle >> persone indicate. La diffusione, copia o qualsiasi altra azione derivant= e >> dalla conoscenza di queste informazioni sono rigorosamente vietate. Qual= ora >> abbiate ricevuto questo documento per errore siete cortesemente pregati = di >> darne immediata comunicazione al mittente e di provvedere alla sua >> distruzione, Grazie. >> >> This e-mail and any attachments is confidential and may contain >> privileged information intended for the addressee(s) only. Dissemination= , >> copying, printing or use by anybody else is unauthorised. If you are not >> the intended recipient, please delete this message and any attachments a= nd >> advise the sender by return e-mail, Thanks. >> >> ______________________________**_________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/**listinfo/mpls >> >> > > -- > ********************************************************************* > =C7=EB=BC=C7=D7=A1=A3=AC=C4=E3=CA=C7=B6=C0=D2=BB=CE=DE=B6= =FE=B5=C4=A3=AC=BE=CD=CF=F1=C6=E4=CB=FB=C3=BF=D2=BB=B8=F6=C8=CB=D2=BB=D1=F9 > > ______________________________**_________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/**listinfo/mpls > --=20 Thanx and BR, yaacov *Still looking for new opportunity* --f46d040fa04c683ba604dc3a2b4c Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable
Huub, hi

Not sure how consistent = your answers are in this email.

You be= lieve that the priority swap should be instituted "to provide consiste= nt behavior", Yet you say that the change should be made to RFC6378, w= hich would make the behavior inconsistent with RFC4427.

So do we want to be consistent or inconsist= ent?

BR,
yaacov
<= /div>


On Wed, = May 8, 2013 at 10:22 PM, Huub van Helvoort <huubatwork@gmail.com>= ; wrote:
Hi,


Hi Eric,
You wrote "is it appropriate to make this priority swap?"
My answer is yes, it shall be done for the reasons explained in liaison 120= 5, bullet 1.

It should be mandatory to swap to provide consistent behaviour.


You wrote "- what do we need to change?  rfc5654?  rfc4427? =  "
No I don't believe it is required to change any RFC but RFC 6378

Indeed RFC6378 should be fixed.

Regards, Huub.



-----Messaggio originale-----
Da: mpls-bounces= @ietf.org [mailto:mpls-bounces@ietf.org] Per conto di Eric Osborne (eosborne)
Inviato: mercoled=A8=AC 17 aprile 2013 14:16
A: mpls@ietf.org
Oggetto: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00

This thread is for discussing draft-rhd-mpls-tp-psc-priority-00. &nb= sp;In brief, the draft proposes swapping the priorities between FS and SF-P= (see section 4.3.2 of rfc6378).  This proposed swap has a long histor= y, dating back to when PSC was an ID.  For some history, see

htt= p://datatracker.ietf.org/liaison/1229/
and
htt= p://datatracker.ietf.org/liaison/1234/

The questions that I think are relevant here are:

- is it appropriate to make this priority swap?
   - are there alternative approaches?
   - what do we need to change?  rfc5654?  rfc4427?
- if we don't make the change, does this expose implementation to probl= ems?
- if we do make the change, how do we go about it?

but of course any and all discussion is welcome.

As with the other threads I'm going to leave my two cents out of this i= ntroductory email but I'll chime in when discussion starts.





eric
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie.

This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks.

_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls



--
*************************************************************= ****
              =C7=EB=BC=C7=D7=A1=A3=AC= =C4=E3=CA=C7=B6=C0=D2=BB=CE=DE=B6=FE=B5=C4=A3=AC=BE=CD=CF=F1=C6=E4=CB=FB=C3= =BF=D2=BB=B8=F6=C8=CB=D2=BB=D1=F9

_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls



--
=
Thanx and BR,
yaacov

Still= looking for new opportunity
--f46d040fa04c683ba604dc3a2b4c-- From huubatwork@gmail.com Wed May 8 13:27:51 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E93621F8F41 for ; Wed, 8 May 2013 13:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.574 X-Spam-Level: X-Spam-Status: No, score=-0.574 tagged_above=-999 required=5 tests=[AWL=-2.025, BAYES_50=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JaRn21ImZ0tX for ; Wed, 8 May 2013 13:27:46 -0700 (PDT) Received: from mail-oa0-f48.google.com (mail-oa0-f48.google.com [209.85.219.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4080221F8EBF for ; Wed, 8 May 2013 13:27:46 -0700 (PDT) Received: by mail-oa0-f48.google.com with SMTP id i4so2568539oah.21 for ; Wed, 08 May 2013 13:27:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:disposition-notification-to:date:from :reply-to:user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=Dh6kUnWIpP/TY2S/1O842vg3aPqeMF+WfXdJyTIyC9s=; b=fyzt4R4EjAO1kDSG8URSHCAiPsXxL5pWaV6JbiDc5a3+uslEcALXUs1zFDKXHKr4kE wqGYjls2aGJQTMDELgGiQzE+HAsvZoXjIvqQVOe0AHYmXEsf6rmSY/U+iuPk+dAFyYhA m1W20h2epR+2JfLy5TEVYGdfFkgUIcHewwXcpnVQ9HXlNibqWnwo1peDaj0jU3s1gvUl WxJQ1mhQc12eC3jDJoeacq/r+G9Iyhg9HziKi+y8Imsd4kMMwUSbtVqK7RvEEHRHnwV3 /xwpS37KVPQuE1TNZCEySBMIFsVxYx6I/htgfi8AOrWxUPtW5soR7u6nM8cE8mnZUy7J we8A== X-Received: by 10.182.241.134 with SMTP id wi6mr2683371obc.46.1368044865794; Wed, 08 May 2013 13:27:45 -0700 (PDT) Received: from McAsterix.local ([129.192.185.164]) by mx.google.com with ESMTPSA id nt17sm23875obb.13.2013.05.08.13.27.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 May 2013 13:27:44 -0700 (PDT) Message-ID: <518AB544.1070109@gmail.com> Date: Wed, 08 May 2013 22:27:48 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mpls@ietf.org References: <20ECF67871905846A80F77F8F4A2757210150296@xmb-rcd-x09.cisco.com> <22257C41A415324A984CD03D63344E270A4750F7@TELMBB002RM001.telecomitalia.local> <518AA5FD.7030704@gmail.com> In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Subject: Re: [mpls] R: PSC: draft-rhd-mpls-tp-psc-priority-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 20:27:51 -0000 Yaacov, hi, You replied: > Not sure how consistent your answers are in this email. > > You believe that the priority swap should be instituted "to provide > consistent behavior", Yet you say that the change should be made to > RFC6378, which would make the behavior inconsistent with RFC4427. As explained in liaison http://datatracker.ietf.org/liaison/1234/ we would like consistency with other transport network linear protection mechanisms. > So do we want to be consistent or inconsistent? If you want consistency between linear protection (using data plane protocols) and linear restoration (using control plane protocols) you should consider changing RFC4427 too. Regards, Huub. > On Wed, May 8, 2013 at 10:22 PM, Huub van Helvoort > wrote: > > Hi, > > > Hi Eric, > You wrote "is it appropriate to make this priority swap?" > My answer is yes, it shall be done for the reasons explained in > liaison 1205, bullet 1. > > > It should be mandatory to swap to provide consistent behaviour. > > > You wrote "- what do we need to change? rfc5654? rfc4427? " > No I don't believe it is required to change any RFC but RFC 6378 > > > Indeed RFC6378 should be fixed. > > Regards, Huub. > > > > -----Messaggio originale----- > Da: mpls-bounces@ietf.org > [mailto:mpls-bounces@ietf.org ] > Per conto di Eric Osborne (eosborne) > Inviato: mercoled¨¬ 17 aprile 2013 14:16 > A: mpls@ietf.org > Oggetto: [mpls] PSC: draft-rhd-mpls-tp-psc-__priority-00 > > This thread is for discussing > draft-rhd-mpls-tp-psc-__priority-00. In brief, the draft > proposes swapping the priorities between FS and SF-P (see > section 4.3.2 of rfc6378). This proposed swap has a long > history, dating back to when PSC was an ID. For some history, see > > http://datatracker.ietf.org/__liaison/1229/ > > and > http://datatracker.ietf.org/__liaison/1234/ > > > The questions that I think are relevant here are: > > - is it appropriate to make this priority swap? > - are there alternative approaches? > - what do we need to change? rfc5654? rfc4427? > - if we don't make the change, does this expose implementation > to problems? > - if we do make the change, how do we go about it? > > but of course any and all discussion is welcome. > > As with the other threads I'm going to leave my two cents out of > this introductory email but I'll chime in when discussion starts. > > > > > > eric > _________________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/__listinfo/mpls > > > Questo messaggio e i suoi allegati sono indirizzati > esclusivamente alle persone indicate. La diffusione, copia o > qualsiasi altra azione derivante dalla conoscenza di queste > informazioni sono rigorosamente vietate. Qualora abbiate > ricevuto questo documento per errore siete cortesemente pregati > di darne immediata comunicazione al mittente e di provvedere > alla sua distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain > privileged information intended for the addressee(s) only. > Dissemination, copying, printing or use by anybody else is > unauthorised. If you are not the intended recipient, please > delete this message and any attachments and advise the sender by > return e-mail, Thanks. > > _________________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/__listinfo/mpls > > > > > > -- > Thanx and BR, > yaacov > > /Still looking for new opportunity/ -- ***************************************************************** Çë¼Çס£¬ÄãÊǶÀÒ»ÎÞ¶þµÄ£¬¾ÍÏñÆäËûÿһ¸öÈËÒ»Ñù From huubatwork@gmail.com Wed May 8 13:43:39 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5853921F8F6D for ; Wed, 8 May 2013 13:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.087 X-Spam-Level: X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[AWL=1.513, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ja87v-UMTsdV for ; Wed, 8 May 2013 13:43:25 -0700 (PDT) Received: from mail-oa0-f50.google.com (mail-oa0-f50.google.com [209.85.219.50]) by ietfa.amsl.com (Postfix) with ESMTP id 9CE4821F8FDF for ; Wed, 8 May 2013 13:43:25 -0700 (PDT) Received: by mail-oa0-f50.google.com with SMTP id l10so2615844oag.9 for ; Wed, 08 May 2013 13:43:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:message-id:disposition-notification-to:date:from :reply-to:user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=u2eSDoDG1c0cH2XtFNkDp6fwTJmj9Ld+5+ZKrCjVV0Q=; b=A215FAI0kWiXWuvxIiThUGvczoBlbhONMKD9h6FZGVIPBt+f3yuk0m5SN6B+UhM+WT LrQQLl/BEkYHEuyQPt/uFX4CyHZTzNXPPz2NFljWk4O7xVrV7lTzVz+RyADJeaN0JkTE 4wiqqMX1X0QHvYYLzkxo+A6yAuZCLdAP4wq7DS27JgXPoJ9MMMBwshhVz54ec7Dsn6dV BwPxVIlZuLIzY2qBShb/JVKEgg9QLIghvc0C0Sj9x/s+7cZommFHlivhh+FxXi6a7mQ8 AUAtRWMKGTMIX5bcYZeG1Bk7Lvuhry+CsnWaO4qs4Hb48QLM+ruLhqbmkR5LlcZUDabV VHkw== X-Received: by 10.60.149.129 with SMTP id ua1mr2772972oeb.56.1368045805197; Wed, 08 May 2013 13:43:25 -0700 (PDT) Received: from McAsterix.local ([129.192.185.164]) by mx.google.com with ESMTPSA id nt17sm65715obb.13.2013.05.08.13.43.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 May 2013 13:43:24 -0700 (PDT) Message-ID: <518AB8EF.9020506@gmail.com> Date: Wed, 08 May 2013 22:43:27 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: mpls@ietf.org References: <20ECF67871905846A80F77F8F4A27572101502D8@xmb-rcd-x09.cisco.com> <22257C41A415324A984CD03D63344E270A4751A0@TELMBB002RM001.telecomitalia.local> In-Reply-To: <22257C41A415324A984CD03D63344E270A4751A0@TELMBB002RM001.telecomitalia.local> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [mpls] R: PSC: draft-cdh-mpls-tp-psc-non-revertive-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 May 2013 20:43:39 -0000 Hi, > You wrote "- do we need MS-W and the associated state changes?" > My answer is yes to preserve current operational practice. I believe the same concept is expressed in the liaison 1205 from ITU-T SG15. Indeed, it is issue #9 in http://datatracker.ietf.org/liaison/1205/ Regards, Huub. > You wrote "- if so, is the method proposed in the draft the correct one?" > My answer is yes because it is the simplest and safest way to introduce such enhancement being based on an approach that has been proved to work. > > Best regards, > Alessandro > ------------------------------------------------------------------ > Telecom Italia > Alessandro Gerardo D'Alessandro > Transport Innovation > Via Reiss Romoli, 274 - 10148 Torino > phone: +39 011 228 5887 > mobile: +39 335 766 9607 > fax: +39 06 418 639 07 > > > -----Messaggio originale----- > Da: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Per conto di Eric Osborne (eosborne) > Inviato: mercoledì 17 aprile 2013 14:32 > A: mpls@ietf.org > Oggetto: [mpls] PSC: draft-cdh-mpls-tp-psc-non-revertive-00 > > This thread is for discussing draft-cdh-mpls-tp-psc-non-revertive-00. This draft adds a MS-W (Manual Switch to Working) command and modifies the PSC text and state machine to handle this new command. The proposed MS-W command is of equal priority to the existing MS-P command, and there is text to handle the simultaneous or sequential occurrence of two equal-priority commands. > > Relevant questions include: > > - do we need MS-W and the associated state changes? > - PSC currently does not have any commands with equal priority. Should we employ such a mechanism to address either this issue or future additions to PSC? > - if so, is the method proposed in the draft the correct one? > - if not, do we need any additional mechanism to handle the issue this draft raises? > > but of course any and all discussion is welcome. > > > > > > eric > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -- ***************************************************************** 请记ä½ï¼Œä½ æ˜¯ç‹¬ä¸€æ— äºŒçš„，就åƒå…¶ä»–æ¯ä¸€ä¸ªäººä¸€æ · From internet-drafts@ietf.org Wed May 8 17:49:33 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9390221F9113; Wed, 8 May 2013 17:49:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.391 X-Spam-Level: X-Spam-Status: No, score=-102.391 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9uZFN+bAM7hu; Wed, 8 May 2013 17:49:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0487E21F8F28; Wed, 8 May 2013 17:49:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p7 Message-ID: <20130509004932.30403.7724.idtracker@ietfa.amsl.com> Date: Wed, 08 May 2013 17:49:32 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 00:49:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : MPLS-TP Traffic Engineering (TE) Management Information = Base (MIB) Author(s) : Venkatesan Mahalingam Kannan KV Sampath Sam Aldrin Thomas D. Nadeau Filename : draft-ietf-mpls-tp-te-mib-06.txt Pages : 57 Date : 2013-05-08 Abstract: This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects of Tunnels, Identifiers, Label Switch Router and Textual conventions for Multiprotocol Label Switching (MPLS) based Transport Profile (TP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-te-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-te-mib-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-te-mib-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From aldrin.ietf@gmail.com Wed May 8 18:09:08 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25D2021F8F25; Wed, 8 May 2013 18:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.474, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+h9ta3KWzwK; Wed, 8 May 2013 18:09:07 -0700 (PDT) Received: from mail-da0-x22f.google.com (mail-da0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD2B21F8DCF; Wed, 8 May 2013 18:09:07 -0700 (PDT) Received: by mail-da0-f47.google.com with SMTP id k13so1280013dae.6 for ; Wed, 08 May 2013 18:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:references:from:mime-version:content-type :x-mailer:message-id:date:cc:content-transfer-encoding:to; bh=RfJeNPI5nym+uhlT/JOGx1XWH3J4YTSdgZGt2Znwf5A=; b=No595Glxyj4zqYJ3Zf2RqL4sbAT/dl4Rg+XIJR075/86zVnGp8NM27/ZfY1uso9JeF K+52zvRRUdaAiPtwdHmnYf0gfUpenk8i+4PBKrEvUI905YgI9OKa7/oU1HRnstLOs2A/ n4IyQ6PoghUce4HgXO+ng8QWdXjtJPHgq8mTuoOliuO1zNrz6mCOjiPjmoxsQ6KZ77Qk wxv7oBT2ti6ucCxucUoQYdXE1FronxKr0Rnv4JCYzK6RYq0Os/p8zCUeXAUSb0cTXfbz W33Kg9b4p64ZGLPNW4Ff/OZH92GjpjzcAeYude5H9GvSrgvQsYtsDNlV6Ebqy5GNn5jI plRA== X-Received: by 10.68.232.42 with SMTP id tl10mr10114995pbc.72.1368061747243; Wed, 08 May 2013 18:09:07 -0700 (PDT) Received: from [192.168.1.4] (c-98-248-237-85.hsd1.ca.comcast.net. [98.248.237.85]) by mx.google.com with ESMTPSA id do4sm783522pbc.8.2013.05.08.18.09.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 May 2013 18:09:06 -0700 (PDT) References: <20130509004932.30403.7724.idtracker@ietfa.amsl.com> From: Sam Aldrin Mime-Version: 1.0 (1.0) Content-Type: multipart/alternative; boundary=Apple-Mail-B05CC59C-F0F9-430F-8CC6-D280569E3E35 X-Mailer: iPad Mail (10B329) Message-Id: Date: Wed, 8 May 2013 18:09:04 -0700 Content-Transfer-Encoding: 7bit To: mpls@ietf.org, Joan Cucchiara , MIB Doctors Cc: Kannan Sampath Subject: [mpls] Fwd: I-D Action: draft-ietf-mpls-tp-te-mib-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 01:09:08 -0000 --Apple-Mail-B05CC59C-F0F9-430F-8CC6-D280569E3E35 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi all, We have posted a new version of the draft. This version addresses all the comments raised thus far. These include the c= omments we have received as part of last call. If we haven't addressed any, kindly let us know, will sure take care of it. As there are significant amount of changes made, please take time to review.= As always, we are open to comments and suggestions. Cheers Sam Sent from my iPad Begin forwarded message: > From: internet-drafts@ietf.org > Date: May 8, 2013, 5:49:32 PM PDT > To: i-d-announce@ietf.org > Cc: mpls@ietf.org > Subject: [mpls] I-D Action: draft-ietf-mpls-tp-te-mib-06.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. > This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. >=20 > Title : MPLS-TP Traffic Engineering (TE) Management Informati= on Base (MIB) > Author(s) : Venkatesan Mahalingam > Kannan KV Sampath > Sam Aldrin > Thomas D. Nadeau > Filename : draft-ietf-mpls-tp-te-mib-06.txt > Pages : 57 > Date : 2013-05-08 >=20 > Abstract: > This memo defines a portion of the Management Information Base (MIB) > for use with network management protocols in the Internet community. > In particular, it describes managed objects of Tunnels, Identifiers, > Label Switch Router and Textual conventions for Multiprotocol Label > Switching (MPLS) based Transport Profile (TP). >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-te-mib >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-mpls-tp-te-mib-06 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-te-mib-06 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --Apple-Mail-B05CC59C-F0F9-430F-8CC6-D280569E3E35 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Hi all,

We ha= ve posted a new version of the draft.
This version addresses all t= he comments raised thus far. These include the comments we have received as p= art of last call.
If we haven't addressed any, kindly let us know,= will sure take care of it.

As there are significan= t amount of changes made, please take time to review.
As always, w= e are open to comments and suggestions.

Cheers
Sam

Sent from my iPad

Begin forwarded message:
From: internet-drafts@ietf.org
Date: May 8, 2= 013, 5:49:32 PM PDT
To: i= -d-announce@ietf.org
Cc: mpls= @ietf.org
Subject: [mpls] I-D Action: draft-ietf-mpls-tp-te= -mib-06.txt


A New Internet-Draft is available from the on-line Inter= net-Drafts directories.
This draft is a work item of the Mu= ltiprotocol Label Switching Working Group of the IETF.

   Title        &n= bsp;  : MPLS-TP Traffic Engineering (TE) Management Information Ba= se (MIB)
   Author(s)     &nb= sp; : Venkatesan Mahalingam
    &n= bsp;            =         Kannan KV Sampath
=            &nb= sp;            &= nbsp;Sam Aldrin
       &= nbsp;            = ;     Thomas D. Nadeau
  &nbs= p;Filename        : draft-ietf-mpls-tp-te= -mib-06.txt
   Pages     &nbs= p;     : 57
   Date &nbs= p;          : 2013-05-08

Abstract:
  This m= emo defines a portion of the Management Information Base (MIB)
  for use with network management protocols in the Internet co= mmunity.
  In particular, it describes managed ob= jects of Tunnels, Identifiers,
  Label Switch Rou= ter and Textual conventions for Multiprotocol Label
 &= nbsp;Switching (MPLS) based Transport Profile (TP).
<= br>
The IETF datatracker status page for this draft is= :
https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-te-mib<= /span>

There's also a htmlized version available a= t:
http://tools.ietf.org/html/draft-ietf-mpls-tp-te-mib-06

A diff from the previous version is available at= :
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-te-m= ib-06


Internet-Drafts a= re also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
= --Apple-Mail-B05CC59C-F0F9-430F-8CC6-D280569E3E35-- From vlim@cisco.com Wed May 8 19:16:18 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE5721F854E for ; Wed, 8 May 2013 19:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wy7dBIypOKVc for ; Wed, 8 May 2013 19:16:13 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id A7C6821F8539 for ; Wed, 8 May 2013 19:16:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2168; q=dns/txt; s=iport; t=1368065773; x=1369275373; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=guhL2G5BgFqoNA6Jb2mh01qwIeFwXIqb3LPf8nOHE4I=; b=bK9SBqmJyR+Emjhm28AkWfCiAUM/L08chPM10mnHNh5SbFsmNFQwxcfI eWu1SaAa832e9Zw2G+x2PQbYs0RcX58fmsr7ylZRkkgUrD800dPQTXDu4 tmpdoxwpaK93SYVQIi2sL94+MgeUYNasrvR7CeoCR817y5DY1OU8ADB/Z s=; X-IronPort-AV: E=Sophos;i="4.87,638,1363132800"; d="scan'208";a="208094784" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 09 May 2013 02:16:13 +0000 Received: from [10.98.73.148] (bxb-vlim-8813.cisco.com [10.98.73.148]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r492GBEr016916; Thu, 9 May 2013 02:16:12 GMT Message-ID: <518B06EB.3070105@cisco.com> Date: Wed, 08 May 2013 22:16:11 -0400 From: Vanson Lim User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Loa Andersson References: <2FE467D3673DCE409A84D67EC2F607BB0FA6DA09@xmb-rcd-x10.cisco.com> In-Reply-To: <2FE467D3673DCE409A84D67EC2F607BB0FA6DA09@xmb-rcd-x10.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "draft-lim-mpls-proxy-lsp-ping@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] IPR poll on draft-lim-mpls-proxy-lsp-ping X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 02:16:18 -0000 No additional disclosures from me.. George's disclosure is all that I am aware of. -Vanson On 5/8/13 12:17 PM, George Swallow (swallow) wrote: > Loa - > > Cisco has IPR as disclosed in > > IPR that was submitted by cisco, and > > > is related to > > > draft-swallow-mpls-remote-lsp-ping, "Proxy LSP Ping," > > > > > > > > 2006-12-20 > ID # 778 > "Cisco's Statement about IPR claimed in > draft-swallow-mpls-remote-lsp-ping-00.txt" > > > > This clearly needs to be updated to point at the current document. I will > take care of that. > > George > > On 5/8/13 4:56 AM, "Loa Andersson" wrote: > >> Working Group and authors; >> >> The authors of Working Group and authors; >> >> The authors of draft-lim-mpls-proxy-lsp-ping has indicated >> that the draft is ready to be adopted as a working group document. >> >> Before we start that poll we need to do an IPR poll on the draft, this >> mail starts that IPR poll. >> >> Are you aware of any IPR that applies to draft-lim-mpls-proxy-lsp-ping? >> >> If so, has this IPR been disclosed in compliance with IETF IPR rules >> (see RFCs 3979, 4879, 3669 and 5378 for more details). >> >> If you are listed as a document author or contributor please respond to >> this email regardless of whether or not you are aware of any relevant >> IPR. *The response needs to be sent to the MPLS wg mailing list.* The >> documents will not advance to the next stage until a response >> has been received from each author and contributor. >> >> If you are on the MPLS WG email list but are not listed as an author or >> contributor, then please explicitly respond only if you are aware of any >> IPR that has not yet been disclosed in conformance with IETF rules. >> >> >> Thanks, Loa >> (as MPLS WG co-chair) >> >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 > . > From loa@pi.nu Thu May 9 01:35:45 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54D921F84B5 for ; Thu, 9 May 2013 01:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtOeN-kG49zz for ; Thu, 9 May 2013 01:35:40 -0700 (PDT) Received: from pipi.pi.nu (unknown [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9006F21F8F0A for ; Thu, 9 May 2013 01:35:38 -0700 (PDT) Received: from [192.168.1.104] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 379FF1802D26; Thu, 9 May 2013 10:35:37 +0200 (CEST) Message-ID: <518B5FDA.40609@pi.nu> Date: Thu, 09 May 2013 10:35:38 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "mpls@ietf.org" References: <518A7009.9090807@pi.nu> In-Reply-To: <518A7009.9090807@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-tp-temporal-hitless-psm@tools.ietf.org Subject: Re: [mpls] Implementations of draft-ietf-mpls-tp-temporal-hitless-psm X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 08:35:46 -0000 Folks, Greg has pointed out the there is a copy and past error in this mail, the pen-ultimate paragraph should be: As part of the shepherd write-up, that is sent as part of the request for publication to the IESG, we need to know about existing or intended implementations of draft-ietf-mpls-tp-temporal-hitless-psm. Tnx Greg! Hope this did not cause any problems. /Loa On 2013-05-08 17:32, Loa Andersson wrote: > Working Group, > > draft-ietf-mpls-tp-temporal-hitless-psm is through working group last > call and has been updated accoring to the comments. > > The working group chairs we will request publication of the document > as an RFC on the Standards track. > > As part of the shepherd write-up, that is sent as part of the request > for publication to the IESG, we need to know about existing or intended > implementations ofdraft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp. > > Please send mails to the mpls wg mailing list (mpls@ietf.org) or the > working group chairs to inform us about implementations. > > /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From Alan.Davey@metaswitch.com Thu May 9 03:59:07 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 862E721F8EED for ; Thu, 9 May 2013 03:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wb98riQpSEV for ; Thu, 9 May 2013 03:59:03 -0700 (PDT) Received: from ENFIRHETS1.metaswitch.com (enfirhets1.metaswitch.com [192.91.191.166]) by ietfa.amsl.com (Postfix) with ESMTP id A977C21F859A for ; Thu, 9 May 2013 03:59:02 -0700 (PDT) Received: from ENFICSCAS1.datcon.co.uk (172.18.4.13) by ENFIRHETS1.metaswitch.com (172.18.209.22) with Microsoft SMTP Server (TLS) id 14.2.342.3; Thu, 9 May 2013 11:57:27 +0100 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFICSCAS1.datcon.co.uk ([::1]) with mapi id 14.02.0342.003; Thu, 9 May 2013 11:59:01 +0100 From: Alan Davey To: David Allan I Thread-Topic: [MPLS] A doubt about RFC 6428 Thread-Index: Ac5IG1yAbZhW1zCyQtKJoj7oW461UgACNQsQARrVc5A= Date: Thu, 9 May 2013 10:59:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.71.124] Content-Type: multipart/alternative; boundary="_000_C2EE31C852049D499842B19FC01C0804C1A8CD51ENFICSMBX1datco_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] [MPLS] A doubt about RFC 6428 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 10:59:07 -0000 --_000_C2EE31C852049D499842B19FC01C0804C1A8CD51ENFICSMBX1datco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dave Thank you very much for getting back to me so quickly. I have a further qu= estion on RFC 6428 if you have another minute. In section 3.5.3, PW End Point MEP-ID, I think that the text defining the = Length field is confusing because it is not clear if the length includes th= e AGI. The text is currently as follows. The length is the length of the following data: the Global_ID, Node Ident= ifier, and Attachment Circuit ID (AC_ID) are as per [9]. Am I correct in thinking that the Length field is the length of the value = fields, as for the Section MEP-ID in section 3.5.1 and the LSP MEP-ID in se= ction 3.5.2? That is, should the text read as follows. The length is the length of the value fields. The Global_ID, Node Identi= fier, and Attachment Circuit ID (AC_ID) are as per [9]. Thanks Alan From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: 03 May 2013 18:35 To: Alan Davey; rfc6428@tools.ietf.org Cc: mpls@ietf.org Subject: RE: [MPLS] A doubt about RFC 6428 Hi Alan: It is kind of implied, as in "received DOWN while NOT in a misconnectivity = state". I'm not sure adding that to the state machine diagram would actuall= y improve the clarity....I'll let others comment. cheers Dave ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of Alan Davey Sent: Friday, May 03, 2013 9:29 AM To: rfc6428@tools.ietf.org Cc: mpls@ietf.org Subject: [mpls] [MPLS] A doubt about RFC 6428 Folks I have a doubt about RFC 6428. Could you please let me know what you think= of the following. Section 3.7.4.2., Exit from a Mis-Connectivity Defect, states that "Exit fr= om a mis-connectivity defect state occurs when no CV messages with mis-conn= ectivity defects have been received for a period of 3.5 seconds". However, the State Machines in section 3.7.5 have no input corresponding to= an "Exit from a Mis-Connectivity Defect" timer pop. (Although they do hav= e a MIS-CONNECTIVITY input added by RFC 6428.) If the State Machine is fol= lowed then Down state is exited as soon as the remote system signals Down s= tate. Should the State Machines be modified such that Down state following a MIS-= CONNECTIVITY input is only exited after an "Exit from a Mis-Connectivity De= fect" timer pop input or am I missing something? Regards Alan Davey Network Technologies Metaswitch Networks alan.davey@metaswitch.com +44 (0) 20 8366 1177 network-technologies.metaswitch.com --_000_C2EE31C852049D499842B19FC01C0804C1A8CD51ENFICSMBX1datco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dave

 

Thank you very much fo= r getting back to me so quickly.  I have a further question on RFC 642= 8 if you have another minute.

 

In section 3.5.3,  PW End Point MEP-ID, I think that the text defining the Length= field is confusing because it is not clear if the length includes the AGI.=   The text is currently as follows.

 

  The length is t= he length of the following data: the Global_ID, Node Identifier, and Attach= ment

   Circuit I= D (AC_ID) are as per [9].

 

Am I correct in thinki= ng that the Length field  is the length of the value fields, as for th= e Section MEP-ID in section 3.5.1 and the LSP MEP-ID in section 3.5.2? = ; That is, should the text read as follows.

 

  The length is t= he length of the value fields.  The Global_ID, Node Identifier, and At= tachment

   Circuit I= D (AC_ID) are as per [9].

 

Thanks

Alan=

 

From: David Allan I [mailto:david.i.allan@ericsson.com]
Sent: 03 May 2013 18:35
To: Alan Davey; rfc6428@tools.ietf.org
Cc: mpls@ietf.org
Subject: RE: [MPLS] A doubt about RFC 6428

 

Hi Alan:

 

It is kind of implie= d, as in "received DOWN while NOT in a misconnectivity state"= ;. I'm not sure adding that to the state machine diagram would actually imp= rove the clarity....I'll let others comment.

 

cheers<= o:p>

Dave

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Alan Davey
Sent: Friday, May 03, 2013 9:29 AM
To: rfc6428@tools.ietf.org=
Cc: mpls@ietf.org
Subject: [mpls] [MPLS] A doubt about RFC 6428

Folks

 

I have a doubt about RFC 6428.  Could you pleas= e let me know what you think of the following.

 

Section 3.7.4.2., Exit from a Mis-Connectivity Defec= t, states that “Exit from a mis-connectivity defect state occurs when= no CV messages with mis-connectivity defects have been received for a peri= od of 3.5 seconds”.

 

However, the State Machines in section 3.7.5 have no= input corresponding to an “Exit from a Mis-Connectivity Defect”= ; timer pop.  (Although they do have a MIS-CONNECTIVITY input added by= RFC 6428.)  If the State Machine is followed then Down state is exited as soon as the remote system signals Down state.=

 

Should the State Machines be modified such that Down= state following a MIS-CONNECTIVITY input is only exited after an “Ex= it from a Mis-Connectivity Defect” timer pop input or am I missing so= mething?

 

Regards

Alan Davey

 

Network Technologies
Metaswitch Networks

 

alan.davey@metaswitch.com
+44 (0) 20 8366 1177
network-technologies.metaswitch.com

 

 

 

--_000_C2EE31C852049D499842B19FC01C0804C1A8CD51ENFICSMBX1datco_-- From internet-drafts@ietf.org Thu May 9 07:18:20 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C0421F8EB5; Thu, 9 May 2013 07:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.424 X-Spam-Level: X-Spam-Status: No, score=-102.424 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jtYcAK1YbtE; Thu, 9 May 2013 07:18:19 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E238121F89E8; Thu, 9 May 2013 07:18:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p7 Message-ID: <20130509141818.32293.89981.idtracker@ietfa.amsl.com> Date: Thu, 09 May 2013 07:18:18 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-ip-pw-capability-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 14:18:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Disabling IPoMPLS and P2P PW LDP Application's State Adv= ertisement Author(s) : Kamran Raza Sami Boutros Filename : draft-ietf-mpls-ldp-ip-pw-capability-04.txt Pages : 13 Date : 2013-05-09 Abstract: Currently, no LDP capability is exchanged for LDP applications like IP Label Switching and L2VPN P2P PW signaling. When an LDP session comes up, an LDP speaker may unnecessarily advertise its local state for such LDP applications even when the peer session is established for some other applications like mLDP or ICCP. This document defines a solution by which an LDP speaker announces to its peer its disinterest in such non-negotiated applications. This, in turn, disables the advertisement of corresponding application state, which would have otherwise be advertised by default, over the established LDP session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ip-pw-capability There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-ip-pw-capability-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-ldp-ip-pw-capability-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From eosborne@cisco.com Thu May 9 08:40:53 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B411521F859A for ; Thu, 9 May 2013 08:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xi4nX+m8AUPS for ; Thu, 9 May 2013 08:40:48 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id AD7E421F8425 for ; Thu, 9 May 2013 08:40:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4485; q=dns/txt; s=iport; t=1368114048; x=1369323648; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=dJlixvzjNwyP5bYTJy6FPlLhf5Zi42EcdZ9GFmbubWU=; b=SKGirTdEwks8MSVqgAIZ47hX3/e6A+zoLGGtbMh1b0O5WzYf3xotY7hp KqYTRv/uUKFAGzYslKAcuZEII/MTCyqMS9N+K/hAkjIhDjaIapPlKiKd5 lRIQ3yy9Vuetq9a3bQJHkBqgC5GnYK0efCz2betJiQovcdHm9H9WwSq8V c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah4FAI3Ci1GtJV2b/2dsb2JhbABPA4MHN8AHehZ0gh8BAQEDAQEBAWsLBQcCAgIBCBEEAQELHQcbDAsUCQgBAQQBDQUIh34GDL1oBI1iEIEBIQsFBwYLgmNhA4hij3CQD4MPgXI1 X-IronPort-AV: E=Sophos;i="4.87,641,1363132800"; d="scan'208";a="208384001" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 09 May 2013 15:40:45 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r49FejOc026599 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 May 2013 15:40:45 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.125]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Thu, 9 May 2013 10:40:45 -0500 From: "Eric Osborne (eosborne)" To: "D'Alessandro Alessandro Gerardo" , "mpls@ietf.org" Thread-Topic: PSC: draft-rhd-mpls-tp-psc-priority-00 Thread-Index: Ac47ZD1tB/jb+CaKQqOehjxMIOgzIgP835SQAFx1EZA= Date: Thu, 9 May 2013 15:40:44 +0000 Message-ID: <20ECF67871905846A80F77F8F4A275721019F7F7@xmb-rcd-x09.cisco.com> References: <20ECF67871905846A80F77F8F4A2757210150296@xmb-rcd-x09.cisco.com> <22257C41A415324A984CD03D63344E270A4750F7@TELMBB002RM001.telecomitalia.local> In-Reply-To: <22257C41A415324A984CD03D63344E270A4750F7@TELMBB002RM001.telecomitalia.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.66.68] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Morro Roberto , Allasia Andrea , Nervo Giacolino Subject: Re: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 15:40:53 -0000 Hi Alessandro, see inline. > -----Original Message----- > From: D'Alessandro Alessandro Gerardo > [mailto:alessandro.dalessandro@telecomitalia.it] > Sent: Tuesday, May 07, 2013 3:27 PM > To: Eric Osborne (eosborne); mpls@ietf.org > Cc: Cavazzoni Carlo; Allasia Andrea; Nervo Giacolino; Morro Roberto; > ryoo@etri.re.kr; lifang@catr.cn; cts@etri.re.kr > Subject: R: PSC: draft-rhd-mpls-tp-psc-priority-00 >=20 > Hi Eric, > You wrote "is it appropriate to make this priority swap?" > My answer is yes, it shall be done for the reasons explained in liaison > 1205, bullet 1. Let me paraphrase the three points in those bullets, I want to make sure I = understand them: a. If the protection path fails then the removal of the FS will not be seen= because the channel used to provide it is gone. b. If there is SF-P and FS is issued by accident then this will cause an ou= tage, which is Bad c. (points to Annex 1): similar to (a) above, the loss of the protection ch= annel means there will be an inconsistency in the protection state Is that an accurate paraphrase? > You wrote "- what do we need to change? rfc5654? rfc4427? " > No I don't believe it is required to change any RFC but RFC 6378 To me this decision is a matter of process rather than of technical behavio= r. =20 I believe the current set of opinions is this: a) some believe that rfc4427 requires the current set of priorities, as per= LS1174 point #1 (http://datatracker.ietf.org/liaison/1174/) b) some believe it does not, and that rfc6378 misinterpreted rfc4427 I think we all agree that the chain here is: 6378 must obey 5654, and that = 5654 requires 4427. So it's going to come down to - is 4427 written wrong but interpreted corre= ctly, or written correctly but misinterpreted? If we decide the former, we need to change 4427 and/or 5654 to clarify the = requirement. If we decide the latter, we do not need to change 4427 and can probably jus= t change 6378. Does that sound right? eric >=20 > Best regards, > Alessandro >=20 > ------------------------------------------------------------------ > Telecom Italia > Alessandro Gerardo D'Alessandro > Transport Innovation > Via Reiss Romoli, 274 - 10148 Torino > phone: +39 011 228 5887 > mobile: +39 335 766 9607 > fax: +39 06 418 639 07 >=20 >=20 > -----Messaggio originale----- > Da: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Per conto di > Eric Osborne (eosborne) > Inviato: mercoled=EC 17 aprile 2013 14:16 > A: mpls@ietf.org > Oggetto: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00 >=20 > This thread is for discussing draft-rhd-mpls-tp-psc-priority-00. In > brief, the draft proposes swapping the priorities between FS and SF-P > (see section 4.3.2 of rfc6378). This proposed swap has a long history, > dating back to when PSC was an ID. For some history, see >=20 > http://datatracker.ietf.org/liaison/1229/ > and > http://datatracker.ietf.org/liaison/1234/ >=20 > The questions that I think are relevant here are: >=20 > - is it appropriate to make this priority swap? > - are there alternative approaches? > - what do we need to change? rfc5654? rfc4427? > - if we don't make the change, does this expose implementation to > problems? > - if we do make the change, how do we go about it? >=20 > but of course any and all discussion is welcome. >=20 > As with the other threads I'm going to leave my two cents out of this > introductory email but I'll chime in when discussion starts. >=20 >=20 >=20 >=20 >=20 > eric > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione > derivante dalla conoscenza di queste informazioni sono rigorosamente > vietate. Qualora abbiate ricevuto questo documento per errore siete > cortesemente pregati di darne immediata comunicazione al mittente e di > provvedere alla sua distruzione, Grazie. >=20 > This e-mail and any attachments is confidential and may contain > privileged information intended for the addressee(s) only. > Dissemination, copying, printing or use by anybody else is unauthorised. > If you are not the intended recipient, please delete this message and > any attachments and advise the sender by return e-mail, Thanks. From alessandro.dalessandro@telecomitalia.it Thu May 9 12:52:33 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9D921F914C for ; Thu, 9 May 2013 12:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.069 X-Spam-Level: X-Spam-Status: No, score=-1.069 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AWFreJUei8a4 for ; Thu, 9 May 2013 12:52:29 -0700 (PDT) Received: from GRFEDG701RM001.telecomitalia.it (grfedg701rm001.telecomitalia.it [217.169.121.20]) by ietfa.amsl.com (Postfix) with ESMTP id A02D421F8CE2 for ; Thu, 9 May 2013 12:52:27 -0700 (PDT) Received: from TELCAH004RM001.telecomitalia.local (10.19.10.108) by GRFEDG701RM001.telecomitalia.it (10.173.88.20) with Microsoft SMTP Server (TLS) id 8.3.297.1; Thu, 9 May 2013 21:52:26 +0200 Received: from TELMBB002RM001.telecomitalia.local ([169.254.3.100]) by TELCAH004RM001.telecomitalia.local ([10.19.10.108]) with mapi id 14.02.0328.009; Thu, 9 May 2013 21:52:25 +0200 From: D'Alessandro Alessandro Gerardo To: "Eric Osborne (eosborne)" , "mpls@ietf.org" Thread-Topic: PSC: draft-rhd-mpls-tp-psc-priority-00 Thread-Index: Ac47ZD1tB/jb+CaKQqOehjxMIOgzIgP835SQAFx1EZAAA1tM4A== Date: Thu, 9 May 2013 19:52:25 +0000 Message-ID: <22257C41A415324A984CD03D63344E270A475D21@TELMBB002RM001.telecomitalia.local> References: <20ECF67871905846A80F77F8F4A2757210150296@xmb-rcd-x09.cisco.com> <22257C41A415324A984CD03D63344E270A4750F7@TELMBB002RM001.telecomitalia.local> <20ECF67871905846A80F77F8F4A275721019F7F7@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A275721019F7F7@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.19.10.75] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Morro Roberto , Allasia Andrea , Nervo Giacolino Subject: [mpls] R: PSC: draft-rhd-mpls-tp-psc-priority-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 19:52:33 -0000 Hi Eric, Please see my answer in line... Best regards, Alessandro -----Messaggio originale----- Da: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] Inviato: gioved=EC 9 maggio 2013 17:41 A: D'Alessandro Alessandro Gerardo; mpls@ietf.org Cc: Cavazzoni Carlo; Allasia Andrea; Nervo Giacolino; Morro Roberto; ryoo@e= tri.re.kr; lifang@catr.cn; cts@etri.re.kr Oggetto: RE: PSC: draft-rhd-mpls-tp-psc-priority-00 Hi Alessandro, see inline. > -----Original Message----- > From: D'Alessandro Alessandro Gerardo > [mailto:alessandro.dalessandro@telecomitalia.it] > Sent: Tuesday, May 07, 2013 3:27 PM > To: Eric Osborne (eosborne); mpls@ietf.org > Cc: Cavazzoni Carlo; Allasia Andrea; Nervo Giacolino; Morro Roberto; > ryoo@etri.re.kr; lifang@catr.cn; cts@etri.re.kr > Subject: R: PSC: draft-rhd-mpls-tp-psc-priority-00 > > Hi Eric, > You wrote "is it appropriate to make this priority swap?" > My answer is yes, it shall be done for the reasons explained in liaison > 1205, bullet 1. Let me paraphrase the three points in those bullets, I want to make sure I = understand them: a. If the protection path fails then the removal of the FS will not be seen= because the channel used to provide it is gone. b. If there is SF-P and FS is issued by accident then this will cause an ou= tage, which is Bad c. (points to Annex 1): similar to (a) above, the loss of the protection ch= annel means there will be an inconsistency in the protection state Is that an accurate paraphrase? [D'Alessandro] about point a, your statement is correct but does not addres= s the actual issue. A more accurate interpretation is: If the protection pa= th fails then service cannot recover promptly and it is interrupted because= FS priority is higher than the SF-P priority. > You wrote "- what do we need to change? rfc5654? rfc4427? " > No I don't believe it is required to change any RFC but RFC 6378 To me this decision is a matter of process rather than of technical behavio= r. I believe the current set of opinions is this: a) some believe that rfc4427 requires the current set of priorities, as per= LS1174 point #1 (http://datatracker.ietf.org/liaison/1174/) b) some believe it does not, and that rfc6378 misinterpreted rfc4427 I think we all agree that the chain here is: 6378 must obey 5654, and that = 5654 requires 4427. [D'Alessandro] I would prefer saying that 6378 must obey 5654, and that 565= 4 references 4427 in informative way. So it's going to come down to - is 4427 written wrong but interpreted corre= ctly, or written correctly but misinterpreted? If we decide the former, we need to change 4427 and/or 5654 to clarify the = requirement. If we decide the latter, we do not need to change 4427 and can probably jus= t change 6378. Does that sound right? [D'Alessandro] yes, it does. [D'Alessandro] Anyway I would like highlighting that according to RFC5654 R= 83A "External controls ... unable to be signaled to the remote end (e.g., = due to a coordination failure of the protection state) MUST be dropped". Th= is requirement stated in RFC5654 applies to FS too and it appears to me ove= rruling RFC 4427 which is referenced in an informative way from RFC5654. eric > > Best regards, > Alessandro > > ------------------------------------------------------------------ > Telecom Italia > Alessandro Gerardo D'Alessandro > Transport Innovation > Via Reiss Romoli, 274 - 10148 Torino > phone: +39 011 228 5887 > mobile: +39 335 766 9607 > fax: +39 06 418 639 07 > > > -----Messaggio originale----- > Da: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Per conto di > Eric Osborne (eosborne) > Inviato: mercoled=EC 17 aprile 2013 14:16 > A: mpls@ietf.org > Oggetto: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00 > > This thread is for discussing draft-rhd-mpls-tp-psc-priority-00. In > brief, the draft proposes swapping the priorities between FS and SF-P > (see section 4.3.2 of rfc6378). This proposed swap has a long history, > dating back to when PSC was an ID. For some history, see > > http://datatracker.ietf.org/liaison/1229/ > and > http://datatracker.ietf.org/liaison/1234/ > > The questions that I think are relevant here are: > > - is it appropriate to make this priority swap? > - are there alternative approaches? > - what do we need to change? rfc5654? rfc4427? > - if we don't make the change, does this expose implementation to > problems? > - if we do make the change, how do we go about it? > > but of course any and all discussion is welcome. > > As with the other threads I'm going to leave my two cents out of this > introductory email but I'll chime in when discussion starts. > > > > > > eric > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione > derivante dalla conoscenza di queste informazioni sono rigorosamente > vietate. Qualora abbiate ricevuto questo documento per errore siete > cortesemente pregati di darne immediata comunicazione al mittente e di > provvedere alla sua distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain > privileged information intended for the addressee(s) only. > Dissemination, copying, printing or use by anybody else is unauthorised. > If you are not the intended recipient, please delete this message and > any attachments and advise the sender by return e-mail, Thanks. Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From wwwrun@rfc-editor.org Thu May 9 13:43:49 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 327E021F8EBC; Thu, 9 May 2013 13:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.825 X-Spam-Level: X-Spam-Status: No, score=-101.825 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FBS4FpEAjHCq; Thu, 9 May 2013 13:43:48 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 8D51F21F8E4C; Thu, 9 May 2013 13:43:48 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 8C166B1E003; Thu, 9 May 2013 13:43:35 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130509204335.8C166B1E003@rfc-editor.org> Date: Thu, 9 May 2013 13:43:35 -0700 (PDT) Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 6923 on MPLS Transport Profile (MPLS-TP) Identifiers Following ITU-T Conventions X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 20:43:49 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6923 Title: MPLS Transport Profile (MPLS-TP) Identifiers Following ITU-T Conventions Author: R. Winter, E. Gray, H. van Helvoort, M. Betts Status: Standards Track Stream: IETF Date: May 2013 Mailbox: rolf.winter@neclab.eu, eric.gray@ericsson.com, huub.van.helvoort@huawei.com, malcolm.betts@zte.com.cn Pages: 12 Characters: 23811 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-tp-itu-t-identifiers-08.txt URL: http://www.rfc-editor.org/rfc/rfc6923.txt This document specifies an extension to the identifiers to be used in the Transport Profile of Multiprotocol Label Switching (MPLS-TP). Identifiers that follow IP/MPLS conventions have already been defined. This memo augments that set of identifiers for MPLS-TP management and Operations, Administration, and Maintenance (OAM) functions to include identifier information in a format typically used by the International Telecommunication Union Telecommunication Standardization Sector (ITU-T). This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard. 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 Association Management Solutions, LLC From lberger@labn.net Thu May 9 14:25:34 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC1E921F8FD0 for ; Thu, 9 May 2013 14:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.121 X-Spam-Level: X-Spam-Status: No, score=-102.121 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UVBUH0tkemGe for ; Thu, 9 May 2013 14:25:28 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id ECCF021F8EF7 for ; Thu, 9 May 2013 14:25:27 -0700 (PDT) Received: (qmail 17014 invoked by uid 0); 9 May 2013 21:25:05 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 9 May 2013 21:25:05 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=MEJR0o7x67nDZFcz04bq0eRYXCAR0KjGZE+q91YV2/Q=; b=jHkgLRQWN+s+SbeDK4oNQIaNDJ/rTUrHKX2TgZ9fhMFqRoyU8r5zVr06i3t0Me3jri/hcIfVc/Ns9HH5kxT+LKo4rTA/KsUpNuA5NGyNvZfrGxCMFGa21vW4d+P+Fuku; Received: from box313.bluehost.com ([69.89.31.113]:45567 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UaYKn-0003ql-FB; Thu, 09 May 2013 15:25:05 -0600 Message-ID: <518C1431.70204@labn.net> Date: Thu, 09 May 2013 17:25:05 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Eric Osborne (eosborne)" References: <20ECF67871905846A80F77F8F4A2757210150296@xmb-rcd-x09.cisco.com> <22257C41A415324A984CD03D63344E270A4750F7@TELMBB002RM001.telecomitalia.local> <20ECF67871905846A80F77F8F4A275721019F7F7@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A275721019F7F7@xmb-rcd-x09.cisco.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "mpls@ietf.org" , Morro Roberto , Allasia Andrea , Nervo Giacolino Subject: Re: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 21:25:34 -0000 Eric, I think you might have missed that rfc6372 section 6.1.2 is consistent with RFC4427. So perhaps it would be best to have a standalone draft/rfc that updates both rfc6372 and rfc4427 on this specific point alone. If this is done, no change to rfc5654 is needed. Lou On 5/9/2013 11:40 AM, Eric Osborne (eosborne) wrote: > Hi Alessandro, see inline. > >> -----Original Message----- >> From: D'Alessandro Alessandro Gerardo >> [mailto:alessandro.dalessandro@telecomitalia.it] >> Sent: Tuesday, May 07, 2013 3:27 PM >> To: Eric Osborne (eosborne); mpls@ietf.org >> Cc: Cavazzoni Carlo; Allasia Andrea; Nervo Giacolino; Morro Roberto; >> ryoo@etri.re.kr; lifang@catr.cn; cts@etri.re.kr >> Subject: R: PSC: draft-rhd-mpls-tp-psc-priority-00 >> >> Hi Eric, >> You wrote "is it appropriate to make this priority swap?" >> My answer is yes, it shall be done for the reasons explained in liaison >> 1205, bullet 1. > > Let me paraphrase the three points in those bullets, I want to make sure I understand them: > > a. If the protection path fails then the removal of the FS will not be seen because the channel used to provide it is gone. > b. If there is SF-P and FS is issued by accident then this will cause an outage, which is Bad > c. (points to Annex 1): similar to (a) above, the loss of the protection channel means there will be an inconsistency in the protection state > > Is that an accurate paraphrase? > >> You wrote "- what do we need to change? rfc5654? rfc4427? " >> No I don't believe it is required to change any RFC but RFC 6378 > > To me this decision is a matter of process rather than of technical behavior. > I believe the current set of opinions is this: > > a) some believe that rfc4427 requires the current set of priorities, as per LS1174 point #1 (http://datatracker.ietf.org/liaison/1174/) > b) some believe it does not, and that rfc6378 misinterpreted rfc4427 > > I think we all agree that the chain here is: 6378 must obey 5654, and that 5654 requires 4427. > > So it's going to come down to - is 4427 written wrong but interpreted correctly, or written correctly but misinterpreted? > If we decide the former, we need to change 4427 and/or 5654 to clarify the requirement. > If we decide the latter, we do not need to change 4427 and can probably just change 6378. > > Does that sound right? > > > > eric > >> >> Best regards, >> Alessandro >> >> ------------------------------------------------------------------ >> Telecom Italia >> Alessandro Gerardo D'Alessandro >> Transport Innovation >> Via Reiss Romoli, 274 - 10148 Torino >> phone: +39 011 228 5887 >> mobile: +39 335 766 9607 >> fax: +39 06 418 639 07 >> >> >> -----Messaggio originale----- >> Da: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Per conto di >> Eric Osborne (eosborne) >> Inviato: mercoledì 17 aprile 2013 14:16 >> A: mpls@ietf.org >> Oggetto: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00 >> >> This thread is for discussing draft-rhd-mpls-tp-psc-priority-00. In >> brief, the draft proposes swapping the priorities between FS and SF-P >> (see section 4.3.2 of rfc6378). This proposed swap has a long history, >> dating back to when PSC was an ID. For some history, see >> >> http://datatracker.ietf.org/liaison/1229/ >> and >> http://datatracker.ietf.org/liaison/1234/ >> >> The questions that I think are relevant here are: >> >> - is it appropriate to make this priority swap? >> - are there alternative approaches? >> - what do we need to change? rfc5654? rfc4427? >> - if we don't make the change, does this expose implementation to >> problems? >> - if we do make the change, how do we go about it? >> >> but of course any and all discussion is welcome. >> >> As with the other threads I'm going to leave my two cents out of this >> introductory email but I'll chime in when discussion starts. >> >> >> >> >> >> eric >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle >> persone indicate. La diffusione, copia o qualsiasi altra azione >> derivante dalla conoscenza di queste informazioni sono rigorosamente >> vietate. Qualora abbiate ricevuto questo documento per errore siete >> cortesemente pregati di darne immediata comunicazione al mittente e di >> provvedere alla sua distruzione, Grazie. >> >> This e-mail and any attachments is confidential and may contain >> privileged information intended for the addressee(s) only. >> Dissemination, copying, printing or use by anybody else is unauthorised. >> If you are not the intended recipient, please delete this message and >> any attachments and advise the sender by return e-mail, Thanks. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > > > From Alexander.Vainshtein@ecitele.com Thu May 9 19:30:56 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5603921F8539 for ; Thu, 9 May 2013 19:30:56 -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, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2JWYKm7FMzZX for ; Thu, 9 May 2013 19:30:51 -0700 (PDT) Received: from mail1.bemta14.messagelabs.com (mail1.bemta14.messagelabs.com [193.109.254.107]) by ietfa.amsl.com (Postfix) with ESMTP id 8289E21F89D5 for ; Thu, 9 May 2013 19:30:50 -0700 (PDT) Received: from [193.109.254.147:11141] by server-3.bemta-14.messagelabs.com id E9/87-06484-9DB5C815; Fri, 10 May 2013 02:30:49 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-12.tower-27.messagelabs.com!1368153047!8752349!1 X-Originating-IP: [147.234.242.234] X-StarScan-Received: X-StarScan-Version: 6.9.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 24031 invoked from network); 10 May 2013 02:30:48 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-12.tower-27.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 May 2013 02:30:48 -0000 X-AuditID: 93eaf2e7-b7f9d6d00000657d-e7-518c5bd70f56 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 11.90.25981.7DB5C815; Fri, 10 May 2013 05:30:47 +0300 (IDT) Received: from ILPTWPVEXCA02.ecitele.com (172.31.244.232) by ILPTEXCH02.ecitele.com (147.234.245.181) with Microsoft SMTP Server (TLS) id 8.3.264.0; Fri, 10 May 2013 05:30:47 +0300 Received: from ILPTWPVEXMB01.ecitele.com ([fe80::f152:8eaf:8fb0:a5da]) by ILPTWPVEXCA02.ecitele.com ([fe80::c473:490d:3a7e:e34a%12]) with mapi id 14.03.0123.003; Fri, 10 May 2013 05:30:46 +0300 From: Alexander Vainshtein To: "adrian@olddog.co.uk" , "Stewart Bryant (stbryant@cisco.com)" Thread-Topic: I-D Action: draft-farbryantrel-mpls-retire-ach-tlv-00.txt Thread-Index: AQHOS0CccENP5txSYUOKcNTl14UKAZj9tI2Z Date: Fri, 10 May 2013 02:30:46 +0000 Message-ID: References: <20130507163315.5251.24612.idtracker@ietfa.amsl.com> In-Reply-To: <20130507163315.5251.24612.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.1.1] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupil+LIzCtJLcpLzFFi42KZ/OrTF93r0T2BBr0TFSxuLV3JanHu6RxG ByaPKb83snosWfKTKYApqoHRJjEvL78ksSRVISW1ONlWKaAosywxuVJJITPFVslQSaEgJzE5 NTc1r8RWKbGgIDUvRcmOSwED2ACVZeYppOYl56dk5qXbKnkG++taWJha6hoq2akpGxpbc4Vk ZBYrpOrmJmbmKOSmFhcnpqcqAEUStjBntPbOYiq4LlRxYUMPYwPjS74uRk4OCQETiSNPL7NA 2GISF+6tZ+ti5OIQEtjPKHFtVyMThLODUWLZqcUsEM5RRonX37+wgbSwCdhKbFp9F8wWEciV uNS2irWLkYODWUBZ4tRdGZCwsICbRMfxaVAl7hJrZz6Cso0kFj5cwAxiswioSqw93csKYvMK BEjc3nUFzBYScJDoPNcGVsMp4CjRc24xO4jNCHTp91NrmEBsZgFxiVtP5jNBfCAgsWTPeWYI W1Ti5eN/rBC2vMTFDw+g6nUkFuz+xAZha0ssW/iaGWKvoMTJmU9YIPbqSpw60QU1U1Li4Iob LBMYJWchWTcLyahZSEbNQjJqASPLKkbRzJyCkqTcdANDvdTkzJLUnFS95PzcTYyQxPN8B+Ov +SqHGAU4GJV4eD32dAcKsSaWFVfmHmKU5GBSEuXlCewJFOJLyk+pzEgszogvKs1JLT7EKMHB rCTCu2EDUDlvSmJlVWpRPkzKFRiaE5mluJPzgck0ryTe2MAAN0dJnHd5Q7i/kEA6MGlmp6YW pBbBzJHh4FCS4P0aBbResCg1PbUiLTOnBCHNxMEJcgYP0BncwOQvxFtckJhbnJkOkT/FqMux YvPL14xCLHn5ealS4rw3QAYJgBRllObBzYFloVeM4sAAEOblBRnFA8xgcJNeAS1hAlqSFQPy azEwC8GlpBoYV3ZP47/3Qjnnz4T4rifKv7NOzlS5s8Z9k7p+/pKDj1xFF1zhTn4UHG4q1yKw qUXfiGe51ikrpWnMrVm28wKf1b9duatDb+tEL4t5GltXfZLti6/V/JNY7VlrqHyNS8Dz0rNf 85Unm6y1NPv8x3fhhS2LhHkvSbsfX31G9FN/haC0EuuO2TM2KrEUZyQaajEXFScCAE7QnQAd BAAA Cc: "mpls@ietf.org" Subject: Re: [mpls] I-D Action: draft-farbryantrel-mpls-retire-ach-tlv-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 02:30:56 -0000 Stewart, Adrian and all, Late is better than never! (I must admit that I never understood the need for generic TLVs preceding G-= ACH messages. Looks as I was not the only one, since, so far, nobody has defined any such.= ..) Hopefully the WG and the IESG will handle this I-D fast enough. Regards, Sasha ________________________________________ From: i-d-announce-bounces@ietf.org [i-d-announce-bounces@ietf.org] on behal= f of internet-drafts@ietf.org [internet-drafts@ietf.org] Sent: Tuesday, May 07, 2013 6:33 PM To: i-d-announce@ietf.org Subject: I-D Action: draft-farbryantrel-mpls-retire-ach-tlv-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directori= es. Title : Retiring TLVs from the Associated Channel Header o= f the MPLS Generic Associated Channel Author(s) : Adrian Farrel Stewart Bryant Filename : draft-farbryantrel-mpls-retire-ach-tlv-00.txt Pages : 4 Date : 2013-05-07 Abstract: The MPLS Generic Associated Channel (G-ACh) is a generalization of the applicability of the Pseudowire (PW) Associated Channel Header (ACH). RFC 5586 defines the concept of Type-Length-Variable (TLV) constructs that can be carried in messages on the G-ACh by placing them in the ACH. No Associated Channel Type yet defined uses a TLV. Furthermore, it is believed that handling TLVs in hardware introduces significant problems to the fast-path, and since G-ACh messages are intended to be processed substantially in hardware, the use of TLVs in undesirable. This document updates RFC 5586 by retiring ACH TLVs and removing the associated registry. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-farbryantrel-mpls-retire-ach-tlv There's also a htmlized version available at: http://tools.ietf.org/html/draft-farbryantrel-mpls-retire-ach-tlv-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt This e-mail message is intended for the recipient only and contains informat= ion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If yo= u have received this transmission in error, please inform us by e-mail, phon= e or fax, and then delete the original and all copies thereof. From internet-drafts@ietf.org Fri May 10 06:50:12 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7335121F9026; Fri, 10 May 2013 06:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7g9qsC+NWkT; Fri, 10 May 2013 06:50:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D836721F9019; Fri, 10 May 2013 06:50:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p7 Message-ID: <20130510135011.21484.16683.idtracker@ietfa.amsl.com> Date: Fri, 10 May 2013 06:50:11 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-ip-pw-capability-05.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 13:50:12 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Disabling IPoMPLS and P2P PW LDP Application's State Adv= ertisement Author(s) : Kamran Raza Sami Boutros Filename : draft-ietf-mpls-ldp-ip-pw-capability-05.txt Pages : 13 Date : 2013-05-09 Abstract: Currently, no LDP capability is exchanged for LDP applications like IP Label Switching and L2VPN P2P PW signaling. When an LDP session comes up, an LDP speaker may unnecessarily advertise its local state for such LDP applications even when the peer session is established for some other applications like mLDP or ICCP. This document defines a solution by which an LDP speaker announces to its peer its disinterest in such non-negotiated applications. This, in turn, disables the advertisement of corresponding application state, which would have otherwise be advertised by default, over the established LDP session. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-ip-pw-capability There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-ip-pw-capability-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-ldp-ip-pw-capability-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From db3546@att.com Fri May 10 08:04:40 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 949C421F8B64 for ; Fri, 10 May 2013 08:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7NOQIsnU6K2 for ; Fri, 10 May 2013 08:04:34 -0700 (PDT) Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2EA21F8B2B for ; Fri, 10 May 2013 08:04:34 -0700 (PDT) Received: from unknown [144.160.20.146] (EHLO nbfkord-smmo05.seg.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 28c0d815.2aaaf5a48940.157114.00-576.425696.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 10 May 2013 15:04:34 +0000 (UTC) X-MXL-Hash: 518d0c8221fd42d4-6d0708bde05ab40a5775bb9f339829051959be86 Received: from unknown [144.160.20.146] (EHLO mlpd194.enaf.sfdc.sbc.com) by nbfkord-smmo05.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id 18c0d815.0.157106.00-479.425667.nbfkord-smmo05.seg.att.com (envelope-from ); Fri, 10 May 2013 15:04:33 +0000 (UTC) X-MXL-Hash: 518d0c81655bdee0-b4f757712485948647ad2ad459ef10c5d8e1ef2f Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4AF4Wg1016882; Fri, 10 May 2013 11:04:33 -0400 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by mlpd194.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id r4AF4Oke016748 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 May 2013 11:04:27 -0400 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Fri, 10 May 2013 15:04:12 GMT Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([144.151.223.75]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.02.0342.003; Fri, 10 May 2013 11:04:12 -0400 From: "BRUNGARD, DEBORAH A" To: Lou Berger , "Eric Osborne (eosborne)" Thread-Topic: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00 Thread-Index: Ac47ZD1tB/jb+CaKQqOehjxMIOgzIgP835SQAFx1EZAAFOjRgAAbKFJw Date: Fri, 10 May 2013 15:04:12 +0000 Message-ID: References: <20ECF67871905846A80F77F8F4A2757210150296@xmb-rcd-x09.cisco.com> <22257C41A415324A984CD03D63344E270A4750F7@TELMBB002RM001.telecomitalia.local> <20ECF67871905846A80F77F8F4A275721019F7F7@xmb-rcd-x09.cisco.com> <518C1431.70204@labn.net> In-Reply-To: <518C1431.70204@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.214] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.146] X-AnalysisOut: [v=2.0 cv=M6z63VMs c=1 sm=0 a=Qs8R1XBwmid1qBFB/a8mmA==:17 a] X-AnalysisOut: [=RWEAq7CW3jcA:10 a=eeLOSi2EoM8A:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=8nJEP1OIZ-IA:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=LUSkZWHcu0cA:10 a=48vgC7mUAAAA:8 a=6n3J-JnjD85qh8] X-AnalysisOut: [gd4KwA:9 a=wPNLvfGTeEIA:10 a=I7u-ks9roaUA:10 a=lZB815dzVvQ] X-AnalysisOut: [A:10 a=Hr59RgoP3KgA:10 a=68PJXqtGKPpLVetU:21 a=iIDo4RZNUUw] X-AnalysisOut: [icBvi:21] Cc: "mpls@ietf.org" , Morro Roberto , Allasia Andrea , Nervo Giacolino Subject: Re: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 15:04:40 -0000 Hi, Agree with Lou, an update would be good for these documents considering the= confusion. As an author on RFC4427, it's intent was as an informative, generalized doc= ument on all types of recovery schemes. The definitions were (quite) shorte= ned and so in this case the 2nd paragraph of G.808.1's definition regarding= APS specifics was not included. RFC4427 didn't discuss state machines or a= ny details of any specific scheme. When generalize, it helps with readabili= ty but there is always the danger of missed details. So on Eric's items, it= falls under a third bullet: "written correctly though lacking in detail ca= using mis-interpretation":-) RFC4427 fully intended to align with the ITU-T terminology and in the Recov= ery Terminology Section (Section 4) referred the reader to the ITU-T Recomm= endations: "The reader is invited to read [G.841] and [G.808.1] for references to SDH protection and Generic Protection Switching terminology, respectively." Thanks, Deborah -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Lou= Berger Sent: Thursday, May 09, 2013 5:25 PM To: Eric Osborne (eosborne) Cc: mpls@ietf.org; Morro Roberto; Allasia Andrea; Nervo Giacolino Subject: Re: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00 Eric, I think you might have missed that rfc6372 section 6.1.2 is consistent with RFC4427. So perhaps it would be best to have a standalone draft/rfc that updates both rfc6372 and rfc4427 on this specific point alone. If this is done, no change to rfc5654 is needed. Lou On 5/9/2013 11:40 AM, Eric Osborne (eosborne) wrote: > Hi Alessandro, see inline. >=20 >> -----Original Message----- >> From: D'Alessandro Alessandro Gerardo >> [mailto:alessandro.dalessandro@telecomitalia.it] >> Sent: Tuesday, May 07, 2013 3:27 PM >> To: Eric Osborne (eosborne); mpls@ietf.org >> Cc: Cavazzoni Carlo; Allasia Andrea; Nervo Giacolino; Morro Roberto; >> ryoo@etri.re.kr; lifang@catr.cn; cts@etri.re.kr >> Subject: R: PSC: draft-rhd-mpls-tp-psc-priority-00 >> >> Hi Eric, >> You wrote "is it appropriate to make this priority swap?" >> My answer is yes, it shall be done for the reasons explained in liaison >> 1205, bullet 1. >=20 > Let me paraphrase the three points in those bullets, I want to make sure = I understand them: >=20 > a. If the protection path fails then the removal of the FS will not be se= en because the channel used to provide it is gone. > b. If there is SF-P and FS is issued by accident then this will cause an = outage, which is Bad > c. (points to Annex 1): similar to (a) above, the loss of the protection = channel means there will be an inconsistency in the protection state >=20 > Is that an accurate paraphrase? >=20 >> You wrote "- what do we need to change? rfc5654? rfc4427? " >> No I don't believe it is required to change any RFC but RFC 6378 >=20 > To me this decision is a matter of process rather than of technical behav= ior. =20 > I believe the current set of opinions is this: >=20 > a) some believe that rfc4427 requires the current set of priorities, as p= er LS1174 point #1 (http://datatracker.ietf.org/liaison/1174/) > b) some believe it does not, and that rfc6378 misinterpreted rfc4427 >=20 > I think we all agree that the chain here is: 6378 must obey 5654, and tha= t 5654 requires 4427. >=20 > So it's going to come down to - is 4427 written wrong but interpreted cor= rectly, or written correctly but misinterpreted? > If we decide the former, we need to change 4427 and/or 5654 to clarify th= e requirement. > If we decide the latter, we do not need to change 4427 and can probably j= ust change 6378. >=20 > Does that sound right? >=20 >=20 >=20 > eric >=20 >> >> Best regards, >> Alessandro >> >> ------------------------------------------------------------------ >> Telecom Italia >> Alessandro Gerardo D'Alessandro >> Transport Innovation >> Via Reiss Romoli, 274 - 10148 Torino >> phone: +39 011 228 5887 >> mobile: +39 335 766 9607 >> fax: +39 06 418 639 07 >> >> >> -----Messaggio originale----- >> Da: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Per conto di >> Eric Osborne (eosborne) >> Inviato: mercoled=EC 17 aprile 2013 14:16 >> A: mpls@ietf.org >> Oggetto: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00 >> >> This thread is for discussing draft-rhd-mpls-tp-psc-priority-00. In >> brief, the draft proposes swapping the priorities between FS and SF-P >> (see section 4.3.2 of rfc6378). This proposed swap has a long history, >> dating back to when PSC was an ID. For some history, see >> >> http://datatracker.ietf.org/liaison/1229/ >> and >> http://datatracker.ietf.org/liaison/1234/ >> >> The questions that I think are relevant here are: >> >> - is it appropriate to make this priority swap? >> - are there alternative approaches? >> - what do we need to change? rfc5654? rfc4427? >> - if we don't make the change, does this expose implementation to >> problems? >> - if we do make the change, how do we go about it? >> >> but of course any and all discussion is welcome. >> >> As with the other threads I'm going to leave my two cents out of this >> introductory email but I'll chime in when discussion starts. >> >> >> >> >> >> eric >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> >> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle >> persone indicate. La diffusione, copia o qualsiasi altra azione >> derivante dalla conoscenza di queste informazioni sono rigorosamente >> vietate. Qualora abbiate ricevuto questo documento per errore siete >> cortesemente pregati di darne immediata comunicazione al mittente e di >> provvedere alla sua distruzione, Grazie. >> >> This e-mail and any attachments is confidential and may contain >> privileged information intended for the addressee(s) only. >> Dissemination, copying, printing or use by anybody else is unauthorised. >> If you are not the intended recipient, please delete this message and >> any attachments and advise the sender by return e-mail, Thanks. >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 >=20 >=20 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From internet-drafts@ietf.org Fri May 10 09:15:48 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D30721F854D; Fri, 10 May 2013 09:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.526 X-Spam-Level: X-Spam-Status: No, score=-102.526 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjfbEQCDY+AE; Fri, 10 May 2013 09:15:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D5E5B21F84D4; Fri, 10 May 2013 09:15:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p7 Message-ID: <20130510161547.11440.63136.idtracker@ietfa.amsl.com> Date: Fri, 10 May 2013 09:15:47 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-dod-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 16:15:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : LDP Downstream-on-Demand in Seamless MPLS Author(s) : Thomas Beckhaus Bruno Decraene Kishore Tiruveedhula Maciek Konstantynowicz Luca Martini Filename : draft-ietf-mpls-ldp-dod-06.txt Pages : 33 Date : 2013-05-10 Abstract: Seamless MPLS design enables a single IP/MPLS network to scale over core, metro and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access, including high number of devices, their position in network topology and their compute and memory constraints that limit the amount of state access devices can hold.This can be achieved with LDP Downstream-on-Demand (LDP DoD) label advertisement. This document describes LDP DoD use cases and lists required LDP DoD procedures in the context of Seamless MPLS design. In addition, a new optional TLV type in the LDP Label Request message is defined for fast-up convergence. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-dod There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-dod-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-ldp-dod-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jhaas@slice.pfrc.org Fri May 10 10:24:47 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556B221F8E6E; Fri, 10 May 2013 10:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5i21cFT1Qb6; Fri, 10 May 2013 10:24:42 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B8B2621F8E62; Fri, 10 May 2013 10:24:41 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 2D96CC27A; Fri, 10 May 2013 13:24:41 -0400 (EDT) Date: Fri, 10 May 2013 13:24:41 -0400 From: Jeffrey Haas To: Sam Aldrin Message-ID: <20130510172441.GB12732@pfrc> References: <4A6CE49E6084B141B15C0713B8993F281BD38595@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF11201E91E@eusaamb103.ericsson.se> <0C8935EE66D53445A3D3982BD9BE546815573400@xmb-aln-x09.cisco.com> <0C709968-C915-4CDA-98E5-361E67D4C923@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0C709968-C915-4CDA-98E5-361E67D4C923@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "Santiago Alvarez \(saalvare\)" , "rtg-bfd@ietf.org" , "pwe3@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] Commenst on draft-akiya-bfd-intervals-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 17:24:47 -0000 On Mon, Dec 03, 2012 at 11:53:47AM -0800, Sam Aldrin wrote: > I echo what Santiago had said in his email. Good to have an informational document and do not support the idea of standardizing the intervals. Speaking as chair, while I'm not in favor of have a standardized set of intervals (the fights such a document would create would be epic), I am highly supportive of such a document having informational status. As a suggestion, there may be two actual documents in such a case: - An informational document covering the intervals. - A short document, potentially on the standards track, covering the procedure by which timers can negotiate to such an interval. This may be worth standardizing. (This is covered by Appendix B.) -- Jeff From nitinb@juniper.net Fri May 10 11:22:35 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC48D21F901B for ; Fri, 10 May 2013 11:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.467 X-Spam-Level: X-Spam-Status: No, score=-3.467 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNRESOLVED_TEMPLATE=3.132] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-foG3jusDCg for ; Fri, 10 May 2013 11:22:30 -0700 (PDT) Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id BEA1D21F9017 for ; Fri, 10 May 2013 11:22:29 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKUY065ZfcspcG2b7xGeLzJpDCXooAU0tk@postini.com; Fri, 10 May 2013 11:22:29 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 10 May 2013 11:21:38 -0700 Received: from o365mail.juniper.net (207.17.137.224) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Fri, 10 May 2013 11:21:37 -0700 Received: from co1outboundpool.messaging.microsoft.com (216.32.180.188) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 10 May 2013 11:32:31 -0700 Received: from mail185-co1-R.bigfish.com (10.243.78.245) by CO1EHSOBE009.bigfish.com (10.243.66.72) with Microsoft SMTP Server id 14.1.225.23; Fri, 10 May 2013 18:21:33 +0000 Received: from mail185-co1 (localhost [127.0.0.1]) by mail185-co1-R.bigfish.com (Postfix) with ESMTP id 65E0D8C0405 for ; Fri, 10 May 2013 18:21:33 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -27 X-BigFish: PS-27(zzbb2dI98dI9371I936eI542I1432I4015Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275dhz2dh2a8h668h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1d0ch1d2eh1d3fh1155h) Received: from mail185-co1 (localhost.localdomain [127.0.0.1]) by mail185-co1 (MessageSwitch) id 1368210091519237_23593; Fri, 10 May 2013 18:21:31 +0000 (UTC) Received: from CO1EHSMHS002.bigfish.com (unknown [10.243.78.252]) by mail185-co1.bigfish.com (Postfix) with ESMTP id 7C1B79E0050; Fri, 10 May 2013 18:21:31 +0000 (UTC) Received: from SN2PRD0510HT001.namprd05.prod.outlook.com (157.56.234.117) by CO1EHSMHS002.bigfish.com (10.243.66.12) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 10 May 2013 18:21:29 +0000 Received: from SN2PRD0510MB383.namprd05.prod.outlook.com ([169.254.10.62]) by SN2PRD0510HT001.namprd05.prod.outlook.com ([10.255.116.36]) with mapi id 14.16.0305.001; Fri, 10 May 2013 18:21:24 +0000 From: Nitin Bahadur To: "adrian@olddog.co.uk" , "mpls@ietf.org" Thread-Topic: [mpls] Retiring ACH TLVs Thread-Index: Ac5LRX560irUVDlgRIKUWSY/7OcnkACKv34A Date: Fri, 10 May 2013 18:21:23 +0000 Message-ID: In-Reply-To: <002a01ce4b45$82e38ae0$88aaa0a0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.255.116.4] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%OLDDOG.CO.UK$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Subject: Re: [mpls] Retiring ACH TLVs X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 18:22:36 -0000 Fully support the ID. I was never a fan of ACH TLVs. Thanks Nitin Bahadur On 5/7/13 10:08 AM, "Adrian Farrel" wrote: >Hi, > >ACH TLVs keep popping up and causing Stewart and me trouble. Mainly it is >about explaining why no-one actually wants to use them (i.e., when each >new ACH Type is defined and has a "No TLVs" written for it, we get asked >"why not?"). > >It seems to us that ACH TLVs are an idea that has been rejected. >Initially we thought they might be used (especially for identifiers), but >there seems to be good opinion that handling generic TLVs would be a pain. > >Since I was heavily responsible for insisting that ACH TLVs were included >in RFC 5586, it seems reasonable that I do the work to fix it. > >The I-D below retires ACH TLVs and handles the necessary registry changes. > >Note, of course, that structured data are still possible within >individual ACHs if the protocol spec for an individual ACH decides to >have them. > >We're directing this work to the MPLS working group because that is where >5586 was written. I have BCC'ed PWE3, L2VPN, and BFD for information. > >Thanks for any comments. > >As humble WG contributors we would be enthusiastic to see early WG >adoption and last call :-) > >Thanks, >Adrian > >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: 07 May 2013 17:33 >> To: Adrian Farrel; Stewart Bryant >> Subject: New Version Notification for >>draft-farbryantrel-mpls-retire-ach-tlv- >> 00.txt >>=20 >>=20 >> A new version of I-D, draft-farbryantrel-mpls-retire-ach-tlv-00.txt >> has been successfully submitted by Adrian Farrel and posted to the >> IETF repository. >>=20 >> Filename: draft-farbryantrel-mpls-retire-ach-tlv >> Revision: 00 >> Title: Retiring TLVs from the Associated Channel Header of the MPLS >> Generic Associated Channel >> Creation date: 2013-05-07 >> Group: Individual Submission >> Number of pages: 4 >> URL: =20 >>http://www.ietf.org/internet-drafts/draft-farbryantrel-mpls-retire- >> ach-tlv-00.txt >> Status: =20 >>http://datatracker.ietf.org/doc/draft-farbryantrel-mpls-retire-ach-tlv >> Htmlized: =20 >>http://tools.ietf.org/html/draft-farbryantrel-mpls-retire-ach-tlv-00 >>=20 >>=20 >> Abstract: >> The MPLS Generic Associated Channel (G-ACh) is a generalization of >> the applicability of the Pseudowire (PW) Associated Channel Header >> (ACH). RFC 5586 defines the concept of Type-Length-Variable (TLV) >> constructs that can be carried in messages on the G-ACh by placing >> them in the ACH. >>=20 >> No Associated Channel Type yet defined uses a TLV. Furthermore, it >> is believed that handling TLVs in hardware introduces significant >> problems to the fast-path, and since G-ACh messages are intended to >> be processed substantially in hardware, the use of TLVs in >> undesirable. >>=20 >> This document updates RFC 5586 by retiring ACH TLVs and removing the >> associated registry. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls > From giles.heron@gmail.com Fri May 10 11:37:14 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F3321F90C1 for ; Fri, 10 May 2013 11:37:14 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lKQd-whoDy0c for ; Fri, 10 May 2013 11:37:10 -0700 (PDT) Received: from cloud9-2.dh.bytemark.co.uk (cloud9-2.dh.bytemark.co.uk [89.16.179.42]) by ietfa.amsl.com (Postfix) with ESMTP id 87B9221F9021 for ; Fri, 10 May 2013 11:37:09 -0700 (PDT) Received: (qmail 23104 invoked by uid 0); 10 May 2013 18:37:08 -0000 Received: from unknown (HELO ?10.61.198.200?) (giles@gizzer.org@64.103.25.233) by cloud9-2.dh.bytemark.co.uk with ESMTPA; 10 May 2013 18:37:08 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Giles Heron In-Reply-To: Date: Fri, 10 May 2013 19:36:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Nitin Bahadur X-Mailer: Apple Mail (2.1503) Cc: "mpls@ietf.org" Subject: Re: [mpls] Retiring ACH TLVs X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 18:37:14 -0000 Likewise. ACH TLVs tripped me up when editing the PWE3 static status draft (now = RFC6478), so I'd be glad to be rid of them :) Giles On 10 May 2013, at 19:21, Nitin Bahadur wrote: >=20 > Fully support the ID. I was never a fan of ACH TLVs. >=20 > Thanks > Nitin Bahadur >=20 >=20 >=20 >=20 >=20 > On 5/7/13 10:08 AM, "Adrian Farrel" wrote: >=20 >> Hi, >>=20 >> ACH TLVs keep popping up and causing Stewart and me trouble. Mainly = it is >> about explaining why no-one actually wants to use them (i.e., when = each >> new ACH Type is defined and has a "No TLVs" written for it, we get = asked >> "why not?"). >>=20 >> It seems to us that ACH TLVs are an idea that has been rejected. >> Initially we thought they might be used (especially for identifiers), = but >> there seems to be good opinion that handling generic TLVs would be a = pain. >>=20 >> Since I was heavily responsible for insisting that ACH TLVs were = included >> in RFC 5586, it seems reasonable that I do the work to fix it. >>=20 >> The I-D below retires ACH TLVs and handles the necessary registry = changes. >>=20 >> Note, of course, that structured data are still possible within >> individual ACHs if the protocol spec for an individual ACH decides to >> have them. >>=20 >> We're directing this work to the MPLS working group because that is = where >> 5586 was written. I have BCC'ed PWE3, L2VPN, and BFD for information. >>=20 >> Thanks for any comments. >>=20 >> As humble WG contributors we would be enthusiastic to see early WG >> adoption and last call :-) >>=20 >> Thanks, >> Adrian >>=20 >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: 07 May 2013 17:33 >>> To: Adrian Farrel; Stewart Bryant >>> Subject: New Version Notification for >>> draft-farbryantrel-mpls-retire-ach-tlv- >>> 00.txt >>>=20 >>>=20 >>> A new version of I-D, draft-farbryantrel-mpls-retire-ach-tlv-00.txt >>> has been successfully submitted by Adrian Farrel and posted to the >>> IETF repository. >>>=20 >>> Filename: draft-farbryantrel-mpls-retire-ach-tlv >>> Revision: 00 >>> Title: Retiring TLVs from the Associated Channel = Header of the MPLS >>> Generic Associated Channel >>> Creation date: 2013-05-07 >>> Group: Individual Submission >>> Number of pages: 4 >>> URL: =20 >>> http://www.ietf.org/internet-drafts/draft-farbryantrel-mpls-retire- >>> ach-tlv-00.txt >>> Status: =20 >>> = http://datatracker.ietf.org/doc/draft-farbryantrel-mpls-retire-ach-tlv >>> Htmlized: =20 >>> http://tools.ietf.org/html/draft-farbryantrel-mpls-retire-ach-tlv-00 >>>=20 >>>=20 >>> Abstract: >>> The MPLS Generic Associated Channel (G-ACh) is a generalization of >>> the applicability of the Pseudowire (PW) Associated Channel Header >>> (ACH). RFC 5586 defines the concept of Type-Length-Variable (TLV) >>> constructs that can be carried in messages on the G-ACh by placing >>> them in the ACH. >>>=20 >>> No Associated Channel Type yet defined uses a TLV. Furthermore, = it >>> is believed that handling TLVs in hardware introduces significant >>> problems to the fast-path, and since G-ACh messages are intended = to >>> be processed substantially in hardware, the use of TLVs in >>> undesirable. >>>=20 >>> This document updates RFC 5586 by retiring ACH TLVs and removing = the >>> associated registry. >>>=20 >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From nobo@cisco.com Fri May 10 15:06:31 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7812D21F909A; Fri, 10 May 2013 15:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VXYb2cwBx6Gr; Fri, 10 May 2013 15:06:26 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id BBD8521F8FF1; Fri, 10 May 2013 15:06:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1800; q=dns/txt; s=iport; t=1368223586; x=1369433186; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kZmq7trb6vqPwOKuUIXPa9nv4Q4n618d1eXhEjA1jWc=; b=e3gHnH/7kR03lWGZhMx0zAO6R3CpB5goTeVhvvsbdemRBSeaSIFzsSQj viwPpGvgYkhfOV8HcDI3nP1FulY9WYT8HaRRc3X20ywr2nMz4o0nZv1OQ 59Ihq1v64r5zhJgGbRLWYL1J6byssQBhxwRQWB0UI503PBHu3cqbprhoU M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFALBujVGtJXG8/2dsb2JhbABSgmYhN8AgfBZ0gh8BAQEDAQEBATc0CwUHBAIBCA4DBAEBAQoUCQcnCxQJCAIEAQ0FCId+BgELvTcEjVsLgRExBwaCbmEDqGGDD4FyNQ X-IronPort-AV: E=Sophos;i="4.87,651,1363132800"; d="scan'208";a="208981369" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 10 May 2013 22:06:25 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4AM6P00006170 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 May 2013 22:06:25 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Fri, 10 May 2013 17:06:24 -0500 From: "Nobo Akiya (nobo)" To: Jeffrey Haas , Sam Aldrin Thread-Topic: [mpls] Commenst on draft-akiya-bfd-intervals-03 Thread-Index: Ac3Rh3XM5+9UcfrcQ2S8rX469rwQOQAAVMZQAAy8rAAAAN+FAAAAiuEAAAAzaYAfAr3RgAABGsbw Date: Fri, 10 May 2013 22:06:23 +0000 Message-ID: References: <4A6CE49E6084B141B15C0713B8993F281BD38595@SJEXCHMB12.corp.ad.broadcom.com> <7347100B5761DC41A166AC17F22DF11201E91E@eusaamb103.ericsson.se> <0C8935EE66D53445A3D3982BD9BE546815573400@xmb-aln-x09.cisco.com> <0C709968-C915-4CDA-98E5-361E67D4C923@gmail.com> <20130510172441.GB12732@pfrc> In-Reply-To: <20130510172441.GB12732@pfrc> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [161.44.212.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Santiago Alvarez \(saalvare\)" , "rtg-bfd@ietf.org" , "Marc Binderberger \(mbinderb\)" , "pwe3@ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] Commenst on draft-akiya-bfd-intervals-03 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 May 2013 22:06:31 -0000 Hello Jeff, Sam, Santiago, > As a suggestion, there may be two actual documents in such a case: > - An informational document covering the intervals. > - A short document, potentially on the standards track, covering the > procedure by which timers can negotiate to such an interval. This may = be > worth standardizing. (This is covered by Appendix B.) Thanks for comments & make sense. Marc and I will take this offline (potent= ially pull in some folks) and further discuss next steps. Regards, Nobo > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Jeffrey Haas > Sent: Friday, May 10, 2013 1:25 PM > To: Sam Aldrin > Cc: Santiago Alvarez (saalvare); rtg-bfd@ietf.org; pwe3@ietf.org; > mpls@ietf.org > Subject: Re: [mpls] Commenst on draft-akiya-bfd-intervals-03 >=20 > On Mon, Dec 03, 2012 at 11:53:47AM -0800, Sam Aldrin wrote: > > I echo what Santiago had said in his email. Good to have an information= al > document and do not support the idea of standardizing the intervals. >=20 > Speaking as chair, while I'm not in favor of have a standardized set of > intervals (the fights such a document would create would be epic), I am > highly supportive of such a document having informational status. >=20 > As a suggestion, there may be two actual documents in such a case: > - An informational document covering the intervals. > - A short document, potentially on the standards track, covering the > procedure by which timers can negotiate to such an interval. This may = be > worth standardizing. (This is covered by Appendix B.) >=20 > -- Jeff > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From loa@pi.nu Sat May 11 01:42:52 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7C621F8EA4 for ; Sat, 11 May 2013 01:42:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TNrpfvWIQRKD for ; Sat, 11 May 2013 01:42:47 -0700 (PDT) Received: from pipi.pi.nu (unknown [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id EA12F21F8C69 for ; Sat, 11 May 2013 01:42:46 -0700 (PDT) Received: from [192.168.1.130] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 51740180287B; Sat, 11 May 2013 10:42:44 +0200 (CEST) Message-ID: <518E0484.7030904@pi.nu> Date: Sat, 11 May 2013 10:42:44 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "" , "mpls-chairs@tools.ietf.org" Subject: [mpls] MPLS wg charter update X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2013 08:42:52 -0000 Working Group, The working group chairs have discussed an MPLS wg charter update for sometime. We have converged on the text below and while we understand that it still not "perfect" (for some value of perfect) we believe that it is good enough to serve as a basis for a working group discussion of our charter. Please note that this is not a "re-charter", but a normal charter update (maintenance) that should take place when adopting new work items or finalizing others. The only "issue" is that we have not maintained the charter to the degree we should have during the last years when the work load has been quite heavy. Please view the text below as a starting point for an update of our charter and send your comments to mpls@ietf.org. We would like to see your comments before June 7th, 2013. -------------------- Proposed new charter text ------------------------- Description of Working Group The MPLS working group is responsible for standardizing technology for label switching and for the implementation of label-switched paths over packet based link-level technologies. The responsibility includes procedures and protocols for the distribution of labels between Label Switching Routers (LSRs), MPLS packet encapsulation, and for Operation, Administration, and Maintenance (OAM) (including the necessary management objects expressed as MIB modules or using other techniques). The current WG work items are: • Maintain existing MPLS requirements, mechanisms, and protocols, in coordination with other working groups, e.g. CCAMP, PWE3 and OPSAWG working groups. • Evolve key MPLS protocols, including LDP, tLDP, mLDP, RSVP-TE and LSP Ping to meet new requirements. • Define an overall OAM framework for topology-driven, traffic engineered, and transport profile MPLS applications. • Determine MPLS-specific aspects of traffic engineering for multi-areas/multi-AS in cooperation with the CCAMP WG • Define necessary extensions for MPLS key protocols for dual-stack and IPv6 only networks • Coordinate with the CCAMP working group on the extensions of MPLS and GMPLS protocols • Document current implementation practices for MPLS load sharing. • Document mechanisms for securing MPLS networks in coordination with the KARP working group. • Document mechanisms for adding multi-topology support to existing MPLS protocols. • Document use cases for MPLS protocols. -------------------------- end proposed text ------------------------ Loa (for the wg chairs) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From adrian@olddog.co.uk Sat May 11 05:13:03 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECBF221F8BBA for ; Sat, 11 May 2013 05:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.632 X-Spam-Level: X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=-0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DaBzl6sV+ZC2 for ; Sat, 11 May 2013 05:12:58 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id C77F721F8B9C for ; Sat, 11 May 2013 05:12:57 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4BCCqG9013338; Sat, 11 May 2013 13:12:53 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4BCCp7Z013328 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 11 May 2013 13:12:52 +0100 From: "Adrian Farrel" To: "'Loa Andersson'" , References: <518E0484.7030904@pi.nu> In-Reply-To: <518E0484.7030904@pi.nu> Date: Sat, 11 May 2013 13:12:51 +0100 Message-ID: <037d01ce4e40$dc9ccc60$95d66520$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ+qBGCwI4WuAgPsSB3ce6PRIELfZefMGcg Content-Language: en-gb Cc: mpls-ads@tools.ietf.org, mpls-chairs@tools.ietf.org Subject: Re: [mpls] MPLS wg charter update X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2013 12:13:04 -0000 Chairs, WG, I am going to enter this text into the datatracker. Updating charters is / should be a similar process as for I-Ds. Using the datatracker allows us to see the latest version and to compare with previous versions. Putting the text under change control makes no statement about whether the text is ready or whether the AD supports the change :-) Cheers, Adrian > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: 11 May 2013 09:43 > To: mpls@ietf.org > Cc: ; mpls-chairs@tools.ietf.org; VIGOUREUX, MARTIN > (MARTIN) > Subject: MPLS wg charter update > > Working Group, > > The working group chairs have discussed an MPLS wg charter update > for sometime. > > We have converged on the text below and while we understand that > it still not "perfect" (for some value of perfect) we believe that > it is good enough to serve as a basis for a working group discussion > of our charter. > > Please note that this is not a "re-charter", but a normal charter update > (maintenance) that should take place when adopting new work items or > finalizing others. The only "issue" is that we have not maintained the > charter to the degree we should have during the last years when the > work load has been quite heavy. > > Please view the text below as a starting point for an update of our > charter and send your comments to mpls@ietf.org. We would like to see > your comments before June 7th, 2013. > > -------------------- Proposed new charter text ------------------------- > > > Description of Working Group > > The MPLS working group is responsible for standardizing technology > for label switching and for the implementation of label-switched > paths over packet based link-level technologies. > > The responsibility includes procedures and protocols for the > distribution of labels between Label Switching Routers (LSRs), > MPLS packet encapsulation, and for Operation, Administration, and > Maintenance (OAM) (including the necessary management objects > expressed as MIB modules or using other techniques). > > The current WG work items are: > > . Maintain existing MPLS requirements, mechanisms, and protocols, > in coordination with other working groups, e.g. CCAMP, PWE3 > and OPSAWG working groups. > . Evolve key MPLS protocols, including LDP, tLDP, mLDP, RSVP-TE > and LSP Ping to meet new requirements. > . Define an overall OAM framework for topology-driven, traffic > engineered, and transport profile MPLS applications. > . Determine MPLS-specific aspects of traffic engineering for > multi-areas/multi-AS in cooperation with the CCAMP WG > . Define necessary extensions for MPLS key protocols for > dual-stack and IPv6 only networks > . Coordinate with the CCAMP working group on the extensions of > MPLS and GMPLS protocols > . Document current implementation practices for MPLS load sharing. > . Document mechanisms for securing MPLS networks in coordination > with the KARP working group. > . Document mechanisms for adding multi-topology support to > existing MPLS protocols. > . Document use cases for MPLS protocols. > > -------------------------- end proposed text ------------------------ > > Loa > (for the wg chairs) > > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From cpignata@cisco.com Sat May 11 16:24:45 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3E421F8976 for ; Sat, 11 May 2013 16:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wBXrpNQXL01 for ; Sat, 11 May 2013 16:24:40 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id BBE2421F8956 for ; Sat, 11 May 2013 16:24:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3629; q=dns/txt; s=iport; t=1368314680; x=1369524280; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=AMXzFoVu9VNTIxEASFtKodEP2MQIIzaMjmTwMp1fE58=; b=cxiaE3EOsX5Jm6+QXuwTYE+j/lO6h/tGRc4I+6U6BUefTl7289L3lSAQ /OX17axUJBBE7a1S6sxFIt7DYG1rK1EDSzo/yU4UL3WyKxistnwEvK2L5 lelFJWk1Kly/OFAMlWkFJG9TX3Q46KTtlzzdhJiryPbI/HRj3SHprHMVF 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFAMrRjlGtJXG8/2dsb2JhbABagwc3wCKBABZ0gh8BAQEDAQEBAWgDCwUJAgIBCEYbDAsUEQIEDgWIBgYMu0wEBI1igQ8zB4J0YQOXLJE1gw+Bcg X-IronPort-AV: E=Sophos;i="4.87,654,1363132800"; d="scan'208";a="209085301" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 11 May 2013 23:24:40 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4BNOdL4015035 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 11 May 2013 23:24:40 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Sat, 11 May 2013 18:24:39 -0500 From: "Carlos Pignataro (cpignata)" To: Loa Andersson Thread-Topic: [mpls] MPLS wg charter update Thread-Index: AQHOTiOPdfooKAm0P0iPmQKc7Qi8r5kAoSId Date: Sat, 11 May 2013 23:24:38 +0000 Message-ID: <3598378B-38F0-4AB4-ABEA-5BEFBB714DD8@cisco.com> References: <518E0484.7030904@pi.nu> In-Reply-To: <518E0484.7030904@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "" Subject: Re: [mpls] MPLS wg charter update X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 May 2013 23:24:45 -0000 Hi Loa, Please find two very small questions/comments inline. Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On May 11, 2013, at 4:43 AM, "Loa Andersson" wrote: > Working Group, >=20 > The working group chairs have discussed an MPLS wg charter update > for sometime. >=20 > We have converged on the text below and while we understand that > it still not "perfect" (for some value of perfect) we believe that > it is good enough to serve as a basis for a working group discussion > of our charter. >=20 > Please note that this is not a "re-charter", but a normal charter update > (maintenance) that should take place when adopting new work items or > finalizing others. The only "issue" is that we have not maintained the > charter to the degree we should have during the last years when the > work load has been quite heavy. >=20 > Please view the text below as a starting point for an update of our > charter and send your comments to mpls@ietf.org. We would like to see > your comments before June 7th, 2013. >=20 > -------------------- Proposed new charter text ------------------------- >=20 >=20 > Description of Working Group >=20 > The MPLS working group is responsible for standardizing technology > for label switching and for the implementation of label-switched > paths over packet based link-level technologies. >=20 > The responsibility includes procedures and protocols for the > distribution of labels between Label Switching Routers (LSRs), > MPLS packet encapsulation, and for Operation, Administration, and > Maintenance (OAM) (including the necessary management objects > expressed as MIB modules or using other techniques). >=20 > The current WG work items are: >=20 The text above looks good. A nit: are these "work items" or "focus areas"? > =95 Maintain existing MPLS requirements, mechanisms, and protocols, > in coordination with other working groups, e.g. CCAMP, PWE3 > and OPSAWG working groups. > =95 Evolve key MPLS protocols, including LDP, tLDP, mLDP, RSVP-TE > and LSP Ping to meet new requirements. > =95 Define an overall OAM framework for topology-driven, traffic > engineered, and transport profile MPLS applications. > =95 Determine MPLS-specific aspects of traffic engineering for > multi-areas/multi-AS in cooperation with the CCAMP WG > =95 Define necessary extensions for MPLS key protocols for > dual-stack and IPv6 only networks In addition to defining extensions, could we add also a "gap analysis" of t= he IPv6 (dual stack and IPv6 only) state for MPLS key protocols and procedu= res? Thanks, Carlos.=20 > =95 Coordinate with the CCAMP working group on the extensions of > MPLS and GMPLS protocols > =95 Document current implementation practices for MPLS load sharing. > =95 Document mechanisms for securing MPLS networks in coordination > with the KARP working group. > =95 Document mechanisms for adding multi-topology support to > existing MPLS protocols. > =95 Document use cases for MPLS protocols. >=20 > -------------------------- end proposed text ------------------------ >=20 > Loa > (for the wg chairs) >=20 > --=20 >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From loa@pi.nu Sun May 12 00:00:30 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3565521F87D2 for ; Sun, 12 May 2013 00:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WL2Fvt71E3Eb for ; Sun, 12 May 2013 00:00:25 -0700 (PDT) Received: from pipi.pi.nu (unknown [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCB021F89B2 for ; Sun, 12 May 2013 00:00:24 -0700 (PDT) Received: from [192.168.1.130] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id CFF5B1802D26; Sun, 12 May 2013 09:00:19 +0200 (CEST) Message-ID: <518F3E03.7080003@pi.nu> Date: Sun, 12 May 2013 09:00:19 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Carlos Pignataro (cpignata)" References: <518E0484.7030904@pi.nu> <3598378B-38F0-4AB4-ABEA-5BEFBB714DD8@cisco.com> In-Reply-To: <3598378B-38F0-4AB4-ABEA-5BEFBB714DD8@cisco.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "" Subject: Re: [mpls] MPLS wg charter update X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 May 2013 07:00:30 -0000 Carlos, thanks for comments! My personal response too them would be: 1. Work items vs. focus areas. Not being a native English speaker I would need a better definition of the terms, tentatively I'd say that either would work for me, maybe say "work items and focus areas" if that aligns with how the terms are defined. 2. IPv6 gap analysis I believe that the IPv6 gap analysis is part of "necessary extensions ... for dual stack and IPv6 only" The gap analysis will show up as a milestone when we accept an ID on that topic as a wg group document. /Loa On 2013-05-12 01:24, Carlos Pignataro (cpignata) wrote: > Hi Loa, > > Please find two very small questions/comments inline. > > Thumb typed by Carlos Pignataro. > Excuze typofraphicak errows > > On May 11, 2013, at 4:43 AM, "Loa Andersson" wrote: > >> Working Group, >> >> The working group chairs have discussed an MPLS wg charter update >> for sometime. >> >> We have converged on the text below and while we understand that >> it still not "perfect" (for some value of perfect) we believe that >> it is good enough to serve as a basis for a working group discussion >> of our charter. >> >> Please note that this is not a "re-charter", but a normal charter update >> (maintenance) that should take place when adopting new work items or >> finalizing others. The only "issue" is that we have not maintained the >> charter to the degree we should have during the last years when the >> work load has been quite heavy. >> >> Please view the text below as a starting point for an update of our >> charter and send your comments to mpls@ietf.org. We would like to see >> your comments before June 7th, 2013. >> >> -------------------- Proposed new charter text ------------------------- >> >> >> Description of Working Group >> >> The MPLS working group is responsible for standardizing technology >> for label switching and for the implementation of label-switched >> paths over packet based link-level technologies. >> >> The responsibility includes procedures and protocols for the >> distribution of labels between Label Switching Routers (LSRs), >> MPLS packet encapsulation, and for Operation, Administration, and >> Maintenance (OAM) (including the necessary management objects >> expressed as MIB modules or using other techniques). >> >> The current WG work items are: >> > > The text above looks good. A nit: are these "work items" or "focus areas"? > >> • Maintain existing MPLS requirements, mechanisms, and protocols, >> in coordination with other working groups, e.g. CCAMP, PWE3 >> and OPSAWG working groups. >> • Evolve key MPLS protocols, including LDP, tLDP, mLDP, RSVP-TE >> and LSP Ping to meet new requirements. >> • Define an overall OAM framework for topology-driven, traffic >> engineered, and transport profile MPLS applications. >> • Determine MPLS-specific aspects of traffic engineering for >> multi-areas/multi-AS in cooperation with the CCAMP WG >> • Define necessary extensions for MPLS key protocols for >> dual-stack and IPv6 only networks > > In addition to defining extensions, could we add also a "gap analysis" of the IPv6 (dual stack and IPv6 only) state for MPLS key protocols and procedures? > > Thanks, > > Carlos. > >> • Coordinate with the CCAMP working group on the extensions of >> MPLS and GMPLS protocols >> • Document current implementation practices for MPLS load sharing. >> • Document mechanisms for securing MPLS networks in coordination >> with the KARP working group. >> • Document mechanisms for adding multi-topology support to >> existing MPLS protocols. >> • Document use cases for MPLS protocols. >> >> -------------------------- end proposed text ------------------------ >> >> Loa >> (for the wg chairs) >> >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >> -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From loa@pi.nu Sun May 12 03:06:21 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E9B21F8B33 for ; Sun, 12 May 2013 03:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lL980b6Q4RPp for ; Sun, 12 May 2013 03:06:16 -0700 (PDT) Received: from pipi.pi.nu (unknown [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id E00DB21F84A7 for ; Sun, 12 May 2013 03:06:15 -0700 (PDT) Received: from [192.168.1.130] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id D94A41802D26; Sun, 12 May 2013 12:06:13 +0200 (CEST) Message-ID: <518F6996.7070904@pi.nu> Date: Sun, 12 May 2013 12:06:14 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , draft-ietf-mpls-ldp-multi-topology@tools.ietf.org Subject: [mpls] Implementations of draft-ietf-mpls-ldp-multi-topology X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 May 2013 10:06:21 -0000 Working Group, draft-ietf-mpls-ldp-multi-topology has been being updated after working group last call. We will request publication of the document as an RFC on the Standards Track. As part of the shepherd write-up, that is sent as part of the request for publication to the IESG, we need to know about existing or intended implementations of draft-ietf-mpls-ldp-multi-topology. Please send mails to the mpls wg mailing list (mpls@ietf.org) or the working group chairs to inform us about implementations. /Loa (as wg co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From cpignata@cisco.com Sun May 12 13:28:07 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72E0521F85D6 for ; Sun, 12 May 2013 13:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f75PtGAJDQEf for ; Sun, 12 May 2013 13:28:02 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 7824121F85CE for ; Sun, 12 May 2013 13:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3755; q=dns/txt; s=iport; t=1368390482; x=1369600082; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=BqjDedA4Evn5TgT70yDMwfP4a6z//V6huzL6wQyhAjc=; b=QjRAM41chBNx9agUoYjGW0MBJl/EwKRGL73kWGSG4mWVJfgzQFbU3Eqa 3MR0+aSTqNsKJZ+IqBpXvEWIPJZFXMBcDL0f3KicEVoRRLeRnhW5guWNn IZU2YOAc1ssCT4sZpXLHMJaQuTAFeSPUQ46vv0xDPvfWL8CMVkaB2i0+q A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAAb6j1GtJV2c/2dsb2JhbABagwc3wCeBAxZ0gh8BAQEDAQEBATctBwsMBAIBCBEEAQEBChQJBycLFAkIAgQOBQgBh30GDLsZjnUCMQcGgm5hA5hSkA+DD4In X-IronPort-AV: E=Sophos;i="4.87,657,1363132800"; d="scan'208";a="206516789" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 12 May 2013 20:28:01 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r4CKS1T6031822 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 12 May 2013 20:28:01 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Sun, 12 May 2013 15:28:01 -0500 From: "Carlos Pignataro (cpignata)" To: Nitin Bahadur Thread-Topic: [mpls] Retiring ACH TLVs Thread-Index: AQHOT08y6w2F43NGUEaFNASPNIw/zg== Date: Sun, 12 May 2013 20:28:00 +0000 Message-ID: <95067C434CE250468B77282634C96ED322B44332@xmb-aln-x02.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.117.115.56] Content-Type: text/plain; charset="us-ascii" Content-ID: <34618218CD126346BBE291930B009BB6@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Retiring ACH TLVs X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 May 2013 20:28:07 -0000 +1. Thanks, -- Carlos. On May 10, 2013, at 2:21 PM, Nitin Bahadur wrote: >=20 > Fully support the ID. I was never a fan of ACH TLVs. >=20 > Thanks > Nitin Bahadur >=20 >=20 >=20 >=20 >=20 > On 5/7/13 10:08 AM, "Adrian Farrel" wrote: >=20 >> Hi, >>=20 >> ACH TLVs keep popping up and causing Stewart and me trouble. Mainly it i= s >> about explaining why no-one actually wants to use them (i.e., when each >> new ACH Type is defined and has a "No TLVs" written for it, we get asked >> "why not?"). >>=20 >> It seems to us that ACH TLVs are an idea that has been rejected. >> Initially we thought they might be used (especially for identifiers), bu= t >> there seems to be good opinion that handling generic TLVs would be a pai= n. >>=20 >> Since I was heavily responsible for insisting that ACH TLVs were include= d >> in RFC 5586, it seems reasonable that I do the work to fix it. >>=20 >> The I-D below retires ACH TLVs and handles the necessary registry change= s. >>=20 >> Note, of course, that structured data are still possible within >> individual ACHs if the protocol spec for an individual ACH decides to >> have them. >>=20 >> We're directing this work to the MPLS working group because that is wher= e >> 5586 was written. I have BCC'ed PWE3, L2VPN, and BFD for information. >>=20 >> Thanks for any comments. >>=20 >> As humble WG contributors we would be enthusiastic to see early WG >> adoption and last call :-) >>=20 >> Thanks, >> Adrian >>=20 >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: 07 May 2013 17:33 >>> To: Adrian Farrel; Stewart Bryant >>> Subject: New Version Notification for >>> draft-farbryantrel-mpls-retire-ach-tlv- >>> 00.txt >>>=20 >>>=20 >>> A new version of I-D, draft-farbryantrel-mpls-retire-ach-tlv-00.txt >>> has been successfully submitted by Adrian Farrel and posted to the >>> IETF repository. >>>=20 >>> Filename: draft-farbryantrel-mpls-retire-ach-tlv >>> Revision: 00 >>> Title: Retiring TLVs from the Associated Channel Header of the MPLS >>> Generic Associated Channel >>> Creation date: 2013-05-07 >>> Group: Individual Submission >>> Number of pages: 4 >>> URL: =20 >>> http://www.ietf.org/internet-drafts/draft-farbryantrel-mpls-retire- >>> ach-tlv-00.txt >>> Status: =20 >>> http://datatracker.ietf.org/doc/draft-farbryantrel-mpls-retire-ach-tlv >>> Htmlized: =20 >>> http://tools.ietf.org/html/draft-farbryantrel-mpls-retire-ach-tlv-00 >>>=20 >>>=20 >>> Abstract: >>> The MPLS Generic Associated Channel (G-ACh) is a generalization of >>> the applicability of the Pseudowire (PW) Associated Channel Header >>> (ACH). RFC 5586 defines the concept of Type-Length-Variable (TLV) >>> constructs that can be carried in messages on the G-ACh by placing >>> them in the ACH. >>>=20 >>> No Associated Channel Type yet defined uses a TLV. Furthermore, it >>> is believed that handling TLVs in hardware introduces significant >>> problems to the fast-path, and since G-ACh messages are intended to >>> be processed substantially in hardware, the use of TLVs in >>> undesirable. >>>=20 >>> This document updates RFC 5586 by retiring ACH TLVs and removing the >>> associated registry. >>>=20 >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From danfrost@cisco.com Mon May 13 03:16:01 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C9E21F8EE3 for ; Mon, 13 May 2013 03:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QsdRAjOQAYn for ; Mon, 13 May 2013 03:15:56 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id F2C6621F923C for ; Mon, 13 May 2013 03:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1269; q=dns/txt; s=iport; t=1368440156; x=1369649756; h=date:from:to:cc:subject:message-id:references: mime-version:in-reply-to; bh=bCgZ8ycXTAoClJtp7AG3bCgMviQpV6DY4iPMgYwqN2A=; b=GhGZ/0x4+EYBu5SjYBGMJWc1vH/3YI5RrMoDH320HVtn/LqeCubSMqXd eJkTY7T8TaRceWtM1AoUsbAXiMibOIgOKKWr39fMbJYfZW8f80sR7WhOY e2qRftaBbfZd4YtSlkp5ZBqaKOtXAHQnndqcFaqJ6mh9cNGIObcTpSpAO 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAIO8kFGtJV2a/2dsb2JhbABagwfAXoECFnSCHwEBAQQ6PxALGAklDwVJiB+7N48oB4J0YQOXKwGRNYMQOw X-IronPort-AV: E=Sophos;i="4.87,660,1363132800"; d="scan'208";a="209676063" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-8.cisco.com with ESMTP; 13 May 2013 10:15:55 +0000 Received: from isolaria.cisco.com (isolaria.cisco.com [10.83.106.70]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4DAFt0k012229 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 May 2013 10:15:55 GMT Received: from isolaria.cisco.com (isolaria [127.0.0.1]) by isolaria.cisco.com (8.13.1/8.13.1) with ESMTP id r4DAFru5009760; Mon, 13 May 2013 06:15:54 -0400 Received: (from danfrost@localhost) by isolaria.cisco.com (8.13.1/8.13.1/Submit) id r4DAFrN7009759; Mon, 13 May 2013 11:15:53 +0100 Date: Mon, 13 May 2013 11:15:53 +0100 From: Dan Frost To: Adrian Farrel Message-ID: <20130513101553.GC9619@cisco.com> References: <002a01ce4b45$82e38ae0$88aaa0a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002a01ce4b45$82e38ae0$88aaa0a0$@olddog.co.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: mpls@ietf.org Subject: Re: [mpls] Retiring ACH TLVs X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 10:16:01 -0000 Full support, and sooner the better. :) -d On Tue, May 07, 2013 at 06:08:34PM +0100, Adrian Farrel wrote: > Hi, > > ACH TLVs keep popping up and causing Stewart and me trouble. Mainly it is about explaining why no-one actually wants to use them (i.e., when each new ACH Type is defined and has a "No TLVs" written for it, we get asked "why not?"). > > It seems to us that ACH TLVs are an idea that has been rejected. Initially we thought they might be used (especially for identifiers), but there seems to be good opinion that handling generic TLVs would be a pain. > > Since I was heavily responsible for insisting that ACH TLVs were included in RFC 5586, it seems reasonable that I do the work to fix it. > > The I-D below retires ACH TLVs and handles the necessary registry changes. > > Note, of course, that structured data are still possible within individual ACHs if the protocol spec for an individual ACH decides to have them. > > We're directing this work to the MPLS working group because that is where 5586 was written. I have BCC'ed PWE3, L2VPN, and BFD for information. > > Thanks for any comments. > > As humble WG contributors we would be enthusiastic to see early WG adoption and last call :-) > > Thanks, > Adrian From aldrin.ietf@gmail.com Mon May 13 03:30:44 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24E2321F942B for ; Mon, 13 May 2013 03:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-frwQBApXzv for ; Mon, 13 May 2013 03:30:39 -0700 (PDT) Received: from mail-gh0-f181.google.com (mail-gh0-f181.google.com [209.85.160.181]) by ietfa.amsl.com (Postfix) with ESMTP id 70B8121F93F0 for ; Mon, 13 May 2013 03:30:39 -0700 (PDT) Received: by mail-gh0-f181.google.com with SMTP id z12so136330ghb.40 for ; Mon, 13 May 2013 03:30:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=MGA3G8A5XgeBPVIqwuhS7ifv4SU1dv/NlyepzjIChT0=; b=f+k3nwxY9fU32BekwI8JTYxsPXuWRynrNpKbYSvwOqcjxqSqv7j4ehAnA7AeOyeQ2A dJWrCmQpk4ePErXXPjFmUQ7fj/zLPb/O0m7xnGBwiIVa8uEJziDM8HZ+qMIhVCdP8/uu mFL0mGeyRu8pY+409AXxGO9GAQPyqu3ieXsPLg63ZyRSvqVJNcfRRNWGBbMtZzUaEHax cve4P38Yd5Tmyg4fWS1dys1kefsJ8SlmV+04KkyxhSSzWXJXQbYMK5w5nShTygPtzxoi L4to9skJYe1gCZocAe1219yZiKZCcRRID1nsEIRhhuvyxHy3cBQvYrqT9Tg4vATNhImL opyw== X-Received: by 10.236.133.97 with SMTP id p61mr15450180yhi.0.1368441038967; Mon, 13 May 2013 03:30:38 -0700 (PDT) Received: from [10.119.251.254] (mobile-166-147-117-043.mycingular.net. [166.147.117.43]) by mx.google.com with ESMTPSA id p31sm19945828yhm.10.2013.05.13.03.30.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 13 May 2013 03:30:38 -0700 (PDT) References: <002a01ce4b45$82e38ae0$88aaa0a0$@olddog.co.uk> Mime-Version: 1.0 (1.0) In-Reply-To: <002a01ce4b45$82e38ae0$88aaa0a0$@olddog.co.uk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <12BA262D-8402-4E44-B806-F40B8F868642@gmail.com> X-Mailer: iPhone Mail (10B350) From: Sam Aldrin Date: Mon, 13 May 2013 06:30:35 -0400 To: "adrian@olddog.co.uk" Cc: "" Subject: Re: [mpls] Retiring ACH TLVs X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 10:30:44 -0000 Fully support. -sam Sent from my iPhone On May 7, 2013, at 1:08 PM, "Adrian Farrel" wrote: > Hi, >=20 > ACH TLVs keep popping up and causing Stewart and me trouble. Mainly it is a= bout explaining why no-one actually wants to use them (i.e., when each new A= CH Type is defined and has a "No TLVs" written for it, we get asked "why not= ?"). >=20 > It seems to us that ACH TLVs are an idea that has been rejected. Initially= we thought they might be used (especially for identifiers), but there seems= to be good opinion that handling generic TLVs would be a pain. >=20 > Since I was heavily responsible for insisting that ACH TLVs were included i= n RFC 5586, it seems reasonable that I do the work to fix it. >=20 > The I-D below retires ACH TLVs and handles the necessary registry changes.= >=20 > Note, of course, that structured data are still possible within individual= ACHs if the protocol spec for an individual ACH decides to have them. >=20 > We're directing this work to the MPLS working group because that is where 5= 586 was written. I have BCC'ed PWE3, L2VPN, and BFD for information.=20 >=20 > Thanks for any comments. >=20 > As humble WG contributors we would be enthusiastic to see early WG adoptio= n and last call :-) >=20 > Thanks, > Adrian >=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: 07 May 2013 17:33 >> To: Adrian Farrel; Stewart Bryant >> Subject: New Version Notification for draft-farbryantrel-mpls-retire-ach-= tlv- >> 00.txt >>=20 >>=20 >> A new version of I-D, draft-farbryantrel-mpls-retire-ach-tlv-00.txt >> has been successfully submitted by Adrian Farrel and posted to the >> IETF repository. >>=20 >> Filename: draft-farbryantrel-mpls-retire-ach-tlv >> Revision: 00 >> Title: Retiring TLVs from the Associated Channel Header of the MP= LS >> Generic Associated Channel >> Creation date: 2013-05-07 >> Group: Individual Submission >> Number of pages: 4 >> URL: http://www.ietf.org/internet-drafts/draft-farbryantrel-m= pls-retire- >> ach-tlv-00.txt >> Status: http://datatracker.ietf.org/doc/draft-farbryantrel-mpls-= retire-ach-tlv >> Htmlized: http://tools.ietf.org/html/draft-farbryantrel-mpls-retir= e-ach-tlv-00 >>=20 >>=20 >> Abstract: >> The MPLS Generic Associated Channel (G-ACh) is a generalization of >> the applicability of the Pseudowire (PW) Associated Channel Header >> (ACH). RFC 5586 defines the concept of Type-Length-Variable (TLV) >> constructs that can be carried in messages on the G-ACh by placing >> them in the ACH. >>=20 >> No Associated Channel Type yet defined uses a TLV. Furthermore, it >> is believed that handling TLVs in hardware introduces significant >> problems to the fast-path, and since G-ACh messages are intended to >> be processed substantially in hardware, the use of TLVs in >> undesirable. >>=20 >> This document updates RFC 5586 by retiring ACH TLVs and removing the >> associated registry. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From internet-drafts@ietf.org Mon May 13 05:40:55 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4541D21F95C4; Mon, 13 May 2013 05:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.141 X-Spam-Level: X-Spam-Status: No, score=-102.141 tagged_above=-999 required=5 tests=[AWL=0.459, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0khcTTuDUCHu; Mon, 13 May 2013 05:40:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B6521F94CC; Mon, 13 May 2013 05:40:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p7 Message-ID: <20130513124054.31902.27266.idtracker@ietfa.amsl.com> Date: Mon, 13 May 2013 05:40:54 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-dod-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 12:40:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : LDP Downstream-on-Demand in Seamless MPLS Author(s) : Thomas Beckhaus Bruno Decraene Kishore Tiruveedhula Maciek Konstantynowicz Luca Martini Filename : draft-ietf-mpls-ldp-dod-07.txt Pages : 33 Date : 2013-05-13 Abstract: Seamless MPLS design enables a single IP/MPLS network to scale over core, metro and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access, including high number of devices, their position in network topology and their compute and memory constraints that limit the amount of state access devices can hold.This can be achieved with LDP Downstream-on-Demand (LDP DoD) label advertisement. This document describes LDP DoD use cases and lists required LDP DoD procedures in the context of Seamless MPLS design. In addition, a new optional TLV type in the LDP Label Request message is defined for fast-up convergence. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-dod There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-dod-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-ldp-dod-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon May 13 06:54:55 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 410F621F93E9; Mon, 13 May 2013 06:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.246 X-Spam-Level: X-Spam-Status: No, score=-102.246 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WdOXjDZyxlcl; Mon, 13 May 2013 06:54:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C3A21F8F9E; Mon, 13 May 2013 06:54:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p7 Message-ID: <20130513135454.9508.80896.idtracker@ietfa.amsl.com> Date: Mon, 13 May 2013 06:54:54 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-dod-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 13:54:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : LDP Downstream-on-Demand in Seamless MPLS Author(s) : Thomas Beckhaus Bruno Decraene Kishore Tiruveedhula Maciek Konstantynowicz Luca Martini Filename : draft-ietf-mpls-ldp-dod-08.txt Pages : 33 Date : 2013-05-13 Abstract: Seamless MPLS design enables a single IP/MPLS network to scale over core, metro and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access, including high number of devices, their position in network topology and their compute and memory constraints that limit the amount of state access devices can hold.This can be achieved with LDP Downstream-on-Demand (LDP DoD) label advertisement. This document describes LDP DoD use cases and lists required LDP DoD procedures in the context of Seamless MPLS design. In addition, a new optional TLV type in the LDP Label Request message is defined for fast-up convergence. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-dod There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-dod-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-ldp-dod-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon May 13 07:02:14 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E60521F965B; Mon, 13 May 2013 07:02:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.244 X-Spam-Level: X-Spam-Status: No, score=-102.244 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+SlUd7KxyOy; Mon, 13 May 2013 07:02:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DC56D21F964F; Mon, 13 May 2013 07:02:13 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p7 Message-ID: <20130513140213.9446.9131.idtracker@ietfa.amsl.com> Date: Mon, 13 May 2013 07:02:13 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-seamless-mpls-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 14:02:14 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Seamless MPLS Architecture Author(s) : Nicolai Leymann Bruno Decraene Clarence Filsfils Maciek Konstantynowicz Dirk Steinberg Filename : draft-ietf-mpls-seamless-mpls-03.txt Pages : 41 Date : 2013-05-13 Abstract: This documents describes an architecture which can be used to extend MPLS networks to integrate access and aggregation networks into a single MPLS domain ("Seamless MPLS"). The Seamless MPLS approach is based on existing and well known protocols. It provides a highly flexible and a scalable architecture and the possibility to integrate 100.000 of nodes. The separation of the service and transport plane is one of the key elements; Seamless MPLS provides end to end service independent transport. Therefore it removes the need for service specific configurations in network transport nodes (without end to end transport MPLS, some additional services nodes/configurations would be required to glue each transport domain). This draft defines a routing architecture using existing standardized protocols. It does not invent any new protocols or defines extensions to existing protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-seamless-mpls There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-seamless-mpls-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-seamless-mpls-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iesg-secretary@ietf.org Mon May 13 09:01:30 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBD5B21F95F3; Mon, 13 May 2013 09:01:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.167 X-Spam-Level: X-Spam-Status: No, score=-102.167 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9i7dKbcnfzIo; Mon, 13 May 2013 09:01:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6123221F93BF; Mon, 13 May 2013 09:01:30 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p7 Sender: Message-ID: <20130513160130.30975.44987.idtracker@ietfa.amsl.com> Date: Mon, 13 May 2013 09:01:30 -0700 Cc: mpls@ietf.org Subject: [mpls] Last Call: (LDP Downstream-on-Demand in Seamless MPLS) to Proposed Standard X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 16:01:31 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'LDP Downstream-on-Demand in Seamless MPLS' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-05-27. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Seamless MPLS design enables a single IP/MPLS network to scale over core, metro and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access, including high number of devices, their position in network topology and their compute and memory constraints that limit the amount of state access devices can hold.This can be achieved with LDP Downstream-on-Demand (LDP DoD) label advertisement. This document describes LDP DoD use cases and lists required LDP DoD procedures in the context of Seamless MPLS design. In addition, a new optional TLV type in the LDP Label Request message is defined for fast-up convergence. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-dod/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-dod/ballot/ No IPR declarations have been submitted directly on this I-D. From mkonstan@cisco.com Mon May 13 09:37:12 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE4621F90EE for ; Mon, 13 May 2013 09:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQkCuldw04Kw for ; Mon, 13 May 2013 09:37:07 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 01C7621F8F4D for ; Mon, 13 May 2013 09:37:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11697; q=dns/txt; s=iport; t=1368463027; x=1369672627; h=from:to:cc:subject:date:message-id:references: mime-version; bh=XGIInFE2QO6CoaSEaBkKjlTgOaQej2qr8PRanVesi9A=; b=jANy5M2UCZ6QW7uFOSASiJk215znNC15WQxHn9NBrYXHCy/pcW1B4cWy VOD9mOJUg+AWxFrscVg4GdDNKOgKdU/FaS+adNjaA3A1g9Z2QZsVQUG18 Syw3art9oC+ouLn9G6nCebVBeidHu+w/mGaYwDxEgDfNuD80UNNAeC2Rw Q=; X-IronPort-AV: E=Sophos;i="4.87,663,1363132800"; d="scan'208,217";a="209817004" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 13 May 2013 16:37:06 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4DGb5Nx026509 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 13 May 2013 16:37:05 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Mon, 13 May 2013 11:37:04 -0500 From: "Maciek Konstantynowicz (mkonstan)" To: "mpls@ietf.org" Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-ldp-dod-08.txt Thread-Index: AQHOT/gaVK/Ei/T0rEamwZtN5Zn1iA== Date: Mon, 13 May 2013 16:37:04 +0000 Message-ID: <96EE5A5F6E4E6448B2AC953A71A9739B1142EBFC@xmb-rcd-x06.cisco.com> References: <20130513135454.9508.80896.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.107.156] Content-Type: multipart/alternative; boundary="_000_96EE5A5F6E4E6448B2AC953A71A9739B1142EBFCxmbrcdx06ciscoc_" MIME-Version: 1.0 Subject: [mpls] Fwd: I-D Action: draft-ietf-mpls-ldp-dod-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 16:37:12 -0000 --_000_96EE5A5F6E4E6448B2AC953A71A9739B1142EBFCxmbrcdx06ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We have just published revised I-D draft-ietf-mpls-ldp-dod-08, addressing a= ll comments raised during AD review. The document is now in the IESG Last Call queue for publication. Below brief summary of substantial edits vs. -06, following the reviews by = Doc Shepherd ( Loa Andersson ) and AD ( Adrian Farrel ):- ( many thanks to Loa and Adrian for good guidance and reviews ) - made consistent references to IGP protocols throughout the document, inst= ead of just referring to ISIS. - corrected references to LDP IPv4 and IPv6 address families. - moved the proposed extension to LDP to separate section 5, made it normat= ive with RFC 2119 language. - filled in proposed value for the new LDP Queue Request TLV, subject to IA= NA review during the last call. - updated the security section, adding reference to RFC 5920. - cleaned up normative and informative reference parts throughout the docum= ent. - other minor edits. Thanks, Maciek. Begin forwarded message: From: > Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-dod-08.txt Date: 13 May 2013 14:54:54 GMT+01:00 To: > Cc: > A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Grou= p of the IETF. Title : LDP Downstream-on-Demand in Seamless MPLS Author(s) : Thomas Beckhaus Bruno Decraene Kishore Tiruveedhula Maciek Konstantynowicz Luca Martini Filename : draft-ietf-mpls-ldp-dod-08.txt Pages : 33 Date : 2013-05-13 Abstract: Seamless MPLS design enables a single IP/MPLS network to scale over core, metro and access parts of a large packet network infrastructure using standardized IP/MPLS protocols. One of the key goals of Seamless MPLS is to meet requirements specific to access, including high number of devices, their position in network topology and their compute and memory constraints that limit the amount of state access devices can hold.This can be achieved with LDP Downstream-on-Demand (LDP DoD) label advertisement. This document describes LDP DoD use cases and lists required LDP DoD procedures in the context of Seamless MPLS design. In addition, a new optional TLV type in the LDP Label Request message is defined for fast-up convergence. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-dod There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-dod-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-ldp-dod-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_96EE5A5F6E4E6448B2AC953A71A9739B1142EBFCxmbrcdx06ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <7D057A0A43D024438B0CEB3DEE96C06D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable Hi,

We have just published revised I-D draft-ietf-mpls-ldp-dod-08, ad= dressing all comments raised during AD review.
The document is now in the IESG Last Call queue for publication.

Below brief summary of substantial edits vs. -06, following the review= s by Doc Shepherd ( Loa Andersson ) and AD ( Adrian Farrel ):-
( many thanks to Loa and Adrian for good guidance and reviews )

- made consistent references to IGP protocols throughout the document,= instead of just referring to ISIS.
- corrected references to LDP IPv4 and IPv6 address families.
- moved the proposed extension to LDP to separate section 5, made it n= ormative with RFC 2119 language.
- filled in proposed value for the new LDP Queue Request TLV, subject = to IANA review during the last call.
- updated the security section, adding reference to RFC 5920.
- cleaned up normative and informative reference parts throughout the = document.
- other minor edits.

Thanks,
Maciek.

Begin forwarded message:

From: <<= a href=3D"mailto:internet-drafts@ietf.org">internet-drafts@ietf.org>=
Subject: [m= pls] I-D Action: draft-ietf-mpls-ldp-dod-08.txt
Date: 13 Ma= y 2013 14:54:54 GMT+01:00
To: <<= a href=3D"mailto:i-d-announce@ietf.org">i-d-announce@ietf.org>
Cc: <<= a href=3D"mailto:mpls@ietf.org">mpls@ietf.org>


A New Internet-Draft is available from the on-line Internet-Drafts director= ies.
This draft is a work item of the Multiprotocol Label Switching Working Grou= p of the IETF.

Title  = ;         : LDP Downstream-on-= Demand in Seamless MPLS
Author(s) &= nbsp;     : Thomas Beckhaus
            &nb= sp;            = Bruno Decraene
            &nb= sp;            = Kishore Tiruveedhula
            &nb= sp;            = Maciek Konstantynowicz
            &nb= sp;            = Luca Martini
Filename &n= bsp;      : draft-ietf-mpls-ldp-dod-08.txt Pages  = ;         : 33
Date  =           : 2013-05-13
Abstract:
  Seamless MPLS design enables a single IP/MPLS network to scale = over
  core, metro and access parts of a large packet network infrastr= ucture
  using standardized IP/MPLS protocols.  One of the key goal= s of
  Seamless MPLS is to meet requirements specific to access, inclu= ding
  high number of devices, their position in network topology and = their
  compute and memory constraints that limit the amount of state a= ccess
  devices can hold.This can be achieved with LDP Downstream-on-De= mand
  (LDP DoD) label advertisement.  This document describes LD= P DoD use
  cases and lists required LDP DoD procedures in the context of   Seamless MPLS design.

  In addition, a new optional TLV type in the LDP Label Request m= essage
  is defined for fast-up convergence.



The IETF datatracker status page for this draft is:
https:= //datatracker.ietf.org/doc/draft-ietf-mpls-ldp-dod

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-mpls-ldp-dod-08

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-ldp-dod-08


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

--_000_96EE5A5F6E4E6448B2AC953A71A9739B1142EBFCxmbrcdx06ciscoc_-- From david.i.allan@ericsson.com Mon May 13 12:57:57 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0760E21F8EA4 for ; Mon, 13 May 2013 12:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAQDYaePGX-l for ; Mon, 13 May 2013 12:57:46 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9DA21F8BBA for ; Mon, 13 May 2013 12:57:46 -0700 (PDT) X-AuditID: c618062d-b7ff46d000006709-41-519145b9bfae Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 40.69.26377.9B541915; Mon, 13 May 2013 21:57:45 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Mon, 13 May 2013 15:57:44 -0400 From: David Allan I To: Alan Davey Thread-Topic: [MPLS] A doubt about RFC 6428 Thread-Index: Ac5IG1yAbZhW1zCyQtKJoj7oW461UgACNQsQARrVc5AA4QRRQA== Date: Mon, 13 May 2013 19:57:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_E6C17D2345AC7A45B7D054D407AA205C09B253eusaamb105ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyuXRPrO5O14mBBs8f6lk8mTaLzeLW0pWs DkweS5b8ZPI4enMucwBTFJdNSmpOZllqkb5dAlfGqxa/gvX1FbcWPWRtYLye18XIySEhYCKx Y/9zFghbTOLCvfVsXYxcHEICRxklHjx8ywrhLGeUODZpMlgVm4CBxJ7/XxhBbBEBLYkd0z8D dXBwMAsoS5y6KwNiCgOFn88qgajQltgxtYcJwnaSOHRyDpjNIqAq8eTpVbApvALeEi+fT4Ja dZVR4vPKs6wgCU4Bf4l3PUvAGhiBjvt+ag2YzSwgLnHryXwmiKMFJJbsOc8MYYtKvHz8jxXC Vpb4PucRC8Rp+RI3/ipB7BKUODnzCcsERtFZSCbNQqiahaQKokRHYsHuT2wQtrbEsoWvmWHs MwceMyGLL2BkX8XIUVqcWpabbmSwiREYT8ck2HR3MO55aXmIUZqDRUmcN4qrMVBIID2xJDU7 NbUgtSi+qDQntfgQIxMHp1QDo21T20aV2hO3m6Vj1dl5fENqFq3LPlE04dj3CKH6J477N9W4 r2neuDI/w8PmlkfAlG+a8a2bt+VlayxyOsFy6a2kaFjq1bNrD4qtqz/783TuI/EdrQ683GKM x5RP91t8PWgYasuulcCnJC/OsLxpU00p1xvtP+r3RBhEtO8dy2PSclwSM3uOEktxRqKhFnNR cSIAFpLMzXUCAAA= Cc: "mpls@ietf.org" Subject: Re: [mpls] [MPLS] A doubt about RFC 6428 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 May 2013 19:57:57 -0000 --_000_E6C17D2345AC7A45B7D054D407AA205C09B253eusaamb105ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It is all in how you interpret "The length is the length of the following d= ata." Which is referring to the diagram above (e.g. the colon below is you= r addition), and then goes on to tells you how to find the less-obvious fie= lds. If it said "The length is the length of the data following the length field= "... it would be clearer. Dave ________________________________ From: Alan Davey [mailto:Alan.Davey@metaswitch.com] Sent: Thursday, May 09, 2013 3:59 AM To: David Allan I Cc: mpls@ietf.org Subject: RE: [MPLS] A doubt about RFC 6428 Hi Dave Thank you very much for getting back to me so quickly. I have a further qu= estion on RFC 6428 if you have another minute. In section 3.5.3, PW End Point MEP-ID, I think that the text defining the = Length field is confusing because it is not clear if the length includes th= e AGI. The text is currently as follows. The length is the length of the following data: the Global_ID, Node Ident= ifier, and Attachment Circuit ID (AC_ID) are as per [9]. Am I correct in thinking that the Length field is the length of the value = fields, as for the Section MEP-ID in section 3.5.1 and the LSP MEP-ID in se= ction 3.5.2? That is, should the text read as follows. The length is the length of the value fields. The Global_ID, Node Identi= fier, and Attachment Circuit ID (AC_ID) are as per [9]. Thanks Alan From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: 03 May 2013 18:35 To: Alan Davey; rfc6428@tools.ietf.org Cc: mpls@ietf.org Subject: RE: [MPLS] A doubt about RFC 6428 Hi Alan: It is kind of implied, as in "received DOWN while NOT in a misconnectivity = state". I'm not sure adding that to the state machine diagram would actuall= y improve the clarity....I'll let others comment. cheers Dave ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of Alan Davey Sent: Friday, May 03, 2013 9:29 AM To: rfc6428@tools.ietf.org Cc: mpls@ietf.org Subject: [mpls] [MPLS] A doubt about RFC 6428 Folks I have a doubt about RFC 6428. Could you please let me know what you think= of the following. Section 3.7.4.2., Exit from a Mis-Connectivity Defect, states that "Exit fr= om a mis-connectivity defect state occurs when no CV messages with mis-conn= ectivity defects have been received for a period of 3.5 seconds". However, the State Machines in section 3.7.5 have no input corresponding to= an "Exit from a Mis-Connectivity Defect" timer pop. (Although they do hav= e a MIS-CONNECTIVITY input added by RFC 6428.) If the State Machine is fol= lowed then Down state is exited as soon as the remote system signals Down s= tate. Should the State Machines be modified such that Down state following a MIS-= CONNECTIVITY input is only exited after an "Exit from a Mis-Connectivity De= fect" timer pop input or am I missing something? Regards Alan Davey Network Technologies Metaswitch Networks alan.davey@metaswitch.com +44 (0) 20 8366 1177 network-technologies.metaswitch.com --_000_E6C17D2345AC7A45B7D054D407AA205C09B253eusaamb105ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
It is all in how you interpret "The length is the lengt= h of the following data."  Which is referring to the diagram abov= e (e.g. the colon below is your addition), and then goes on to tells you how to find the less-obvious fields.
 
If it said "The length is the length of the data follow= ing the length field"... it would be clearer.
 
Dave

From: Alan Davey [mailto:Alan.Davey= @metaswitch.com]
Sent: Thursday, May 09, 2013 3:59 AM
To: David Allan I
Cc: mpls@ietf.org
Subject: RE: [MPLS] A doubt about RFC 6428

Hi Dave

 

Thank you very much f= or getting back to me so quickly.  I have a further question on RFC 64= 28 if you have another minute.

 

In section 3.5.3,  PW End Point MEP-ID, I think that the text defining the Length= field is confusing because it is not clear if the length includes the AGI.=   The text is currently as follows.

 

  The length is = the length of the following data: the Global_ID, Node Identifier, and Attac= hment

   Circuit = ID (AC_ID) are as per [9].

 

Am I correct in think= ing that the Length field  is the length of the value fields, as for t= he Section MEP-ID in section 3.5.1 and the LSP MEP-ID in section 3.5.2?&nbs= p; That is, should the text read as follows.

 

  The length is = the length of the value fields.  The Global_ID, Node Identifier, and A= ttachment

   Circuit = ID (AC_ID) are as per [9].

 

Thanks

Alan

 

From: David Allan I [m= ailto:david.i.allan@ericsson.com]
Sent: 03 May 2013 18:35
To: Alan Davey; rfc6428@tools.ietf.org
Cc: mpls@ietf.org
Subject: RE: [MPLS] A doubt about RFC 6428

 

Hi Alan:

It is kind of implied, as in "re= ceived DOWN while NOT in a misconnectivity state". I'm not sure a= dding that to the state machine diagram would actually improve the clarity....I'll let others comment.

cheers

Dave

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Alan Davey
Sent: Friday, May 03, 2013 9:29 AM
To: rfc6428@tools.ietf.org=
Cc: mpls@ietf.org
Subject: [mpls] [MPLS] A doubt about RFC 6428

Folks

 

I have a doubt about RFC 6428.  Could you pleas= e let me know what you think of the following.

 

Section 3.7.4.2., Exit from a Mis-Connectivity Defec= t, states that “Exit from a mis-connectivity defect state occurs when= no CV messages with mis-connectivity defects have been received for a peri= od of 3.5 seconds”.

 

However, the State Machines in section 3.7.5 have no= input corresponding to an “Exit from a Mis-Connectivity Defect”= ; timer pop.  (Although they do have a MIS-CONNECTIVITY input added by= RFC 6428.)  If the State Machine is followed then Down state is exited as soon as the remote system signals Down state.=

 

Should the State Machines be modified such that Down= state following a MIS-CONNECTIVITY input is only exited after an “Ex= it from a Mis-Connectivity Defect” timer pop input or am I missing so= mething?

 

Regards

Alan Davey

 

Network Technologies
Metaswitch Networks

 

alan.davey@meta= switch.com
+44 (0) 20 8366 1177
network-technologies.metaswitch.com

 

 

 

--_000_E6C17D2345AC7A45B7D054D407AA205C09B253eusaamb105ericsso_-- From internet-drafts@ietf.org Mon May 13 17:26:36 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E1C21F8DFC; Mon, 13 May 2013 17:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.383 X-Spam-Level: X-Spam-Status: No, score=-102.383 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1RO6yWCsx35; Mon, 13 May 2013 17:26:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 089E621F8E9D; Mon, 13 May 2013 17:26:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p7 Message-ID: <20130514002547.32164.75897.idtracker@ietfa.amsl.com> Date: Mon, 13 May 2013 17:25:47 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-ldp-multi-topology-08.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 00:26:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : LDP Extensions for Multi Topology Routing Author(s) : Quintin Zhao Luyuan Fang Chao Zhou Lianyuan Li Kamran Raza Filename : draft-ietf-mpls-ldp-multi-topology-08.txt Pages : 18 Date : 2013-05-13 Abstract: Multi-Topology (MT) routing is supported in IP networks with the use of MT aware IGP protocols. In order to provide MT routing within Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) networks new extensions are required. This document updates RFC4379. This document describes the LDP protocol extensions required to support MT routing in an MPLS environment. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-multi-topology There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-ldp-multi-topology-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-ldp-multi-topology-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Tue May 14 08:02:41 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9916621F910E; Tue, 14 May 2013 08:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.439 X-Spam-Level: X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3ThzNG8viA8; Tue, 14 May 2013 08:02:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 084EE21F8709; Tue, 14 May 2013 08:02:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p7 Message-ID: <20130514150241.10908.85403.idtracker@ietfa.amsl.com> Date: Tue, 14 May 2013 08:02:41 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-seamless-mcast-07.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 15:02:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Inter-Area P2MP Segmented LSPs Author(s) : Yakov Rekhter Rahul Aggarwal Filename : draft-ietf-mpls-seamless-mcast-07.txt Pages : 40 Date : 2013-05-14 Abstract: This document describes procedures for building inter-area point-to- multipoint (P2MP) segmented service LSPs by partitioning such LSPs into intra-area segments and using BGP as the inter-area routing and label distribution protocol. Within each IGP area the intra-area segments are either carried over intra-area P2MP LSPs, using P2MP LSP hierarchy, or instantiated using ingress replication. The intra-area P2MP LSPs may be signaled using P2MP RSVP-TE or P2MP mLDP. If ingress replication is used within an IGP area, then MP2P LDP LSPs or P2P RSVP-TE LSPs may be used in the IGP area. The applications/services that use such inter-area service LSPs may be BGP MVPN, VPLS multicast, or global table multicast over MPLS. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-seamless-mcast There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-seamless-mcast-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-seamless-mcast-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From carlo.cavazzoni@telecomitalia.it Tue May 14 08:08:42 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F6AB21F854E for ; Tue, 14 May 2013 08:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.719 X-Spam-Level: X-Spam-Status: No, score=-1.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w+oe8RidJnet for ; Tue, 14 May 2013 08:08:38 -0700 (PDT) Received: from GRFEDG701BA020.telecomitalia.it (grfedg701ba020.telecomitalia.it [156.54.233.200]) by ietfa.amsl.com (Postfix) with ESMTP id 00BA821F9128 for ; Tue, 14 May 2013 08:08:34 -0700 (PDT) Received: from grfhub704ba020.griffon.local (10.188.101.117) by GRFEDG701BA020.telecomitalia.it (10.188.45.100) with Microsoft SMTP Server (TLS) id 8.3.297.1; Tue, 14 May 2013 17:08:29 +0200 Received: from GRFMBX703BA020.griffon.local ([10.188.101.13]) by grfhub704ba020.griffon.local ([10.188.101.117]) with mapi; Tue, 14 May 2013 17:08:28 +0200 From: Cavazzoni Carlo To: "Eric Osborne (eosborne)" , "mpls@ietf.org" Date: Tue, 14 May 2013 17:08:27 +0200 Thread-Topic: PSC: draft-rhd-mpls-tp-psc-priority-00 Thread-Index: Ac47ZD1tB/jb+CaKQqOehjxMIOgzIgVT6XFA Message-ID: <05540BD841BBD643BB51404C4C9171521518059A97@GRFMBX703BA020.griffon.local> References: <20ECF67871905846A80F77F8F4A2757210150296@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A2757210150296@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 15:08:42 -0000 Eric, in order to clarify, from a network operator point of view, why I think the= SF-P must have higher priority than the FS-P I would make the following si= mple practical example. For the execution of a programmed maintenance activity on one or more secti= ons of a MPLS-TP ring, all the connections routed on those sections have be= en moved to the protection paths with a FS-P command for a defined maintena= nce window timeframe. The maintenance work is typically done by a team diff= erent from that managing the MPLS-TP network: let's imagine maintenance peo= ple complete the work well in advance with respect to the planned maintenan= ce window. Unfortunately a failure (SF-P) happens before the end of the planned mainte= nance window timeframe, what happens? a) If SF-P has higher priority than FS-P then PSC moves the traffic ba= ck to the working path so recovering the connectivity in a short protection= switching time; b) If FS-P has higher priority than SF-P then the traffic remains on t= he broken connection and it will continue to be lost even when the working = path is up and running (i.e. at the latest at the end of the planned maint= enance window): it seems that only a manual (and slow) reconfiguration of b= oth protection endpoints from the management system could recover the norma= l working state. Why do we have to define case b) as the standard behavior? Are there use cases that suggest case b) as the preferred choice? Hope this can help. Regards, Carlo ------------------------------------------------------------------ Telecom Italia Carlo Cavazzoni Transport Innovation Via G. Reiss Romoli, 274 10148 Torino +39 011 2285732 +39 335 7854045 Fax: +39 06 91861099 carlo.cavazzoni@telecomitalia.it -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Eri= c Osborne (eosborne) Sent: mercoled=EC 17 aprile 2013 14:16 To: mpls@ietf.org Subject: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00 This thread is for discussing draft-rhd-mpls-tp-psc-priority-00. In brief,= the draft proposes swapping the priorities between FS and SF-P (see sectio= n 4.3.2 of rfc6378). This proposed swap has a long history, dating back to= when PSC was an ID. For some history, see http://datatracker.ietf.org/liaison/1229/ and http://datatracker.ietf.org/liaison/1234/ The questions that I think are relevant here are: - is it appropriate to make this priority swap? - are there alternative approaches? - what do we need to change? rfc5654? rfc4427? - if we don't make the change, does this expose implementation to problems? - if we do make the change, how do we go about it? but of course any and all discussion is welcome. As with the other threads I'm going to leave my two cents out of this intro= ductory email but I'll chime in when discussion starts. eric _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle per= sone indicate. La diffusione, copia o qualsiasi altra azione derivante dall= a conoscenza di queste informazioni sono rigorosamente vietate. Qualora abb= iate ricevuto questo documento per errore siete cortesemente pregati di dar= ne immediata comunicazione al mittente e di provvedere alla sua distruzione= , Grazie. This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks. From swallow@cisco.com Tue May 14 08:27:01 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E25121F84AF for ; Tue, 14 May 2013 08:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OPmB4XqVu1D for ; Tue, 14 May 2013 08:26:55 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id A540121F8519 for ; Tue, 14 May 2013 08:26:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5445; q=dns/txt; s=iport; t=1368545185; x=1369754785; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=p+GqR5o4ROYdDczT0KMY9dgC/ssOsvfhfMO6u3iihFk=; b=iwT4ZsrYVku2aEA/4/ekjO/do91mn4l5Xs0ZNVFryYgUz6wAITaXvSn4 2na7j9LHZ0a4EAGn7Q3cy3bvXUkqeXSnC3cjL1Wg8asT7LXklir7b2zYT PBUONPXY7zXyh2p+KzkIbhEPkgicbnu1xmuJo3PEMbcIU9eJMghUpMG3I 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAO5WklGtJXG+/2dsb2JhbABagkNEwGJ/FnSCHwEBAQQtQQsSAQgOAwMBAgsdORQJCAEBBAENBQiIBK5XjzKObSARB4J0YQOocYFXgTiCJw X-IronPort-AV: E=Sophos;i="4.87,671,1363132800"; d="scan'208,217";a="210296991" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-2.cisco.com with ESMTP; 14 May 2013 15:26:25 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4EFQON8023396 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 May 2013 15:26:24 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Tue, 14 May 2013 10:26:24 -0500 From: "George Swallow (swallow)" To: Ross Callon , "mpls@ietf.org" , "draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org" Thread-Topic: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 Thread-Index: Ac5KBNrRqy5GgTuxR1iRJSatXBuqdwGuuqEA Date: Tue, 14 May 2013 15:26:23 +0000 Message-ID: <2FE467D3673DCE409A84D67EC2F607BB0FA778AF@xmb-rcd-x10.cisco.com> In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316C3ED09@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.98.56.166] Content-Type: multipart/alternative; boundary="_000_2FE467D3673DCE409A84D67EC2F607BB0FA778AFxmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 15:27:01 -0000 --_000_2FE467D3673DCE409A84D67EC2F607BB0FA778AFxmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable With hat off. No/do not support. I believe that making a single sub-TLV space is going to lead to a lot of c= onfusion in the future as to which sub-TLVs are used with which TLVs. That= is one will have to search through bunch of documents instead of seeing it= clearly laid out in the registry. Keeping the spaces separate for RSVP has worked well. I really don't get w= hat is preventing that here. George From: Ross Callon > Date: Sunday, May 5, 2013 10:53 PM To: "mpls@ietf.org" >, "draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org" > Cc: "mpls-chairs@tools.ietf.org" > Subject: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-s= ub-tlvs-registry-02 Working group, this is to start a "two week" poll on adopting draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end May 20th, 2013. Ross (as mpls wg co-chair) --_000_2FE467D3673DCE409A84D67EC2F607BB0FA778AFxmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <6A3530E1920F254EA8C577128BA78486@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
With hat off.

No/do not support.

I believe that making a single sub-TLV space is going to lead to a lot= of confusion in the future as to which sub-TLVs are used with which TLVs. =  That is one will have to search through bunch of documents instead of= seeing it clearly laid out in the registry.  

Keeping the spaces separate for RSVP has worked well.  I really d= on't get what is preventing that here.  

George

From: Ross Callon <rcallon@juniper.net>
Date: Sunday, May 5, 2013 10:53 PM<= br> To: "mpls@ietf.org" <mpls@i= etf.org>, "draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-= registry@tools.ietf.org" <draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.iet= f.org>
Cc: "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>
Subject: [mpls] Poll for WG adoptio= n for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02

Working group,
 
this is to start a "two week" poll on adopting
draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02
as an MPLS working group document.
 
Please send your comments (support/not support) to the mpls working
group mailing list (mpls@ietf.org).
 
This poll will end May 20th, 2013.
 
Ross
(as mpls wg co-chair)
&nbs= p;
&nbs= p;
--_000_2FE467D3673DCE409A84D67EC2F607BB0FA778AFxmbrcdx10ciscoc_-- From swallow@cisco.com Tue May 14 08:30:33 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 047C221F8E49 for ; Tue, 14 May 2013 08:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6x5ls3iqYOnP for ; Tue, 14 May 2013 08:30:27 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id CA45321F8E2C for ; Tue, 14 May 2013 08:30:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3638; q=dns/txt; s=iport; t=1368545428; x=1369755028; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=JipcCKk8H/tkKa24U2MZt0lAvzlcvKnEGpOtQ47JN4g=; b=Ae5RrA/mSfckEDvmYTFl6CpywgibLrWzSM0sQAy4znboyiAauUF5Z7ib 3LoFRXtfb+iwL+VrSKJXWYtneQen/lbmv8fTq9sxeaNK8+6Yu4ZdaWEh8 +Sef7Bc+QcabC1H2a8SBMLz+VOWrxJn/4IrrN2JJYRnO5ctrECaAHpHDH s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAC1YklGtJV2c/2dsb2JhbABagwc3wCt/FnSCHwEBAQQBAQE3LQcLDAYBCBEEAQEBChQJKAYLFAkIAQEEAQ0FCAGHcQMPDK5Shl0NiEiMSIIlMQcGgm5hA5VPgw2KcoUjgw+CJw X-IronPort-AV: E=Sophos;i="4.87,671,1363132800"; d="scan'208";a="210321457" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 14 May 2013 15:30:27 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r4EFURf8016267 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 14 May 2013 15:30:27 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Tue, 14 May 2013 10:30:26 -0500 From: "George Swallow (swallow)" To: Sam Aldrin , "adrian@olddog.co.uk" Thread-Topic: [mpls] Retiring ACH TLVs Thread-Index: Ac5LRX560irUVDlgRIKUWSY/7OcnkAEqVF6AADRhjoA= Date: Tue, 14 May 2013 15:30:26 +0000 Message-ID: <2FE467D3673DCE409A84D67EC2F607BB0FA778F0@xmb-rcd-x10.cisco.com> In-Reply-To: <12BA262D-8402-4E44-B806-F40B8F868642@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.98.56.166] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [mpls] Retiring ACH TLVs X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 15:30:33 -0000 Absolutely! On 5/13/13 6:30 AM, "Sam Aldrin" wrote: >Fully support. > >-sam > >Sent from my iPhone > >On May 7, 2013, at 1:08 PM, "Adrian Farrel" wrote: > >> Hi, >>=20 >> ACH TLVs keep popping up and causing Stewart and me trouble. Mainly it >>is about explaining why no-one actually wants to use them (i.e., when >>each new ACH Type is defined and has a "No TLVs" written for it, we get >>asked "why not?"). >>=20 >> It seems to us that ACH TLVs are an idea that has been rejected. >>Initially we thought they might be used (especially for identifiers), >>but there seems to be good opinion that handling generic TLVs would be a >>pain. >>=20 >> Since I was heavily responsible for insisting that ACH TLVs were >>included in RFC 5586, it seems reasonable that I do the work to fix it. >>=20 >> The I-D below retires ACH TLVs and handles the necessary registry >>changes. >>=20 >> Note, of course, that structured data are still possible within >>individual ACHs if the protocol spec for an individual ACH decides to >>have them. >>=20 >> We're directing this work to the MPLS working group because that is >>where 5586 was written. I have BCC'ed PWE3, L2VPN, and BFD for >>information.=20 >>=20 >> Thanks for any comments. >>=20 >> As humble WG contributors we would be enthusiastic to see early WG >>adoption and last call :-) >>=20 >> Thanks, >> Adrian >>=20 >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: 07 May 2013 17:33 >>> To: Adrian Farrel; Stewart Bryant >>> Subject: New Version Notification for >>>draft-farbryantrel-mpls-retire-ach-tlv- >>> 00.txt >>>=20 >>>=20 >>> A new version of I-D, draft-farbryantrel-mpls-retire-ach-tlv-00.txt >>> has been successfully submitted by Adrian Farrel and posted to the >>> IETF repository. >>>=20 >>> Filename: draft-farbryantrel-mpls-retire-ach-tlv >>> Revision: 00 >>> Title: Retiring TLVs from the Associated Channel Header of the >>>MPLS >>> Generic Associated Channel >>> Creation date: 2013-05-07 >>> Group: Individual Submission >>> Number of pages: 4 >>> URL: =20 >>>http://www.ietf.org/internet-drafts/draft-farbryantrel-mpls-retire- >>> ach-tlv-00.txt >>> Status: =20 >>>http://datatracker.ietf.org/doc/draft-farbryantrel-mpls-retire-ach-tlv >>> Htmlized: =20 >>>http://tools.ietf.org/html/draft-farbryantrel-mpls-retire-ach-tlv-00 >>>=20 >>>=20 >>> Abstract: >>> The MPLS Generic Associated Channel (G-ACh) is a generalization of >>> the applicability of the Pseudowire (PW) Associated Channel Header >>> (ACH). RFC 5586 defines the concept of Type-Length-Variable (TLV) >>> constructs that can be carried in messages on the G-ACh by placing >>> them in the ACH. >>>=20 >>> No Associated Channel Type yet defined uses a TLV. Furthermore, it >>> is believed that handling TLVs in hardware introduces significant >>> problems to the fast-path, and since G-ACh messages are intended to >>> be processed substantially in hardware, the use of TLVs in >>> undesirable. >>>=20 >>> This document updates RFC 5586 by retiring ACH TLVs and removing the >>> associated registry. >>>=20 >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat >>=20 >> _______________________________________________ >> 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 jeff.tantsura@ericsson.com Tue May 14 09:10:46 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0692521F8B64 for ; Tue, 14 May 2013 09:10:45 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSiBd2SK5aSh for ; Tue, 14 May 2013 09:10:40 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id C4DD721F92F4 for ; Tue, 14 May 2013 09:10:38 -0700 (PDT) X-AuditID: c618062d-b7ff46d000006709-18-519261fd099b Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id AF.4E.26377.DF162915; Tue, 14 May 2013 18:10:38 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.02.0328.009; Tue, 14 May 2013 12:10:37 -0400 From: Jeff Tantsura To: "George Swallow (swallow)" Thread-Topic: [mpls] Retiring ACH TLVs Thread-Index: Ac5LRX560irUVDlgRIKUWSY/7OcnkAEoO+2AADzDeAD//8grZQ== Date: Tue, 14 May 2013 16:10:36 +0000 Message-ID: References: <12BA262D-8402-4E44-B806-F40B8F868642@gmail.com>, <2FE467D3673DCE409A84D67EC2F607BB0FA778F0@xmb-rcd-x10.cisco.com> In-Reply-To: <2FE467D3673DCE409A84D67EC2F607BB0FA778F0@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsUyuXSPn+6/xEmBBtMaGC1+9NxgtpjQ+oXR 4tbSlawWt6c0MTqweEz5vZHVY+esu+weS5b8ZPJYsXklYwBLFJdNSmpOZllqkb5dAldGx171 guPyFRPfz2NuYHwt2cXIySEhYCJx7cFHNghbTOLCvfVANheHkMBRRonbnduYIJzljBJXDzWy g1SxCRhI/P92nAXEFhEwkrh4shcszixQIdF94iVQNweHsICqxNK7ZhAlahL7T39mAQmLCDhJ 7D4gDRJmAao4cfg62BReAXuJyXuPgNlCArUSHz99ZgSxOQV8Jf7d7AGbzgh02/dTa5ggNolL 3HoynwniZgGJJXvOM0PYohIvH/9jhajRkViw+xMbhK0tsWzha2aIXYISJ2c+YZnAKDoLyahZ SFpmIWmZhaRlASPLKkaO0uLUstx0I4NNjMCIOSbBpruDcc9Ly0OM0hwsSuK8UVyNgUIC6Ykl qdmpqQWpRfFFpTmpxYcYmTg4pRoYeffWPpvycnXLnOxZ597N/rL7WOBnjelSMzOu/elYJ7It ePmy7gf5n97O5OL/0/X3duCR5vPWh1yfSnktWz3p1oHqdfldSyuDg1h3cZxcf+vIdol+9rUf LH+wcO3bH5y4VCZ6vX1YQPD8Q7f5lu9/cGau2gnnDwvKehisC91ZpvLHZT1e921C4VElluKM REMt5qLiRADPub6iZgIAAA== Cc: "" Subject: Re: [mpls] Retiring ACH TLVs X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 16:10:46 -0000 Support Regards, Jeff On May 14, 2013, at 5:30 PM, "George Swallow (swallow)" = wrote: > Absolutely! >=20 > On 5/13/13 6:30 AM, "Sam Aldrin" wrote: >=20 >> Fully support. >>=20 >> -sam >>=20 >> Sent from my iPhone >>=20 >> On May 7, 2013, at 1:08 PM, "Adrian Farrel" wrote: >>=20 >>> Hi, >>>=20 >>> ACH TLVs keep popping up and causing Stewart and me trouble. Mainly it >>> is about explaining why no-one actually wants to use them (i.e., when >>> each new ACH Type is defined and has a "No TLVs" written for it, we get >>> asked "why not?"). >>>=20 >>> It seems to us that ACH TLVs are an idea that has been rejected. >>> Initially we thought they might be used (especially for identifiers), >>> but there seems to be good opinion that handling generic TLVs would be = a >>> pain. >>>=20 >>> Since I was heavily responsible for insisting that ACH TLVs were >>> included in RFC 5586, it seems reasonable that I do the work to fix it. >>>=20 >>> The I-D below retires ACH TLVs and handles the necessary registry >>> changes. >>>=20 >>> Note, of course, that structured data are still possible within >>> individual ACHs if the protocol spec for an individual ACH decides to >>> have them. >>>=20 >>> We're directing this work to the MPLS working group because that is >>> where 5586 was written. I have BCC'ed PWE3, L2VPN, and BFD for >>> information.=20 >>>=20 >>> Thanks for any comments. >>>=20 >>> As humble WG contributors we would be enthusiastic to see early WG >>> adoption and last call :-) >>>=20 >>> Thanks, >>> Adrian >>>=20 >>>> -----Original Message----- >>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>> Sent: 07 May 2013 17:33 >>>> To: Adrian Farrel; Stewart Bryant >>>> Subject: New Version Notification for >>>> draft-farbryantrel-mpls-retire-ach-tlv- >>>> 00.txt >>>>=20 >>>>=20 >>>> A new version of I-D, draft-farbryantrel-mpls-retire-ach-tlv-00.txt >>>> has been successfully submitted by Adrian Farrel and posted to the >>>> IETF repository. >>>>=20 >>>> Filename: draft-farbryantrel-mpls-retire-ach-tlv >>>> Revision: 00 >>>> Title: Retiring TLVs from the Associated Channel Header of the >>>> MPLS >>>> Generic Associated Channel >>>> Creation date: 2013-05-07 >>>> Group: Individual Submission >>>> Number of pages: 4 >>>> URL: =20 >>>> http://www.ietf.org/internet-drafts/draft-farbryantrel-mpls-retire- >>>> ach-tlv-00.txt >>>> Status: =20 >>>> http://datatracker.ietf.org/doc/draft-farbryantrel-mpls-retire-ach-tlv >>>> Htmlized: =20 >>>> http://tools.ietf.org/html/draft-farbryantrel-mpls-retire-ach-tlv-00 >>>>=20 >>>>=20 >>>> Abstract: >>>> The MPLS Generic Associated Channel (G-ACh) is a generalization of >>>> the applicability of the Pseudowire (PW) Associated Channel Header >>>> (ACH). RFC 5586 defines the concept of Type-Length-Variable (TLV) >>>> constructs that can be carried in messages on the G-ACh by placing >>>> them in the ACH. >>>>=20 >>>> No Associated Channel Type yet defined uses a TLV. Furthermore, it >>>> is believed that handling TLVs in hardware introduces significant >>>> problems to the fast-path, and since G-ACh messages are intended to >>>> be processed substantially in hardware, the use of TLVs in >>>> undesirable. >>>>=20 >>>> This document updates RFC 5586 by retiring ACH TLVs and removing the >>>> associated registry. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> The IETF Secretariat >>>=20 >>> _______________________________________________ >>> 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 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From david.i.allan@ericsson.com Tue May 14 09:18:10 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF68F21F8D8E for ; Tue, 14 May 2013 09:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzxgxvq1lkCu for ; Tue, 14 May 2013 09:17:48 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 69C5621F8506 for ; Tue, 14 May 2013 09:17:40 -0700 (PDT) X-AuditID: c6180641-b7f906d000003e3f-50-51926372f278 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 24.7E.15935.27362915; Tue, 14 May 2013 18:16:51 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.02.0328.009; Tue, 14 May 2013 12:16:50 -0400 From: David Allan I To: "" Thread-Topic: [mpls] Retiring ACH TLVs Thread-Index: Ac5LRX560irUVDlgRIKUWSY/7OcnkAEoO+2AADzDeAD//8grZf///prA Date: Tue, 14 May 2013 16:16:49 +0000 Message-ID: References: <12BA262D-8402-4E44-B806-F40B8F868642@gmail.com>, <2FE467D3673DCE409A84D67EC2F607BB0FA778F0@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUyuXRPgm5x8qRAg01vhSxuLV3J6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujF23VrIWXJermHerlbmBcb1kFyMnh4SAiUT7iYnsELaYxIV7 69m6GLk4hASOMkpM//0GylnOKLH5QAMLSBWbgIHEnv9fGEFsEQFViYbFN1lBbGEg+8SS08wQ cTWJ/ac/s0DYbhL/d1wAq2cBqvnXdxushlfAW6L3ejsrxIJtjBJPfl8Ea+AUcJDY8fsSWBEj 0EnfT61hArGZBcQlbj2ZzwRxqoDEkj3nmSFsUYmXj/+xQtjKEkue7GeBqNeRWLD7ExuErS2x bOFrqMWCEidnPmGZwCg6C8nYWUhaZiFpmYWkZQEjyypGjtLi1LLcdCPDTYzA4D8mwea4g3HB J8tDjNIcLErivIlcjYFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGPtu3k/1cj6+yKCWt8o0 SZlhv3bbh8Dzu/of6c96mpEqtvDeLvsX52pDjfdOkltjyOikmqPPZvA0jOXO39Z4pSDbBfcb NiU0G7OpBzubM3pff3R8xq0NSx2/8+6fvrOLd9GM00ISp+Vy173YvaFK9m1yT4Ri88WH6rvt GqNiMhXj+flWlScoKrEUZyQaajEXFScCAJiN53RMAgAA Subject: Re: [mpls] Retiring ACH TLVs X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 16:18:10 -0000 I'm all for deprecating ACH TLVs.=20 Support=20 Dave=20 >>> Hi, >>>=20 >>> ACH TLVs keep popping up and causing Stewart and me trouble. Mainly=20 >>> it is about explaining why no-one actually wants to use them (i.e.,=20 >>> when each new ACH Type is defined and has a "No TLVs" written for=20 >>> it, we get asked "why not?"). >>>=20 >>> It seems to us that ACH TLVs are an idea that has been rejected. >>> Initially we thought they might be used (especially for=20 >>> identifiers), but there seems to be good opinion that handling=20 >>> generic TLVs would be a pain. >>>=20 >>> Since I was heavily responsible for insisting that ACH TLVs were=20 >>> included in RFC 5586, it seems reasonable that I do the work to fix it. >>>=20 >>> The I-D below retires ACH TLVs and handles the necessary registry=20 >>> changes. >>>=20 >>> Note, of course, that structured data are still possible within=20 >>> individual ACHs if the protocol spec for an individual ACH decides=20 >>> to have them. >>>=20 >>> We're directing this work to the MPLS working group because that is=20 >>> where 5586 was written. I have BCC'ed PWE3, L2VPN, and BFD for=20 >>> information. >>>=20 >>> Thanks for any comments. >>>=20 >>> As humble WG contributors we would be enthusiastic to see early WG=20 >>> adoption and last call :-) >>>=20 >>> Thanks, >>> Adrian >>>=20 >>>> -----Original Message----- >>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>> Sent: 07 May 2013 17:33 >>>> To: Adrian Farrel; Stewart Bryant >>>> Subject: New Version Notification for >>>> draft-farbryantrel-mpls-retire-ach-tlv- >>>> 00.txt >>>>=20 >>>>=20 >>>> A new version of I-D, draft-farbryantrel-mpls-retire-ach-tlv-00.txt >>>> has been successfully submitted by Adrian Farrel and posted to the=20 >>>> IETF repository. >>>>=20 >>>> Filename: draft-farbryantrel-mpls-retire-ach-tlv >>>> Revision: 00 >>>> Title: Retiring TLVs from the Associated Channel Header of the >>>> MPLS >>>> Generic Associated Channel >>>> Creation date: 2013-05-07 >>>> Group: Individual Submission >>>> Number of pages: 4 >>>> URL: =20 >>>> http://www.ietf.org/internet-drafts/draft-farbryantrel-mpls-retire- >>>> ach-tlv-00.txt >>>> Status: =20 >>>> http://datatracker.ietf.org/doc/draft-farbryantrel-mpls-retire-ach-tlv >>>> Htmlized: =20 >>>> http://tools.ietf.org/html/draft-farbryantrel-mpls-retire-ach-tlv-0 >>>> 0 >>>>=20 >>>>=20 >>>> Abstract: >>>> The MPLS Generic Associated Channel (G-ACh) is a generalization of =20 >>>> the applicability of the Pseudowire (PW) Associated Channel Header =20 >>>> (ACH). RFC 5586 defines the concept of Type-Length-Variable (TLV) =20 >>>> constructs that can be carried in messages on the G-ACh by placing =20 >>>> them in the ACH. >>>>=20 >>>> No Associated Channel Type yet defined uses a TLV. Furthermore,=20 >>>> it is believed that handling TLVs in hardware introduces=20 >>>> significant problems to the fast-path, and since G-ACh messages=20 >>>> are intended to be processed substantially in hardware, the use of=20 >>>> TLVs in undesirable. >>>>=20 >>>> This document updates RFC 5586 by retiring ACH TLVs and removing=20 >>>> the associated registry. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> The IETF Secretariat >>>=20 >>> _______________________________________________ >>> 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 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From davari@broadcom.com Tue May 14 10:04:17 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90C6B21F8F53 for ; Tue, 14 May 2013 10:04:16 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irrprYf4N0yO for ; Tue, 14 May 2013 10:04:11 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9B70621F91F1 for ; Tue, 14 May 2013 10:03:46 -0700 (PDT) Received: from [10.9.208.53] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Tue, 14 May 2013 10:00:00 -0700 X-Server-Uuid: 06151B78-6688-425E-9DE2-57CB27892261 Received: from SJEXCHCAS07.corp.ad.broadcom.com (10.16.203.16) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.1.438.0; Tue, 14 May 2013 10:03:34 -0700 Received: from SJEXCHMB12.corp.ad.broadcom.com ( [fe80::bc15:c1e1:c29a:36f7]) by SJEXCHCAS07.corp.ad.broadcom.com ( [::1]) with mapi id 14.01.0438.000; Tue, 14 May 2013 10:03:33 -0700 From: "Shahram Davari" To: "George Swallow (swallow)" , "Sam Aldrin" , "adrian@olddog.co.uk" Thread-Topic: [mpls] Retiring ACH TLVs Thread-Index: Ac5LRX560irUVDlgRIKUWSY/7OcnkAEuhUCAADzDeQAAC2zZcA== Date: Tue, 14 May 2013 17:03:32 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F281BDF32DC@SJEXCHMB12.corp.ad.broadcom.com> References: <12BA262D-8402-4E44-B806-F40B8F868642@gmail.com> <2FE467D3673DCE409A84D67EC2F607BB0FA778F0@xmb-rcd-x10.cisco.com> In-Reply-To: <2FE467D3673DCE409A84D67EC2F607BB0FA778F0@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.203.100] MIME-Version: 1.0 X-WSS-ID: 7D8CB21A31W19257230-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "" Subject: Re: [mpls] Retiring ACH TLVs X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 May 2013 17:04:19 -0000 Support. Thx SD -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Geo= rge Swallow (swallow) Sent: Tuesday, May 14, 2013 8:30 AM To: Sam Aldrin; adrian@olddog.co.uk Cc: Subject: Re: [mpls] Retiring ACH TLVs Absolutely! On 5/13/13 6:30 AM, "Sam Aldrin" wrote: >Fully support. > >-sam > >Sent from my iPhone > >On May 7, 2013, at 1:08 PM, "Adrian Farrel" wrote: > >> Hi, >>=20 >> ACH TLVs keep popping up and causing Stewart and me trouble. Mainly it >>is about explaining why no-one actually wants to use them (i.e., when >>each new ACH Type is defined and has a "No TLVs" written for it, we get >>asked "why not?"). >>=20 >> It seems to us that ACH TLVs are an idea that has been rejected. >>Initially we thought they might be used (especially for identifiers), >>but there seems to be good opinion that handling generic TLVs would be a >>pain. >>=20 >> Since I was heavily responsible for insisting that ACH TLVs were >>included in RFC 5586, it seems reasonable that I do the work to fix it. >>=20 >> The I-D below retires ACH TLVs and handles the necessary registry >>changes. >>=20 >> Note, of course, that structured data are still possible within >>individual ACHs if the protocol spec for an individual ACH decides to >>have them. >>=20 >> We're directing this work to the MPLS working group because that is >>where 5586 was written. I have BCC'ed PWE3, L2VPN, and BFD for >>information.=20 >>=20 >> Thanks for any comments. >>=20 >> As humble WG contributors we would be enthusiastic to see early WG >>adoption and last call :-) >>=20 >> Thanks, >> Adrian >>=20 >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: 07 May 2013 17:33 >>> To: Adrian Farrel; Stewart Bryant >>> Subject: New Version Notification for >>>draft-farbryantrel-mpls-retire-ach-tlv- >>> 00.txt >>>=20 >>>=20 >>> A new version of I-D, draft-farbryantrel-mpls-retire-ach-tlv-00.txt >>> has been successfully submitted by Adrian Farrel and posted to the >>> IETF repository. >>>=20 >>> Filename: draft-farbryantrel-mpls-retire-ach-tlv >>> Revision: 00 >>> Title: Retiring TLVs from the Associated Channel Header of the >>>MPLS >>> Generic Associated Channel >>> Creation date: 2013-05-07 >>> Group: Individual Submission >>> Number of pages: 4 >>> URL: =20 >>>http://www.ietf.org/internet-drafts/draft-farbryantrel-mpls-retire- >>> ach-tlv-00.txt >>> Status: =20 >>>http://datatracker.ietf.org/doc/draft-farbryantrel-mpls-retire-ach-tlv >>> Htmlized: =20 >>>http://tools.ietf.org/html/draft-farbryantrel-mpls-retire-ach-tlv-00 >>>=20 >>>=20 >>> Abstract: >>> The MPLS Generic Associated Channel (G-ACh) is a generalization of >>> the applicability of the Pseudowire (PW) Associated Channel Header >>> (ACH). RFC 5586 defines the concept of Type-Length-Variable (TLV) >>> constructs that can be carried in messages on the G-ACh by placing >>> them in the ACH. >>>=20 >>> No Associated Channel Type yet defined uses a TLV. Furthermore, it >>> is believed that handling TLVs in hardware introduces significant >>> problems to the fast-path, and since G-ACh messages are intended to >>> be processed substantially in hardware, the use of TLVs in >>> undesirable. >>>=20 >>> This document updates RFC 5586 by retiring ACH TLVs and removing the >>> associated registry. >>>=20 >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat >>=20 >> _______________________________________________ >> 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 ietf-secretariat-reply@ietf.org Wed May 15 03:56:38 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3CEB21F8935 for ; Wed, 15 May 2013 03:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpBBuzpK9wmQ; Wed, 15 May 2013 03:56:38 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E4121F8E9E; Wed, 15 May 2013 03:56:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: mpls@ietf.org, mpls-chairs@tools.ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.45 Message-ID: <20130515105638.25106.75568.idtracker@ietfa.amsl.com> Date: Wed, 15 May 2013 03:56:38 -0700 From: IETF Secretariat Subject: [mpls] State changed: charter-ietf-mpls-05-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 10:56:39 -0000 State changed to Informal IESG review. URL: http://datatracker.ietf.org/doc/charter-ietf-mpls/ From adrian@olddog.co.uk Wed May 15 03:59:32 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37CF021F8FEC for ; Wed, 15 May 2013 03:59:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.467 X-Spam-Level: X-Spam-Status: No, score=-2.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57HgiNZf+xkU for ; Wed, 15 May 2013 03:59:27 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 4E09621F8F69 for ; Wed, 15 May 2013 03:59:27 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4FAxPR0004149 for ; Wed, 15 May 2013 11:59:25 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4FAxMUe004108 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 15 May 2013 11:59:23 +0100 From: "Adrian Farrel" To: Date: Wed, 15 May 2013 11:59:21 +0100 Message-ID: <003901ce515b$415079f0$c3f16dd0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5RWz91KnwCnbMGSlCZCqxCBfdHEQ== Content-Language: en-gb Subject: [mpls] Your draft charter X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 10:59:32 -0000 The current proposed text is at https://datatracker.ietf.org/doc/charter-ietf-mpls/ Keep commenting and discussing with your chairs. Adrian From loa@pi.nu Wed May 15 12:01:48 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D459721F9029 for ; Wed, 15 May 2013 12:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.748 X-Spam-Level: X-Spam-Status: No, score=-100.748 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggR9xiUCit3B for ; Wed, 15 May 2013 12:01:43 -0700 (PDT) Received: from pipi.pi.nu (unknown [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 1352021F9180 for ; Wed, 15 May 2013 12:01:33 -0700 (PDT) Received: from [192.168.1.130] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id B835D18028FF for ; Wed, 15 May 2013 21:01:31 +0200 (CEST) Message-ID: <5193DB8D.9040405@pi.nu> Date: Wed, 15 May 2013 21:01:33 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "mpls@ietf.org" References: In-Reply-To: X-Forwarded-Message-Id: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Fwd: NomCom 2013-2014 Call for Volunteers - CORRECTED dates in first sentence X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 19:01:48 -0000 Working Group, The IETF are forming the next Nomcom, if you are eligible please consider carefully to through your name into the hat. /Loa -------- Original Message -------- Subject: NomCom 2013-2014 Call for Volunteers - CORRECTED dates in first sentence Date: Mon, 13 May 2013 21:27:21 +0000 From: Mankin, Allison To: ietf-announce@ietf.org The IETF nominating committee (nomcom) process for 2013-14 has begun. The IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, and the IESG. Ten voting members for the nomcom are selected in a verifiably random way from a pool of volunteers. The more volunteers, the better chance we have of choosing a random yet representative cross section of the IETF population. This year, a challenge: let's get beyond the 100-mark for number of volunteers. Let's get to 200 volunteers! The details of the operation of the nomcom can be found in RFC 3777. Volunteers must have attended 3 of the past 5 IETF meetings. As specified in RFC 3777, that means three out of the five past meetings up to the time this email announcement goes out to start the solicitation of volunteers. The five meetings out of which you must have attended three are IETF 82, 83, 84, 85, 86. If you qualify, please volunteer. However, much as we want this, before you decide to volunteer, please be sure you are willing to forgo appointment to any of the positions for which this nomcom is responsible. The list of people and posts whose terms end with the March 2014 IETF meeting, and thus the positions for which this nomcom is responsible, are IAOC: Chris Griffiths IAB: Bernard Aboba Marc Blanchet Ross Callon Eliot Lear Hannes Tschofenig IESG: Barry Leiba (Applications) Brian Haberman (Internet) Benoit Claise (Operations and Management) Gonzalo Camarillo (RAI) Stewart Bryant (Routing) Sean Turner (Security) Martin Stiemerling (Transport) The primary activity for this nomcom will begin in July 2013 and should be completed in January 2014. The nomcom will have regularly scheduled conference calls to ensure progress. There will be activities to collect requirements from the community, review candidate questionnaires, review feedback from community members about candidates, and talk to candidates. Thus, being a nomcom member does require some time commitment. Please volunteer by sending me an email before 11:59 pm EDT (UTC -4 hours) June 16, 2013, as follows: To: amankin@verisign.com Subject: Nomcom 2013-14 Volunteer Please include the following information in the email body: // First/Given Name followed by Last/Family Name // matching how you enter it in the IETF Registration Form) // Typically what goes in the Company field // in the IETF Registration Form [] // For confirmation if selected You should expect an email response from me within 3 business days stating whether or not you are qualified. If you don't receive this response, please re-send your email with the tag "RESEND"" added to the subject line. If you are not yet sure if you would like to volunteer, please consider that nomcom members play a very important role in shaping the leadership of the IETF. Volunteering for the nomcom is a great way to contribute to the IETF! I will be publishing a more detailed target timetable, as well as details of the randomness seeds to be used for the RFC 3797 selection process, within the next couple weeks. Thank you! Allison Mankin amankin@verisign.com P.S. Because the 2012-2013 nomcom is still at work, we cannot use the ietf addresses for the nomcom chair or the nomcom committee yet, so please send all the volunteer mail (and any questions/comments you may have) to the address given. From agmalis@gmail.com Wed May 15 14:51:48 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D637D11E80E3 for ; Wed, 15 May 2013 14:51: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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HD8Q98NcRMDn for ; Wed, 15 May 2013 14:51:47 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 837F911E80E0 for ; Wed, 15 May 2013 14:51:46 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id ey16so3638954wid.17 for ; Wed, 15 May 2013 14:51:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=s6+khECRNBpUF37wSBBIDKU6OYbtsA8M9jPVu+lRmIA=; b=fMquXifgvRXI+EtUYBF3cfBchy8z5ZZOVLholJDx834Phu4gMdfe+3StLdHk4lNffD TEEwXQBw5tYI/6Sz41C/QxssGla2rPAAipRQ+bfdAICxP43YJ5qVl9LpPvdXLy9l2Pn6 VcXVV5OVmkGDcV9/nkaij3cmTX2BZvVv9Db4/FlHUvD2VB62FNZNqnDGM3ZAKpi0xfdA GohQzRhbTBEgJeE5/kpNP8nBwSj0LEtOqwRNBwfIlh/5WEfUzhYad8b97QgvOT4cgfk0 P6+Tj4dSkXRCP1+WjJv71UsFxT5wYZbPWyVQOBwOpyG4zuRoKUAmKjZ9VBaUv0YgHQRs 7kFA== X-Received: by 10.180.89.170 with SMTP id bp10mr18157600wib.26.1368654705331; Wed, 15 May 2013 14:51:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.79.138 with HTTP; Wed, 15 May 2013 14:51:25 -0700 (PDT) In-Reply-To: <2FE467D3673DCE409A84D67EC2F607BB0FA778AF@xmb-rcd-x10.cisco.com> References: <62CCD4C52ACDAD4481149BD5D8A72FD316C3ED09@CH1PRD0510MB355.namprd05.prod.outlook.com> <2FE467D3673DCE409A84D67EC2F607BB0FA778AF@xmb-rcd-x10.cisco.com> From: "Andrew G. Malis" Date: Wed, 15 May 2013 17:51:25 -0400 Message-ID: To: "George Swallow (swallow)" Content-Type: multipart/alternative; boundary=14dae9cc955088154004dcc8c192 Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org" Subject: Re: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 May 2013 21:51:48 -0000 --14dae9cc955088154004dcc8c192 Content-Type: text/plain; charset=ISO-8859-1 I agree with George from a definition standpoint, I don't find the "TLVs and sub-TLVs" table at http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xmldifficult to follow at all. However, it would be interesting to hear from implementers if they've had any difficulty implementing the TLVs and sub-TLVs. But at this point, with existing implementations, I think we need a REALLY GOOD reason to change other than some people find the table confusing, which seems to be the main justification in the draft. Also, if the draft is adopted, it would be useful for it to have a link to the IANA page in the references. Cheers, Andy On Tue, May 14, 2013 at 11:26 AM, George Swallow (swallow) < swallow@cisco.com> wrote: > With hat off. > > No/do not support. > > I believe that making a single sub-TLV space is going to lead to a lot > of confusion in the future as to which sub-TLVs are used with which TLVs. > That is one will have to search through bunch of documents instead of > seeing it clearly laid out in the registry. > > Keeping the spaces separate for RSVP has worked well. I really don't > get what is preventing that here. > > George > > From: Ross Callon > Date: Sunday, May 5, 2013 10:53 PM > To: "mpls@ietf.org" , " > draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org" < > draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org> > Cc: "mpls-chairs@tools.ietf.org" > > Subject: [mpls] Poll for WG adoption for > draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 > > Working group, > > this is to start a "two week" poll on adopting > draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 > as an MPLS working group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (*mpls@ietf.org* ). > > This poll will end May 20th, 2013. > > Ross > (as mpls wg co-chair) > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --14dae9cc955088154004dcc8c192 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I agree with George from a definition standpoint, I d= on't find the "TLVs and sub-TLVs" table at http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping= -parameters.xml difficult to follow at all. However, it would be intere= sting to hear from implementers if they've had any difficulty implement= ing the TLVs and sub-TLVs.

But at this point, with existing implementations, I think we= need a REALLY GOOD reason to change other than some people find the table = confusing, which seems to be the main justification in the draft.

Also, if the draft is adopted, it would be useful for i= t to have a link to the IANA page in the references.

Cheers,
Andy



On Tue, May 14, 2013 at 11:26 AM, George Swallow (swallow) <swallow@cisco.= com> wrote:
With hat off.

No/do not support.

I believe that making a single sub-TLV space is going to lead to a lot= of confusion in the future as to which sub-TLVs are used with which TLVs. = =A0That is one will have to search through bunch of documents instead of se= eing it clearly laid out in the registry. =A0

Keeping the spaces separate for RSVP has worked well. =A0I really don&= #39;t get what is preventing that here. =A0

George

From: Ross Callon <rcallon@juniper.net>
Date: Sunday, May 5, 2013 10:53 PM<= br> To: "mpls@ietf.org" <mpls@ietf.org>, "draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.o= rg" <draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-= registry@tools.ietf.org>
Cc: "mpls-chairs@tools.ietf.org"= <mpls-c= hairs@tools.ietf.org>

Subject: [mpls] Poll for WG adoptio= n for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02

Working group,
=A0
this is to start a "two week" poll on adopting
draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02
as an MPLS working group document.
=A0
Please send your comments (support/not support) to the mpls working
group mailing list (mpls@ietf.org).
=A0
This poll will end May 20th, 2013.
=A0
Ross
(as mpls wg co-chair)
=A0
=A0

_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls


--14dae9cc955088154004dcc8c192-- From mach.chen@huawei.com Wed May 15 20:35:30 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E38B21F89FF for ; Wed, 15 May 2013 20:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id teL+n3GgrjMD for ; Wed, 15 May 2013 20:35:26 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 970A321F85EB for ; Wed, 15 May 2013 20:35:23 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARK68703; Thu, 16 May 2013 03:35:19 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 16 May 2013 04:34:42 +0100 Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 16 May 2013 04:35:15 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.134]) by szxeml422-hub.china.huawei.com ([10.82.67.161]) with mapi id 14.01.0323.007; Thu, 16 May 2013 11:35:10 +0800 From: Mach Chen To: "Andrew G. Malis" , "George Swallow (swallow)" Thread-Topic: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 Thread-Index: AQHOUbZsa483pHucbkmjSAI4uCnpBpkHFe1Q Date: Thu, 16 May 2013 03:35:10 +0000 Message-ID: References: <62CCD4C52ACDAD4481149BD5D8A72FD316C3ED09@CH1PRD0510MB355.namprd05.prod.outlook.com> <2FE467D3673DCE409A84D67EC2F607BB0FA778AF@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255B86EE0szxeml558mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Ross Callon , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org" Subject: Re: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 03:35:30 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255B86EE0szxeml558mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andy, The current "TLVs and sub-TLVs" structure works very well if specific sub-T= LVs only belong to a single TLV. But with increasing of TLVs and sub-TLVs, = there are more and more TLVs trying to share sub-TLVs defined for other TLV= . For example, Type 16 TLV is designed to reuse all existing and future sub= -TLVs defined for Type 1 TLV. Type 21 TLV is also intended to apply all the= existing and future defined sub-TLVs of Type 1 TLV, and at the same time, = it also defines its own dedicated sub-TLVs, it's difficult or even impossib= le to achieve this with the current "TLV and sub-TLVs" allocation rules and= policies. Since if one TLV wants to inherit/reuse all sub-TLVs of one TLV,= they actually share the same name space, there is no safe way to define TL= V dedicated sub-TLVs. For example, Type 1 TLV has defined 25 sub-TLVs so far, it will define more= in the future, Type 21 TLV applies these sub-TLVs for itself; then Type 21= TLV wants to define its own sub-TLV, what code points should be allocated = to the sub-TLV? If allocating 26 to it, then when Type 1 TLV defines one m= ore new sub-TLV, it will probably be allocated 26 as the code point, then c= onfliction occurs. And even if you allocate a much bigger number (e.g., 100= 0) to the new sub-TLV, in theory, the confliction cannot be avoided complet= ely. The required changes proposed in the draft will not impact the implementati= on, it just changes the way on how to register a sub-TLV. In addition, the similar definition/usage is not novel, for example, the At= tribute Flag TLV can be carried/shared in/by many Objects, but flags are de= fined and register in a common space. There are a lot of discussions online/offline about the TLV and sub-TLVs al= locations rules and policies on progressing the draft-ietf-mpls-return-path= -specified-lsp-ping, and the draft is still stuck by this allocation issue= . Seems this is the best solution that we could think of so far. Best regards, Mach From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of And= rew G. Malis Sent: Thursday, May 16, 2013 5:51 AM To: George Swallow (swallow) Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-pac-mpls-= lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org Subject: Re: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-a= nd-sub-tlvs-registry-02 I agree with George from a definition standpoint, I don't find the "TLVs an= d sub-TLVs" table at http://www.iana.org/assignments/mpls-lsp-ping-paramete= rs/mpls-lsp-ping-parameters.xml difficult to follow at all. However, it wou= ld be interesting to hear from implementers if they've had any difficulty i= mplementing the TLVs and sub-TLVs. But at this point, with existing implementations, I think we need a REALLY = GOOD reason to change other than some people find the table confusing, whic= h seems to be the main justification in the draft. Also, if the draft is adopted, it would be useful for it to have a link to = the IANA page in the references. Cheers, Andy On Tue, May 14, 2013 at 11:26 AM, George Swallow (swallow) > wrote: With hat off. No/do not support. I believe that making a single sub-TLV space is going to lead to a lot of c= onfusion in the future as to which sub-TLVs are used with which TLVs. That= is one will have to search through bunch of documents instead of seeing it= clearly laid out in the registry. Keeping the spaces separate for RSVP has worked well. I really don't get w= hat is preventing that here. George From: Ross Callon > Date: Sunday, May 5, 2013 10:53 PM To: "mpls@ietf.org" >, "draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org" > Cc: "mpls-chairs@tools.ietf.org" > Subject: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-s= ub-tlvs-registry-02 Working group, this is to start a "two week" poll on adopting draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end May 20th, 2013. Ross (as mpls wg co-chair) _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255B86EE0szxeml558mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi Andy,=

=  

= The current “TLVs and sub-T= LVs” structure works very well if specific sub-TLVs only belong to a single TLV= . But with increasing of TLVs and sub-TLVs, there are more and more TLVs tr= ying to share sub-TLVs defined for other TLV. For example, Type 16 TLV is d= esigned to reuse all existing and future sub-TLVs defined for Type 1 TLV. Type 21 TLV is also intended to ap= ply all the existing and future defined sub-TLVs of Type 1 TLV, and at the = same time, it also defines its own dedicated sub-TLVs, it’s difficult= or even impossible to achieve this with the current “TLV and sub-TLVs” allocation rules and policies. = Since if one TLV wants to inherit/reuse all sub-TLVs of one TLV, they actua= lly share the same name space, there is no safe way to define TLV dedicated= sub-TLVs.

=  

= For example, Type 1 TLV has defin= ed 25 sub-TLVs so far, it will define more in the future, Type 21 TLV applies= these sub-TLVs for itself; then Type 21 TLV wants to define its own sub-TL= V, what code points should be allocated to the sub-TLV?  If allocating 26 to it, then = when Type 1 TLV defines one more new sub-TLV, it will probably be allocated= 26 as the code point, then confliction occurs. And even if you allocate a = much bigger number (e.g., 1000) to the new sub-TLV, in theory, the confliction cannot be avoided completely.

=  

= The required changes proposed in the draft will not impact the implementation, it just changes the way on h= ow to register a sub-TLV.

=  

= In addition, the similar definiti= on/usage is not novel, for example, the Attribute Flag TLV can be carried/shared in= /by many Objects, but flags are defined and register in a common space.

=  

= There are a lot of discussions on= line/offline about the TLV and sub-TLVs allocations rules and policies on progressing t= he draft-ietf-mpls-return-path-specified-lsp-ping,  and the draft is still stuck = by this allocation issue. Seems this is the best solution that we could thi= nk of so far.  

=  

= Best regards,

= Mach

=  

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Andrew G. Malis
Sent: Thursday, May 16, 2013= 5:51 AM
To: George Swallow (swallow)=
Cc: Ross Callon; mpls@ietf.o= rg; mpls-chairs@tools.ietf.org; draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-r= egistry@tools.ietf.org
Subject: Re: [mpls] Poll for= WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02=

 

I agre= e with George from a definition standpoint, I don't find the "TLVs and= sub-TLVs" table at http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-para= meters.xml difficult to follow at all. However, it would be interesting= to hear from implementers if they've had any difficulty implementing the T= LVs and sub-TLVs.

But at this point, with existing impl= ementations, I think we need a REALLY GOOD reason to change other than some= people find the table confusing, which seems to be the main justification in the draft.

 

Also, if the draft is adopted, it wou= ld be useful for it to have a link to the IANA page in the references.

Cheers,

Andy

&= nbsp;

On Tue, May 14, 2013 at 11:26 AM, Geo= rge Swallow (swallow) <swallow@cisco.com> wrote:

With hat off.

 

No/do not support.

 

I believe that making a single sub-TLV space is going to lead to a= lot of confusion in the future as to which sub-TLVs are used with which TLVs.  That is one will have to search through bunch of do= cuments instead of seeing it clearly laid out in the registry.  <= /o:p>

 

Keeping the spaces separate for RSVP has worked well.  I real= ly don't get what is preventing that here.  <= /p>

 

George

 

From: Ross Callon <rcallon@juniper.net>
Date: Sunday, May 5, 2013 10= :53 PM
To: "mpls@ietf.org" <mpls@ietf.org>, "draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@too= ls.ietf.org" <draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-= registry@tools.ietf.org>
Cc: "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>


Subject: [mpls] Poll for WG = adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02

 

Working group,

 

this is to start a &quo= t;two week" poll on adopting

draft-pac-mpls-lsp-ping= -tlvs-and-sub-tlvs-registry-02

as an MPLS working grou= p document.

 

Please send your commen= ts (support/not support) to the mpls working

group mailing list (mpls@ietf.org).

 

This poll will end May = 20th, 2013.

 

Ross<= /font>

(as mpls wg co-chair)

 

 


_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

 

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255B86EE0szxeml558mbschi_-- From ietfc@btconnect.com Thu May 16 02:48:31 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6718221F889C for ; Thu, 16 May 2013 02:48:31 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K8JKthq0Gf8E for ; Thu, 16 May 2013 02:48:25 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 02C3021F8895 for ; Thu, 16 May 2013 02:48:24 -0700 (PDT) Received: from mail185-ch1-R.bigfish.com (10.43.68.242) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.23; Thu, 16 May 2013 09:48:23 +0000 Received: from mail185-ch1 (localhost [127.0.0.1]) by mail185-ch1-R.bigfish.com (Postfix) with ESMTP id A905E240491; Thu, 16 May 2013 09:48:23 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.254.197; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0711HT002.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -19 X-BigFish: PS-19(zz98dI9371I936eI542Iec9I1432I1418I4015Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839h946hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh304l1d11m1155h) Received: from mail185-ch1 (localhost.localdomain [127.0.0.1]) by mail185-ch1 (MessageSwitch) id 1368697651905577_9405; Thu, 16 May 2013 09:47:31 +0000 (UTC) Received: from CH1EHSMHS028.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.235]) by mail185-ch1.bigfish.com (Postfix) with ESMTP id D0677220214; Thu, 16 May 2013 09:47:31 +0000 (UTC) Received: from DB3PRD0711HT002.eurprd07.prod.outlook.com (157.56.254.197) by CH1EHSMHS028.bigfish.com (10.43.70.28) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 16 May 2013 09:47:31 +0000 Received: from DB3PRD0511HT003.eurprd05.prod.outlook.com (157.56.254.213) by pod51017.outlook.com (10.255.183.35) with Microsoft SMTP Server (TLS) id 14.16.311.1; Thu, 16 May 2013 09:47:19 +0000 Message-ID: <02b901ce5219$9ae3bf40$4001a8c0@gateway.2wire.net> From: t.petch To: Loa Andersson , "Carlos Pignataro (cpignata)" References: <518E0484.7030904@pi.nu><3598378B-38F0-4AB4-ABEA-5BEFBB714DD8@cisco.com> <518F3E03.7080003@pi.nu> Date: Thu, 16 May 2013 10:07:51 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.254.213] Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: btconnect.com Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org, mpls-ads@tools.ietf.org Subject: Re: [mpls] MPLS wg charter update X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 09:48:31 -0000 ---- Original Message ----- From: "Loa Andersson" To: "Carlos Pignataro (cpignata)" Cc: ; ; Sent: Sunday, May 12, 2013 8:00 AM Carlos, thanks for comments! My personal response too them would be: 1. Work items vs. focus areas. Not being a native English speaker I would need a better definition of the terms, tentatively I'd say that either would work for me, maybe say "work items and focus areas" if that aligns with how the terms are defined. Loa I see focus areas as vague and woolly, like soft-focus only different, useful for management speak that can later be redefined to mean something different if the need arises:-) Work items I would see as more specific, having an outcome that is defined and can be measured eg was an I-D delivered to the IESG by March 2010? Of the items listed, I think that most are work items but perhaps not =95 Maintain existing MPLS requirements, mechanisms, and protocols, in coordination with other working groups, e.g. CCAMP, PWE3 and OPSAWG working groups. =95 Evolve key MPLS protocols, including LDP, tLDP, mLDP, RSVP-TE and LSP Ping to meet new requirements. I would prefer those at the end, not the front, which is where I think that catch-alls belong; and I would make them more action-oriented, such as =95 Identify new requirements in key MPLS protocols, including but not limited to LDP, tLDP, mLDP, RSVP-TE and LSP Ping, and define solutions to meet them Tom Petch 2. IPv6 gap analysis I believe that the IPv6 gap analysis is part of "necessary extensions ... for dual stack and IPv6 only" The gap analysis will show up as a milestone when we accept an ID on that topic as a wg group document. /Loa On 2013-05-12 01:24, Carlos Pignataro (cpignata) wrote: > Hi Loa, > > Please find two very small questions/comments inline. > > Thumb typed by Carlos Pignataro. > Excuze typofraphicak errows > > On May 11, 2013, at 4:43 AM, "Loa Andersson" wrote: > >> Working Group, >> >> The working group chairs have discussed an MPLS wg charter update >> for sometime. >> >> We have converged on the text below and while we understand that >> it still not "perfect" (for some value of perfect) we believe that >> it is good enough to serve as a basis for a working group discussion >> of our charter. >> >> Please note that this is not a "re-charter", but a normal charter update >> (maintenance) that should take place when adopting new work items or >> finalizing others. The only "issue" is that we have not maintained the >> charter to the degree we should have during the last years when the >> work load has been quite heavy. >> >> Please view the text below as a starting point for an update of our >> charter and send your comments to mpls@ietf.org. We would like to see >> your comments before June 7th, 2013. >> >> -------------------- Proposed new charter text ------------------------- >> >> >> Description of Working Group >> >> The MPLS working group is responsible for standardizing technology >> for label switching and for the implementation of label-switched >> paths over packet based link-level technologies. >> >> The responsibility includes procedures and protocols for the >> distribution of labels between Label Switching Routers (LSRs), >> MPLS packet encapsulation, and for Operation, Administration, and >> Maintenance (OAM) (including the necessary management objects >> expressed as MIB modules or using other techniques). >> >> The current WG work items are: >> > > The text above looks good. A nit: are these "work items" or "focus areas"? > >> =95 Maintain existing MPLS requirements, mechanisms, and protocols, >> in coordination with other working groups, e.g. CCAMP, PWE3 >> and OPSAWG working groups. >> =95 Evolve key MPLS protocols, including LDP, tLDP, mLDP, RSVP-TE >> and LSP Ping to meet new requirements. >> =95 Define an overall OAM framework for topology-driven, traffic >> engineered, and transport profile MPLS applications. >> =95 Determine MPLS-specific aspects of traffic engineering for >> multi-areas/multi-AS in cooperation with the CCAMP WG >> =95 Define necessary extensions for MPLS key protocols for >> dual-stack and IPv6 only networks > > In addition to defining extensions, could we add also a "gap analysis" of the IPv6 (dual stack and IPv6 only) state for MPLS key protocols and procedures? > > Thanks, > > Carlos. > >> =95 Coordinate with the CCAMP working group on the extensions of >> MPLS and GMPLS protocols >> =95 Document current implementation practices for MPLS load sharing= . >> =95 Document mechanisms for securing MPLS networks in coordination >> with the KARP working group. >> =95 Document mechanisms for adding multi-topology support to >> existing MPLS protocols. >> =95 Document use cases for MPLS protocols. >> >> -------------------------- end proposed text ------------------------ >> >> Loa >> (for the wg chairs) From agmalis@gmail.com Thu May 16 04:27:54 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 226EC21F8F41 for ; Thu, 16 May 2013 04:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EBcvSsfCsLFy for ; Thu, 16 May 2013 04:27:52 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 3D16621F8F38 for ; Thu, 16 May 2013 04:27:52 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id hn14so4003336wib.2 for ; Thu, 16 May 2013 04:27:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=5n6ED3MdFdtnu3jFmVg08Gmh0CTg4C2TdAg8HbadSEI=; b=zUeMVV4QrckzdtvVlRySCUvPfyz3mRCf4NwSbE4iNE3HbaDW29BAY7JIG/j1JgK1bR D8P7tZGslDck3OmAUEymhxIiR9hA91Tfb6WPt985VEFZJP5YpZuGfnN5hxt6mXduWyPz s6zXYVGxRzMAF9xV97rSRgC/W8Mofw8ffLrLY0sjpj6nowGu+7TWlNeCXy3/pwKvvOMN jV/8ugTNvHXbjxXacw577UYe6qHtDk8yG+drTDhhvJ3jWxM8rOWMGZ1PPLhGzbfNIzDh Y08wvsf3LQyeBwvfNlPj5kP8RgKEp5+gonxgPkqqKV0oLsVvgBHT7pBn0CnpdzbIHIDN 32Jw== X-Received: by 10.181.13.169 with SMTP id ez9mr6809212wid.8.1368703671198; Thu, 16 May 2013 04:27:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.79.138 with HTTP; Thu, 16 May 2013 04:27:31 -0700 (PDT) In-Reply-To: References: <62CCD4C52ACDAD4481149BD5D8A72FD316C3ED09@CH1PRD0510MB355.namprd05.prod.outlook.com> <2FE467D3673DCE409A84D67EC2F607BB0FA778AF@xmb-rcd-x10.cisco.com> From: "Andrew G. Malis" Date: Thu, 16 May 2013 07:27:31 -0400 Message-ID: To: Mach Chen Content-Type: multipart/alternative; boundary=f46d0438eb9f1fe97404dcd42867 Cc: Ross Callon , "mpls-chairs@tools.ietf.org" , "draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 11:27:54 -0000 --f46d0438eb9f1fe97404dcd42867 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Mach, But if you make this change, then you have the opposite problem, because you also have TLVs that don't inherit the sub-TLVs from type 1, so you need some way of saying exactly which sub-TLVs apply to those. And you could easily create new sub-TLVs that don't apply to TLV 1, 16, or 21. A better solution to me is to list the sub-TLVs for TLV 1 just as it is now, and for TLV 21, use the exact same note that's in the table for TLV 16 ("NOTE: all current and future sub-TLVs for Target FEC Stack also apply to this TLV"). In addition, for TLV 21, if there's an RFC that creates a new sub-TLV that is ONLY for TLV 21, in that RFC the instructions for IANA are to create a new sub-TLV (say 26) for TLV 21, and at the same time, allocate sub-TLV 26 of TLV 1 as "Reserved for TLV 21 use, unused for TLV 1". Cheers, Andy On Wed, May 15, 2013 at 11:35 PM, Mach Chen wrote: > Hi Andy,**** > > ** ** > > The current =93TLVs and sub-TLVs=94 structure works very well if specific > sub-TLVs only belong to a single TLV. But with increasing of TLVs and > sub-TLVs, there are more and more TLVs trying to share sub-TLVs defined f= or > other TLV. For example, Type 16 TLV is designed to reuse all existing and > future sub-TLVs defined for Type 1 TLV. Type 21 TLV is also intended to > apply all the existing and future defined sub-TLVs of Type 1 TLV, and at > the same time, it also defines its own dedicated sub-TLVs, it=92s difficu= lt > or even impossible to achieve this with the current =93TLV and sub-TLVs= =94 > allocation rules and policies. Since if one TLV wants to inherit/reuse al= l > sub-TLVs of one TLV, they actually share the same name space, there is no > safe way to define TLV dedicated sub-TLVs. **** > > ** ** > > For example, Type 1 TLV has defined 25 sub-TLVs so far, it will define > more in the future, Type 21 TLV applies these sub-TLVs for itself; then > Type 21 TLV wants to define its own sub-TLV, what code points should be > allocated to the sub-TLV? If allocating 26 to it, then when Type 1 TLV > defines one more new sub-TLV, it will probably be allocated 26 as the cod= e > point, then confliction occurs. And even if you allocate a much bigger > number (e.g., 1000) to the new sub-TLV, in theory, the confliction cannot > be avoided completely. **** > > ** ** > > The required changes proposed in the draft will not impact the > implementation, it just changes the way on how to register a sub-TLV. ***= * > > ** ** > > In addition, the similar definition/usage is not novel, for example, the > Attribute Flag TLV can be carried/shared in/by many Objects, but flags ar= e > defined and register in a common space.**** > > ** ** > > There are a lot of discussions online/offline about the TLV and sub-TLVs > allocations rules and policies on progressing the draft-ietf-mpls > -return-path-specified-lsp-ping, and the draft is still stuck by this > allocation issue. Seems this is the best solution that we could think of = so > far. **** > > ** ** > > Best regards,**** > > Mach**** > > ** ** > > *From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf > Of *Andrew G. Malis > *Sent:* Thursday, May 16, 2013 5:51 AM > *To:* George Swallow (swallow) > *Cc:* Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; > draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org > *Subject:* Re: [mpls] Poll for WG adoption for > draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02**** > > ** ** > > I agree with George from a definition standpoint, I don't find the "TLVs > and sub-TLVs" table at > http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-pa= rameters.xmldifficult to follow at all. However, it would be interesting to= hear from > implementers if they've had any difficulty implementing the TLVs and > sub-TLVs.**** > > But at this point, with existing implementations, I think we need a REALL= Y > GOOD reason to change other than some people find the table confusing, > which seems to be the main justification in the draft.**** > > ** ** > > Also, if the draft is adopted, it would be useful for it to have a link t= o > the IANA page in the references. > > Cheers,**** > > Andy**** > > ** ** > > On Tue, May 14, 2013 at 11:26 AM, George Swallow (swallow) < > swallow@cisco.com> wrote:**** > > With hat off.**** > > ** ** > > No/do not support.**** > > ** ** > > I believe that making a single sub-TLV space is going to lead to a lot of > confusion in the future as to which sub-TLVs are used with which TLVs. > That is one will have to search through bunch of documents instead of > seeing it clearly laid out in the registry. **** > > ** ** > > Keeping the spaces separate for RSVP has worked well. I really don't get > what is preventing that here. **** > > ** ** > > George**** > > ** ** > > *From: *Ross Callon > *Date: *Sunday, May 5, 2013 10:53 PM > *To: *"mpls@ietf.org" , " > draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org" < > draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org> > *Cc: *"mpls-chairs@tools.ietf.org" **** > > > *Subject: *[mpls] Poll for WG adoption for > draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02**** > > ** ** > > Working group,**** > > **** > > this is to start a "two week" poll on adopting**** > > draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02**** > > as an MPLS working group document.**** > > **** > > Please send your comments (support/not support) to the mpls working**** > > group mailing list (mpls@ietf.org).**** > > **** > > This poll will end May 20th, 2013.**** > > **** > > Ross**** > > (as mpls wg co-chair)**** > > **** > > **** > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls**** > > ** ** > --f46d0438eb9f1fe97404dcd42867 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Mach,

But if you make this change, = then you have the opposite problem, because you also have TLVs that don'= ;t inherit the sub-TLVs from type 1, so you need some way of saying exactly= which sub-TLVs apply to those. And you could easily create new sub-TLVs th= at don't apply to TLV 1, 16, or 21.

A better solution to me is to list the sub-TLVs for TLV 1 just as it is= now, and for TLV 21, use the exact same note that's in the table for T= LV 16 ("NOTE: all current and future sub-TLVs for Target FEC Stack als= o apply to this TLV"). In addition, for TLV 21, if there's an RFC = that creates a new sub-TLV that is ONLY for TLV 21, in that RFC the instruc= tions for IANA are to create a new sub-TLV (say 26) for TLV 21, and at the = same time, allocate sub-TLV 26 of TLV 1 as "Reserved for TLV 21 use, u= nused for TLV 1".

Cheers,
Andy


On Wed, May 15, 2013 at 11:35 PM, Mach Chen <mach= .chen@huawei.com> wrote:

Hi Andy,

=A0

The current =93TLVs and sub-TLVs=94 structure works very well if specific sub-TLVs only belong to a single TLV= . But with increasing of TLVs and sub-TLVs, there are more and more TLVs tr= ying to share sub-TLVs defined for other TLV. For example, Type 16 TLV is d= esigned to reuse all existing and future sub-TLVs defined for Type 1 TLV. Type 21 TLV is also intended to ap= ply all the existing and future defined sub-TLVs of Type 1 TLV, and at the = same time, it also defines its own dedicated sub-TLVs, it=92s difficult or = even impossible to achieve this with the current =93TLV and sub-TLVs=94 allocation rules and policies. Since if= one TLV wants to inherit/reuse all sub-TLVs of one TLV, they actually shar= e the same name space, there is no safe way to define TLV dedicated sub-TLV= s.

=A0

For example, Type 1 TLV has defined 25 sub-TLVs so far, it will define more in the future, Type 21 TLV applies= these sub-TLVs for itself; then Type 21 TLV wants to define its own sub-TL= V, what code points should be allocated to the sub-TLV? =A0If allocating 26 to it, then when Type 1 TLV defines one mo= re new sub-TLV, it will probably be allocated 26 as the code point, then co= nfliction occurs. And even if you allocate a much bigger number (e.g., 1000= ) to the new sub-TLV, in theory, the confliction cannot be avoided completely. <= /u>

=A0

The required changes proposed in the draft will not impact the implementation, it just changes the way on h= ow to register a sub-TLV.

=A0

In addition, the similar definition/usage is not novel, for example, the Attribute Flag TLV can be carried/shared in= /by many Objects, but flags are defined and register in a common space.<= /u>

=A0

There are a lot of discussions online/offlin= e about the TLV and sub-TLVs allocations rules and policies on progressing t= he draft-ietf-mpls-return-path-specified-ls= p-ping, =A0and the draft is still stuck by this allocation issue. Seem= s this is the best solution that we could think of so far. =A0

=A0

Best regards,

Mach

=A0

From: mpls-bounces@ie= tf.org [mailto:mpls-bounces@ietf.org] On Behalf= Of Andrew G. Malis
Sent: Thursday, May 16, 2013= 5:51 AM
To: George Swallow (swallow)=
Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org<= /a>; draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-= registry@tools.ietf.org
Subject: Re: [mpls] Poll for= WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02

=A0

I agre= e with George from a definition standpoint, I don't find the "TLVs= and sub-TLVs" table at http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-para= meters.xml difficult to follow at all. However, it would be interesting= to hear from implementers if they've had any difficulty implementing t= he TLVs and sub-TLVs.

But at this point, with existing impl= ementations, I think we need a REALLY GOOD reason to change other than some= people find the table confusing, which seems to be the main justification in the draft.

=A0

Also, if the draft is adopted, it wou= ld be useful for it to have a link to the IANA page in the references.

Cheers,

Andy

=A0

On Tue, May 14, 2013 at 11:26 AM, Geo= rge Swallow (swallow) <swallow@cisco.com> wrote:

With hat off.

=A0

No/do not support.

=A0

I believe that making a single sub-TLV space is going to lead to= a lot of confusion in the future as to which sub-TLVs are used with which TLVs. =A0That is one will have to search through bunch of docum= ents instead of seeing it clearly laid out in the registry. =A0

=A0

Keeping the spaces separate for RSVP has worked well. =A0I reall= y don't get what is preventing that here. =A0

=A0

George

=A0

From: Ross C= allon <rcallon@= juniper.net>
Date: Sunday, May 5, 2013 10= :53 PM
To: "mpls@ietf.org" <mpls@ietf.org>, "draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@too= ls.ietf.org" <draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-= registry@tools.ietf.org>
Cc: "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>

<= br> Subject: [mpls] Poll for WG = adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02

=A0

Working group,

=A0

this is to start a "two week&= quot; poll on adopting

draft-pac-mpls-lsp-ping-tlvs-and-s= ub-tlvs-registry-02

as an MPLS working group document.=

=A0

Please send your comments (support= /not support) to the mpls working

group mailing list (mpls@ietf.org).

=A0

This poll will end May 20th, 2013.=

=A0

Ross

(as mpls wg co-chair)

= =A0

= =A0


_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

=A0


--f46d0438eb9f1fe97404dcd42867-- From ietfc@btconnect.com Thu May 16 04:40:09 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BE7221F8F38 for ; Thu, 16 May 2013 04:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.062 X-Spam-Level: X-Spam-Status: No, score=-3.062 tagged_above=-999 required=5 tests=[AWL=0.537, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gKeHI5+qyJWj for ; Thu, 16 May 2013 04:40:04 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id 261DC21F8F43 for ; Thu, 16 May 2013 04:40:04 -0700 (PDT) Received: from mail16-am1-R.bigfish.com (10.3.201.254) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.23; Thu, 16 May 2013 11:40:03 +0000 Received: from mail16-am1 (localhost [127.0.0.1]) by mail16-am1-R.bigfish.com (Postfix) with ESMTP id 416A24408D4; Thu, 16 May 2013 11:40:03 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.197; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0710HT004.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -16 X-BigFish: PS-16(zz98dI9371I542Iec9I1432Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275bh8275dh8275chz2dh2a8h5a9h668h839h946hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh304l1d11m1155h) Received: from mail16-am1 (localhost.localdomain [127.0.0.1]) by mail16-am1 (MessageSwitch) id 1368704401516832_16982; Thu, 16 May 2013 11:40:01 +0000 (UTC) Received: from AM1EHSMHS002.bigfish.com (unknown [10.3.201.229]) by mail16-am1.bigfish.com (Postfix) with ESMTP id 76E13360119; Thu, 16 May 2013 11:40:01 +0000 (UTC) Received: from DBXPRD0710HT004.eurprd07.prod.outlook.com (157.56.253.197) by AM1EHSMHS002.bigfish.com (10.3.207.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 16 May 2013 11:39:56 +0000 Received: from AMXPRD0111HT004.eurprd01.prod.exchangelabs.com (157.56.250.117) by pod51017.outlook.com (10.255.79.167) with Microsoft SMTP Server (TLS) id 14.16.311.1; Thu, 16 May 2013 11:39:47 +0000 Message-ID: <002901ce5229$511090e0$4001a8c0@gateway.2wire.net> From: t.petch To: "Andrew G. Malis" , Mach Chen References: <62CCD4C52ACDAD4481149BD5D8A72FD316C3ED09@CH1PRD0510MB355.namprd05.prod.outlook.com><2FE467D3673DCE409A84D67EC2F607BB0FA778AF@xmb-rcd-x10.cisco.com> Date: Thu, 16 May 2013 12:34:16 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.250.117] X-FOPE-CRA-Verdict: 157.56.253.197$juniper.net%12218%4%btconnect.com%False%False%0$ Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: btconnect.com Cc: Ross Callon , mpls@ietf.org, mpls-chairs@tools.ietf.org, draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org Subject: Re: [mpls] Poll for WG adoption fordraft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 11:40:09 -0000 ----- Original Message ----- From: "Andrew G. Malis" To: "Mach Chen" Cc: "Ross Callon" ; ; ; Sent: Thursday, May 16, 2013 12:27 PM Mach, But if you make this change, then you have the opposite problem, because you also have TLVs that don't inherit the sub-TLVs from type 1, so you need some way of saying exactly which sub-TLVs apply to those. And you could easily create new sub-TLVs that don't apply to TLV 1, 16, or 21. Andrew I don't see it; any RFC defining a TLV says which sub-TLVs apply. That is true now, and will be true in future if the approach in this I-D is adopted. What changes is that there is a unique, unambiguous way of referring to any sub-TLV anywhere; 33 will mean 33, and not the 33 that is defined under that TLV as opposed to the 33 that is defined under this or the other TLV. The history of the past two years is of the writers of some I-Ds getting this wrong (because it is complex, not obvious or whatever) - the aim is this I-D is to make simple enough for people not to get wrong. Tom Petch A better solution to me is to list the sub-TLVs for TLV 1 just as it is now, and for TLV 21, use the exact same note that's in the table for TLV 16 ("NOTE: all current and future sub-TLVs for Target FEC Stack also apply to this TLV"). In addition, for TLV 21, if there's an RFC that creates a new sub-TLV that is ONLY for TLV 21, in that RFC the instructions for IANA are to create a new sub-TLV (say 26) for TLV 21, and at the same time, allocate sub-TLV 26 of TLV 1 as "Reserved for TLV 21 use, unused for TLV 1". Cheers, Andy On Wed, May 15, 2013 at 11:35 PM, Mach Chen wrote: > Hi Andy,**** > > ** ** > > The current =93TLVs and sub-TLVs=94 structure works very well if specif= ic > sub-TLVs only belong to a single TLV. But with increasing of TLVs and > sub-TLVs, there are more and more TLVs trying to share sub-TLVs defined for > other TLV. For example, Type 16 TLV is designed to reuse all existing and > future sub-TLVs defined for Type 1 TLV. Type 21 TLV is also intended to > apply all the existing and future defined sub-TLVs of Type 1 TLV, and at > the same time, it also defines its own dedicated sub-TLVs, it=92s difficult > or even impossible to achieve this with the current =93TLV and sub-TLVs= =94 > allocation rules and policies. Since if one TLV wants to inherit/reuse all > sub-TLVs of one TLV, they actually share the same name space, there is no > safe way to define TLV dedicated sub-TLVs. **** > > ** ** > > For example, Type 1 TLV has defined 25 sub-TLVs so far, it will define > more in the future, Type 21 TLV applies these sub-TLVs for itself; then > Type 21 TLV wants to define its own sub-TLV, what code points should be > allocated to the sub-TLV? If allocating 26 to it, then when Type 1 TLV > defines one more new sub-TLV, it will probably be allocated 26 as the code > point, then confliction occurs. And even if you allocate a much bigger > number (e.g., 1000) to the new sub-TLV, in theory, the confliction cannot > be avoided completely. **** > > ** ** > > The required changes proposed in the draft will not impact the > implementation, it just changes the way on how to register a sub-TLV. **** > > ** ** > > In addition, the similar definition/usage is not novel, for example, the > Attribute Flag TLV can be carried/shared in/by many Objects, but flags are > defined and register in a common space.**** > > ** ** > > There are a lot of discussions online/offline about the TLV and sub-TLVs > allocations rules and policies on progressing the draft-ietf-mpls > -return-path-specified-lsp-ping, and the draft is still stuck by this > allocation issue. Seems this is the best solution that we could think of so > far. **** > > ** ** > > Best regards,**** > > Mach**** > > ** ** > > *From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On Behalf > Of *Andrew G. Malis > *Sent:* Thursday, May 16, 2013 5:51 AM > *To:* George Swallow (swallow) > *Cc:* Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; > draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org > *Subject:* Re: [mpls] Poll for WG adoption for > draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02**** > > ** ** > > I agree with George from a definition standpoint, I don't find the "TLVs > and sub-TLVs" table at > http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-p arameters.xmldifficult to follow at all. However, it would be interesting to hear from > implementers if they've had any difficulty implementing the TLVs and > sub-TLVs.**** > > But at this point, with existing implementations, I think we need a REALLY > GOOD reason to change other than some people find the table confusing, > which seems to be the main justification in the draft.**** > > ** ** > > Also, if the draft is adopted, it would be useful for it to have a link to > the IANA page in the references. > > Cheers,**** > > Andy**** > > ** ** > > On Tue, May 14, 2013 at 11:26 AM, George Swallow (swallow) < > swallow@cisco.com> wrote:**** > > With hat off.**** > > ** ** > > No/do not support.**** > > ** ** > > I believe that making a single sub-TLV space is going to lead to a lot of > confusion in the future as to which sub-TLVs are used with which TLVs. > That is one will have to search through bunch of documents instead of > seeing it clearly laid out in the registry. **** > > ** ** > > Keeping the spaces separate for RSVP has worked well. I really don't get > what is preventing that here. **** > > ** ** > > George**** > > ** ** > > *From: *Ross Callon > *Date: *Sunday, May 5, 2013 10:53 PM > *To: *"mpls@ietf.org" , " > draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org" < > draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org> > *Cc: *"mpls-chairs@tools.ietf.org" **** > > > *Subject: *[mpls] Poll for WG adoption for > draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02**** > > ** ** > > Working group,**** > > **** > > this is to start a "two week" poll on adopting**** > > draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02**** > > as an MPLS working group document.**** > > **** > > Please send your comments (support/not support) to the mpls working**** > > group mailing list (mpls@ietf.org).**** > > **** > > This poll will end May 20th, 2013.**** > > **** > > Ross**** > > (as mpls wg co-chair)**** > > **** > > **** > > > _______________________________________________ > 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 pabloisnot@gmail.com Thu May 16 08:13:28 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0213021F85D1 for ; Thu, 16 May 2013 08:13:28 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jFORy3gPbuX for ; Thu, 16 May 2013 08:13:26 -0700 (PDT) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [IPv6:2607:f8b0:400c:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id CD46D21F8517 for ; Thu, 16 May 2013 08:13:25 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id jz10so1930210veb.7 for ; Thu, 16 May 2013 08:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=rApio4pC91uXBr/wVk2f2rWef2h5KpeZduG+8m6Ydjw=; b=eG5mlmTRNM9unuWgocIi1LoYg5lHAGHUG8M7s/jzq4Xpr/9+Jt5JgP/rKMQf0wkXFq kQRtwBETsv6ixfNJs/V9usu8rvQ2bYG6w5yJyzLHO/79F2TukO88yDX27U8T7pgJC9/7 C2zawTwt5kjZLE5A/TQ5yYZGH+VjNY+Pfcol6kcHq2fPDKwq692rBrYSa5hU8n8RdWAs E6Dj2EPb9rWoivehDu2mj19cImTx+HIJpZk956ot4ZxZRZL4W8atUsRPTnFxqjY4ebLA uIPK5xNYMZE0h3/Jns3iCkik+zcsaPcqxzRlYf0HPKx/Y6oSTkgtcCR6mv1541CxPpUL necw== MIME-Version: 1.0 X-Received: by 10.52.75.71 with SMTP id a7mr24034602vdw.104.1368717203538; Thu, 16 May 2013 08:13:23 -0700 (PDT) Received: by 10.52.114.9 with HTTP; Thu, 16 May 2013 08:13:23 -0700 (PDT) In-Reply-To: <002a01ce4b45$82e38ae0$88aaa0a0$@olddog.co.uk> References: <002a01ce4b45$82e38ae0$88aaa0a0$@olddog.co.uk> Date: Thu, 16 May 2013 11:13:23 -0400 Message-ID: From: Pablo Frank To: adrian@olddog.co.uk Content-Type: multipart/alternative; boundary=20cf3071cf7eb7075204dcd74e83 Cc: "mpls@ietf.org" Subject: Re: [mpls] Retiring ACH TLVs X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 15:13:28 -0000 --20cf3071cf7eb7075204dcd74e83 Content-Type: text/plain; charset=ISO-8859-1 Please, please do this. thanks, Pablo On Tue, May 7, 2013 at 1:08 PM, Adrian Farrel wrote: > Hi, > > ACH TLVs keep popping up and causing Stewart and me trouble. Mainly it is > about explaining why no-one actually wants to use them (i.e., when each new > ACH Type is defined and has a "No TLVs" written for it, we get asked "why > not?"). > > It seems to us that ACH TLVs are an idea that has been rejected. Initially > we thought they might be used (especially for identifiers), but there seems > to be good opinion that handling generic TLVs would be a pain. > > Since I was heavily responsible for insisting that ACH TLVs were included > in RFC 5586, it seems reasonable that I do the work to fix it. > > The I-D below retires ACH TLVs and handles the necessary registry changes. > > Note, of course, that structured data are still possible within individual > ACHs if the protocol spec for an individual ACH decides to have them. > > We're directing this work to the MPLS working group because that is where > 5586 was written. I have BCC'ed PWE3, L2VPN, and BFD for information. > > Thanks for any comments. > > As humble WG contributors we would be enthusiastic to see early WG > adoption and last call :-) > > Thanks, > Adrian > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: 07 May 2013 17:33 > > To: Adrian Farrel; Stewart Bryant > > Subject: New Version Notification for > draft-farbryantrel-mpls-retire-ach-tlv- > > 00.txt > > > > > > A new version of I-D, draft-farbryantrel-mpls-retire-ach-tlv-00.txt > > has been successfully submitted by Adrian Farrel and posted to the > > IETF repository. > > > > Filename: draft-farbryantrel-mpls-retire-ach-tlv > > Revision: 00 > > Title: Retiring TLVs from the Associated Channel Header > of the MPLS > > Generic Associated Channel > > Creation date: 2013-05-07 > > Group: Individual Submission > > Number of pages: 4 > > URL: > http://www.ietf.org/internet-drafts/draft-farbryantrel-mpls-retire- > > ach-tlv-00.txt > > Status: > http://datatracker.ietf.org/doc/draft-farbryantrel-mpls-retire-ach-tlv > > Htmlized: > http://tools.ietf.org/html/draft-farbryantrel-mpls-retire-ach-tlv-00 > > > > > > Abstract: > > The MPLS Generic Associated Channel (G-ACh) is a generalization of > > the applicability of the Pseudowire (PW) Associated Channel Header > > (ACH). RFC 5586 defines the concept of Type-Length-Variable (TLV) > > constructs that can be carried in messages on the G-ACh by placing > > them in the ACH. > > > > No Associated Channel Type yet defined uses a TLV. Furthermore, it > > is believed that handling TLVs in hardware introduces significant > > problems to the fast-path, and since G-ACh messages are intended to > > be processed substantially in hardware, the use of TLVs in > > undesirable. > > > > This document updates RFC 5586 by retiring ACH TLVs and removing the > > associated registry. > > > > > > > > > > The IETF Secretariat > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --20cf3071cf7eb7075204dcd74e83 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Please, please do this.

thanks,
Pablo


O= n Tue, May 7, 2013 at 1:08 PM, Adrian Farrel <adrian@olddog.co.uk&g= t; wrote:
Hi,

ACH TLVs keep popping up and causing Stewart and me trouble. Mainly it is a= bout explaining why no-one actually wants to use them (i.e., when each new = ACH Type is defined and has a "No TLVs" written for it, we get as= ked "why not?").

It seems to us that ACH TLVs are an idea that has been rejected. Initially = we thought they might be used (especially for identifiers), but there seems= to be good opinion that handling generic TLVs would be a pain.

Since I was heavily responsible for insisting that ACH TLVs were included i= n RFC 5586, it seems reasonable that I do the work to fix it.

The I-D below retires ACH TLVs and handles the necessary registry changes.<= br>
Note, of course, that structured data are still possible within individual = ACHs if the protocol spec for an individual ACH decides to have them.

We're directing this work to the MPLS working group because that is whe= re 5586 was written. I have BCC'ed PWE3, L2VPN, and BFD for information= .

Thanks for any comments.

As humble WG contributors we would be enthusiastic to see early WG adoption= and last call :-)

Thanks,
Adrian

> -----Original Message-----
> From: internet-drafts@ietf= .org [mailto:internet-draft= s@ietf.org]
> Sent: 07 May 2013 17:33
> To: Adrian Farrel; Stewart Bryant
> Subject: New Version Notification for draft-farbryantrel-mpls-retire-a= ch-tlv-
> 00.txt
>
>
> A new version of I-D, draft-farbryantrel-mpls-retire-ach-tlv-00.txt > has been successfully submitted by Adrian Farrel and posted to the
> IETF repository.
>
> Filename: =A0 =A0 =A0draft-farbryantrel-mpls-retire-ach-tlv
> Revision: =A0 =A0 =A000
> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Retiring TLVs from the Associat= ed Channel Header of the MPLS
> Generic Associated Channel
> Creation date: =A0 =A0 =A0 =A0 2013-05-07
> Group: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Individual Submission
> Number of pages: 4
> URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.or= g/internet-drafts/draft-farbryantrel-mpls-retire-
> ach-tlv-00.txt
> Status: =A0 =A0 =A0 =A0 =A0http://datatracke= r.ietf.org/doc/draft-farbryantrel-mpls-retire-ach-tlv
> Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org= /html/draft-farbryantrel-mpls-retire-ach-tlv-00
>
>
> Abstract:
> =A0 =A0The MPLS Generic Associated Channel (G-ACh) is a generalization= of
> =A0 =A0the applicability of the Pseudowire (PW) Associated Channel Hea= der
> =A0 =A0(ACH). =A0RFC 5586 defines the concept of Type-Length-Variable = (TLV)
> =A0 =A0constructs that can be carried in messages on the G-ACh by plac= ing
> =A0 =A0them in the ACH.
>
> =A0 =A0No Associated Channel Type yet defined uses a TLV. =A0Furthermo= re, it
> =A0 =A0is believed that handling TLVs in hardware introduces significa= nt
> =A0 =A0problems to the fast-path, and since G-ACh messages are intende= d to
> =A0 =A0be processed substantially in hardware, the use of TLVs in
> =A0 =A0undesirable.
>
> =A0 =A0This document updates RFC 5586 by retiring ACH TLVs and removin= g the
> =A0 =A0associated registry.
>
>
>
>
> The IETF Secretariat

_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--20cf3071cf7eb7075204dcd74e83-- From yaakov_s@rad.com Thu May 16 09:14:05 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85FF321F91CB for ; Thu, 16 May 2013 09:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VU5DqXGVqRz7 for ; Thu, 16 May 2013 09:14:00 -0700 (PDT) Received: from rad.co.il (mailrelay01.rad.co.il [62.0.23.252]) by ietfa.amsl.com (Postfix) with ESMTP id CD29921F8F41 for ; Thu, 16 May 2013 09:13:57 -0700 (PDT) Received: from Internal Mail-Server by MailRelay01 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 16 May 2013 19:08:45 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.02.0298.004; Thu, 16 May 2013 19:13:53 +0300 From: Yaakov Stein To: "adrian@olddog.co.uk" , "mpls@ietf.org" Thread-Topic: [mpls] Retiring ACH TLVs Thread-Index: Ac5LRX560irUVDlgRIKUWSY/7OcnkAHCaQig Date: Thu, 16 May 2013 16:13:52 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC904D3032A@EXRAD5.ad.rad.co.il> References: <002a01ce4b45$82e38ae0$88aaa0a0$@olddog.co.uk> In-Reply-To: <002a01ce4b45$82e38ae0$88aaa0a0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.115.243.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A0C0204.519505C1.016F,ss=1,fgs=0 Subject: Re: [mpls] Retiring ACH TLVs X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 16:14:05 -0000 Actually, I hadn't noticed that the registry was under Pseudowire Name Spac= es, which is silly, since TLVs were never defined for the PW ACh. (The ACh types is different, since at least some of these are used for VCCV= .) If there is no use for them, then let's deprecate. However, I believe that options for the signalling and management channels = of RFC 5718 have never been spelled out. Are we sure that these will not need some sta= ndard modifiers/parameters ? Y(J)S -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Adr= ian Farrel Sent: 07 May, 2013 20:09 To: mpls@ietf.org Subject: [mpls] Retiring ACH TLVs Hi, ACH TLVs keep popping up and causing Stewart and me trouble. Mainly it is a= bout explaining why no-one actually wants to use them (i.e., when each new = ACH Type is defined and has a "No TLVs" written for it, we get asked "why n= ot?"). It seems to us that ACH TLVs are an idea that has been rejected. Initially = we thought they might be used (especially for identifiers), but there seems= to be good opinion that handling generic TLVs would be a pain. Since I was heavily responsible for insisting that ACH TLVs were included i= n RFC 5586, it seems reasonable that I do the work to fix it. The I-D below retires ACH TLVs and handles the necessary registry changes. Note, of course, that structured data are still possible within individual = ACHs if the protocol spec for an individual ACH decides to have them. We're directing this work to the MPLS working group because that is where 5= 586 was written. I have BCC'ed PWE3, L2VPN, and BFD for information.=20 Thanks for any comments. As humble WG contributors we would be enthusiastic to see early WG adoption= and last call :-) Thanks, Adrian > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: 07 May 2013 17:33 > To: Adrian Farrel; Stewart Bryant > Subject: New Version Notification for draft-farbryantrel-mpls-retire-ach-= tlv- > 00.txt >=20 >=20 > A new version of I-D, draft-farbryantrel-mpls-retire-ach-tlv-00.txt > has been successfully submitted by Adrian Farrel and posted to the > IETF repository. >=20 > Filename: draft-farbryantrel-mpls-retire-ach-tlv > Revision: 00 > Title: Retiring TLVs from the Associated Channel Header of the MPLS > Generic Associated Channel > Creation date: 2013-05-07 > Group: Individual Submission > Number of pages: 4 > URL: http://www.ietf.org/internet-drafts/draft-farbryantrel-m= pls-retire- > ach-tlv-00.txt > Status: http://datatracker.ietf.org/doc/draft-farbryantrel-mpls-= retire-ach-tlv > Htmlized: http://tools.ietf.org/html/draft-farbryantrel-mpls-retir= e-ach-tlv-00 >=20 >=20 > Abstract: > The MPLS Generic Associated Channel (G-ACh) is a generalization of > the applicability of the Pseudowire (PW) Associated Channel Header > (ACH). RFC 5586 defines the concept of Type-Length-Variable (TLV) > constructs that can be carried in messages on the G-ACh by placing > them in the ACH. >=20 > No Associated Channel Type yet defined uses a TLV. Furthermore, it > is believed that handling TLVs in hardware introduces significant > problems to the fast-path, and since G-ACh messages are intended to > be processed substantially in hardware, the use of TLVs in > undesirable. >=20 > This document updates RFC 5586 by retiring ACH TLVs and removing the > associated registry. >=20 >=20 >=20 >=20 > The IETF Secretariat _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From cpignata@cisco.com Thu May 16 09:21:07 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C63921F91CB for ; Thu, 16 May 2013 09:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0nJp1YOqhYC for ; Thu, 16 May 2013 09:21:02 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 77AE421F901B for ; Thu, 16 May 2013 09:21:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6595; q=dns/txt; s=iport; t=1368721262; x=1369930862; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=J7zWMpwnx1aRaVvUl/wCFlTPZ3woSMwEJJfGWEMERuw=; b=DfDMw3Q5tDHSpveSbiFgrTEIgg94ltPi0qiE5iPXdTYP/64kAenwiIfV ZfQXasfm3DGMc3K/2xxsxXg8bzE2i4Y/Momz7yMdfgUkBoyRQou1NOPIm c0UHoq+C/RURZjXD+FijqkflQgyewjJ8K513deIFrJb4YzPqlP1P/FjDG 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAC4GlVGtJV2c/2dsb2JhbABbgkNEN4YduUWBZX0WdIIgAQEEAQEBawsQAgEIDhQdBycLFBEBAQQOBQgBiAMMvQaObi0EB4J0YQOoeIE0JIE4giY X-IronPort-AV: E=Sophos;i="4.87,684,1363132800"; d="scan'208,217";a="211324259" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 16 May 2013 16:21:01 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r4GGL1W9021852 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 May 2013 16:21:01 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Thu, 16 May 2013 11:21:01 -0500 From: "Carlos Pignataro (cpignata)" To: Ross Callon Thread-Topic: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 Thread-Index: Ac5KBNrRqy5GgTuxR1iRJSatXBuqdwIdmhAA Date: Thu, 16 May 2013 16:21:00 +0000 Message-ID: <95067C434CE250468B77282634C96ED322B582FB@xmb-aln-x02.cisco.com> References: <62CCD4C52ACDAD4481149BD5D8A72FD316C3ED09@CH1PRD0510MB355.namprd05.prod.outlook.com> In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316C3ED09@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.157.229] Content-Type: multipart/alternative; boundary="_000_95067C434CE250468B77282634C96ED322B582FBxmbalnx02ciscoc_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org" Subject: Re: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 16:21:07 -0000 --_000_95067C434CE250468B77282634C96ED322B582FBxmbalnx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I do not support adoption of this document. I believe that coalescing the sub-TLVs into a single space is harmful on a = number of areas; here's some of the main implications: * Bugs about applicability of sub-TLVs -- all of a sudden there would b= e no clarity as to what sub-TLVs are applicable -- or not -- to each TLV. * Context lost -- the context of a sub-TLV is, by definition, subordina= te to the TLV. This is in meaning, and presence. * It already cannot work -- because the TLV Type 9 already has specific= definition for its use of sub-TLVs, it would not be a single space; it wou= ld start with exceptions already. * Backwards compatibility -- existing implementations that follow RFC 4= 379 treat sub-TLVs as subordinates such that the "meaning of a sub-TLV is s= coped by the TLV". This creates parsing bugs. * The concept of subordinate spaces has worked for LSP Ping as well as = for many protocols, all the way to ICMP types and codes http://www.iana.org= /assignments/icmp-parameters/icmp-parameters.xml If there is a need to synchronize the sub-TLVs of two or more specific TLVs= , that can be codified without changing the whole structure of the registry= (for example, by saying "TLV-foo uses the same sub-TLVs from TLV-bar). Fra= nkly, http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-pin= g-parameters.xml#mpls-lsp-ping-parameters-7 seems pretty clear to me. I wou= ld not let the corner case dictate the overall structure. Thanks, -- Carlos. On May 5, 2013, at 10:53 PM, Ross Callon > wrote: Working group, this is to start a "two week" poll on adopting draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end May 20th, 2013. Ross (as mpls wg co-chair) _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_95067C434CE250468B77282634C96ED322B582FBxmbalnx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <2535D6DAAAD4764A81FCD1BD7D533276@emea.cisco.com> Content-Transfer-Encoding: quoted-printable I do not support adoption of this document.

I believe that coalescing the sub-TLVs into a single space is harmful = on a number of areas; here's some of the main implications:
  • Bugs about applicability of sub-TLVs -- all of a sudden there would be = no clarity as to what sub-TLVs are applicable -- or not -- to each TLV.
  • Context lost -- the context of a sub-TLV is, by definition, subordinat= e to the TLV. This is in meaning, and presence.
  • It already cannot w= ork -- because the TLV Type 9 already has specific definition for its use o= f sub-TLVs, it would not be a single space; it would start with exceptions = already.
  • Backwards compatibility -- existing implementations that f= ollow RFC 4379 treat sub-TLVs as subordinates such that the "meaning o= f a sub-TLV is scoped by the TLV". This creates parsing bugs.
  • = The concept of subordinate spaces has worked for LSP Ping as well as for ma= ny protocols, all the way to ICMP types and codes http://www.iana= .org/assignments/icmp-parameters/icmp-parameters.xml

If there is a need to synchronize the sub-TLVs of two or more specific= TLVs, that can be codified without changing the whole structure of the reg= istry (for example, by saying "TLV-foo uses the same sub-TLVs from TLV= -bar). Frankly, http= ://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-paramete= rs.xml#mpls-lsp-ping-parameters-7 seems pretty clear to me. I would not let the corner case dictate the over= all structure.

Thanks,

-- Carlos.

On May 5, 2013, at 10:53 PM, Ross Callon <rcallon@juniper.net> wrote:

Working group,
 
this is to start a "two week" poll on adopting
draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02
as an MPLS working group document.
 
Please send your comments (support/not support) to the mpls working
group mailing list (mpls@ietf.org).
 
This poll will end May 20th, 2013.
 
Ross
(as mpls wg co-chair)
&n= bsp;
&n= bsp;
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org= /mailman/listinfo/mpls

--_000_95067C434CE250468B77282634C96ED322B582FBxmbalnx02ciscoc_-- From cpignata@cisco.com Thu May 16 09:39:00 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E598211E810C for ; Thu, 16 May 2013 09:39:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFLrWZqDiLqk for ; Thu, 16 May 2013 09:38:56 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0A011E8106 for ; Thu, 16 May 2013 09:38:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9711; q=dns/txt; s=iport; t=1368722334; x=1369931934; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=p+qJEIo2WkEExi/v84cCQMlXcKfsGG32eRurIcPKA20=; b=INlDY6tE8JTEBJUoNyPZ1EoPpZC7rVGxCKu4X9B8v7U1OxU5IMIO6TP9 7ePPAgLXZ+UyI98jRW8VIhlMG+HbXHVElCFG8AYAtlcjl2IelqjHCKjgf yjAlfTa+HKb8uMW1R5QQqE/I5O7Xj3olSeAOBNCzPLN9TqP8898Y/7vF5 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFANsKlVGtJV2Y/2dsb2JhbABbgwc3wUl9FnSCHwEBAQMBAQEBZAcLBQcEAgEIEQMBAQEBCh0HIQYLFAkIAgQOBQgBEodfAwkGDLQhDYhhjEiCJAIxBwaCbmEDlVKOA4UjgViBOIIm X-IronPort-AV: E=Sophos;i="4.87,684,1363132800"; d="scan'208";a="208389182" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP; 16 May 2013 16:38:53 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r4GGcrxH017159 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 16 May 2013 16:38:53 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Thu, 16 May 2013 11:38:53 -0500 From: "Carlos Pignataro (cpignata)" To: "t.petch" Thread-Topic: [mpls] Poll for WG adoption fordraft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 Thread-Index: AQHOUiooEWGww7Nyq0m5SRwwfoMKpZkIVy8A Date: Thu, 16 May 2013 16:38:52 +0000 Message-ID: <95067C434CE250468B77282634C96ED322B58488@xmb-aln-x02.cisco.com> References: <62CCD4C52ACDAD4481149BD5D8A72FD316C3ED09@CH1PRD0510MB355.namprd05.prod.outlook.com><2FE467D3673DCE409A84D67EC2F607BB0FA778AF@xmb-rcd-x10.cisco.com> <002901ce5229$511090e0$4001a8c0@gateway.2wire.net> In-Reply-To: <002901ce5229$511090e0$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.102.157.229] Content-Type: text/plain; charset="Windows-1252" Content-ID: <4B611C637743B844AF2A8168DD3B5B2C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , Ross Callon , "" , "" Subject: Re: [mpls] Poll for WG adoption fordraft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 16:39:01 -0000 Tom, Mach, Please see inline. On May 16, 2013, at 7:34 AM, t.petch wrote: > ----- Original Message ----- > From: "Andrew G. Malis" > To: "Mach Chen" > Cc: "Ross Callon" ; ; > ; > > Sent: Thursday, May 16, 2013 12:27 PM >=20 > Mach, >=20 > But if you make this change, then you have the opposite problem, because > you also have TLVs that don't inherit the sub-TLVs from type 1, so you > need > some way of saying exactly which sub-TLVs apply to those. And you could > easily create new sub-TLVs that don't apply to TLV 1, 16, or 21. >=20 > > Andrew >=20 > I don't see it; any RFC defining a TLV says which sub-TLVs apply. >=20 > That is true now, and will be true in future if the approach in this I-D > is adopted. >=20 > What changes is that there is a unique, unambiguous way of referring to > any sub-TLV anywhere; 33 will mean 33, and not the 33 that is defined > under that TLV as opposed to the 33 that is defined under this or the > other TLV. But that would not be a feature. By definition, sub-TLVs are scoped within = each TLV. And the parsing of this sub-TLV is, again, within the context of = the TLV. A sub-TLV under TLV Type 9 means something different than under TL= V Type 1 -- today. One of the pragmatic consequences of this is that, unless IANA maintains an= impractical 64k x 64k matrix of TLV vs. sub-TLV applicability, an implemen= tor would have to go through all those RFCs to see what applies to what.=20 For example, if TLV1 has sub-TLVs 10-12 that apply to it, and TLV2 has sub-= TLVs 14-18 that apply to it, but neither sub-TLV applies to the other TLV (= the common case), how do you codify that in an IANA registry? And in an imp= lementaiton? >=20 > The history of the past two years is of the writers of some I-Ds getting > this wrong (because it is complex, not obvious or whatever) - the aim is > this I-D is to make simple enough for people not to get wrong. >=20 It is not clear to me what problem is being solved. You could define a "Glo= bal sub-TLV" TLV if you want to include some sub-TLV in a message with appl= icability regardless of what other TLV is presence. RFC 4379 is fairly unambiguous: The IANA has created and will maintain a registry for the Type field of top-level TLVs as well as for any associated sub-TLVs. Note the meaning of a sub-TLV is scoped by the TLV. Mach, please see below. > Tom Petch >=20 > A better solution to me is to list the sub-TLVs for TLV 1 just as it is > now, and for TLV 21, use the exact same note that's in the table for TLV > 16 > ("NOTE: all current and future sub-TLVs for Target FEC Stack also apply > to > this TLV"). In addition, for TLV 21, if there's an RFC that creates a > new > sub-TLV that is ONLY for TLV 21, in that RFC the instructions for IANA > are > to create a new sub-TLV (say 26) for TLV 21, and at the same time, > allocate > sub-TLV 26 of TLV 1 as "Reserved for TLV 21 use, unused for TLV 1". >=20 > Cheers, > Andy >=20 >=20 > On Wed, May 15, 2013 at 11:35 PM, Mach Chen > wrote: >=20 >> Hi Andy,**** >>=20 >> ** ** >>=20 >> The current =93TLVs and sub-TLVs=94 structure works very well if specifi= c >> sub-TLVs only belong to a single TLV. But with increasing of TLVs and >> sub-TLVs, there are more and more TLVs trying to share sub-TLVs > defined for >> other TLV. For example, Type 16 TLV is designed to reuse all existing > and >> future sub-TLVs defined for Type 1 TLV. Type 21 TLV is also intended > to >> apply all the existing and future defined sub-TLVs of Type 1 TLV, and > at >> the same time, it also defines its own dedicated sub-TLVs, it=92s > difficult >> or even impossible to achieve this with the current =93TLV and sub-TLVs= =94 >> allocation rules and policies. Since if one TLV wants to inherit/reuse > all >> sub-TLVs of one TLV, they actually share the same name space, there is > no >> safe way to define TLV dedicated sub-TLVs. **** >>=20 >> ** ** >>=20 >> For example, Type 1 TLV has defined 25 sub-TLVs so far, it will define >> more in the future, Type 21 TLV applies these sub-TLVs for itself; > then >> Type 21 TLV wants to define its own sub-TLV, what code points should > be >> allocated to the sub-TLV? If allocating 26 to it, then when Type 1 > TLV >> defines one more new sub-TLV, it will probably be allocated 26 as the > code >> point, then confliction occurs. And even if you allocate a much bigger >> number (e.g., 1000) to the new sub-TLV, in theory, the confliction > cannot >> be avoided completely. **** >>=20 The current proposal does not solve this problem either. If Type 21 wants t= o allocate a sub-TLV that it applies to it but not to Type 1, how do you re= cord that with a global sub-TLV space? >> ** ** >>=20 >> The required changes proposed in the draft will not impact the >> implementation, it just changes the way on how to register a sub-TLV. > **** >>=20 >> ** ** >>=20 >> In addition, the similar definition/usage is not novel, for example, > the >> Attribute Flag TLV can be carried/shared in/by many Objects, but flags > are >> defined and register in a common space.**** >>=20 >> ** ** >>=20 >> There are a lot of discussions online/offline about the TLV and > sub-TLVs >> allocations rules and policies on progressing the draft-ietf-mpls >> -return-path-specified-lsp-ping, and the draft is still stuck by this >> allocation issue. Seems this is the best solution that we could think > of so >> far. **** >>=20 Have you considered these? 1. Have TLV 21 be an "I follow TLV 1" definition. 2. Have new sub-TLVs added to 1. 3. If you need sub-TLVs that do not apply to both TLV 1 and TLV21, then def= ine a new TLV. Thanks, -- Carlos. >> ** ** >>=20 >> Best regards,**** >>=20 >> Mach**** >>=20 >> ** ** >>=20 >> *From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On > Behalf >> Of *Andrew G. Malis >> *Sent:* Thursday, May 16, 2013 5:51 AM >> *To:* George Swallow (swallow) >> *Cc:* Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; >> draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org >> *Subject:* Re: [mpls] Poll for WG adoption for >> draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02**** >>=20 >> ** ** >>=20 >> I agree with George from a definition standpoint, I don't find the > "TLVs >> and sub-TLVs" table at >>=20 > http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-p > arameters.xmldifficult to follow at all. However, it would be > interesting to hear from >> implementers if they've had any difficulty implementing the TLVs and >> sub-TLVs.**** >>=20 >> But at this point, with existing implementations, I think we need a > REALLY >> GOOD reason to change other than some people find the table confusing, >> which seems to be the main justification in the draft.**** >>=20 >> ** ** >>=20 >> Also, if the draft is adopted, it would be useful for it to have a > link to >> the IANA page in the references. >>=20 >> Cheers,**** >>=20 >> Andy**** >>=20 >> ** ** >>=20 >> On Tue, May 14, 2013 at 11:26 AM, George Swallow (swallow) < >> swallow@cisco.com> wrote:**** >>=20 >> With hat off.**** >>=20 >> ** ** >>=20 >> No/do not support.**** >>=20 >> ** ** >>=20 >> I believe that making a single sub-TLV space is going to lead to a lot > of >> confusion in the future as to which sub-TLVs are used with which TLVs. >> That is one will have to search through bunch of documents instead of >> seeing it clearly laid out in the registry. **** >>=20 >> ** ** >>=20 >> Keeping the spaces separate for RSVP has worked well. I really don't > get >> what is preventing that here. **** >>=20 >> ** ** >>=20 >> George**** >>=20 >> ** ** >>=20 >> *From: *Ross Callon >> *Date: *Sunday, May 5, 2013 10:53 PM >> *To: *"mpls@ietf.org" , " >> draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org" < >> draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org> >> *Cc: *"mpls-chairs@tools.ietf.org" **** >>=20 >>=20 >> *Subject: *[mpls] Poll for WG adoption for >> draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02**** >>=20 >> ** ** >>=20 >> Working group,**** >>=20 >> **** >>=20 >> this is to start a "two week" poll on adopting**** >>=20 >> draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02**** >>=20 >> as an MPLS working group document.**** >>=20 >> **** >>=20 >> Please send your comments (support/not support) to the mpls > working**** >>=20 >> group mailing list (mpls@ietf.org).**** >>=20 >> **** >>=20 >> This poll will end May 20th, 2013.**** >>=20 >> **** >>=20 >> Ross**** >>=20 >> (as mpls wg co-chair)**** >>=20 >> **** >>=20 >> **** >>=20 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls**** >>=20 >> ** ** >>=20 >=20 >=20 >=20 > ------------------------------------------------------------------------ > -------- >=20 >=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >>=20 >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls >=20 From loa@pi.nu Thu May 16 10:49:27 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B94411E812D for ; Thu, 16 May 2013 10:49:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.948 X-Spam-Level: X-Spam-Status: No, score=-100.948 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8M7ZEJV4ey4R for ; Thu, 16 May 2013 10:49:21 -0700 (PDT) Received: from pipi.pi.nu (unknown [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 7557A11E812C for ; Thu, 16 May 2013 10:49:10 -0700 (PDT) Received: from [192.168.1.130] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id D05D31800272; Thu, 16 May 2013 19:49:08 +0200 (CEST) Message-ID: <51951C17.8010906@pi.nu> Date: Thu, 16 May 2013 19:49:11 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-jjb-mpls-rsvp-te-hsmp-lsp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: [mpls] poll to see if we have consensus to make draft-jjb-mpls-rsvp-te-hsmp-lsp an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 17:49:27 -0000 Working Group, This is to start a two week poll on adopting draft-jjb-mpls-rsvp-te-hsmp-lsp-04 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). Please give a technical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document. This poll ends May 31, 2013. There are one IPR claim against this document, see IPR claim #1840. The authors has stated on the working group mailing list that they are not aware of any other IPR claims against this draft. However if you are on the the mpls working group mailing list and aware of IPR that relates to this draft, the time to disclose this is now. /Loa (mpls wg co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From ietfc@btconnect.com Thu May 16 12:36:23 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85A3111E8110 for ; Thu, 16 May 2013 12:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vnww71fmWQQJ for ; Thu, 16 May 2013 12:36:18 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0188.outbound.messaging.microsoft.com [213.199.154.188]) by ietfa.amsl.com (Postfix) with ESMTP id 5942411E80FD for ; Thu, 16 May 2013 12:36:18 -0700 (PDT) Received: from mail194-db8-R.bigfish.com (10.174.8.236) by DB8EHSOBE022.bigfish.com (10.174.4.85) with Microsoft SMTP Server id 14.1.225.23; Thu, 16 May 2013 19:36:17 +0000 Received: from mail194-db8 (localhost [127.0.0.1]) by mail194-db8-R.bigfish.com (Postfix) with ESMTP id 3581B40896; Thu, 16 May 2013 19:36:17 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.85; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0710HT003.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -18 X-BigFish: PS-18(zz98dI9371I542Iec9I1432I4015I1521Idb82hzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah8275bh8275dh8275chz2dh2a8h5a9h668h839h946hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh19f0h1ad9h1b0ah1d0ch1d2eh1d3fh304l1d11m1155h) Received: from mail194-db8 (localhost.localdomain [127.0.0.1]) by mail194-db8 (MessageSwitch) id 1368732973517939_31035; Thu, 16 May 2013 19:36:13 +0000 (UTC) Received: from DB8EHSMHS030.bigfish.com (unknown [10.174.8.232]) by mail194-db8.bigfish.com (Postfix) with ESMTP id 7ABEA3400D2; Thu, 16 May 2013 19:36:13 +0000 (UTC) Received: from DB3PRD0710HT003.eurprd07.prod.outlook.com (157.56.253.85) by DB8EHSMHS030.bigfish.com (10.174.4.40) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 16 May 2013 19:36:13 +0000 Received: from pc6 (86.173.197.168) by pod51017.outlook.com (10.255.75.38) with Microsoft SMTP Server (TLS) id 14.16.311.1; Thu, 16 May 2013 19:36:12 +0000 Message-ID: <01b201ce526b$dea72f80$4001a8c0@gateway.2wire.net> From: t.petch To: "Carlos Pignataro (cpignata)" References: <62CCD4C52ACDAD4481149BD5D8A72FD316C3ED09@CH1PRD0510MB355.namprd05.prod.outlook.com><2FE467D3673DCE409A84D67EC2F607BB0FA778AF@xmb-rcd-x10.cisco.com> <002901ce5229$511090e0$4001a8c0@gateway.2wire.net> <95067C434CE250468B77282634C96ED322B58488@xmb-aln-x02.cisco.com> Date: Thu, 16 May 2013 20:21:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.173.197.168] X-FOPE-CRA-Verdict: 157.56.253.85$juniper.net%12218%4%btconnect.com%False%False%0$ Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: btconnect.com Cc: mpls@ietf.org, Ross Callon , mpls-chairs@tools.ietf.org, draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org Subject: Re: [mpls] Poll for WG adoptionfordraft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 May 2013 19:36:23 -0000 Carlos inline Tom Petch ----- Original Message ----- From: "Carlos Pignataro (cpignata)" To: "t.petch" Sent: Thursday, May 16, 2013 5:38 PM Tom, Mach, Please see inline. On May 16, 2013, at 7:34 AM, t.petch wrote: > ----- Original Message ----- > From: "Andrew G. Malis" > To: "Mach Chen" > Cc: "Ross Callon" ; ; > ; > > Sent: Thursday, May 16, 2013 12:27 PM > > Mach, > > But if you make this change, then you have the opposite problem, because > you also have TLVs that don't inherit the sub-TLVs from type 1, so you > need > some way of saying exactly which sub-TLVs apply to those. And you could > easily create new sub-TLVs that don't apply to TLV 1, 16, or 21. > > > Andrew > > I don't see it; any RFC defining a TLV says which sub-TLVs apply. > > That is true now, and will be true in future if the approach in this I-D > is adopted. > > What changes is that there is a unique, unambiguous way of referring to > any sub-TLV anywhere; 33 will mean 33, and not the 33 that is defined > under that TLV as opposed to the 33 that is defined under this or the > other TLV. But that would not be a feature. By definition, sub-TLVs are scoped within each TLV. And the parsing of this sub-TLV is, again, within the context of the TLV. A sub-TLV under TLV Type 9 means something different than under TLV Type 1 -- today. One of the pragmatic consequences of this is that, unless IANA maintains an impractical 64k x 64k matrix of TLV vs. sub-TLV applicability, an implementor would have to go through all those RFCs to see what applies to what. For example, if TLV1 has sub-TLVs 10-12 that apply to it, and TLV2 has sub-TLVs 14-18 that apply to it, but neither sub-TLV applies to the other TLV (the common case), how do you codify that in an IANA registry? And in an implementaiton? Carlos I wonder if you imbue the IANA registry with too much power! If you are going to implement LSP Ping, then I cannot see any way to avoid reading the RFC, and if you are implementing all TLVs and sub-TLVs, then that is some seven documents, which tell you what actions to take, what sub-TLVs are relevant, and so on. IANA provides a registry of what has been registered, where to go for more information and how to update the registry. Authoritative technical details of the meaning and usage of the entries lie elsewhere, in those seven documents. How do I codify which sub-TLVs apply, in what combination, in an IANA registry? I don't, I turn to the relevant RFC for that technical information which then informs the implementation. So if you are implementing TLV Type 21, then you go to the defining document for that in order to understand what sub-TLVs to expect. And if, at any time, you are parsing sub-TLV Type 19, then, at present, you have in some sense a separate parser for each and every 19 because each and every one is in some respect different, at least since it is under a different scope; the current rules mean that sub-TLV Type 19 of one TLV is defined to have no relationship with sub-TLV Type 19 of another, different TLV. You can assume nothing. Perhaps the implementation would be simpler if 19 always meant the same, as is now being proposed for future allocations, perhaps not, but I struggle to see how it would be more complex. Certainly the documentation becomes clearer. Tom Petch > > The history of the past two years is of the writers of some I-Ds getting > this wrong (because it is complex, not obvious or whatever) - the aim is > this I-D is to make simple enough for people not to get wrong. > It is not clear to me what problem is being solved. You could define a "Global sub-TLV" TLV if you want to include some sub-TLV in a message with applicability regardless of what other TLV is presence. RFC 4379 is fairly unambiguous: The IANA has created and will maintain a registry for the Type field of top-level TLVs as well as for any associated sub-TLVs. Note the meaning of a sub-TLV is scoped by the TLV. Mach, please see below. > Tom Petch > > A better solution to me is to list the sub-TLVs for TLV 1 just as it is > now, and for TLV 21, use the exact same note that's in the table for TLV > 16 > ("NOTE: all current and future sub-TLVs for Target FEC Stack also apply > to > this TLV"). In addition, for TLV 21, if there's an RFC that creates a > new > sub-TLV that is ONLY for TLV 21, in that RFC the instructions for IANA > are > to create a new sub-TLV (say 26) for TLV 21, and at the same time, > allocate > sub-TLV 26 of TLV 1 as "Reserved for TLV 21 use, unused for TLV 1". > > Cheers, > Andy > > > On Wed, May 15, 2013 at 11:35 PM, Mach Chen > wrote: > >> Hi Andy,**** >> >> ** ** >> >> The current =93TLVs and sub-TLVs=94 structure works very well if speci= fic >> sub-TLVs only belong to a single TLV. But with increasing of TLVs and >> sub-TLVs, there are more and more TLVs trying to share sub-TLVs > defined for >> other TLV. For example, Type 16 TLV is designed to reuse all existing > and >> future sub-TLVs defined for Type 1 TLV. Type 21 TLV is also intended > to >> apply all the existing and future defined sub-TLVs of Type 1 TLV, and > at >> the same time, it also defines its own dedicated sub-TLVs, it=92s > difficult >> or even impossible to achieve this with the current =93TLV and sub-TLVs=94 >> allocation rules and policies. Since if one TLV wants to inherit/reuse > all >> sub-TLVs of one TLV, they actually share the same name space, there is > no >> safe way to define TLV dedicated sub-TLVs. **** >> >> ** ** >> >> For example, Type 1 TLV has defined 25 sub-TLVs so far, it will define >> more in the future, Type 21 TLV applies these sub-TLVs for itself; > then >> Type 21 TLV wants to define its own sub-TLV, what code points should > be >> allocated to the sub-TLV? If allocating 26 to it, then when Type 1 > TLV >> defines one more new sub-TLV, it will probably be allocated 26 as the > code >> point, then confliction occurs. And even if you allocate a much bigger >> number (e.g., 1000) to the new sub-TLV, in theory, the confliction > cannot >> be avoided completely. **** >> The current proposal does not solve this problem either. If Type 21 wants to allocate a sub-TLV that it applies to it but not to Type 1, how do you record that with a global sub-TLV space? >> ** ** >> >> The required changes proposed in the draft will not impact the >> implementation, it just changes the way on how to register a sub-TLV. > **** >> >> ** ** >> >> In addition, the similar definition/usage is not novel, for example, > the >> Attribute Flag TLV can be carried/shared in/by many Objects, but flags > are >> defined and register in a common space.**** >> >> ** ** >> >> There are a lot of discussions online/offline about the TLV and > sub-TLVs >> allocations rules and policies on progressing the draft-ietf-mpls >> -return-path-specified-lsp-ping, and the draft is still stuck by this >> allocation issue. Seems this is the best solution that we could think > of so >> far. **** >> Have you considered these? 1. Have TLV 21 be an "I follow TLV 1" definition. 2. Have new sub-TLVs added to 1. 3. If you need sub-TLVs that do not apply to both TLV 1 and TLV21, then define a new TLV. Thanks, -- Carlos. >> ** ** >> >> Best regards,**** >> >> Mach**** >> >> ** ** >> >> *From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On > Behalf >> Of *Andrew G. Malis >> *Sent:* Thursday, May 16, 2013 5:51 AM >> *To:* George Swallow (swallow) >> *Cc:* Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; >> draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org >> *Subject:* Re: [mpls] Poll for WG adoption for >> draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02**** >> >> ** ** >> >> I agree with George from a definition standpoint, I don't find the > "TLVs >> and sub-TLVs" table at >> > http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-p > arameters.xmldifficult to follow at all. However, it would be > interesting to hear from >> implementers if they've had any difficulty implementing the TLVs and >> sub-TLVs.**** >> >> But at this point, with existing implementations, I think we need a > REALLY >> GOOD reason to change other than some people find the table confusing, >> which seems to be the main justification in the draft.**** >> >> ** ** >> >> Also, if the draft is adopted, it would be useful for it to have a > link to >> the IANA page in the references. >> >> Cheers,**** >> >> Andy**** >> >> ** ** >> >> On Tue, May 14, 2013 at 11:26 AM, George Swallow (swallow) < >> swallow@cisco.com> wrote:**** >> >> With hat off.**** >> >> ** ** >> >> No/do not support.**** >> >> ** ** >> >> I believe that making a single sub-TLV space is going to lead to a lot > of >> confusion in the future as to which sub-TLVs are used with which TLVs. >> That is one will have to search through bunch of documents instead of >> seeing it clearly laid out in the registry. **** >> >> ** ** >> >> Keeping the spaces separate for RSVP has worked well. I really don't > get >> what is preventing that here. **** >> >> ** ** >> >> George**** >> >> ** ** >> >> *From: *Ross Callon >> *Date: *Sunday, May 5, 2013 10:53 PM >> *To: *"mpls@ietf.org" , " >> draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org" < >> draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org> >> *Cc: *"mpls-chairs@tools.ietf.org" **** >> >> >> *Subject: *[mpls] Poll for WG adoption for >> draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02**** >> >> ** ** >> >> Working group,**** >> >> **** >> >> this is to start a "two week" poll on adopting**** >> >> draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02**** >> >> as an MPLS working group document.**** >> >> **** >> >> Please send your comments (support/not support) to the mpls > working**** >> >> group mailing list (mpls@ietf.org).**** >> >> **** >> >> This poll will end May 20th, 2013.**** >> >> **** >> >> Ross**** >> >> (as mpls wg co-chair)**** >> >> **** >> >> **** >> >> >> _______________________________________________ >> 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 lizho.jin@gmail.com Thu May 16 21:59:28 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9356B21F8EAE for ; Thu, 16 May 2013 21:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7NEJ4MX98kz for ; Thu, 16 May 2013 21:59:23 -0700 (PDT) Received: from mail-qe0-f47.google.com (mail-qe0-f47.google.com [209.85.128.47]) by ietfa.amsl.com (Postfix) with ESMTP id 70C8521F8AD5 for ; Thu, 16 May 2013 21:59:23 -0700 (PDT) Received: by mail-qe0-f47.google.com with SMTP id w7so2482163qeb.34 for ; Thu, 16 May 2013 21:59:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=NT7XvB4W/nGPqgB9kqHP4YI5oF7P+aAY+jfWDpsA6Dg=; b=eNfzn3rJ2SjfuZ1LYY9ZM9sus523jwETWWkI+qwvPbCEf9HSeA9e/NktbY3sPIEMba DouFY3p5xLnI4eaqVwWD0lxeb0fPtnNvV3N5pGB22BtuVusZf5vyaTFWWkXON3ccYoc/ /i4ldg/rSh3OlOcelh5oqIKHPhlmHXAubC40dkLXdbz+klJhlCc4ofJx5DmyWZ61+ByA ETNdi1re5c+NuVuQAJMQxllv5GMKHgL1Hhxw3qpdCcJLB4nRJg49rXaBaReHRn/Otn28 9TY+9ADi6M0jClw2tQJdXCUaVycCmFARdpReL6nOcvKKQJYwUt8qPKnLji/sHUBWa16o T/wA== MIME-Version: 1.0 X-Received: by 10.229.94.4 with SMTP id x4mr13172775qcm.56.1368766762921; Thu, 16 May 2013 21:59:22 -0700 (PDT) Received: by 10.49.129.162 with HTTP; Thu, 16 May 2013 21:59:22 -0700 (PDT) Date: Fri, 17 May 2013 12:59:22 +0800 Message-ID: From: Lizhong Jin To: Loa Andersson Content-Type: multipart/alternative; boundary=90e6ba5bbc55af542f04dce2d89d Cc: "mpls@ietf.org" Subject: Re: [mpls] poll to see if we have consensus to make draft-jjb-mpls-rsvp-te-hsmp-lsp an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 04:59:28 -0000 --90e6ba5bbc55af542f04dce2d89d Content-Type: text/plain; charset=ISO-8859-1 Support as co-author. Lizhong On Fri, May 17, 2013 at 1:49 AM, Loa Andersson wrote: > Working Group, > > This is to start a two week poll on adopting > draft-jjb-mpls-rsvp-te-hsmp-**lsp-04 as an MPLS working > group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > This poll ends May 31, 2013. > > There are one IPR claim against this document, see IPR claim #1840. > > The authors has stated on the working group mailing list > that they are not aware of any other IPR claims against this draft. > However if you are on the the mpls working group mailing list and > aware of IPR that relates to this draft, the time to disclose > this is now. > > /Loa > (mpls wg co-chair) > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > --90e6ba5bbc55af542f04dce2d89d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Support as co-author.
=A0
Lizhong

<= /div>
On Fri, May 17, 2013 at 1:49 AM, Loa Anders= son <lo= a@pi.nu> wrote:
Working Group,

This is to start a two week poll on adopting
draft-jjb-mpls-rsvp-te-hsmp-lsp-04 as an MPLS working
group document.

Please send your comments (support/not support) to the mpls working
group mailing list (mpls= @ietf.org). Please give a technical
motivation for your support/not support, especially if you think that
the document should not be adopted as a working group document.

This poll ends May 31, 2013.

There are one IPR claim against this document, see IPR claim #1840.

The authors has stated on the working group mailing list
that they are not aware of any other IPR claims against this draft.
However if you are on the the mpls working group mailing list and
aware of IPR that relates to this draft, the time to disclose
this is now.

/Loa
(mpls wg co-chair)
--


Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0email: loa@mail01.huawei.com
Senior MPLS Expert =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
Huawei Technologies (consultant) =A0 =A0 phone: +46 739 81 21 64

--90e6ba5bbc55af542f04dce2d89d-- From lizho.jin@gmail.com Thu May 16 22:44:13 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7664F21F924A for ; Thu, 16 May 2013 22:44:13 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9Lxjw0O7m6F for ; Thu, 16 May 2013 22:44:12 -0700 (PDT) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) by ietfa.amsl.com (Postfix) with ESMTP id DC0CF21F923B for ; Thu, 16 May 2013 22:44:11 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id hu16so197222qab.13 for ; Thu, 16 May 2013 22:44:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=hkdzMQoMkjGLT9G0KQY+54hF9B8dKuDCHeGerJxwTXM=; b=vAIfin6l4C+r0AqWRa9XVyvgVUzD4ILaotjqbhMJXOQcVg4FEGVlZ4XLaBPCIsKTbx ZX00X//e7R1CQenimnnTL7qqnkVDua/nBSlwT3MEvOj9n3R+LSWnzel1PMuD8S2jnUti I1vhqUjWfJnAY3w3j7UPCL4XY3g9iFsiawyqQSHUSdEIVhcbBaBQlcQMBrMxcukYSSYf TBR3loNo53/2vbBLxt5VbwxpOTRLlvOd9oyHAz0/ZYfe6fYh8IBykWrR78XI2qu2tKG1 Ff5JbPkaqARiFw98dfA9Rzz4dqAOdZKxNFTLcE/yqvnxYU3HAHm+bHQIc6H8YQSuL9tV cw2g== MIME-Version: 1.0 X-Received: by 10.224.7.195 with SMTP id e3mr35414267qae.5.1368769451323; Thu, 16 May 2013 22:44:11 -0700 (PDT) Received: by 10.49.129.162 with HTTP; Thu, 16 May 2013 22:44:11 -0700 (PDT) Date: Fri, 17 May 2013 13:44:11 +0800 Message-ID: From: Lizhong Jin To: "mpls@ietf.org" , "adrian@olddog.co.uk" Content-Type: multipart/alternative; boundary=e89a8f923b36ed143f04dce37899 Subject: Re: [mpls] Retiring ACH TLVs X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 05:44:14 -0000 --e89a8f923b36ed143f04dce37899 Content-Type: text/plain; charset=ISO-8859-1 Hi, Support, and I like this. But it seems deleting section 3 in RFC5586 is not enough. Other sections in RFC5586 also has the content of ACH TLV. Is it engouth to update by only deleting section 3 described in this draft? Lizhong > > > On Tue, May 7, 2013 at 1:08 PM, Adrian Farrel wrote: > > > Hi, > > > > ACH TLVs keep popping up and causing Stewart and me trouble. Mainly it is > > about explaining why no-one actually wants to use them (i.e., when each > new > > ACH Type is defined and has a "No TLVs" written for it, we get asked "why > > not?"). > > > > It seems to us that ACH TLVs are an idea that has been rejected. > Initially > > we thought they might be used (especially for identifiers), but there > seems > > to be good opinion that handling generic TLVs would be a pain. > > > > Since I was heavily responsible for insisting that ACH TLVs were included > > in RFC 5586, it seems reasonable that I do the work to fix it. > > > > The I-D below retires ACH TLVs and handles the necessary registry > changes. > > > > Note, of course, that structured data are still possible within > individual > > ACHs if the protocol spec for an individual ACH decides to have them. > > > > We're directing this work to the MPLS working group because that is where > > 5586 was written. I have BCC'ed PWE3, L2VPN, and BFD for information. > > > > Thanks for any comments. > > > > As humble WG contributors we would be enthusiastic to see early WG > > adoption and last call :-) > > > > Thanks, > > Adrian > > > > > -----Original Message----- > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > Sent: 07 May 2013 17:33 > > > To: Adrian Farrel; Stewart Bryant > > > Subject: New Version Notification for > > draft-farbryantrel-mpls-retire-ach-tlv- > > > 00.txt > > > > > > > > > A new version of I-D, draft-farbryantrel-mpls-retire-ach-tlv-00.txt > > > has been successfully submitted by Adrian Farrel and posted to the > > > IETF repository. > > > > > > Filename: draft-farbryantrel-mpls-retire-ach-tlv > > > Revision: 00 > > > Title: Retiring TLVs from the Associated Channel Header > > of the MPLS > > > Generic Associated Channel > > > Creation date: 2013-05-07 > > > Group: Individual Submission > > > Number of pages: 4 > > > URL: > > http://www.ietf.org/internet-drafts/draft-farbryantrel-mpls-retire- > > > ach-tlv-00.txt > > > Status: > > http://datatracker.ietf.org/doc/draft-farbryantrel-mpls-retire-ach-tlv > > > Htmlized: > > http://tools.ietf.org/html/draft-farbryantrel-mpls-retire-ach-tlv-00 > > > > > > > > > Abstract: > > > The MPLS Generic Associated Channel (G-ACh) is a generalization of > > > the applicability of the Pseudowire (PW) Associated Channel Header > > > (ACH). RFC 5586 defines the concept of Type-Length-Variable (TLV) > > > constructs that can be carried in messages on the G-ACh by placing > > > them in the ACH. > > > > > > No Associated Channel Type yet defined uses a TLV. Furthermore, it > > > is believed that handling TLVs in hardware introduces significant > > > problems to the fast-path, and since G-ACh messages are intended to > > > be processed substantially in hardware, the use of TLVs in > > > undesirable. > > > > > > This document updates RFC 5586 by retiring ACH TLVs and removing the > > > associated registry. > > > > > > > > > > > > > > > The IETF Secretariat > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.ietf.org/mail-archive/web/mpls/attachments/20130516/f560777c/attachment.htm > > > > ------------------------------ > --e89a8f923b36ed143f04dce37899 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
Support, and I like this. But it seems deleting section 3 in RFC5586 i= s not enough. Other sections in RFC5586 also has the content of ACH TLV. Is= it engouth to update by only deleting section 3 described in this draft?
=A0
Lizhong

=A0


On Tue, May 7, 2013 at 1:08 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:

> Hi,
>
> ACH TLVs keep popping up and causing Stewart and me trouble. Mainly it= is
> about explaining why no-one actually wants to use them (i.e., when eac= h new
> ACH Type is defined and has a "No TLVs" written for it, we g= et asked "why
> not?").
>
> It seems to us that ACH TLVs are an idea that has been rejected. Initi= ally
> we thought they might be used (especially for identifiers), but there = seems
> to be good opinion that handling generic TLVs would be a pain.
>
> Since I was heavily responsible for insisting that ACH TLVs were inclu= ded
> in RFC 5586, it seems reasonable that I do the work to fix it.
>
> The I-D below retires ACH TLVs and handles the necessary registry chan= ges.
>
> Note, of course, that structured data are still possible within indivi= dual
> ACHs if the protocol spec for an individual ACH decides to have them.<= br> >
> We're directing this work to the MPLS working group because that i= s where
> 5586 was written. I have BCC'ed PWE3, L2VPN, and BFD for informati= on.
>
> Thanks for any comments.
>
> As humble WG contributors we would be enthusiastic to see early WG
> adoption and last call :-)
>
> Thanks,
> Adrian
>
> > -----Original Message-----
> > From: internet-drafts= @ietf.org [mailto:internet-= drafts@ietf.org]
> > Sent: 07 May 2013 17:33
> > To: Adrian Farrel; Stewart Bryant
> > Subject: New Version Notification for
> draft-farbryantrel-mpls-retire-ach-tlv-
> > 00.txt
> >
> >
> > A new version of I-D, draft-farbryantrel-mpls-retire-ach-tlv-00.t= xt
> > has been successfully submitted by Adrian Farrel and posted to th= e
> > IETF repository.
> >
> > Filename: =A0 =A0 =A0draft-farbryantrel-mpls-retire-ach-tlv
> > Revision: =A0 =A0 =A000
> > Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Retiring TLVs from the Ass= ociated Channel Header
> of the MPLS
> > Generic Associated Channel
> > Creation date: =A0 =A0 =A0 =A0 2013-05-07
> > Group: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Individual Submission
> > Number of pages: 4
> > URL:
> http://www.ietf.org/internet-drafts/draft-farbr= yantrel-mpls-retire-
> > ach-tlv-00.txt
> > Status:
> http://datatracker.ietf.org/doc/draft-farbry= antrel-mpls-retire-ach-tlv
> > Htmlized:
> http://tools.ietf.org/html/draft-farbryantrel-= mpls-retire-ach-tlv-00
> >
> >
> > Abstract:
> > =A0 =A0The MPLS Generic Associated Channel (G-ACh) is a generaliz= ation of
> > =A0 =A0the applicability of the Pseudowire (PW) Associated Channe= l Header
> > =A0 =A0(ACH). =A0RFC 5586 defines the concept of Type-Length-Vari= able (TLV)
> > =A0 =A0constructs that can be carried in messages on the G-ACh by= placing
> > =A0 =A0them in the ACH.
> >
> > =A0 =A0No Associated Channel Type yet defined uses a TLV. =A0Furt= hermore, it
> > =A0 =A0is believed that handling TLVs in hardware introduces sign= ificant
> > =A0 =A0problems to the fast-path, and since G-ACh messages are in= tended to
> > =A0 =A0be processed substantially in hardware, the use of TLVs in=
> > =A0 =A0undesirable.
> >
> > =A0 =A0This document updates RFC 5586 by retiring ACH TLVs and re= moving the
> > =A0 =A0associated registry.
> >
> >
> >
> >
> > The IETF Secretariat
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail= -archive/web/mpls/attachments/20130516/f560777c/attachment.htm>

------------------------------
--e89a8f923b36ed143f04dce37899-- From fu.xihua@zte.com.cn Thu May 16 23:26:10 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 207A021F92D3 for ; Thu, 16 May 2013 23:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fc2lYVJWzcXL for ; Thu, 16 May 2013 23:26:06 -0700 (PDT) Received: from zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id A707121F92CB for ; Thu, 16 May 2013 23:26:02 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 7A5ED19376E9 for ; Fri, 17 May 2013 14:25:33 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 3555D7048B2; Fri, 17 May 2013 14:25:31 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id r4H6PYHO036708; Fri, 17 May 2013 14:25:34 +0800 (GMT-8) (envelope-from fu.xihua@zte.com.cn) To: Loa Andersson MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: fu.xihua@zte.com.cn Date: Fri, 17 May 2013 14:23:33 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-05-17 14:25:14, Serialize complete at 2013-05-17 14:25:14 Content-Type: multipart/alternative; boundary="=_alternative 002354A048257B6E_=" X-MAIL: mse01.zte.com.cn r4H6PYHO036708 Cc: "mpls@ietf.org" Subject: Re: [mpls] poll to see if we have consensus to make draft-jjb-mpls-rsvp-te-hsmp-lsp an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 06:26:10 -0000 This is a multipart message in MIME format. --=_alternative 002354A048257B6E_= Content-Type: text/plain; charset="US-ASCII" Support. Xihua Fu On Fri, May 17, 2013 at 1:49 AM, Loa Andersson wrote: Working Group, This is to start a two week poll on adopting draft-jjb-mpls-rsvp-te-hsmp-lsp-04 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). Please give a technical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document. This poll ends May 31, 2013. There are one IPR claim against this document, see IPR claim #1840. The authors has stated on the working group mailing list that they are not aware of any other IPR claims against this draft. However if you are on the the mpls working group mailing list and aware of IPR that relates to this draft, the time to disclose this is now. /Loa (mpls wg co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --=_alternative 002354A048257B6E_= Content-Type: text/html; charset="US-ASCII"
Support.

Xihua Fu


On Fri, May 17, 2013 at 1:49 AM, Loa Andersson <loa@pi.nu> wrote:
Working Group,

This is to start a two week poll on adopting
draft-jjb-mpls-rsvp-te-hsmp-lsp-04 as an MPLS working
group document.

Please send your comments (support/not support) to the mpls working
group mailing list (mpls@ietf.org). Please give a technical
motivation for your support/not support, especially if you think that
the document should not be adopted as a working group document.

This poll ends May 31, 2013.

There are one IPR claim against this document, see IPR claim #1840.

The authors has stated on the working group mailing list
that they are not aware of any other IPR claims against this draft.
However if you are on the the mpls working group mailing list and
aware of IPR that relates to this draft, the time to disclose
this is now.

/Loa
(mpls wg co-chair)
--


Loa Andersson                        email: loa@mail01.huawei.com
Senior MPLS Expert                          loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
 --=_alternative 002354A048257B6E_=-- From mach.chen@huawei.com Fri May 17 00:38:09 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B8B21F8FDD for ; Fri, 17 May 2013 00:38:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wTUqMGvOCu57 for ; Fri, 17 May 2013 00:38:05 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1493621F8FC4 for ; Fri, 17 May 2013 00:38:03 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARL75059; Fri, 17 May 2013 07:37:59 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 17 May 2013 08:37:19 +0100 Received: from SZXEML452-HUB.china.huawei.com (10.82.67.195) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 17 May 2013 08:37:55 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.134]) by szxeml452-hub.china.huawei.com ([10.82.67.195]) with mapi id 14.01.0323.007; Fri, 17 May 2013 15:37:50 +0800 From: Mach Chen To: "Andrew G. Malis" Thread-Topic: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 Thread-Index: AQHOUihqolFYPe7DdE+Oy9ifKyyLGZkI9mxQ Date: Fri, 17 May 2013 07:37:49 +0000 Message-ID: References: <62CCD4C52ACDAD4481149BD5D8A72FD316C3ED09@CH1PRD0510MB355.namprd05.prod.outlook.com> <2FE467D3673DCE409A84D67EC2F607BB0FA778AF@xmb-rcd-x10.cisco.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255B87661szxeml558mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Ross Callon , "mpls-chairs@tools.ietf.org" , "draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 07:38:09 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255B87661szxeml558mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Andy, With this "Common sub-TLVs" structure and registry, as Tom said, for the IA= NA registry, we don't have to explicitly list which sub-TLVs apply to which= TLVs, we could just only list which RFCs (as the reference) defines the su= b-TLVs. As for which TLVs could carry the sub-TLVs, this is left for the re= levant RFCs to define. Specific to the issue that TLV 21 faced, your solution is an alternative, a= nd we actually had thought about it. The side effect is that it will make t= he allocation more complicated and does not completely solve the issue. Think about if there is a TLV that needs to reuse/inherit sub-TLVs of more = than one TLVs; or two or more TLVs want to reuse/inherit sub-TLVs each othe= r..., this will make the allocation more and more complicated. Best regards, Mach From: Andrew G. Malis [mailto:agmalis@gmail.com] Sent: Thursday, May 16, 2013 7:28 PM To: Mach Chen Cc: George Swallow (swallow); Ross Callon; mpls@ietf.org; mpls-chairs@tools= .ietf.org; draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.or= g Subject: Re: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-a= nd-sub-tlvs-registry-02 Mach, But if you make this change, then you have the opposite problem, because yo= u also have TLVs that don't inherit the sub-TLVs from type 1, so you need s= ome way of saying exactly which sub-TLVs apply to those. And you could easi= ly create new sub-TLVs that don't apply to TLV 1, 16, or 21. A better solution to me is to list the sub-TLVs for TLV 1 just as it is now= , and for TLV 21, use the exact same note that's in the table for TLV 16 ("= NOTE: all current and future sub-TLVs for Target FEC Stack also apply to th= is TLV"). In addition, for TLV 21, if there's an RFC that creates a new sub= -TLV that is ONLY for TLV 21, in that RFC the instructions for IANA are to = create a new sub-TLV (say 26) for TLV 21, and at the same time, allocate su= b-TLV 26 of TLV 1 as "Reserved for TLV 21 use, unused for TLV 1". Cheers, Andy On Wed, May 15, 2013 at 11:35 PM, Mach Chen > wrote: Hi Andy, The current "TLVs and sub-TLVs" structure works very well if specific sub-= TLVs only belong to a single TLV. But with increasing of TLVs and sub-TLVs,= there are more and more TLVs trying to share sub-TLVs defined for other TL= V. For example, Type 16 TLV is designed to reuse all existing and future su= b-TLVs defined for Type 1 TLV. Type 21 TLV is also intended to apply all th= e existing and future defined sub-TLVs of Type 1 TLV, and at the same time,= it also defines its own dedicated sub-TLVs, it's difficult or even impossi= ble to achieve this with the current "TLV and sub-TLVs" allocation rules an= d policies. Since if one TLV wants to inherit/reuse all sub-TLVs of one TLV= , they actually share the same name space, there is no safe way to define T= LV dedicated sub-TLVs. For example, Type 1 TLV has defined 25 sub-TLVs so far, it will define mor= e in the future, Type 21 TLV applies these sub-TLVs for itself; then Type 2= 1 TLV wants to define its own sub-TLV, what code points should be allocated= to the sub-TLV? If allocating 26 to it, then when Type 1 TLV defines one = more new sub-TLV, it will probably be allocated 26 as the code point, then = confliction occurs. And even if you allocate a much bigger number (e.g., 10= 00) to the new sub-TLV, in theory, the confliction cannot be avoided comple= tely. The required changes proposed in the draft will not impact the implementat= ion, it just changes the way on how to register a sub-TLV. In addition, the similar definition/usage is not novel, for example, the A= ttribute Flag TLV can be carried/shared in/by many Objects, but flags are d= efined and register in a common space. There are a lot of discussions online/offline about the TLV and sub-TLVs a= llocations rules and policies on progressing the draft-ietf-mpls-return-pat= h-specified-lsp-ping, and the draft is still stuck by this allocation issu= e. Seems this is the best solution that we could think of so far. Best regards, Mach From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of Andrew G. Malis Sent: Thursday, May 16, 2013 5:51 AM To: George Swallow (swallow) Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.iet= f.org; draft-pac-mpls-lsp-ping-tlvs-and-= sub-tlvs-registry@tools.ietf.org Subject: Re: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-a= nd-sub-tlvs-registry-02 I agree with George from a definition standpoint, I don't find the "TLVs an= d sub-TLVs" table at http://www.iana.org/assignments/mpls-lsp-ping-paramete= rs/mpls-lsp-ping-parameters.xml difficult to follow at all. However, it wou= ld be interesting to hear from implementers if they've had any difficulty i= mplementing the TLVs and sub-TLVs. But at this point, with existing implementations, I think we need a REALLY = GOOD reason to change other than some people find the table confusing, whic= h seems to be the main justification in the draft. Also, if the draft is adopted, it would be useful for it to have a link to = the IANA page in the references. Cheers, Andy On Tue, May 14, 2013 at 11:26 AM, George Swallow (swallow) > wrote: With hat off. No/do not support. I believe that making a single sub-TLV space is going to lead to a lot of c= onfusion in the future as to which sub-TLVs are used with which TLVs. That= is one will have to search through bunch of documents instead of seeing it= clearly laid out in the registry. Keeping the spaces separate for RSVP has worked well. I really don't get w= hat is preventing that here. George From: Ross Callon > Date: Sunday, May 5, 2013 10:53 PM To: "mpls@ietf.org" >, "draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org" > Cc: "mpls-chairs@tools.ietf.org" > Subject: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-s= ub-tlvs-registry-02 Working group, this is to start a "two week" poll on adopting draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end May 20th, 2013. Ross (as mpls wg co-chair) _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255B87661szxeml558mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Andy,

=  

= With this “Common sub-TLVs&= #8221; structure and registry, as Tom said, for the IANA registry, we don’t have to e= xplicitly list which sub-TLVs apply to which TLVs, we could just only list = which RFCs (as the reference) defines the sub-TLVs. As for which TLVs could= carry the sub-TLVs, this is left for the relevant RFCs to define.

=  

= Specific to the issue that TLV 21 faced, your solution is an alternative, and we actually had thought about = it. The side effect is that it will make the allocation more complicated an= d does not completely solve the issue.  

=  

= Think about if there is a TLV tha= t needs to reuse/inherit sub-TLVs of more than one TLVs; or two or more TLVs= want to reuse/inherit sub-TLVs each other…, this will make the alloc= ation more and more complicated.

=  

= Best regards,

= Mach

=  

From: Andrew G. Malis [mailto:agmalis@gmail.com]
Sent: Thursday, May 16, 2013= 7:28 PM
To: Mach Chen
Cc: George Swallow (swallow)= ; Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-pac-mpls-ls= p-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org
Subject: Re: [mpls] Poll for= WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02=

 

Mach,<= o:p>

But if= you make this change, then you have the opposite problem, because you also= have TLVs that don't inherit the sub-TLVs from type 1, so you need some way of saying exactly which sub-TLVs apply to tho= se. And you could easily create new sub-TLVs that don't apply to TLV 1, 16,= or 21.

A better solution to me is to list the sub-TLVs for TLV 1 just as it is now= , and for TLV 21, use the exact same note that's in the table for TLV 16 (&= quot;NOTE: all current and future sub-TLVs for Target FEC Stack also apply = to this TLV"). In addition, for TLV 21, if there's an RFC that creates a new sub-TLV that is ONLY for TLV 21, in t= hat RFC the instructions for IANA are to create a new sub-TLV (say 26) for = TLV 21, and at the same time, allocate sub-TLV 26 of TLV 1 as "Reserve= d for TLV 21 use, unused for TLV 1".

Cheers,
Andy

&= nbsp;

On Wed, May 15, 2013 at 11:35 PM, Mac= h Chen <mach.c= hen@huawei.com> wrote:

Hi Andy,

 The current “TLVs and sub-TLVs̶= 1; structure works very well if specific sub-TLVs only belong to a single TLV. But with= increasing of TLVs and sub-TLVs, there are more and more TLVs trying to sh= are sub-TLVs defined for other TLV. For example, Type 16 TLV is designed to= reuse all existing and future sub-TLVs defined for Type 1 TLV. Type 21 TLV is also intended to apply all the exis= ting and future defined sub-TLVs of Type 1 TLV, and at the same time, it al= so defines its own dedicated sub-TLVs, it’s difficult or even impossi= ble to achieve this with the current “TLV and sub-TLVs” allocation rules and policies. Since if one TLV wants = to inherit/reuse all sub-TLVs of one TLV, they actually share the same name= space, there is no safe way to define TLV dedicated sub-TLVs.

 For example, Type 1 TLV has defined 25 sub-TLVs so far, it will define more in the future, Type 21 TLV applies th= ese sub-TLVs for itself; then Type 21 TLV wants to define its own sub-TLV, = what code points should be allocated to the sub-TLV?  If allocating 26= to it, then when Type 1 TLV defines one more new sub-TLV, it will probably be allocated 26 as the code point, = then confliction occurs. And even if you allocate a much bigger number (e.g= ., 1000) to the new sub-TLV, in theory, the confliction cannot be avoided c= ompletely.

 The required changes proposed in the draft will not impact the implementation, it just changes the way on how t= o register a sub-TLV.

 In addition, the similar definition/usage is not novel, for example, the Attribute Flag TLV can be carried/shared in= /by many Objects, but flags are defined and register in a common space.

 There are a lot of discussions online/off= line about the TLV and sub-TLVs allocations rules and policies on progressing t= he draft-ietf-mpls-return-path-specified-lsp-ping,  and the draft is s= till stuck by this allocation issue. Seems this is the best solution that w= e could think of so far.  

 Best regards,

Mach

 <= /o:p>

From: mpls-bounces@iet= f.org [mailto:mpls-bounces@ietf.org] On Behalf Of Andrew G. Malis=
Sent: Thursday, May 16, 2013= 5:51 AM
To: George Swallow (swallow)=
Cc: Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org
Subject: Re: [mpls] Poll for= WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02

 

I agree with George from a definition standpoint, I don't= find the "TLVs and sub-TLVs" table at http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-para= meters.xml difficult to follow at all. However, it would be interesting= to hear from implementers if they've had any difficulty implementing the T= LVs and sub-TLVs.

But at this point, with existing implementations, I= think we need a REALLY GOOD reason to change other than some people find the table confusing, which seems to be the mai= n justification in the draft.

 

Also, if the draft is adopted, it would be useful f= or it to have a link to the IANA page in the references.

Cheers,

Andy

 

On Tue, May 14, 2013 at 11:26 AM, George Swallow (s= wallow) <swallow@= cisco.com> wrote:

With = hat off.

 = ;

No/do= not support.

 = ;

I bel= ieve that making a single sub-TLV space is going to lead to a lot of confusion in the future as to which sub-TLVs are used with which TLVs. =  That is one will have to search through bunch of documents instead of= seeing it clearly laid out in the registry.  

 = ;

Keepi= ng the spaces separate for RSVP has worked well.  I really don't get what is preventing that here.  

 = ;

Georg= e

 = ;

From: Ross Callon <rcallon@juniper.net>
Date: Sunday, May 5, 2013 10= :53 PM
To: "mpls@ietf.org" <mpls@ietf.org>, "draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@too= ls.ietf.org" <draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-= registry@tools.ietf.org>
Cc: "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>=


Subject: [mpls] Poll for WG = adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02

 = ;

Working group,

 

this is to start a "two week&quo= t; poll on adopting

draft-pac-mpls-lsp-ping-tlvs-and-sub-= tlvs-registry-02

as an MPLS working group document.

 

Please send your comments (support/no= t support) to the mpls working

group mailing list (mpls@ietf.org).

 

This poll will end May 20th, 2013.

 

Ross

(as mpls wg co-chair)

&nbs= p;

&nbs= p;


_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

 

 

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255B87661szxeml558mbschi_-- From mach.chen@huawei.com Fri May 17 01:07:48 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0A321F939E for ; Fri, 17 May 2013 01:07:48 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YmPTJht+1IJm for ; Fri, 17 May 2013 01:07:43 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3D97B21F9347 for ; Fri, 17 May 2013 01:07:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ASW65634; Fri, 17 May 2013 08:07:38 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 17 May 2013 09:07:03 +0100 Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 17 May 2013 09:07:32 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.134]) by szxeml402-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Fri, 17 May 2013 16:07:25 +0800 From: Mach Chen To: "Carlos Pignataro (cpignata)" , "t.petch" Thread-Topic: [mpls] Poll for WG adoption fordraft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 Thread-Index: AQHOUlPi+b2P81ATe02MErbswaxvkZkI/oeg Date: Fri, 17 May 2013 08:07:23 +0000 Message-ID: References: <62CCD4C52ACDAD4481149BD5D8A72FD316C3ED09@CH1PRD0510MB355.namprd05.prod.outlook.com><2FE467D3673DCE409A84D67EC2F607BB0FA778AF@xmb-rcd-x10.cisco.com> <002901ce5229$511090e0$4001a8c0@gateway.2wire.net> <95067C434CE250468B77282634C96ED322B58488@xmb-aln-x02.cisco.com> In-Reply-To: <95067C434CE250468B77282634C96ED322B58488@xmb-aln-x02.cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Ross Callon , "" , "" , "" Subject: Re: [mpls] Poll for WG adoption fordraft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 08:07:48 -0000 Hi Carlos, Please see inline... Sniped >=20 > Mach, please see below. >=20 > >> The current "TLVs and sub-TLVs" structure works very well if specific > >> sub-TLVs only belong to a single TLV. But with increasing of TLVs and > >> sub-TLVs, there are more and more TLVs trying to share sub-TLVs > > defined for > >> other TLV. For example, Type 16 TLV is designed to reuse all existing > > and > >> future sub-TLVs defined for Type 1 TLV. Type 21 TLV is also intended > > to > >> apply all the existing and future defined sub-TLVs of Type 1 TLV, and > > at > >> the same time, it also defines its own dedicated sub-TLVs, it's > > difficult > >> or even impossible to achieve this with the current "TLV and sub-TLVs" > >> allocation rules and policies. Since if one TLV wants to inherit/reuse > > all > >> sub-TLVs of one TLV, they actually share the same name space, there is > > no > >> safe way to define TLV dedicated sub-TLVs. **** > >> > >> ** ** > >> > >> For example, Type 1 TLV has defined 25 sub-TLVs so far, it will define > >> more in the future, Type 21 TLV applies these sub-TLVs for itself; > > then > >> Type 21 TLV wants to define its own sub-TLV, what code points should > > be > >> allocated to the sub-TLV? If allocating 26 to it, then when Type 1 > > TLV > >> defines one more new sub-TLV, it will probably be allocated 26 as the > > code > >> point, then confliction occurs. And even if you allocate a much bigger > >> number (e.g., 1000) to the new sub-TLV, in theory, the confliction > > cannot > >> be avoided completely. **** > >> >=20 > The current proposal does not solve this problem either. If Type 21 wants= to > allocate a sub-TLV that it applies to it but not to Type 1, how do you re= cord that > with a global sub-TLV space? One of the purposes of this draft is to simplify the IANA registry, the IAN= A registry does not need to record which sub-TLVs apply to which TLVs, it j= ust records which RFC defines the sub-TLVs, it likes most of definitions an= d registries of "capabilities", "flags", "objects", as how to use these cap= abilities, flags and objects is left to the relevant RFCs that define/apply= them.=20 >=20 > >> ** ** > >> > >> The required changes proposed in the draft will not impact the > >> implementation, it just changes the way on how to register a sub-TLV. > > **** > >> > >> ** ** > >> > >> In addition, the similar definition/usage is not novel, for example, > > the > >> Attribute Flag TLV can be carried/shared in/by many Objects, but flags > > are > >> defined and register in a common space.**** > >> > >> ** ** > >> > >> There are a lot of discussions online/offline about the TLV and > > sub-TLVs > >> allocations rules and policies on progressing the draft-ietf-mpls > >> -return-path-specified-lsp-ping, and the draft is still stuck by this > >> allocation issue. Seems this is the best solution that we could think > > of so > >> far. **** > >> >=20 > Have you considered these? > 1. Have TLV 21 be an "I follow TLV 1" definition. > 2. Have new sub-TLVs added to 1. > 3. If you need sub-TLVs that do not apply to both TLV 1 and TLV21, then d= efine a > new TLV. I have considered 1 and 2, the new sub-TLVs may apply to both TLVs, with th= is, the final result seems the same as the "common sub-TLVs" registry solut= ion, the sub-TLV registry of type 1 TLV is equivalent to the "common sub-TL= Vs".=20 Best regards, Mach >=20 > Thanks, >=20 > -- Carlos. From cpignata@cisco.com Fri May 17 01:43:43 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 222AD21F8607 for ; Fri, 17 May 2013 01:43:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GOQbw01jxq02 for ; Fri, 17 May 2013 01:43:38 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 39B9821F85CE for ; Fri, 17 May 2013 01:43:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13762; q=dns/txt; s=iport; t=1368780218; x=1369989818; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=G2tNTT6RitXbO5lvdMGh+enpoHl63kPCjvW4LehzKGs=; b=YnKQeGa+saWj05cyb/QE5rIu31V3d41FMrMYO87sEuHfOkBf64Bfr/pk nI5v6d+L9zcXjMZwJfyJps3VLPi7hw2gW/p5OkdEJopImviQelzUUvXqR 9wkQL5VXG1GH9rBiP9VJ6wW2ekmTAq8TwWzBtOqDmT/rxG2eWRMCXWThW I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFABntlVGtJXG//2dsb2JhbABbgwg3wVx8FnSCHwEBAQMBAQEBZAUCBAcFBwQCAQgRAwEBAQEnByEGCxQJCAIEDgUJEodfAwkGDLN9DYhejEiBJn4zBwaCbmEDk2eBa4FmjB2FI4FYgTg X-IronPort-AV: E=Sophos;i="4.87,690,1363132800"; d="scan'208";a="211479679" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 17 May 2013 08:43:37 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r4H8hbw9020958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 May 2013 08:43:37 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.192]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Fri, 17 May 2013 03:43:37 -0500 From: "Carlos Pignataro (cpignata)" To: "t.petch" Thread-Topic: [mpls] Poll for WG adoptionfordraft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 Thread-Index: AQHOUmymZGcC+Rmn0k6IqNU0yqzZTZkJEGTo Date: Fri, 17 May 2013 08:43:36 +0000 Message-ID: <189C9E40-C2CC-48CA-8333-9676AD523153@cisco.com> References: <62CCD4C52ACDAD4481149BD5D8A72FD316C3ED09@CH1PRD0510MB355.namprd05.prod.outlook.com><2FE467D3673DCE409A84D67EC2F607BB0FA778AF@xmb-rcd-x10.cisco.com> <002901ce5229$511090e0$4001a8c0@gateway.2wire.net> <95067C434CE250468B77282634C96ED322B58488@xmb-aln-x02.cisco.com>, <01b201ce526b$dea72f80$4001a8c0@gateway.2wire.net> In-Reply-To: <01b201ce526b$dea72f80$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , Ross Callon , "mpls-chairs@tools.ietf.org" , "draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org" Subject: Re: [mpls] Poll for WG adoptionfordraft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 08:43:43 -0000 Tom, Thanks for the follow-up. Please see inline.=20 Thumb typed by Carlos Pignataro. Excuze typofraphicak errows On May 16, 2013, at 3:36 PM, "t.petch" wrote: > Carlos >=20 > inline >=20 > Tom Petch >=20 > ----- Original Message ----- > From: "Carlos Pignataro (cpignata)" > To: "t.petch" > Sent: Thursday, May 16, 2013 5:38 PM >=20 >=20 > Tom, Mach, >=20 > Please see inline. >=20 > On May 16, 2013, at 7:34 AM, t.petch wrote: >=20 >> ----- Original Message ----- >> From: "Andrew G. Malis" >> To: "Mach Chen" >> Cc: "Ross Callon" ; ; >> ; >> >> Sent: Thursday, May 16, 2013 12:27 PM >>=20 >> Mach, >>=20 >> But if you make this change, then you have the opposite problem, > because >> you also have TLVs that don't inherit the sub-TLVs from type 1, so you >> need >> some way of saying exactly which sub-TLVs apply to those. And you > could >> easily create new sub-TLVs that don't apply to TLV 1, 16, or 21. >>=20 >> >> Andrew >>=20 >> I don't see it; any RFC defining a TLV says which sub-TLVs apply. >>=20 >> That is true now, and will be true in future if the approach in this > I-D >> is adopted. >>=20 >> What changes is that there is a unique, unambiguous way of referring > to >> any sub-TLV anywhere; 33 will mean 33, and not the 33 that is defined >> under that TLV as opposed to the 33 that is defined under this or the >> other TLV. >=20 > But that would not be a feature. By definition, sub-TLVs are scoped > within each TLV. And the parsing of this sub-TLV is, again, within the > context of the TLV. A sub-TLV under TLV Type 9 means something different > than under TLV Type 1 -- today. >=20 > One of the pragmatic consequences of this is that, unless IANA maintains > an impractical 64k x 64k matrix of TLV vs. sub-TLV applicability, an > implementor would have to go through all those RFCs to see what applies > to what. >=20 > For example, if TLV1 has sub-TLVs 10-12 that apply to it, and TLV2 has > sub-TLVs 14-18 that apply to it, but neither sub-TLV applies to the > other TLV (the common case), how do you codify that in an IANA registry? > And in an implementaiton? >=20 > >=20 > Carlos >=20 > I wonder if you imbue the IANA registry with too much power! >=20 > If you are going to implement LSP Ping, then I cannot see any way to > avoid reading the RFC, and if you are implementing all TLVs and > sub-TLVs, then that is some seven documents, which tell you what actions > to take, what sub-TLVs are relevant, and so on. >=20 > IANA provides a registry of what has been registered, where to go for > more information and how to update the registry. Authoritative > technical details of the meaning and usage of the entries lie elsewhere, > in those seven documents. >=20 > How do I codify which sub-TLVs apply, in what combination, in an IANA > registry? I don't, I turn to the relevant RFC for that technical > information which then informs the implementation. >=20 It's not about "power"; to me, usefulness and simplicity are key drivers th= ough.=20 Today, you have a registry with TLVs and sub-TLVs, where the sub-TLV defini= tion is scoped within each TLV.=20 Changing this to a flat common sub-TLV space results in: 1. Loosing information about applicability of sub-TLVs (less usefulness) 2. Need for over-specification of which sub-TLVs from a universal flap spac= e are not applicable (less simplicity) 3. Increase in the number of exceptions, because TLVs 1, 9, 11, and 20 have= already conflicting overlapping sub-TLVs. (A lot less protocol simplicity) > So if you are implementing TLV Type 21, then you go to the defining > document for that in order to understand what sub-TLVs to expect. And > if, at any time, you are parsing sub-TLV Type 19, then, at present, you > have in some sense a separate parser for each and every 19 because each > and every one is in some respect different, at least since it is under a > different scope; the current rules mean that sub-TLV Type 19 of one TLV > is defined to have no relationship with sub-TLV Type 19 of another, > different TLV. You can assume nothing. >=20 C that assumption is major, which is why I am trying to see what's gained b= y the proposal.=20 > Perhaps the implementation would be simpler if 19 always meant the same, > as is now being proposed for future allocations, perhaps not, but I > struggle to see how it would be more complex. Certainly the > documentation becomes clearer. >=20 It seems to me that the current hierarchical allocation serves a purpose of= allowing expansion with sub-TLVs where needed with expansions contained wi= thin the scope, semantics, and control of the TLV.=20 Protocol complexity increases by these subTLVs bleed into another scope. Ma= ny sub-TLVs make no sense within another TLV than where defined.=20 A change like proposed starts with more exceptions (Types 1, 9, 11, 20) tha= n status quo, increasing complexity. TLV Type 9 is, by generic definition o= f the semantics of its sub-TLV, a permanent exception (it's sub-TLVs are el= iciting errored TLVs). Conversely, it's OK to say "new TLV m shares the sub= -TLV space with existing TLV n" (as a whole or for ranges); seems to me tha= t going further is over engineering.=20 Thank you, Carlos.=20 > Tom Petch >=20 > >=20 >>=20 >> The history of the past two years is of the writers of some I-Ds > getting >> this wrong (because it is complex, not obvious or whatever) - the aim > is >> this I-D is to make simple enough for people not to get wrong. >=20 > It is not clear to me what problem is being solved. You could define a > "Global sub-TLV" TLV if you want to include some sub-TLV in a message > with applicability regardless of what other TLV is presence. >=20 > RFC 4379 is fairly unambiguous: >=20 > The IANA has created and will maintain a registry for the Type field > of top-level TLVs as well as for any associated sub-TLVs. Note the > meaning of a sub-TLV is scoped by the TLV. >=20 >=20 > Mach, please see below. >=20 >> Tom Petch >>=20 >> A better solution to me is to list the sub-TLVs for TLV 1 just as it > is >> now, and for TLV 21, use the exact same note that's in the table for > TLV >> 16 >> ("NOTE: all current and future sub-TLVs for Target FEC Stack also > apply >> to >> this TLV"). In addition, for TLV 21, if there's an RFC that creates a >> new >> sub-TLV that is ONLY for TLV 21, in that RFC the instructions for IANA >> are >> to create a new sub-TLV (say 26) for TLV 21, and at the same time, >> allocate >> sub-TLV 26 of TLV 1 as "Reserved for TLV 21 use, unused for TLV 1". >>=20 >> Cheers, >> Andy >>=20 >>=20 >> On Wed, May 15, 2013 at 11:35 PM, Mach Chen >> wrote: >>=20 >>> Hi Andy,**** >>>=20 >>> ** ** >>>=20 >>> The current =93TLVs and sub-TLVs=94 structure works very well if specif= ic >>> sub-TLVs only belong to a single TLV. But with increasing of TLVs and >>> sub-TLVs, there are more and more TLVs trying to share sub-TLVs >> defined for >>> other TLV. For example, Type 16 TLV is designed to reuse all existing >> and >>> future sub-TLVs defined for Type 1 TLV. Type 21 TLV is also intended >> to >>> apply all the existing and future defined sub-TLVs of Type 1 TLV, and >> at >>> the same time, it also defines its own dedicated sub-TLVs, it=92s >> difficult >>> or even impossible to achieve this with the current =93TLV and > sub-TLVs=94 >>> allocation rules and policies. Since if one TLV wants to > inherit/reuse >> all >>> sub-TLVs of one TLV, they actually share the same name space, there > is >> no >>> safe way to define TLV dedicated sub-TLVs. **** >>>=20 >>> ** ** >>>=20 >>> For example, Type 1 TLV has defined 25 sub-TLVs so far, it will > define >>> more in the future, Type 21 TLV applies these sub-TLVs for itself; >> then >>> Type 21 TLV wants to define its own sub-TLV, what code points should >> be >>> allocated to the sub-TLV? If allocating 26 to it, then when Type 1 >> TLV >>> defines one more new sub-TLV, it will probably be allocated 26 as the >> code >>> point, then confliction occurs. And even if you allocate a much > bigger >>> number (e.g., 1000) to the new sub-TLV, in theory, the confliction >> cannot >>> be avoided completely. **** >=20 > The current proposal does not solve this problem either. If Type 21 > wants to allocate a sub-TLV that it applies to it but not to Type 1, how > do you record that with a global sub-TLV space? >=20 >>> ** ** >>>=20 >>> The required changes proposed in the draft will not impact the >>> implementation, it just changes the way on how to register a sub-TLV. >> **** >>>=20 >>> ** ** >>>=20 >>> In addition, the similar definition/usage is not novel, for example, >> the >>> Attribute Flag TLV can be carried/shared in/by many Objects, but > flags >> are >>> defined and register in a common space.**** >>>=20 >>> ** ** >>>=20 >>> There are a lot of discussions online/offline about the TLV and >> sub-TLVs >>> allocations rules and policies on progressing the draft-ietf-mpls >>> -return-path-specified-lsp-ping, and the draft is still stuck by > this >>> allocation issue. Seems this is the best solution that we could think >> of so >>> far. **** >=20 > Have you considered these? > 1. Have TLV 21 be an "I follow TLV 1" definition. > 2. Have new sub-TLVs added to 1. > 3. If you need sub-TLVs that do not apply to both TLV 1 and TLV21, then > define a new TLV. >=20 > Thanks, >=20 > -- Carlos. >=20 >>> ** ** >>>=20 >>> Best regards,**** >>>=20 >>> Mach**** >>>=20 >>> ** ** >>>=20 >>> *From:* mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] *On >> Behalf >>> Of *Andrew G. Malis >>> *Sent:* Thursday, May 16, 2013 5:51 AM >>> *To:* George Swallow (swallow) >>> *Cc:* Ross Callon; mpls@ietf.org; mpls-chairs@tools.ietf.org; >>> draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org >>> *Subject:* Re: [mpls] Poll for WG adoption for >>> draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02**** >>>=20 >>> ** ** >>>=20 >>> I agree with George from a definition standpoint, I don't find the >> "TLVs >>> and sub-TLVs" table at > http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-p >> arameters.xmldifficult to follow at all. However, it would be >> interesting to hear from >>> implementers if they've had any difficulty implementing the TLVs and >>> sub-TLVs.**** >>>=20 >>> But at this point, with existing implementations, I think we need a >> REALLY >>> GOOD reason to change other than some people find the table > confusing, >>> which seems to be the main justification in the draft.**** >>>=20 >>> ** ** >>>=20 >>> Also, if the draft is adopted, it would be useful for it to have a >> link to >>> the IANA page in the references. >>>=20 >>> Cheers,**** >>>=20 >>> Andy**** >>>=20 >>> ** ** >>>=20 >>> On Tue, May 14, 2013 at 11:26 AM, George Swallow (swallow) < >>> swallow@cisco.com> wrote:**** >>>=20 >>> With hat off.**** >>>=20 >>> ** ** >>>=20 >>> No/do not support.**** >>>=20 >>> ** ** >>>=20 >>> I believe that making a single sub-TLV space is going to lead to a > lot >> of >>> confusion in the future as to which sub-TLVs are used with which > TLVs. >>> That is one will have to search through bunch of documents instead of >>> seeing it clearly laid out in the registry. **** >>>=20 >>> ** ** >>>=20 >>> Keeping the spaces separate for RSVP has worked well. I really don't >> get >>> what is preventing that here. **** >>>=20 >>> ** ** >>>=20 >>> George**** >>>=20 >>> ** ** >>>=20 >>> *From: *Ross Callon >>> *Date: *Sunday, May 5, 2013 10:53 PM >>> *To: *"mpls@ietf.org" , " >>> draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org" < >>> draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org> >>> *Cc: *"mpls-chairs@tools.ietf.org" **** >>>=20 >>>=20 >>> *Subject: *[mpls] Poll for WG adoption for >>> draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02**** >>>=20 >>> ** ** >>>=20 >>> Working group,**** >>>=20 >>> **** >>>=20 >>> this is to start a "two week" poll on adopting**** >>>=20 >>> draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02**** >>>=20 >>> as an MPLS working group document.**** >>>=20 >>> **** >>>=20 >>> Please send your comments (support/not support) to the mpls >> working**** >>>=20 >>> group mailing list (mpls@ietf.org).**** >>>=20 >>> **** >>>=20 >>> This poll will end May 20th, 2013.**** >>>=20 >>> **** >>>=20 >>> Ross**** >>>=20 >>> (as mpls wg co-chair)**** >>>=20 >>> **** >>>=20 >>> **** >>>=20 >>>=20 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls**** >>>=20 >>> ** ** >>=20 >>=20 >>=20 >> ---------------------------------------------------------------------- > -- >> -------- >>=20 >>=20 >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>=20 >>=20 >> _______________________________________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls >=20 >=20 >=20 >=20 From pabloisnot@gmail.com Fri May 17 06:52:13 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDA721F949D for ; Fri, 17 May 2013 06:52:13 -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.499, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMaNczL9Fr0v for ; Fri, 17 May 2013 06:52:08 -0700 (PDT) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) by ietfa.amsl.com (Postfix) with ESMTP id B80C621F9446 for ; Fri, 17 May 2013 06:52:07 -0700 (PDT) Received: by mail-vc0-f179.google.com with SMTP id hz10so1098688vcb.24 for ; Fri, 17 May 2013 06:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=i2FKwuqJuV2poX2K9jBlmO6TmxzGl1eVtq4jA8QaKVo=; b=RmH5E89MLOmztrUEhoJDeZI63s/fhFland8ZfELGzTAS0sxXjtiAK23b8IwzEYz1c3 pmKeFAwApnmfyP+2CptOA9eyuT+q/s9UTlq0Txc10H260ZNqTUuFxvWKjo1+897i5U0Y faJOqez80Idm+AS9ZGsHJXQLz2q569LlgaaHiKD9GYgQu7eA/4lGFGsC1tuLYc0j85kr dgg19tg+FPkOHpGUryh+K2KHqf5d2oZf1PbiVNbrS5JfdtnVJSp4m5Rrfi6Qj/bnvL37 VwySuX9jNT9vqbq4CiEo7cOpK8fhlM5Bl8w1XwiucwhEab+VQh3iVnm/tW1e4SeI4N1b X2NA== MIME-Version: 1.0 X-Received: by 10.220.114.203 with SMTP id f11mr19168753vcq.21.1368798727149; Fri, 17 May 2013 06:52:07 -0700 (PDT) Received: by 10.52.114.9 with HTTP; Fri, 17 May 2013 06:52:07 -0700 (PDT) In-Reply-To: <05540BD841BBD643BB51404C4C9171521518059A97@GRFMBX703BA020.griffon.local> References: <20ECF67871905846A80F77F8F4A2757210150296@xmb-rcd-x09.cisco.com> <05540BD841BBD643BB51404C4C9171521518059A97@GRFMBX703BA020.griffon.local> Date: Fri, 17 May 2013 09:52:07 -0400 Message-ID: From: Pablo Frank To: Cavazzoni Carlo Content-Type: multipart/alternative; boundary=047d7b342cb4e69c2f04dcea49ae Cc: "mpls@ietf.org" Subject: Re: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 May 2013 13:52:13 -0000 --047d7b342cb4e69c2f04dcea49ae Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Carlo, Why wouldn't the network operator in your example use a manual switch to protection instead of a forced switch? It gives exactly the desired behaviour for your scenario, does it not? Consider this counter-example to your scenario: what if the maintenance activity that is occurring on the working path is *not* complete? Suppose that the working path is technically up but the maintenance team is running a long-term service activation test that can take several hours. From the perspective of BFD and PSC, the working path is 'up' but from the operator's perspective, it's not ready for use (they're still testing and stressing the new transport path). A SF-P suddenly pushing the traffic back to the path that is under test may be undesirable and in the worst case, could cause problems for other transport paths especially in a packet-switched network. We're now pretty clearly in the murky world of double failures and I imagine different operators have different policies for how they want to handle this. I can see why Eric claims that some operators have asked for this change. One of the things that troubles me about making the proposed change in priority is that we end up with no practicable difference between FS-P and MS-P. If I refer back to G.8031, one of the differences between FS-P and MS-P is that MS-P will be overridden by a Signal Degrade but FS-P will not. There seems to be a strong sense on the list that SD is not a meaningful condition that we can define for packet switched networks. So assuming that holds and we make this change, we'll end up with literally no difference in behaviour between FS-P and MS-P. I understand the implications that the ITU-T has pointed out that a FS could lead to a broken network but so could Lockout-of-Protection. It seems to me that in either case of LO or FS, you've made a conscious choice to run unprotected for some period of time. So buyer beware. If that was not your intent, then use MS. Am I missing something here? regards, Pablo On Tue, May 14, 2013 at 11:08 AM, Cavazzoni Carlo < carlo.cavazzoni@telecomitalia.it> wrote: > Eric, > > in order to clarify, from a network operator point of view, why I think > the SF-P must have higher priority than the FS-P I would make the followi= ng > simple practical example. > > For the execution of a programmed maintenance activity on one or more > sections of a MPLS-TP ring, all the connections routed on those sections > have been moved to the protection paths with a FS-P command for a defined > maintenance window timeframe. The maintenance work is typically done by a > team different from that managing the MPLS-TP network: let's imagine > maintenance people complete the work well in advance with respect to the > planned maintenance window. > Unfortunately a failure (SF-P) happens before the end of the planned > maintenance window timeframe, what happens? > > a) If SF-P has higher priority than FS-P then PSC moves the traffic > back to the working path so recovering the connectivity in a short > protection switching time; > b) If FS-P has higher priority than SF-P then the traffic remains on > the broken connection and it will continue to be lost even when the worki= ng > path is up and running (i.e. at the latest at the end of the planned > maintenance window): it seems that only a manual (and slow) reconfigurati= on > of both protection endpoints from the management system could recover the > normal working state. > > Why do we have to define case b) as the standard behavior? > Are there use cases that suggest case b) as the preferred choice? > > Hope this can help. > > Regards, > > Carlo > > ------------------------------------------------------------------ > Telecom Italia > Carlo Cavazzoni > Transport Innovation > Via G. Reiss Romoli, 274 10148 Torino > +39 011 2285732 > +39 335 7854045 > Fax: +39 06 91861099 > carlo.cavazzoni@telecomitalia.it > > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Eric Osborne (eosborne) > Sent: mercoled=EC 17 aprile 2013 14:16 > To: mpls@ietf.org > Subject: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00 > > This thread is for discussing draft-rhd-mpls-tp-psc-priority-00. In > brief, the draft proposes swapping the priorities between FS and SF-P (se= e > section 4.3.2 of rfc6378). This proposed swap has a long history, dating > back to when PSC was an ID. For some history, see > > http://datatracker.ietf.org/liaison/1229/ > and > http://datatracker.ietf.org/liaison/1234/ > > The questions that I think are relevant here are: > > - is it appropriate to make this priority swap? > - are there alternative approaches? > - what do we need to change? rfc5654? rfc4427? > - if we don't make the change, does this expose implementation to problem= s? > - if we do make the change, how do we go about it? > > but of course any and all discussion is welcome. > > As with the other threads I'm going to leave my two cents out of this > introductory email but I'll chime in when discussion starts. > > > > > > eric > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle > persone indicate. La diffusione, copia o qualsiasi altra azione derivante > dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualo= ra > abbiate ricevuto questo documento per errore siete cortesemente pregati d= i > darne immediata comunicazione al mittente e di provvedere alla sua > distruzione, Grazie. > > This e-mail and any attachments is confidential and may contain privilege= d > information intended for the addressee(s) only. Dissemination, copying, > printing or use by anybody else is unauthorised. If you are not the > intended recipient, please delete this message and any attachments and > advise the sender by return e-mail, Thanks. > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --047d7b342cb4e69c2f04dcea49ae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Carlo,

Why wouldn't the ne= twork operator in your example use a manual switch to protection instead of= a forced switch? =A0It gives exactly the desired behaviour for your scenar= io, does it not?

Consider this counter-example to your scena= rio: =A0what if the maintenance activity that is occurring on the working p= ath is *not* complete? =A0Suppose that the working path is technically up b= ut the maintenance team is running a long-term service activation test that= can take several hours. =A0From the perspective of BFD and PSC, the workin= g path is 'up' but from the operator's perspective, it's no= t ready for use (they're still testing and stressing the new transport = path). =A0A SF-P suddenly pushing the traffic back to the path that is unde= r test may be undesirable and in the worst case, could cause problems for o= ther transport paths especially in a packet-switched network. =A0We're = now pretty clearly in the murky world of double failures and I imagine diff= erent operators have different policies for how they want to handle this. = =A0I can see why Eric claims that some operators have asked for this change= .

One of the things that troubles me about ma= king the proposed change in priority is that we end up with no practicable = difference between FS-P and MS-P. =A0If I refer back to G.8031, one of the = differences between FS-P and MS-P is that MS-P will be overridden by a Sign= al Degrade but FS-P will not. =A0There seems to be a strong sense on the li= st that SD is not a meaningful condition that we can define for packet swit= ched networks. =A0So assuming that holds and we make this change, we'll= end up with literally no difference in behaviour between FS-P and MS-P.

I understand the implications that th= e ITU-T has pointed out that a FS could lead to a broken network but so cou= ld Lockout-of-Protection. =A0It seems to me that in either case of LO or FS= , you've made a conscious choice to run unprotected for some period of = time. =A0So buyer beware. =A0If that was not your intent, then use MS. =A0A= m I missing something here?

regards,
Pablo
<= div class=3D"gmail_extra">

On Tue, May 14= , 2013 at 11:08 AM, Cavazzoni Carlo <carlo.cavazzoni@teleco= mitalia.it> wrote:
Eric,

in order to clarify, from a network operator point of view, why I think the= SF-P must have higher priority than the FS-P I would make the following si= mple practical example.

For the execution of a programmed maintenance activity on one or more secti= ons of a MPLS-TP ring, all the connections routed on those sections have be= en moved to the protection paths with a FS-P command for a defined maintena= nce window timeframe. The maintenance work is typically done by a team diff= erent from that managing the MPLS-TP network: let's imagine maintenance= people complete the work well in advance with respect to the planned maint= enance window.
Unfortunately a failure (SF-P) happens before the end of the planned mainte= nance window timeframe, what happens?

a) =A0 =A0 =A0If SF-P has higher priority than FS-P then PSC moves the traf= fic back to the working path so recovering the connectivity in a short prot= ection switching time;
b) =A0 =A0 =A0If FS-P has higher priority than SF-P then the traffic remain= s on the broken connection and it will continue to be lost even when the wo= rking =A0path is up and running (i.e. at the latest at the end of the plann= ed maintenance window): it seems that only a manual (and slow) reconfigurat= ion of both protection endpoints from the management system could recover t= he normal working state.

Why do we have to define case b) as the standard behavior?
Are there use cases that suggest case b) as the preferred choice?

Hope this can help.

Regards,

Carlo

------------------------------------------------------------------
Telecom Italia
Carlo Cavazzoni
Transport Innovation
Via G. Reiss Romoli, 274 10148 Torino
+39 011 22857= 32
+39 335 78540= 45
Fax: +39 06 9= 1861099
carlo.cavazzoni@telecom= italia.it


-----Original Message-----
From: mpls-bounces@ietf.org [m= ailto:mpls-bounces@ietf.org] O= n Behalf Of Eric Osborne (eosborne)
Sent: mercoled=EC 17 aprile 2013 14:16
To: mpls@ietf.org
Subject: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00

This thread is for discussing draft-rhd-mpls-tp-psc-priority-00. =A0In brie= f, the draft proposes swapping the priorities between FS and SF-P (see sect= ion 4.3.2 of rfc6378). =A0This proposed swap has a long history, dating bac= k to when PSC was an ID. =A0For some history, see

htt= p://datatracker.ietf.org/liaison/1229/
and
htt= p://datatracker.ietf.org/liaison/1234/

The questions that I think are relevant here are:

- is it appropriate to make this priority swap?
=A0 - are there alternative approaches?
=A0 - what do we need to change? =A0rfc5654? =A0rfc4427?
- if we don't make the change, does this expose implementation to probl= ems?
- if we do make the change, how do we go about it?

but of course any and all discussion is welcome.

As with the other threads I'm going to leave my two cents out of this i= ntroductory email but I'll chime in when discussion starts.





eric
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

Questo messaggio e i suoi allegati son= o indirizzati esclusivamente alle persone indicate. La diffusione, copia o = qualsiasi altra azione derivante dalla conoscenza di queste informazioni so= no rigorosamente vietate. Qualora abbiate ricevuto questo documento per err= ore siete cortesemente pregati di darne immediata comunicazione al mittente= e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged = information intended for the addressee(s) only. Dissemination, copying, pri= nting or use by anybody else is unauthorised. If you are not the intended r= ecipient, please delete this message and any attachments and advise the sen= der by return e-mail, Thanks.

_____________________________= __________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--047d7b342cb4e69c2f04dcea49ae-- From ryoo@etri.re.kr Sat May 18 00:25:10 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5C121F922A for ; Sat, 18 May 2013 00:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9GWiG7uwdkx for ; Sat, 18 May 2013 00:25:05 -0700 (PDT) Received: from smtpeg.etri.re.kr (smtpeg1.etri.re.kr [129.254.27.141]) by ietfa.amsl.com (Postfix) with ESMTP id 97C9221F92D3 for ; Sat, 18 May 2013 00:25:03 -0700 (PDT) Received: from SMTP3.etri.info (129.254.28.73) by SMTPEG1.etri.info (129.254.27.141) with Microsoft SMTP Server (TLS) id 14.1.355.2; Sat, 18 May 2013 16:24:55 +0900 Received: from SMTP2.etri.info ([169.254.2.183]) by SMTP3.etri.info ([169.254.4.97]) with mapi id 14.01.0355.002; Sat, 18 May 2013 16:24:56 +0900 From: "Ryoo, Jeong-dong" To: Pablo Frank , Cavazzoni Carlo Thread-Topic: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00 Thread-Index: Ac47ZD1tB/jb+CaKQqOehjxMIOgzIgVT6XFAAIGZRIAANpFFvg== Date: Sat, 18 May 2013 07:24:56 +0000 Message-ID: <5B4A6CBE3924BB41A3BEE462A8E0B75A0DF28376@SMTP2.etri.info> References: <20ECF67871905846A80F77F8F4A2757210150296@xmb-rcd-x09.cisco.com> <05540BD841BBD643BB51404C4C9171521518059A97@GRFMBX703BA020.griffon.local>, In-Reply-To: Accept-Language: ko-KR, en-US Content-Language: ko-KR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-new-displayname: UnlvbywgSmVvbmctZG9uZw== x-originating-ip: [129.254.28.46] Content-Type: multipart/alternative; boundary="_000_5B4A6CBE3924BB41A3BEE462A8E0B75A0DF28376SMTP2etriinfo_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 May 2013 07:25:11 -0000 --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A0DF28376SMTP2etriinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UGFibG8sDQoNCkZTIGNvbW1hbmQgaXMgdXN1YWxseSBpc3N1ZWQgYmVmb3JlIGEgbmV0d29yayBv cGVyYXRvciBwZXJmb3JtcyBhbnkgbmV0d29yayBtYWludGVuYW5jZSBqb2JzIGZvciB0aGUgd29y a2luZyBwYXRoLCBzdWNoIGFzIHJlcGxhY2luZyBhIGNhYmxlLCBhbnkgY29tcG9uZW50cyBvZiBh IHN3aXRjaCwgb3IgdGhlIHN3aXRjaCBpdHNlbGYgb24gdGhlIHdvcmtpbmcgcGF0aC4gQWZ0ZXIg dGhlIG1haW50ZW5hbmNlIGpvYiwgdGhlIHRyYWZmaWMgY2FuIGdvIGJhY2sgdG8gdGhlIHdvcmtp bmcgcGF0aCBhbmQgcHJvdGVjdGlvbiBkb21haW4gY2FuIHJldHVybiB0byBub3JtYWwgYnkgdGhl IG5ldHdvcmsgb3BlcmF0b3IncyBjbGVhciBjb21tYW5kLg0KDQpJZiBNUyBpcyBpc3N1ZWQgYW5k IGEgY2FibGUgaXMgcHVsbGVkIG9mZiwgdGhlbiBTRi1XIHdpbGwgb2NjdXIuDQpOb3csIHRoaXMg U0YtVyB3aWxsIGJlIHRoZSB0b3AgcHJpb3JpdHkgcmVxdWVzdCBvbiB0aGUgcHJvdGVjdGlvbiBk b21haW4gYW5kIHdpbGwgZG9taW5hdGUgYW55IGZvbGxvd2luZyBwcm90ZWN0aW9uIGFjdGlvbnMs IHN1Y2ggYXMgcnVubmluZyBXVFIgdGltZXIsIHRyYWZmaWMgcmV2ZXJzaW9uIGFmdGVyIFdUUiB0 aW1lciBleHByaXJlcywgb3IgZW50ZXJpbmcgRE5SLCBldGMuDQoNCk1TIGFuZCBGUyBhcmUgZGlm ZmVyZW50IHJlZ2FyZGxlc3Mgb2YgU0QuDQoNCkJlc3QgcmVnYXJkcywNCg0KSmVvbmctZG9uZw0K DQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9tIDogIlBhYmxv IEZyYW5rIiA8cGFibG9pc25vdEBnbWFpbC5jb20+DQpTZW50IDogMjAxMy0wNS0xNyAyMjo1Mjoz MiAoICswOTowMCApDQpUbyA6IENhdmF6em9uaSBDYXJsbyA8Y2FybG8uY2F2YXp6b25pQHRlbGVj b21pdGFsaWEuaXQ+DQpDYyA6IG1wbHNAaWV0Zi5vcmcgPG1wbHNAaWV0Zi5vcmc+DQpTdWJqZWN0 IDogUmU6IFttcGxzXSBQU0M6IGRyYWZ0LXJoZC1tcGxzLXRwLXBzYy1wcmlvcml0eS0wMA0KDQpI aSBDYXJsbywNCg0KV2h5IHdvdWxkbid0IHRoZSBuZXR3b3JrIG9wZXJhdG9yIGluIHlvdXIgZXhh bXBsZSB1c2UgYSBtYW51YWwgc3dpdGNoIHRvIHByb3RlY3Rpb24gaW5zdGVhZCBvZiBhIGZvcmNl ZCBzd2l0Y2g/ICBJdCBnaXZlcyBleGFjdGx5IHRoZSBkZXNpcmVkIGJlaGF2aW91ciBmb3IgeW91 ciBzY2VuYXJpbywgZG9lcyBpdCBub3Q/DQoNCkNvbnNpZGVyIHRoaXMgY291bnRlci1leGFtcGxl IHRvIHlvdXIgc2NlbmFyaW86ICB3aGF0IGlmIHRoZSBtYWludGVuYW5jZSBhY3Rpdml0eSB0aGF0 IGlzIG9jY3VycmluZyBvbiB0aGUgd29ya2luZyBwYXRoIGlzICpub3QqIGNvbXBsZXRlPyAgU3Vw cG9zZSB0aGF0IHRoZSB3b3JraW5nIHBhdGggaXMgdGVjaG5pY2FsbHkgdXAgYnV0IHRoZSBtYWlu dGVuYW5jZSB0ZWFtIGlzIHJ1bm5pbmcgYSBsb25nLXRlcm0gc2VydmljZSBhY3RpdmF0aW9uIHRl c3QgdGhhdCBjYW4gdGFrZSBzZXZlcmFsIGhvdXJzLiAgRnJvbSB0aGUgcGVyc3BlY3RpdmUgb2Yg QkZEIGFuZCBQU0MsIHRoZSB3b3JraW5nIHBhdGggaXMgJ3VwJyBidXQgZnJvbSB0aGUgb3BlcmF0 b3IncyBwZXJzcGVjdGl2ZSwgaXQncyBub3QgcmVhZHkgZm9yIHVzZSAodGhleSdyZSBzdGlsbCB0 ZXN0aW5nIGFuZCBzdHJlc3NpbmcgdGhlIG5ldyB0cmFuc3BvcnQgcGF0aCkuICBBIFNGLVAgc3Vk ZGVubHkgcHVzaGluZyB0aGUgdHJhZmZpYyBiYWNrIHRvIHRoZSBwYXRoIHRoYXQgaXMgdW5kZXIg dGVzdCBtYXkgYmUgdW5kZXNpcmFibGUgYW5kIGluIHRoZSB3b3JzdCBjYXNlLCBjb3VsZCBjYXVz ZSBwcm9ibGVtcyBmb3Igb3RoZXIgdHJhbnNwb3J0IHBhdGhzIGVzcGVjaWFsbHkgaW4gYSBwYWNr ZXQtc3dpdGNoZWQgbmV0d29yay4gIFdlJ3JlIG5vdyBwcmV0dHkgY2xlYXJseSBpbiB0aGUgbXVy a3kgd29ybGQgb2YgZG91YmxlIGZhaWx1cmVzIGFuZCBJIGltYWdpbmUgZGlmZmVyZW50IG9wZXJh dG9ycyBoYXZlIGRpZmZlcmVudCBwb2xpY2llcyBmb3IgaG93IHRoZXkgd2FudCB0byBoYW5kbGUg dGhpcy4gIEkgY2FuIHNlZSB3aHkgRXJpYyBjbGFpbXMgdGhhdCBzb21lIG9wZXJhdG9ycyBoYXZl IGFza2VkIGZvciB0aGlzIGNoYW5nZS4NCg0KT25lIG9mIHRoZSB0aGluZ3MgdGhhdCB0cm91Ymxl cyBtZSBhYm91dCBtYWtpbmcgdGhlIHByb3Bvc2VkIGNoYW5nZSBpbiBwcmlvcml0eSBpcyB0aGF0 IHdlIGVuZCB1cCB3aXRoIG5vIHByYWN0aWNhYmxlIGRpZmZlcmVuY2UgYmV0d2VlbiBGUy1QIGFu ZCBNUy1QLiAgSWYgSSByZWZlciBiYWNrIHRvIEcuODAzMSwgb25lIG9mIHRoZSBkaWZmZXJlbmNl cyBiZXR3ZWVuIEZTLVAgYW5kIE1TLVAgaXMgdGhhdCBNUy1QIHdpbGwgYmUgb3ZlcnJpZGRlbiBi eSBhIFNpZ25hbCBEZWdyYWRlIGJ1dCBGUy1QIHdpbGwgbm90LiAgVGhlcmUgc2VlbXMgdG8gYmUg YSBzdHJvbmcgc2Vuc2Ugb24gdGhlIGxpc3QgdGhhdCBTRCBpcyBub3QgYSBtZWFuaW5nZnVsIGNv bmRpdGlvbiB0aGF0IHdlIGNhbiBkZWZpbmUgZm9yIHBhY2tldCBzd2l0Y2hlZCBuZXR3b3Jrcy4g IFNvIGFzc3VtaW5nIHRoYXQgaG9sZHMgYW5kIHdlIG1ha2UgdGhpcyBjaGFuZ2UsIHdlJ2xsIGVu ZCB1cCB3aXRoIGxpdGVyYWxseSBubyBkaWZmZXJlbmNlIGluIGJlaGF2aW91ciBiZXR3ZWVuIEZT LVAgYW5kIE1TLVAuDQoNCkkgdW5kZXJzdGFuZCB0aGUgaW1wbGljYXRpb25zIHRoYXQgdGhlIElU VS1UIGhhcyBwb2ludGVkIG91dCB0aGF0IGEgRlMgY291bGQgbGVhZCB0byBhIGJyb2tlbiBuZXR3 b3JrIGJ1dCBzbyBjb3VsZCBMb2Nrb3V0LW9mLVByb3RlY3Rpb24uICBJdCBzZWVtcyB0byBtZSB0 aGF0IGluIGVpdGhlciBjYXNlIG9mIExPIG9yIEZTLCB5b3UndmUgbWFkZSBhIGNvbnNjaW91cyBj aG9pY2UgdG8gcnVuIHVucHJvdGVjdGVkIGZvciBzb21lIHBlcmlvZCBvZiB0aW1lLiAgU28gYnV5 ZXIgYmV3YXJlLiAgSWYgdGhhdCB3YXMgbm90IHlvdXIgaW50ZW50LCB0aGVuIHVzZSBNUy4gIEFt IEkgbWlzc2luZyBzb21ldGhpbmcgaGVyZT8NCg0KcmVnYXJkcywNClBhYmxvDQoNCg0KT24gVHVl LCBNYXkgMTQsIDIwMTMgYXQgMTE6MDggQU0sIENhdmF6em9uaSBDYXJsbyA8Y2FybG8uY2F2YXp6 b25pQHRlbGVjb21pdGFsaWEuaXQ8bWFpbHRvOmNhcmxvLmNhdmF6em9uaUB0ZWxlY29taXRhbGlh Lml0Pj4gd3JvdGU6DQpFcmljLA0KDQppbiBvcmRlciB0byBjbGFyaWZ5LCBmcm9tIGEgbmV0d29y ayBvcGVyYXRvciBwb2ludCBvZiB2aWV3LCB3aHkgSSB0aGluayB0aGUgU0YtUCBtdXN0IGhhdmUg aGlnaGVyIHByaW9yaXR5IHRoYW4gdGhlIEZTLVAgSSB3b3VsZCBtYWtlIHRoZSBmb2xsb3dpbmcg c2ltcGxlIHByYWN0aWNhbCBleGFtcGxlLg0KDQpGb3IgdGhlIGV4ZWN1dGlvbiBvZiBhIHByb2dy YW1tZWQgbWFpbnRlbmFuY2UgYWN0aXZpdHkgb24gb25lIG9yIG1vcmUgc2VjdGlvbnMgb2YgYSBN UExTLVRQIHJpbmcsIGFsbCB0aGUgY29ubmVjdGlvbnMgcm91dGVkIG9uIHRob3NlIHNlY3Rpb25z IGhhdmUgYmVlbiBtb3ZlZCB0byB0aGUgcHJvdGVjdGlvbiBwYXRocyB3aXRoIGEgRlMtUCBjb21t YW5kIGZvciBhIGRlZmluZWQgbWFpbnRlbmFuY2Ugd2luZG93IHRpbWVmcmFtZS4gVGhlIG1haW50 ZW5hbmNlIHdvcmsgaXMgdHlwaWNhbGx5IGRvbmUgYnkgYSB0ZWFtIGRpZmZlcmVudCBmcm9tIHRo YXQgbWFuYWdpbmcgdGhlIE1QTFMtVFAgbmV0d29yazogbGV0J3MgaW1hZ2luZSBtYWludGVuYW5j ZSBwZW9wbGUgY29tcGxldGUgdGhlIHdvcmsgd2VsbCBpbiBhZHZhbmNlIHdpdGggcmVzcGVjdCB0 byB0aGUgcGxhbm5lZCBtYWludGVuYW5jZSB3aW5kb3cuDQpVbmZvcnR1bmF0ZWx5IGEgZmFpbHVy ZSAoU0YtUCkgaGFwcGVucyBiZWZvcmUgdGhlIGVuZCBvZiB0aGUgcGxhbm5lZCBtYWludGVuYW5j ZSB3aW5kb3cgdGltZWZyYW1lLCB3aGF0IGhhcHBlbnM/DQoNCmEpICAgICAgSWYgU0YtUCBoYXMg aGlnaGVyIHByaW9yaXR5IHRoYW4gRlMtUCB0aGVuIFBTQyBtb3ZlcyB0aGUgdHJhZmZpYyBiYWNr IHRvIHRoZSB3b3JraW5nIHBhdGggc28gcmVjb3ZlcmluZyB0aGUgY29ubmVjdGl2aXR5IGluIGEg c2hvcnQgcHJvdGVjdGlvbiBzd2l0Y2hpbmcgdGltZTsNCmIpICAgICAgSWYgRlMtUCBoYXMgaGln aGVyIHByaW9yaXR5IHRoYW4gU0YtUCB0aGVuIHRoZSB0cmFmZmljIHJlbWFpbnMgb24gdGhlIGJy b2tlbiBjb25uZWN0aW9uIGFuZCBpdCB3aWxsIGNvbnRpbnVlIHRvIGJlIGxvc3QgZXZlbiB3aGVu IHRoZSB3b3JraW5nICBwYXRoIGlzIHVwIGFuZCBydW5uaW5nIChpLmUuIGF0IHRoZSBsYXRlc3Qg YXQgdGhlIGVuZCBvZiB0aGUgcGxhbm5lZCBtYWludGVuYW5jZSB3aW5kb3cpOiBpdCBzZWVtcyB0 aGF0IG9ubHkgYSBtYW51YWwgKGFuZCBzbG93KSByZWNvbmZpZ3VyYXRpb24gb2YgYm90aCBwcm90 ZWN0aW9uIGVuZHBvaW50cyBmcm9tIHRoZSBtYW5hZ2VtZW50IHN5c3RlbSBjb3VsZCByZWNvdmVy IHRoZSBub3JtYWwgd29ya2luZyBzdGF0ZS4NCg0KV2h5IGRvIHdlIGhhdmUgdG8gZGVmaW5lIGNh c2UgYikgYXMgdGhlIHN0YW5kYXJkIGJlaGF2aW9yPw0KQXJlIHRoZXJlIHVzZSBjYXNlcyB0aGF0 IHN1Z2dlc3QgY2FzZSBiKSBhcyB0aGUgcHJlZmVycmVkIGNob2ljZT8NCg0KSG9wZSB0aGlzIGNh biBoZWxwLg0KDQpSZWdhcmRzLA0KDQpDYXJsbw0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRlbGVjb20gSXRhbGlh DQpDYXJsbyBDYXZhenpvbmkNClRyYW5zcG9ydCBJbm5vdmF0aW9uDQpWaWEgRy4gUmVpc3MgUm9t b2xpLCAyNzQgMTAxNDggVG9yaW5vDQorMzkgMDExIDIyODU3MzI8dGVsOiUyQjM5JTIwMDExJTIw MjI4NTczMj4NCiszOSAzMzUgNzg1NDA0NTx0ZWw6JTJCMzklMjAzMzUlMjA3ODU0MDQ1Pg0KRmF4 OiArMzkgMDYgOTE4NjEwOTk8dGVsOiUyQjM5JTIwMDYlMjA5MTg2MTA5OT4NCmNhcmxvLmNhdmF6 em9uaUB0ZWxlY29taXRhbGlhLml0PG1haWx0bzpjYXJsby5jYXZhenpvbmlAdGVsZWNvbWl0YWxp YS5pdD4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogbXBscy1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86bXBscy1ib3Vu Y2VzQGlldGYub3JnPG1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2Yg RXJpYyBPc2Jvcm5lIChlb3Nib3JuZSkNClNlbnQ6IG1lcmNvbGVkw6wgMTcgYXByaWxlIDIwMTMg MTQ6MTYNClRvOiBtcGxzQGlldGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPg0KU3ViamVjdDog W21wbHNdIFBTQzogZHJhZnQtcmhkLW1wbHMtdHAtcHNjLXByaW9yaXR5LTAwDQoNClRoaXMgdGhy ZWFkIGlzIGZvciBkaXNjdXNzaW5nIGRyYWZ0LXJoZC1tcGxzLXRwLXBzYy1wcmlvcml0eS0wMC4g IEluIGJyaWVmLCB0aGUgZHJhZnQgcHJvcG9zZXMgc3dhcHBpbmcgdGhlIHByaW9yaXRpZXMgYmV0 d2VlbiBGUyBhbmQgU0YtUCAoc2VlIHNlY3Rpb24gNC4zLjIgb2YgcmZjNjM3OCkuICBUaGlzIHBy b3Bvc2VkIHN3YXAgaGFzIGEgbG9uZyBoaXN0b3J5LCBkYXRpbmcgYmFjayB0byB3aGVuIFBTQyB3 YXMgYW4gSUQuICBGb3Igc29tZSBoaXN0b3J5LCBzZWUNCg0KaHR0cDovL2RhdGF0cmFja2VyLmll dGYub3JnL2xpYWlzb24vMTIyOS8NCmFuZA0KaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2xp YWlzb24vMTIzNC8NCg0KVGhlIHF1ZXN0aW9ucyB0aGF0IEkgdGhpbmsgYXJlIHJlbGV2YW50IGhl cmUgYXJlOg0KDQotIGlzIGl0IGFwcHJvcHJpYXRlIHRvIG1ha2UgdGhpcyBwcmlvcml0eSBzd2Fw Pw0KICAtIGFyZSB0aGVyZSBhbHRlcm5hdGl2ZSBhcHByb2FjaGVzPw0KICAtIHdoYXQgZG8gd2Ug bmVlZCB0byBjaGFuZ2U/ICByZmM1NjU0PyAgcmZjNDQyNz8NCi0gaWYgd2UgZG9uJ3QgbWFrZSB0 aGUgY2hhbmdlLCBkb2VzIHRoaXMgZXhwb3NlIGltcGxlbWVudGF0aW9uIHRvIHByb2JsZW1zPw0K LSBpZiB3ZSBkbyBtYWtlIHRoZSBjaGFuZ2UsIGhvdyBkbyB3ZSBnbyBhYm91dCBpdD8NCg0KYnV0 IG9mIGNvdXJzZSBhbnkgYW5kIGFsbCBkaXNjdXNzaW9uIGlzIHdlbGNvbWUuDQoNCkFzIHdpdGgg dGhlIG90aGVyIHRocmVhZHMgSSdtIGdvaW5nIHRvIGxlYXZlIG15IHR3byBjZW50cyBvdXQgb2Yg dGhpcyBpbnRyb2R1Y3RvcnkgZW1haWwgYnV0IEknbGwgY2hpbWUgaW4gd2hlbiBkaXNjdXNzaW9u IHN0YXJ0cy4NCg0KDQoNCg0KDQplcmljDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5vcmc8bWFpbHRv Om1wbHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21w bHMNCg0KUXVlc3RvIG1lc3NhZ2dpbyBlIGkgc3VvaSBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRp IGVzY2x1c2l2YW1lbnRlIGFsbGUgcGVyc29uZSBpbmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwgY29w aWEgbyBxdWFsc2lhc2kgYWx0cmEgYXppb25lIGRlcml2YW50ZSBkYWxsYSBjb25vc2NlbnphIGRp IHF1ZXN0ZSBpbmZvcm1hemlvbmkgc29ubyByaWdvcm9zYW1lbnRlIHZpZXRhdGUuIFF1YWxvcmEg YWJiaWF0ZSByaWNldnV0byBxdWVzdG8gZG9jdW1lbnRvIHBlciBlcnJvcmUgc2lldGUgY29ydGVz ZW1lbnRlIHByZWdhdGkgZGkgZGFybmUgaW1tZWRpYXRhIGNvbXVuaWNhemlvbmUgYWwgbWl0dGVu dGUgZSBkaSBwcm92dmVkZXJlIGFsbGEgc3VhIGRpc3RydXppb25lLCBHcmF6aWUuDQoNClRoaXMg ZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFp biBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9u bHkuIERpc3NlbWluYXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVs c2UgaXMgdW5hdXRob3Jpc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LCBwbGVhc2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZp c2UgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsLCBUaGFua3MuDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBs c0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbXBscw0KDQo= --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A0DF28376SMTP2etriinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5QIHtNQVJHSU4tVE9QOiAwbW07IE1B UkdJTi1CT1RUT006IDBtbX08L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHk+DQo8ZGl2IHN0eWxlPSJG T05ULUZBTUlMWTogQXJpYWw7IEZPTlQtU0laRTogMTBwdCIgaWQ9ImV6Rm9ybVByb2NfZGl2Ij4N CjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBBcmlhbCIgaWQ9Im1zZ2JvZHkiPg0KPGRpdj4NCjxk aXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij5QYWJsbyw8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJ TkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAx NXB0Ij5GUyBjb21tYW5kIGlzIHVzdWFsbHkgaXNzdWVkIGJlZm9yZSZuYnNwO2EgbmV0d29yayBv cGVyYXRvciBwZXJmb3JtcyBhbnkgbmV0d29yayZuYnNwO21haW50ZW5hbmNlIGpvYnMgZm9yIHRo ZSB3b3JraW5nIHBhdGgsIHN1Y2ggYXMgcmVwbGFjaW5nJm5ic3A7YSBjYWJsZSwgYW55IGNvbXBv bmVudHMgb2YgYSZuYnNwO3N3aXRjaCwgb3IgdGhlIHN3aXRjaCBpdHNlbGYmbmJzcDtvbiB0aGUg d29ya2luZyBwYXRoLiBBZnRlciB0aGUgbWFpbnRlbmFuY2UNCiBqb2IsIHRoZSB0cmFmZmljIGNh biBnbyBiYWNrIHRvIHRoZSB3b3JraW5nIHBhdGggYW5kIHByb3RlY3Rpb24gZG9tYWluIGNhbiBy ZXR1cm4gdG8gbm9ybWFsIGJ5Jm5ic3A7dGhlJm5ic3A7bmV0d29yayBvcGVyYXRvcidzIGNsZWFy IGNvbW1hbmQuJm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+Jm5i c3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+SWYgTVMmbmJzcDtpcyBp c3N1ZWQgYW5kIGEgY2FibGUgaXMgcHVsbGVkIG9mZiwgdGhlbiBTRi1XIHdpbGwgb2NjdXIuPC9k aXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+Tm93LCB0aGlzIFNGLVcgd2lsbCBi ZSB0aGUgdG9wIHByaW9yaXR5IHJlcXVlc3Qgb24gdGhlIHByb3RlY3Rpb24gZG9tYWluIGFuZCB3 aWxsIGRvbWluYXRlJm5ic3A7YW55IGZvbGxvd2luZyZuYnNwO3Byb3RlY3Rpb24gYWN0aW9ucywg c3VjaCBhcyZuYnNwO3J1bm5pbmcgV1RSJm5ic3A7dGltZXIsIHRyYWZmaWMgcmV2ZXJzaW9uIGFm dGVyIFdUUiB0aW1lciBleHByaXJlcywgb3IgZW50ZXJpbmcgRE5SLCBldGMuPC9kaXY+DQo8ZGl2 IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5F LUhFSUdIVDogMTVwdCI+TVMgYW5kIEZTIGFyZSZuYnNwO2RpZmZlcmVudCByZWdhcmRsZXNzIG9m IFNELjwvZGl2Pg0KPGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPiZuYnNwOzwvZGl2Pg0K PGRpdiBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiPkJlc3QgcmVnYXJkcyw8L2Rpdj4NCjxkaXYg c3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4mbmJzcDs8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUt SEVJR0hUOiAxNXB0Ij5KZW9uZy1kb25nPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDog MTVwdCI+Jm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+PGJyPg0K PGJyPg0KJm5ic3A7PC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCIgaWQ9Ik1h aWxTaWduIj48YnI+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9IkxJTkUtSEVJR0hUOiAxNXB0Ij4NCjxo ciB0YWJpbmRleD0iLTEiPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJMSU5FLUhFSUdIVDogMTVwdCI+ PGI+RnJvbSA6IDwvYj4mcXVvdDtQYWJsbyBGcmFuayZxdW90OyAmbHQ7cGFibG9pc25vdEBnbWFp bC5jb20mZ3Q7PGJyPg0KPGI+U2VudCA6IDwvYj4yMDEzLTA1LTE3IDIyOjUyOjMyICggJiM0Mzsw OTowMCApPGJyPg0KPGI+VG8gOiA8L2I+Q2F2YXp6b25pIENhcmxvICZsdDtjYXJsby5jYXZhenpv bmlAdGVsZWNvbWl0YWxpYS5pdCZndDs8YnI+DQo8Yj5DYyA6IDwvYj5tcGxzQGlldGYub3JnICZs dDttcGxzQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3QgOiA8L2I+UmU6IFttcGxzXSBQU0M6 IGRyYWZ0LXJoZC1tcGxzLXRwLXBzYy1wcmlvcml0eS0wMDxicj4NCjxicj4NCjwvZGl2Pg0KPGRp diBzdHlsZT0iTElORS1IRUlHSFQ6IDE1cHQiIGRpcj0ibHRyIj5IaSBDYXJsbywNCjxkaXY+PGJy Pg0KPC9kaXY+DQo8ZGl2PldoeSB3b3VsZG4ndCB0aGUgbmV0d29yayBvcGVyYXRvciBpbiB5b3Vy IGV4YW1wbGUgdXNlIGEgbWFudWFsIHN3aXRjaCB0byBwcm90ZWN0aW9uIGluc3RlYWQgb2YgYSBm b3JjZWQgc3dpdGNoPyAmbmJzcDtJdCBnaXZlcyBleGFjdGx5IHRoZSBkZXNpcmVkIGJlaGF2aW91 ciBmb3IgeW91ciBzY2VuYXJpbywgZG9lcyBpdCBub3Q/PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGRpdj5Db25zaWRlciB0aGlzIGNvdW50ZXItZXhhbXBsZSB0byB5b3VyIHNjZW5hcmlvOiAm bmJzcDt3aGF0IGlmIHRoZSBtYWludGVuYW5jZSBhY3Rpdml0eSB0aGF0IGlzIG9jY3VycmluZyBv biB0aGUgd29ya2luZyBwYXRoIGlzICpub3QqIGNvbXBsZXRlPyAmbmJzcDtTdXBwb3NlIHRoYXQg dGhlIHdvcmtpbmcgcGF0aCBpcyB0ZWNobmljYWxseSB1cCBidXQgdGhlIG1haW50ZW5hbmNlIHRl YW0gaXMgcnVubmluZyBhIGxvbmctdGVybSBzZXJ2aWNlIGFjdGl2YXRpb24NCiB0ZXN0IHRoYXQg Y2FuIHRha2Ugc2V2ZXJhbCBob3Vycy4gJm5ic3A7RnJvbSB0aGUgcGVyc3BlY3RpdmUgb2YgQkZE IGFuZCBQU0MsIHRoZSB3b3JraW5nIHBhdGggaXMgJ3VwJyBidXQgZnJvbSB0aGUgb3BlcmF0b3In cyBwZXJzcGVjdGl2ZSwgaXQncyBub3QgcmVhZHkgZm9yIHVzZSAodGhleSdyZSBzdGlsbCB0ZXN0 aW5nIGFuZCBzdHJlc3NpbmcgdGhlIG5ldyB0cmFuc3BvcnQgcGF0aCkuICZuYnNwO0EgU0YtUCBz dWRkZW5seSBwdXNoaW5nIHRoZSB0cmFmZmljDQogYmFjayB0byB0aGUgcGF0aCB0aGF0IGlzIHVu ZGVyIHRlc3QgbWF5IGJlIHVuZGVzaXJhYmxlIGFuZCBpbiB0aGUgd29yc3QgY2FzZSwgY291bGQg Y2F1c2UgcHJvYmxlbXMgZm9yIG90aGVyIHRyYW5zcG9ydCBwYXRocyBlc3BlY2lhbGx5IGluIGEg cGFja2V0LXN3aXRjaGVkIG5ldHdvcmsuICZuYnNwO1dlJ3JlIG5vdyBwcmV0dHkgY2xlYXJseSBp biB0aGUgbXVya3kgd29ybGQgb2YgZG91YmxlIGZhaWx1cmVzIGFuZCBJIGltYWdpbmUgZGlmZmVy ZW50IG9wZXJhdG9ycw0KIGhhdmUgZGlmZmVyZW50IHBvbGljaWVzIGZvciBob3cgdGhleSB3YW50 IHRvIGhhbmRsZSB0aGlzLiAmbmJzcDtJIGNhbiBzZWUgd2h5IEVyaWMgY2xhaW1zIHRoYXQgc29t ZSBvcGVyYXRvcnMgaGF2ZSBhc2tlZCBmb3IgdGhpcyBjaGFuZ2UuPC9kaXY+DQo8ZGl2Pjxicj4N CjwvZGl2Pg0KPGRpdj5PbmUgb2YgdGhlIHRoaW5ncyB0aGF0IHRyb3VibGVzIG1lIGFib3V0IG1h a2luZyB0aGUgcHJvcG9zZWQgY2hhbmdlIGluIHByaW9yaXR5IGlzIHRoYXQgd2UgZW5kIHVwIHdp dGggbm8gcHJhY3RpY2FibGUgZGlmZmVyZW5jZSBiZXR3ZWVuIEZTLVAgYW5kIE1TLVAuICZuYnNw O0lmIEkgcmVmZXIgYmFjayB0byBHLjgwMzEsIG9uZSBvZiB0aGUgZGlmZmVyZW5jZXMgYmV0d2Vl biBGUy1QIGFuZCBNUy1QIGlzIHRoYXQgTVMtUCB3aWxsIGJlIG92ZXJyaWRkZW4NCiBieSBhIFNp Z25hbCBEZWdyYWRlIGJ1dCBGUy1QIHdpbGwgbm90LiAmbmJzcDtUaGVyZSBzZWVtcyB0byBiZSBh IHN0cm9uZyBzZW5zZSBvbiB0aGUgbGlzdCB0aGF0IFNEIGlzIG5vdCBhIG1lYW5pbmdmdWwgY29u ZGl0aW9uIHRoYXQgd2UgY2FuIGRlZmluZSBmb3IgcGFja2V0IHN3aXRjaGVkIG5ldHdvcmtzLiAm bmJzcDtTbyBhc3N1bWluZyB0aGF0IGhvbGRzIGFuZCB3ZSBtYWtlIHRoaXMgY2hhbmdlLCB3ZSds bCBlbmQgdXAgd2l0aCBsaXRlcmFsbHkgbm8gZGlmZmVyZW5jZQ0KIGluIGJlaGF2aW91ciBiZXR3 ZWVuIEZTLVAgYW5kIE1TLVAuPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5J IHVuZGVyc3RhbmQgdGhlIGltcGxpY2F0aW9ucyB0aGF0IHRoZSBJVFUtVCBoYXMgcG9pbnRlZCBv dXQgdGhhdCBhIEZTIGNvdWxkIGxlYWQgdG8gYSBicm9rZW4gbmV0d29yayBidXQgc28gY291bGQg TG9ja291dC1vZi1Qcm90ZWN0aW9uLiAmbmJzcDtJdCBzZWVtcyB0byBtZSB0aGF0IGluIGVpdGhl ciBjYXNlIG9mIExPIG9yIEZTLCB5b3UndmUgbWFkZSBhIGNvbnNjaW91cyBjaG9pY2UgdG8gcnVu IHVucHJvdGVjdGVkIGZvciBzb21lIHBlcmlvZA0KIG9mIHRpbWUuICZuYnNwO1NvIGJ1eWVyIGJl d2FyZS4gJm5ic3A7SWYgdGhhdCB3YXMgbm90IHlvdXIgaW50ZW50LCB0aGVuIHVzZSBNUy4gJm5i c3A7QW0gSSBtaXNzaW5nIHNvbWV0aGluZyBoZXJlPzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+cmVnYXJkcyw8L2Rpdj4NCjxkaXY+UGFibG88L2Rpdj4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0iTElORS1IRUlHSFQ6IDE1cHQiIGNsYXNzPSJnbWFpbF9leHRyYSI+PGJyPg0KPGJyPg0KPGRp diBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIFR1ZSwgTWF5IDE0LCAyMDEzIGF0IDExOjA4IEFNLCBD YXZhenpvbmkgQ2FybG8gPHNwYW4gZGlyPSJsdHIiPg0KJmx0OzxhIGhyZWY9Im1haWx0bzpjYXJs by5jYXZhenpvbmlAdGVsZWNvbWl0YWxpYS5pdCIgdGFyZ2V0PSJfYmxhbmsiPmNhcmxvLmNhdmF6 em9uaUB0ZWxlY29taXRhbGlhLml0PC9hPiZndDs8L3NwYW4+IHdyb3RlOjxicj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJCT1JERVItTEVGVDogI2NjYyAxcHggc29saWQ7IE1BUkdJTjogMHB4IDBweCAw cHggMC44ZXg7IFBBRERJTkctTEVGVDogMWV4IiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KRXJpYyw8 YnI+DQo8YnI+DQppbiBvcmRlciB0byBjbGFyaWZ5LCBmcm9tIGEgbmV0d29yayBvcGVyYXRvciBw b2ludCBvZiB2aWV3LCB3aHkgSSB0aGluayB0aGUgU0YtUCBtdXN0IGhhdmUgaGlnaGVyIHByaW9y aXR5IHRoYW4gdGhlIEZTLVAgSSB3b3VsZCBtYWtlIHRoZSBmb2xsb3dpbmcgc2ltcGxlIHByYWN0 aWNhbCBleGFtcGxlLjxicj4NCjxicj4NCkZvciB0aGUgZXhlY3V0aW9uIG9mIGEgcHJvZ3JhbW1l ZCBtYWludGVuYW5jZSBhY3Rpdml0eSBvbiBvbmUgb3IgbW9yZSBzZWN0aW9ucyBvZiBhIE1QTFMt VFAgcmluZywgYWxsIHRoZSBjb25uZWN0aW9ucyByb3V0ZWQgb24gdGhvc2Ugc2VjdGlvbnMgaGF2 ZSBiZWVuIG1vdmVkIHRvIHRoZSBwcm90ZWN0aW9uIHBhdGhzIHdpdGggYSBGUy1QIGNvbW1hbmQg Zm9yIGEgZGVmaW5lZCBtYWludGVuYW5jZSB3aW5kb3cgdGltZWZyYW1lLiBUaGUgbWFpbnRlbmFu Y2UNCiB3b3JrIGlzIHR5cGljYWxseSBkb25lIGJ5IGEgdGVhbSBkaWZmZXJlbnQgZnJvbSB0aGF0 IG1hbmFnaW5nIHRoZSBNUExTLVRQIG5ldHdvcms6IGxldCdzIGltYWdpbmUgbWFpbnRlbmFuY2Ug cGVvcGxlIGNvbXBsZXRlIHRoZSB3b3JrIHdlbGwgaW4gYWR2YW5jZSB3aXRoIHJlc3BlY3QgdG8g dGhlIHBsYW5uZWQgbWFpbnRlbmFuY2Ugd2luZG93Ljxicj4NClVuZm9ydHVuYXRlbHkgYSBmYWls dXJlIChTRi1QKSBoYXBwZW5zIGJlZm9yZSB0aGUgZW5kIG9mIHRoZSBwbGFubmVkIG1haW50ZW5h bmNlIHdpbmRvdyB0aW1lZnJhbWUsIHdoYXQgaGFwcGVucz88YnI+DQo8YnI+DQphKSAmbmJzcDsg Jm5ic3A7ICZuYnNwO0lmIFNGLVAgaGFzIGhpZ2hlciBwcmlvcml0eSB0aGFuIEZTLVAgdGhlbiBQ U0MgbW92ZXMgdGhlIHRyYWZmaWMgYmFjayB0byB0aGUgd29ya2luZyBwYXRoIHNvIHJlY292ZXJp bmcgdGhlIGNvbm5lY3Rpdml0eSBpbiBhIHNob3J0IHByb3RlY3Rpb24gc3dpdGNoaW5nIHRpbWU7 PGJyPg0KYikgJm5ic3A7ICZuYnNwOyAmbmJzcDtJZiBGUy1QIGhhcyBoaWdoZXIgcHJpb3JpdHkg dGhhbiBTRi1QIHRoZW4gdGhlIHRyYWZmaWMgcmVtYWlucyBvbiB0aGUgYnJva2VuIGNvbm5lY3Rp b24gYW5kIGl0IHdpbGwgY29udGludWUgdG8gYmUgbG9zdCBldmVuIHdoZW4gdGhlIHdvcmtpbmcg Jm5ic3A7cGF0aCBpcyB1cCBhbmQgcnVubmluZyAoaS5lLiBhdCB0aGUgbGF0ZXN0IGF0IHRoZSBl bmQgb2YgdGhlIHBsYW5uZWQgbWFpbnRlbmFuY2Ugd2luZG93KTogaXQgc2VlbXMgdGhhdCBvbmx5 DQogYSBtYW51YWwgKGFuZCBzbG93KSByZWNvbmZpZ3VyYXRpb24gb2YgYm90aCBwcm90ZWN0aW9u IGVuZHBvaW50cyBmcm9tIHRoZSBtYW5hZ2VtZW50IHN5c3RlbSBjb3VsZCByZWNvdmVyIHRoZSBu b3JtYWwgd29ya2luZyBzdGF0ZS48YnI+DQo8YnI+DQpXaHkgZG8gd2UgaGF2ZSB0byBkZWZpbmUg Y2FzZSBiKSBhcyB0aGUgc3RhbmRhcmQgYmVoYXZpb3I/PGJyPg0KQXJlIHRoZXJlIHVzZSBjYXNl cyB0aGF0IHN1Z2dlc3QgY2FzZSBiKSBhcyB0aGUgcHJlZmVycmVkIGNob2ljZT88YnI+DQo8YnI+ DQpIb3BlIHRoaXMgY2FuIGhlbHAuPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQo8YnI+DQpDYXJs bzxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NClRlbGVjb20gSXRhbGlhPGJyPg0KPHNwYW4gY2xh c3M9IkhPRW5aYiI+PGZvbnQgY29sb3I9IiM4ODg4ODgiPkNhcmxvIENhdmF6em9uaTxicj4NClRy YW5zcG9ydCBJbm5vdmF0aW9uPGJyPg0KVmlhIEcuIFJlaXNzIFJvbW9saSwgMjc0IDEwMTQ4IFRv cmlubzxicj4NCjxhIGhyZWY9InRlbDolMkIzOSUyMDAxMSUyMDIyODU3MzIiIHRhcmdldD0iX2Js YW5rIiB2YWx1ZT0iJiM0MzszOTAxMTIyODU3MzIiPiYjNDM7MzkgMDExIDIyODU3MzI8L2E+PGJy Pg0KPGEgaHJlZj0idGVsOiUyQjM5JTIwMzM1JTIwNzg1NDA0NSIgdGFyZ2V0PSJfYmxhbmsiIHZh bHVlPSImIzQzOzM5MzM1Nzg1NDA0NSI+JiM0MzszOSAzMzUgNzg1NDA0NTwvYT48YnI+DQpGYXg6 IDxhIGhyZWY9InRlbDolMkIzOSUyMDA2JTIwOTE4NjEwOTkiIHRhcmdldD0iX2JsYW5rIiB2YWx1 ZT0iJiM0MzszOTA2OTE4NjEwOTkiPiYjNDM7MzkgMDYgOTE4NjEwOTk8L2E+PGJyPg0KPGEgaHJl Zj0ibWFpbHRvOmNhcmxvLmNhdmF6em9uaUB0ZWxlY29taXRhbGlhLml0IiB0YXJnZXQ9Il9ibGFu ayI+Y2FybG8uY2F2YXp6b25pQHRlbGVjb21pdGFsaWEuaXQ8L2E+PGJyPg0KPC9mb250Pjwvc3Bh bj4NCjxkaXYgY2xhc3M9IkhPRW5aYiI+DQo8ZGl2IGNsYXNzPSJoNSI+PGJyPg0KPGJyPg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiA8YSBocmVmPSJtYWlsdG86bXBscy1i b3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bXBscy1ib3VuY2VzQGlldGYub3JnPC9h PiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5tcGxzLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgRXJpYyBPc2Jv cm5lIChlb3Nib3JuZSk8YnI+DQpTZW50OiBtZXJjb2xlZMOsIDE3IGFwcmlsZSAyMDEzIDE0OjE2 PGJyPg0KVG86IDxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ bXBsc0BpZXRmLm9yZzwvYT48YnI+DQpTdWJqZWN0OiBbbXBsc10gUFNDOiBkcmFmdC1yaGQtbXBs cy10cC1wc2MtcHJpb3JpdHktMDA8YnI+DQo8YnI+DQpUaGlzIHRocmVhZCBpcyBmb3IgZGlzY3Vz c2luZyBkcmFmdC1yaGQtbXBscy10cC1wc2MtcHJpb3JpdHktMDAuICZuYnNwO0luIGJyaWVmLCB0 aGUgZHJhZnQgcHJvcG9zZXMgc3dhcHBpbmcgdGhlIHByaW9yaXRpZXMgYmV0d2VlbiBGUyBhbmQg U0YtUCAoc2VlIHNlY3Rpb24gNC4zLjIgb2YgcmZjNjM3OCkuICZuYnNwO1RoaXMgcHJvcG9zZWQg c3dhcCBoYXMgYSBsb25nIGhpc3RvcnksIGRhdGluZyBiYWNrIHRvIHdoZW4gUFNDIHdhcyBhbiBJ RC4gJm5ic3A7Rm9yIHNvbWUgaGlzdG9yeSwNCiBzZWU8YnI+DQo8YnI+DQo8YSBocmVmPSJodHRw Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbGlhaXNvbi8xMjI5LyIgdGFyZ2V0PSJfYmxhbmsiPmh0 dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzEyMjkvPC9hPjxicj4NCmFuZDxicj4N CjxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzEyMzQvIiB0YXJn ZXQ9Il9ibGFuayI+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2xpYWlzb24vMTIzNC88L2E+ PGJyPg0KPGJyPg0KVGhlIHF1ZXN0aW9ucyB0aGF0IEkgdGhpbmsgYXJlIHJlbGV2YW50IGhlcmUg YXJlOjxicj4NCjxicj4NCi0gaXMgaXQgYXBwcm9wcmlhdGUgdG8gbWFrZSB0aGlzIHByaW9yaXR5 IHN3YXA/PGJyPg0KJm5ic3A7IC0gYXJlIHRoZXJlIGFsdGVybmF0aXZlIGFwcHJvYWNoZXM/PGJy Pg0KJm5ic3A7IC0gd2hhdCBkbyB3ZSBuZWVkIHRvIGNoYW5nZT8gJm5ic3A7cmZjNTY1ND8gJm5i c3A7cmZjNDQyNz88YnI+DQotIGlmIHdlIGRvbid0IG1ha2UgdGhlIGNoYW5nZSwgZG9lcyB0aGlz IGV4cG9zZSBpbXBsZW1lbnRhdGlvbiB0byBwcm9ibGVtcz88YnI+DQotIGlmIHdlIGRvIG1ha2Ug dGhlIGNoYW5nZSwgaG93IGRvIHdlIGdvIGFib3V0IGl0Pzxicj4NCjxicj4NCmJ1dCBvZiBjb3Vy c2UgYW55IGFuZCBhbGwgZGlzY3Vzc2lvbiBpcyB3ZWxjb21lLjxicj4NCjxicj4NCkFzIHdpdGgg dGhlIG90aGVyIHRocmVhZHMgSSdtIGdvaW5nIHRvIGxlYXZlIG15IHR3byBjZW50cyBvdXQgb2Yg dGhpcyBpbnRyb2R1Y3RvcnkgZW1haWwgYnV0IEknbGwgY2hpbWUgaW4gd2hlbiBkaXNjdXNzaW9u IHN0YXJ0cy48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQplcmljPGJyPg0KX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQptcGxzIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzptcGxzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+bXBsc0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL21wbHMiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHM8L2E+PGJyPg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9ImltIEhPRW5aYiI+UXVlc3RvIG1lc3NhZ2dpbyBlIGkgc3VvaSBhbGxlZ2F0 aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1c2l2YW1lbnRlIGFsbGUgcGVyc29uZSBpbmRpY2F0ZS4g TGEgZGlmZnVzaW9uZSwgY29waWEgbyBxdWFsc2lhc2kgYWx0cmEgYXppb25lIGRlcml2YW50ZSBk YWxsYSBjb25vc2NlbnphIGRpIHF1ZXN0ZSBpbmZvcm1hemlvbmkgc29ubyByaWdvcm9zYW1lbnRl IHZpZXRhdGUuIFF1YWxvcmEgYWJiaWF0ZSByaWNldnV0bw0KIHF1ZXN0byBkb2N1bWVudG8gcGVy IGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29t dW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlv bmUsIEdyYXppZS48YnI+DQo8YnI+DQpUaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRzIGlz IGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRl bmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBw cmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFy ZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UN CiBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNlbmRlciBieSByZXR1cm4gZS1t YWlsLCBUaGFua3MuPGJyPg0KPGJyPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSJIT0VuWmIiPg0KPGRp diBjbGFzcz0iaDUiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KbXBscyBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1wbHNAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzPC9hPjxicj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxicj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_5B4A6CBE3924BB41A3BEE462A8E0B75A0DF28376SMTP2etriinfo_-- From sriganeshkini@gmail.com Sun May 19 18:39:09 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B2A21F8ED8 for ; Sun, 19 May 2013 18:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.311 X-Spam-Level: X-Spam-Status: No, score=-0.311 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ny2EIiALS1Kc for ; Sun, 19 May 2013 18:39:09 -0700 (PDT) Received: from mail-da0-x234.google.com (mail-da0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 17A6421F8ECB for ; Sun, 19 May 2013 18:39:08 -0700 (PDT) Received: by mail-da0-f52.google.com with SMTP id o9so3526665dan.25 for ; Sun, 19 May 2013 18:39:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=skpaD9F+uugb3ktHS1m76/kBA96rrWkNyMc+PG30Y/8=; b=exHLVBsRLWw0lG5CH0edrEk3RRUkgVuqEbQs+SockMRvSqr1C30TPW5EAwdLTn8a8/ VZnAeme+yMe/o/aQZdbsqICdmFWaWZJX1Vi42vKSaVa2WmgKJLSET/giX3RnsndOjjUW qpCdeF1niCtHsjrFsjnwTSfEi1tXmIbX/PVcpirysybKxcWUj6lzmWvc9o7OuKPkHp4F YJ21jrUVzxlFk3QYfg8f8IFH0w4CNWw65fxvrh9K8q79hrImQc0MOWN7IZIumFM1yYzG TM+xMF+v+tWe/3GWoUSNaOlxI8Dd7qVh4j6KW5Y3JkmgMAsHL8qt8WHO69QABmDOFkhp 1CTg== X-Received: by 10.66.121.169 with SMTP id ll9mr58473929pab.126.1369013948721; Sun, 19 May 2013 18:39:08 -0700 (PDT) MIME-Version: 1.0 Sender: sriganeshkini@gmail.com Received: by 10.70.17.161 with HTTP; Sun, 19 May 2013 18:38:37 -0700 (PDT) In-Reply-To: <51951C17.8010906@pi.nu> References: <51951C17.8010906@pi.nu> From: Sriganesh Kini Date: Sun, 19 May 2013 18:38:37 -0700 X-Google-Sender-Auth: LCe5D5FAr4STpBIS4mkvNDj6sMc Message-ID: To: Loa Andersson Content-Type: multipart/alternative; boundary=047d7b2e4fa41b2ff804dd1c66f8 Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-jjb-mpls-rsvp-te-hsmp-lsp@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus to make draft-jjb-mpls-rsvp-te-hsmp-lsp an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 01:39:09 -0000 --047d7b2e4fa41b2ff804dd1c66f8 Content-Type: text/plain; charset=UTF-8 Support (as co-author). - Sri On Thu, May 16, 2013 at 10:49 AM, Loa Andersson wrote: > Working Group, > > This is to start a two week poll on adopting > draft-jjb-mpls-rsvp-te-hsmp-**lsp-04 as an MPLS working > group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > This poll ends May 31, 2013. > > There are one IPR claim against this document, see IPR claim #1840. > > The authors has stated on the working group mailing list > that they are not aware of any other IPR claims against this draft. > However if you are on the the mpls working group mailing list and > aware of IPR that relates to this draft, the time to disclose > this is now. > > /Loa > (mpls wg co-chair) > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > ______________________________**_________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/**listinfo/mpls > --047d7b2e4fa41b2ff804dd1c66f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Support (as co-author).

- Sri<= /div>


On Thu, May 1= 6, 2013 at 10:49 AM, Loa Andersson <loa@pi.nu> wrote:
Working Group,

This is to start a two week poll on adopting
draft-jjb-mpls-rsvp-te-hsmp-lsp-04 as an MPLS working
group document.

Please send your comments (support/not support) to the mpls working
group mailing list (mpls= @ietf.org). Please give a technical
motivation for your support/not support, especially if you think that
the document should not be adopted as a working group document.

This poll ends May 31, 2013.

There are one IPR claim against this document, see IPR claim #1840.

The authors has stated on the working group mailing list
that they are not aware of any other IPR claims against this draft.
However if you are on the the mpls working group mailing list and
aware of IPR that relates to this draft, the time to disclose
this is now.

/Loa
(mpls wg co-chair)
--


Loa Andersson =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0email: loa@mail01.huawei.com
Senior MPLS Expert =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loa@pi.nu
Huawei Technologies (consultant) =C2=A0 =C2=A0 phone: +46 739 81 2= 1 64
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--047d7b2e4fa41b2ff804dd1c66f8-- From loa@pi.nu Mon May 20 01:59:54 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EFFF21F84A9 for ; Mon, 20 May 2013 01:59:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.998 X-Spam-Level: X-Spam-Status: No, score=-100.998 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cdPJyOl11HUv for ; Mon, 20 May 2013 01:59:49 -0700 (PDT) Received: from pipi.pi.nu (unknown [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id E76A121F9339 for ; Mon, 20 May 2013 01:27:15 -0700 (PDT) Received: from [192.168.1.130] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 9968B1800272; Mon, 20 May 2013 10:25:13 +0200 (CEST) Message-ID: <5199DDEB.9020609@pi.nu> Date: Mon, 20 May 2013 10:25:15 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Sriganesh Kini References: <51951C17.8010906@pi.nu> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-jjb-mpls-rsvp-te-hsmp-lsp@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus to make draft-jjb-mpls-rsvp-te-hsmp-lsp an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 08:59:54 -0000 Sri, as always it is good if the co-authors speak up, but it would also be good if you made sure that folks you know ae interested also did so. /Loa On 2013-05-20 03:38, Sriganesh Kini wrote: > Support (as co-author). > > - Sri > > > On Thu, May 16, 2013 at 10:49 AM, Loa Andersson > wrote: > > Working Group, > > This is to start a two week poll on adopting > draft-jjb-mpls-rsvp-te-hsmp-__lsp-04 as an MPLS working > group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org ). Please > give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > This poll ends May 31, 2013. > > There are one IPR claim against this document, see IPR claim #1840. > > The authors has stated on the working group mailing list > that they are not aware of any other IPR claims against this draft. > However if you are on the the mpls working group mailing list and > aware of IPR that relates to this draft, the time to disclose > this is now. > > /Loa > (mpls wg co-chair) > -- > > > Loa Andersson email: loa@mail01.huawei.com > > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > > _________________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/__listinfo/mpls > > > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From muly_i@rad.com Mon May 20 05:59:33 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4493C21F884F for ; Mon, 20 May 2013 05:59:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 88B+qpFgVRQ6 for ; Mon, 20 May 2013 05:59:27 -0700 (PDT) Received: from rad.co.il (mailrelay02.rad.co.il [62.0.23.237]) by ietfa.amsl.com (Postfix) with ESMTP id D058C21F920B for ; Mon, 20 May 2013 05:59:24 -0700 (PDT) Received: from Internal Mail-Server by MailRelay02 (envelope-from muly?i@rad.com) with AES128-SHA encrypted SMTP; 20 May 2013 15:55:46 +0300 Received: from EXRAD5.ad.rad.co.il ([192.114.24.28]) by EXRAD5.ad.rad.co.il ([192.114.24.28]) with mapi id 14.02.0298.004; Mon, 20 May 2013 15:59:20 +0300 From: Muly Ilan To: "mpls@ietf.org" Thread-Topic: Comment on draft-ietf-mpls-tp-te-mib-06.txt Thread-Index: Ac5VWdfzY80uKUZeQMmsnYGiL0LWRQ== Date: Mon, 20 May 2013 12:59:20 +0000 Message-ID: <32CB7A1F0806AB4688CE3F22C29DAC87049BDD91@EXRAD5.ad.rad.co.il> Accept-Language: en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.17.170.136] Content-Type: multipart/alternative; boundary="_000_32CB7A1F0806AB4688CE3F22C29DAC87049BDD91EXRAD5adradcoil_" MIME-Version: 1.0 X-Commtouch-Refid: str=0001.0A010209.519A1E29.005F,ss=1,fgs=0 Cc: "venkat.mahalingams@gmail.com" , "kannankvs@gmail.com" Subject: [mpls] Comment on draft-ietf-mpls-tp-te-mib-06.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 12:59:33 -0000 --_000_32CB7A1F0806AB4688CE3F22C29DAC87049BDD91EXRAD5adradcoil_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Please fix a small typo. Section 9.1.2. and section 9.3.2. mplsTunnelExtOppositeDirTnlPtr --> mplsTunnelExtOppositeDirPtr Regards, Muly --_000_32CB7A1F0806AB4688CE3F22C29DAC87049BDD91EXRAD5adradcoil_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

Please fix a small typo.

 

Section 9.1.2.  and section 9.3.2.

mplsTunnelExtOppositeDirTn= lPtr =E0 mplsTunnelExtOppositeDirPt= r

 

 

Regards,

 

Muly

--_000_32CB7A1F0806AB4688CE3F22C29DAC87049BDD91EXRAD5adradcoil_-- From adrian@olddog.co.uk Mon May 20 09:34:21 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD8121F95EB for ; Mon, 20 May 2013 09:34:21 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BbwADtRwp7bJ for ; Mon, 20 May 2013 09:34:15 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 9D7BF21F95E4 for ; Mon, 20 May 2013 09:34:12 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4KGY90r016291; Mon, 20 May 2013 17:34:09 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4KGY7u8016278 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 20 May 2013 17:34:08 +0100 From: "Adrian Farrel" To: "'Eric Osborne \(eosborne\)'" References: <518A064C.7090006@pi.nu> <20ECF67871905846A80F77F8F4A275721024709E@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A275721024709E@xmb-rcd-x09.cisco.com> Date: Mon, 20 May 2013 17:34:07 +0100 Message-ID: <024701ce5577$d9b881e0$8d2985a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEA85wkIqTcvalMAOBxYkCEqrMtWQD7Kf7FmqEug/A= Content-Language: en-gb Cc: draft-farbryantrel-mpls-retire-ach-tlv@tools.ietf.org, mpls-chairs@tools.ietf.org, mpls@ietf.org Subject: Re: [mpls] MPLS-RT review of draft-farbryantrel-mpls-retire-ach-tlv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 16:34:21 -0000 Thanks Eric, [Adding the MPLS list] I just posted a revised I-D. Adrian > -----Original Message----- > From: Eric Osborne (eosborne) [mailto:eosborne@cisco.com] > Sent: 20 May 2013 17:11 > To: Loa Andersson; Lizhong Jin; Jia He; Gregory Mirsky; Martin Vigoureux > Cc: draft-farbryantrel-mpls-retire-ach-tlv@tools.ietf.org; mpls- > chairs@tools.ietf.org > Subject: RE: MPLS-RT review of draft-farbryantrel-mpls-retire-ach-tlv > > I have completed my review of this draft. I have no issues with it, only a few nits > that I only pick in order to demonstrate that I have in fact actually read the > document. > > - The first sentence in section 1 is kind of bumpy. I suggest something along the > lines of > > --- > RFC4385 says that if the first nibble of a PW packet carried over an MPLS network > has a value of 1 then the packet starts with a specific header format called the > Pseudowire Associated Channel Header, known as the PWACH or more generally > as the ACH. > --- > > At a minimum, "defines that is the first" and "header format call the" are typos. > > > - Section 1 goes on to say "There are no currently live Internet-Drafts that utilize > ACH TLVs". Is this a sentence that should live in perpetuity when this draft > becomes an RFC? > > - The security section suggests that removing the ACH TLV has a 'marginal positive > effect', but this ignores the idea that one could have an authentication TLV or > some sort of encrypted message; removing this capability has as much of a > theoretical marginally negative effect as removing a vector for buffer bloat or > bogus TLV values. > > > > > > eric > > > > -----Original Message----- > > From: Loa Andersson [mailto:loa@pi.nu] > > Sent: Wednesday, May 08, 2013 4:01 AM > > To: Lizhong Jin; Jia He; Gregory Mirsky; Eric Osborne (eosborne); Martin > > Vigoureux > > Cc: draft-farbryantrel-mpls-retire-ach-tlv@tools.ietf.org; mpls- > > chairs@tools.ietf.org > > Subject: MPLS-RT review of draft-farbryantrel-mpls-retire-ach-tlv > > > > Jia, Lizhong, Greg and Eric, > > > > You have been selected as an MPLS Review team reviewers for draft- > > farbryantrel-mpls-retire-ach-tlv-00. > > > > Note to authors: You have been CC'd on this email so that you can know > > that this review is going on. However, please do not review your own > > document. > > > > Reviews should comment on whether the document is coherent, is it useful > > (ie, is it likely to be actually useful in operational networks), and is > > the document technically sound? We are interested in knowing whether > > the document is ready to be considered for WG adoption (ie, it doesn't > > have to be perfect at this point, but should be a good start). > > > > Reviews should be sent to the document authors, WG co-chairs and WG > > secretary, and CC'd to the MPLS WG email list. If necessary, comments > > may be sent privately to only the WG chairs. > > > > Are you able to review this draft by Mat 24, 2013? > > > > Thanks, Loa > > (as MPLS WG chair) > > -- > > > > > > Loa Andersson email: loa@mail01.huawei.com > > Senior MPLS Expert loa@pi.nu > > Huawei Technologies (consultant) phone: +46 739 81 21 64 From adrian@olddog.co.uk Mon May 20 09:42:24 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8516321F9644 for ; Mon, 20 May 2013 09:42: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITJes4ialh3p for ; Mon, 20 May 2013 09:42:18 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 743A821F9636 for ; Mon, 20 May 2013 09:42:18 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4KGgGVv029290; Mon, 20 May 2013 17:42:16 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4KGgFPT029275 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 20 May 2013 17:42:16 +0100 From: "Adrian Farrel" To: "'Yaakov Stein'" References: <002a01ce4b45$82e38ae0$88aaa0a0$@olddog.co.uk> <07F7D7DED63154409F13298786A2ADC904D3032A@EXRAD5.ad.rad.co.il> In-Reply-To: <07F7D7DED63154409F13298786A2ADC904D3032A@EXRAD5.ad.rad.co.il> Date: Mon, 20 May 2013 17:42:14 +0100 Message-ID: <025101ce5578$fc510e10$f4f32a30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLV0SBduuCV8Bbr8Ga6vxHiyLN4SAGga88vlvJKfHA= Content-Language: en-gb Cc: mpls@ietf.org Subject: Re: [mpls] Retiring ACH TLVs X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 16:42:24 -0000 Yaakov, > However, I believe that options for the signalling and management channels of > RFC 5718 have never been spelled out. Are we sure that these will not need > some standard modifiers/parameters ? It's a reasonable question, and perhaps why the TLV space was initially defined. The example use cases I have seen discussed have been addresses and security. However, we have got this far without any actual use cases which makes me think that "standard modifiers/parameters" will not be applied to all of the existing ACH types (essentially they had the "No TLVs" box checked in the registry). So, I think the way it works is that if one or more new ACH types need "standard" modifiers in their messages, they can build that information into the messages they define rather than into the generic header that is the ACH. Cheers, Adrian From adrian@olddog.co.uk Mon May 20 09:43:05 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 266B621F9636 for ; Mon, 20 May 2013 09:43:05 -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, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7Tr6i4q56sb for ; Mon, 20 May 2013 09:43:00 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 78A0E21F9626 for ; Mon, 20 May 2013 09:42:59 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4KGgvGP032614; Mon, 20 May 2013 17:42:57 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4KGgtOq032592 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 20 May 2013 17:42:56 +0100 From: "Adrian Farrel" To: "'Lizhong Jin'" References: In-Reply-To: Date: Mon, 20 May 2013 17:42:54 +0100 Message-ID: <025801ce5579$141f9160$3c5eb420$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0259_01CE5581.76136DD0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGGWIjsQYs32SwzsMqrAMhBNSQ7UpmeQCEQ Content-Language: en-gb Cc: mpls@ietf.org Subject: Re: [mpls] Retiring ACH TLVs X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 16:43:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0259_01CE5581.76136DD0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Lizhong, I just went back and checked 5586. In Section 4 it talks about "ACH TLVs if present." And I am working on the assumption that if TLVs are not defined, they will never be present, so the text doesn't actually need updating. In Section 10 there is the IANA work to create the ACH TLV registry and add the column to the ACH Type registry. We are directly instructing IANA to remove that from the registry, and I don't think that 5586 needs to be updated. Our aim was minimal and clear update to 5586 rather than a new revision. If the WG prefers, we could bis 5586 to remove all discussion of the ACH TLV. Thanks, Adrian From: Lizhong Jin [mailto:lizho.jin@gmail.com] Sent: 17 May 2013 06:44 To: mpls@ietf.org; adrian@olddog.co.uk Subject: Re: [mpls] Retiring ACH TLVs Hi, Support, and I like this. But it seems deleting section 3 in RFC5586 is not enough. Other sections in RFC5586 also has the content of ACH TLV. Is it engouth to update by only deleting section 3 described in this draft? Lizhong On Tue, May 7, 2013 at 1:08 PM, Adrian Farrel wrote: > Hi, > > ACH TLVs keep popping up and causing Stewart and me trouble. Mainly it is > about explaining why no-one actually wants to use them (i.e., when each new > ACH Type is defined and has a "No TLVs" written for it, we get asked "why > not?"). > > It seems to us that ACH TLVs are an idea that has been rejected. Initially > we thought they might be used (especially for identifiers), but there seems > to be good opinion that handling generic TLVs would be a pain. > > Since I was heavily responsible for insisting that ACH TLVs were included > in RFC 5586, it seems reasonable that I do the work to fix it. > > The I-D below retires ACH TLVs and handles the necessary registry changes. > > Note, of course, that structured data are still possible within individual > ACHs if the protocol spec for an individual ACH decides to have them. > > We're directing this work to the MPLS working group because that is where > 5586 was written. I have BCC'ed PWE3, L2VPN, and BFD for information. > > Thanks for any comments. > > As humble WG contributors we would be enthusiastic to see early WG > adoption and last call :-) > > Thanks, > Adrian > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: 07 May 2013 17:33 > > To: Adrian Farrel; Stewart Bryant > > Subject: New Version Notification for > draft-farbryantrel-mpls-retire-ach-tlv- > > 00.txt > > > > > > A new version of I-D, draft-farbryantrel-mpls-retire-ach-tlv-00.txt > > has been successfully submitted by Adrian Farrel and posted to the > > IETF repository. > > > > Filename: draft-farbryantrel-mpls-retire-ach-tlv > > Revision: 00 > > Title: Retiring TLVs from the Associated Channel Header > of the MPLS > > Generic Associated Channel > > Creation date: 2013-05-07 > > Group: Individual Submission > > Number of pages: 4 > > URL: > http://www.ietf.org/internet-drafts/draft-farbryantrel-mpls-retire- > > ach-tlv-00.txt > > Status: > http://datatracker.ietf.org/doc/draft-farbryantrel-mpls-retire-ach-tlv > > Htmlized: > http://tools.ietf.org/html/draft-farbryantrel-mpls-retire-ach-tlv-00 > > > > > > Abstract: > > The MPLS Generic Associated Channel (G-ACh) is a generalization of > > the applicability of the Pseudowire (PW) Associated Channel Header > > (ACH). RFC 5586 defines the concept of Type-Length-Variable (TLV) > > constructs that can be carried in messages on the G-ACh by placing > > them in the ACH. > > > > No Associated Channel Type yet defined uses a TLV. Furthermore, it > > is believed that handling TLVs in hardware introduces significant > > problems to the fast-path, and since G-ACh messages are intended to > > be processed substantially in hardware, the use of TLVs in > > undesirable. > > > > This document updates RFC 5586 by retiring ACH TLVs and removing the > > associated registry. > > > > > > > > > > The IETF Secretariat > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ ------=_NextPart_000_0259_01CE5581.76136DD0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Lizhong,

 

I just went back and checked = 5586.

 

In Section 4 it talks about = "ACH TLVs if present." And I am working on the assumption that = if TLVs are not defined, they will never be present, so the text doesn't = actually need updating.

 

In Section  10 there is the IANA work to = create the ACH TLV registry and add the column to the ACH Type registry. = We are directly instructing IANA to remove that from the registry, and I = don't think that 5586 needs to be updated.

 

Our aim was minimal and clear = update to 5586 rather than a new revision.

 

If the WG prefers, we could = bis 5586 to remove all discussion of the ACH = TLV.

 

Thanks,

Adrian

 

From: Lizhong Jin = [mailto:lizho.jin@gmail.com]
Sent: 17 May 2013 = 06:44
To: mpls@ietf.org; = adrian@olddog.co.uk
Subject: Re: [mpls] Retiring ACH = TLVs

 

Hi,

Support, and I like this. But it seems deleting = section 3 in RFC5586 is not enough. Other sections in RFC5586 also has = the content of ACH TLV. Is it engouth to update by only deleting section = 3 described in this draft?

 

Lizhong


 



On Tue, May 7, 2013 at 1:08 PM, Adrian Farrel = <adrian@olddog.co.uk> = wrote:

> Hi,
>
> ACH TLVs keep popping up and = causing Stewart and me trouble. Mainly it is
> about explaining = why no-one actually wants to use them (i.e., when each new
> ACH = Type is defined and has a "No TLVs" written for it, we get = asked "why
> not?").
>
> It seems to us that = ACH TLVs are an idea that has been rejected. Initially
> we = thought they might be used (especially for identifiers), but there = seems
> to be good opinion that handling generic TLVs would be a = pain.
>
> Since I was heavily responsible for insisting that = ACH TLVs were included
> in RFC 5586, it seems reasonable that I = do the work to fix it.
>
> The I-D below retires ACH TLVs = and handles the necessary registry changes.
>
> Note, of = course, that structured data are still possible within = individual
> ACHs if the protocol spec for an individual ACH = decides to have them.
>
> We're directing this work to the = MPLS working group because that is where
> 5586 was written. I = have BCC'ed PWE3, L2VPN, and BFD for information.
>
> Thanks = for any comments.
>
> As humble WG contributors we would be = enthusiastic to see early WG
> adoption and last call = :-)
>
> Thanks,
> Adrian
>
> > = -----Original Message-----
> > From: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]> > Sent: 07 May 2013 17:33
> > To: Adrian Farrel; = Stewart Bryant
> > Subject: New Version Notification = for
> draft-farbryantrel-mpls-retire-ach-tlv-
> > = 00.txt
> >
> >
> > A new version of I-D, = draft-farbryantrel-mpls-retire-ach-tlv-00.txt
> > has been = successfully submitted by Adrian Farrel and posted to the
> > = IETF repository.
> >
> > Filename:     =  draft-farbryantrel-mpls-retire-ach-tlv
> > Revision: =      00
> > Title:         =         Retiring TLVs from the Associated Channel = Header
> of the MPLS
> > Generic Associated = Channel
> > Creation date:         = 2013-05-07
> > Group:             =     Individual Submission
> > Number of pages: = 4
> > URL:
> http://www.ietf.org/internet-drafts/draft-farbryantrel-= mpls-retire-
> > ach-tlv-00.txt
> > = Status:
> http://datatracker.ietf.org/doc/draft-farbryantrel-mpls= -retire-ach-tlv
> > Htmlized:
> http://tools.ietf.org/html/draft-farbryantrel-mpls-reti= re-ach-tlv-00
> >
> >
> > = Abstract:
> >    The MPLS Generic Associated Channel = (G-ACh) is a generalization of
> >    the = applicability of the Pseudowire (PW) Associated Channel Header
> = >    (ACH).  RFC 5586 defines the concept of = Type-Length-Variable (TLV)
> >    constructs that can = be carried in messages on the G-ACh by placing
> >   =  them in the ACH.
> >
> >    No = Associated Channel Type yet defined uses a TLV.  Furthermore, = it
> >    is believed that handling TLVs in hardware = introduces significant
> >    problems to the = fast-path, and since G-ACh messages are intended to
> >   =  be processed substantially in hardware, the use of TLVs in
> = >    undesirable.
> >
> >   =  This document updates RFC 5586 by retiring ACH TLVs and removing = the
> >    associated registry.
> >
> = >
> >
> >
> > The IETF = Secretariat
>
> = _______________________________________________
> mpls mailing = list
> mpls@ietf.org
> = https://www.ietf.org/mailman/listinfo/mpls
><= br>-------------- next part --------------
An HTML attachment was = scrubbed...
URL: <http://www.ietf.org/mail-archive/web/mpls/attachments/2= 0130516/f560777c/attachment.htm>

--------------------------= ----

------=_NextPart_000_0259_01CE5581.76136DD0-- From junaid.syed@ericsson.com Mon May 20 10:37:47 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABA721F965B for ; Mon, 20 May 2013 10:37: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eLcgEOPWbpcu for ; Mon, 20 May 2013 10:37:42 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 0553D21F9673 for ; Mon, 20 May 2013 10:37:41 -0700 (PDT) X-AuditID: c6180641-b7f7b6d000001a44-f2-519a5f64048b Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id E3.22.06724.46F5A915; Mon, 20 May 2013 19:37:41 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0328.009; Mon, 20 May 2013 13:37:40 -0400 From: Junaid Syed To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] poll to see if we have consensus to make draft-jjb-mpls-rsvp-te-hsmp-lsp an MPLS wg document Thread-Index: AQHOUl3BoPrWxX4QSUiCgovDj58W1pkOXH9Q Date: Mon, 20 May 2013 17:37:40 +0000 Message-ID: <09FEC81F035F3F4AB4CBE8D3A3A7678C1E67DE@eusaamb101.ericsson.se> References: <51951C17.8010906@pi.nu> In-Reply-To: <51951C17.8010906@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyuXRPiG5q/KxAgwUPBSw+HZnKbvFv7hxm i++XlrBY3Fq6ktWBxWPJkp9MHrOmt7F5fLn8mS2AOYrLJiU1J7MstUjfLoEr48uC2UwFP7kr LpxZwtTAeISzi5GTQ0LAROLG1wtMELaYxIV769m6GLk4hASOMkqc2DmNHcJZzihx+vIDdpAq NgEdiQPvloN1iAjYSWx89Y8RpIhZYAmjxO2pDWAJYYEiiaVHV7BAFBVLrL92lxXCNpI4cmYn WJxFQFVi58wVYEN5Bbwlrj5fCzSIA2ibisSlF3ogYU6gkrY7K8FaGYGu+35qDdh4ZgFxiVtP 5kNdLSCxZM95ZghbVOLl43+sELayxJIn+1kg6nUkFuz+xAZha0ssW/iaGWKtoMTJmU9YJjCK zUIydhaSlllIWmYhaVnAyLKKkaO0OLUsN93IcBMjMIqOSbA57mBc8MnyEKM0B4uSOG+39tRA IYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYwyxhXnDkp/3rmq33+m8KYnnwNdb69d6LWgKevN ue4YE5PorHsvlnQarD2Qz9zSYeF21FrHu5RvqXzondAfKzTLel6+b5/tYcC1M2Qxy/uN/0P4 C1ReF7kqL9EMSe0P1ra+cnXL29iZynkXd1i1zbE+Y/DKv4Sj7gXDkhPea25qL6iO9p7xSEmJ pTgj0VCLuag4EQD24bRmcAIAAA== Cc: "draft-jjb-mpls-rsvp-te-hsmp-lsp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus to make draft-jjb-mpls-rsvp-te-hsmp-lsp an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 17:37:47 -0000 Support.=20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Thursday, May 16, 2013 10:49 AM To: mpls@ietf.org Cc: draft-jjb-mpls-rsvp-te-hsmp-lsp@tools.ietf.org; mpls-chairs@tools.ietf.= org Subject: [mpls] poll to see if we have consensus to make draft-jjb-mpls-rsv= p-te-hsmp-lsp an MPLS wg document Working Group, This is to start a two week poll on adopting draft-jjb-mpls-rsvp-te-hsmp-lsp-04 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group m= ailing list (mpls@ietf.org). Please give a technical motivation for your su= pport/not support, especially if you think that the document should not be = adopted as a working group document. This poll ends May 31, 2013. There are one IPR claim against this document, see IPR claim #1840. The authors has stated on the working group mailing list that they are not = aware of any other IPR claims against this draft. However if you are on the the mpls working group mailing list and aware of = IPR that relates to this draft, the time to disclose this is now. /Loa (mpls wg co-chair) --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From iesg-secretary@ietf.org Mon May 20 18:40:56 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51A6221F9703; Mon, 20 May 2013 18:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vx440s3PnUJB; Mon, 20 May 2013 18:40:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1300021F970D; Mon, 20 May 2013 18:40:55 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130521014055.20751.92371.idtracker@ietfa.amsl.com> Date: Mon, 20 May 2013 18:40:55 -0700 Cc: mpls mailing list , mpls chair , RFC Editor Subject: [mpls] Document Action: 'Applicability of MPLS-TP Linear Protection for Ring Topologies' to Informational RFC (draft-ietf-mpls-tp-ring-protection-06.txt) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 01:40:56 -0000 The IESG has approved the following document: - 'Applicability of MPLS-TP Linear Protection for Ring Topologies' (draft-ietf-mpls-tp-ring-protection-06.txt) as Informational RFC This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-ring-protection/ Technical Summary This document presents an applicability of existing MPLS protection mechanisms, both local and end-to-end, to Multi-Protocol Label Switching Transport Profile (MPLS-TP) in ring topologies. This document does not propose any new mechanisms or protocols. Protection on rings offers a number of opportunities for optimization as the protection choices are starkly limited (all traffic traveling one way around a ring can only be switched to travel the other way on the ring), but also suffers from some complications caused by the limitations of the topology. Requirements for MPLS-TP protection especially for protection in ring topologies are discussed in "Requirements of an MPLS Transport Profile" (RFC 5654) and "MPLS Transport Profile (MPLS-TP) Survivability Framework" (RFC 6372). This document shows how MPLS-TP linear protection as defined in RFC 6378 can be applied to single ring topologies, discusses how most of the requirements are met, and describes scenarios in which the function provided by applying linear protection in a ring topology falls short of some of the requirements. Working Group Summary This document was the subject of considerable debate in the MPLS working group. There was some concern about whether this work prohibited or devalued the development of specialised protection techniques for deployment in ring topologies. The document was re-worked to make it clear that it is basically an applicability statement showing how linear protection defined in RFC 6378 can be applied to ring topologies, what function can be achieved, and what issues remain. It was made clear to the working group that specialist ring protection techniques were still in scope for the working group provided that they demonstrate improvements over the application of linear protection, and provided they can interwork with general protection in the wider MPLS-TP network. A second WG last call was held and the document gained consensus. Please see RFC editor note for a commentary on the number of front-page authors. Document Quality This an informational document, it describes how the technologies defined in earlier RFCs can be applied to ring topologies. The document has been reviewed needed, the working group last call was brought to the attention of SG15 in ITU-T. Personnel Loa Andersson (loa@pi.nu) is the document shepherd Adrian Farrel (Adrian@olddog.co.uk) is the Responsible AD RFC Editor Note Please allow an exception to the normal front-page limit so that all eight named authors can be present. The WG chair/ shepherd explains it as follows: > Early 2010 we had 5 or 6 different drafts addressing "mpls-tp- > ring-protection" from one aspect or another. Most of these > drafts had 2 or maybe 3 different authors. > > The WG chairs took an initiative to discuss the possibilities to > merge all drafts into one. The discussion was partially > successful, and all draft but one, were merged into a single > document. Texts from all drafts were merged into draft- > weingarten-mpls-tp-ring-protection (later to be adopted as > the working group draft draft-ietf-mpls-tp-ring-protection. > > The number of authors on the first page reflect text > contributions made to the drafts that were merged. --- You may rename and reposition Section 1.4 according to your style guide. --- If (and only if) you consider it necessary, you may consider some of the text as Tables and apply captions as follows... In Section 3.1 on page 19 "Table x : Backup LSPs for Node Protection" In Section 3.1.1 on page 20 "Table x : Nodes Traversed by Protection: LSPs" In Section 3.1.1 on page 21 "Table x : Bandwidth Utilization on Links During Protection" In Section 3.2.2 on page 25 "Table x : Context Specific Labels for Connected LSPs" From daniele.ceccarelli@ericsson.com Tue May 21 00:37:36 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3C721F9763 for ; Tue, 21 May 2013 00:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.416 X-Spam-Level: X-Spam-Status: No, score=-5.416 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLJ3ILJLtHr9 for ; Tue, 21 May 2013 00:37:30 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5EFFB21F9754 for ; Tue, 21 May 2013 00:37:30 -0700 (PDT) X-AuditID: c1b4fb25-b7efb6d000007c26-15-519b2439dd53 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 60.4F.31782.9342B915; Tue, 21 May 2013 09:37:29 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.55]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0328.009; Tue, 21 May 2013 09:37:28 +0200 From: Daniele Ceccarelli To: Loa Andersson Thread-Topic: [mpls] poll to see if we have consensus to make draft-jjb-mpls-rsvp-te-hsmp-lsp an MPLS wg document Thread-Index: AQHOVfYLaHJsvp4iAUO0pw8FaDzLuQ== Date: Tue, 21 May 2013 07:37:28 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE480CBBA8@ESESSMB301.ericsson.se> References: <51951C17.8010906@pi.nu> In-Reply-To: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE480CBBA8ESESSMB301ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM+Jvra6lyuxAg2u3pC0+HZnKbvFv7hxm i++XlrBY3Fq6ktWBxWPJkp9MHrOmt7F5fLn8mS2AOYrLJiU1J7MstUjfLoEr4+eSu6wFO/Qr rn8+ydTAuEGzi5GDQ0LAROLMpMwuRk4gU0ziwr31bF2MXBxCAocZJWbvO8EE4SxmlDiw4gAT SAObgJXEk0M+IA0iArIS17b9BKthFjjOKHFm9i5WkISwQJHE0qMrWCCKiiXWX7vLCmHrSdzb /4sZxGYRUJU4d3IVWA2vgLfEwS0XwWwhgWyJ+/sngNVzCgRKPDn2G6yeEWjZhN2LGEFsZgFx iVtP5jNBXC0gsWTPeWYIW1Ti5eN/rBC2osTHV/ug6vMlnjUeYYPYJShxcuYTlgmMorOQjJqF pGwWkjKIuI7Egt2f2CBsbYllC18zw9hnDjxmQhZfwMi+ipE9NzEzJ73caBMjMOIObvmtuoPx zjmRQ4zSHCxK4ry92lMDhQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTDWrrAuvPr4muiE1e1b fod5rig0dj0qKD+54xb7/rA5z/wm3oq6HXKi/ev8U7XX2CYcDJzC8jKE79Lko0+3K8SfmOIS 0+Xiq7WKz6A2SfGRVJvC7U1HCrsfrd0anvk46vf1jXeO1C076nL7iEbtmtvvZtT/f9jHsfLC V85/HIckf+9b7Hi+6hvXIiWW4oxEQy3mouJEAFOeHwyGAgAA Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-jjb-mpls-rsvp-te-hsmp-lsp@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus to make draft-jjb-mpls-rsvp-te-hsmp-lsp an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 07:37:36 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE480CBBA8ESESSMB301ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes/support BR Daniele ---------- Forwarded message ---------- From: Loa Andersson > Date: Thu, May 16, 2013 at 10:49 AM Subject: [mpls] poll to see if we have consensus to make draft-jjb-mpls-rsv= p-te-hsmp-lsp an MPLS wg document To: "mpls@ietf.org" > Cc: "draft-jjb-mpls-rsvp-te-hsmp-lsp@tools.ietf.org" >, "mpls-chairs= @tools.ietf.org" > Working Group, This is to start a two week poll on adopting draft-jjb-mpls-rsvp-te-hsmp-lsp-04 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). Please give a tec= hnical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document. This poll ends May 31, 2013. There are one IPR claim against this document, see IPR claim #1840. The authors has stated on the working group mailing list that they are not aware of any other IPR claims against this draft. However if you are on the the mpls working group mailing list and aware of IPR that relates to this draft, the time to disclose this is now. /Loa (mpls wg co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_4A1562797D64E44993C5CBF38CF1BE480CBBA8ESESSMB301ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Yes/support
 
BR
Daniele
---------- Forwarded message ----------
From: Loa Andersson <= ;loa@pi.nu>
Date: Thu, May 16, 2013 at 10:49 AM
Subject: [mpls] poll to see if we have consensus to make draft-jjb-mpls-rsv= p-te-hsmp-lsp an MPLS wg document
To: "mpls@ietf.org" <mpls@ietf.org>
Cc: "draft-jjb-mpls-rsvp-te-hsmp-lsp@tools.ietf.org" <draft-jjb-mpls-rsvp-te= -hsmp-lsp@tools.ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.o= rg>


Working Group,

This is to start a two week poll on adopting
draft-jjb-mpls-rsvp-te-hsmp-lsp-04 as an MPLS working
group document.

Please send your comments (support/not support) to the mpls working
group mailing list (mpls= @ietf.org). Please give a technical
motivation for your support/not support, especially if you think that
the document should not be adopted as a working group document.

This poll ends May 31, 2013.

There are one IPR claim against this document, see IPR claim #1840.

The authors has stated on the working group mailing list
that they are not aware of any other IPR claims against this draft.
However if you are on the the mpls working group mailing list and
aware of IPR that relates to this draft, the time to disclose
this is now.

/Loa
(mpls wg co-chair)
--


Loa Andersson                  = ;      email: loa@mail01.huawei.com
Senior MPLS Expert                 =          loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--_000_4A1562797D64E44993C5CBF38CF1BE480CBBA8ESESSMB301ericsso_-- From jeff.tantsura@ericsson.com Tue May 21 01:05:34 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47E7B21F9786 for ; Tue, 21 May 2013 01:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.766 X-Spam-Level: X-Spam-Status: No, score=-1.766 tagged_above=-999 required=5 tests=[AWL=-0.834, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udlfVOlmYz0v for ; Tue, 21 May 2013 01:05:29 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id A4E4021F976F for ; Tue, 21 May 2013 01:05:28 -0700 (PDT) X-AuditID: c618062d-b7fb56d0000042e1-43-519b2ac7cda4 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id F5.6D.17121.7CA2B915; Tue, 21 May 2013 10:05:27 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Tue, 21 May 2013 04:05:27 -0400 From: Jeff Tantsura To: Loa Andersson Thread-Topic: [mpls] poll to see if we have consensus to make draft-jjb-mpls-rsvp-te-hsmp-lsp an MPLS wg document Thread-Index: AQHOVfYZt/FuWW85C0Kt6tpM9UXrJZkPFPCA Date: Tue, 21 May 2013 08:05:26 +0000 Message-ID: <60DEDD93F5E54B4AB55647B8B6C7483936AB6C@eusaamb109.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE480CBBA8@ESESSMB301.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_60DEDD93F5E54B4AB55647B8B6C7483936AB6Ceusaamb109ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkkeLIzCtJLcpLzFFi42KZXLonSve41uxAg60LLCw+HZnKbvFv7hxm i++XlrBY3Fq6ktWBxWPJkp9MHrOmt7F5fLn8mS2AOYrLJiU1J7MstUjfLoErY+3nfpaCz4YV F8+2MTYwbtbuYuTkkBAwkVh8dCozhC0mceHeerYuRi4OIYGjjBKvV99ghHCWM0pM3b2PFaSK TcBA4v+34ywgtoiArMS1bT+ZQIqYBY4zStz70sAOkhAWKJI4c+kWG0RRscT6a3dZIWwjibvH 74I1swioSsz6cR9sNa+At8SqYzsZQWxOAR+JY6v/MYHYjEAnfT+1BsxmFhCXuPVkPhPEqQIS S/achzpbVOLl439g80UF9CTajp1hh4grSyx5sp8Fojdf4vqVNiaIXYISJ2c+YZnAKDoLydhZ SMpmISmDiOtILNj9iQ3C1pZYtvA1M4x95sBjoHoOINtaonmaJrKSBYwcqxg5SotTy3LTjQw2 MQKj8ZgEm+4Oxj0vLQ8xSnOwKInztmpPDRQSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAyLqJ 8dTnqs53VZeCdzqdu/WiLkJV4+qxV3GSi0uZWBc4su+IO3bQ7I3EZN3Zf+13O/P8T2SUdgtd /1nZVsLg7Uae3Gv+IkulW/dnrI5Yn/vZXOjEki2pKtMPzVFUfrSx9uLdQx4FTddebzzmN3tr z4HG4o01jU3dfd94NF/zTZG8+nnKMZ6g6UosxRmJhlrMRcWJAEaSOO6UAgAA Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-jjb-mpls-rsvp-te-hsmp-lsp@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus to make draft-jjb-mpls-rsvp-te-hsmp-lsp an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 08:05:34 -0000 --_000_60DEDD93F5E54B4AB55647B8B6C7483936AB6Ceusaamb109ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes/support Cheers, Jeff ---------- Forwarded message ---------- From: Loa Andersson > Date: Thu, May 16, 2013 at 10:49 AM Subject: [mpls] poll to see if we have consensus to make draft-jjb-mpls-rsv= p-te-hsmp-lsp an MPLS wg document To: "mpls@ietf.org" > Cc: "draft-jjb-mpls-rsvp-te-hsmp-lsp@tools.ietf.org" >, "mpls-chairs= @tools.ietf.org" > Working Group, This is to start a two week poll on adopting draft-jjb-mpls-rsvp-te-hsmp-lsp-04 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). Please give a tec= hnical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document. This poll ends May 31, 2013. There are one IPR claim against this document, see IPR claim #1840. The authors has stated on the working group mailing list that they are not aware of any other IPR claims against this draft. However if you are on the the mpls working group mailing list and aware of IPR that relates to this draft, the time to disclose this is now. /Loa (mpls wg co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_60DEDD93F5E54B4AB55647B8B6C7483936AB6Ceusaamb109ericsso_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Yes/support

Cheers,
Jeff

---------- Forwarded message ----------
From: Loa Andersson <= ;loa@pi.nu>
Date: Thu, May 16, 2013 at 10:49 AM
Subject: [mpls] poll to see if we have consensus to make draft-jjb-mpls-rsv= p-te-hsmp-lsp an MPLS wg document
To: "mpls@ietf.org" <mpls@ietf.org>
Cc: "draft-jjb-mpls-rsvp-te-hsmp-lsp@tools.ietf.org" <draft-jjb-mpls-rsvp-te= -hsmp-lsp@tools.ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.o= rg>


Working Group,

This is to start a two week poll on adopting
draft-jjb-mpls-rsvp-te-hsmp-lsp-04 as an MPLS working
group document.

Please send your comments (support/not support) to the mpls working
group mailing list (mpls= @ietf.org). Please give a technical
motivation for your support/not support, especially if you think that
the document should not be adopted as a working group document.

This poll ends May 31, 2013.

There are one IPR claim against this document, see IPR claim #1840.

The authors has stated on the working group mailing list
that they are not aware of any other IPR claims against this draft.
However if you are on the the mpls working group mailing list and
aware of IPR that relates to this draft, the time to disclose
this is now.

/Loa
(mpls wg co-chair)
--


Loa Andersson                  = ;      email: loa@mail01.huawei.com
Senior MPLS Expert                 =          loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

 --_000_60DEDD93F5E54B4AB55647B8B6C7483936AB6Ceusaamb109ericsso_-- From Alan.Davey@metaswitch.com Tue May 21 01:23:47 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F36F621F9793 for ; Tue, 21 May 2013 01:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0-825EPKXyb for ; Tue, 21 May 2013 01:23:41 -0700 (PDT) Received: from ENFIRHETS1.metaswitch.com (enfirhets1.metaswitch.com [192.91.191.166]) by ietfa.amsl.com (Postfix) with ESMTP id BADB321F9636 for ; Tue, 21 May 2013 01:23:40 -0700 (PDT) Received: from ENFICSCAS1.datcon.co.uk (172.18.4.13) by ENFIRHETS1.metaswitch.com (172.18.209.22) with Microsoft SMTP Server (TLS) id 14.2.342.3; Tue, 21 May 2013 09:23:27 +0100 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFICSCAS1.datcon.co.uk ([::1]) with mapi id 14.02.0342.003; Tue, 21 May 2013 09:23:35 +0100 From: Alan Davey To: David Allan I Thread-Topic: [MPLS] A doubt about RFC 6428 Thread-Index: Ac5IG1yAbZhW1zCyQtKJoj7oW461UgACNQsQARrVc5AA4QRRQAF5nPeQ Date: Tue, 21 May 2013 08:23:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.71.124] Content-Type: multipart/alternative; boundary="_000_C2EE31C852049D499842B19FC01C0804C1A901F6ENFICSMBX1datco_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] [MPLS] A doubt about RFC 6428 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 08:23:47 -0000 --_000_C2EE31C852049D499842B19FC01C0804C1A901F6ENFICSMBX1datco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dave Thank you for your response. I think that it is worth raising an erratum f= or section 3.5.3 because the current text is confusing (note that the colon= is in the RFC text). Do you agree? I propose the following. Section 3.5.3 Original text: The length is the length of the following data: the Global_ID, Node Identifier, and Attachment Circuit ID (AC_ID) are as per [9]. Corrected text: The length is the length of the data following the length field. The Global_ID, Node Identifier, and Attachment Circuit ID (AC_ID) are as per [9]. Thanks Alan From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: 13 May 2013 20:58 To: Alan Davey Cc: mpls@ietf.org Subject: RE: [MPLS] A doubt about RFC 6428 It is all in how you interpret "The length is the length of the following d= ata." Which is referring to the diagram above (e.g. the colon below is you= r addition), and then goes on to tells you how to find the less-obvious fie= lds. If it said "The length is the length of the data following the length field= "... it would be clearer. Dave ________________________________ From: Alan Davey [mailto:Alan.Davey@metaswitch.com] Sent: Thursday, May 09, 2013 3:59 AM To: David Allan I Cc: mpls@ietf.org Subject: RE: [MPLS] A doubt about RFC 6428 Hi Dave Thank you very much for getting back to me so quickly. I have a further qu= estion on RFC 6428 if you have another minute. In section 3.5.3, PW End Point MEP-ID, I think that the text defining the = Length field is confusing because it is not clear if the length includes th= e AGI. The text is currently as follows. The length is the length of the following data: the Global_ID, Node Ident= ifier, and Attachment Circuit ID (AC_ID) are as per [9]. Am I correct in thinking that the Length field is the length of the value = fields, as for the Section MEP-ID in section 3.5.1 and the LSP MEP-ID in se= ction 3.5.2? That is, should the text read as follows. The length is the length of the value fields. The Global_ID, Node Identi= fier, and Attachment Circuit ID (AC_ID) are as per [9]. Thanks Alan From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: 03 May 2013 18:35 To: Alan Davey; rfc6428@tools.ietf.org Cc: mpls@ietf.org Subject: RE: [MPLS] A doubt about RFC 6428 Hi Alan: It is kind of implied, as in "received DOWN while NOT in a misconnectivity = state". I'm not sure adding that to the state machine diagram would actuall= y improve the clarity....I'll let others comment. cheers Dave ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of Alan Davey Sent: Friday, May 03, 2013 9:29 AM To: rfc6428@tools.ietf.org Cc: mpls@ietf.org Subject: [mpls] [MPLS] A doubt about RFC 6428 Folks I have a doubt about RFC 6428. Could you please let me know what you think= of the following. Section 3.7.4.2., Exit from a Mis-Connectivity Defect, states that "Exit fr= om a mis-connectivity defect state occurs when no CV messages with mis-conn= ectivity defects have been received for a period of 3.5 seconds". However, the State Machines in section 3.7.5 have no input corresponding to= an "Exit from a Mis-Connectivity Defect" timer pop. (Although they do hav= e a MIS-CONNECTIVITY input added by RFC 6428.) If the State Machine is fol= lowed then Down state is exited as soon as the remote system signals Down s= tate. Should the State Machines be modified such that Down state following a MIS-= CONNECTIVITY input is only exited after an "Exit from a Mis-Connectivity De= fect" timer pop input or am I missing something? Regards Alan Davey Network Technologies Metaswitch Networks alan.davey@metaswitch.com +44 (0) 20 8366 1177 network-technologies.metaswitch.com --_000_C2EE31C852049D499842B19FC01C0804C1A901F6ENFICSMBX1datco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dave

 

Thank you for your res= ponse.  I think that it is worth raising an erratum for section 3.5.3 = because the current text is confusing (note that the colon is in the RFC text).  Do you agree?

 

I propose the followin= g.

 

Section 3.5.3

 

Original text:

 

   The lengt= h is the length of the

   following= data: the Global_ID, Node Identifier, and Attachment

   Circuit I= D (AC_ID) are as per [9].

 

Corrected text:

 

   The lengt= h is the length of the data following the length field.

   The Globa= l_ID, Node Identifier, and Attachment

   Circuit I= D (AC_ID) are as per [9].

 

Thanks

Alan=

 

From: David Allan I [mailto:david.i.allan@ericsson.com]
Sent: 13 May 2013 20:58
To: Alan Davey
Cc: mpls@ietf.org
Subject: RE: [MPLS] A doubt about RFC 6428

 

It is all in how you interpret= "The length is the length of the following data."  Which is= referring to the diagram above (e.g. the colon below is your addition), and then goes on to tells you how to find the less-obvious fields. =

 

If it said "The length is= the length of the data following the length field"... it would be cle= arer.

 

Dave

 

From: Alan Davey [mailto:Alan.Davey@metaswitch.com]
Sent: Thursday, May 09, 2013 3:59 AM
To: David Allan I
Cc: mpls@ietf.org
Subject: RE: [MPLS] A doubt about RFC 6428

Hi Dave

 

Thank you very much fo= r getting back to me so quickly.  I have a further question on RFC 642= 8 if you have another minute.

 

In section 3.5.3,  PW End Point MEP-ID, I think that the text defining the Length= field is confusing because it is not clear if the length includes the AGI.=   The text is currently as follows.

 

  The length is t= he length of the following data: the Global_ID, Node Identifier, and Attach= ment

   Circuit I= D (AC_ID) are as per [9].

 

Am I correct in thinki= ng that the Length field  is the length of the value fields, as for th= e Section MEP-ID in section 3.5.1 and the LSP MEP-ID in section 3.5.2? = ; That is, should the text read as follows.

 

  The length is t= he length of the value fields.  The Global_ID, Node Identifier, and At= tachment

   Circuit I= D (AC_ID) are as per [9].

 

Thanks

Alan=

 

From: David Allan I [mailto:david.i.allan@ericsson.com]
Sent: 03 May 2013 18:35
To: Alan Davey; rfc6428@to= ols.ietf.org
Cc: mpls@ietf.org
Subject: RE: [MPLS] A doubt about RFC 6428

 

Hi Alan:

 

It is kind of implie= d, as in "received DOWN while NOT in a misconnectivity state"= ;. I'm not sure adding that to the state machine diagram would actually imp= rove the clarity....I'll let others comment.

 

cheers<= o:p>

Dave

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Alan Davey
Sent: Friday, May 03, 2013 9:29 AM
To: rfc6428@tools.ietf.org=
Cc: mpls@ietf.org
Subject: [mpls] [MPLS] A doubt about RFC 6428

Folks

 

I have a doubt about RFC 6428.  Could you pleas= e let me know what you think of the following.

 

Section 3.7.4.2., Exit from a Mis-Connectivity Defec= t, states that “Exit from a mis-connectivity defect state occurs when= no CV messages with mis-connectivity defects have been received for a peri= od of 3.5 seconds”.

 

However, the State Machines in section 3.7.5 have no= input corresponding to an “Exit from a Mis-Connectivity Defect”= ; timer pop.  (Although they do have a MIS-CONNECTIVITY input added by= RFC 6428.)  If the State Machine is followed then Down state is exited as soon as the remote system signals Down state.=

 

Should the State Machines be modified such that Down= state following a MIS-CONNECTIVITY input is only exited after an “Ex= it from a Mis-Connectivity Defect” timer pop input or am I missing so= mething?

 

Regards

Alan Davey

 

Network Technologies
Metaswitch Networks

 

alan.davey@metaswitch.com
+44 (0) 20 8366 1177
network-technologies.metaswitch.com

 

 

 

--_000_C2EE31C852049D499842B19FC01C0804C1A901F6ENFICSMBX1datco_-- From adrian@olddog.co.uk Tue May 21 05:14:32 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13F5D21F86BB for ; Tue, 21 May 2013 05:14:32 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtnLzMHlE0Fm for ; Tue, 21 May 2013 05:14:27 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 0EA6921F96C1 for ; Tue, 21 May 2013 05:14:26 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4LCEPhw010865; Tue, 21 May 2013 13:14:25 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4LCEOqY010838 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 May 2013 13:14:24 +0100 From: "Adrian Farrel" To: , References: <20130521052910.25936.54558.idtracker@ietfa.amsl.com> In-Reply-To: <20130521052910.25936.54558.idtracker@ietfa.amsl.com> Date: Tue, 21 May 2013 13:14:23 +0100 Message-ID: <001b01ce561c$bb9e9b90$32dbd2b0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF+PUJtdfZLupy0ee69PZk9Qhy/UJmvvZyw Content-Language: en-gb Subject: [mpls] FW: I-D Action: draft-mahesh-karp-rsvp-te-analysis-01.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 12:14:32 -0000 Heads up. Discussion on the Karp list, please. Adrian > -----Original Message----- > From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] > On Behalf Of internet-drafts@ietf.org > Sent: 21 May 2013 06:29 > To: i-d-announce@ietf.org > Subject: I-D Action: draft-mahesh-karp-rsvp-te-analysis-01.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > > Title : Analysis of RSVP-TE Security According to KARP Design Guide > Author(s) : Mahesh Jethanandani > Dacheng Zhang > Filename : draft-mahesh-karp-rsvp-te-analysis-01.txt > Pages : 9 > Date : 2013-05-20 > > Abstract: > This document analyzes Resource reSerVation Protocol-Traffic > Engineering (RSVP-TE) according to guidelines set forth in section > 4.2 of KARP Design Guidelines (RFC 6518). > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-mahesh-karp-rsvp-te-analysis > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-mahesh-karp-rsvp-te-analysis-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-mahesh-karp-rsvp-te-analysis-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From david.i.allan@ericsson.com Tue May 21 06:51:04 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB55F21F969C for ; Tue, 21 May 2013 06:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRRRjTw9yH3h for ; Tue, 21 May 2013 06:50:59 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id C926B21F85E0 for ; Tue, 21 May 2013 06:50:55 -0700 (PDT) X-AuditID: c6180641-b7f7b6d000001a44-8f-519b7bbee7ac Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id BD.C4.06724.EBB7B915; Tue, 21 May 2013 15:50:55 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Tue, 21 May 2013 09:50:54 -0400 From: David Allan I To: Alan Davey Thread-Topic: [MPLS] A doubt about RFC 6428 Thread-Index: Ac5IG1yAbZhW1zCyQtKJoj7oW461UgACNQsQARrVc5AA4QRRQAF5nPeQAAwHmdA= Date: Tue, 21 May 2013 13:50:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_E6C17D2345AC7A45B7D054D407AA205C09E00Feusaamb105ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKLMWRmVeSWpSXmKPExsUyuXSPt+7+6tmBBoeaRC2eTJvFZnFr6UpW ByaPJUt+MnkcvTmXOYApissmJTUnsyy1SN8ugSvjesszxoJ/mxgrZk1/wdTA2DGHsYuRk0NC wETizbJjLBC2mMSFe+vZQGwhgaOMEjNflHcxcgHZyxkljp+dygSSYBMwkNjz/wtYs4iAlsSO 6Z+BGjg4mAWUJU7dlQExhYHCz2eVQFRoS+yY2sMEYftJrFy/mx2khEVAVaJ9rRlImFfAW6Jz TS8TxKY7TBLXV24Bm84p4C+xbcksMJsR6LTvp9aAzWEWEJe49WQ+E8TJAhJL9pxnhrBFJV4+ /scKYStLLHmynwWiPl9i7dyVzBDLBCVOznzCMoFRdBaSUbOQlM1CUgYR15FYsPsTG4StLbFs 4WtmGPvMgcdMyOILGNlXMXKUFqeW5aYbGW5iBEbVMQk2xx2MCz5ZHmKU5mBREuft1p4aKCSQ nliSmp2aWpBaFF9UmpNafIiRiYNTqoHxYO/ui+un8h7sLynryt09b416v4Fq1rW2OMlUcU6R 6LxnGxtaTWNu+0YILPXRcXPgO7R5y/edLPkNtjpRekrnbudp66wVz7/T7L6l08hP9Jnq88YF m+P146PvtO2f0zNjRWawdO4E3Q4+1t7AA4KPZ91pf3Su/+e8Ile/mqvcYa6f1FIuz1ViKc5I NNRiLipOBADl07roeAIAAA== Cc: "mpls@ietf.org" Subject: Re: [mpls] [MPLS] A doubt about RFC 6428 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 13:51:04 -0000 --_000_E6C17D2345AC7A45B7D054D407AA205C09E00Feusaamb105ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with your proposed change. cheers Dave ________________________________ From: Alan Davey [mailto:Alan.Davey@metaswitch.com] Sent: Tuesday, May 21, 2013 1:24 AM To: David Allan I Cc: mpls@ietf.org Subject: RE: [MPLS] A doubt about RFC 6428 Hi Dave Thank you for your response. I think that it is worth raising an erratum f= or section 3.5.3 because the current text is confusing (note that the colon= is in the RFC text). Do you agree? I propose the following. Section 3.5.3 Original text: The length is the length of the following data: the Global_ID, Node Identifier, and Attachment Circuit ID (AC_ID) are as per [9]. Corrected text: The length is the length of the data following the length field. The Global_ID, Node Identifier, and Attachment Circuit ID (AC_ID) are as per [9]. Thanks Alan From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: 13 May 2013 20:58 To: Alan Davey Cc: mpls@ietf.org Subject: RE: [MPLS] A doubt about RFC 6428 It is all in how you interpret "The length is the length of the following d= ata." Which is referring to the diagram above (e.g. the colon below is you= r addition), and then goes on to tells you how to find the less-obvious fie= lds. If it said "The length is the length of the data following the length field= "... it would be clearer. Dave ________________________________ From: Alan Davey [mailto:Alan.Davey@metaswitch.com] Sent: Thursday, May 09, 2013 3:59 AM To: David Allan I Cc: mpls@ietf.org Subject: RE: [MPLS] A doubt about RFC 6428 Hi Dave Thank you very much for getting back to me so quickly. I have a further qu= estion on RFC 6428 if you have another minute. In section 3.5.3, PW End Point MEP-ID, I think that the text defining the = Length field is confusing because it is not clear if the length includes th= e AGI. The text is currently as follows. The length is the length of the following data: the Global_ID, Node Ident= ifier, and Attachment Circuit ID (AC_ID) are as per [9]. Am I correct in thinking that the Length field is the length of the value = fields, as for the Section MEP-ID in section 3.5.1 and the LSP MEP-ID in se= ction 3.5.2? That is, should the text read as follows. The length is the length of the value fields. The Global_ID, Node Identi= fier, and Attachment Circuit ID (AC_ID) are as per [9]. Thanks Alan From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: 03 May 2013 18:35 To: Alan Davey; rfc6428@tools.ietf.org Cc: mpls@ietf.org Subject: RE: [MPLS] A doubt about RFC 6428 Hi Alan: It is kind of implied, as in "received DOWN while NOT in a misconnectivity = state". I'm not sure adding that to the state machine diagram would actuall= y improve the clarity....I'll let others comment. cheers Dave ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of Alan Davey Sent: Friday, May 03, 2013 9:29 AM To: rfc6428@tools.ietf.org Cc: mpls@ietf.org Subject: [mpls] [MPLS] A doubt about RFC 6428 Folks I have a doubt about RFC 6428. Could you please let me know what you think= of the following. Section 3.7.4.2., Exit from a Mis-Connectivity Defect, states that "Exit fr= om a mis-connectivity defect state occurs when no CV messages with mis-conn= ectivity defects have been received for a period of 3.5 seconds". However, the State Machines in section 3.7.5 have no input corresponding to= an "Exit from a Mis-Connectivity Defect" timer pop. (Although they do hav= e a MIS-CONNECTIVITY input added by RFC 6428.) If the State Machine is fol= lowed then Down state is exited as soon as the remote system signals Down s= tate. Should the State Machines be modified such that Down state following a MIS-= CONNECTIVITY input is only exited after an "Exit from a Mis-Connectivity De= fect" timer pop input or am I missing something? Regards Alan Davey Network Technologies Metaswitch Networks alan.davey@metaswitch.com +44 (0) 20 8366 1177 network-technologies.metaswitch.com --_000_E6C17D2345AC7A45B7D054D407AA205C09E00Feusaamb105ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I agree with your proposed change.
 
cheers
Dave

From: Alan Davey [mailto:Alan.Davey= @metaswitch.com]
Sent: Tuesday, May 21, 2013 1:24 AM
To: David Allan I
Cc: mpls@ietf.org
Subject: RE: [MPLS] A doubt about RFC 6428

Hi Dave

 

Thank you for your re= sponse.  I think that it is worth raising an erratum for section 3.5.3= because the current text is confusing (note that the colon is in the RFC text).  Do you agree?

 

I propose the followi= ng.

 

Section 3.5.3

 

Original text: <= /o:p>

 

   The leng= th is the length of the

   followin= g data: the Global_ID, Node Identifier, and Attachment

   Circuit = ID (AC_ID) are as per [9].

 

Corrected text:<= /o:p>

 

   The leng= th is the length of the data following the length field.<= /p>

   The Glob= al_ID, Node Identifier, and Attachment

   Circuit = ID (AC_ID) are as per [9].

 

Thanks

Alan

 

From: David Allan I [m= ailto:david.i.allan@ericsson.com]
Sent: 13 May 2013 20:58
To: Alan Davey
Cc: mpls@ietf.org
Subject: RE: [MPLS] A doubt about RFC 6428

 

It is all in how you interpret "The length= is the length of the following data."  Which is referring to the= diagram above (e.g. the colon below is your addition), and then goes on to tells you how to find the less-obvious fields. =

If it said "The length is the length of th= e data following the length field"... it would be clearer.

Dave

From: Alan Davey [mail= to:Alan.Davey@metaswitch.com]
Sent: Thursday, May 09, 2013 3:59 AM
To: David Allan I
Cc: mpls@ietf.org
Subject: RE: [MPLS] A doubt about RFC 6428

Hi Dave

 

Thank you very much f= or getting back to me so quickly.  I have a further question on RFC 64= 28 if you have another minute.

 

In section 3.5.3,  PW End Point MEP-ID, I think that the text defining the Length= field is confusing because it is not clear if the length includes the AGI.=   The text is currently as follows.

 

  The length is = the length of the following data: the Global_ID, Node Identifier, and Attac= hment

   Circuit = ID (AC_ID) are as per [9].

 

Am I correct in think= ing that the Length field  is the length of the value fields, as for t= he Section MEP-ID in section 3.5.1 and the LSP MEP-ID in section 3.5.2?&nbs= p; That is, should the text read as follows.

 

  The length is = the length of the value fields.  The Global_ID, Node Identifier, and A= ttachment

   Circuit = ID (AC_ID) are as per [9].

 

Thanks

Alan

 

From: David Allan I [<= a href=3D"mailto:david.i.allan@ericsson.com">mailto:david.i.allan@ericsson.= com]
Sent: 03 May 2013 18:35
To: Alan Davey; rfc6428@to= ols.ietf.org
Cc: mpls@ietf.org
Subject: RE: [MPLS] A doubt about RFC 6428

 

Hi Alan:

It is kind of implied, as in "re= ceived DOWN while NOT in a misconnectivity state". I'm not sure a= dding that to the state machine diagram would actually improve the clarity....I'll let others comment.

cheers

Dave

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Alan Davey
Sent: Friday, May 03, 2013 9:29 AM
To: rfc6428@tools.ietf.org=
Cc: mpls@ietf.org
Subject: [mpls] [MPLS] A doubt about RFC 6428

Folks

 

I have a doubt about RFC 6428.  Could you pleas= e let me know what you think of the following.

 

Section 3.7.4.2., Exit from a Mis-Connectivity Defec= t, states that “Exit from a mis-connectivity defect state occurs when= no CV messages with mis-connectivity defects have been received for a peri= od of 3.5 seconds”.

 

However, the State Machines in section 3.7.5 have no= input corresponding to an “Exit from a Mis-Connectivity Defect”= ; timer pop.  (Although they do have a MIS-CONNECTIVITY input added by= RFC 6428.)  If the State Machine is followed then Down state is exited as soon as the remote system signals Down state.=

 

Should the State Machines be modified such that Down= state following a MIS-CONNECTIVITY input is only exited after an “Ex= it from a Mis-Connectivity Defect” timer pop input or am I missing so= mething?

 

Regards

Alan Davey

 

Network Technologies
Metaswitch Networks

 

alan.davey@meta= switch.com
+44 (0) 20 8366 1177
network-technologies.metaswitch.com

 

 

 

--_000_E6C17D2345AC7A45B7D054D407AA205C09E00Feusaamb105ericsso_-- From wwwrun@rfc-editor.org Tue May 21 07:14:24 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDE0921F96F4 for ; Tue, 21 May 2013 07:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.169 X-Spam-Level: X-Spam-Status: No, score=-102.169 tagged_above=-999 required=5 tests=[AWL=0.431, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IseoexpWXTa4 for ; Tue, 21 May 2013 07:14:20 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1F121F89EB for ; Tue, 21 May 2013 07:14:20 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id EF4F862100; Tue, 21 May 2013 07:13:50 -0700 (PDT) To: david.i.allan@ericsson.com, swallow@cisco.com, jdrake@juniper.net, stbryant@cisco.com, adrian@olddog.co.uk, loa@pi.nu, swallow@cisco.com, rcallon@juniper.net From: RFC Errata System Message-Id: <20130521141350.EF4F862100@rfc-editor.org> Date: Tue, 21 May 2013 07:13:50 -0700 (PDT) Cc: mpls@ietf.org, alan.davey@metaswitch.com, rfc-editor@rfc-editor.org Subject: [mpls] [Technical Errata Reported] RFC6428 (3629) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 14:14:25 -0000 The following errata report has been submitted for RFC6428, "Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6428&eid=3629 -------------------------------------- Type: Technical Reported by: Alan Davey Section: 3.5.3 Original Text ------------- The length is the length of the following data: the Global_ID, Node Identifier, and Attachment Circuit ID (AC_ID) are as per [9]. Corrected Text -------------- The length is the length of the data following the length field. The Global_ID, Node Identifier, and Attachment Circuit ID (AC_ID) are as per [9]. Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6428 (draft-ietf-mpls-tp-cc-cv-rdi-06) -------------------------------------- Title : Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile Publication Date : November 2011 Author(s) : D. Allan, Ed., G. Swallow Ed., J. Drake Ed. Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From david.i.allan@ericsson.com Tue May 21 07:17:25 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28B8B21F975D for ; Tue, 21 May 2013 07:17:25 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTJLc8Xp0aee for ; Tue, 21 May 2013 07:17:19 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id A34E521F9761 for ; Tue, 21 May 2013 07:17:19 -0700 (PDT) X-AuditID: c6180641-b7f7b6d000001a44-16-519b81ee9fd9 Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 02.A6.06724.EE18B915; Tue, 21 May 2013 16:17:19 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Tue, 21 May 2013 10:17:18 -0400 From: David Allan I To: RFC Errata System , "swallow@cisco.com" , "jdrake@juniper.net" , "stbryant@cisco.com" , "adrian@olddog.co.uk" , "loa@pi.nu" , "swallow@cisco.com" , "rcallon@juniper.net" Thread-Topic: [Technical Errata Reported] RFC6428 (3629) Thread-Index: AQHOVi2KkgPrSIG09U+ak6pwqmgNkZkPr18g Date: Tue, 21 May 2013 14:17:17 +0000 Message-ID: References: <20130521141350.EF4F862100@rfc-editor.org> In-Reply-To: <20130521141350.EF4F862100@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZXLonVvd94+xAg9cPeCx+9NxgtngybRab xZy7zhb/5s5htri1dCWrxd8VV1gsmvZ/ZbM493QOo8XtKU2MDpweU35vZPVYsuQnk8f1pqvs HkdvzmX2WLF5JaPHrOltbB4NbcdYA9ijuGxSUnMyy1KL9O0SuDK2Xt3LWPBWoGJ94yaWBsbr vF2MnBwSAiYSN+auZIewxSQu3FvP1sXIxSEkcJRRYnPvfjaQhJDAckaJY6vLQWw2AQOJPf+/ MIIUiQhcYZI4s+IMWDezQJzErHUXGEFsYQFziaf7ngHFOYCKLCTObnSDMI0k5r02BKlgEVCV eLftM9h4XgFviZudB9khVplJnPz+jAXE5gSacmHmDrAaRqDbvp9awwSxSVzi1pP5TBA3C0gs 2XOeGcIWlXj5+B8rhK0sseTJfhaIeh2JBbs/sUHY2hLLFr5mhtgrKHFy5hOWCYxis5CMnYWk ZRaSlllIWhYwsqxi5CgtTi3LTTcy3MQIjMxjEmyOOxgXfLI8xCjNwaIkztutPTVQSCA9sSQ1 OzW1ILUovqg0J7X4ECMTB6dUA+PMG1nrm7w/du+YwPIpb/PdG5cNNFkyJe4uPSOcoaUZf1Ej u+ZpRMXZcztE+UTW5MgeP5Mcep7fLvWIppbs1hixDz9OdntuKS5miZbINPSX6Ey+ZCX4UKDx 3n7NCo8jD6wXK79bpu43u1r46ZkJk9X/Trra8r1jyw3VWeyMTCo2R1/VGKZnn1diKc5INNRi LipOBAB8UfX+mgIAAA== Cc: "mpls@ietf.org" , "alan.davey@metaswitch.com" Subject: Re: [mpls] [Technical Errata Reported] RFC6428 (3629) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 14:17:25 -0000 I agree with the proposed change... Dave=20 -----Original Message----- From: RFC Errata System [mailto:rfc-editor@rfc-editor.org]=20 Sent: Tuesday, May 21, 2013 7:14 AM To: David Allan I; swallow@cisco.com; jdrake@juniper.net; stbryant@cisco.co= m; adrian@olddog.co.uk; loa@pi.nu; swallow@cisco.com; rcallon@juniper.net Cc: alan.davey@metaswitch.com; mpls@ietf.org; rfc-editor@rfc-editor.org Subject: [Technical Errata Reported] RFC6428 (3629) The following errata report has been submitted for RFC6428, "Proactive Conn= ectivity Verification, Continuity Check, and Remote Defect Indication for t= he MPLS Transport Profile". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D6428&eid=3D3629 -------------------------------------- Type: Technical Reported by: Alan Davey Section: 3.5.3 Original Text ------------- The length is the length of the following data: the Global_ID, Node Identif= ier, and Attachment Circuit ID (AC_ID) are as per [9]. =20 Corrected Text -------------- The length is the length of the data following the length field. The Globa= l_ID, Node Identifier, and Attachment Circuit ID (AC_ID) are as per [9].=20 Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Re= ply All" to discuss whether it should be verified or rejected. When a decis= ion is reached, the verifying party (IESG) can log in to change the status = and edit the report, if necessary.=20 -------------------------------------- RFC6428 (draft-ietf-mpls-tp-cc-cv-rdi-06) -------------------------------------- Title : Proactive Connectivity Verification, Continuity Check= , and Remote Defect Indication for the MPLS Transport Profile Publication Date : November 2011 Author(s) : D. Allan, Ed., G. Swallow Ed., J. Drake Ed. Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG From stbryant@cisco.com Tue May 21 07:34:14 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9C2121F981C for ; Tue, 21 May 2013 07:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=3.999, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWXMFJ1Trmq4 for ; Tue, 21 May 2013 07:34:08 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 472F621F8FDC for ; Tue, 21 May 2013 07:34:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42522; q=dns/txt; s=iport; t=1369146847; x=1370356447; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=UtbXfhValnmcVx3GpqTiyVPXUfnS0V2G262QwIYTNOU=; b=ZKKTlmOrDIeLLF2pxmIe2TxYVRVL55zSVcMrISvrwoAwj/eFS7JxgI4a EkVvqtj2FNAiv1JQRsvkDxluU8X4rG3UYKy+oWXM4iOEdBi1z9uU+desf kFLTwAcmNCW8187rEmlrnu2i0TMLallxlzm4PFxbzK1tIoBcY5/1SLl45 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8HAD2Fm1GQ/khM/2dsb2JhbABZgkREMIkZuDaBCBZ0giMBAQEDAQEBASo6BwoBBQcECxEEAQEBCRYBAQYHCQMCAQIBDwUBHwkIEwEEAQIBAQWHcgMJBgyyYw2IWYxDgSWBEB0FBgEGg04DlVKBZoEpinSFI4MQgXA X-IronPort-AV: E=Sophos;i="4.87,714,1363132800"; d="scan'208,217";a="14077899" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 21 May 2013 14:34:05 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4LEY3ZR009246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 May 2013 14:34:03 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r4LEY2Ii022906; Tue, 21 May 2013 15:34:02 +0100 (BST) Message-ID: <519B85DA.5000504@cisco.com> Date: Tue, 21 May 2013 15:34:02 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <025801ce5579$141f9160$3c5eb420$@olddog.co.uk> In-Reply-To: <025801ce5579$141f9160$3c5eb420$@olddog.co.uk> Content-Type: multipart/alternative; boundary="------------050104010406070301000609" Cc: mpls@ietf.org, 'Lizhong Jin' Subject: Re: [mpls] Retiring ACH TLVs X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 14:34:14 -0000 This is a multi-part message in MIME format. --------------050104010406070301000609 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit "If the WG prefers, we could bis 5586 to remove all discussion of the ACH TLV." Noting that this will inevitably take longer, and is not mutually exclusive with this approach. However the longer we take the longer we will have to answer the question about why we say we preclude them in each ACK draft. ... but is up to the WG, we can follow either path. Stewart On 20/05/2013 17:42, Adrian Farrel wrote: > > Hi Lizhong, > > I just went back and checked 5586. > > In Section 4 it talks about "ACH TLVs if present." And I am working on > the assumption that if TLVs are not defined, they will never be > present, so the text doesn't actually need updating. > > In Section10 there is the IANA work to create the ACH TLV registry and > add the column to the ACH Type registry. We are directly instructing > IANA to remove that from the registry, and I don't think that 5586 > needs to be updated. > > Our aim was minimal and clear update to 5586 rather than a new revision. > > If the WG prefers, we could bis 5586 to remove all discussion of the > ACH TLV. > > Thanks, > > Adrian > > *From:*Lizhong Jin [mailto:lizho.jin@gmail.com] > *Sent:* 17 May 2013 06:44 > *To:* mpls@ietf.org; adrian@olddog.co.uk > *Subject:* Re: [mpls] Retiring ACH TLVs > > Hi, > > Support, and I like this. But it seems deleting section 3 in RFC5586 > is not enough. Other sections in RFC5586 also has the content of ACH > TLV. Is it engouth to update by only deleting section 3 described in > this draft? > > Lizhong > > > > > On Tue, May 7, 2013 at 1:08 PM, Adrian Farrel > wrote: > > > Hi, > > > > ACH TLVs keep popping up and causing Stewart and me trouble. > Mainly it is > > about explaining why no-one actually wants to use them (i.e., > when each new > > ACH Type is defined and has a "No TLVs" written for it, we get > asked "why > > not?"). > > > > It seems to us that ACH TLVs are an idea that has been rejected. > Initially > > we thought they might be used (especially for identifiers), but > there seems > > to be good opinion that handling generic TLVs would be a pain. > > > > Since I was heavily responsible for insisting that ACH TLVs were > included > > in RFC 5586, it seems reasonable that I do the work to fix it. > > > > The I-D below retires ACH TLVs and handles the necessary > registry changes. > > > > Note, of course, that structured data are still possible within > individual > > ACHs if the protocol spec for an individual ACH decides to have > them. > > > > We're directing this work to the MPLS working group because that > is where > > 5586 was written. I have BCC'ed PWE3, L2VPN, and BFD for > information. > > > > Thanks for any comments. > > > > As humble WG contributors we would be enthusiastic to see early WG > > adoption and last call :-) > > > > Thanks, > > Adrian > > > > > -----Original Message----- > > > From: internet-drafts@ietf.org > [mailto:internet-drafts@ietf.org > ] > > > Sent: 07 May 2013 17:33 > > > To: Adrian Farrel; Stewart Bryant > > > Subject: New Version Notification for > > draft-farbryantrel-mpls-retire-ach-tlv- > > > 00.txt > > > > > > > > > A new version of I-D, > draft-farbryantrel-mpls-retire-ach-tlv-00.txt > > > has been successfully submitted by Adrian Farrel and posted to the > > > IETF repository. > > > > > > Filename: draft-farbryantrel-mpls-retire-ach-tlv > > > Revision: 00 > > > Title: Retiring TLVs from the Associated > Channel Header > > of the MPLS > > > Generic Associated Channel > > > Creation date: 2013-05-07 > > > Group: Individual Submission > > > Number of pages: 4 > > > URL: > > http://www.ietf.org/internet-drafts/draft-farbryantrel-mpls-retire- > > > ach-tlv-00.txt > > > Status: > > > http://datatracker.ietf.org/doc/draft-farbryantrel-mpls-retire-ach-tlv > > > Htmlized: > > http://tools.ietf.org/html/draft-farbryantrel-mpls-retire-ach-tlv-00 > > > > > > > > > Abstract: > > > The MPLS Generic Associated Channel (G-ACh) is a > generalization of > > > the applicability of the Pseudowire (PW) Associated Channel > Header > > > (ACH). RFC 5586 defines the concept of > Type-Length-Variable (TLV) > > > constructs that can be carried in messages on the G-ACh by > placing > > > them in the ACH. > > > > > > No Associated Channel Type yet defined uses a TLV. > Furthermore, it > > > is believed that handling TLVs in hardware introduces > significant > > > problems to the fast-path, and since G-ACh messages are > intended to > > > be processed substantially in hardware, the use of TLVs in > > > undesirable. > > > > > > This document updates RFC 5586 by retiring ACH TLVs and > removing the > > > associated registry. > > > > > > > > > > > > > > > The IETF Secretariat > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > ------------------------------ > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------050104010406070301000609 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
"If the WG prefers, we could bis 5586 to remove all discussion of the ACH TLV."

Noting that this will inevitably take longer, and is not mutually
exclusive with this approach. However the longer we take the
longer we will have to answer the question about why
we say we preclude them in each ACK draft.

... but is up to the WG, we can follow either path.

Stewart


On 20/05/2013 17:42, Adrian Farrel wrote:

Hi Lizhong,

 

I just went back and checked 5586.

 

In Section 4 it talks about "ACH TLVs if present." And I am working on the assumption that if TLVs are not defined, they will never be present, so the text doesn't actually need updating.

 

In Section  10 there is the IANA work to create the ACH TLV registry and add the column to the ACH Type registry. We are directly instructing IANA to remove that from the registry, and I don't think that 5586 needs to be updated.

 

Our aim was minimal and clear update to 5586 rather than a new revision.

 

If the WG prefers, we could bis 5586 to remove all discussion of the ACH TLV.

 

Thanks,

Adrian

 

From: Lizhong Jin [mailto:lizho.jin@gmail.com]
Sent: 17 May 2013 06:44
To: mpls@ietf.org; adrian@olddog.co.uk
Subject: Re: [mpls] Retiring ACH TLVs

 

Hi,

Support, and I like this. But it seems deleting section 3 in RFC5586 is not enough. Other sections in RFC5586 also has the content of ACH TLV. Is it engouth to update by only deleting section 3 described in this draft?

 

Lizhong


 



On Tue, May 7, 2013 at 1:08 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:

> Hi,
>
> ACH TLVs keep popping up and causing Stewart and me trouble. Mainly it is
> about explaining why no-one actually wants to use them (i.e., when each new
> ACH Type is defined and has a "No TLVs" written for it, we get asked "why
> not?").
>
> It seems to us that ACH TLVs are an idea that has been rejected. Initially
> we thought they might be used (especially for identifiers), but there seems
> to be good opinion that handling generic TLVs would be a pain.
>
> Since I was heavily responsible for insisting that ACH TLVs were included
> in RFC 5586, it seems reasonable that I do the work to fix it.
>
> The I-D below retires ACH TLVs and handles the necessary registry changes.
>
> Note, of course, that structured data are still possible within individual
> ACHs if the protocol spec for an individual ACH decides to have them.
>
> We're directing this work to the MPLS working group because that is where
> 5586 was written. I have BCC'ed PWE3, L2VPN, and BFD for information.
>
> Thanks for any comments.
>
> As humble WG contributors we would be enthusiastic to see early WG
> adoption and last call :-)
>
> Thanks,
> Adrian
>
> > -----Original Message-----
> > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > Sent: 07 May 2013 17:33
> > To: Adrian Farrel; Stewart Bryant
> > Subject: New Version Notification for
> draft-farbryantrel-mpls-retire-ach-tlv-
> > 00.txt
> >
> >
> > A new version of I-D, draft-farbryantrel-mpls-retire-ach-tlv-00.txt
> > has been successfully submitted by Adrian Farrel and posted to the
> > IETF repository.
> >
> > Filename:      draft-farbryantrel-mpls-retire-ach-tlv
> > Revision:      00
> > Title:                 Retiring TLVs from the Associated Channel Header
> of the MPLS
> > Generic Associated Channel
> > Creation date:         2013-05-07
> > Group:                 Individual Submission
> > Number of pages: 4
> > URL:
> http://www.ietf.org/internet-drafts/draft-farbryantrel-mpls-retire-
> > ach-tlv-00.txt
> > Status:
> http://datatracker.ietf.org/doc/draft-farbryantrel-mpls-retire-ach-tlv
> > Htmlized:
> http://tools.ietf.org/html/draft-farbryantrel-mpls-retire-ach-tlv-00
> >
> >
> > Abstract:
> >    The MPLS Generic Associated Channel (G-ACh) is a generalization of
> >    the applicability of the Pseudowire (PW) Associated Channel Header
> >    (ACH).  RFC 5586 defines the concept of Type-Length-Variable (TLV)
> >    constructs that can be carried in messages on the G-ACh by placing
> >    them in the ACH.
> >
> >    No Associated Channel Type yet defined uses a TLV.  Furthermore, it
> >    is believed that handling TLVs in hardware introduces significant
> >    problems to the fast-path, and since G-ACh messages are intended to
> >    be processed substantially in hardware, the use of TLVs in
> >    undesirable.
> >
> >    This document updates RFC 5586 by retiring ACH TLVs and removing the
> >    associated registry.
> >
> >
> >
> >
> > The IETF Secretariat
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/mpls/attachments/20130516/f560777c/attachment.htm>

------------------------------



_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls



-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------050104010406070301000609-- From lizho.jin@gmail.com Tue May 21 07:57:12 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCE7021F9830 for ; Tue, 21 May 2013 07:57: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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mVr6NswLLPE for ; Tue, 21 May 2013 07:57:11 -0700 (PDT) Received: from mail-qa0-x235.google.com (mail-qa0-x235.google.com [IPv6:2607:f8b0:400d:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 8959E21F97E6 for ; Tue, 21 May 2013 07:57:11 -0700 (PDT) Received: by mail-qa0-f53.google.com with SMTP id bs12so433561qab.5 for ; Tue, 21 May 2013 07:57:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nyIzN9crGndYyN95Cjd6C3VcVopIGIkpJ2MLlhogX4w=; b=ACOscvv9HDWnPzKb958HyNLa1DMPq+nNtVEw5/wE8iqHiyoQgO2f3mxmji8i4c93WK 3iYFGcpCegDuXhOIzFdnjxJVftRHhUM6kEQkOX1y2QIXImUDC/NO1iYDyWVQCWWyL5uH 3QEpnvDOUz2zOuvBZrTh13AkXUmRUJ5PPS6U7RsyQjlzuAs98Zm20IvYpP3H+tRhuY44 fyhLzI1MpfXtM1Z31lZLRThXY//xv5XJQC4FHQ8PZvsl9grc+gCtlWqm29/U/mH0wopm DKggB3Q1Rb5LiALwHW3umro9EthMg3/h9nrlqBjhQsEEdSxYqv563VwlZO6lj/UmGF5g 9Bjg== MIME-Version: 1.0 X-Received: by 10.229.64.69 with SMTP id d5mr977718qci.38.1369148230906; Tue, 21 May 2013 07:57:10 -0700 (PDT) Received: by 10.49.25.11 with HTTP; Tue, 21 May 2013 07:57:10 -0700 (PDT) In-Reply-To: <025801ce5579$141f9160$3c5eb420$@olddog.co.uk> References: <025801ce5579$141f9160$3c5eb420$@olddog.co.uk> Date: Tue, 21 May 2013 22:57:10 +0800 Message-ID: From: Lizhong Jin To: "adrian@olddog.co.uk" Content-Type: multipart/alternative; boundary=089e0163525af2bf8d04dd3ba9ed Cc: "mpls@ietf.org" Subject: Re: [mpls] Retiring ACH TLVs X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 14:57:12 -0000 --089e0163525af2bf8d04dd3ba9ed Content-Type: text/plain; charset=ISO-8859-1 Hi Adrian, > In Section 4 it talks about "ACH TLVs if present." And I am working on the > assumption that if TLVs are not defined, they will never be present, so the > text doesn't actually need updating. > [Lizhong] Thanks for the reply. I do not have strong preferrence for bising RFC5586. A note in section 2 maybe be enough, e.g, since ACH TLV has been removed, the ACH TLV description in section 4 will also be removed. Thanks Lizhong > ** > > In Section 10 there is the IANA work to create the ACH TLV registry and > add the column to the ACH Type registry. We are directly instructing IANA > to remove that from the registry, and I don't think that 5586 needs to be > updated.**** > > ** ** > > Our aim was minimal and clear update to 5586 rather than a new revision. * > *** > > ** ** > > If the WG prefers, we could bis 5586 to remove all discussion of the ACH > TLV.**** > > ** ** > > Thanks,**** > > Adrian**** > > ** ** > > *From:* Lizhong Jin [mailto:lizho.jin@gmail.com] > *Sent:* 17 May 2013 06:44 > *To:* mpls@ietf.org; adrian@olddog.co.uk > *Subject:* Re: [mpls] Retiring ACH TLVs**** > > ** ** > > Hi,**** > > Support, and I like this. But it seems deleting section 3 in RFC5586 is > not enough. Other sections in RFC5586 also has the content of ACH TLV. Is > it engouth to update by only deleting section 3 described in this draft?** > ** > > **** > > Lizhong**** > > > **** > > > > On Tue, May 7, 2013 at 1:08 PM, Adrian Farrel wrote: > > > Hi, > > > > ACH TLVs keep popping up and causing Stewart and me trouble. Mainly it is > > about explaining why no-one actually wants to use them (i.e., when each > new > > ACH Type is defined and has a "No TLVs" written for it, we get asked "why > > not?"). > > > > It seems to us that ACH TLVs are an idea that has been rejected. > Initially > > we thought they might be used (especially for identifiers), but there > seems > > to be good opinion that handling generic TLVs would be a pain. > > > > Since I was heavily responsible for insisting that ACH TLVs were included > > in RFC 5586, it seems reasonable that I do the work to fix it. > > > > The I-D below retires ACH TLVs and handles the necessary registry > changes. > > > > Note, of course, that structured data are still possible within > individual > > ACHs if the protocol spec for an individual ACH decides to have them. > > > > We're directing this work to the MPLS working group because that is where > > 5586 was written. I have BCC'ed PWE3, L2VPN, and BFD for information. > > > > Thanks for any comments. > > > > As humble WG contributors we would be enthusiastic to see early WG > > adoption and last call :-) > > > > Thanks, > > Adrian > > > > > -----Original Message----- > > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > > Sent: 07 May 2013 17:33 > > > To: Adrian Farrel; Stewart Bryant > > > Subject: New Version Notification for > > draft-farbryantrel-mpls-retire-ach-tlv- > > > 00.txt > > > > > > > > > A new version of I-D, draft-farbryantrel-mpls-retire-ach-tlv-00.txt > > > has been successfully submitted by Adrian Farrel and posted to the > > > IETF repository. > > > > > > Filename: draft-farbryantrel-mpls-retire-ach-tlv > > > Revision: 00 > > > Title: Retiring TLVs from the Associated Channel Header > > of the MPLS > > > Generic Associated Channel > > > Creation date: 2013-05-07 > > > Group: Individual Submission > > > Number of pages: 4 > > > URL: > > http://www.ietf.org/internet-drafts/draft-farbryantrel-mpls-retire- > > > ach-tlv-00.txt > > > Status: > > http://datatracker.ietf.org/doc/draft-farbryantrel-mpls-retire-ach-tlv > > > Htmlized: > > http://tools.ietf.org/html/draft-farbryantrel-mpls-retire-ach-tlv-00 > > > > > > > > > Abstract: > > > The MPLS Generic Associated Channel (G-ACh) is a generalization of > > > the applicability of the Pseudowire (PW) Associated Channel Header > > > (ACH). RFC 5586 defines the concept of Type-Length-Variable (TLV) > > > constructs that can be carried in messages on the G-ACh by placing > > > them in the ACH. > > > > > > No Associated Channel Type yet defined uses a TLV. Furthermore, it > > > is believed that handling TLVs in hardware introduces significant > > > problems to the fast-path, and since G-ACh messages are intended to > > > be processed substantially in hardware, the use of TLVs in > > > undesirable. > > > > > > This document updates RFC 5586 by retiring ACH TLVs and removing the > > > associated registry. > > > > > > > > > > > > > > > The IETF Secretariat > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://www.ietf.org/mail-archive/web/mpls/attachments/20130516/f560777c/attachment.htm > > > > ------------------------------**** > > --089e0163525af2bf8d04dd3ba9ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Adrian,

In Section 4 it talks about "ACH TLVs if present." And I am wo= rking on the assumption that if TLVs are not defined, they will never be pr= esent, so the text doesn't actually need updating.

[Lizhong] Thanks for the reply. I do not have= strong preferrence for bising RFC5586. A note in section 2 maybe be enough= , e.g, since ACH TLV has been removed, the ACH TLV description in section 4= will also be removed.=A0

Thanks
Lizhong
=A0

In Section=A0 10 th= ere is the IANA work to create the ACH TLV registry and add the column to t= he ACH Type registry. We are directly instructing IANA to remove that from = the registry, and I don't think that 5586 needs to be updated.

=A0

Our= aim was minimal and clear update to 5586 rather than a new revision.

=A0

If = the WG prefers, we could bis 5586 to remove all discussion of the ACH TLV.<= u>

=A0

Tha= nks,

Adrian

= =A0

From: Lizhong Jin [mailto:lizho.jin@gmail.com]
Sent: 17 May 2013 06:44
To: mpls@ietf.org; adrian@olddog.co.uk
Subject: Re: [mpls]= Retiring ACH TLVs

=A0

=

Hi,

Support, a= nd I like this. But it seems deleting section 3 in RFC5586 is not enough. O= ther sections in RFC5586 also has the content of ACH TLV. Is it engouth to = update by only deleting section 3 described in this draft?

=A0

Lizh= ong


=A0



On Tue, May 7, 2013 at 1:08 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:

> Hi,
>
> ACH TLVs keep popping up and = causing Stewart and me trouble. Mainly it is
> about explaining why no-one actually wants to use them (i.e., when eac= h new
> ACH Type is defined and has a "No TLVs" written for= it, we get asked "why
> not?").
>
> It seems t= o us that ACH TLVs are an idea that has been rejected. Initially
> we thought they might be used (especially for identifiers), but there = seems
> to be good opinion that handling generic TLVs would be a pain= .
>
> Since I was heavily responsible for insisting that ACH TL= Vs were included
> in RFC 5586, it seems reasonable that I do the work to fix it.
>=
> The I-D below retires ACH TLVs and handles the necessary registry = changes.
>
> Note, of course, that structured data are still po= ssible within individual
> ACHs if the protocol spec for an individual ACH decides to have them.<= br>>
> We're directing this work to the MPLS working group bec= ause that is where
> 5586 was written. I have BCC'ed PWE3, L2VPN,= and BFD for information.
>
> Thanks for any comments.
>
> As humble WG contribu= tors we would be enthusiastic to see early WG
> adoption and last cal= l :-)
>
> Thanks,
> Adrian
>
> > -----Orig= inal Message-----
> > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> > Sent:= 07 May 2013 17:33
> > To: Adrian Farrel; Stewart Bryant
> > Subject: New Versi= on Notification for
> draft-farbryantrel-mpls-retire-ach-tlv-
>= > 00.txt
> >
> >
> > A new version of I-D, d= raft-farbryantrel-mpls-retire-ach-tlv-00.txt
> > has been successfully submitted by Adrian Farrel and posted to th= e
> > IETF repository.
> >
> > Filename: =A0 =A0= =A0draft-farbryantrel-mpls-retire-ach-tlv
> > Revision: =A0 =A0 = =A000
> > Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Retiring TLVs from the Ass= ociated Channel Header
> of the MPLS
> > Generic Associated = Channel
> > Creation date: =A0 =A0 =A0 =A0 2013-05-07
> >= Group: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Individual Submission
> > Number of pages: 4
> > URL:
> http://www.ietf.org/internet-drafts/draft-farbryantrel-mpls-retire-<= br> > > ach-tlv-00.txt
> > Status:
> http://datatracker.ietf.org/doc/draft-farbryantrel-mpls-retire-ach-tlv=
> > Htmlized:
> http://tools.ietf.org/h= tml/draft-farbryantrel-mpls-retire-ach-tlv-00
> >
> >=
> > Abstract:
> > =A0 =A0The MPLS Generic Associated Channel= (G-ACh) is a generalization of
> > =A0 =A0the applicability of th= e Pseudowire (PW) Associated Channel Header
> > =A0 =A0(ACH). =A0R= FC 5586 defines the concept of Type-Length-Variable (TLV)
> > =A0 =A0constructs that can be carried in messages on the G-ACh by= placing
> > =A0 =A0them in the ACH.
> >
> > =A0= =A0No Associated Channel Type yet defined uses a TLV. =A0Furthermore, it> > =A0 =A0is believed that handling TLVs in hardware introduces si= gnificant
> > =A0 =A0problems to the fast-path, and since G-ACh messages are in= tended to
> > =A0 =A0be processed substantially in hardware, the u= se of TLVs in
> > =A0 =A0undesirable.
> >
> > = =A0 =A0This document updates RFC 5586 by retiring ACH TLVs and removing the=
> > =A0 =A0associated registry.
> >
> >
> >= ;
> >
> > The IETF Secretariat
>
> __________= _____________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
--------------= next part --------------
An HTML attachment was scrubbed...
URL: <= ;http://www.ietf.org/mail-archive= /web/mpls/attachments/20130516/f560777c/attachment.htm>

------------------------------


--089e0163525af2bf8d04dd3ba9ed-- From eric.gray@ericsson.com Tue May 21 08:14:48 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B74E21F9003 for ; Tue, 21 May 2013 08:14:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m77y+Q0JJl7J for ; Tue, 21 May 2013 08:14:42 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id A656521F8FEC for ; Tue, 21 May 2013 08:14:42 -0700 (PDT) X-AuditID: c618062d-b7fb56d0000042e1-02-519b8f60e028 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 01.CB.17121.16F8B915; Tue, 21 May 2013 17:14:41 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Tue, 21 May 2013 11:14:40 -0400 From: Eric Gray To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] poll to see if we have consensus to make draft-jjb-mpls-rsvp-te-hsmp-lsp an MPLS wg document Thread-Index: AQHOUl3EnkN5IwrH0kC3iE0K4vUjd5kPxwKg Date: Tue, 21 May 2013 15:14:40 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF60ADC2C@eusaamb107.ericsson.se> References: <51951C17.8010906@pi.nu> In-Reply-To: <51951C17.8010906@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrDLMWRmVeSWpSXmKPExsUyuXRPlG5i/+xAg/ntohafjkxlt/g3dw6z xfdLS1gsbi1dyerA4rFkyU8mj1nT29g8vlz+zBbAHMVlk5Kak1mWWqRvl8CV0b+/naXgM3fF 5rdPWBoYD3B2MXJySAiYSHw8sY4NwhaTuHBvPZDNxSEkcJRRYtm/U0wQznJGiXtdz1hAqtgE NCSO3VnLCGKLCNhJbHz1jxGkiFlgCaPE7akNTCAJYYEiiaVHV7BAFBVLrL92l7WLkQPINpJY MTkeJMwioCrx785PZhCbV8BbYs60X2AlQgIqEpde6IGEOYFK2u6sZAWxGYGO+35qDdh0ZgFx iVtP5jNBHC0gsWTPeWYIW1Ti5eN/rBC2ssSSJ/tZIOp1JBbs/sQGYWtLLFv4GmqtoMTJmU9Y JjCKzUIydhaSlllIWmYhaVnAyLKKkaO0OLUsN93IYBMjMIaOSbDp7mDc89LyEKM0B4uSOG+r 9tRAIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYxaqnci2SeUJv8/XNGYvXJbYEVwRgOf3pM3 /AdLW3ifi7n3Twtnn+q+f3YkQ91s+aXihoyBqWueuC7otwtqivPJOnGnbcaa21qHX1a3e5zu P20/5ejrlu0W7Lt2cd+Kc161taggxXzF+3/ML0V+dU6aFPswWbZAql7NQvjOa7fy9pgAbbH5 XEosxRmJhlrMRcWJANA2vZtvAgAA Cc: "draft-jjb-mpls-rsvp-te-hsmp-lsp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus to make draft-jjb-mpls-rsvp-te-hsmp-lsp an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 15:14:48 -0000 Support. -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Thursday, May 16, 2013 1:49 PM To: mpls@ietf.org Cc: draft-jjb-mpls-rsvp-te-hsmp-lsp@tools.ietf.org; mpls-chairs@tools.ietf.= org Subject: [mpls] poll to see if we have consensus to make draft-jjb-mpls-rsv= p-te-hsmp-lsp an MPLS wg document Working Group, This is to start a two week poll on adopting draft-jjb-mpls-rsvp-te-hsmp-lsp-04 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group m= ailing list (mpls@ietf.org). Please give a technical motivation for your su= pport/not support, especially if you think that the document should not be = adopted as a working group document. This poll ends May 31, 2013. There are one IPR claim against this document, see IPR claim #1840. The authors has stated on the working group mailing list that they are not = aware of any other IPR claims against this draft. However if you are on the the mpls working group mailing list and aware of = IPR that relates to this draft, the time to disclose this is now. /Loa (mpls wg co-chair) --=20 Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From eric.gray@ericsson.com Tue May 21 08:41:06 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10BF521F9722 for ; Tue, 21 May 2013 08:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtcPIF5ed5Lt for ; Tue, 21 May 2013 08:41:00 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 48DE421F9714 for ; Tue, 21 May 2013 08:41:00 -0700 (PDT) X-AuditID: c618062d-b7fb56d0000042e1-b0-519b958b6a18 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 7E.7D.17121.B859B915; Tue, 21 May 2013 17:40:59 +0200 (CEST) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0328.009; Tue, 21 May 2013 11:40:56 -0400 From: Eric Gray To: "adrian@olddog.co.uk" , "Stewart Bryant (stbryant) (stbryant@cisco.com)" Thread-Topic: [mpls] Retiring ACH TLVs Thread-Index: AQHOUsGO0irUVDlgRIKUWSY/7OcnkJkOj7EAgAE6KXA= Date: Tue, 21 May 2013 15:40:55 +0000 Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF60ADCBC@eusaamb107.ericsson.se> References: <025801ce5579$141f9160$3c5eb420$@olddog.co.uk> In-Reply-To: <025801ce5579$141f9160$3c5eb420$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_48E1A67CB9CA044EADFEAB87D814BFF60ADCBCeusaamb107ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyuXSPt2731NmBBseumFn86LnBbLHi9DNm i1tLV7JanHs6h9GBxWPK742sHjtn3WX3WLLkJ5PHis0rGQNYorhsUlJzMstSi/TtErgyJva8 YC2Yd4yx4ur7XrYGxk1rGLsYOTkkBEwkDkxsYoawxSQu3FvP1sXIxSEkcJRR4s7D11DOckaJ 40tOsIBUsQloSBy7sxaom4NDRKBC4sqBAJAws4CHxOl7J9lBbGEBVYkTS06DDRURUJPYf/oz C4RtJfHxCMhMTg4WoJpTl9uYQMbwCnhLLJ8mDLGqkVFi5e4GsHpOAWuJ7uPLwOoZgY77fmoN E8QucYlbT+YzQRwtILFkz3moB0QlXj7+xwphK0ssebKfBaI+X2LSghlg9bwCghInZz5hmcAo OgvJqFlIymYhKYOI60gs2P2JDcLWlli28DUzjH3mwGMmZPEFjOyrGDlKi1PLctONDDYxAiPw mASb7g7GPS8tDzFKc7AoifO2ak8NFBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cC45cVt1iPu VxUTH/+3mH9w+esKOU25M/MWhP3+bLyya7pX9ZnosJcGpw4VVvznPRzw1D7QWPDcOsEzq2pn HFnrLrhxX4mcTOLbFXy+aqYtKrMS2lZXPjw9RePf1T6dt09/eBzT3btvdXQAU7zflFSdR+Ln Wx/5H9kpsfK+kN3x+yfWTvmk5x8UqMRSnJFoqMVcVJwIALkNAwaOAgAA Cc: "mpls@ietf.org" , 'Lizhong Jin' Subject: Re: [mpls] Retiring ACH TLVs X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 15:41:06 -0000 --_000_48E1A67CB9CA044EADFEAB87D814BFF60ADCBCeusaamb107ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adrian/Stewart, I believe that past precedence exists in abundance to indic= ate that - if we produce an RFC that updates RFC 5586, we do not also need to produce an RFC that replaces = it for the same purpose. For instance, RFC 5586 was updated by RFC 6423. There are a number of RFCs that change the name space(s) de= fined in an earlier RFC for IANA's management. I believe that - as long as IANA has an unambiguous und= erstanding of the current applicable state for registries IANA manages - an updating RFC is s= ufficient. If we were - for some reason - required to replace RFC 5586= at a later date (this might be needed to "advance" the standard, for instance), I assume we would "roll-up= " all updates (and errata) that are still applicable. Once an update that removes ACH TLVs has been published (or= is near to being published), it should no longer be necessary for folks submitting related drafts to exp= lain why ACH TLVs are not supported. Therefore I support the quicker approach of publishing an R= FC to update RFC 5586 and suggest that this is sufficient for now. -- Eric From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Adr= ian Farrel Sent: Monday, May 20, 2013 12:43 PM To: 'Lizhong Jin' Cc: mpls@ietf.org Subject: Re: [mpls] Retiring ACH TLVs Hi Lizhong, I just went back and checked 5586. In Section 4 it talks about "ACH TLVs if present." And I am working on the = assumption that if TLVs are not defined, they will never be present, so the= text doesn't actually need updating. In Section 10 there is the IANA work to create the ACH TLV registry and ad= d the column to the ACH Type registry. We are directly instructing IANA to = remove that from the registry, and I don't think that 5586 needs to be upda= ted. Our aim was minimal and clear update to 5586 rather than a new revision. If the WG prefers, we could bis 5586 to remove all discussion of the ACH TL= V. Thanks, Adrian From: Lizhong Jin [mailto:lizho.jin@gmail.com] Sent: 17 May 2013 06:44 To: mpls@ietf.org; adrian@olddog.co.uk Subject: Re: [mpls] Retiring ACH TLVs Hi, Support, and I like this. But it seems deleting section 3 in RFC5586 is not= enough. Other sections in RFC5586 also has the content of ACH TLV. Is it e= ngouth to update by only deleting section 3 described in this draft? Lizhong On Tue, May 7, 2013 at 1:08 PM, Adrian Farrel > wrote: > Hi, > > ACH TLVs keep popping up and causing Stewart and me trouble. Mainly it is > about explaining why no-one actually wants to use them (i.e., when each n= ew > ACH Type is defined and has a "No TLVs" written for it, we get asked "why > not?"). > > It seems to us that ACH TLVs are an idea that has been rejected. Initiall= y > we thought they might be used (especially for identifiers), but there see= ms > to be good opinion that handling generic TLVs would be a pain. > > Since I was heavily responsible for insisting that ACH TLVs were included > in RFC 5586, it seems reasonable that I do the work to fix it. > > The I-D below retires ACH TLVs and handles the necessary registry changes= . > > Note, of course, that structured data are still possible within individua= l > ACHs if the protocol spec for an individual ACH decides to have them. > > We're directing this work to the MPLS working group because that is where > 5586 was written. I have BCC'ed PWE3, L2VPN, and BFD for information. > > Thanks for any comments. > > As humble WG contributors we would be enthusiastic to see early WG > adoption and last call :-) > > Thanks, > Adrian > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto= :internet-drafts@ietf.org] > > Sent: 07 May 2013 17:33 > > To: Adrian Farrel; Stewart Bryant > > Subject: New Version Notification for > draft-farbryantrel-mpls-retire-ach-tlv- > > 00.txt > > > > > > A new version of I-D, draft-farbryantrel-mpls-retire-ach-tlv-00.txt > > has been successfully submitted by Adrian Farrel and posted to the > > IETF repository. > > > > Filename: draft-farbryantrel-mpls-retire-ach-tlv > > Revision: 00 > > Title: Retiring TLVs from the Associated Channel Header > of the MPLS > > Generic Associated Channel > > Creation date: 2013-05-07 > > Group: Individual Submission > > Number of pages: 4 > > URL: > http://www.ietf.org/internet-drafts/draft-farbryantrel-mpls-retire- > > ach-tlv-00.txt > > Status: > http://datatracker.ietf.org/doc/draft-farbryantrel-mpls-retire-ach-tlv > > Htmlized: > http://tools.ietf.org/html/draft-farbryantrel-mpls-retire-ach-tlv-00 > > > > > > Abstract: > > The MPLS Generic Associated Channel (G-ACh) is a generalization of > > the applicability of the Pseudowire (PW) Associated Channel Header > > (ACH). RFC 5586 defines the concept of Type-Length-Variable (TLV) > > constructs that can be carried in messages on the G-ACh by placing > > them in the ACH. > > > > No Associated Channel Type yet defined uses a TLV. Furthermore, it > > is believed that handling TLVs in hardware introduces significant > > problems to the fast-path, and since G-ACh messages are intended to > > be processed substantially in hardware, the use of TLVs in > > undesirable. > > > > This document updates RFC 5586 by retiring ACH TLVs and removing the > > associated registry. > > > > > > > > > > The IETF Secretariat > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ --_000_48E1A67CB9CA044EADFEAB87D814BFF60ADCBCeusaamb107ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Adrian/Stewart,

 <= /p>

    &= nbsp;           I believe= that past precedence exists in abundance to indicate that – if we pr= oduce an RFC

that updates RFC 5586, we do not also need to produce an RF= C that replaces it for the same purpose.

 <= /p>

    &= nbsp;           For insta= nce, RFC 5586 was updated by RFC 6423.

 <= /p>

    &= nbsp;           There are= a number of RFCs that change the name space(s) defined in an earlier RFC f= or

IANA's management.  = I believe that – as long as IANA has an unambiguous understanding of = the

current applicable state = for registries IANA manages – an updating RFC is sufficient.

 <= /p>

    &= nbsp;           If we wer= e – for some reason – required to replace RFC 5586 at a later d= ate (this might be

needed to "advance&q= uot; the standard, for instance), I assume we would "roll-up" all= updates (and errata)

that are still applicable= .

 <= /p>

    &= nbsp;           Once an u= pdate that removes ACH TLVs has been published (or is near to being publish= ed),

it should no longer be ne= cessary for folks submitting related drafts to explain why ACH TLVs are not=

supported.

 <= /p>

    &= nbsp;           Therefore= I support the quicker approach of publishing an RFC to update RFC 5586 and

suggest that this is suff= icient for now.

 <= /p>

--

Eric

 <= /p>

From: mpls-bou= nces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Monday, May 20, 2013 12:43 PM
To: 'Lizhong Jin'
Cc: mpls@ietf.org
Subject: Re: [mpls] Retiring ACH TLVs

 

Hi Lizhong= ,

 = ;

I just wen= t back and checked 5586.

 = ;

In Section= 4 it talks about "ACH TLVs if present." And I am working on the = assumption that if TLVs are not defined, they will never be present, so the text doesn't actually need updating.

 = ;

In Section=   10 there is the IANA work to create the ACH TLV registry and add the= column to the ACH Type registry. We are directly instructing IANA to remove that from the registry, and I don't think that 5586 needs to be = updated.

 = ;

Our aim wa= s minimal and clear update to 5586 rather than a new revision.

 = ;

If the WG = prefers, we could bis 5586 to remove all discussion of the ACH TLV.

 = ;

Thanks,

Adrian

 = ;

From: Lizhong = Jin [mailto:lizho.jin@gmail.com]
Sent: 17 May 2013 06:44
To: mpls@ietf.org; adrian@olddog.co.uk
Subject: Re: [mpls] Retiring ACH TLVs

 

Hi,

Support, and I like this. But i= t seems deleting section 3 in RFC5586 is not enough. Other sections in RFC5= 586 also has the content of ACH TLV. Is it engouth to update by only deleti= ng section 3 described in this draft?

 

Lizhong


 



On Tue, May 7, 2013 at 1:08 PM, Adrian Farrel <adrian@olddog.co.uk> wrote:

> Hi,
>
> ACH TLVs keep popping up and causing Stewart and me trouble. Mainly it= is
> about explaining why no-one actually wants to use them (i.e., when eac= h new
> ACH Type is defined and has a "No TLVs" written for it, we g= et asked "why
> not?").
>
> It seems to us that ACH TLVs are an idea that has been rejected. Initi= ally
> we thought they might be used (especially for identifiers), but there = seems
> to be good opinion that handling generic TLVs would be a pain.
>
> Since I was heavily responsible for insisting that ACH TLVs were inclu= ded
> in RFC 5586, it seems reasonable that I do the work to fix it.
>
> The I-D below retires ACH TLVs and handles the necessary registry chan= ges.
>
> Note, of course, that structured data are still possible within indivi= dual
> ACHs if the protocol spec for an individual ACH decides to have them.<= br> >
> We're directing this work to the MPLS working group because that is wh= ere
> 5586 was written. I have BCC'ed PWE3, L2VPN, and BFD for information.<= br> >
> Thanks for any comments.
>
> As humble WG contributors we would be enthusiastic to see early WG
> adoption and last call :-)
>
> Thanks,
> Adrian
>
> > -----Original Message-----
> > From: internet-drafts= @ietf.org [mailto:internet-= drafts@ietf.org]
> > Sent: 07 May 2013 17:33
> > To: Adrian Farrel; Stewart Bryant
> > Subject: New Version Notification for
> draft-farbryantrel-mpls-retire-ach-tlv-
> > 00.txt
> >
> >
> > A new version of I-D, draft-farbryantrel-mpls-retire-ach-tlv-00.t= xt
> > has been successfully submitted by Adrian Farrel and posted to th= e
> > IETF repository.
> >
> > Filename:      draft-farbryantrel-mpls-retire-ach-= tlv
> > Revision:      00
> > Title:                 Re= tiring TLVs from the Associated Channel Header
> of the MPLS
> > Generic Associated Channel
> > Creation date:         2013-05-07
> > Group:                 In= dividual Submission
> > Number of pages: 4
> > URL:
> http://www.ietf.org/internet-drafts/draft-farbryantrel-mpls-retire-
> > ach-tlv-00.txt
> > Status:
> http://datatracker.ietf.org/doc/draft-farbryantrel-mpls-retire-ach-tlv<= br> > > Htmlized:
> http://tools.ietf.org/html/draft-farbryantrel-mpls-retire-ach-tlv-00 > >
> >
> > Abstract:
> >    The MPLS Generic Associated Channel (G-ACh) is a gen= eralization of
> >    the applicability of the Pseudowire (PW) Associated = Channel Header
> >    (ACH).  RFC 5586 defines the concept of Type-Le= ngth-Variable (TLV)
> >    constructs that can be carried in messages on the G-= ACh by placing
> >    them in the ACH.
> >
> >    No Associated Channel Type yet defined uses a TLV. &= nbsp;Furthermore, it
> >    is believed that handling TLVs in hardware introduce= s significant
> >    problems to the fast-path, and since G-ACh messages = are intended to
> >    be processed substantially in hardware, the use of T= LVs in
> >    undesirable.
> >
> >    This document updates RFC 5586 by retiring ACH TLVs = and removing the
> >    associated registry.
> >
> >
> >
> >
> > The IETF Secretariat
>
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail= -archive/web/mpls/attachments/20130516/f560777c/attachment.htm>

------------------------------

--_000_48E1A67CB9CA044EADFEAB87D814BFF60ADCBCeusaamb107ericsso_-- From gregory.mirsky@ericsson.com Tue May 21 09:10:19 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D3621F93E8 for ; Tue, 21 May 2013 09:10:19 -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] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e11+yJBZls4P for ; Tue, 21 May 2013 09:10:14 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 2836C21F93A3 for ; Tue, 21 May 2013 09:10:14 -0700 (PDT) X-AuditID: c6180641-b7f7b6d000001a44-85-519b9c655a7c Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 89.BE.06724.56C9B915; Tue, 21 May 2013 18:10:13 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Tue, 21 May 2013 12:10:12 -0400 From: Gregory Mirsky To: RFC Errata System , David Allan I , "swallow@cisco.com" , "jdrake@juniper.net" , "stbryant@cisco.com" , "adrian@olddog.co.uk" , "loa@pi.nu" , "swallow@cisco.com" , "rcallon@juniper.net" Thread-Topic: [mpls] [Technical Errata Reported] RFC6428 (3629) Thread-Index: AQHOVi2M5pBMiqQP60uFllVNlHd4dpkPznaQ Date: Tue, 21 May 2013 16:10:12 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B49D27A@eusaamb103.ericsson.se> References: <20130521141350.EF4F862100@rfc-editor.org> In-Reply-To: <20130521141350.EF4F862100@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgkeLIzCtJLcpLzFFi42KZXLonVjd1zuxAgwcb1C1+9NxgtngybRab xZy7zhb/5s5htri1dCWrxd8VV1gsmvZ/ZbM493QOo8XtKU2MDpweU35vZPVYsuQnk8f1pqvs HkdvzmX2WLF5JaPHrOltbB4NbcdYA9ijuGxSUnMyy1KL9O0SuDKuTygpaBapONexn62BcalA FyMHh4SAicSjjbpdjJxAppjEhXvr2boYuTiEBI4ySnw52MwI4SxnlNj/8yQ7SBWbgJHEi409 7CAJEYEmZompBw+DJZgF4iSWbrkEZgsL2EnsaTrHAmKLCNhLbOppY4awjSS6Tl5kArFZBFQl zrffAqvhFfCVuPp4LViNkICZxMnvz8DinALmEhdm7mADsRmBzvt+ag0TxC5xiVtP5jNBnC0g sWTPeWYIW1Ti5eN/rBC2ssSSJ/tZIOp1JBbs/sQGYWtLLFv4mhlir6DEyZlPWCYwis1CMnYW kpZZSFpmIWlZwMiyipGjtDi1LDfdyHATIzA2j0mwOe5gXPDJ8hCjNAeLkjhvt/bUQCGB9MSS 1OzU1ILUovii0pzU4kOMTBycUg2Mrk82LihwD9kjknis4pHZhR75pq8MdrJN+VoLTjzyDqh7 rOLs8ar8ubJT2x3N6T9zEmfsqu102JXq4dZRm2MXJG0Usr3neszGq3u/9T0wEtp/I+71ioQP l8tN7c7fKmKbmz+vvsyKw2FPR/vTZ6sUO+4Jr5Tk4dvgdb/0kf6dFesTWvuC1tkqsRRnJBpq MRcVJwIAFC7l7psCAAA= Cc: "mpls@ietf.org" , "alan.davey@metaswitch.com" Subject: Re: [mpls] [Technical Errata Reported] RFC6428 (3629) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 16:10:19 -0000 Dear Alan, et al., may I suggest minor modification by capitalizing Length to the proposed Cor= rected Text: The Length is the length of the data following the Length field. The Globa= l_ID, Node Identifier, and Attachment Circuit ID (AC_ID) are as per [9]. Regards, greg -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of RFC= Errata System Sent: Tuesday, May 21, 2013 7:14 AM To: David Allan I; swallow@cisco.com; jdrake@juniper.net; stbryant@cisco.co= m; adrian@olddog.co.uk; loa@pi.nu; swallow@cisco.com; rcallon@juniper.net Cc: mpls@ietf.org; alan.davey@metaswitch.com; rfc-editor@rfc-editor.org Subject: [mpls] [Technical Errata Reported] RFC6428 (3629) The following errata report has been submitted for RFC6428, "Proactive Conn= ectivity Verification, Continuity Check, and Remote Defect Indication for t= he MPLS Transport Profile". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3D6428&eid=3D3629 -------------------------------------- Type: Technical Reported by: Alan Davey Section: 3.5.3 Original Text ------------- The length is the length of the following data: the Global_ID, Node Identif= ier, and Attachment Circuit ID (AC_ID) are as per [9].=20 Corrected Text -------------- The length is the length of the data following the length field. The Globa= l_ID, Node Identifier, and Attachment Circuit ID (AC_ID) are as per [9]. Notes ----- Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Re= ply All" to discuss whether it should be verified or rejected. When a decis= ion is reached, the verifying party (IESG) can log in to change the status = and edit the report, if necessary.=20 -------------------------------------- RFC6428 (draft-ietf-mpls-tp-cc-cv-rdi-06) -------------------------------------- Title : Proactive Connectivity Verification, Continuity Check= , and Remote Defect Indication for the MPLS Transport Profile Publication Date : November 2011 Author(s) : D. Allan, Ed., G. Swallow Ed., J. Drake Ed. Category : PROPOSED STANDARD Source : Multiprotocol Label Switching Area : Routing Stream : IETF Verifying Party : IESG _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From gregory.mirsky@ericsson.com Tue May 21 09:12:06 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C60CE21F9869 for ; Tue, 21 May 2013 09:12:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1VJ2u220FOz for ; Tue, 21 May 2013 09:11:59 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id C29B321F9860 for ; Tue, 21 May 2013 09:11:56 -0700 (PDT) X-AuditID: c618062d-b7fb56d0000042e1-58-519b9ccbe7d3 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 56.8F.17121.BCC9B915; Tue, 21 May 2013 18:11:56 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0328.009; Tue, 21 May 2013 12:11:53 -0400 From: Gregory Mirsky To: Alan Davey , David Allan I Thread-Topic: [MPLS] A doubt about RFC 6428 Thread-Index: Ac5IG1yAbZhW1zCyQtKJoj7oW461UgACNQsQARrVc5AA4QRRQAF5nPeQABDx9AA= Date: Tue, 21 May 2013 16:11:52 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B49D295@eusaamb103.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B49D295eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyuXRPuO6ZObMDDeafZLR4Mm0Wm8WtpStZ HZg8liz5yeRx9OZc5gCmKC6blNSczLLUIn27BK6Mjq5mpoLJ2xgrLnUXNjBuncfYxcjJISFg IrHwzn0WCFtM4sK99WxdjFwcQgJHGSWOv1zJCpIQEljOKPH3iiiIzSZgJPFiYw87iC0iECEx beMzpi5GDg5mAWWJU3dlQExhAS2J57NKICq0JXZM7WGCsP0k5v89xghSwiKgKnFifTZImFfA V6LpzBImiK13mCRaG9axgSQ4Bfwlti2ZBXYmI9Bp30+tAZvDLCAucevJfCaIkwUkluw5zwxh i0q8fPyPFcJWlljyZD8LxGX5Esf3uUPsEpQ4OfMJywRG0VlIJs1CqJqFpAqiREdiwe5PbBC2 tsSyha+ZYewzBx4zIYsvYGRfxchRWpxalptuZLCJERhPxyTYdHcw7nlpeYhRmoNFSZy3VXtq oJBAemJJanZqakFqUXxRaU5q8SFGJg5OqQbGsKk+pS/4F03i+3YvznTqCkEL6dX9oZtP64Z6 RPC9dNRnzcpICY40TFx4wb3W1NHaqc09dWLk7Rm5czvdO3s9BDKnx6feSXBksz/8XuRk4Em/ fqOXE65LzZzl5mlmMqv1X6HJ4uVq+ax5ExdtvSAlWzP3TqhObYZ+0iUrM7dFk+dvm3/Z6aES S3FGoqEWc1FxIgAOwJYldQIAAA== Cc: "mpls@ietf.org" Subject: Re: [mpls] [MPLS] A doubt about RFC 6428 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 16:12:06 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B49D295eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Alan, et al., may I suggest minor modification by capitalizing Length to the proposed Cor= rected text: The Length is the length of the data following the Length field. The Global= _ID, Node Identifier, and Attachment Circuit ID (AC_ID) are as per [9]. Regards, Greg ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ala= n Davey Sent: Tuesday, May 21, 2013 1:24 AM To: David Allan I Cc: mpls@ietf.org Subject: Re: [mpls] [MPLS] A doubt about RFC 6428 Hi Dave Thank you for your response. I think that it is worth raising an erratum f= or section 3.5.3 because the current text is confusing (note that the colon= is in the RFC text). Do you agree? I propose the following. Section 3.5.3 Original text: The length is the length of the following data: the Global_ID, Node Identifier, and Attachment Circuit ID (AC_ID) are as per [9]. Corrected text: The length is the length of the data following the length field. The Global_ID, Node Identifier, and Attachment Circuit ID (AC_ID) are as per [9]. Thanks Alan From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: 13 May 2013 20:58 To: Alan Davey Cc: mpls@ietf.org Subject: RE: [MPLS] A doubt about RFC 6428 It is all in how you interpret "The length is the length of the following d= ata." Which is referring to the diagram above (e.g. the colon below is you= r addition), and then goes on to tells you how to find the less-obvious fie= lds. If it said "The length is the length of the data following the length field= "... it would be clearer. Dave ________________________________ From: Alan Davey [mailto:Alan.Davey@metaswitch.com] Sent: Thursday, May 09, 2013 3:59 AM To: David Allan I Cc: mpls@ietf.org Subject: RE: [MPLS] A doubt about RFC 6428 Hi Dave Thank you very much for getting back to me so quickly. I have a further qu= estion on RFC 6428 if you have another minute. In section 3.5.3, PW End Point MEP-ID, I think that the text defining the = Length field is confusing because it is not clear if the length includes th= e AGI. The text is currently as follows. The length is the length of the following data: the Global_ID, Node Ident= ifier, and Attachment Circuit ID (AC_ID) are as per [9]. Am I correct in thinking that the Length field is the length of the value = fields, as for the Section MEP-ID in section 3.5.1 and the LSP MEP-ID in se= ction 3.5.2? That is, should the text read as follows. The length is the length of the value fields. The Global_ID, Node Identi= fier, and Attachment Circuit ID (AC_ID) are as per [9]. Thanks Alan From: David Allan I [mailto:david.i.allan@ericsson.com] Sent: 03 May 2013 18:35 To: Alan Davey; rfc6428@tools.ietf.org Cc: mpls@ietf.org Subject: RE: [MPLS] A doubt about RFC 6428 Hi Alan: It is kind of implied, as in "received DOWN while NOT in a misconnectivity = state". I'm not sure adding that to the state machine diagram would actuall= y improve the clarity....I'll let others comment. cheers Dave ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of Alan Davey Sent: Friday, May 03, 2013 9:29 AM To: rfc6428@tools.ietf.org Cc: mpls@ietf.org Subject: [mpls] [MPLS] A doubt about RFC 6428 Folks I have a doubt about RFC 6428. Could you please let me know what you think= of the following. Section 3.7.4.2., Exit from a Mis-Connectivity Defect, states that "Exit fr= om a mis-connectivity defect state occurs when no CV messages with mis-conn= ectivity defects have been received for a period of 3.5 seconds". However, the State Machines in section 3.7.5 have no input corresponding to= an "Exit from a Mis-Connectivity Defect" timer pop. (Although they do hav= e a MIS-CONNECTIVITY input added by RFC 6428.) If the State Machine is fol= lowed then Down state is exited as soon as the remote system signals Down s= tate. Should the State Machines be modified such that Down state following a MIS-= CONNECTIVITY input is only exited after an "Exit from a Mis-Connectivity De= fect" timer pop input or am I missing something? Regards Alan Davey Network Technologies Metaswitch Networks alan.davey@metaswitch.com +44 (0) 20 8366 1177 network-technologies.metaswitch.com --_000_7347100B5761DC41A166AC17F22DF1121B49D295eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Alan, et al.,

may I suggest minor modification by capitalizing Length to the proposed = Corrected text:

The Length is the length of the data following the Length field. The Glo= bal_ID, Node Identifier, and Attachment Circuit ID (AC_ID) are as per [9].<= /p>

    Regards,

      &= nbsp; Greg


From: mpls-bounces@ietf.org [mailto= :mpls-bounces@ietf.org] On Behalf Of Alan Davey
Sent: Tuesday, May 21, 2013 1:24 AM
To: David Allan I
Cc: mpls@ietf.org
Subject: Re: [mpls] [MPLS] A doubt about RFC 6428

Hi Dave

 

Thank you for your re= sponse.  I think that it is worth raising an erratum for section 3.5.3= because the current text is confusing (note that the colon is in the RFC text).  Do you agree?

 

I propose the followi= ng.

 

Section 3.5.3

 

Original text: <= /o:p>

 

   The leng= th is the length of the

   followin= g data: the Global_ID, Node Identifier, and Attachment

   Circuit = ID (AC_ID) are as per [9].

 

Corrected text:<= /o:p>

 

   The leng= th is the length of the data following the length field.<= /p>

   The Glob= al_ID, Node Identifier, and Attachment

   Circuit = ID (AC_ID) are as per [9].

 

Thanks

Alan

 

From: David Allan I [m= ailto:david.i.allan@ericsson.com]
Sent: 13 May 2013 20:58
To: Alan Davey
Cc: mpls@ietf.org
Subject: RE: [MPLS] A doubt about RFC 6428

 

It is all in how you interpret "The length= is the length of the following data."  Which is referring to the= diagram above (e.g. the colon below is your addition), and then goes on to tells you how to find the less-obvious fields. =

 

If it said "The length is the length of th= e data following the length field"... it would be clearer.

 

Dave

 

From: Alan Davey [mail= to:Alan.Davey@metaswitch.com]
Sent: Thursday, May 09, 2013 3:59 AM
To: David Allan I
Cc: mpls@ietf.org
Subject: RE: [MPLS] A doubt about RFC 6428

Hi Dave

 

Thank you very much f= or getting back to me so quickly.  I have a further question on RFC 64= 28 if you have another minute.

 

In section 3.5.3,  PW End Point MEP-ID, I think that the text defining the Length= field is confusing because it is not clear if the length includes the AGI.=   The text is currently as follows.

 

  The length is = the length of the following data: the Global_ID, Node Identifier, and Attac= hment

   Circuit = ID (AC_ID) are as per [9].

 

Am I correct in think= ing that the Length field  is the length of the value fields, as for t= he Section MEP-ID in section 3.5.1 and the LSP MEP-ID in section 3.5.2?&nbs= p; That is, should the text read as follows.

 

  The length is = the length of the value fields.  The Global_ID, Node Identifier, and A= ttachment

   Circuit = ID (AC_ID) are as per [9].

 

Thanks

Alan

 

From: David Allan I [<= a href=3D"mailto:david.i.allan@ericsson.com">mailto:david.i.allan@ericsson.= com]
Sent: 03 May 2013 18:35
To: Alan Davey; rfc6428@to= ols.ietf.org
Cc: mpls@ietf.org
Subject: RE: [MPLS] A doubt about RFC 6428

 

Hi Alan:

 

It is kind of implied, as in "re= ceived DOWN while NOT in a misconnectivity state". I'm not sure a= dding that to the state machine diagram would actually improve the clarity....I'll let others comment.

 

cheers

Dave

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Alan Davey
Sent: Friday, May 03, 2013 9:29 AM
To: rfc6428@tools.ietf.org=
Cc: mpls@ietf.org
Subject: [mpls] [MPLS] A doubt about RFC 6428

Folks

 

I have a doubt about RFC 6428.  Could you pleas= e let me know what you think of the following.

 

Section 3.7.4.2., Exit from a Mis-Connectivity Defec= t, states that “Exit from a mis-connectivity defect state occurs when= no CV messages with mis-connectivity defects have been received for a peri= od of 3.5 seconds”.

 

However, the State Machines in section 3.7.5 have no= input corresponding to an “Exit from a Mis-Connectivity Defect”= ; timer pop.  (Although they do have a MIS-CONNECTIVITY input added by= RFC 6428.)  If the State Machine is followed then Down state is exited as soon as the remote system signals Down state.=

 

Should the State Machines be modified such that Down= state following a MIS-CONNECTIVITY input is only exited after an “Ex= it from a Mis-Connectivity Defect” timer pop input or am I missing so= mething?

 

Regards

Alan Davey

 

Network Technologies
Metaswitch Networks

 

alan.davey@meta= switch.com
+44 (0) 20 8366 1177
<= /p>

 

 

 

--_000_7347100B5761DC41A166AC17F22DF1121B49D295eusaamb103erics_-- From adrian@olddog.co.uk Tue May 21 09:17:19 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D8221F988E for ; Tue, 21 May 2013 09:17:17 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpZgkvru9gmC for ; Tue, 21 May 2013 09:17:12 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 0FD9521F988C for ; Tue, 21 May 2013 09:17:11 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4LGGr4S001404; Tue, 21 May 2013 17:16:53 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4LGGoLF001377 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 21 May 2013 17:16:51 +0100 From: "Adrian Farrel" To: "'Gregory Mirsky'" , "'RFC Errata System'" , "'David Allan I'" , , , , , , Date: Tue, 21 May 2013 17:16:50 +0100 Message-ID: <009e01ce563e$9b7d14f0$d2773ed0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5WPpeKgl5pDUhlQL2uz4YIGMeLLQ== Content-Language: en-gb Cc: mpls@ietf.org, alan.davey@metaswitch.com Subject: Re: [mpls] [Technical Errata Reported] RFC6428 (3629) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 16:17:19 -0000 Greg, You make a perfectly valid point, but I don't want to go through the whole draft capitalising the names of all of the fields. A > -----Original Message----- > From: Gregory Mirsky [mailto:gregory.mirsky@ericsson.com] > Sent: 21 May 2013 17:10 > To: RFC Errata System; David Allan I; swallow@cisco.com; jdrake@juniper.net; > stbryant@cisco.com; adrian@olddog.co.uk; loa@pi.nu; swallow@cisco.com; > rcallon@juniper.net > Cc: mpls@ietf.org; alan.davey@metaswitch.com > Subject: RE: [mpls] [Technical Errata Reported] RFC6428 (3629) > > Dear Alan, et al., > may I suggest minor modification by capitalizing Length to the proposed > Corrected Text: > > The Length is the length of the data following the Length field. The Global_ID, > Node Identifier, and Attachment Circuit ID (AC_ID) are as per [9]. > > Regards, > greg > > > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of RFC > Errata System > Sent: Tuesday, May 21, 2013 7:14 AM > To: David Allan I; swallow@cisco.com; jdrake@juniper.net; stbryant@cisco.com; > adrian@olddog.co.uk; loa@pi.nu; swallow@cisco.com; rcallon@juniper.net > Cc: mpls@ietf.org; alan.davey@metaswitch.com; rfc-editor@rfc-editor.org > Subject: [mpls] [Technical Errata Reported] RFC6428 (3629) > > The following errata report has been submitted for RFC6428, "Proactive > Connectivity Verification, Continuity Check, and Remote Defect Indication for the > MPLS Transport Profile". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6428&eid=3629 > > -------------------------------------- > Type: Technical > Reported by: Alan Davey > > Section: 3.5.3 > > Original Text > ------------- > The length is the length of the following data: the Global_ID, Node Identifier, and > Attachment Circuit ID (AC_ID) are as per [9]. > > > Corrected Text > -------------- > The length is the length of the data following the length field. The Global_ID, > Node Identifier, and Attachment Circuit ID (AC_ID) are as per [9]. > > > Notes > ----- > > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please use "Reply All" > to discuss whether it should be verified or rejected. When a decision is reached, > the verifying party (IESG) can log in to change the status and edit the report, if > necessary. > > -------------------------------------- > RFC6428 (draft-ietf-mpls-tp-cc-cv-rdi-06) > -------------------------------------- > Title : Proactive Connectivity Verification, Continuity Check, and Remote > Defect Indication for the MPLS Transport Profile > Publication Date : November 2011 > Author(s) : D. Allan, Ed., G. Swallow Ed., J. Drake Ed. > Category : PROPOSED STANDARD > Source : Multiprotocol Label Switching > Area : Routing > Stream : IETF > Verifying Party : IESG > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From swallow@cisco.com Tue May 21 09:23:06 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E527421F98AC for ; Tue, 21 May 2013 09:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OBkjBrrvmIj for ; Tue, 21 May 2013 09:23:00 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2CC21F98AB for ; Tue, 21 May 2013 09:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2884; q=dns/txt; s=iport; t=1369153375; x=1370362975; h=from:to:cc:subject:date:message-id:mime-version; bh=U2bcKxZCYJ3YpSwKzocqhDBpr/sRKMNHc3L9BXxY9A0=; b=NIDDcl76oY6onXaYwM8RltNQZDEI9sKBryGMCACFnGR+A1JGlp9SL3tL xFBjoOq52Hv5yJJi+h38GXiEd2yj3Yys2JpQiL1wDZ6c0SqwepnkOD8/S mcNkQjlv+FztSv45FPYes3E+KoLV5XustQvsnZPLThj2pHOpkALb2EXLh 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYGACyem1GtJV2a/2dsb2JhbABPCoJERMB3gQiBCRZtB4IlAQR5EgEMAR1WJwQODYgFu1qNXoELMYJ6YQOoeIMPgiY X-IronPort-AV: E=Sophos;i="4.87,714,1363132800"; d="scan'208,217";a="213165207" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 21 May 2013 16:22:54 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4LGMonZ011501 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 May 2013 16:22:54 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Tue, 21 May 2013 11:22:53 -0500 From: "George Swallow (swallow)" To: "draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org" Thread-Topic: Meaning of sub-TLVs for TLV 21 in Return Path Specified Thread-Index: AQHOVj9xsbdxNWyKhUe07sOydMXSag== Date: Tue, 21 May 2013 16:22:52 +0000 Message-ID: <2FE467D3673DCE409A84D67EC2F607BB0FA82512@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.98.56.166] Content-Type: multipart/alternative; boundary="_000_2FE467D3673DCE409A84D67EC2F607BB0FA82512xmbrcdx10ciscoc_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: [mpls] Meaning of sub-TLVs for TLV 21 in Return Path Specified X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 16:23:06 -0000 --_000_2FE467D3673DCE409A84D67EC2F607BB0FA82512xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mach, et al. - In section 4.1. Sending an Echo Request, it is stated: The Reply Path TLV includes one or several reply path sub-TLV(s) to identify the return path(s) the egress LSR should use for its reply. It would appear that the semantics of TLV 21 are very different than the se= mantics of TLV 1. Since TLV 1 defines a FEC stack which maps to a single L= SP. Why do you want the NIL FEC which only makes sense as part of a FEC st= ack? Under what circumstances would you ever use one of the multicast FECs (sub-= TLVs 17, 18, 19, 20)? What is the meaning of a return path to a VPN IPv4 prefix, or VPN IPv6 pre= fix? Note that if the prefix is multi-homed it may not even return to the = originating PE! What is the meaning of a return path to an L2 VPN endpoint? George --_000_2FE467D3673DCE409A84D67EC2F607BB0FA82512xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Mach, et al. -

In section 4.1. Sending an Echo Request, it is stated:
The Reply Path TLV includes one or several reply path sub-TLV(s) to
identify the return path(s) the egress LSR should use for its reply.=

It would appear that the semantics of TLV 21 ar=
e very different than the semantics of TLV 1.  Since TLV 1 defines a FEC st=
ack which maps to a single LSP.  Why do you want the NIL FEC which only mak=
es sense as part of a FEC stack?
Under what circumstances would you ever use one=
 of the multicast FECs (sub-TLVs 17, 18, 19, 20)?
What is the meaning of a return path to a VPN I=
Pv4 prefix, or  VPN IPv6 prefix?  Note that if the prefix is multi-homed it=
 may not even return to the originating PE!
What is the meaning of a return path to an L2 V=
PN endpoint?
George
--_000_2FE467D3673DCE409A84D67EC2F607BB0FA82512xmbrcdx10ciscoc_-- From autumn.liu@ericsson.com Tue May 21 10:11:30 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6336421F968F for ; Tue, 21 May 2013 10:11:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.932 X-Spam-Level: X-Spam-Status: No, score=-0.932 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyVQsL4peatM for ; Tue, 21 May 2013 10:11:25 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id D7AA721F974D for ; Tue, 21 May 2013 10:11:24 -0700 (PDT) X-AuditID: c6180641-b7f7b6d000001a44-35-519baabb743b Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 38.B2.06724.CBAAB915; Tue, 21 May 2013 19:11:24 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0328.009; Tue, 21 May 2013 13:11:23 -0400 From: Autumn Liu To: Loa Andersson Thread-Topic: [mpls] poll to see if we have consensus to make draft-jjb-mpls-rsvp-te-hsmp-lsp an MPLS wg document Thread-Index: AQHOVfYZMJpY9x5+EEG/oi64mBrXI5kPiwgAgABVU2A= Date: Tue, 21 May 2013 17:11:22 +0000 Message-ID: References: <4A1562797D64E44993C5CBF38CF1BE480CBBA8@ESESSMB301.ericsson.se> <60DEDD93F5E54B4AB55647B8B6C7483936AB6C@eusaamb109.ericsson.se> In-Reply-To: <60DEDD93F5E54B4AB55647B8B6C7483936AB6C@eusaamb109.ericsson.se> Accept-Language: zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_E4F89EAEF1386F42AA8E6FB5C35399A61BEA27DDeusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyuXRPrO6eVbMDDf73iFt8OjKV3eLf3DnM Ft8vLWGxuLV0JasDi8eSJT+ZPGZNb2Pz+HL5M1sAcxSXTUpqTmZZapG+XQJXxvm5PYwF08wq 3r2YydLAuEa/i5GTQ0LARKK9/Q8jhC0mceHeerYuRi4OIYGjjBJvF9xhgnCWM0rM+vWWHaSK TUBLYt/+d2C2iICsxLVtP8GKmAWOM0rc+9IAlhAWKJJYenQFC0RRscT6a3dZIWwriR8bdzKB 2CwCqhIrL78Fi/MK+ErsPtQPta2XUeLg9U9gRZwCPhKf/s0EG8oItG3ao/tgcWYBcYlbT+Yz QdwtILFkz3lmCFtU4uXjf6wQtrLEkif7WSDq8yV2vVsItUxQ4uTMJywTGEVnIRk1C0nZLCRl EHEdiQW7P7FB2NoSyxa+Zoaxzxx4zIQsvoCRfRUjR2lxalluupHhJkZg5B2TYHPcwbjgk+Uh RmkOFiVx3m7tqYFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGBny3Qqv+G/P2mfcoRt9OTuX lflk9JOlVx4EFCv+3lGzXa+uPkp47VbWtbN2m6+/fFTBT9xJIWc30zsP+6X+mlYn1AIz9G1T aq8dP8l/Qy6mI2uCSHm7bK6RbxzDyWk71h68d4Ftxp+PUge043lyPV4eqbilsL1hcbjo+icH mPaLzflSY2h/VImlOCPRUIu5qDgRAJ7ibB+KAgAA Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-jjb-mpls-rsvp-te-hsmp-lsp@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus to make draft-jjb-mpls-rsvp-te-hsmp-lsp an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 17:11:30 -0000 --_000_E4F89EAEF1386F42AA8E6FB5C35399A61BEA27DDeusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable yes/support -Autumn ---------- Forwarded message ---------- From: Loa Andersson > Date: Thu, May 16, 2013 at 10:49 AM Subject: [mpls] poll to see if we have consensus to make draft-jjb-mpls-rsv= p-te-hsmp-lsp an MPLS wg document To: "mpls@ietf.org" > Cc: "draft-jjb-mpls-rsvp-te-hsmp-lsp@tools.ietf.org" >, "mpls-chairs= @tools.ietf.org" > Working Group, This is to start a two week poll on adopting draft-jjb-mpls-rsvp-te-hsmp-lsp-04 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). Please give a tec= hnical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document. This poll ends May 31, 2013. There are one IPR claim against this document, see IPR claim #1840. The authors has stated on the working group mailing list that they are not aware of any other IPR claims against this draft. However if you are on the the mpls working group mailing list and aware of IPR that relates to this draft, the time to disclose this is now. /Loa (mpls wg co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_E4F89EAEF1386F42AA8E6FB5C35399A61BEA27DDeusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 

yes/support
 
-Autumn
---------- Forwarded message ----------
From: Loa Andersson <= ;loa@pi.nu>
Date: Thu, May 16, 2013 at 10:49 AM
Subject: [mpls] poll to see if we have consensus to make draft-jjb-mpls-rsv= p-te-hsmp-lsp an MPLS wg document
To: "mpls@ietf.org" <mpls@ietf.org>
Cc: "draft-jjb-mpls-rsvp-te-hsmp-lsp@tools.ietf.org" <draft-jjb-mpls-rsvp-te= -hsmp-lsp@tools.ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.o= rg>


Working Group,

This is to start a two week poll on adopting
draft-jjb-mpls-rsvp-te-hsmp-lsp-04 as an MPLS working
group document.

Please send your comments (support/not support) to the mpls working
group mailing list (mpls= @ietf.org). Please give a technical
motivation for your support/not support, especially if you think that
the document should not be adopted as a working group document.

This poll ends May 31, 2013.

There are one IPR claim against this document, see IPR claim #1840.

The authors has stated on the working group mailing list
that they are not aware of any other IPR claims against this draft.
However if you are on the the mpls working group mailing list and
aware of IPR that relates to this draft, the time to disclose
this is now.

/Loa
(mpls wg co-chair)
--


Loa Andersson                  = ;      email: loa@mail01.huawei.com
Senior MPLS Expert                 =          loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--_000_E4F89EAEF1386F42AA8E6FB5C35399A61BEA27DDeusaamb103erics_-- From gregory.mirsky@ericsson.com Tue May 21 15:56:31 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4928A11E80B8 for ; Tue, 21 May 2013 15:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l6mV66GHYYcj for ; Tue, 21 May 2013 15:56:24 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7062C11E80A4 for ; Tue, 21 May 2013 15:56:24 -0700 (PDT) X-AuditID: c618062d-b7fb56d0000042e1-a6-519bfb971c29 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id B0.28.17121.79BFB915; Wed, 22 May 2013 00:56:23 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0328.009; Tue, 21 May 2013 18:56:22 -0400 From: Gregory Mirsky To: Loa Andersson , Lizhong Jin , Jia He , "Eric Osborne (eosborne)" , "Martin Vigoureux" Thread-Topic: MPLS-RT review of draft-farbryantrel-mpls-retire-ach-tlv Thread-Index: AQHOS8I4kQ5ZZhSZYU2ktTA0E8MN1pkQQ7ug Date: Tue, 21 May 2013 22:56:21 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B49D68C@eusaamb103.ericsson.se> References: <518A064C.7090006@pi.nu> In-Reply-To: <518A064C.7090006@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.134] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B49D68Ceusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHIsWRmVeSWpSXmKPExsUyuXRPuO7037MDDRa/s7SYfGkVi0XTnM2M Fi1T3jFbrDj9jNni39w5zBZ3dn1htfh+aQmLxa2lK1kdODxan+1l9ZjyeyOrx85Zd9k9Wo68 ZfVYsuQnk8es6W1sHl8uf2YLYI/isklJzcksSy3St0vgyjg6cydLwXanipWzL7E0ME4272Lk 5JAQMJG4snkHI4QtJnHh3nq2LkYuDiGBo4wSZ1c/Y4JwljNKfJ7RygZSxSZgJPFiYw87SEJE 4CSjxNEXW1lBHGaBq4wSv+cdBpslLOAq8e3bbGYQW0TATWLd/ttMELaRxKrt14AmcXCwCKhK zL0TChLmFfCVeLLkPFi5kICKxKbO32DLOIFKmm4tYQWxGYHO+35qDdgYZgFxiVtP5jNBnC0g sWQPRK+EgKjEy8f/WCFsZYklT/azQNTnS9x48IoZYpegxMmZT1gmMIrOQjJqFpKyWUjKIOI6 Egt2f2KDsLUlli18zQxjnznwmAlZfAEj+ypGjtLi1LLcdCODTYzAOD4mwaa7g3HPS8tDjNIc LErivK3aUwOFBNITS1KzU1MLUovii0pzUosPMTJxcEo1MLpbqe6fu/XlW54zk2PbT5tHhFof DdJdLWJne25NMlfd+p+NFm1Hc3/k7D/xPVyKVdw68uQ5h3mBtk4JrAp35medaHbYtbs5NWBj c/TmJPmmsnOv0pb7TTj3IETlCe+Lxzbllq6ROdv+RN+V3/j+fqXC/ee70nS1pqcEsx/Orer+ s2Lb2cpeeyWW4oxEQy3mouJEALQavTmxAgAA Cc: "draft-farbryantrel-mpls-retire-ach-tlv@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-farbryantrel-mpls-retire-ach-tlv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 22:56:31 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B49D68Ceusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Authors, et al., firstly, I'll address format of MPLS-RT review as set by WG chairs: * The document is coherent, clearly useful and technically sound * The document is ready to be adopted by MPLS WG Now several comments and possible typo corrections: * Perhaps re-word "No Associated Channel Type yet defined uses a TLV"= into "So far none of defined Associated Channel Types uses a TLV as specif= ied by RFC 5586". That seems to be more accurate as MPLS-TP BFD Proactive C= V message format uses Source MEP-ID TLV, though not according to RFC 5586, = that might be viewed as example of ACH TLV. * Introduction, first para, first sentense s/is/if/ * Introduction, fourth para, in "However, of the 18 ACH Channel Types= currently defined none allows the use of ACH TLVs [IANA-ACH]" I'd consider= s/allows/requires/ to stress that up to now we managed to develop protocol= suite without use of a single ACH TLV * Introduction, last para "This document determines that ACH TLVs are= not useful ..." might be re-worded to "This document states that ACH TLVs,= as specified in RFC 5586, are not useful ..." * Section 2, note that references to ACH TLVs exist in RFC 5586 outsi= de of Section 3, e.g. Section 4.2.1.1, p.10, as well as in several figures,= e.g. figure 6. * Section 3, if motivation of this document is to negate MUST in Sect= ion 3 of RFC 5586 that ACH TLV Header preceeds G-ACh message, then would fo= llowing sufficiently express it: "A G-ACh message MAY NOT be preceeded by a= n ACH TLV Header." * Section 6, I think that we might only remove too restrictive requir= ement of RFC 5586 while allowing use of ACH TLV following G-ACh message. Regards, Greg -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu] Sent: Wednesday, May 08, 2013 1:01 AM To: Lizhong Jin; Jia He; Gregory Mirsky; Eric Osborne (eosborne); Martin Vi= goureux Cc: draft-farbryantrel-mpls-retire-ach-tlv@tools.ietf.org; mpls-chairs@tool= s.ietf.org Subject: MPLS-RT review of draft-farbryantrel-mpls-retire-ach-tlv Jia, Lizhong, Greg and Eric, You have been selected as an MPLS Review team reviewers for draft-farbryant= rel-mpls-retire-ach-tlv-00. Note to authors: You have been CC'd on this email so that you can know that= this review is going on. However, please do not review your own document. Reviews should comment on whether the document is coherent, is it useful (i= e, is it likely to be actually useful in operational networks), and is the = document technically sound? We are interested in knowing whether the docum= ent is ready to be considered for WG adoption (ie, it doesn't have to be pe= rfect at this point, but should be a good start). Reviews should be sent to the document authors, WG co-chairs and WG secreta= ry, and CC'd to the MPLS WG email list. If necessary, comments may be sent = privately to only the WG chairs. Are you able to review this draft by Mat 24, 2013? Thanks, Loa (as MPLS WG chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 --_000_7347100B5761DC41A166AC17F22DF1121B49D68Ceusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear Authors, et al.,
firstly, I'll address format of MPLS-RT review as set by WG chairs:
  • The document is coherent, clearly useful and technically sound
  • = The document is ready to be adopted by MPLS WG
 
Now several comments and possible typo corrections:
  • Perhaps re-word "No Associated Channel Type yet defined uses a TLV= " into "So far none of defined Associated Channel Types uses a TL= V as specified by RFC 5586". That seems to be more accurate as MPLS-TP= BFD Proactive CV message format uses Source MEP-ID TLV, though not according to RFC 5586, that might be viewed as example of A= CH TLV.
  • Introduction, first para, first sentense s/is/if/
  • I= ntroduction, fourth para, in "However, of the 18 ACH Channel Types cur= rently defined none allows the use of ACH TLVs [IANA-ACH]" I'd conside= r s/allows/requires/ to stress that up to now we managed to develop protoco= l suite without use of  a single ACH TLV
  • Introduction, last para "This document determines that ACH= TLVs are not useful …" might be re-worded to "This documen= t states that ACH TLVs, as specified in RFC 5586, are not useful …&qu= ot;
  • Section 2, note that references to ACH TLVs exist in RFC 5586 o= utside of Section 3, e.g. Section 4.2.1.1, p.10, as well as in several figu= res, e.g. figure 6.
  • Section 3, if motivation of this document is to= negate MUST in Section 3 of RFC 5586 that ACH TLV Header preceeds G-ACh me= ssage, then would following sufficiently express it: "A G-ACh message = MAY NOT be preceeded by an ACH TLV Header."
  • Section 6, I think= that we might only remove too restrictive requirement of RFC 5586 while al= lowing use of ACH TLV following G-ACh message.
 
        Regards,
           &nbs= p;    Greg
 
-----Original Message-----
From: Loa Andersson [mailto:loa@pi.nu]
Sent: Wednesday, May 08, 2013 1:01 AM
To: Lizhong Jin; Jia He; Gregory Mirsky; Eric Osborne (eosborne); Mart= in Vigoureux
Cc: draft-farbryantrel-mpls-retire-ach-tlv@tools.ietf.org; mpls-chairs= @tools.ietf.org
Subject: MPLS-RT review of draft-farbryantrel-mpls-retire-ach-tlv
 
Jia, Lizhong, Greg and Eric,
 
You have been selected as an MPLS Review team reviewers for draft-farb= ryantrel-mpls-retire-ach-tlv-00.
 
Note to authors: You have been CC'd on this email so that you can know= that this review is going on. However, please do not review your own docum= ent.
 
Reviews should comment on whether the document is coherent, is it usef= ul (ie, is it likely to be actually useful in operational networks), and is= the document technically sound?  We are interested in knowing whether= the document is ready to be considered for WG adoption (ie, it doesn't have to be perfect at this point, but shoul= d be a good start).
 
Reviews should be sent to the document authors, WG co-chairs and WG se= cretary, and CC'd to the MPLS WG email list. If necessary, comments may be = sent privately to only the WG chairs.
 
Are you able to review this draft by Mat 24, 2013?
 
Thanks, Loa
(as MPLS WG chair)
--
 
 
Loa Andersson         &nb= sp;            =   email: loa@mail01.huawei.com
Senior MPLS Expert        &nbs= p;            &= nbsp;    loa@pi.nu
Huawei Technologies (consultant)     phone: +4= 6 739 81 21 64
 
 --_000_7347100B5761DC41A166AC17F22DF1121B49D68Ceusaamb103erics_-- From adrian@olddog.co.uk Tue May 21 16:52:31 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D9221F93B7 for ; Tue, 21 May 2013 16:52: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddlJLmTMQFKF for ; Tue, 21 May 2013 16:52:25 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 84FE221F93BC for ; Tue, 21 May 2013 16:52:24 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4LNqDPp000495; Wed, 22 May 2013 00:52:13 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4LNqCPh000478 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 May 2013 00:52:12 +0100 From: "Adrian Farrel" To: "'Gregory Mirsky'" Date: Wed, 22 May 2013 00:52:11 +0100 Message-ID: <012901ce567e$36ebe3a0$a4c3aae0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5WfidbzVxohruxRp2osFqGxzUHYA== Content-Language: en-gb Cc: draft-farbryantrel-mpls-retire-ach-tlv@tools.ietf.org, mpls@ietf.org, 'Lizhong Jin' , mpls-chairs@tools.ietf.org, 'Loa Andersson' Subject: Re: [mpls] MPLS-RT review of draft-farbryantrel-mpls-retire-ach-tlv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 23:52:31 -0000 Hi Greg, Thanks for the review. > firstly, I'll address format of MPLS-RT review as set by WG chairs: > =95 The document is coherent, clearly useful and technically sound > =95 The document is ready to be adopted by MPLS WG Thanks for that. =A0 > Now several comments and possible typo corrections: > =95 Perhaps re-word "No Associated Channel Type yet defined > uses a TLV" into "So far none of defined Associated Channel=20 > Types uses a TLV as specified by RFC 5586". That seems to be > more accurate as MPLS-TP BFD Proactive CV message format > uses Source MEP-ID TLV, though not according to RFC 5586,=20 > that might be viewed as example of ACH TLV. Interesting point. Yes, the text should say "ACH TLV" since individual = message definitions are free to use TLVs. This usage finds itself in the main = text, so it is just the Abstract that needs attention. > =95 Introduction, first para, first sentense s/is/if/ Yup > =95 Introduction, fourth para, in "However, of the 18 ACH Channel = Types > currently defined none allows the use of ACH TLVs [IANA-ACH]"=20 > I'd consider s/allows/requires/ to stress that up to now we managed > to develop protocol suite without use of=A0 a single ACH TLV I think I disagree. While 'requires' is seemingly stronger, the = permissive nature of 'allows' makes a stronger point here. I.e., not only is the = TLV not required, but it is even not allowed. > =95 Introduction, last para "This document determines that ACH TLVs > are not useful =85" might be re-worded to "This document states that > ACH TLVs, as specified in RFC 5586, are not useful =85" OK. Makes note to stop using English when writing I-Ds :-) > =95 Section 2, note that references to ACH TLVs exist in RFC 5586 > outside of Section 3, e.g. Section 4.2.1.1, p.10, as well as in = several >l figures, e.g. figure 6. Yeah. Point also made by Lizhong, so I'm updating Section 2 to read... Section 3 of RFC 5586 is deleted. References to ACH TLVs in Section 4 of RFC 5586 should also be disregarded. Note that the text in Section 4 currently uses phrases like "ACH TLV(s), if present" so, with the removal of Section 3 that used to define ACH TLVs, they will not be present. > =95 Section 3, if motivation of this document is to negate MUST in=20 > Section 3 of RFC 5586 that ACH TLV Header preceeds G-ACh message, > then would following sufficiently express it: "A G-ACh message MAY=20 > NOT be preceeded by an ACH TLV Header." 1. "MAY NOT" is the stuff of RFC 6919, not RFC 2119. So you mean "MUST NOT". 2. Doesn't deleting the whole section achieve the effect? I suppose we could add an explicit statement if people feel strongly. > =95 Section 6, I think that we might only remove too restrictive > requirement of RFC 5586 while allowing use of ACH TLV following > G-ACh message. I think that once you have started the G-ACh message, you have = completely stopped talking about ACH TLVs. Any TLVs that you encounter will be message-specific. There may turn out to be value in the definition of common G-ACh message = TLVs, but that seems to be a decision for the future. What we find (mia culpa) = is that when we specify stuff for which we have no immediate use, we end up = wasting our time. Now, I have a -02 ready to post, but the chairs slapped my wrist when I = posted -01 during the MPLS-RT review period, so i am left puzzled as to whether = I am allowed to post a new revision of an individual I-D. (Actually, I am not = puzzled at all, since I know how the IETF works. I will nevertheless attempt to = be polite and friendly to the chairs - the shock may kill them :-) Cheers, Adrian From adrian@olddog.co.uk Tue May 21 16:55:36 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9509E21F8FE8 for ; Tue, 21 May 2013 16:55:36 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sK4W21mpR7AD for ; Tue, 21 May 2013 16:55:30 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 83D6821F8F69 for ; Tue, 21 May 2013 16:55:30 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4LNtRuN001738; Wed, 22 May 2013 00:55:27 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4LNtQGq001720 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 22 May 2013 00:55:27 +0100 From: "Adrian Farrel" To: , "'Gregory Mirsky'" References: <012901ce567e$36ebe3a0$a4c3aae0$@olddog.co.uk> In-Reply-To: <012901ce567e$36ebe3a0$a4c3aae0$@olddog.co.uk> Date: Wed, 22 May 2013 00:55:26 +0100 Message-ID: <012a01ce567e$aaec6450$00c52cf0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHjlrqD5TCYuhB4I6CUrBwlvWSptZjlz2cw Content-Language: en-gb Cc: draft-farbryantrel-mpls-retire-ach-tlv@tools.ietf.org, mpls-chairs@tools.ietf.org, 'Lizhong Jin' , 'Loa Andersson' , mpls@ietf.org Subject: Re: [mpls] MPLS-RT review of draft-farbryantrel-mpls-retire-ach-tlv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 May 2013 23:55:36 -0000 Oh, I forgot to check the I-D! > > . Section 3, if motivation of this document is to negate MUST in > > Section 3 of RFC 5586 that ACH TLV Header preceeds G-ACh message, > > then would following sufficiently express it: "A G-ACh message MAY > > NOT be preceeded by an ACH TLV Header." > > 1. "MAY NOT" is the stuff of RFC 6919, not RFC 2119. So you mean "MUST > NOT". > 2. Doesn't deleting the whole section achieve the effect? > > I suppose we could add an explicit statement if people feel strongly. Section 3 *is* that explicit statement. So you are only asking about s/MUST NOT/MAY NOT/. I don't believe that makes sense. Cheers, Adrian From liushucheng@huawei.com Tue May 21 20:03:37 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E0F321F934B for ; Tue, 21 May 2013 20:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.265 X-Spam-Level: X-Spam-Status: No, score=-7.265 tagged_above=-999 required=5 tests=[AWL=-0.666, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4A28Z105RQkV for ; Tue, 21 May 2013 20:03:33 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 74D8421F9318 for ; Tue, 21 May 2013 20:03:32 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATA31317; Wed, 22 May 2013 03:03:30 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 22 May 2013 04:02:44 +0100 Received: from SZXEML424-HUB.china.huawei.com (10.82.67.163) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 22 May 2013 04:02:53 +0100 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.199]) by szxeml424-hub.china.huawei.com ([10.82.67.163]) with mapi id 14.01.0323.007; Wed, 22 May 2013 11:02:41 +0800 From: "Will Liu (Shucheng)" To: "mpls@ietf.org" Thread-Topic: New Version Notification for draft-manral-mpls-rfc3811bis-02.txt Thread-Index: AQHOVlmidmIrNtZlCEydD0bqhMBO45kQf6+A Date: Wed, 22 May 2013 03:02:41 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.78.79] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [mpls] FW: New Version Notification for draft-manral-mpls-rfc3811bis-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 03:03:37 -0000 Rm9sa3MsIA0KDQpXZSB1cGRhdGVkIHRoZSBkcmFmdCBieSBtb2RpZnlpbmcgdGhlIGludHJvZHVj dGlvbiwgdHlwb3MgaW4gc2VjdGlvbiA1LCBhbmQgYWRkaW5nIGEgc2VjdGlvbiBoaWdobGlnaHRp bmcgdGhlIGNoYW5nZXMgb24gcmZjMzgxMS4NCg0KWW91ciByZXZpZXcgYW5kIGNvbW1lbnRzIGFy ZSBoaWdobHkgYXBwcmVjaWF0ZWQuIA0KDQpSZWdhcmRzLA0KV2lsbA0KDQoNCi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzpp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogV2VkbmVzZGF5LCBNYXkgMjIsIDIwMTMg MzozMCBBTQ0KVG86IFRpbmEgVFNPVTsgV2lsbCBMaXUgKFNodWNoZW5nKTsgVmlzaHdhcyBNYW5y YWw7IFdpbGwgTGl1IChTaHVjaGVuZykNClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtbWFucmFsLW1wbHMtcmZjMzgxMWJpcy0wMi50eHQNCg0KDQpBIG5ldyB2ZXJz aW9uIG9mIEktRCwgZHJhZnQtbWFucmFsLW1wbHMtcmZjMzgxMWJpcy0wMi50eHQNCmhhcyBiZWVu IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgVmlzaHdhcyBNYW5yYWwgYW5kIHBvc3RlZCB0byB0 aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1tYW5yYWwtbXBscy1yZmMz ODExYmlzDQpSZXZpc2lvbjoJIDAyDQpUaXRsZToJCSBEZWZpbml0aW9ucyBvZiBUZXh0dWFsIENv bnZlbnRpb25zIChUQ3MpIGZvciBNdWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGluZyAoTVBMUykg TWFuYWdlbWVudA0KQ3JlYXRpb24gZGF0ZToJIDIwMTMtMDUtMjANCkdyb3VwOgkJIEluZGl2aWR1 YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAyMg0KVVJMOiAgICAgICAgICAgICBodHRw Oi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1tYW5yYWwtbXBscy1yZmMzODEx YmlzLTAyLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LW1hbnJhbC1tcGxzLXJmYzM4MTFiaXMNCkh0bWxpemVkOiAgICAgICAgaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWFucmFsLW1wbHMtcmZjMzgxMWJpcy0wMg0KRGlm ZjogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1tYW5y YWwtbXBscy1yZmMzODExYmlzLTAyDQoNCkFic3RyYWN0Og0KICAgVGhpcyBtZW1vIGRlZmluZXMg YSBNYW5hZ2VtZW50IEluZm9ybWF0aW9uIEJhc2UgKE1JQikgbW9kdWxlIHdoaWNoDQogICBjb250 YWlucyBUZXh0dWFsIENvbnZlbnRpb25zIHRvIHJlcHJlc2VudCBjb21tb25seSB1c2VkIE11bHRp cHJvdG9jb2wNCiAgIExhYmVsIFN3aXRjaGluZyAoTVBMUykgbWFuYWdlbWVudCBpbmZvcm1hdGlv bi4gIFRoZSBpbnRlbnQgaXMgdGhhdA0KICAgdGhlc2UgVEVYVFVBTCBDT05WRU5USU9OUyAoVENz KSB3aWxsIGJlIGltcG9ydGVkIGFuZCB1c2VkIGluIE1QTFMNCiAgIHJlbGF0ZWQgTUlCIG1vZHVs ZXMgdGhhdCB3b3VsZCBvdGhlcndpc2UgZGVmaW5lIHRoZWlyIG93bg0KICAgcmVwcmVzZW50YXRp b25zLg0KDQogICBUaGlzIGRvY3VtZW50IG9ic29sZXRlcyBSRkMzODExIGFzIGl0IGFkZHJlc3Nl cyB0aGUgbmVlZCB0byBzdXBwb3J0DQogICBJUHY2IGV4dGVuZGVkIFR1bm5lbElEJ3MgYnkgZGVm aW5pbmcgYSBuZXcgVEMtDQogICBNcGxzTmV3RXh0ZW5kZWRUdW5uZWxJRCB3aGljaCBzdWdnZXN0 cyB1c2luZyBJUHY0IGFkZHJlc3Mgb2YgdGhlDQogICBpbmdyZXNzIG9yIGVncmVzcyBMU1IgZm9y IHRoZSB0dW5uZWwgZm9yIGFuIElQdjYgbmV0d29yay4gIENoYW5nZXMNCiAgIGZyb20gUkZDMzgx MSBhbmQgdGhlIGVmZmVjdCBvZiB0aGUgbmV3IFRDIHRvIG90aGVyIHJlbGF0ZWQgZG9jdW1lbnRz DQogICBhcmUgc3VtbWFyaXplZCBpbiBTZWN0aW9uIDQgYW5kIDUsIHJlc3BlY3RpdmVseS4NCg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From manavbhatia@gmail.com Tue May 21 20:23:55 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6632621F934B for ; Tue, 21 May 2013 20:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.933 X-Spam-Level: X-Spam-Status: No, score=-0.933 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUUoKukBA2Ff for ; Tue, 21 May 2013 20:23:54 -0700 (PDT) Received: from mail-ie0-x22a.google.com (mail-ie0-x22a.google.com [IPv6:2607:f8b0:4001:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 839A421F92BB for ; Tue, 21 May 2013 20:23:54 -0700 (PDT) Received: by mail-ie0-f170.google.com with SMTP id aq17so4129827iec.1 for ; Tue, 21 May 2013 20:23:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bXiefX4SgS2IJKfLP7d0dKmse2+Qc8Nbe8vgBWLC/rk=; b=umenby9fnvq1wzp/QBqPVl0EF8S0ByTSHG26lZrbViKf5m+zRcBhT5kpJvPJxr2W11 mMWBAutQO9IWboo3IMSUckPymHbnd/nnHqWqXoNojXyiEHzqPzTFbla5Hmuaar+vxITp nRD/LJ9GydAlzz3IhCGOw+tVE+1OXvq+yfe5MuNSuywhWsdhM9btmO8yiOV4I/HUPIri Adv9YtilM2UeT5poki4ULqMvxUprd4dHWALzA+XeRgmB7eoOSzrrLZ3B9w0a+2t3Ammx M+4tcMlC+BeL4nyO8/BoxI5FtM0iT+URfGYuMYBeV+e/GilR84amJ2sOyaSBFjCWtc4D 9geg== MIME-Version: 1.0 X-Received: by 10.50.92.69 with SMTP id ck5mr2909823igb.107.1369193034089; Tue, 21 May 2013 20:23:54 -0700 (PDT) Received: by 10.64.245.244 with HTTP; Tue, 21 May 2013 20:23:53 -0700 (PDT) In-Reply-To: References: <4A1562797D64E44993C5CBF38CF1BE480CBBA8@ESESSMB301.ericsson.se> <60DEDD93F5E54B4AB55647B8B6C7483936AB6C@eusaamb109.ericsson.se> Date: Wed, 22 May 2013 08:53:53 +0530 Message-ID: From: Manav Bhatia To: Autumn Liu Content-Type: multipart/alternative; boundary=047d7b10d03d6d130704dd46189e Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-jjb-mpls-rsvp-te-hsmp-lsp@tools.ietf.org" , Loa Andersson Subject: Re: [mpls] poll to see if we have consensus to make draft-jjb-mpls-rsvp-te-hsmp-lsp an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 03:23:55 -0000 --047d7b10d03d6d130704dd46189e Content-Type: text/plain; charset=ISO-8859-1 Support. Cheers, Manav On Tue, May 21, 2013 at 10:41 PM, Autumn Liu wrote: > ** > > > yes/support > > -Autumn > > ---------- Forwarded message ---------- > From: Loa Andersson > Date: Thu, May 16, 2013 at 10:49 AM > Subject: [mpls] poll to see if we have consensus to make > draft-jjb-mpls-rsvp-te-hsmp-lsp an MPLS wg document > To: "mpls@ietf.org" > Cc: "draft-jjb-mpls-rsvp-te-hsmp-lsp@tools.ietf.org" < > draft-jjb-mpls-rsvp-te-hsmp-lsp@tools.ietf.org>, " > mpls-chairs@tools.ietf.org" > > > Working Group, > > This is to start a two week poll on adopting > draft-jjb-mpls-rsvp-te-hsmp-**lsp-04 as an MPLS working > group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > This poll ends May 31, 2013. > > There are one IPR claim against this document, see IPR claim #1840. > > The authors has stated on the working group mailing list > that they are not aware of any other IPR claims against this draft. > However if you are on the the mpls working group mailing list and > aware of IPR that relates to this draft, the time to disclose > this is now. > > /Loa > (mpls wg co-chair) > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > ______________________________**_________________ > 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 > > --047d7b10d03d6d130704dd46189e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Support.

Cheers, Manav


On Tue, May = 21, 2013 at 10:41 PM, Autumn Liu <autumn.liu@ericsson.com> wrote:
=A0

yes/s= upport
=A0
-Autu= mn
---------- Forwarded message ----------
From: Loa Andersson <= ;loa@pi.nu> Date: Thu, May 16, 2013 at 10:49 AM
Subject: [mpls] poll to see if we have consensus to make draft-jjb-mpls-rsv= p-te-hsmp-lsp an MPLS wg document
To: "mpls@ietf.org<= /a>" <mpls@ietf.= org>
Cc: "draft-jjb-mpls-rsvp-te-hsmp-lsp@tools.ietf.org"= <draft-jjb-mpls-rsvp-te-hsmp-lsp@tools.ietf.org>, "= ;mpls-chair= s@tools.ietf.org" <mpls-c= hairs@tools.ietf.org>


Working Group,

This is to start a two week poll on adopting
draft-jjb-mpls-rsvp-te-hsmp-lsp-04 as an MPLS working
group document.

Please send your comments (support/not support) to the mpls working
group mailing list (mpls= @ietf.org). Please give a technical
motivation for your support/not support, especially if you think that
the document should not be adopted as a working group document.

This poll ends May 31, 2013.

There are one IPR claim against this document, see IPR claim #1840.

The authors has stated on the working group mailing list
that they are not aware of any other IPR claims against this draft.
However if you are on the the mpls working group mailing list and
aware of IPR that relates to this draft, the time to disclose
this is now.

/Loa
(mpls wg co-chair)
--


Loa Andersson =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0email: loa@mail01.huawei.com
Senior MPLS Expert =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0loa@pi.nu
Huawei Technologies (consultant) =A0 =A0 phone: +46 739 81 21 64
_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls


--047d7b10d03d6d130704dd46189e-- From mach.chen@huawei.com Tue May 21 22:38:35 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F6D21F9301 for ; Tue, 21 May 2013 22:38:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fkHLiPn7my5 for ; Tue, 21 May 2013 22:38:30 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3D82321F92F4 for ; Tue, 21 May 2013 22:38:28 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATA41866; Wed, 22 May 2013 05:38:25 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 22 May 2013 06:38:11 +0100 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 22 May 2013 13:38:19 +0800 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.243]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.007; Wed, 22 May 2013 13:38:16 +0800 From: Mach Chen To: "George Swallow (swallow)" , "draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org" Thread-Topic: Meaning of sub-TLVs for TLV 21 in Return Path Specified Thread-Index: AQHOVj9xsbdxNWyKhUe07sOydMXSapkQbk2g Date: Wed, 22 May 2013 05:38:16 +0000 Message-ID: References: <2FE467D3673DCE409A84D67EC2F607BB0FA82512@xmb-rcd-x10.cisco.com> In-Reply-To: <2FE467D3673DCE409A84D67EC2F607BB0FA82512@xmb-rcd-x10.cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BA3D94szxeml558mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" Subject: Re: [mpls] Meaning of sub-TLVs for TLV 21 in Return Path Specified X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 05:38:35 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BA3D94szxeml558mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi George, I guess your question is that why TLV 21 have to apply all the sub-TLVs of = TLV 1. For TLV 21, there are at least two usages, one is for specifying the return= path of the echo reply, and if just for specifying the return path of echo= reply, yes, it may not necessary to use all sub-TLVs of TLV 1. The other i= s for testing and validating the specified return path by carrying TLV 21( = just as the FEC Stack TLV for forward path). For usage 2, the TLV 21 should= have the same semantics as TLV 1, thus applying all sub-TLVs of TLV 1 is r= easonable. Many thanks, Mach From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Geo= rge Swallow (swallow) Sent: Wednesday, May 22, 2013 12:23 AM To: draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org Cc: mpls@ietf.org Subject: [mpls] Meaning of sub-TLVs for TLV 21 in Return Path Specified Mach, et al. - In section 4.1. Sending an Echo Request, it is stated: The Reply Path TLV includes one or several reply path sub-TLV(s) to identify the return path(s) the egress LSR should use for its reply. It would appear that the semantics of TLV 21 are very different than the se= mantics of TLV 1. Since TLV 1 defines a FEC stack which maps to a single L= SP. Why do you want the NIL FEC which only makes sense as part of a FEC st= ack? Under what circumstances would you ever use one of the multicast FECs (sub-= TLVs 17, 18, 19, 20)? What is the meaning of a return path to a VPN IPv4 prefix, or VPN IPv6 pre= fix? Note that if the prefix is multi-homed it may not even return to the = originating PE! What is the meaning of a return path to an L2 VPN endpoint? George --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BA3D94szxeml558mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi George,

=  

= I guess your question is that why TLV 21 have to apply all the sub-TLVs of TLV 1.

=  

= For TLV 21, there are at least tw= o usages, one is for specifying the return path of the echo reply, and if ju= st for specifying the return path of echo reply, yes, it may not necessary = to use all sub-TLVs of TLV 1. The other is for testing and validating the s= pecified return path by carrying TLV 21( just as the FEC Stack TLV for forward path). For usage 2, the TLV = 21 should have the same semantics as TLV 1, thus applying all sub-TLVs of T= LV 1 is reasonable.

=  

= Many thanks,

= Mach

=  

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of George Swallow (swallow)
Sent: Wednesday, May 22, 201= 3 12:23 AM
To: draft-ietf-mpls-return-p= ath-specified-lsp-ping.all@tools.ietf.org
Cc: mpls@ietf.org
Subject: [mpls] Meaning of s= ub-TLVs for TLV 21 in Return Path Specified

 

Mach, et al. -

 

In section 4.1. Sending an Echo Request, it is stated:

The Reply Path T=
LV includes one or several reply path sub-TLV(s) to
identify the ret=
urn path(s) the egress LSR should use for its reply.
It would=
 appear that the semantics of TLV 21 are very different than the semantics =
of TLV 1.  Since TLV 1 defines=
 a FEC stack which maps to a single LSP.&n=
bsp; Why do you want the NIL FEC which only makes sense as part of a=
 FEC stack?
Under wh=
at circumstances would you ever use one of the multicast FECs (sub-TLVs 17,=
 18, 19, 20)?
What is =
the meaning of a return path to a VPN IPv4 prefix, or  VPN IPv6 prefix?&=
nbsp; Note that if the prefix is multi-homed it may not even return =
to the originating PE!=

What is =
the meaning of a return path to an L2 VPN endpoint?
George
--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BA3D94szxeml558mbschi_-- From michelg@upperside.fr Wed May 22 05:51:31 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BAE921F852D for ; Wed, 22 May 2013 05:51:31 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrM6Cux9O866 for ; Wed, 22 May 2013 05:51:25 -0700 (PDT) Received: from smtp26.msg.oleane.net (smtp26.msg.oleane.net [62.161.4.26]) by ietfa.amsl.com (Postfix) with ESMTP id 7B06521F856D for ; Wed, 22 May 2013 05:51:24 -0700 (PDT) Received: from MichelGosseDel ([195.6.217.229]) (authenticated) by smtp26.msg.oleane.net (MSA) with ESMTP id r4MCpLpg031686 for ; Wed, 22 May 2013 14:51:22 +0200 X-Oleane-Rep: REPA From: "Michel Gosse" To: References: <002301ce56e6$810fb480$832f1d80$@upperside.fr> <004c01ce56e9$966b5bb0$c3421310$@upperside.fr> In-Reply-To: <004c01ce56e9$966b5bb0$c3421310$@upperside.fr> Date: Wed, 22 May 2013 14:51:17 +0200 Message-ID: <003d01ce56eb$10534900$30f9db00$@upperside.fr> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003E_01CE56FB.D3DF2640" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIpOe69cu5ReSmh16oM9bvOl37lDwGBBAwFmE9ZPFA= Content-Language: fr X-PMX-Spam: Probability=8% X-PFSI-Info: PMX 5.5.9.395186, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.22.123616 (no antivirus check) X-Orange-Auth: bWcyNjMtM0B1cHBlc2lkZS5mci5mdG8= Subject: [mpls] Call for proposals X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 May 2013 12:51:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_003E_01CE56FB.D3DF2640 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The next editions of the MPLS & Ethernet World Congress and the co-located SDN Summit will be organized in Paris next March 18-21, 2014. Both events attracted 1350+ participants in 2013. The call for proposals are available online: http://www.uppersideconferences.com/ ------=_NextPart_000_003E_01CE56FB.D3DF2640 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The next = editions of the MPLS & Ethernet World Congress and the co-located = SDN Summit will be organized in Paris next March 18-21, = 2014.

Both events = attracted 1350+ participants in 2013. 

The call for = proposals are available online: http://www.uppersideconferences.com/

 

 

 =

------=_NextPart_000_003E_01CE56FB.D3DF2640-- From hejia@huawei.com Thu May 23 04:52:35 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A288D21F92EB for ; Thu, 23 May 2013 04:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sAK9LNQi1mFj for ; Thu, 23 May 2013 04:52:23 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F3BD921F9424 for ; Thu, 23 May 2013 04:52:09 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARQ86883; Thu, 23 May 2013 11:52:00 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 23 May 2013 12:51:47 +0100 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 23 May 2013 12:51:59 +0100 Received: from SZXEML505-MBX.china.huawei.com ([169.254.1.213]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.007; Thu, 23 May 2013 19:51:56 +0800 From: "Hejia (Jia)" To: Loa Andersson , Martin Vigoureux , "draft-farbryantrel-mpls-retire-ach-tlv@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Thread-Topic: MPLS-RT review of draft-farbryantrel-mpls-retire-ach-tlv Thread-Index: AQHOS8JMSi4lzPf5Dki5qykaXc/xG5kSvnnw Date: Thu, 23 May 2013 11:51:56 +0000 Message-ID: <735916399E11684EAF4EB4FB376B71952C6CCBDA@SZXEML505-MBX.china.huawei.com> References: <518A064C.7090006@pi.nu> In-Reply-To: <518A064C.7090006@pi.nu> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.169] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-farbryantrel-mpls-retire-ach-tlv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 11:52:36 -0000 SGksDQoNCkkgbm90aWNlZCBhIDAxIHZlcnNpb24gb2YgZHJhZnQtZmFyYnJ5YW50cmVsLW1wbHMt cmV0aXJlLWFjaC10bHYgaXMgYXZhaWxhYmxlLiBTbyBJIGJhc2VkIG15IE1QTFMgUlQgcmV2aWV3 IG9uIHRoYXQgdmVyc2lvbi4gSSB0aGluayB0aGUgZG9jdW1lbnQgaXMgY29oZXJlbnQsIHVzZWZ1 bCwgdGVjaG5pY2FsbHkgc291bmQgYW5kIHJlYWR5IHRvIGJlIGFkb3B0ZWQgYXMgYSBXRyBkcmFm dC4gSnVzdCBvbmUgY29tbWVudDoNCg0KMSkgSW4gdGhlIEFic3RyYWN0IHBhcnQsIGl0IGlzIHdy aXR0ZW4gYXMNCg0KICAgTm8gQXNzb2NpYXRlZCBDaGFubmVsIFR5cGUgeWV0IGRlZmluZWQgdXNl cyBhIFRMVi4gRnVydGhlcm1vcmUsIGl0DQogICBpcyBiZWxpZXZlZCB0aGF0IGhhbmRsaW5nIFRM VnMgaW4gaGFyZHdhcmUgaW50cm9kdWNlcyBzaWduaWZpY2FudA0KICAgcHJvYmxlbXMgdG8gdGhl IGZhc3QtcGF0aCwgYW5kIHNpbmNlIEctQUNoIG1lc3NhZ2VzIGFyZSBpbnRlbmRlZCB0bw0KICAg YmUgcHJvY2Vzc2VkIHN1YnN0YW50aWFsbHkgaW4gaGFyZHdhcmUsIHRoZSB1c2Ugb2YgVExWcyBp bg0KICAgdW5kZXNpcmFibGUuDQoNClRoZSB3aG9sZSBwYXJhZ3JhcGggc2VlbXMgdGFsa2luZyBn ZW5lcmFsbHkgYWJvdXQgVExWcyBmb3IgRy1BQ2ggbWVzc2FnZXMsIG5vdCBzcGVjaWZpY2FsbHkg YW4gQUNIIFRMVi4gVGhpcyBtaWdodCBub3QgYmUgc28gYWNjdXJhdGUgc2luY2Ugd2UgaGF2ZSBz b21lIEctQUNoIGNoYW5uZWwgdHlwZSB1c2luZyBUTFZzIGluIGl0cyBtZXNzYWdlLCBlLmcuIFJG QyA2NDI4IGRlZmluZXMgYSBzb3VyY2UgTUVQLUlEIFRMViBmb3IgdGhlIE1QTFMtVFAgQ1YgdHlw ZSB3aGljaCBhbHNvIHJlcXVpcmVzIGhhcmR3YXJlIHByb2Nlc3NpbmcuIEkgdGhpbmsgaXQgbWln aHQgYmUgYmV0dGVyIHRvIHNpbXBseSBzYXkgQUNIIFRMViBpcyBub3QgdXNlZCBhbmQgbWF5IGNh dXNlIGFkZGl0aW9uYWwgcHJvY2Vzc2luZyB3aGljaCBpcyBub3QgZGVzaXJhYmxlLiBPciBzb21l IGJldHRlciB3b3JkaW5nLi4uDQoNClRoYW5rcyENCg0KDQpCLlIuDQpKaWENCg0KDQotLS0tLdPK vP7Urbz+LS0tLS0NCreivP7IyzogTG9hIEFuZGVyc3NvbiBbbWFpbHRvOmxvYUBwaS5udV0gDQq3 osvNyrG85DogMjAxM8TqNdTCOMjVIDE2OjAxDQrK1bz+yMs6IExpemhvbmcgSmluOyBIZWppYSAo SmlhKTsgR3JlZ29yeSBNaXJza3k7IEVyaWMgT3Nib3JuZSAoZW9zYm9ybmUpOyBNYXJ0aW4gVmln b3VyZXV4DQqzrcvNOiBkcmFmdC1mYXJicnlhbnRyZWwtbXBscy1yZXRpcmUtYWNoLXRsdkB0b29s cy5pZXRmLm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNCtb3zOI6IE1QTFMtUlQgcmV2 aWV3IG9mIGRyYWZ0LWZhcmJyeWFudHJlbC1tcGxzLXJldGlyZS1hY2gtdGx2DQoNCkppYSwgTGl6 aG9uZywgR3JlZyBhbmQgRXJpYywNCg0KWW91IGhhdmUgYmVlbiBzZWxlY3RlZCBhcyBhbiBNUExT IFJldmlldyB0ZWFtIHJldmlld2VycyBmb3INCmRyYWZ0LWZhcmJyeWFudHJlbC1tcGxzLXJldGly ZS1hY2gtdGx2LTAwLg0KDQpOb3RlIHRvIGF1dGhvcnM6IFlvdSBoYXZlIGJlZW4gQ0MnZCBvbiB0 aGlzIGVtYWlsIHNvIHRoYXQgeW91IGNhbiBrbm93DQp0aGF0IHRoaXMgcmV2aWV3IGlzIGdvaW5n IG9uLiBIb3dldmVyLCBwbGVhc2UgZG8gbm90IHJldmlldyB5b3VyIG93bg0KZG9jdW1lbnQuDQoN ClJldmlld3Mgc2hvdWxkIGNvbW1lbnQgb24gd2hldGhlciB0aGUgZG9jdW1lbnQgaXMgY29oZXJl bnQsIGlzIGl0DQp1c2VmdWwgKGllLCBpcyBpdCBsaWtlbHkgdG8gYmUgYWN0dWFsbHkgdXNlZnVs IGluIG9wZXJhdGlvbmFsDQpuZXR3b3JrcyksIGFuZCBpcyB0aGUgZG9jdW1lbnQgdGVjaG5pY2Fs bHkgc291bmQ/ICBXZSBhcmUgaW50ZXJlc3RlZA0KaW4ga25vd2luZyB3aGV0aGVyIHRoZSBkb2N1 bWVudCBpcyByZWFkeSB0byBiZSBjb25zaWRlcmVkIGZvciBXRw0KYWRvcHRpb24gKGllLCBpdCBk b2Vzbid0IGhhdmUgdG8gYmUgcGVyZmVjdCBhdCB0aGlzIHBvaW50LCBidXQgc2hvdWxkIGJlDQph IGdvb2Qgc3RhcnQpLg0KDQpSZXZpZXdzIHNob3VsZCBiZSBzZW50IHRvIHRoZSBkb2N1bWVudCBh dXRob3JzLCBXRyBjby1jaGFpcnMgYW5kDQpXRyBzZWNyZXRhcnksIGFuZCBDQydkIHRvIHRoZSBN UExTIFdHIGVtYWlsIGxpc3QuIElmIG5lY2Vzc2FyeSwgY29tbWVudHMNCm1heSBiZSBzZW50IHBy aXZhdGVseSB0byBvbmx5IHRoZSBXRyBjaGFpcnMuDQoNCkFyZSB5b3UgYWJsZSB0byByZXZpZXcg dGhpcyBkcmFmdCBieSBNYXQgMjQsIDIwMTM/DQoNClRoYW5rcywgTG9hDQooYXMgTVBMUyBXRyBj aGFpcikNCi0tIA0KDQoNCkxvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICBlbWFp bDogbG9hQG1haWwwMS5odWF3ZWkuY29tDQpTZW5pb3IgTVBMUyBFeHBlcnQgICAgICAgICAgICAg ICAgICAgICAgICAgIGxvYUBwaS5udQ0KSHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkg ICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQo= From adrian@olddog.co.uk Thu May 23 05:15:08 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80E2721F9234 for ; Thu, 23 May 2013 05:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.111 X-Spam-Level: X-Spam-Status: No, score=-1.111 tagged_above=-999 required=5 tests=[AWL=-1.301, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LAa0yyN4dk+C for ; Thu, 23 May 2013 05:14:56 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id CACF621F91CB for ; Thu, 23 May 2013 05:14:55 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4NCEkkN007682; Thu, 23 May 2013 13:14:46 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4NCEhQV007621 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 23 May 2013 13:14:44 +0100 From: "Adrian Farrel" To: "'Hejia \(Jia\)'" , "'Loa Andersson'" , "'Martin Vigoureux'" , , References: <518A064C.7090006@pi.nu> <735916399E11684EAF4EB4FB376B71952C6CCBDA@SZXEML505-MBX.china.huawei.com> In-Reply-To: <735916399E11684EAF4EB4FB376B71952C6CCBDA@SZXEML505-MBX.china.huawei.com> Date: Thu, 23 May 2013 13:14:43 +0100 Message-ID: <040501ce57af$1d2f8570$578e9050$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEA85wkIqTcvalMAOBxYkCEqrMtWQIYPP8Lmpy02EA= Content-Language: en-gb Cc: mpls@ietf.org Subject: Re: [mpls] MPLS-RT review of draft-farbryantrel-mpls-retire-ach-tlv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 12:15:08 -0000 Thanks Jia, Your point is well taken and the Abstract in the working copy (ready to = post) now reads... The MPLS Generic Associated Channel (G-ACh) is a generalization of the applicability of the Pseudowire (PW) Associated Channel Header (ACH). RFC 5586 defines the concept of TLV constructs that can be carried in messages on the G-ACh by placing them in the ACH between the fixed header fields and the G-ACh message. These TLVs are called ACH TLVs No Associated Channel Type yet defined uses an ACH TLV. Furthermore, it is believed that handling TLVs in hardware introduces significant problems to the fast-path, and since G-ACh messages are intended to be processed substantially in hardware, the use of TLVs in undesirable. This document updates RFC 5586 by retiring ACH TLVs and removing the associated registry. Cheers, Adrian > -----Original Message----- > From: Hejia (Jia) [mailto:hejia@huawei.com] > Sent: 23 May 2013 12:52 > To: Loa Andersson; Martin Vigoureux; = draft-farbryantrel-mpls-retire-ach- > tlv@tools.ietf.org; mpls-chairs@tools.ietf.org > Cc: mpls@ietf.org > Subject: Re: MPLS-RT review of draft-farbryantrel-mpls-retire-ach-tlv >=20 > Hi, >=20 > I noticed a 01 version of draft-farbryantrel-mpls-retire-ach-tlv is = available. So I > based my MPLS RT review on that version. I think the document is = coherent, > useful, technically sound and ready to be adopted as a WG draft. Just = one > comment: >=20 > 1) In the Abstract part, it is written as >=20 > No Associated Channel Type yet defined uses a TLV. Furthermore, it > is believed that handling TLVs in hardware introduces significant > problems to the fast-path, and since G-ACh messages are intended to > be processed substantially in hardware, the use of TLVs in > undesirable. >=20 > The whole paragraph seems talking generally about TLVs for G-ACh = messages, > not specifically an ACH TLV. This might not be so accurate since we = have some G- > ACh channel type using TLVs in its message, e.g. RFC 6428 defines a = source MEP- > ID TLV for the MPLS-TP CV type which also requires hardware = processing. I think > it might be better to simply say ACH TLV is not used and may cause = additional > processing which is not desirable. Or some better wording... >=20 > Thanks! >=20 >=20 > B.R. > Jia >=20 >=20 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Loa Andersson [mailto:loa@pi.nu] > =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA5=D4=C28=C8=D5 16:01 > =CA=D5=BC=FE=C8=CB: Lizhong Jin; Hejia (Jia); Gregory Mirsky; Eric = Osborne (eosborne); Martin > Vigoureux > =B3=AD=CB=CD: draft-farbryantrel-mpls-retire-ach-tlv@tools.ietf.org; = mpls- > chairs@tools.ietf.org > =D6=F7=CC=E2: MPLS-RT review of draft-farbryantrel-mpls-retire-ach-tlv >=20 > Jia, Lizhong, Greg and Eric, >=20 > You have been selected as an MPLS Review team reviewers for > draft-farbryantrel-mpls-retire-ach-tlv-00. >=20 > Note to authors: You have been CC'd on this email so that you can know > that this review is going on. However, please do not review your own > document. >=20 > Reviews should comment on whether the document is coherent, is it > useful (ie, is it likely to be actually useful in operational > networks), and is the document technically sound? We are interested > in knowing whether the document is ready to be considered for WG > adoption (ie, it doesn't have to be perfect at this point, but should = be > a good start). >=20 > Reviews should be sent to the document authors, WG co-chairs and > WG secretary, and CC'd to the MPLS WG email list. If necessary, = comments > may be sent privately to only the WG chairs. >=20 > Are you able to review this draft by Mat 24, 2013? >=20 > Thanks, Loa > (as MPLS WG chair) > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From adrian@olddog.co.uk Thu May 23 06:45:02 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D319821F8A6B for ; Thu, 23 May 2013 06:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.425 X-Spam-Level: X-Spam-Status: No, score=-2.425 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ax5Mv4U1iyUT for ; Thu, 23 May 2013 06:44:57 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id F3FC221F89E1 for ; Thu, 23 May 2013 06:44:45 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4NDihwU005043 for ; Thu, 23 May 2013 14:44:43 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4NDif9C005001 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 23 May 2013 14:44:42 +0100 From: "Adrian Farrel" To: Date: Thu, 23 May 2013 14:44:41 +0100 Message-ID: <042401ce57bb$adfc5860$09f50920$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5Xu6u1DbATyNo6T0Swwcoohg+4jw== Content-Language: en-gb Subject: [mpls] FW: New Version Notification for draft-farbryantrel-mpls-retire-ach-tlv-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 13:45:02 -0000 Hi, Update to take account of MPLS-RT reviews. Many thanks to them for their input. Adrian > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: 23 May 2013 14:43 > To: Adrian Farrel; Stewart Bryant > Subject: New Version Notification for = draft-farbryantrel-mpls-retire-ach-tlv- > 02.txt >=20 >=20 > A new version of I-D, draft-farbryantrel-mpls-retire-ach-tlv-02.txt > has been successfully submitted by Adrian Farrel and posted to the > IETF repository. >=20 > Filename: draft-farbryantrel-mpls-retire-ach-tlv > Revision: 02 > Title: Retiring TLVs from the Associated Channel Header of the MPLS > Generic Associated Channel > Creation date: 2013-05-23 > Group: Individual Submission > Number of pages: 5 > URL: = http://www.ietf.org/internet-drafts/draft-farbryantrel-mpls-retire- > ach-tlv-02.txt > Status: = http://datatracker.ietf.org/doc/draft-farbryantrel-mpls-retire-ach-tlv > Htmlized: = http://tools.ietf.org/html/draft-farbryantrel-mpls-retire-ach-tlv-02 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-farbryantrel-mpls-retire-ach- > tlv-02 >=20 > Abstract: > The MPLS Generic Associated Channel (G-ACh) is a generalization of > the applicability of the Pseudowire (PW) Associated Channel Header > (ACH). RFC 5586 defines the concept of TLV constructs that can be > carried in messages on the G-ACh by placing them in the ACH between > the fixed header fields and the G-ACh message. These TLVs are = called > ACH TLVs >=20 > No Associated Channel Type yet defined uses an ACH TLV. = Furthermore, > it is believed that handling TLVs in hardware introduces = significant > problems to the fast-path, and since G-ACh messages are intended to > be processed substantially in hardware, the use of TLVs in > undesirable. >=20 > This document updates RFC 5586 by retiring ACH TLVs and removing = the > associated registry. >=20 >=20 >=20 >=20 > The IETF Secretariat From loa@pi.nu Thu May 23 09:38:12 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3656521F9777 for ; Thu, 23 May 2013 09:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.021 X-Spam-Level: X-Spam-Status: No, score=-101.021 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IPJsEsYYo02d for ; Thu, 23 May 2013 09:37:57 -0700 (PDT) Received: from pipi.pi.nu (unknown [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id D88C321F976E for ; Thu, 23 May 2013 09:36:46 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 80B3E180287B; Thu, 23 May 2013 18:36:45 +0200 (CEST) Message-ID: <519E459D.40105@pi.nu> Date: Thu, 23 May 2013 18:36:45 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-farbryantrel-mpls-retire-ach-tlv@tools.ietf.org, "mpls-chairs@tools.ietf.org" Subject: [mpls] adopting draft-farbryantrel-mpls-retire-ach-tlv as an MPLS working group draft X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 16:38:12 -0000 Working Group, we have a quite simple and straightforward draft, that is also necessary to progress other working group drafts - draft-farbryantrel-mpls-retire-ach-tlv. The draft has been through an MPLS-RT review and updated after the (small) comments in that review. All reviewers agree that the draft is ready to be adopted as a working group draft. The working group chairs has re-read the thread on this draft and found a good support in the working group to make it a working group document. The working group chairs has therefore decided to make the draft an MPLS working group document. The authors have stated that they do not know of any IPR applicable to this draft; in the unlikely event that some have IPRs that are applicable please disclose this on the mpls wg mailing list. Could the authors please re-post the draft as draft-ietf-mpls-retire-ach-tlv-00. /Loa for the mpls wg co-chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From adrian@olddog.co.uk Thu May 23 13:53:06 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3FC421F96BB for ; Thu, 23 May 2013 13:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKDl-MIuam0y for ; Thu, 23 May 2013 13:52:42 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 96C0621F970A for ; Thu, 23 May 2013 13:11:07 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4NKB4OO019319; Thu, 23 May 2013 21:11:04 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4NKB2Ou019311 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 23 May 2013 21:11:03 +0100 From: "Adrian Farrel" To: Date: Thu, 23 May 2013 21:11:02 +0100 Message-ID: <04ae01ce57f1$a6b72b80$f4258280$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5X8Z5cL5m9BeCeSFm7SPc+FcNigQ== Content-Language: en-gb Cc: mpls@ietf.org, mpls-chairs@tools.ietf.org Subject: [mpls] AD review of draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 20:53:07 -0000 Hi, I have done my usual AD review of this draft on receipt of the publication request from the MPLS WG chairs. As well as the desire to remove issues that might otherwise show up during IETF last call and IESG review (thereby saving resources), my review is to make sure that I understand the intention and details of the work so that I can support the document as it goes through these later reviews and also the publication process. As you will see from my comments below, I am not currently comfortable with the document. At the moment I am not saying that the proposals are bad and dangerous, although I am at least believing them to be unnecessary and based on some misstatements of the problems that need to be addressed. I understand that the chairs report there is WG consensus behind this document in its current form, but I am unable to support it for publication as an RFC. You have two options open to you to advance your work as a standards track RFC. Firstly, you could seek to address my concerns through a combination of changes to the text and discussions with me. Secondly, you can attempt to find another AD to sponsor the work - possibly Stewart is a good starting point. For the moment, I am returning the I-D to the working group. Thanks, Adrian --- Was this document shown to the CCAMP working group? The P2MP work (4875) was developed in partnership with CCAMP because it was intended to be equally applicable to MPLS-TE and GMPLS. Presumably this is also true of this work. You might find that by consulting CCAMP you are able to get some more P2MP implementers to have a look at the problems this draft is proposing to solve. --- I am surprised that the working group has taken this approach to the described problem of re-merge avoidance. This problem is addressed by the combination of PCE and Path Keys. However, if the working group has considered that approach and has consensus to take this other approach, I will not object. Could the chairs confirm that the existing mechanisms have been considered and that the WG determined to add new extensions to the signaling protocols instead. --- I'm afraid I find myself wondering whether this document is addressing the wrong problem :-( Re-merge is a bad thing to have as a persistent situation, and certainly must not be allowed to cause data duplication downstream of the re-remerge point. However, avoiding re-merge by selecting disjoint paths is not the solution. If re-merge happens, it is because the path to one set of destinations has intersected the path to another set of destinations. When this happens, one of the two paths to the re-merge point must be optimal (for *any* definition of optimal) or the paths are equally optimal. In either case, the correct solution is to move all of the destinations (the union of the two sets) onto the same path and prune out the sub-optimal one. In this case, the bottom line will be that the upstream branch was wrong to use two distinct domain border nodes for the two sets of destinations. That is the problem that needs to be fixed. What I seem to be reading here is an attempt to avoid re-merge that favors the use of suboptimal paths. In many network configurations that will be impossible. But in any case, it will prove as costly in terms of network resources as the re-merge itself. The discussion about re-optimization using 4736, is a different problem that you can raise. The description of the problem doesn't really surface until the description of the solution in Section 1.1, which is a pity. This is largely a descriptive issue, although I would argue that the partial reomptimization is easily handled using partial resignaling, and therefore without any protocol extensions. --- Please fix the minor spacing not reported by idnits. --- idnits shows several problems with references. You are missing RFC 2119 from the normative references. You are missing RFC 4874 from the informative references. You are missing RFC 2205 from the normative references. RFC 4726 is an informative reference, but not cited. Possibly work it into the 4th para of the Introduction? RFC 5920 is a downref. Does it need to be a normative reference? RFC 4736 is a downref. It appears that you are using it in a normative way - please confirm this so that we can handle the downref correctly. Document Shepherd - please update the write-up to correctly note the downrefs that remain after this work. --- Please remove citations from the Abstract. The Abstract is stand-alone text and cannot have external references. --- The Abstract is not clear and needs work. - The issues *may* arise, but do not always arise - The "computation of loosely routed inter-domain P2MP-TE LSP paths that are re-merge free" is not an issue and is not addressed in this document. Please describe the actual issue you are addressing. - s/vs./versus/ - I don't think "the loosely routing domain ingress border node is not aware of the reoptimization scope" describes a problem well because the issue is the "there is no way to indicate which branches of the P2MP tree are to be reoptimised". - In the light of my observation that techniques already exist to address the problems described in this document, it may be too strong to say "This document defines the required protocol extensions needed for ..." Maybe change this to "This document defines signaling protocol extensions for..." --- It would really help the reader and reviewers if someone could take an editorial pass on the document. This is not so much a problem of English usage as missing words and such like. A native speaker would clean it up very quickly and avoid the risk of the RFC Editor accidentally breaking the technical content. --- In the Introduction... Consequently one of the requirements for signaling P2MP LSPs is to choose a P2MP path that is re-merge free. Is this a signaling requirement? 1. Surely it is a path computation requirement, if it is a requirement at all. 2. Isn't the point that signaling is supposed to detect and resolve re-merge issues rather than avoid them? --- In the Introduction... For the purposes of this document, a domain is considered to be any collection of network elements within a common sphere of address management or path computational responsibility. Examples of such domains include Interior Gateway Protocol (IGP) areas and Autonomous Systems (ASes). A border node is a node between different routing domains. "domain" or "routing domain"? --- In the Introduction... In that case, the border node for a new domain will be given loose next hops for one or more destinations in a P2MP LSP. s/will be/may be/ ? --- In the Introduction... A border node can ensure that it computes the re-merge free paths while performing loose hop ERO expansions by individually grafting destinations. Note that the computed P2MP tree by a border node in this case may not be optimal. Why are you suggesting a mechanism for computing paths? That is an implementation detail. Furthermore, suggesting a mechanism that is almost certain to generate a suboptimal solution seems perverse! --- In the Introduction... In that case, existing protocol mechanisms do not provide sufficient information for it to be able to expand the loose hop(s) such that the overall P2MP LSP tree is guaranteed to be re-merge free. Weeeeell... Even if you don't want to use PCE and Path Key, you could use RRO and XRO with suitable staggered processing at the branch node. That would provide sufficient information using existing protocol elements, although a small (but obvious) piece of processing needs to added at the branch node --- In the Introduction... [RFC4875] specifies two approaches to handle re-merge conditions. The first method is based on control plane handling the re-merge. In this case the node detecting the re-merge condition, i.e. the re-merge node initiates the removal of the re-merge sub-LSP(s) by sending a PathErr message(s) towards the ingress node. However, this can lead to a deadlock in setting up the P2MP LSP in certain cases; for example, when the first S2L setup causes the re-merge with all subsequent S2Ls in the tree. I am glad you are now discussing the mechanisms in 4875, but I disagree that there is a deadlock condition as you claim. You are saying that if the first S2L sub-LSP takes a route that causes all other S2L sub-LSPs to re-merge then there will be deadlock. Far from it! What will happen is that a PathErr will be sent for each subsequent S2L sub-LSP stating "re-merge", and the destinations for each subsequent S2L sub-LSP will be added to the set of destinations in the first S2L sub-LSP. So, what is the issue with the first mechanism in 4875? --- In the Introduction... [RFC4736] defines procedures and signaling extensions for reoptimizing an inter-domain P2P LSP. Specifically, an ingress node sends a "path re-evaluation request" to a border node by setting a flag (0x20) in SESSION_ATTRIBUTES object in a Path message. A border node sends a PathErr code 25 (notify error defined in [RFC3209]) with sub-code 6 to indicate "preferable path exists" to the ingress node. The ingress node upon receiving this PathErr may initiate reoptimization of the LSP. [RFC4736] however does not define a procedure to reoptimize the entire P2MP LSP as a whole tree. I'm afraid that the mechanism you have accurately described could be used precisely as specified for reoptimising the whole tree since such reoptimization takes place from the ingress node. But I think (from 1.1) that you are trying to describe the subtleties involved in reoptimizing only some parts of the tree downstream of the reporting border node. Firstly, you need to clarify the problem being addressed with clearer text in the Introduction. Then you need to decide why you need to address the problem. In 4736 there is no distinction made about which of the loose hops should be reomptimised and which not. So it is unclear why you should want to apply such a filter in the case of a P2MP LSP. If there is a reason it would be good to set it out in more detail. It is also possible that the ingress will want to dampen its activity to ensure is receives all 25/6 reports before starting reoptimization. It is also possible that if you ignore the way 4875 handles remerge, this could get complicated. --- In the Introduction... The Sub-Group-Based reoptimization is not always applicable because it can lead to data duplication inside the backbone. I am suspicious of this statement! Are you saying that the remerge issues may give rise to data duplication? Or is it the make-before- break nature that may cause the problem? Is it a transitory problem during the one or two seconds of signaling change, or is it a long-term problem? If you want to persist with this assertion then you need to substantiate it in the draft. --- The comparison in Section 1.1 of re-merge "avoidance" with crankback is interesting, but the two issues are different. Crankback is designed to facilitate re-route to avoid blocking resources, while re-merge avoidance is about moving destinations from one sub-tree to another. But, you could consider the PathErr mechanism of 4875 as crankback because it reports the error relating to the re-merge node, it unpicks the LSP setup, and it allows an upstream node to "correct" the issue. The only thing that you might want to add to 4875 is the replacement of the ID of the reporting node with the ID of the reporting domain so that the upstream node can apply meaning to the PathErr. Maybe if the problem was clearly described, this solution would stand out. --- Section 1.3 says that this work is limited to "multiple routing domains that belong to a single administrative area. Use case for the Multiple administrative domains (e.g. autonomous systems) is outside the scope of this document." A couple of points: - An "administrative area" is a new term and the next sentence uses "administrative domains" so that is probably what you mean. - It is unclear whether multiple ASes is in scope since the second sentence appears to rule them out, but multiple ASes may be under the care of one administrator. - You haven't given any reason for excluding multiple administrative domains, and that would help people understand what your objectives are and what the problems are. --- Section 3 It is RECOMMENDED that boundary re-routing is requested for P2MP LSPs The use of upper case "RECOMMENDED" is equivalent to "SHOULD". This is usually protocol requirements language. Anyway, if you use "SHOULD" you also need to discuss the associated "MAY". --- In Section 3.1 you recommend that the ingress node of a P2MP LSP selects the same ingress border node in the loose hop ERO for all sibling S2L sub-LSPs that transit through a given domain. This, of course, produces sub-optimal LSPs and can be resolved using PCE. But I am interested in the overlap between this statement and the scope statement in 1.3. You are recommending using only single attachments between domains: that means that remerge can only happen when the sub- LSPs transit different domains and come back together in a further domain. But since you are (apparently) limiting to IGP areas and ruling out ASes, the largest domain diameter you have is 3 with the result that remerge is entirely impossible! --- In Section 3.1 you have "RECOMMENDED". What is the associated "MAY"? --- Here's another example from Section 3.2 If an ingress border node on the path of the P2MP LSP is unable to find a route that can supply the required resources or that is re- merge free, it MUST generate a PathErr message for the subset of the S2L sub-LSPs which it is not able to route. This implies that the border node is trying to find a disjoint path. Such a path represents a waste of network resources that is *worse* than the data plane remerge case that you reject as a bad idea. The point of re-merge avoidance is simply moving destinations from one sub-tree to another and it can only be done at the branch point for the two trees - or even at the ingress depending on your signaling approach and explicit paths. --- Section 3.2 For this purpose the ingress border node SHOULD try to find a minimum subset of S2L sub- LSPs for which the PathErr needs to be generated towards the ingress node. These are the S2L sub-LSPs on an incoming interface that has less number of S2L sub-LSPs compared to the second incoming interface that is causing the re-merge condition. OK. It took me four or five readings and a lot of pain to parse what you are trying to say. You are saying that, if the border node is a branch node for two sets of sub-LSPs that are remerging, then the border node should fix this by moving the smaller set to share the path with the larger set. There are two reasons why this is a bad idea: 1. The first set may have been set up with a Path/Resv exchange, while the second set has not been set up and a PathErr was returned. Maybe the remerge node could have made the decision you are suggesting, but even that sounds like a bad idea. 2. The choice of the correct path to the remerge node should be made according to which is the shortest path, not which path has the most destinations. --- Section 3.2 The RSVP-TE Notify messages do not include S2L_SUB_LSP objects and cannot be used to send errors for a subset of the S2L sub-LSPs in a Path message. This is not true! A Downstream Notify message (headed upstream) is described in RFC 3473 as: ::= [] [ [ | ] ... ] [ ] ::= [ ] | ::= [...] And according to RFC 4875, nets down to one or more of... ::= [ ] --- Section 3.2 A border node receiving a PathErr message for a set of S2L sub-LSPs MAY hold the message and attempt to signal an alternate path that can avoid re-merge through its domain for those S2L sub-LSPs that pass through it. However, in the case of a re-merge error for which some of the re-merging S2L sub-LSPs do not pass through the border node, it SHOULD propagate the PathErr upstream towards the ingress node. If the subsequent attempt by the border node is successful, the border node discards the held PathErr and follows the crankback roles of [RFC4920] and [RFC5151]. If repeated subsequent attempts by the border node are unsuccessful, the border node MUST send the held PathErr upstream towards the ingress node. How can an attempt to avoid re-merge be unsuccessful? There is already a suitable path. We know this because the re-merge has happened. --- Section 3.2 If the ingress node receives a PathErr message with error code "Routing Problem" and error value "ERO resulted in re-merge", then it SHOULD attempt to signal an alternate path through a different domain or through a different border node for the affected S2L sub-LSPs. The ingress node MAY use the error node information from the PathErr for this purpose. This is plain wrong. It should attempt to move the destinations to the same sub-tree, not try to signal the remerging destinations on a diverse sub-tree. --- Section 4 purports to be about the dataplane re-merge handling scenario, and it starts well. But then... The following sections define the RSVP-TE signaling extensions for "P2MP- TE Re-merge Recording Request" and "P2MP-TE Re-merge Present" messages. That look like it is control plane work and so does not belong in this section. Furthermore, this section appears to be offering a third solution to add to the two noted in 4875. That is, you are proposing that dataplane handling should be used, but that the control plane should be used to resolve the issue. This is an OK idea, but was discussed at the time of 4875 when two approaches handling this situation were discussed. 1. Use a Notify message sent after the Resv 2. Use a non-destructive PathErr sent after the Resv Admittedly, neither of those approaches is quite tidy, but it was thought that if you cared about the remerge you would fix it at setup time, and if you didn't care, then you didn't care. Thus the case you are fixing is a corner case (care a bit, but not too much) and the existing untidy solutions are enough. Nevertheless, the mechanism you describe does provide some additional useful diagnostics, and so should not be ruled out. Of course, those diagnostics are already visible simply by inspecting the full set of RRO information from the various S2L sub-LSPs as a re-merge point will show up as the same node appearing in two different sub-trees. Thus, the question only applies when RRO information is being stripped at domain boundaries. However, this last issue is the one you note in the final paragraph of section 4.3. There you appear to say that since the re-merge report info would be stripped from the Resv, the Resv should be discarded and a PathErr sent upstream. That would be fine, but it does seem to leave half an LSP provisioned and doing nothing (downstream between the border node and the re-merge point) --- 4.3 This can be achieved by computing and selecting alternate path(s) for the S2L(s) bypassing the re-merge node(s). Again, avoiding the remerge node is not the best result. --- Section 5 Re-merges between S2Ls in a single domain can occur due to provisioning errors or path computation errors in the environment where IGP-TE or PCE is used. What is a "provisioning error"? Are you referring to cases where the EROs of P2MP trees are entered by hand? What has IGP-TE to do with this? If PCE (whether a separate component or embedded in an LSR) is making such fundamental computation errors, then we should certainly not crash, but I also don't think we should optimise the protocol to handle it. This represents a critical implementation bug! --- Section 6.3 Using signaling procedure defined in [RFC4736], an ingress node MUST initiate "path re-evaluation request" query to reoptimize a destination in a P2MP LSP. Note that this message MUST be used to reoptimize a single or a sub-set of the destinations in a P2MP LSP. Ingress node MUST send this query in a Path message for each destination it is reoptimizing. When a Path message for a destination in a P2MP LSP with "path re-evaluation request" flag [RFC4736] is received at the border node, it MUST re-compute the loose-hop ERO to see if a preferable path exists for that destination. I am hugely worried about your use of 2119 language in this text. Is it your intention to redefine the procedures of RFC 4736? Because that is what you are doing! Perhaps you consider that you are only defining the procedures for P2MP LSPs with the claim that they were not covered by 4736. I don't see on what evidence such a claim would be made, and I am particularly concerned that you have turned the request in 4736 into a demand in your draft. --- Section 6.3 is almost impossible to understand. I think there are probably some assumptions that a request to reoptimise the path to a single destination would: a. be made b. be responded with "not telling you, but I could reoptimise the whole sub-tree." On the other hand, there also seems to be a desire to send a reoptimise request that identifies just on destination, but is actually a request to reoptimise the whole tree. Colour me confused! From internet-drafts@ietf.org Thu May 23 14:52:45 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBF621F98A4; Thu, 23 May 2013 14:52:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.447 X-Spam-Level: X-Spam-Status: No, score=-102.447 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5RtOJ0T3kUy; Thu, 23 May 2013 14:52:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A23A21F86AE; Thu, 23 May 2013 14:04:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130523210405.28308.88900.idtracker@ietfa.amsl.com> Date: Thu, 23 May 2013 14:04:05 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-retire-ach-tlv-00.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 May 2013 21:52:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Retiring TLVs from the Associated Channel Header of the = MPLS Generic Associated Channel Author(s) : Adrian Farrel Stewart Bryant Filename : draft-ietf-mpls-retire-ach-tlv-00.txt Pages : 5 Date : 2013-05-23 Abstract: The MPLS Generic Associated Channel (G-ACh) is a generalization of the applicability of the Pseudowire (PW) Associated Channel Header (ACH). RFC 5586 defines the concept of TLV constructs that can be carried in messages on the G-ACh by placing them in the ACH between the fixed header fields and the G-ACh message. These TLVs are called ACH TLVs No Associated Channel Type yet defined uses an ACH TLV. Furthermore, it is believed that handling TLVs in hardware introduces significant problems to the fast-path, and since G-ACh messages are intended to be processed substantially in hardware, the use of TLVs in undesirable. This document updates RFC 5586 by retiring ACH TLVs and removing the associated registry. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-retire-ach-tlv There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-retire-ach-tlv-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From hejia@huawei.com Fri May 24 03:58:07 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D3EA21F9418 for ; Fri, 24 May 2013 03:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.057 X-Spam-Level: X-Spam-Status: No, score=-2.057 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CN_BODY_35=0.339, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lOEzk8FqpRTW for ; Fri, 24 May 2013 03:58:02 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id ECB1021F8FA9 for ; Fri, 24 May 2013 03:57:58 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATD11596; Fri, 24 May 2013 10:57:57 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 24 May 2013 11:57:38 +0100 Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 24 May 2013 11:57:38 +0100 Received: from SZXEML505-MBX.china.huawei.com ([169.254.1.213]) by szxeml412-hub.china.huawei.com ([10.82.67.91]) with mapi id 14.01.0323.007; Fri, 24 May 2013 18:57:24 +0800 From: "Hejia (Jia)" To: "adrian@olddog.co.uk" , "'Loa Andersson'" , "'Martin Vigoureux'" , "draft-farbryantrel-mpls-retire-ach-tlv@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Thread-Topic: MPLS-RT review of draft-farbryantrel-mpls-retire-ach-tlv Thread-Index: AQHOS8JMSi4lzPf5Dki5qykaXc/xG5kSvnnw//+CHICAAeqBsA== Date: Fri, 24 May 2013 10:57:24 +0000 Message-ID: <735916399E11684EAF4EB4FB376B71952C6CCF9A@SZXEML505-MBX.china.huawei.com> References: <518A064C.7090006@pi.nu> <735916399E11684EAF4EB4FB376B71952C6CCBDA@SZXEML505-MBX.china.huawei.com> <040501ce57af$1d2f8570$578e9050$@olddog.co.uk> In-Reply-To: <040501ce57af$1d2f8570$578e9050$@olddog.co.uk> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.169] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-farbryantrel-mpls-retire-ach-tlv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 10:58:07 -0000 QWRyaWFuLA0KDQpUaGFua3MgZm9yIHlvdXIgcHJvbXB0IHJlc3BvbnNlLiBZb3UgYXJlIHNvIHF1 aWNrLiBJIG5vdGljZWQgeW91IGhhdmUgYWxyZWFkeSB1cGxvYWRlZCBhbm90aGVyIFdHIHZlcnNp b24gd2hlbiBJIGdvdCB0aW1lIHRvIHJlYWQgZW1haWxzIHRvZGF5Oi0pIA0KSWYgcG9zc2libGUs IEkgZ3Vlc3MgdGhlIGxhc3Qgc2VudGVuY2Ugb2YgdGhlIHNlY29uZCBwYXJhZ3JhcGggY2FuIGJl IG1vcmUgcHJlY2lzZSBieSBhZGRpbmcgIkFDSCIgYmVmb3JlICJUTFZzIiB3aGljaCByZWFkcw0K DQoiIHRoZSB1c2Ugb2YgQUNIIFRMVnMgaXMgdW5kZXNpcmFibGUuIiAgKHR5cG86IHMvaW4vaXMp DQoNClRoaXMgd2lsbCBoZWxwIHRvIHJlbW92ZSB0aGUgaW1wYWN0IHRvIG90aGVyIFRMVnMgdXNl ZCBpbiBHLUFDaCBtZXNzYWdlcyBidXQgbm90IGluIHRoZSBBQ0guDQoNClRoYW5rcyEgDQoNCg0K Qi5SLg0KSmlhDQoNCg0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogQWRyaWFuIEZhcnJl bCBbbWFpbHRvOmFkcmlhbkBvbGRkb2cuY28udWtdIA0Kt6LLzcqxvOQ6IDIwMTPE6jXUwjIzyNUg MjA6MTUNCsrVvP7IyzogSGVqaWEgKEppYSk7ICdMb2EgQW5kZXJzc29uJzsgJ01hcnRpbiBWaWdv dXJldXgnOyBkcmFmdC1mYXJicnlhbnRyZWwtbXBscy1yZXRpcmUtYWNoLXRsdkB0b29scy5pZXRm Lm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcNCrOty806IG1wbHNAaWV0Zi5vcmcNCtb3 zOI6IFJFOiBNUExTLVJUIHJldmlldyBvZiBkcmFmdC1mYXJicnlhbnRyZWwtbXBscy1yZXRpcmUt YWNoLXRsdg0KDQpUaGFua3MgSmlhLA0KDQpZb3VyIHBvaW50IGlzIHdlbGwgdGFrZW4gYW5kIHRo ZSBBYnN0cmFjdCBpbiB0aGUgd29ya2luZyBjb3B5IChyZWFkeSB0byBwb3N0KQ0Kbm93IHJlYWRz Li4uDQoNCiAgIFRoZSBNUExTIEdlbmVyaWMgQXNzb2NpYXRlZCBDaGFubmVsIChHLUFDaCkgaXMg YSBnZW5lcmFsaXphdGlvbiBvZg0KICAgdGhlIGFwcGxpY2FiaWxpdHkgb2YgdGhlIFBzZXVkb3dp cmUgKFBXKSBBc3NvY2lhdGVkIENoYW5uZWwgSGVhZGVyDQogICAoQUNIKS4gIFJGQyA1NTg2IGRl ZmluZXMgdGhlIGNvbmNlcHQgb2YgVExWIGNvbnN0cnVjdHMgdGhhdCBjYW4gYmUNCiAgIGNhcnJp ZWQgaW4gbWVzc2FnZXMgb24gdGhlIEctQUNoIGJ5IHBsYWNpbmcgdGhlbSBpbiB0aGUgQUNIIGJl dHdlZW4NCiAgIHRoZSBmaXhlZCBoZWFkZXIgZmllbGRzIGFuZCB0aGUgRy1BQ2ggbWVzc2FnZS4g IFRoZXNlIFRMVnMgYXJlIGNhbGxlZA0KICAgQUNIIFRMVnMNCg0KICAgTm8gQXNzb2NpYXRlZCBD aGFubmVsIFR5cGUgeWV0IGRlZmluZWQgdXNlcyBhbiBBQ0ggVExWLiAgRnVydGhlcm1vcmUsDQog ICBpdCBpcyBiZWxpZXZlZCB0aGF0IGhhbmRsaW5nIFRMVnMgaW4gaGFyZHdhcmUgaW50cm9kdWNl cyBzaWduaWZpY2FudA0KICAgcHJvYmxlbXMgdG8gdGhlIGZhc3QtcGF0aCwgYW5kIHNpbmNlIEct QUNoIG1lc3NhZ2VzIGFyZSBpbnRlbmRlZCB0bw0KICAgYmUgcHJvY2Vzc2VkIHN1YnN0YW50aWFs bHkgaW4gaGFyZHdhcmUsIHRoZSB1c2Ugb2YgVExWcyBpbg0KICAgdW5kZXNpcmFibGUuDQoNCiAg IFRoaXMgZG9jdW1lbnQgdXBkYXRlcyBSRkMgNTU4NiBieSByZXRpcmluZyBBQ0ggVExWcyBhbmQg cmVtb3ZpbmcgdGhlDQogICBhc3NvY2lhdGVkIHJlZ2lzdHJ5Lg0KDQpDaGVlcnMsDQpBZHJpYW4N Cg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBIZWppYSAoSmlhKSBbbWFp bHRvOmhlamlhQGh1YXdlaS5jb21dDQo+IFNlbnQ6IDIzIE1heSAyMDEzIDEyOjUyDQo+IFRvOiBM b2EgQW5kZXJzc29uOyBNYXJ0aW4gVmlnb3VyZXV4OyBkcmFmdC1mYXJicnlhbnRyZWwtbXBscy1y ZXRpcmUtYWNoLQ0KPiB0bHZAdG9vbHMuaWV0Zi5vcmc7IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYu b3JnDQo+IENjOiBtcGxzQGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBNUExTLVJUIHJldmlldyBv ZiBkcmFmdC1mYXJicnlhbnRyZWwtbXBscy1yZXRpcmUtYWNoLXRsdg0KPiANCj4gSGksDQo+IA0K PiBJIG5vdGljZWQgYSAwMSB2ZXJzaW9uIG9mIGRyYWZ0LWZhcmJyeWFudHJlbC1tcGxzLXJldGly ZS1hY2gtdGx2IGlzIGF2YWlsYWJsZS4NClNvIEkNCj4gYmFzZWQgbXkgTVBMUyBSVCByZXZpZXcg b24gdGhhdCB2ZXJzaW9uLiBJIHRoaW5rIHRoZSBkb2N1bWVudCBpcyBjb2hlcmVudCwNCj4gdXNl ZnVsLCB0ZWNobmljYWxseSBzb3VuZCBhbmQgcmVhZHkgdG8gYmUgYWRvcHRlZCBhcyBhIFdHIGRy YWZ0LiBKdXN0IG9uZQ0KPiBjb21tZW50Og0KPiANCj4gMSkgSW4gdGhlIEFic3RyYWN0IHBhcnQs IGl0IGlzIHdyaXR0ZW4gYXMNCj4gDQo+ICAgIE5vIEFzc29jaWF0ZWQgQ2hhbm5lbCBUeXBlIHll dCBkZWZpbmVkIHVzZXMgYSBUTFYuIEZ1cnRoZXJtb3JlLCBpdA0KPiAgICBpcyBiZWxpZXZlZCB0 aGF0IGhhbmRsaW5nIFRMVnMgaW4gaGFyZHdhcmUgaW50cm9kdWNlcyBzaWduaWZpY2FudA0KPiAg ICBwcm9ibGVtcyB0byB0aGUgZmFzdC1wYXRoLCBhbmQgc2luY2UgRy1BQ2ggbWVzc2FnZXMgYXJl IGludGVuZGVkIHRvDQo+ICAgIGJlIHByb2Nlc3NlZCBzdWJzdGFudGlhbGx5IGluIGhhcmR3YXJl LCB0aGUgdXNlIG9mIFRMVnMgaW4NCj4gICAgdW5kZXNpcmFibGUuDQo+IA0KPiBUaGUgd2hvbGUg cGFyYWdyYXBoIHNlZW1zIHRhbGtpbmcgZ2VuZXJhbGx5IGFib3V0IFRMVnMgZm9yIEctQUNoIG1l c3NhZ2VzLA0KPiBub3Qgc3BlY2lmaWNhbGx5IGFuIEFDSCBUTFYuIFRoaXMgbWlnaHQgbm90IGJl IHNvIGFjY3VyYXRlIHNpbmNlIHdlIGhhdmUgc29tZQ0KRy0NCj4gQUNoIGNoYW5uZWwgdHlwZSB1 c2luZyBUTFZzIGluIGl0cyBtZXNzYWdlLCBlLmcuIFJGQyA2NDI4IGRlZmluZXMgYSBzb3VyY2UN Ck1FUC0NCj4gSUQgVExWIGZvciB0aGUgTVBMUy1UUCBDViB0eXBlIHdoaWNoIGFsc28gcmVxdWly ZXMgaGFyZHdhcmUgcHJvY2Vzc2luZy4gSQ0KdGhpbmsNCj4gaXQgbWlnaHQgYmUgYmV0dGVyIHRv IHNpbXBseSBzYXkgQUNIIFRMViBpcyBub3QgdXNlZCBhbmQgbWF5IGNhdXNlIGFkZGl0aW9uYWwN Cj4gcHJvY2Vzc2luZyB3aGljaCBpcyBub3QgZGVzaXJhYmxlLiBPciBzb21lIGJldHRlciB3b3Jk aW5nLi4uDQo+IA0KPiBUaGFua3MhDQo+IA0KPiANCj4gQi5SLg0KPiBKaWENCj4gDQo+IA0KPiAt LS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8/sjLOiBMb2EgQW5kZXJzc29uIFttYWlsdG86bG9hQHBp Lm51XQ0KPiC3osvNyrG85DogMjAxM8TqNdTCOMjVIDE2OjAxDQo+IMrVvP7IyzogTGl6aG9uZyBK aW47IEhlamlhIChKaWEpOyBHcmVnb3J5IE1pcnNreTsgRXJpYyBPc2Jvcm5lIChlb3Nib3JuZSk7 DQpNYXJ0aW4NCj4gVmlnb3VyZXV4DQo+ILOty806IGRyYWZ0LWZhcmJyeWFudHJlbC1tcGxzLXJl dGlyZS1hY2gtdGx2QHRvb2xzLmlldGYub3JnOyBtcGxzLQ0KPiBjaGFpcnNAdG9vbHMuaWV0Zi5v cmcNCj4g1vfM4jogTVBMUy1SVCByZXZpZXcgb2YgZHJhZnQtZmFyYnJ5YW50cmVsLW1wbHMtcmV0 aXJlLWFjaC10bHYNCj4gDQo+IEppYSwgTGl6aG9uZywgR3JlZyBhbmQgRXJpYywNCj4gDQo+IFlv dSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgYW4gTVBMUyBSZXZpZXcgdGVhbSByZXZpZXdlcnMgZm9y DQo+IGRyYWZ0LWZhcmJyeWFudHJlbC1tcGxzLXJldGlyZS1hY2gtdGx2LTAwLg0KPiANCj4gTm90 ZSB0byBhdXRob3JzOiBZb3UgaGF2ZSBiZWVuIENDJ2Qgb24gdGhpcyBlbWFpbCBzbyB0aGF0IHlv dSBjYW4ga25vdw0KPiB0aGF0IHRoaXMgcmV2aWV3IGlzIGdvaW5nIG9uLiBIb3dldmVyLCBwbGVh c2UgZG8gbm90IHJldmlldyB5b3VyIG93bg0KPiBkb2N1bWVudC4NCj4gDQo+IFJldmlld3Mgc2hv dWxkIGNvbW1lbnQgb24gd2hldGhlciB0aGUgZG9jdW1lbnQgaXMgY29oZXJlbnQsIGlzIGl0DQo+ IHVzZWZ1bCAoaWUsIGlzIGl0IGxpa2VseSB0byBiZSBhY3R1YWxseSB1c2VmdWwgaW4gb3BlcmF0 aW9uYWwNCj4gbmV0d29ya3MpLCBhbmQgaXMgdGhlIGRvY3VtZW50IHRlY2huaWNhbGx5IHNvdW5k PyAgV2UgYXJlIGludGVyZXN0ZWQNCj4gaW4ga25vd2luZyB3aGV0aGVyIHRoZSBkb2N1bWVudCBp cyByZWFkeSB0byBiZSBjb25zaWRlcmVkIGZvciBXRw0KPiBhZG9wdGlvbiAoaWUsIGl0IGRvZXNu J3QgaGF2ZSB0byBiZSBwZXJmZWN0IGF0IHRoaXMgcG9pbnQsIGJ1dCBzaG91bGQgYmUNCj4gYSBn b29kIHN0YXJ0KS4NCj4gDQo+IFJldmlld3Mgc2hvdWxkIGJlIHNlbnQgdG8gdGhlIGRvY3VtZW50 IGF1dGhvcnMsIFdHIGNvLWNoYWlycyBhbmQNCj4gV0cgc2VjcmV0YXJ5LCBhbmQgQ0MnZCB0byB0 aGUgTVBMUyBXRyBlbWFpbCBsaXN0LiBJZiBuZWNlc3NhcnksIGNvbW1lbnRzDQo+IG1heSBiZSBz ZW50IHByaXZhdGVseSB0byBvbmx5IHRoZSBXRyBjaGFpcnMuDQo+IA0KPiBBcmUgeW91IGFibGUg dG8gcmV2aWV3IHRoaXMgZHJhZnQgYnkgTWF0IDI0LCAyMDEzPw0KPiANCj4gVGhhbmtzLCBMb2EN Cj4gKGFzIE1QTFMgV0cgY2hhaXIpDQo+IC0tDQo+IA0KPiANCj4gTG9hIEFuZGVyc3NvbiAgICAg ICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5jb20NCj4gU2VuaW9y IE1QTFMgRXhwZXJ0ICAgICAgICAgICAgICAgICAgICAgICAgICBsb2FAcGkubnUNCj4gSHVhd2Vp IFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQoN Cg== From adrian@olddog.co.uk Fri May 24 05:47:45 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D30E21F9012 for ; Fri, 24 May 2013 05:47:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.971 X-Spam-Level: X-Spam-Status: No, score=-0.971 tagged_above=-999 required=5 tests=[AWL=-1.161, BAYES_00=-2.599, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6QPx49oIzDGK for ; Fri, 24 May 2013 05:47:39 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 638C821F8E8F for ; Fri, 24 May 2013 05:47:39 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4OClTXA017013; Fri, 24 May 2013 13:47:29 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4OClQJn016991 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 May 2013 13:47:26 +0100 From: "Adrian Farrel" To: "'Hejia \(Jia\)'" , "'Loa Andersson'" , "'Martin Vigoureux'" , , References: <518A064C.7090006@pi.nu> <735916399E11684EAF4EB4FB376B71952C6CCBDA@SZXEML505-MBX.china.huawei.com> <040501ce57af$1d2f8570$578e9050$@olddog.co.uk> <735916399E11684EAF4EB4FB376B71952C6CCF9A@SZXEML505-MBX.china.huawei.com> In-Reply-To: <735916399E11684EAF4EB4FB376B71952C6CCF9A@SZXEML505-MBX.china.huawei.com> Date: Fri, 24 May 2013 13:47:22 +0100 Message-ID: <05e901ce587c$d95cf520$8c16df60$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEA85wkIqTcvalMAOBxYkCEqrMtWQIYPP8LAbZBcX0Co20WUZp7gnnQ Content-Language: en-gb Cc: mpls@ietf.org Subject: Re: [mpls] MPLS-RT review of draft-farbryantrel-mpls-retire-ach-tlv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 12:47:45 -0000 Got it, thanks. Stored for next revision. A > -----Original Message----- > From: Hejia (Jia) [mailto:hejia@huawei.com] > Sent: 24 May 2013 11:57 > To: adrian@olddog.co.uk; 'Loa Andersson'; 'Martin Vigoureux'; draft-farbryantrel- > mpls-retire-ach-tlv@tools.ietf.org; mpls-chairs@tools.ietf.org > Cc: mpls@ietf.org > Subject: Re: MPLS-RT review of draft-farbryantrel-mpls-retire-ach-tlv >=20 > Adrian, >=20 > Thanks for your prompt response. You are so quick. I noticed you have = already > uploaded another WG version when I got time to read emails today:-) > If possible, I guess the last sentence of the second paragraph can be = more > precise by adding "ACH" before "TLVs" which reads >=20 > " the use of ACH TLVs is undesirable." (typo: s/in/is) >=20 > This will help to remove the impact to other TLVs used in G-ACh = messages but > not in the ACH. >=20 > Thanks! >=20 >=20 > B.R. > Jia >=20 >=20 >=20 > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > =B7=A2=BC=FE=C8=CB: Adrian Farrel [mailto:adrian@olddog.co.uk] > =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA5=D4=C223=C8=D5 20:15 > =CA=D5=BC=FE=C8=CB: Hejia (Jia); 'Loa Andersson'; 'Martin Vigoureux'; draft-farbryantrel-mpls- > retire-ach-tlv@tools.ietf.org; mpls-chairs@tools.ietf.org > =B3=AD=CB=CD: mpls@ietf.org > =D6=F7=CC=E2: RE: MPLS-RT review of = draft-farbryantrel-mpls-retire-ach-tlv >=20 > Thanks Jia, >=20 > Your point is well taken and the Abstract in the working copy (ready = to post) > now reads... >=20 > The MPLS Generic Associated Channel (G-ACh) is a generalization of > the applicability of the Pseudowire (PW) Associated Channel Header > (ACH). RFC 5586 defines the concept of TLV constructs that can be > carried in messages on the G-ACh by placing them in the ACH between > the fixed header fields and the G-ACh message. These TLVs are = called > ACH TLVs >=20 > No Associated Channel Type yet defined uses an ACH TLV. = Furthermore, > it is believed that handling TLVs in hardware introduces = significant > problems to the fast-path, and since G-ACh messages are intended to > be processed substantially in hardware, the use of TLVs in > undesirable. >=20 > This document updates RFC 5586 by retiring ACH TLVs and removing = the > associated registry. >=20 > Cheers, > Adrian >=20 > > -----Original Message----- > > From: Hejia (Jia) [mailto:hejia@huawei.com] > > Sent: 23 May 2013 12:52 > > To: Loa Andersson; Martin Vigoureux; = draft-farbryantrel-mpls-retire-ach- > > tlv@tools.ietf.org; mpls-chairs@tools.ietf.org > > Cc: mpls@ietf.org > > Subject: Re: MPLS-RT review of = draft-farbryantrel-mpls-retire-ach-tlv > > > > Hi, > > > > I noticed a 01 version of draft-farbryantrel-mpls-retire-ach-tlv is available. > So I > > based my MPLS RT review on that version. I think the document is = coherent, > > useful, technically sound and ready to be adopted as a WG draft. = Just one > > comment: > > > > 1) In the Abstract part, it is written as > > > > No Associated Channel Type yet defined uses a TLV. Furthermore, = it > > is believed that handling TLVs in hardware introduces significant > > problems to the fast-path, and since G-ACh messages are intended = to > > be processed substantially in hardware, the use of TLVs in > > undesirable. > > > > The whole paragraph seems talking generally about TLVs for G-ACh = messages, > > not specifically an ACH TLV. This might not be so accurate since we = have some > G- > > ACh channel type using TLVs in its message, e.g. RFC 6428 defines a = source > MEP- > > ID TLV for the MPLS-TP CV type which also requires hardware = processing. I > think > > it might be better to simply say ACH TLV is not used and may cause additional > > processing which is not desirable. Or some better wording... > > > > Thanks! > > > > > > B.R. > > Jia > > > > > > -----=D3=CA=BC=FE=D4=AD=BC=FE----- > > =B7=A2=BC=FE=C8=CB: Loa Andersson [mailto:loa@pi.nu] > > =B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA5=D4=C28=C8=D5 16:01 > > =CA=D5=BC=FE=C8=CB: Lizhong Jin; Hejia (Jia); Gregory Mirsky; Eric = Osborne (eosborne); > Martin > > Vigoureux > > =B3=AD=CB=CD: draft-farbryantrel-mpls-retire-ach-tlv@tools.ietf.org; = mpls- > > chairs@tools.ietf.org > > =D6=F7=CC=E2: MPLS-RT review of = draft-farbryantrel-mpls-retire-ach-tlv > > > > Jia, Lizhong, Greg and Eric, > > > > You have been selected as an MPLS Review team reviewers for > > draft-farbryantrel-mpls-retire-ach-tlv-00. > > > > Note to authors: You have been CC'd on this email so that you can = know > > that this review is going on. However, please do not review your own > > document. > > > > Reviews should comment on whether the document is coherent, is it > > useful (ie, is it likely to be actually useful in operational > > networks), and is the document technically sound? We are interested > > in knowing whether the document is ready to be considered for WG > > adoption (ie, it doesn't have to be perfect at this point, but = should be > > a good start). > > > > Reviews should be sent to the document authors, WG co-chairs and > > WG secretary, and CC'd to the MPLS WG email list. If necessary, = comments > > may be sent privately to only the WG chairs. > > > > Are you able to review this draft by Mat 24, 2013? > > > > Thanks, Loa > > (as MPLS WG chair) > > -- > > > > > > Loa Andersson email: loa@mail01.huawei.com > > Senior MPLS Expert loa@pi.nu > > Huawei Technologies (consultant) phone: +46 739 81 21 64 From francesco.fondelli@gmail.com Fri May 24 11:09:39 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEC4321E8055 for ; Fri, 24 May 2013 11:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAEgDb2yfS8B for ; Fri, 24 May 2013 11:09:35 -0700 (PDT) Received: from mail-lb0-f173.google.com (mail-lb0-f173.google.com [209.85.217.173]) by ietfa.amsl.com (Postfix) with ESMTP id 130EF21E804E for ; Fri, 24 May 2013 11:09:31 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id t10so5006523lbi.18 for ; Fri, 24 May 2013 11:09:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=s9z+ulpzw5u9ySIj2RZUE90EU22qqQGAqrzaTnt2yH4=; b=VUaQgRiMEvXCMcl1gn+sSFkzyEqjVpGN3wuz1xIkGSUPke/gz+xscNvba56UC0FrqF bddQtXXK4gB83j3lAWW0efIOc69LbsLtX20QEBPEzVQJToKbVsOnE8qPrlIhlGvC7maE BAlZXP4m/5ElFJ8QeRG+EJa8+OlbMnqnyuc5h5QEROk7riWShz0UJeVV7jRBeoQhFqH6 VLqJBiIZbCIyzh0a0HomTmntXfBNOw2caTST8GJOVwnW42KY4OJzcXgLCdcSEr6pGlUF Ye6uX+8oGkom0JYC3pHEygMIQNUbxvhZ2ttDqUWO3z6jBqV9U/CXRjV66qSopCHEX8nS lf2g== MIME-Version: 1.0 X-Received: by 10.152.26.225 with SMTP id o1mr9554001lag.43.1369418963173; Fri, 24 May 2013 11:09:23 -0700 (PDT) Received: by 10.114.183.114 with HTTP; Fri, 24 May 2013 11:09:23 -0700 (PDT) In-Reply-To: References: Date: Fri, 24 May 2013 20:09:23 +0200 Message-ID: From: Francesco Fondelli To: "Will Liu (Shucheng)" Content-Type: text/plain; charset=UTF-8 Cc: "mpls@ietf.org" Subject: Re: [mpls] FW: New Version Notification for draft-manral-mpls-rfc3811bis-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 18:09:39 -0000 Hi Will, all, I have always thought MplsLSPID description in 3811 was misleading (or inconsistent): "A unique identifier within an MPLS network that is assigned to each LSP...". For LDP this is 6 bytes 'IP addr + local ID' and can be used as a network-unique handle. However, for LSPs signaled using RSVP-TE, RFC3811 suggests to use the LSP_ID (2 byte) used in the SENDER_TEMPLATE obj. This is just a local number (it is unique within the scope of the SESSION) so it cannot be used to uniquely identify an LSP on a network. Can we also "fix" this in 3811bis ? We can simply state (in the MplsLSPID description) that for LSPs signaled using RSVP-TE this is just a local number. Alternatively, we can make room (now is max 6 octets) for full network level LSP identification: 5-tuple { Destination Address, Tunnel_ID, Extended Tunnel ID, Sender Address, LSP_ID }. thank you ciao fra On Wed, May 22, 2013 at 5:02 AM, Will Liu (Shucheng) wrote: > Folks, > > We updated the draft by modifying the introduction, typos in section 5, and adding a section highlighting the changes on rfc3811. > > Your review and comments are highly appreciated. > > Regards, > Will > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Wednesday, May 22, 2013 3:30 AM > To: Tina TSOU; Will Liu (Shucheng); Vishwas Manral; Will Liu (Shucheng) > Subject: New Version Notification for draft-manral-mpls-rfc3811bis-02.txt > > > A new version of I-D, draft-manral-mpls-rfc3811bis-02.txt > has been successfully submitted by Vishwas Manral and posted to the > IETF repository. > > Filename: draft-manral-mpls-rfc3811bis > Revision: 02 > Title: Definitions of Textual Conventions (TCs) for Multiprotocol Label Switching (MPLS) Management > Creation date: 2013-05-20 > Group: Individual Submission > Number of pages: 22 > URL: http://www.ietf.org/internet-drafts/draft-manral-mpls-rfc3811bis-02.txt > Status: http://datatracker.ietf.org/doc/draft-manral-mpls-rfc3811bis > Htmlized: http://tools.ietf.org/html/draft-manral-mpls-rfc3811bis-02 > Diff: http://www.ietf.org/rfcdiff?url2=draft-manral-mpls-rfc3811bis-02 > > Abstract: > This memo defines a Management Information Base (MIB) module which > contains Textual Conventions to represent commonly used Multiprotocol > Label Switching (MPLS) management information. The intent is that > these TEXTUAL CONVENTIONS (TCs) will be imported and used in MPLS > related MIB modules that would otherwise define their own > representations. > > This document obsoletes RFC3811 as it addresses the need to support > IPv6 extended TunnelID's by defining a new TC- > MplsNewExtendedTunnelID which suggests using IPv4 address of the > ingress or egress LSR for the tunnel for an IPv6 network. Changes > from RFC3811 and the effect of the new TC to other related documents > are summarized in Section 4 and 5, respectively. > > > > > The IETF Secretariat > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From kireeti.kompella@gmail.com Fri May 24 15:00:31 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 459DF21E808B for ; Fri, 24 May 2013 15:00: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=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXC9Oj+4+z-9 for ; Fri, 24 May 2013 15:00:30 -0700 (PDT) Received: from mail-vb0-x229.google.com (mail-vb0-x229.google.com [IPv6:2607:f8b0:400c:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA0721E8087 for ; Fri, 24 May 2013 15:00:30 -0700 (PDT) Received: by mail-vb0-f41.google.com with SMTP id p14so3423708vbm.14 for ; Fri, 24 May 2013 15:00:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=7Jmw3ExuF1E+RzTYhr9HOTMTMUJj7m9mp3vMgYiWbEg=; b=wOT3HLwij159gK3NHxorRFJ18w/JcYyieuXFGxt1J4tI+CIz70P2GqKRcO67ZhPNGr UvYmoM6FPftGDrB2R+umqibIriIP2X9Phj0NhBYHYB5/YOKxQ9v2LKy5AsQzoqIvVBGS iSn2rNmGejBUOrUH/tsfTdHoVGqqLd8gl5FJ+5Om0iK389GxwPq504ZvRU+j/0UlQW9A fd80FxAfPBhyPpGJXKZFExQJO5/hIE1mpTAuBRvwZv1hn+HfUC7IDPGos2Tff6FKhVRf dchZTM9qZWkjlkcMnTLSwit9JNfnu8Sv2ib35cRhfemekihyeREJNUlAAD9iOv2EjKYv ctGg== X-Received: by 10.58.189.197 with SMTP id gk5mr9687637vec.57.1369432829524; Fri, 24 May 2013 15:00:29 -0700 (PDT) Received: from [172.28.130.4] (westford-nat.juniper.net. [66.129.232.2]) by mx.google.com with ESMTPSA id tf2sm10506001veb.8.2013.05.24.15.00.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 24 May 2013 15:00:28 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Kireeti Kompella In-Reply-To: <10026.1363629922@erosen-linux> Date: Fri, 24 May 2013 15:00:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <37E234C8-8167-4375-8EE2-693E3041140A@gmail.com> References: <10026.1363629922@erosen-linux> To: erosen@cisco.com X-Mailer: Apple Mail (2.1503) Cc: MPLS Subject: Re: [mpls] comments on draft-kompella-mpls-special-purpose-labels-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 May 2013 22:00:31 -0000 Hi Eric, On Mar 18, 2013, at 11:05 , Eric Rosen wrote: > A few comments: >=20 > - The extended special purpose label space has about a million = possible > values (16 - 1048559), with an allocation policy of "standards = action". > This encourages squatting on "unofficial" codepoints while = discouraging > the publication of non-standards-track drafts describing the use of = those > codepoints. >=20 > I think it would be better to have a much smaller piece of the label = space > to be allocated under the "standards action" policy. Okay, will reduce. Question is, what to do with the rest of the label = space: make reserved, or FCFS (or both)? If FCFS, how big? > - With a large extended special purpose label space, why do we need a > process for reusing deprecated (non-extended) special purpose label > values? Especially when we already know that "IETF-wide surveys" = don't > necessarily determine correctly whether some feature is actually in = use > somewhere. Added the following. (See below too.) 3.2. Process for Retiring Special Purpose Labels While the following process is defined for the sake of completeness, note that retiring special purpose labels is difficult. It is recommended that this process be used sparingly. a. A label value that has been assigned from the "Special Purpose MPLS Label Values" may be deprecated by IETF consensus with (etc.) > - "an arbitrary string of consecutive extension labels is legal, and > semantically equivalent to a single extension label" Gone. > I don't see the sense of this. It will only lead to interoperability > issues when some implementation puts in lots of extraneous labels and = some > other implementation can't handle it properly (as mentioned in the > Security Considerations). >=20 > - Section 3, point 4, on the possible use of codepoint 3, doesn't seem = to > make any change to existing process or usage. I'm not sure why it is = even > in the document. Will remove. Both deprecation above and using 3 in the data plane were = in response to a comment that non-extended special purpose labels were a = precious commodity, even with the extended space (packet processing = cycles, etc.). > - The fact that every special purpose label has a corresponding = extended > special purpose label seems problematic to me. Suppose some > implementation decides that when it needs to push "IPv4 explicit = null" on > a packet, it is always going to use the extended special purpose = label. > This seems perfectly legal, but will not interoperate with other > implementations that understand "IPv4 explicit null" but that don't > support the extended special purpose label space. Reworded thus: For now, the use of the "implicit null label" (label 3) in the data plane will not be allowed. If this decision is revisited later, an accompanying Standards Track RFC that details the use of the label, a discussion of possible sources of confusion between signaling and data plane, and mitigation thereof. and Values 0-6 and 8-15 of the extended special purpose label registry are set aside as reserved; these MUST NOT appear in the data plane. Label 7 (when received) retains its meaning = as ELI whether a regular or an extended special purpose label; however, an implementation SHOULD NOT insert a label of 7 as an extended special purpose label, preferring instead to send 7 as a regular special purpose label. > - =46rom section 3.1: >=20 > An extension label MUST be followed by another label L (and thus > MUST have the bottom-of-stack bit clear). L MUST be interpreted > as an "extended special purpose label" from a new registry > created by this document (see Section 5). Whether or not L has > the bottom-of-stack bit set depends on whether other labels > follow L. Only L is interpreted as an extended special purpose > label; labels following L are interpreted as normal. >=20 > If all labels following a special purpose label "are interpreted as > normal", it follows that there can only be one special purpose label = in > the stack. I don't think that's the intention. >=20 > Probably the final sentence should be "an extension label only = affects the > interpretation of the label immediately below it". That was the intent. Reworded thus: An extension label MUST be followed by another label L (and thus MUST have the bottom-of-stack bit clear). L MUST be interpreted as an "extended special purpose label" and interpreted as defined in a new registry created by this document (see ). Whether or not L has the bottom-of-stack bit set depends on whether other labels follow L. The extension label only assigns special meaning to L. A label after L (if any) is parsed as usual, and thus may be a regular label, a special purpose label or (if prefixed by another extension label) an extended special purpose label. Kireeti. >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From loa@pi.nu Sat May 25 10:42:28 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED5D21F8895 for ; Sat, 25 May 2013 10:42:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.952 X-Spam-Level: X-Spam-Status: No, score=-99.952 tagged_above=-999 required=5 tests=[AWL=-1.204, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, MANGLED_PAIN=2.3, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1YxndaklO1kT for ; Sat, 25 May 2013 10:42:22 -0700 (PDT) Received: from pipi.pi.nu (unknown [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 803A721F8709 for ; Sat, 25 May 2013 10:42:20 -0700 (PDT) Received: from [192.168.1.130] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 469821800272; Sat, 25 May 2013 19:42:19 +0200 (CEST) Message-ID: <51A0F7FB.2040706@pi.nu> Date: Sat, 25 May 2013 19:42:19 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "mpls@ietf.org" , Adrian Farrel , draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp@tools.ietf.org, "VIGOUREUX, MARTIN (MARTIN)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] status and paln for draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 May 2013 17:42:28 -0000 Working Group, On 2013-05-20 we requested publication of draft-ietf-mpls-inter-domain- p2mp-rsvp-te-lsp as an RFC on the Standards Draft. After a timely and detailed AD review the document has been "returned to the working group for more work". The AD review comments has been has been sent to the working group mailing list and to the authors. The comments are comprehensive, nevertheless the author should proceed as usual: - Create a list of the comments and for each comment explain how each comment has been addressed and verify that Adrian is comfortable about how the comments have been address. This process should to the extent possible take place on the mailing list. After further discussion with Adrian we have agreed that I as the document shepherd should organize a review by "P2MP implementers". - The comments received via this review should be handle the same way as the comments from the AD review. I've a few names that I think fit the "P2MP implementer" profile, and will soon send out mails directly to them. I'm also looking for more willing reviewers that are willing to undertake this review. If you are interested please send a uni-directional mail to me or to the working group chairs. /Loa for the MPLS wg co-chairs -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From Frederic.Jounay@orange.ch Mon May 27 00:46:51 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC83B21F9350 for ; Mon, 27 May 2013 00:46:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMsGioMtigCD for ; Mon, 27 May 2013 00:46:46 -0700 (PDT) Received: from smtp10.eds.ch (smtp10.eds.ch [195.160.148.39]) by ietfa.amsl.com (Postfix) with ESMTP id EA0F521F9260 for ; Mon, 27 May 2013 00:46:45 -0700 (PDT) X-AuditID: c3a09427-b7f4c6d000002b80-8d-51a30f4cd4ec Received: from chcrochs054.orange.ch (Unknown_Domain [204.104.149.84]) (using TLS with cipher RC4-MD5 (RC4-MD5/128 bits)) (Client did not present a certificate) by smtp10.eds.ch () with SMTP id 75.74.11136.C4F03A15; Mon, 27 May 2013 09:46:20 +0200 (CEST) Received: from CHCROCHC051.orange.ch ([fe80:0000:0000:0000:704b:3a68:12.14.247.83]) by chcrochs054.orange.ch ([172.19.166.54]) with mapi; Mon, 27 May 2013 09:46:20 +0200 From: =?utf-8?B?Sm91bmF5IEZyw6lkw6lyaWM=?= To: "Loa Andersson (loa@pi.nu)" , "mpls@ietf.org" Date: Mon, 27 May 2013 09:46:19 +0200 Thread-Topic: [mpls] poll to see if we have consensus to make draft-jjb-mpls-rsvp-te-hsmp-lsp an MPLS wg document Thread-Index: Ac5arfogzhY/QZDMT2OhZfmrV8bi2gAABgOg Message-ID: <78046FD1C8FE0345AFBC11640A8DF6E20181D490ED82@CHCROCHC051.orange.ch> References: <51951C17.8010906@pi.nu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_78046FD1C8FE0345AFBC11640A8DF6E20181D490ED82CHCROCHC051_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCIsWRmVeSWpSXmKPExsVyJmNqiG4y/+JAgw93OC0+HZnKbvFv7hxm i++XlrBY3Fq6ktWBxWPJkp9MHrOmt7F5fLn8mS2AOYrLJiU1J7MstUjfLoErY/P0fqaCXwEV a57FNTDe8eti5OSQEDCRWLt9CxuELSZx4d56MFtIoIVJouNyRhcjF5C9llHibdNFJpAEm4Cb xJpLk8GKRAR8JG58/soOUsQssIRRYu+GDawgCRYBVYmuu3uBEhwcwgJFEjcXJkLUF0usv3aX FcI2kpj44C4TSAmvQIDE2teaEHuzJV7N3QNWwikQKDF5Zw+YzQh02/dTa8BOYBYQl7j1ZD4T xM0CEkv2nGeGsEUlXj7+B1UvKnGnfT0jRH2+xLTZ18HivAKCEidnPmGZwCg6C8moWUjKZiEp mwV0HbOApsT6XfoQJYoSU7ofskPYGhKtc+ayI4svYGRfxchbnFtSYGigl5pSrJecsYkRGHeH F0xR38E4/YL5IUYBDkYlHt6fsxYFCrEmlhVX5h5ilOBgVhLhTYgGCvGmJFZWpRblxxeV5qQW H2KU5mBREufl8pgfKCSQnliSmp2aWpBaBJNl4uCUamD0yVvNsGjyqql7/n1/xVDL7ar3aq9C 6JEJ9XE1Cpd29Edd17BfJS06ZaenyoofWy74zu2Ydyy8kk1fI+9IewB/4oEdG973+qa9cq6K u/JqjbZR0LENq4ryCru8Pm2X/yP74PLd2lmR6yTXyDR6bNq94oPFy3LHh1cq9gYrBq0/L5Mk 8qt4b+FSJZbijERDLeai4kQAHqj2lbcCAAA= Cc: "draft-jjb-mpls-rsvp-te-hsmp-lsp@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: [mpls] FW: poll to see if we have consensus to make draft-jjb-mpls-rsvp-te-hsmp-lsp an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 07:46:52 -0000 --_000_78046FD1C8FE0345AFBC11640A8DF6E20181D490ED82CHCROCHC051_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkNClN1cHBvcnQgKGFzIGNvLWF1dGhvcikNCkZyZWQNCi0tLS0tLS0tLS0gRm9yd2FyZGVkIG1l c3NhZ2UgLS0tLS0tLS0tLQ0KRnJvbTogTG9hIEFuZGVyc3NvbiA8bG9hQHBpLm51PG1haWx0bzps b2FAcGkubnU+Pg0KRGF0ZTogVGh1LCBNYXkgMTYsIDIwMTMgYXQgMTA6NDkgQU0NClN1YmplY3Q6 IFttcGxzXSBwb2xsIHRvIHNlZSBpZiB3ZSBoYXZlIGNvbnNlbnN1cyB0byBtYWtlIGRyYWZ0LWpq Yi1tcGxzLXJzdnAtdGUtaHNtcC1sc3AgYW4gTVBMUyB3ZyBkb2N1bWVudA0KVG86ICJtcGxzQGll dGYub3JnPG1haWx0bzptcGxzQGlldGYub3JnPiIgPG1wbHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNA aWV0Zi5vcmc+Pg0KQ2M6ICJkcmFmdC1qamItbXBscy1yc3ZwLXRlLWhzbXAtbHNwQHRvb2xzLmll dGYub3JnPG1haWx0bzpkcmFmdC1qamItbXBscy1yc3ZwLXRlLWhzbXAtbHNwQHRvb2xzLmlldGYu b3JnPiIgPGRyYWZ0LWpqYi1tcGxzLXJzdnAtdGUtaHNtcC1sc3BAdG9vbHMuaWV0Zi5vcmc8bWFp bHRvOmRyYWZ0LWpqYi1tcGxzLXJzdnAtdGUtaHNtcC1sc3BAdG9vbHMuaWV0Zi5vcmc+PiwgIm1w bHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPG1haWx0bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9y Zz4iIDxtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZzxtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMu aWV0Zi5vcmc+Pg0KDQoNCldvcmtpbmcgR3JvdXAsDQoNClRoaXMgaXMgdG8gc3RhcnQgYSB0d28g d2VlayBwb2xsIG9uIGFkb3B0aW5nDQpkcmFmdC1qamItbXBscy1yc3ZwLXRlLWhzbXAtbHNwLTA0 IGFzIGFuIE1QTFMgd29ya2luZw0KZ3JvdXAgZG9jdW1lbnQuDQoNClBsZWFzZSBzZW5kIHlvdXIg Y29tbWVudHMgKHN1cHBvcnQvbm90IHN1cHBvcnQpIHRvIHRoZSBtcGxzIHdvcmtpbmcNCmdyb3Vw IG1haWxpbmcgbGlzdCAobXBsc0BpZXRmLm9yZzxtYWlsdG86bXBsc0BpZXRmLm9yZz4pLiBQbGVh c2UgZ2l2ZSBhIHRlY2huaWNhbA0KbW90aXZhdGlvbiBmb3IgeW91ciBzdXBwb3J0L25vdCBzdXBw b3J0LCBlc3BlY2lhbGx5IGlmIHlvdSB0aGluayB0aGF0DQp0aGUgZG9jdW1lbnQgc2hvdWxkIG5v dCBiZSBhZG9wdGVkIGFzIGEgd29ya2luZyBncm91cCBkb2N1bWVudC4NCg0KVGhpcyBwb2xsIGVu ZHMgTWF5IDMxLCAyMDEzLg0KDQpUaGVyZSBhcmUgb25lIElQUiBjbGFpbSBhZ2FpbnN0IHRoaXMg ZG9jdW1lbnQsIHNlZSBJUFIgY2xhaW0gIzE4NDAuDQoNClRoZSBhdXRob3JzIGhhcyBzdGF0ZWQg b24gdGhlIHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQp0aGF0IHRoZXkgYXJlIG5vdCBhd2Fy ZSBvZiBhbnkgb3RoZXIgSVBSIGNsYWltcyBhZ2FpbnN0IHRoaXMgZHJhZnQuDQpIb3dldmVyIGlm IHlvdSBhcmUgb24gdGhlIHRoZSBtcGxzIHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0IGFuZA0K YXdhcmUgb2YgSVBSIHRoYXQgcmVsYXRlcyB0byB0aGlzIGRyYWZ0LCB0aGUgdGltZSB0byBkaXNj bG9zZQ0KdGhpcyBpcyBub3cuDQoNCi9Mb2ENCihtcGxzIHdnIGNvLWNoYWlyKQ0KLS0NCg0KDQpM b2EgQW5kZXJzc29uICAgICAgICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYUBtYWlsMDEuaHVh d2VpLmNvbTxtYWlsdG86bG9hQG1haWwwMS5odWF3ZWkuY29tPg0KU2VuaW9yIE1QTFMgRXhwZXJ0 ICAgICAgICAgICAgICAgICAgICAgICAgICBsb2FAcGkubnU8bWFpbHRvOmxvYUBwaS5udT4NCkh1 YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRhbnQpICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2 NDx0ZWw6JTJCNDYlMjA3MzklMjA4MSUyMDIxJTIwNjQ+DQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KbXBscyBtYWlsaW5nIGxpc3QNCm1wbHNAaWV0Zi5v cmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL21wbHMNCg0K --_000_78046FD1C8FE0345AFBC11640A8DF6E20181D490ED82CHCROCHC051_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNv QWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxv b24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNw YW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs InNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9t YSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLUdCO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIu MHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9RU4tR0IgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2 IGNsYXNzPVdvcmRTZWN0aW9uMT48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2lu LWJvdHRvbToxMi4wcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SGk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjtjb2xvcjojMUY0OTdEJz5TdXBwb3J0IChhcyBjby1hdXRob3IpPG86cD48L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxz cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7Y29sb3I6IzFGNDk3RCc+RnJlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwIGNs YXNzPU1zb05vcm1hbD4tLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdlIC0tLS0tLS0tLS08YnI+ RnJvbTogPGI+TG9hIEFuZGVyc3NvbjwvYj4gJmx0OzxhIGhyZWY9Im1haWx0bzpsb2FAcGkubnUi PmxvYUBwaS5udTwvYT4mZ3Q7PGJyPkRhdGU6IFRodSwgTWF5IDE2LCAyMDEzIGF0IDEwOjQ5IEFN PGJyPlN1YmplY3Q6IFttcGxzXSBwb2xsIHRvIHNlZSBpZiB3ZSBoYXZlIGNvbnNlbnN1cyB0byBt YWtlIGRyYWZ0LWpqYi1tcGxzLXJzdnAtdGUtaHNtcC1sc3AgYW4gTVBMUyB3ZyBkb2N1bWVudDxi cj5UbzogJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciPm1wbHNAaWV0Zi5vcmc8 L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bXBsc0BpZXRmLm9yZyI+bXBsc0BpZXRmLm9y ZzwvYT4mZ3Q7PGJyPkNjOiAmcXVvdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtampiLW1wbHMtcnN2 cC10ZS1oc21wLWxzcEB0b29scy5pZXRmLm9yZyI+ZHJhZnQtampiLW1wbHMtcnN2cC10ZS1oc21w LWxzcEB0b29scy5pZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1q amItbXBscy1yc3ZwLXRlLWhzbXAtbHNwQHRvb2xzLmlldGYub3JnIj5kcmFmdC1qamItbXBscy1y c3ZwLXRlLWhzbXAtbHNwQHRvb2xzLmlldGYub3JnPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1h aWx0bzptcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZyI+bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5v cmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5v cmciPm1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnPC9hPiZndDs8YnI+PGJyPjxicj5Xb3JraW5n IEdyb3VwLDxicj48YnI+VGhpcyBpcyB0byBzdGFydCBhIHR3byB3ZWVrIHBvbGwgb24gYWRvcHRp bmc8YnI+ZHJhZnQtampiLW1wbHMtcnN2cC10ZS1oc21wLWxzcC0wNCBhcyBhbiBNUExTIHdvcmtp bmc8YnI+Z3JvdXAgZG9jdW1lbnQuPGJyPjxicj5QbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIChz dXBwb3J0L25vdCBzdXBwb3J0KSB0byB0aGUgbXBscyB3b3JraW5nPGJyPmdyb3VwIG1haWxpbmcg bGlzdCAoPGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5tcGxz QGlldGYub3JnPC9hPikuIFBsZWFzZSBnaXZlIGEgdGVjaG5pY2FsPGJyPm1vdGl2YXRpb24gZm9y IHlvdXIgc3VwcG9ydC9ub3Qgc3VwcG9ydCwgZXNwZWNpYWxseSBpZiB5b3UgdGhpbmsgdGhhdDxi cj50aGUgZG9jdW1lbnQgc2hvdWxkIG5vdCBiZSBhZG9wdGVkIGFzIGEgd29ya2luZyBncm91cCBk b2N1bWVudC48YnI+PGJyPlRoaXMgcG9sbCBlbmRzIE1heSAzMSwgMjAxMy48YnI+PGJyPlRoZXJl IGFyZSBvbmUgSVBSIGNsYWltIGFnYWluc3QgdGhpcyBkb2N1bWVudCwgc2VlIElQUiBjbGFpbSAj MTg0MC48YnI+PGJyPlRoZSBhdXRob3JzIGhhcyBzdGF0ZWQgb24gdGhlIHdvcmtpbmcgZ3JvdXAg bWFpbGluZyBsaXN0PGJyPnRoYXQgdGhleSBhcmUgbm90IGF3YXJlIG9mIGFueSBvdGhlciBJUFIg Y2xhaW1zIGFnYWluc3QgdGhpcyBkcmFmdC48YnI+SG93ZXZlciBpZiB5b3UgYXJlIG9uIHRoZSB0 aGUgbXBscyB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCBhbmQ8YnI+YXdhcmUgb2YgSVBSIHRo YXQgcmVsYXRlcyB0byB0aGlzIGRyYWZ0LCB0aGUgdGltZSB0byBkaXNjbG9zZTxicj50aGlzIGlz IG5vdy48YnI+PGJyPi9Mb2E8YnI+KG1wbHMgd2cgY28tY2hhaXIpPHNwYW4gc3R5bGU9J2NvbG9y OiM4ODg4ODgnPjxicj48c3BhbiBjbGFzcz1ob2VuemI+LS0gPC9zcGFuPjxicj48YnI+PGJyPjxz cGFuIGNsYXNzPWhvZW56Yj5Mb2EgQW5kZXJzc29uICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ZW1haWw6IDxhIGhyZWY9Im1haWx0bzpsb2FAbWFpbDAxLmh1YXdlaS5jb20iIHRhcmdldD0iX2Js YW5rIj5sb2FAbWFpbDAxLmh1YXdlaS5jb208L2E+PC9zcGFuPjxicj48c3BhbiBjbGFzcz1ob2Vu emI+U2VuaW9yIE1QTFMgRXhwZXJ0ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxh IGhyZWY9Im1haWx0bzpsb2FAcGkubnUiIHRhcmdldD0iX2JsYW5rIj5sb2FAcGkubnU8L2E+PC9z cGFuPjxicj48c3BhbiBjbGFzcz1ob2VuemI+SHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdGFu dCkgJm5ic3A7ICZuYnNwOyBwaG9uZTogPGEgaHJlZj0idGVsOiUyQjQ2JTIwNzM5JTIwODElMjAy MSUyMDY0IiB0YXJnZXQ9Il9ibGFuayI+KzQ2IDczOSA4MSAyMSA2NDwvYT48L3NwYW4+PGJyPjxz cGFuIGNsYXNzPWhvZW56Yj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzwvc3Bhbj48YnI+PHNwYW4gY2xhc3M9aG9lbnpiPm1wbHMgbWFpbGluZyBsaXN0PC9z cGFuPjxicj48c3BhbiBjbGFzcz1ob2VuemI+PGEgaHJlZj0ibWFpbHRvOm1wbHNAaWV0Zi5vcmci IHRhcmdldD0iX2JsYW5rIj5tcGxzQGlldGYub3JnPC9hPjwvc3Bhbj48YnI+PHNwYW4gY2xhc3M9 aG9lbnpiPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBs cyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bXBsczwvYT48L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPjwvZGl2PjxwIGNsYXNzPU1zb05v cm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg== --_000_78046FD1C8FE0345AFBC11640A8DF6E20181D490ED82CHCROCHC051_-- From liushucheng@huawei.com Mon May 27 06:08:53 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1CD721F95E9 for ; Mon, 27 May 2013 06:08:53 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDT6-qvYINhW for ; Mon, 27 May 2013 06:08:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DF73B21F95E5 for ; Mon, 27 May 2013 06:08:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARV48666; Mon, 27 May 2013 13:08:47 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 27 May 2013 14:08:18 +0100 Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 27 May 2013 14:08:43 +0100 Received: from SZXEML546-MBS.china.huawei.com ([169.254.4.131]) by szxeml411-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Mon, 27 May 2013 21:08:39 +0800 From: "Will Liu (Shucheng)" To: Francesco Fondelli Thread-Topic: [mpls] FW: New Version Notification for draft-manral-mpls-rfc3811bis-02.txt Thread-Index: AQHOVlmidmIrNtZlCEydD0bqhMBO45kQf6+AgAOhJICABCuTMIAAvTOA Date: Mon, 27 May 2013 13:08:39 +0000 Message-ID: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.78.79] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" Subject: Re: [mpls] FW: New Version Notification for draft-manral-mpls-rfc3811bis-02.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 13:08:53 -0000 SGkgRnJhbmNlc2NvLA0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuIFBsZWFzZSBzZWUgYmVs b3cgaW4tbGluZS4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBGcmFu Y2VzY28gRm9uZGVsbGkgW21haWx0bzpmcmFuY2VzY28uZm9uZGVsbGlAZ21haWwuY29tXQ0KPiBT ZW50OiBTYXR1cmRheSwgTWF5IDI1LCAyMDEzIDI6MDkgQU0NCj4gVG86IFdpbGwgTGl1IChTaHVj aGVuZykNCj4gQ2M6IG1wbHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFttcGxzXSBGVzogTmV3 IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KPiBkcmFmdC1tYW5yYWwtbXBscy1yZmMzODExYmlz LTAyLnR4dA0KPiANCj4gSGkgV2lsbCwgYWxsLA0KPiANCj4gSSBoYXZlIGFsd2F5cyB0aG91Z2h0 IE1wbHNMU1BJRCBkZXNjcmlwdGlvbiBpbiAzODExIHdhcyBtaXNsZWFkaW5nIChvcg0KPiBpbmNv bnNpc3RlbnQpOiAiQSB1bmlxdWUgaWRlbnRpZmllciB3aXRoaW4gYW4gTVBMUyBuZXR3b3JrIHRo YXQgaXMgYXNzaWduZWQNCj4gdG8gZWFjaCBMU1AuLi4iLiAgRm9yIExEUCB0aGlzIGlzIDYgYnl0 ZXMgJ0lQIGFkZHIgKyBsb2NhbCBJRCcgYW5kIGNhbg0KPiBiZSB1c2VkIGFzIGEgbmV0d29yay11 bmlxdWUgaGFuZGxlLiAgSG93ZXZlciwgZm9yIExTUHMgc2lnbmFsZWQgdXNpbmcNCj4gUlNWUC1U RSwgUkZDMzgxMSBzdWdnZXN0cyB0byB1c2UgdGhlIExTUF9JRCAoMiBieXRlKSB1c2VkIGluIHRo ZQ0KPiBTRU5ERVJfVEVNUExBVEUgb2JqLiAgVGhpcyBpcyBqdXN0IGEgbG9jYWwgbnVtYmVyIChp dCBpcyB1bmlxdWUgd2l0aGluDQo+IHRoZSBzY29wZSBvZiB0aGUgU0VTU0lPTikgc28gaXQgY2Fu bm90IGJlIHVzZWQgdG8gdW5pcXVlbHkgaWRlbnRpZnkgYW4NCj4gTFNQIG9uIGEgbmV0d29yay4N Cg0KQWdyZWUuDQo+IA0KPiBDYW4gd2UgYWxzbyAiZml4IiB0aGlzIGluIDM4MTFiaXMgPw0KDQpZ ZXMuIEkgdGhpbmsgd2UgY2FuIGZpeCB0aGlzIGluIHRoZSBuZXh0IHZlcnNpb24uDQo+IA0KPiBX ZSBjYW4gc2ltcGx5IHN0YXRlIChpbiB0aGUgTXBsc0xTUElEIGRlc2NyaXB0aW9uKSB0aGF0IGZv ciBMU1BzIHNpZ25hbGVkDQo+IHVzaW5nIFJTVlAtVEUgdGhpcyBpcyBqdXN0IGEgbG9jYWwgbnVt YmVyLiAgQWx0ZXJuYXRpdmVseSwgd2UgY2FuIG1ha2UNCj4gcm9vbSAobm93IGlzIG1heCA2IG9j dGV0cykgZm9yIGZ1bGwgbmV0d29yayBsZXZlbCBMU1AgaWRlbnRpZmljYXRpb246DQo+IDUtdHVw bGUgeyBEZXN0aW5hdGlvbiBBZGRyZXNzLCBUdW5uZWxfSUQsIEV4dGVuZGVkIFR1bm5lbCBJRCwg U2VuZGVyDQo+IEFkZHJlc3MsDQo+IExTUF9JRCB9Lg0KPiANCj4gdGhhbmsgeW91DQo+IGNpYW8N Cj4gZnJhDQo+IA0KPiBPbiBXZWQsIE1heSAyMiwgMjAxMyBhdCA1OjAyIEFNLCBXaWxsIExpdSAo U2h1Y2hlbmcpDQo+IDxsaXVzaHVjaGVuZ0BodWF3ZWkuY29tPiB3cm90ZToNCj4gPiBGb2xrcywN Cj4gPg0KPiA+IFdlIHVwZGF0ZWQgdGhlIGRyYWZ0IGJ5IG1vZGlmeWluZyB0aGUgaW50cm9kdWN0 aW9uLCB0eXBvcyBpbiBzZWN0aW9uIDUsIGFuZA0KPiBhZGRpbmcgYSBzZWN0aW9uIGhpZ2hsaWdo dGluZyB0aGUgY2hhbmdlcyBvbiByZmMzODExLg0KPiA+DQo+ID4gWW91ciByZXZpZXcgYW5kIGNv bW1lbnRzIGFyZSBoaWdobHkgYXBwcmVjaWF0ZWQuDQo+ID4NCj4gPiBSZWdhcmRzLA0KPiA+IFdp bGwNCj4gPg0KPiA+DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmdd DQo+ID4gU2VudDogV2VkbmVzZGF5LCBNYXkgMjIsIDIwMTMgMzozMCBBTQ0KPiA+IFRvOiBUaW5h IFRTT1U7IFdpbGwgTGl1IChTaHVjaGVuZyk7IFZpc2h3YXMgTWFucmFsOyBXaWxsIExpdSAoU2h1 Y2hlbmcpDQo+ID4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1t YW5yYWwtbXBscy1yZmMzODExYmlzLTAyLnR4dA0KPiA+DQo+ID4NCj4gPiBBIG5ldyB2ZXJzaW9u IG9mIEktRCwgZHJhZnQtbWFucmFsLW1wbHMtcmZjMzgxMWJpcy0wMi50eHQNCj4gPiBoYXMgYmVl biBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFZpc2h3YXMgTWFucmFsIGFuZCBwb3N0ZWQgdG8g dGhlDQo+ID4gSUVURiByZXBvc2l0b3J5Lg0KPiA+DQo+ID4gRmlsZW5hbWU6ICAgICAgICBkcmFm dC1tYW5yYWwtbXBscy1yZmMzODExYmlzDQo+ID4gUmV2aXNpb246ICAgICAgICAwMg0KPiA+IFRp dGxlOiAgICAgICAgICAgRGVmaW5pdGlvbnMgb2YgVGV4dHVhbCBDb252ZW50aW9ucyAoVENzKSBm b3INCj4gTXVsdGlwcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgKE1QTFMpIE1hbmFnZW1lbnQNCj4g PiBDcmVhdGlvbiBkYXRlOiAgIDIwMTMtMDUtMjANCj4gPiBHcm91cDogICAgICAgICAgIEluZGl2 aWR1YWwgU3VibWlzc2lvbg0KPiA+IE51bWJlciBvZiBwYWdlczogMjINCj4gPiBVUkw6DQo+IGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LW1hbnJhbC1tcGxzLXJmYzM4 MTFiaXMtMDIudHh0DQo+ID4gU3RhdHVzOg0KPiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LW1hbnJhbC1tcGxzLXJmYzM4MTFiaXMNCj4gPiBIdG1saXplZDoNCj4gaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbWFucmFsLW1wbHMtcmZjMzgxMWJpcy0wMg0KPiA+ IERpZmY6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LW1hbnJhbC1t cGxzLXJmYzM4MTFiaXMtMDINCj4gPg0KPiA+IEFic3RyYWN0Og0KPiA+ICAgIFRoaXMgbWVtbyBk ZWZpbmVzIGEgTWFuYWdlbWVudCBJbmZvcm1hdGlvbiBCYXNlIChNSUIpIG1vZHVsZQ0KPiB3aGlj aA0KPiA+ICAgIGNvbnRhaW5zIFRleHR1YWwgQ29udmVudGlvbnMgdG8gcmVwcmVzZW50IGNvbW1v bmx5IHVzZWQNCj4gTXVsdGlwcm90b2NvbA0KPiA+ICAgIExhYmVsIFN3aXRjaGluZyAoTVBMUykg bWFuYWdlbWVudCBpbmZvcm1hdGlvbi4gIFRoZSBpbnRlbnQgaXMgdGhhdA0KPiA+ICAgIHRoZXNl IFRFWFRVQUwgQ09OVkVOVElPTlMgKFRDcykgd2lsbCBiZSBpbXBvcnRlZCBhbmQgdXNlZCBpbg0K PiBNUExTDQo+ID4gICAgcmVsYXRlZCBNSUIgbW9kdWxlcyB0aGF0IHdvdWxkIG90aGVyd2lzZSBk ZWZpbmUgdGhlaXIgb3duDQo+ID4gICAgcmVwcmVzZW50YXRpb25zLg0KPiA+DQo+ID4gICAgVGhp cyBkb2N1bWVudCBvYnNvbGV0ZXMgUkZDMzgxMSBhcyBpdCBhZGRyZXNzZXMgdGhlIG5lZWQgdG8g c3VwcG9ydA0KPiA+ICAgIElQdjYgZXh0ZW5kZWQgVHVubmVsSUQncyBieSBkZWZpbmluZyBhIG5l dyBUQy0NCj4gPiAgICBNcGxzTmV3RXh0ZW5kZWRUdW5uZWxJRCB3aGljaCBzdWdnZXN0cyB1c2lu ZyBJUHY0IGFkZHJlc3Mgb2YgdGhlDQo+ID4gICAgaW5ncmVzcyBvciBlZ3Jlc3MgTFNSIGZvciB0 aGUgdHVubmVsIGZvciBhbiBJUHY2IG5ldHdvcmsuICBDaGFuZ2VzDQo+ID4gICAgZnJvbSBSRkMz ODExIGFuZCB0aGUgZWZmZWN0IG9mIHRoZSBuZXcgVEMgdG8gb3RoZXIgcmVsYXRlZA0KPiBkb2N1 bWVudHMNCj4gPiAgICBhcmUgc3VtbWFyaXplZCBpbiBTZWN0aW9uIDQgYW5kIDUsIHJlc3BlY3Rp dmVseS4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiA+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+ID4N Cj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ IG1wbHMgbWFpbGluZyBsaXN0DQo+ID4gbXBsc0BpZXRmLm9yZw0KPiA+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0K From internet-drafts@ietf.org Mon May 27 14:40:53 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DACFA21F87CB; Mon, 27 May 2013 14:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.38 X-Spam-Level: X-Spam-Status: No, score=-102.38 tagged_above=-999 required=5 tests=[AWL=0.220, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3w0kYaQZ9Chd; Mon, 27 May 2013 14:40:53 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0AB21F85E6; Mon, 27 May 2013 14:40:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130527214053.24728.86099.idtracker@ietfa.amsl.com> Date: Mon, 27 May 2013 14:40:53 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-kompella-mpls-special-purpose-labels-03.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 21:40:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Allocating and Retiring Special Purpose MPLS Labels Author(s) : Kireeti Kompella Loa Andersson Adrian Farrel Filename : draft-kompella-mpls-special-purpose-labels-03.txt Pages : 9 Date : 2013-05-27 Abstract: Some MPLS labels have been allocated for specific purposes. A block of labels (0-15) has been set aside to this end, and are commonly called "reserved labels". They will be called "special purpose labels" in this document. As there are only 16 of these labels, caution is needed in the allocation of new special purpose labels, yet at the same time allow forward progress when one is called for. This memo defines some procedures to follow in the allocation and retirement of special purpose labels, as well as a method to extend the special purpose label space. Finally, this memo renames the IANA registry for these labels to "Special Purpose MPLS Label Values", and creates a new one called the "Extended Special Purpose MPLS Label Values" registry. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-kompella-mpls-special-purpose-labels There's also a htmlized version available at: http://tools.ietf.org/html/draft-kompella-mpls-special-purpose-labels-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-kompella-mpls-special-purpose-labe= ls-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon May 27 14:55:31 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E92D21F8F61; Mon, 27 May 2013 14:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.394 X-Spam-Level: X-Spam-Status: No, score=-102.394 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lGQUrhZS2CeK; Mon, 27 May 2013 14:55:30 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 790DE21F89EB; Mon, 27 May 2013 14:55:30 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130527215530.13286.9095.idtracker@ietfa.amsl.com> Date: Mon, 27 May 2013 14:55:30 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-kompella-mpls-special-purpose-labels-04.txt X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 May 2013 21:55:31 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multiprotocol Label Switching Working Gro= up of the IETF. Title : Allocating and Retiring Special Purpose MPLS Labels Author(s) : Kireeti Kompella Adrian Farrel Filename : draft-kompella-mpls-special-purpose-labels-04.txt Pages : 9 Date : 2013-05-27 Abstract: Some MPLS labels have been allocated for specific purposes. A block of labels (0-15) has been set aside to this end, and are commonly called "reserved labels". They will be called "special purpose labels" in this document. As there are only 16 of these labels, caution is needed in the allocation of new special purpose labels, yet at the same time allow forward progress when one is called for. This memo defines some procedures to follow in the allocation and retirement of special purpose labels, as well as a method to extend the special purpose label space. Finally, this memo renames the IANA registry for these labels to "Special Purpose MPLS Label Values", and creates a new one called the "Extended Special Purpose MPLS Label Values" registry. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-kompella-mpls-special-purpose-labels There's also a htmlized version available at: http://tools.ietf.org/html/draft-kompella-mpls-special-purpose-labels-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-kompella-mpls-special-purpose-labe= ls-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ietfc@btconnect.com Tue May 28 08:00:57 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 209C421F853A for ; Tue, 28 May 2013 08:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.269 X-Spam-Level: X-Spam-Status: No, score=-0.269 tagged_above=-999 required=5 tests=[AWL=0.471, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9OsZrAtGGTtK for ; Tue, 28 May 2013 08:00:50 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0187.outbound.messaging.microsoft.com [213.199.154.187]) by ietfa.amsl.com (Postfix) with ESMTP id 7019D21F980E for ; Tue, 28 May 2013 08:00:36 -0700 (PDT) Received: from mail197-db8-R.bigfish.com (10.174.8.230) by DB8EHSOBE036.bigfish.com (10.174.4.99) with Microsoft SMTP Server id 14.1.225.23; Tue, 28 May 2013 15:00:35 +0000 Received: from mail197-db8 (localhost [127.0.0.1]) by mail197-db8-R.bigfish.com (Postfix) with ESMTP id 326695E01F9; Tue, 28 May 2013 15:00:35 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.85; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0710HT004.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -17 X-BigFish: PS-17(zz98dI9371I936eI542I1432I62a3Idb82hzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL8275bh8275dhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh304l1d11m1155h) Received: from mail197-db8 (localhost.localdomain [127.0.0.1]) by mail197-db8 (MessageSwitch) id 1369753217240893_20802; Tue, 28 May 2013 15:00:17 +0000 (UTC) Received: from DB8EHSMHS018.bigfish.com (unknown [10.174.8.247]) by mail197-db8.bigfish.com (Postfix) with ESMTP id 641D6180069; Tue, 28 May 2013 15:00:11 +0000 (UTC) Received: from AMSPRD0710HT004.eurprd07.prod.outlook.com (157.56.249.85) by DB8EHSMHS018.bigfish.com (10.174.4.28) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 28 May 2013 15:00:01 +0000 Received: from AMXPRD0111HT002.eurprd01.prod.exchangelabs.com (157.56.250.117) by pod51017.outlook.com (10.255.160.167) with Microsoft SMTP Server (TLS) id 14.16.311.1; Tue, 28 May 2013 14:59:59 +0000 Message-ID: <011001ce5bb3$3cd21e80$4001a8c0@gateway.2wire.net> From: t.petch To: Loa Andersson , , Martin Vigoureux References: <51839D5B.5090108@pi.nu> <5183EAEF.8020100@pi.nu> Date: Tue, 28 May 2013 15:51:43 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [157.56.250.117] X-OriginatorOrg: btconnect.com Subject: Re: [mpls] IANA section of draft-ietf-mpls-ldp-ip-pw-capability X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2013 15:00:57 -0000 ---- Original Message ----- From: "Loa Andersson" To: ; ; "Martin Vigoureux" Sent: Friday, May 03, 2013 5:50 PM > Folks, > > I would like to amend my proposal to say: > > 8. IANA Considerations > > This document defines a new LDP cpability parameter TLV. IANA is > requested to assign the lowest available value after 0x0500 from > "TLV Type Name Space" in the "Label Distribution Protocol (LDP) > Parameters" registry within "Label Distribution Protocol (LDP) > Name Spaces" as the new code point for the LDP TLV code point . I note that -05 has included this text verbatim. I would suggest /LDP cpability parameter/LDP capability parameter/ if and when a revision is needed, else one for the RFC Editor. Tom Petch > > Range | Description | Reference | Notes/Registration Date > -------+---------------------+---------------+------------------------ --- > tbd | Application Control | This document | > | Capability | | > -------+---------------------+---------------+------------------------ --- > > > /Loa > > On 2013-05-03 13:19, Loa Andersson wrote: > > Authors, > > > > > > I should have done this before, IANA sections is always tricky > > and need to be precise, > > > > The IANA section of draft-ietf-mpls-ldp-ip-pw-capability-03.txt > > says: > > > > "8. IANA Considerations > > > > The document defines a new capability parameter TLV and requests > > following LDP TLV code point assignment by IANA from LDP "TLV Type > > Name Space" registry: > > > > o "Application Control Capability" TLV (requested codepoint: 0x50C)" > > > > This is basically correct, but a few details need to be > > added. I would like to have it re-written as: > > > > 8. IANA Considerations > > > > This document defines a new LDP cpability parameter. IANA is > > requested to assign a new LDP TLV code point from "TLV Type > > Name Space" in the "Label Distribution Protocol (LDP) Parameters" > > registry within "Label Distribution Protocol (LDP) Name Spaces". > > > > Range | Description | Reference | Notes/Registration Date > > ------+---------------------+---------------+------------------------- -- > > tbd | Application Control | This document | > > | Capability | | > > ------+---------------------+---------------+------------------------- -- > > > > > > > > Note 1: That naming structure is not good, I will talk to IANA to change it > > to something more intuitive. > > > > Note 2: "Range" is really "Value" or "Type", will check on the defining > > documents and talk to IANA to change it. > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > _______________________________________________ From adrian@olddog.co.uk Tue May 28 23:18:33 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485BC21F904B for ; Tue, 28 May 2013 23:18:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dgteJ1-iDhyW for ; Tue, 28 May 2013 23:18:28 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id BB3C321F9003 for ; Tue, 28 May 2013 23:18:14 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4T6IC7I010360; Wed, 29 May 2013 07:18:13 +0100 Received: from 950129200 (p3040-ipbf515marunouchi.tokyo.ocn.ne.jp [221.189.180.40]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4T6I8Gc010321 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 May 2013 07:18:11 +0100 From: "Adrian Farrel" To: Date: Wed, 29 May 2013 07:18:06 +0100 Message-ID: <00e501ce5c34$4a924dc0$dfb6e940$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5cNCgiJktZy4yHS4OzgkeQ0sBzMA== Content-Language: en-gb Cc: mpls@ietf.org Subject: [mpls] AD review of draft-ietf-mpls-ldp-multi-topology X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 06:18:33 -0000 Hi authors, Thanks for this document. I have done my usual AD review which is intended to catch any issues that I see, and to smooth out the wrinkles before the I-D goes to IETF last call and IESG review. As you will see below, I have a number of editorial comments (nits and larger changes) and also a few questions/issues. The biggest issue concerns the MT-ID and spans sections 3.4, 3.8, and 9. I suggest you read the comments against those sections all together. Note that in my comment for section 9, I think I have worked out what you need to do, and so the resolution to the comments for 3.4 and 3.8 may simply be documenting this change to the IANA registry. As usual, all my comments are up for discussion, so please don't feel you are required to make changes if you think there is a good reason why things are the way they are. At the moment it looks like a new revision will be needed to address the review, so I have set the flag in the datatracker. Please work with your document shepherd to produce and post a new revision. Thanks, Adrian === The document seems to end with a spurious page header. --- The index seems to be considerably adrift from reality. In particular, there is no Appendix in this document. --- Why do you say that this updates RFC 4379? Is it your belief that an implementation of RFC 4379 will not be complete/conformant without these extensions? Or are you just defining extensions which an implementation in an MPLS-MT environment will need to support? I note that you (in my view, correctly) do not say that this document updates RFC 5036, yet it defines extensions to LDP in a similar way. --- Please expand all acronyms on first use unless they show with an asterisk in the RFC Editor's list at http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt I see: CSP LSP QoS --- Abstract and Introduction "IGP protocol" is bad because the "P" in "IGP" is "protocol". --- The RFC Editor prefers documents to have the Introduction as Section 1. You may prefer to make this change yourself, because it will possibly cause some expansions of terms and acronyms that the RFC Editor might so in a way you don't like. --- In section 1, the term "MT Topology" is odd because the "T" of "MT" stands for "Topology". Surely you don't mean "Multi Topology Topology"? --- Section 3.1 s/infers/implies/ --- Section 3.2 I prefer that you don't repeat protocol encodings that are defined elsewhere. This can cause nasty problems if you make a mistake or if the original definition is updated. It is enough for you to write... The LDP base specification [RFC5036] (Section 4.1) defines the "Prefix" FEC Element. The "Prefix" encoding is defined for a given "Address Family" (AF), and has length (in bits) specified by the "PreLen" field. To extend IP address families for MT, two new Address Families named "MT IP" and "MT IPv6" are used to specify IPv4 and IPv6 prefixes within a topology scope. --- Section 3.2 Figure 2 This figure gives the impression that both IPv4 and IPv6 addresses are four bytes long! I think you need: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ IP Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | MT-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: MT IP Address Family Format ...and... Where "IP Address" is a variable length field padded to a four octet boundary and containing an IPv4 or IPv6 address/prefix for the "MT IP" and "MT IPv6" AFs respectively. The field "MT-ID" corresponds to the 16-bit Topology ID for given address. ...but you need to check I got that right! However, before doing this work, see my comment on Section 3.3 --- Section 3.2 The proposed FEC Elements with "MT IP" Address Family can be used in You are not proposing any more, you are defining! See also section 3.6, 3.8, 4.1, 4.3, and 8 --- Section 3.2 [RFC5036] does not specify the handling of "Unknown" Address Families. Therefore, [RFC5036] will need to be updated to include the handling procedure for unknown address families. Ouch! This had me really worried because it implied that you are breaking existing LDP deployments. But I discussed it with Loa, and he pointed me at Section 3.4.1.1 of RFC 5036 "If in decoding a FEC TLV an LSR encounters a FEC Element with an Address Family it does not support, it SHOULD stop decoding the FEC TLV, abort processing the message containing the TLV, and send an "Unsupported Address Family" Notification message to its LDP peer signaling an error. If it encounters a FEC Element type it cannot decode, it SHOULD stop decoding the FEC TLV, abort processing the message containing the TLV, and send an "Unknown FEC" Notification message to its LDP peer signaling an error." So I think you can just delete this paragraph. Furthermore, Section 3.5 defines a capability advertisement that enables you to know whether it is safe to use one of the new AFs. So surely you should also say "MUST NOT send an MT AF unless the peer has said it can handle it." See my re-write in the next comment. --- Section 3.3 appears to be repeating a lot of Section 3.2, but in a better and more concise way. For example, Figure 3 nicely shows how the Prefix FEC element works with the new AFs. This leads me to think that Section 3.2 could be reduced to just a few lines that say... The LDP base specification [RFC5036] (Section 4.1) defines the the use of an "Address Family" (AF) field in FEC Elements to indicate the encoding of the "Prefix" or "Address" that follows, and to indicate how the FEC should be interpreted. This document defines two new AF values named "MT IP" and "MT IPv6" that are used to specify the use of IPv4 or IPv6 within a topology scope. The data associated with these new AFs includes an "MT-ID" field that carries the 16-bit Topology ID for a topology. The value of MT-ID=0 corresponds to default topology and MUST be ignored on receipt so as to not cause any conflict/confusion with existing non-MT procedures. FEC Elements with the new AFs can be used in any LDP message and procedures that currently specify and allow the use of FEC Elements with the IP or IPv6 AFs, but MUST NOT be used unless the peer has indicated it can handle them as described in Section 3.5. Note that behavior by an LDP speaker that receives a FEC element containing an unknown AF is described in Section 3.4.1.1 of [RFC5036]. --- Section 3.4 is perfectly clear except it doesn't say what "reserved", "special", and "translating" mean. This opens up a number of questions including why you need a registry at all. Presumably the "translation" needed is to ensure that the values used in LDP have the same meaning as they do in the IGP. If that is the case, why not simply use exactly the same value? And looking at the registry further, it seems to say that only values allocated by IANA and stored in the registry can be used. That means that an operator that wants to use MT in their network cannot just assign values to the MT-IDs for the topologies because the registry has no space for this to happen. Now, it is possible that you have simply used the wrong words in the registry in section 9, and failed to provide any explanation in the text. Note that "unassigned" means "not yet assigned, but available to be assigned by IANA". And "Reserved" means "Do not assign until a new RFC defines how they should be used." But there are other questions: Why do you need 16 bits when ISIS has only 12 bits and OSPF only 8 bits? I guess 16 is convenient to hold either, but how are the top 4 bits to be handled? How do you handle the case where there are multiple instances of an IGP (or different IGPs) running? If you *do* expect there to be a mapping function between IGP MT-ID and LDP MT-ID, how do you ensure the same function is used at both ends of an LDP session? But Section 3.8 really does seem to say that only MT-IDs in the registry are allowed, which seems to make this I-D almost useless because you have only defined "default" (which we have already), "ISIS IPv6", and "all". Isn't an operator allowed to partition their network into topologies? So... I think what you need in Section 9 is... o New registry "LDP Multi-Topology (MT) ID Name Space" under "LDP Parameter" namespace. The allocation policies for this registry are: Range Registration Policy ------ ------------------- 0-3995 Expert Review 3996-4095 Private Use 4096-4127 Expert Review 4128-4255 Private Use 4256-4351 Reserved (IANA does not assign) 4352-4511 Expert Review 4512-65535 Private Use IANA is requested to populate this registry as follows: Range/Value Purpose Reference ----------- ------------------------------------- --------- 0 Default/standard topology in IS-IS [This.I-D] 1 IPv4 in-band management in IS-IS [This.I-D] 2 IPv6 routing topology in IS-IS [This.I-D] 3 IPv4 multicast topology in IS-IS [This.I-D] 4 IPv6 multicast topology in IS-IS [This.I-D] 5 IPv6 in-band management in IS-IS [This.I-D] 6-3995 Unassigned (intended to mirror IS-IS) 3996-4095 Reserved for private use (from IS-IS) [This.I-D] 4096 Default/standard topology in OSPF [This.I-D] 4097 Default multicast topology in OSPF [This.I-D] 4098 IPv4 in-band management in OSPF [This.I-D] 4099-4127 Unassigned (intended to mirror OSPF) 4128-4255 Reserved for private use (from OSPF) [This.I-D] 4256-4351 Reserved (IANA does not assign) [This.I-D] 4352-4511 Unassigned 4512-65535 Reserved for Private Use [This.I-D] This would address many of the issues in Sections 3.4 and 3.8, and needs to be discussed in those sections. --- In Section 3.5 o Length: The length (in octets) of TLV. Are you sure it is not just the length in octets of the value? Compare with RFC 5036 Section 3.3 --- Sections 3.5 and 3.6 need to be more closely grouped. Suggest moving most of 3.5 into 3.5.1 and moving 3.6 into 3.5.2 --- Section 3.6 To announce its MT capability for an IP address family, LDP FEC type, and Multi Topology, an LDP speaker MAY send an "MT Capability" including the exact Typed Wildcard FEC element with corresponding "AddressFamily" field (i.e., set to "MT IP" for IPv4 and set to "MT IPv6" for IPv6 address family), corresponding "FEC Type" field (i.e., set to "P2P", "P2MP", "MP2MP"), and corresponding "MT-ID". To announce its MT capability for both IPv4 and IPv6 address family, or for multiple FEC types, or for multiple Multi Topologies, an LDP speaker MAY send "MT Capability" with one or more MT Typed FEC elements in it. I don't think this is "MAY" in either case. This *is* how the LDP speaker announces it. There is no other way to announce it. So... To announce its MT capability for an IP address family, LDP FEC type, and Multi Topology, an LDP speaker sends an "MT Capability" including the exact Typed Wildcard FEC element with corresponding "AddressFamily" field (i.e., set to "MT IP" for IPv4 and set to "MT IPv6" for IPv6 address family), corresponding "FEC Type" field (i.e., set to "P2P", "P2MP", "MP2MP"), and corresponding "MT-ID". To announce its MT capability for both IPv4 and IPv6 address family, or for multiple FEC types, or for multiple Multi Topologies, an LDP speaker sends "MT Capability" with one or more MT Typed FEC elements in it. --- Section 3.6 o If an LSR has not advertised MT capability, its peer must not send messages that include MT identifier to this LSR. Isn't that "MUST NOT"? --- Section 3.8 Certain MT topologies are assigned to serve predetermined purposes: It is not the topology that is assigned, but the MT-ID. Should read: Certain MT-ID values are assigned to indicate specific meanings: --- Section 3.8 It is not helpful to "propose" numbers in this section and then to also reference Section 9 for the definitive numbers. I suggest you remove all numbers from this section and simply point at Section 9. --- Section 4.2 This MAY allow an LDP speaker to signal its IP convergence... What does 2119 MAY mean in this context? --- Section 4.3 [RFC4379] defines procedures to detect data-plane failures in MPLS LSPs via LSP ping. The specification defines a "Target FEC Stack" TLV that describes the FEC stack being tested. Ha, ha! You got me :-) s/The specification/That specification/ --- Section 4.3.1 Sub-Type Length Value Field -------- ------ ----------------- TBA5 5 MT LDP IPv4 prefix TBA6 17 MT LDP IPv6 prefix Are you sure you don't mean 8 and 20? --- Section 4.3.4 When detect data plane failures using LSP Ping for a specific topoly, the router will intiate an LSP Ping request with the targer FEC stack I think s/When/To/ s/topoly/topology/ s/intiate/initiate/ s/targer/target/ --- Section 4.3.4 For the case that the LSP ping with return path not specified , the reply packet may go through the default topology instead of the topology where the Echo Request goes through. Is that really "the default" or "any"? If you mean "the default" then I think you need some "MUST NOT" text to talk about other topologies. --- Section 5 The extensions defined in this document utilise the existing LDP error handling defined in [RFC5036]. If an LSR receives an error notification from a peer for an MPLS-MT session, it terminates the LDP session by closing the TCP transport connection for the session and discarding all MT-ID label mappings learned via the session. There is nothing wrong with this text, but it does open a question that is not addressed anywhere in the document: what is the relationship between LDP sessions and MT-IDs? 1:1, 1:n, n:1, n:m? This is somewhat assumable from the discussion of multiple MT-ID wildcard FEC elements in the Multi-Topology Capability TLV, but it is not explicit. --- Shouldn't Section 6 comment on how each of the new protocol elements will not be seen by a legacy implementation because they are only used after successful capability negotiation? But you do need to describe how a legacy node will react to attempted MT capability negotiation. You could also restate the reference to RFC 5036 section 3.4.1.1 since this issue seemed to be a question for you. --- I'm slightly doubtful about the value of Section 7, but I note that the point you are trying to convey is not quite worded correctly. You have: and the specified signaling mechanisms do not provide any way for the data plane to associate a given packet with a context-specific label space. I don't think the signaling mechanism is relevant, and I think "context- specific" hides what you are trying to say. Perhaps you should have: and there is no way for the data plane to associate a received packet with any one topology, meaning that topology-specific label spaces cannot be used. --- Section 9 o New Status Code: "Multi-Topology Capability not supported" (requested code point: TBA2 from LDP registry "Status Code Name Space"). This status code does not appear to be mentioned in the draft. How is it used? Is an implementation that does not know the new MT Capability TLV supposed to generate this status code? Or are you referencing an existing error code: in which case it should not appear in this section. o New Status Code: "Unknown Address Family" (requested code point: TBA4 from LDP registry "Status Code Name Space"). This status code does not appear to be mentioned in the draft. How is it used? Is a legacy implementation that does not know either of your new MT AFs supposed to generate this status code? But I suspect you are just referencing an existing error code (see Section 3.2) as defined in RFC 5036, and so you should not mention it in this section. Figure 10 does not show either of these status codes. --- Figure 10 shows a specific value for the new status code. Is this a request or demand? I don't think it has already been allocated. --- Section 9 o New registry "LDP Multi-Topology (MT) ID Name Space" under "LDP Parameter" namespace. This registry is discussed earlier in my notes. but please be aware that you will need to define the allocation policy because it is a new registry. --- Section 9 I want to ask Loa Andersson to look again at the LSP Ping TLV allocations to check that they conform to the work he is currently doing with that registry. --- It would help considerably to add a Manageability Considerations section to this document because the function being added here is not simple to manage or operate, and will have impact on the way that the network is run. Good guidance on such sections can be found in RFC 5706. Appendix A is particularly helpful at summarising things to consider. -------------------- From loa@pi.nu Wed May 29 03:04:01 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8294821F9307 for ; Wed, 29 May 2013 03:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.048 X-Spam-Level: X-Spam-Status: No, score=-101.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9oTwHrz8W-h for ; Wed, 29 May 2013 03:03:56 -0700 (PDT) Received: from pipi.pi.nu (unknown [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id E03A121F931B for ; Wed, 29 May 2013 03:03:51 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 8FE301800272; Wed, 29 May 2013 12:03:50 +0200 (CEST) Message-ID: <51A5D286.8050203@pi.nu> Date: Wed, 29 May 2013 12:03:50 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" Subject: [mpls] The Label Distribution Protocol (LDP) Parameters in the IANA registries X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 10:04:01 -0000 Working Group, we have done a few (mostly cosmetic) changes in the "Label Distribution Protocol (LDP) Parameters" namespace. You now (as before) find the name space on the IANA Protocol Registries web page: http://www.iana.org/protocols Look for ""Label Distribution Protocol (LDP) Parameters" First, we have changed the name on the IANA page and the name on the page that have the LDP parameter assignments so the have the same name. This should make it easier to write clear and precise IANA sections in our drafts Second - in the "TLV Type Name Space" we have updated the table; the left most column is now "Value" instead of "Range". Third, we have made the "Unassigned" TLV values explicit. Fourth, we have also updated the mail address for Andy, so it is to his current mailbox. /Loa MPLS wg chair -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From akatlas@gmail.com Wed May 29 05:52:34 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C081021F898B for ; Wed, 29 May 2013 05:52: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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4c44MnZrN3f for ; Wed, 29 May 2013 05:52:22 -0700 (PDT) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 08BA721F870F for ; Wed, 29 May 2013 05:52:20 -0700 (PDT) Received: by mail-ie0-f175.google.com with SMTP id tp5so7762785ieb.6 for ; Wed, 29 May 2013 05:52:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=T/2PbadxTWIf8yu6XLMFxQ5oy09K4zfubc8cjWZVmBo=; b=Z7ky4hNlSv5f2+CS85lhfoSN4+yMPH+4BqVyBGrj/kprM0vVZlj3Af+o4BwBXG9YBP 7zxAPOjxFamzfi8W6rrxMW9HECTTdMDdz3emAGRDuIzjlNxAy2YAWBP4zbSMny0U6GLf ZLnUKIupfie5FcBvYCIa348JgelvJ6MoucuxrUW0xbr4TebtgMVf+p9NbpECGE7EQzJT VTIhG2B3HNfPkJ112++QkPL78fn2V7rXJP9LNpfjdRZHbLcondZ4df9lHA1yNUJFFsGh N7jW8Wg4k8klkDj6DYmUx0gKD5gWjjsYD8EesNsbphU/GKgh4bo8glqldYixP5GTjDLB iLSw== MIME-Version: 1.0 X-Received: by 10.50.27.37 with SMTP id q5mr8908281igg.52.1369831939560; Wed, 29 May 2013 05:52:19 -0700 (PDT) Received: by 10.64.46.4 with HTTP; Wed, 29 May 2013 05:52:19 -0700 (PDT) In-Reply-To: <00e501ce5c34$4a924dc0$dfb6e940$@olddog.co.uk> References: <00e501ce5c34$4a924dc0$dfb6e940$@olddog.co.uk> Date: Wed, 29 May 2013 08:52:19 -0400 Message-ID: From: Alia Atlas To: Adrian Farrel Content-Type: multipart/alternative; boundary=047d7b10c83728dc4404dddada04 Cc: "mpls@ietf.org" , draft-ietf-mpls-ldp-multi-topology.all@tools.ietf.org Subject: Re: [mpls] AD review of draft-ietf-mpls-ldp-multi-topology X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 12:52:37 -0000 --047d7b10c83728dc4404dddada04 Content-Type: text/plain; charset=ISO-8859-1 Hi Adrian & authors, I have a couple comments on the IANA registry and number overlapping. First, it would be useful to have a range that is clearly intended to be the same for OSPF, ISIS and LDP. Given the extremely limited range for OSPF multi-topology routing ( http://www.iana.org/assignments/ospf-mt-routing/ospf-mt-routing.xml) of 3-127, it'd be very useful to have that range specifically set aside for cases where it matters that it be the same. One use that I see for this draft is for MRT, which is doing multi-topology forwarding but not multi-topology routing. This means that the MT-IDs used do not need to overlap with those in OSPF or ISIS. It would be good to ensure that there's a reasonable range in LDP for such purposes. LDP is one of the few mechanisms that easily lends itself to multi-topology forwarding. Alia P.S. Having the same values for mLDP and PIM may also be very useful for interworking. PIM doesn't actually have an IANA registry for MT-ID and leaves the meaning of the values up to the network operator. On Wed, May 29, 2013 at 2:18 AM, Adrian Farrel wrote: > Hi authors, > > Thanks for this document. > > I have done my usual AD review which is intended to catch any issues > that I see, and to smooth out the wrinkles before the I-D goes to IETF > last call and IESG review. > > As you will see below, I have a number of editorial comments (nits and > larger changes) and also a few questions/issues. > > The biggest issue concerns the MT-ID and spans sections 3.4, 3.8, and 9. > I suggest you read the comments against those sections all together. > Note that in my comment for section 9, I think I have worked out what > you need to do, and so the resolution to the comments for 3.4 and 3.8 > may simply be documenting this change to the IANA registry. > > As usual, all my comments are up for discussion, so please don't feel > you are required to make changes if you think there is a good reason why > things are the way they are. > > At the moment it looks like a new revision will be needed to address the > review, so I have set the flag in the datatracker. Please work with your > document shepherd to produce and post a new revision. > > Thanks, > Adrian > > === > > The document seems to end with a spurious page header. > > --- > > The index seems to be considerably adrift from reality. > In particular, there is no Appendix in this document. > > --- > > Why do you say that this updates RFC 4379? Is it your belief that an > implementation of RFC 4379 will not be complete/conformant without these > extensions? Or are you just defining extensions which an implementation > in an MPLS-MT environment will need to support? > > I note that you (in my view, correctly) do not say that this document > updates RFC 5036, yet it defines extensions to LDP in a similar way. > > --- > > Please expand all acronyms on first use unless they show with an > asterisk in the RFC Editor's list at > http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt > > I see: > CSP > LSP > QoS > > --- > > Abstract and Introduction > > "IGP protocol" is bad because the "P" in "IGP" is "protocol". > > --- > > The RFC Editor prefers documents to have the Introduction as Section 1. > > You may prefer to make this change yourself, because it will possibly > cause some expansions of terms and acronyms that the RFC Editor might > so in a way you don't like. > > --- > > In section 1, the term "MT Topology" is odd because the "T" of "MT" > stands for "Topology". Surely you don't mean "Multi Topology Topology"? > > --- > > Section 3.1 > > s/infers/implies/ > > --- > > Section 3.2 > > I prefer that you don't repeat protocol encodings that are defined > elsewhere. This can cause nasty problems if you make a mistake or if > the original definition is updated. > > It is enough for you to write... > > The LDP base specification [RFC5036] (Section 4.1) defines the > "Prefix" FEC Element. The "Prefix" encoding is defined for a given > "Address Family" (AF), and has length (in bits) specified by the > "PreLen" field. > > To extend IP address families for MT, two new Address Families named > "MT IP" and "MT IPv6" are used to specify IPv4 and IPv6 prefixes > within a topology scope. > > --- > > Section 3.2 Figure 2 > > This figure gives the impression that both IPv4 and IPv6 addresses are > four bytes long! > > I think you need: > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ~ IP Address ~ > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Reserved | MT-ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 2: MT IP Address Family Format > > ...and... > > Where "IP Address" is a variable length field padded to a four octet > boundary and containing an IPv4 or IPv6 address/prefix for the "MT > IP" and "MT IPv6" AFs respectively. The field "MT-ID" corresponds to > the 16-bit Topology ID for given address. > > ...but you need to check I got that right! > > However, before doing this work, see my comment on Section 3.3 > > --- > > Section 3.2 > > The proposed FEC Elements with "MT IP" Address Family can be used in > > You are not proposing any more, you are defining! > > See also section 3.6, 3.8, 4.1, 4.3, and 8 > > --- > > Section 3.2 > > [RFC5036] does not specify the handling of "Unknown" Address > Families. Therefore, [RFC5036] will need to be updated to include > the handling procedure for unknown address families. > > Ouch! > > This had me really worried because it implied that you are breaking > existing LDP deployments. But I discussed it with Loa, and he pointed me > at Section 3.4.1.1 of RFC 5036 > > "If in decoding a FEC TLV an LSR encounters a FEC Element with an > Address Family it does not support, it SHOULD stop decoding the FEC > TLV, abort processing the message containing the TLV, and send an > "Unsupported Address Family" Notification message to its LDP peer > signaling an error. > > If it encounters a FEC Element type it cannot decode, it SHOULD stop > decoding the FEC TLV, abort processing the message containing the > TLV, and send an "Unknown FEC" Notification message to its LDP peer > signaling an error." > > So I think you can just delete this paragraph. > > Furthermore, Section 3.5 defines a capability advertisement that enables > you to know whether it is safe to use one of the new AFs. So surely you > should also say "MUST NOT send an MT AF unless the peer has said it can > handle it." > > See my re-write in the next comment. > > --- > > Section 3.3 appears to be repeating a lot of Section 3.2, but in a > better and more concise way. For example, Figure 3 nicely shows how the > Prefix FEC element works with the new AFs. > > This leads me to think that Section 3.2 could be reduced to just a few > lines that say... > > The LDP base specification [RFC5036] (Section 4.1) defines the > the use of an "Address Family" (AF) field in FEC Elements to indicate > the encoding of the "Prefix" or "Address" that follows, and to > indicate how the FEC should be interpreted. > > This document defines two new AF values named "MT IP" and "MT IPv6" > that are used to specify the use of IPv4 or IPv6 within a topology > scope. The data associated with these new AFs includes an "MT-ID" > field that carries the 16-bit Topology ID for a topology. > > The value of MT-ID=0 corresponds to default topology and MUST be > ignored on receipt so as to not cause any conflict/confusion with > existing non-MT procedures. > > FEC Elements with the new AFs can be used in any LDP message and > procedures that currently specify and allow the use of FEC Elements > with the IP or IPv6 AFs, but MUST NOT be used unless the peer has > indicated it can handle them as described in Section 3.5. Note that > behavior by an LDP speaker that receives a FEC element containing an > unknown AF is described in Section 3.4.1.1 of [RFC5036]. > > --- > > Section 3.4 is perfectly clear except it doesn't say what "reserved", > "special", and "translating" mean. > > This opens up a number of questions including why you need a registry > at all. Presumably the "translation" needed is to ensure that the > values used in LDP have the same meaning as they do in the IGP. If that > is the case, why not simply use exactly the same value? > > And looking at the registry further, it seems to say that only values > allocated by IANA and stored in the registry can be used. That means > that an operator that wants to use MT in their network cannot just > assign values to the MT-IDs for the topologies because the registry > has no space for this to happen. > > Now, it is possible that you have simply used the wrong words in the > registry in section 9, and failed to provide any explanation in the > text. Note that "unassigned" means "not yet assigned, but available > to be assigned by IANA". And "Reserved" means "Do not assign until > a new RFC defines how they should be used." > > But there are other questions: > > Why do you need 16 bits when ISIS has only 12 bits and OSPF only 8 bits? > I guess 16 is convenient to hold either, but how are the top 4 bits to > be handled? > > How do you handle the case where there are multiple instances of an IGP > (or different IGPs) running? > > If you *do* expect there to be a mapping function between IGP MT-ID and > LDP MT-ID, how do you ensure the same function is used at both ends of > an LDP session? > > But Section 3.8 really does seem to say that only MT-IDs in the registry > are allowed, which seems to make this I-D almost useless because you > have only defined "default" (which we have already), "ISIS IPv6", and > "all". Isn't an operator allowed to partition their network into > topologies? > > So... > > I think what you need in Section 9 is... > > o New registry "LDP Multi-Topology (MT) ID Name Space" under "LDP > Parameter" namespace. The allocation policies for this registry > are: > > Range Registration Policy > ------ ------------------- > 0-3995 Expert Review > 3996-4095 Private Use > 4096-4127 Expert Review > 4128-4255 Private Use > 4256-4351 Reserved (IANA does not assign) > 4352-4511 Expert Review > 4512-65535 Private Use > > IANA is requested to populate this registry as follows: > > > Range/Value Purpose Reference > ----------- ------------------------------------- --------- > 0 Default/standard topology in IS-IS [This.I-D] > 1 IPv4 in-band management in IS-IS [This.I-D] > 2 IPv6 routing topology in IS-IS [This.I-D] > 3 IPv4 multicast topology in IS-IS [This.I-D] > 4 IPv6 multicast topology in IS-IS [This.I-D] > 5 IPv6 in-band management in IS-IS [This.I-D] > 6-3995 Unassigned (intended to mirror IS-IS) > 3996-4095 Reserved for private use (from IS-IS) [This.I-D] > 4096 Default/standard topology in OSPF [This.I-D] > 4097 Default multicast topology in OSPF [This.I-D] > 4098 IPv4 in-band management in OSPF [This.I-D] > 4099-4127 Unassigned (intended to mirror OSPF) > 4128-4255 Reserved for private use (from OSPF) [This.I-D] > 4256-4351 Reserved (IANA does not assign) [This.I-D] > 4352-4511 Unassigned > 4512-65535 Reserved for Private Use [This.I-D] > > This would address many of the issues in Sections 3.4 and 3.8, and needs > to be discussed in those sections. > > --- > > In Section 3.5 > > o Length: The length (in octets) of TLV. > > Are you sure it is not just the length in octets of the value? > Compare with RFC 5036 Section 3.3 > > --- > > Sections 3.5 and 3.6 need to be more closely grouped. > > Suggest moving most of 3.5 into 3.5.1 and moving 3.6 into 3.5.2 > > --- > > Section 3.6 > > To announce its MT capability for an IP address family, LDP FEC type, > and Multi Topology, an LDP speaker MAY send an "MT Capability" > including the exact Typed Wildcard FEC element with corresponding > "AddressFamily" field (i.e., set to "MT IP" for IPv4 and set to "MT > IPv6" for IPv6 address family), corresponding "FEC Type" field (i.e., > set to "P2P", "P2MP", "MP2MP"), and corresponding "MT-ID". To > announce its MT capability for both IPv4 and IPv6 address family, or > for multiple FEC types, or for multiple Multi Topologies, an LDP > speaker MAY send "MT Capability" with one or more MT Typed FEC > elements in it. > > I don't think this is "MAY" in either case. This *is* how the LDP > speaker announces it. There is no other way to announce it. So... > > To announce its MT capability for an IP address family, LDP FEC type, > and Multi Topology, an LDP speaker sends an "MT Capability" including > the exact Typed Wildcard FEC element with corresponding > "AddressFamily" field (i.e., set to "MT IP" for IPv4 and set to "MT > IPv6" for IPv6 address family), corresponding "FEC Type" field (i.e., > set to "P2P", "P2MP", "MP2MP"), and corresponding "MT-ID". To > announce its MT capability for both IPv4 and IPv6 address family, or > for multiple FEC types, or for multiple Multi Topologies, an LDP > speaker sends "MT Capability" with one or more MT Typed FEC elements > in it. > > --- > > Section 3.6 > > o If an LSR has not advertised MT capability, its peer must not send > messages that include MT identifier to this LSR. > > Isn't that "MUST NOT"? > > --- > > Section 3.8 > > Certain MT topologies are assigned to serve predetermined purposes: > > It is not the topology that is assigned, but the MT-ID. Should read: > > Certain MT-ID values are assigned to indicate specific meanings: > > --- > > Section 3.8 > > It is not helpful to "propose" numbers in this section and then to > also reference Section 9 for the definitive numbers. I suggest you > remove all numbers from this section and simply point at Section 9. > > --- > > Section 4.2 > > This MAY allow an LDP speaker to signal its IP convergence... > > What does 2119 MAY mean in this context? > > --- > > Section 4.3 > > [RFC4379] defines procedures to detect data-plane failures in MPLS > LSPs via LSP ping. The specification defines a "Target FEC Stack" > TLV that describes the FEC stack being tested. > > Ha, ha! You got me :-) > s/The specification/That specification/ > > --- > > Section 4.3.1 > > Sub-Type Length Value Field > -------- ------ ----------------- > TBA5 5 MT LDP IPv4 prefix > TBA6 17 MT LDP IPv6 prefix > > Are you sure you don't mean 8 and 20? > > --- > > Section 4.3.4 > > When detect data plane failures using LSP Ping for a specific topoly, > the router will intiate an LSP Ping request with the targer FEC stack > > I think > > s/When/To/ > > s/topoly/topology/ > > s/intiate/initiate/ > > s/targer/target/ > > --- > > Section 4.3.4 > > For the case that the LSP ping with return path not specified , the > reply packet may go through the default topology instead of the > topology where the Echo Request goes through. > > Is that really "the default" or "any"? > If you mean "the default" then I think you need some "MUST NOT" text to > talk about other topologies. > > --- > > Section 5 > > The extensions defined in this document utilise the existing LDP > error handling defined in [RFC5036]. If an LSR receives an error > notification from a peer for an MPLS-MT session, it terminates the > LDP session by closing the TCP transport connection for the session > and discarding all MT-ID label mappings learned via the session. > > There is nothing wrong with this text, but it does open a question that > is not addressed anywhere in the document: what is the relationship > between LDP sessions and MT-IDs? 1:1, 1:n, n:1, n:m? > > This is somewhat assumable from the discussion of multiple MT-ID > wildcard FEC elements in the Multi-Topology Capability TLV, but it is > not explicit. > > --- > > Shouldn't Section 6 comment on how each of the new protocol elements > will not be seen by a legacy implementation because they are only used > after successful capability negotiation? > > But you do need to describe how a legacy node will react to attempted > MT capability negotiation. > > You could also restate the reference to RFC 5036 section 3.4.1.1 since > this issue seemed to be a question for you. > > --- > > I'm slightly doubtful about the value of Section 7, but I note that the > point you are trying to convey is not quite worded correctly. You have: > > and the specified > signaling mechanisms do not provide any way for the data plane to > associate a given packet with a context-specific label space. > > I don't think the signaling mechanism is relevant, and I think "context- > specific" hides what you are trying to say. Perhaps you should have: > > and there is no way > for the data plane to associate a received packet with any one > topology, meaning that topology-specific label spaces cannot be used. > > --- > > Section 9 > > o New Status Code: "Multi-Topology Capability not supported" > (requested code point: TBA2 from LDP registry "Status Code Name > Space"). > > This status code does not appear to be mentioned in the draft. How is > it used? Is an implementation that does not know the new MT Capability > TLV supposed to generate this status code? Or are you referencing an > existing error code: in which case it should not appear in this section. > > o New Status Code: "Unknown Address Family" (requested code point: > TBA4 from LDP registry "Status Code Name Space"). > > This status code does not appear to be mentioned in the draft. How is > it used? Is a legacy implementation that does not know either of your > new MT AFs supposed to generate this status code? But I suspect you are > just referencing an existing error code (see Section 3.2) as defined in > RFC 5036, and so you should not mention it in this section. > > Figure 10 does not show either of these status codes. > > --- > > Figure 10 shows a specific value for the new status code. Is this a > request or demand? I don't think it has already been allocated. > > --- > > Section 9 > > o New registry "LDP Multi-Topology (MT) ID Name Space" under "LDP > Parameter" namespace. > > This registry is discussed earlier in my notes. but please be aware that > you will need to define the allocation policy because it is a new > registry. > > --- > > Section 9 > > I want to ask Loa Andersson to look again at the LSP Ping TLV > allocations to check that they conform to the work he is currently > doing with that registry. > > --- > > It would help considerably to add a Manageability Considerations section > to this document because the function being added here is not simple to > manage or operate, and will have impact on the way that the network is > run. Good guidance on such sections can be found in RFC 5706. Appendix A > is particularly helpful at summarising things to consider. > > -------------------- > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > --047d7b10c83728dc4404dddada04 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Adrian & authors,

I have a= couple comments on the IANA registry and number overlapping.

First, it would be useful to have a range that is c= learly intended to be the same for OSPF, ISIS and LDP. =A0Given the
extremely limited range for OSPF multi-topology routing (ht= tp://www.iana.org/assignments/ospf-mt-routing/ospf-mt-routing.xml) of
3-127, it'd be very useful to have that range specifically s= et aside for cases where it matters that it be the same.=A0

One use that I see for this draft is for MRT, which i= s doing multi-topology forwarding but not multi-topology routing. =A0This m= eans
that the MT-IDs used do not need to overlap with those in OSPF o= r ISIS. =A0It would be good to ensure that there's a reasonable
range in LDP for such purposes. =A0LDP is one of the few mechanism= s that easily lends itself to multi-topology forwarding.

Alia

P= .S. =A0Having the same values for mLDP and PIM may also be very useful for = interworking. =A0PIM doesn't actually have an IANA
regi= stry for MT-ID and leaves the meaning of the values up to the network opera= tor.


On Wed,= May 29, 2013 at 2:18 AM, Adrian Farrel <adrian@olddog.co.uk> wrote:
Hi authors,

Thanks for this document.

I have done my usual AD review which is intended to catch any issues
that I see, and to smooth out the wrinkles before the I-D goes to IETF
last call and IESG review.

As you will see below, I have a number of editorial comments (nits and
larger changes) and also a few questions/issues.

The biggest issue concerns the MT-ID and spans sections 3.4, 3.8, and 9. I suggest you read the comments against those sections all together.
Note that in my comment for section 9, I think I have worked out what
you need to do, and so the resolution to the comments for 3.4 and 3.8
may simply be documenting this change to the IANA registry.

As usual, all my comments are up for discussion, so please don't feel you are required to make changes if you think there is a good reason why things are the way they are.

At the moment it looks like a new revision will be needed to address the review, so I have set the flag in the datatracker. Please work with your document shepherd to produce and post a new revision.

Thanks,
Adrian

=3D=3D=3D

The document seems to end with a spurious page header.

---

The index seems to be considerably adrift from reality.
In particular, there is no Appendix in this document.

---

Why do you say that this updates RFC 4379? Is it your belief that an
implementation of RFC 4379 will not be complete/conformant without these extensions? Or are you just defining extensions which an implementation
in an MPLS-MT environment will need to support?

I note that you (in my view, correctly) do not say that this document
updates RFC 5036, yet it defines extensions to LDP in a similar way.

---

Please expand all acronyms on first use unless they show with an
asterisk in the RFC Editor's list at
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansio= n.txt

I see:
CSP
LSP
QoS

---

Abstract and Introduction

"IGP protocol" is bad because the "P" in "IGP"= ; is "protocol".

---

The RFC Editor prefers documents to have the Introduction as Section 1.

You may prefer to make this change yourself, because it will possibly
cause some expansions of terms and acronyms that the RFC Editor might
so in a way you don't like.

---

In section 1, the term "MT Topology" is odd because the "T&q= uot; of "MT"
stands for "Topology". Surely you don't mean "Multi Topo= logy Topology"?

---

Section 3.1

s/infers/implies/

---

Section 3.2

I prefer that you don't repeat protocol encodings that are defined
elsewhere. This can cause nasty problems if you make a mistake or if
the original definition is updated.

It is enough for you to write...

=A0 =A0The LDP base specification [RFC5036] (Section 4.1) defines the
=A0 =A0"Prefix" FEC Element. =A0The "Prefix" encoding i= s defined for a given
=A0 =A0"Address Family" (AF), and has length (in bits) specified = by the
=A0 =A0"PreLen" field.

=A0 =A0To extend IP address families for MT, two new Address Families named=
=A0 =A0"MT IP" and "MT IPv6" are used to specify IPv4 a= nd IPv6 prefixes
=A0 =A0within a topology scope.

---

Section 3.2 Figure 2

This figure gives the impression that both IPv4 and IPv6 addresses are
four bytes long!

I think you need:

=A0 =A0 =A0 0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 1 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 3
=A0 =A0 =A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=
=A0 =A0 =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
=A0 =A0 =A0~ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 IP Address =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0~
=A0 =A0 =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +
=A0 =A0 =A0| =A0 =A0 =A0 =A0 =A0Reserved =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 = =A0 =A0MT-ID =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Figure 2: MT IP Address Family Forma= t

...and...

=A0 =A0Where "IP Address" is a variable length field padded to a = four octet
=A0 =A0boundary and containing an IPv4 or IPv6 address/prefix for the "= ;MT
=A0 =A0IP" and "MT IPv6" AFs respectively. =A0The field &quo= t;MT-ID" corresponds to
=A0 =A0the 16-bit Topology ID for given address.

...but you need to check I got that right!

However, before doing this work, see my comment on Section 3.3

---

Section 3.2

=A0 =A0The proposed FEC Elements with "MT IP" Address Family can = be used in

You are not proposing any more, you are defining!

See also section 3.6, 3.8, 4.1, 4.3, and 8

---

Section 3.2

=A0 =A0[RFC5036] does not specify the handling of "Unknown" Addre= ss
=A0 =A0Families. =A0Therefore, [RFC5036] will need to be updated to include=
=A0 =A0the handling procedure for unknown address families.

Ouch!

This had me really worried because it implied that you are breaking
existing LDP deployments. But I discussed it with Loa, and he pointed me at Section 3.4.1.1 of RFC 5036

=A0 =A0"If in decoding a FEC TLV an LSR encounters a FEC Element with = an
=A0 =A0 Address Family it does not support, it SHOULD stop decoding the FEC=
=A0 =A0 TLV, abort processing the message containing the TLV, and send an =A0 =A0 "Unsupported Address Family" Notification message to its = LDP peer
=A0 =A0 signaling an error.

=A0 =A0 If it encounters a FEC Element type it cannot decode, it SHOULD sto= p
=A0 =A0 decoding the FEC TLV, abort processing the message containing the =A0 =A0 TLV, and send an "Unknown FEC" Notification message to it= s LDP peer
=A0 =A0 signaling an error."

So I think you can just delete this paragraph.

Furthermore, Section 3.5 defines a capability advertisement that enables you to know whether it is safe to use one of the new AFs. =A0So surely you<= br> should also say "MUST NOT send an MT AF unless the peer has said it ca= n
handle it."

See my re-write in the next comment.

---

Section 3.3 appears to be repeating a lot of Section 3.2, but in a
better and more concise way. For example, Figure 3 nicely shows how the
Prefix FEC element works with the new AFs.

This leads me to think that Section 3.2 could be reduced to just a few
lines that say...

=A0 =A0The LDP base specification [RFC5036] (Section 4.1) defines the
=A0 =A0the use of an "Address Family" (AF) field in FEC Elements = to indicate
=A0 =A0the encoding of the "Prefix" or "Address" that f= ollows, and to
=A0 =A0indicate how the FEC should be interpreted.

=A0 =A0This document defines two new AF values named "MT IP" and = "MT IPv6"
=A0 =A0that are used to specify the use of IPv4 or IPv6 within a topology =A0 =A0scope. =A0The data associated with these new AFs includes an "M= T-ID"
=A0 =A0field that carries the 16-bit Topology ID for a topology.

=A0 =A0The value of MT-ID=3D0 corresponds to default topology and MUST be =A0 =A0ignored on receipt so as to not cause any conflict/confusion with =A0 =A0existing non-MT procedures.

=A0 =A0FEC Elements with the new AFs can be used in any LDP message and
=A0 =A0procedures that currently specify and allow the use of FEC Elements<= br> =A0 =A0with the IP or IPv6 AFs, but MUST NOT be used unless the peer has =A0 =A0indicated it can handle them as described in Section 3.5. =A0Note th= at
=A0 =A0behavior by an LDP speaker that receives a FEC element containing an=
=A0 =A0unknown AF is described in Section 3.4.1.1 of [RFC5036].

---

Section 3.4 is perfectly clear except it doesn't say what "reserve= d",
"special", and "translating" mean.

This opens up a number of questions including why you need a registry
at all. =A0Presumably the "translation" needed is to ensure that = the
values used in LDP have the same meaning as they do in the IGP. If that
is the case, why not simply use exactly the same value?

And looking at the registry further, it seems to say that only values
allocated by IANA and stored in the registry can be used. That means
that an operator that wants to use MT in their network cannot just
assign values to the MT-IDs for the topologies because the registry
has no space for this to happen.

Now, it is possible that you have simply used the wrong words in the
registry in section 9, and failed to provide any explanation in the
text. =A0Note that "unassigned" means "not yet assigned, but= available
to be assigned by IANA". =A0And "Reserved" means "Do no= t assign until
a new RFC defines how they should be used."

But there are other questions:

Why do you need 16 bits when ISIS has only 12 bits and OSPF only 8 bits? I guess 16 is convenient to hold either, but how are the top 4 bits to
be handled?

How do you handle the case where there are multiple instances of an IGP
(or different IGPs) running?

If you *do* expect there to be a mapping function between IGP MT-ID and
LDP MT-ID, how do you ensure the same function is used at both ends of
an LDP session?

But Section 3.8 really does seem to say that only MT-IDs in the registry are allowed, which seems to make this I-D almost useless because you
have only defined "default" (which we have already), "ISIS I= Pv6", and
"all". Isn't an operator allowed to partition their network i= nto
topologies?

So...

I think what you need in Section 9 is...

=A0 =A0o =A0New registry "LDP Multi-Topology (MT) ID Name Space" = under "LDP
=A0 =A0 =A0 Parameter" namespace. =A0The allocation policies for this = registry
=A0 =A0 =A0 are:

=A0 =A0 =A0 Range =A0 =A0 =A0 =A0 =A0 Registration Policy
=A0 =A0 =A0 ------ =A0 =A0 =A0 =A0 =A0-------------------
=A0 =A0 =A0 0-3995 =A0 =A0 =A0 =A0 =A0Expert Review
=A0 =A0 =A0 3996-4095 =A0 =A0 =A0 Private Use
=A0 =A0 =A0 4096-4127 =A0 =A0 =A0 Expert Review
=A0 =A0 =A0 4128-4255 =A0 =A0 =A0 Private Use
=A0 =A0 =A0 4256-4351 =A0 =A0 =A0 Reserved (IANA does not assign)
=A0 =A0 =A0 4352-4511 =A0 =A0 =A0 Expert Review
=A0 =A0 =A0 4512-65535 =A0 =A0 =A0Private Use

=A0 =A0 =A0 IANA is requested to populate this registry as follows:


=A0 =A0 =A0 Range/Value =A0 =A0Purpose =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 Reference
=A0 =A0 =A0 ----------- =A0 =A0------------------------------------- =A0 --= -------
=A0 =A0 =A0 0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Default/standard topology in IS-IS= =A0 =A0 =A0[This.I-D]
=A0 =A0 =A0 1 =A0 =A0 =A0 =A0 =A0 =A0 =A0IPv4 in-band management in IS-IS = =A0 =A0 =A0 =A0[This.I-D]
=A0 =A0 =A0 2 =A0 =A0 =A0 =A0 =A0 =A0 =A0IPv6 routing topology in IS-IS =A0= =A0 =A0 =A0 =A0[This.I-D]
=A0 =A0 =A0 3 =A0 =A0 =A0 =A0 =A0 =A0 =A0IPv4 multicast topology in IS-IS = =A0 =A0 =A0 =A0[This.I-D]
=A0 =A0 =A0 4 =A0 =A0 =A0 =A0 =A0 =A0 =A0IPv6 multicast topology in IS-IS = =A0 =A0 =A0 =A0[This.I-D]
=A0 =A0 =A0 5 =A0 =A0 =A0 =A0 =A0 =A0 =A0IPv6 in-band management in IS-IS = =A0 =A0 =A0 =A0[This.I-D]
=A0 =A0 =A0 6-3995 =A0 =A0 =A0 =A0 Unassigned (intended to mirror IS-IS) =A0 =A0 =A0 3996-4095 =A0 =A0 =A0Reserved for private use (from IS-IS) =A0 = [This.I-D]
=A0 =A0 =A0 4096 =A0 =A0 =A0 =A0 =A0 Default/standard topology in OSPF =A0 = =A0 =A0 [This.I-D]
=A0 =A0 =A0 4097 =A0 =A0 =A0 =A0 =A0 Default multicast topology in OSPF =A0= =A0 =A0[This.I-D]
=A0 =A0 =A0 4098 =A0 =A0 =A0 =A0 =A0 IPv4 in-band management in OSPF =A0 = =A0 =A0 =A0 [This.I-D]
=A0 =A0 =A0 4099-4127 =A0 =A0 =A0Unassigned (intended to mirror OSPF)
=A0 =A0 =A0 4128-4255 =A0 =A0 =A0Reserved for private use (from OSPF) =A0 = =A0[This.I-D]
=A0 =A0 =A0 4256-4351 =A0 =A0 =A0Reserved (IANA does not assign) =A0 =A0 = =A0 =A0 [This.I-D]
=A0 =A0 =A0 4352-4511 =A0 =A0 =A0Unassigned
=A0 =A0 =A0 4512-65535 =A0 =A0 Reserved for Private Use =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0[This.I-D]

This would address many of the issues in Sections 3.4 and 3.8, and needs to be discussed in those sections.

---

In Section 3.5

=A0 =A0o =A0Length: The length (in octets) of TLV.

Are you sure it is not just the length in octets of the value?
Compare with RFC 5036 Section 3.3

---

Sections 3.5 and 3.6 need to be more closely grouped.

Suggest moving most of 3.5 into 3.5.1 and moving 3.6 into 3.5.2

---

Section 3.6

=A0 =A0To announce its MT capability for an IP address family, LDP FEC type= ,
=A0 =A0and Multi Topology, an LDP speaker MAY send an "MT Capability&q= uot;
=A0 =A0including the exact Typed Wildcard FEC element with corresponding =A0 =A0"AddressFamily" field (i.e., set to "MT IP" for = IPv4 and set to "MT
=A0 =A0IPv6" for IPv6 address family), corresponding "FEC Type&qu= ot; field (i.e.,
=A0 =A0set to "P2P", "P2MP", "MP2MP"), and co= rresponding "MT-ID". =A0To
=A0 =A0announce its MT capability for both IPv4 and IPv6 address family, or=
=A0 =A0for multiple FEC types, or for multiple Multi Topologies, an LDP
=A0 =A0speaker MAY send "MT Capability" with one or more MT Typed= FEC
=A0 =A0elements in it.

I don't think this is "MAY" in either case. This *is* how the= LDP
speaker announces it. There is no other way to announce it. So...

=A0 =A0To announce its MT capability for an IP address family, LDP FEC type= ,
=A0 =A0and Multi Topology, an LDP speaker sends an "MT Capability"= ; including
=A0 =A0the exact Typed Wildcard FEC element with corresponding
=A0 =A0"AddressFamily" field (i.e., set to "MT IP" for = IPv4 and set to "MT
=A0 =A0IPv6" for IPv6 address family), corresponding "FEC Type&qu= ot; field (i.e.,
=A0 =A0set to "P2P", "P2MP", "MP2MP"), and co= rresponding "MT-ID". =A0To
=A0 =A0announce its MT capability for both IPv4 and IPv6 address family, or=
=A0 =A0for multiple FEC types, or for multiple Multi Topologies, an LDP
=A0 =A0speaker sends "MT Capability" with one or more MT Typed FE= C elements
=A0 =A0in it.

---

Section 3.6

=A0 =A0o =A0If an LSR has not advertised MT capability, its peer must not s= end
=A0 =A0 =A0 messages that include MT identifier to this LSR.

Isn't that "MUST NOT"?

---

Section 3.8

=A0 =A0Certain MT topologies are assigned to serve predetermined purposes:<= br>
It is not the topology that is assigned, but the MT-ID. Should read:

=A0 =A0Certain MT-ID values are assigned to indicate specific meanings:

---

Section 3.8

It is not helpful to "propose" numbers in this section and then t= o
also reference Section 9 for the definitive numbers. =A0I suggest you
remove all numbers from this section and simply point at Section 9.

---

Section 4.2

=A0 =A0This MAY allow an LDP speaker to signal its IP convergence...

What does 2119 MAY mean in this context?

---

Section 4.3

=A0 =A0[RFC4379] defines procedures to detect data-plane failures in MPLS =A0 =A0LSPs via LSP ping. =A0The specification defines a "Target FEC S= tack"
=A0 =A0TLV that describes the FEC stack being tested.

Ha, ha! You got me :-)
s/The specification/That specification/

---

Section 4.3.1

=A0 =A0 =A0 =A0 =A0Sub-Type =A0 =A0 =A0 Length =A0 =A0 =A0 =A0 =A0 =A0Value= Field
=A0 =A0 =A0 =A0 =A0-------- =A0 =A0 =A0 ------ =A0 =A0 =A0 =A0 =A0 =A0-----= ------------
=A0 =A0 =A0 =A0 =A0 =A0 =A0TBA5 =A0 =A0 =A0 =A0 =A0 =A05 =A0 =A0 =A0 =A0 = =A0 =A0MT LDP IPv4 prefix
=A0 =A0 =A0 =A0 =A0 =A0 =A0TBA6 =A0 =A0 =A0 =A0 =A0 17 =A0 =A0 =A0 =A0 =A0 = =A0MT LDP IPv6 prefix

Are you sure you don't mean 8 and 20?

---

Section 4.3.4

=A0 =A0When detect data plane failures using LSP Ping for a specific topoly= ,
=A0 =A0the router will intiate an LSP Ping request with the targer FEC stac= k

I think

s/When/To/

s/topoly/topology/

s/intiate/initiate/

s/targer/target/

---

Section 4.3.4

=A0 =A0For the case that the LSP ping with return path not specified , the<= br> =A0 =A0reply packet may go through the default topology instead of the
=A0 =A0topology where the Echo Request goes through.

Is that really "the default" or "any"?
If you mean "the default" then I think you need some "MUST N= OT" text to
talk about other topologies.

---

Section 5

=A0 =A0The extensions defined in this document utilise the existing LDP
=A0 =A0error handling defined in [RFC5036]. =A0If an LSR receives an error<= br> =A0 =A0notification from a peer for an MPLS-MT session, it terminates the =A0 =A0LDP session by closing the TCP transport connection for the session<= br> =A0 =A0and discarding all MT-ID label mappings learned via the session.

There is nothing wrong with this text, but it does open a question that
is not addressed anywhere in the document: what is the relationship
between LDP sessions and MT-IDs? =A01:1, 1:n, n:1, n:m?

This is somewhat assumable from the discussion of multiple MT-ID
wildcard FEC elements in the Multi-Topology Capability TLV, but it is
not explicit.

---

Shouldn't Section 6 comment on how each of the new protocol elements will not be seen by a legacy implementation because they are only used
after successful capability negotiation?

But you do need to describe how a legacy node will react to attempted
MT capability negotiation.

You could also restate the reference to RFC 5036 section 3.4.1.1 since
this issue seemed to be a question for you.

---

I'm slightly doubtful about the value of Section 7, but I note that the=
point you are trying to convey is not quite worded correctly. You have:

=A0 =A0and the specified
=A0 =A0signaling mechanisms do not provide any way for the data plane to =A0 =A0associate a given packet with a context-specific label space.

I don't think the signaling mechanism is relevant, and I think "co= ntext-
specific" hides what you are trying to say. =A0Perhaps you should have= :

=A0 =A0and there is no way
=A0 =A0for the data plane to associate a received packet with any one
=A0 =A0topology, meaning that topology-specific label spaces cannot be used= .

---

Section 9

=A0 =A0o =A0New Status Code: "Multi-Topology Capability not supported&= quot;
=A0 =A0 =A0 (requested code point: TBA2 from LDP registry "Status Code= Name
=A0 =A0 =A0 Space").

This status code does not appear to be mentioned in the draft. How is
it used? Is an implementation that does not know the new MT Capability
TLV supposed to generate this status code? Or are you referencing an
existing error code: in which case it should not appear in this section.
=A0 =A0o =A0New Status Code: "Unknown Address Family" (requested = code point:
=A0 =A0 =A0 TBA4 from LDP registry "Status Code Name Space").

This status code does not appear to be mentioned in the draft. How is
it used? Is a legacy implementation that does not know either of your
new MT AFs supposed to generate this status code? But I suspect you are
just referencing an existing error code (see Section 3.2) as defined in
RFC 5036, and so you should not mention it in this section.

Figure 10 does not show either of these status codes.

---

Figure 10 shows a specific value for the new status code. Is this a
request or demand? I don't think it has already been allocated.

---

Section 9

=A0 =A0o =A0New registry "LDP Multi-Topology (MT) ID Name Space" = under "LDP
=A0 =A0 =A0 Parameter" namespace.

This registry is discussed earlier in my notes. but please be aware that you will need to define the allocation policy because it is a new
registry.

---

Section 9

I want to ask Loa Andersson to look again at the LSP Ping TLV
allocations to check that they conform to the work he is currently
doing with that registry.

---

It would help considerably to add a Manageability Considerations section to this document because the function being added here is not simple to
manage or operate, and will have impact on the way that the network is
run. Good guidance on such sections can be found in RFC 5706. Appendix A is particularly helpful at summarising things to consider.

--------------------

_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--047d7b10c83728dc4404dddada04-- From swallow@cisco.com Wed May 29 06:01:44 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7104721F8EEC for ; Wed, 29 May 2013 06:01:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v87GCBEDqYKD for ; Wed, 29 May 2013 06:01:39 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 62FFE21F8EAE for ; Wed, 29 May 2013 06:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=36531; q=dns/txt; s=iport; t=1369832495; x=1371042095; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fLE7ZqGwlXX0x5PgkFhoBCzywgP8WMPHW7zQcPZFz2c=; b=WPDbRIqxng4U4TUGd3JPVXvpTJt8qYd4VO9bjfCFvDnSk5gHjQHCpYNU 5ifT/JNC6O83mSwKhn69S3RnDBihVvNJBnn2kJ/+rMcRaoZP2IP68mDMi R5RCxJsOMBkgrnDI42+GJMDSk9mjoD5cO9moorGeJEnSKTJkJRBqGZ0m5 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkMHANP5pVGtJXHB/2dsb2JhbABQCoJFRDDBe4EKFnSCIwEBAQQBAQEqQQsQAgEIEQQBASEBBgcmAQsUCQgCBA4EAYgNDLo/BI1ZgTgEBgGCc2EDlzuRQIMPgWok X-IronPort-AV: E=Sophos;i="4.87,764,1363132800"; d="scan'208,217";a="216020208" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-1.cisco.com with ESMTP; 29 May 2013 13:01:34 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r4TD1Y1F027949 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 29 May 2013 13:01:34 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Wed, 29 May 2013 08:01:34 -0500 From: "George Swallow (swallow)" To: Mach Chen Thread-Topic: [mpls] Meaning of sub-TLVs for TLV 21 in Return Path Specified Thread-Index: AQHOXGykGpY9jq0QSUO56/n0VHihOA== Date: Wed, 29 May 2013 13:01:32 +0000 Message-ID: References: <2FE467D3673DCE409A84D67EC2F607BB0FA82512@xmb-rcd-x10.cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_CE63D806CA694C839EC8739D84FFE281ciscocom_" MIME-Version: 1.0 Cc: "mpls@ietf.org" , "draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org" Subject: Re: [mpls] Meaning of sub-TLVs for TLV 21 in Return Path Specified X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 13:01:44 -0000 --_000_CE63D806CA694C839EC8739D84FFE281ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Mach - Sorry for the delay. So you have two different uses for one tlv. That in itself is not all that = bad. But apparently what you have is two uses where; 1. The semantics of the sub-tlvs change completely depending on which way y= ou are you are using the tlv. 2. The allowable sub-tlvs vary with the usage of the tlv. Further, on re-reading the draft these two uses are not clearly delineated. It would be a much better protocol design to have two tlvs. In what you cal= l case 2 below, the Tlv could reuse the sub-tlvs of tlv 1. In what you call= case one, the sub-tlvs would go into a registry specific to the tlv for ca= se 1. This would list only those sub-tlvs of tlv 1 that are valid for this= case. By list I mean explicitly list (not reference). It would also list = the new tlvs you have defined. George On May 22, 2013, at 1:39 AM, "Mach Chen" > wrote: Hi George, I guess your question is that why TLV 21 have to apply all the sub-TLVs of = TLV 1. For TLV 21, there are at least two usages, one is for specifying the return= path of the echo reply, and if just for specifying the return path of echo= reply, yes, it may not necessary to use all sub-TLVs of TLV 1. The other i= s for testing and validating the specified return path by carrying TLV 21( = just as the FEC Stack TLV for forward path). For usage 2, the TLV 21 should= have the same semantics as TLV 1, thus applying all sub-TLVs of TLV 1 is r= easonable. Many thanks, Mach From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of George Swallow (swallow) Sent: Wednesday, May 22, 2013 12:23 AM To: draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org Cc: mpls@ietf.org Subject: [mpls] Meaning of sub-TLVs for TLV 21 in Return Path Specified Mach, et al. - In section 4.1. Sending an Echo Request, it is stated: The Reply Path TLV includes one or several reply path sub-TLV(s) to identify the return path(s) the egress LSR should use for its reply. It would appear that the semantics of TLV 21 are very different than the se= mantics of TLV 1. Since TLV 1 defines a FEC stack which maps to a single L= SP. Why do you want the NIL FEC which only makes sense as part of a FEC st= ack? Under what circumstances would you ever use one of the multicast FECs (sub-= TLVs 17, 18, 19, 20)? What is the meaning of a return path to a VPN IPv4 prefix, or VPN IPv6 pre= fix? Note that if the prefix is multi-homed it may not even return to the = originating PE! What is the meaning of a return path to an L2 VPN endpoint? George _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_CE63D806CA694C839EC8739D84FFE281ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Mach -

Sorry for the delay.  

So you have two different uses for one tlv. That in itself is not all = that bad. But apparently what you have is two uses where;

1. The semantics of the sub-tlvs change completely depending on which = way you are you are using the tlv. 

2. The allowable sub-tlvs vary with the usage of the tlv. 

Further, on re-reading the draft these two uses are not clearly deline= ated. 

It would be a much better protocol design to have two tlvs. In what yo= u call case 2 below, the Tlv could reuse the sub-tlvs of tlv 1. In what you= call case one, the sub-tlvs would go into a registry specific to the tlv f= or case 1.  This would list only those sub-tlvs of tlv 1 that are valid for this case.  By list I mean= explicitly list (not reference). It would also list the new tlvs you have = defined. 

George

On May 22, 2013, at 1:39 AM, "Mach Chen" <mach.chen@huawei.com> wrote:

= Hi George,

=  

= I guess your question is that why TLV 21 have to apply all the sub-TLVs of TLV 1.

=  

= For TLV 21, there are at least tw= o usages, one is for specifying the return path of the echo reply, and if ju= st for specifying the return path of echo reply, yes, it may not necessary = to use all sub-TLVs of TLV 1. The other is for testing and validating the s= pecified return path by carrying TLV 21( just as the FEC Stack TLV for forward path). For usage 2, the TLV = 21 should have the same semantics as TLV 1, thus applying all sub-TLVs of T= LV 1 is reasonable.

=  

= Many thanks,

= Mach

=  

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of George Swallow = (swallow)
Sent: Wednesday, May 22, 201= 3 12:23 AM
To: draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org
Cc: mpls@ietf.org
Subject: [mpls] Meaning of s= ub-TLVs for TLV 21 in Return Path Specified

 

Mach, et al. -

 

In section 4.1. Sending an Echo Request, it is stated:

The Reply Path T=
LV includes one or several reply path sub-TLV(s) to
identify the ret=
urn path(s) the egress LSR should use for its reply.
It would=
 appear that the semantics of TLV 21 are very different than the semantics =
of TLV 1.  Since TLV 1 defines=
 a FEC stack which maps to a single LSP.&n=
bsp; Why do you want the NIL FEC which only makes sense as part of a=
 FEC stack?
Under wh=
at circumstances would you ever use one of the multicast FECs (sub-TLVs 17,=
 18, 19, 20)?
What is =
the meaning of a return path to a VPN IPv4 prefix, or  VPN IPv6 prefix?&=
nbsp; Note that if the prefix is multi-homed it may not even return =
to the originating PE!=

What is =
the meaning of a return path to an L2 VPN endpoint?
George
_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ie= tf.org/mailman/listinfo/mpls
--_000_CE63D806CA694C839EC8739D84FFE281ciscocom_-- From loa@pi.nu Wed May 29 06:31:40 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E94D21F90C6 for ; Wed, 29 May 2013 06:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.748 X-Spam-Level: X-Spam-Status: No, score=-100.748 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, J_CHICKENPOX_15=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0pRs-yqPrFV for ; Wed, 29 May 2013 06:31:29 -0700 (PDT) Received: from pipi.pi.nu (unknown [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 3656F21F909A for ; Wed, 29 May 2013 06:31:21 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id E1C731800272; Wed, 29 May 2013 15:31:19 +0200 (CEST) Message-ID: <51A60327.1060108@pi.nu> Date: Wed, 29 May 2013 15:31:19 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "t.petch" References: <51839D5B.5090108@pi.nu> <5183EAEF.8020100@pi.nu> <011001ce5bb3$3cd21e80$4001a8c0@gateway.2wire.net> In-Reply-To: <011001ce5bb3$3cd21e80$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org Subject: Re: [mpls] IANA section of draft-ietf-mpls-ldp-ip-pw-capability X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 13:31:40 -0000 Tom, thanks - I think this spelling error is mine, and it is far from my worst. As I said in an earlier mail we have made we have made certain changes to the structure of the IANA registry and this will have an impact on this IANA section. I will work with the authors to fix that. /Loa On 2013-05-28 16:51, t.petch wrote: > ---- Original Message ----- > From: "Loa Andersson" > To: ; > ; "Martin Vigoureux" > > Sent: Friday, May 03, 2013 5:50 PM > >> Folks, >> >> I would like to amend my proposal to say: >> >> 8. IANA Considerations >> >> This document defines a new LDP cpability parameter TLV. IANA is >> requested to assign the lowest available value after 0x0500 from >> "TLV Type Name Space" in the "Label Distribution Protocol (LDP) >> Parameters" registry within "Label Distribution Protocol (LDP) >> Name Spaces" as the new code point for the LDP TLV code point . > > I note that -05 has included this text verbatim. I would suggest > > /LDP cpability parameter/LDP capability parameter/ > if and when a revision is needed, else one for the RFC Editor. > > Tom Petch > >> >> Range | Description | Reference | Notes/Registration > Date >> -------+---------------------+---------------+------------------------ > --- >> tbd | Application Control | This document | >> | Capability | | >> -------+---------------------+---------------+------------------------ > --- >> >> >> /Loa >> >> On 2013-05-03 13:19, Loa Andersson wrote: >>> Authors, >>> >>> >>> I should have done this before, IANA sections is always tricky >>> and need to be precise, >>> >>> The IANA section of draft-ietf-mpls-ldp-ip-pw-capability-03.txt >>> says: >>> >>> "8. IANA Considerations >>> >>> The document defines a new capability parameter TLV and requests >>> following LDP TLV code point assignment by IANA from LDP "TLV > Type >>> Name Space" registry: >>> >>> o "Application Control Capability" TLV (requested codepoint: > 0x50C)" >>> >>> This is basically correct, but a few details need to be >>> added. I would like to have it re-written as: >>> >>> 8. IANA Considerations >>> >>> This document defines a new LDP cpability parameter. IANA is >>> requested to assign a new LDP TLV code point from "TLV Type >>> Name Space" in the "Label Distribution Protocol (LDP) > Parameters" >>> registry within "Label Distribution Protocol (LDP) Name Spaces". >>> >>> Range | Description | Reference | Notes/Registration > Date >> >> ------+---------------------+---------------+------------------------- > -- >>> tbd | Application Control | This document | >>> | Capability | | >> >> ------+---------------------+---------------+------------------------- > -- >>> >>> >>> >>> Note 1: That naming structure is not good, I will talk to IANA to > change it >>> to something more intuitive. >>> >>> Note 2: "Range" is really "Value" or "Type", will check on the > defining >>> documents and talk to IANA to change it. >> >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 >> _______________________________________________ > > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From rcallon@juniper.net Wed May 29 13:24:11 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 695BE21F9789 for ; Wed, 29 May 2013 13:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=-1.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkFrJG85KX8l for ; Wed, 29 May 2013 13:24:04 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 666D621F9780 for ; Wed, 29 May 2013 13:24:04 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKUaZj2o2j1rw7TuwANVwmjwZcHDHyw+c1@postini.com; Wed, 29 May 2013 13:24:04 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 29 May 2013 13:19:51 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Wed, 29 May 2013 13:19:51 -0700 Received: from ch1outboundpool.messaging.microsoft.com (216.32.181.185) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Wed, 29 May 2013 13:23:13 -0700 Received: from mail156-ch1-R.bigfish.com (10.43.68.246) by CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id 14.1.225.23; Wed, 29 May 2013 20:19:50 +0000 Received: from mail156-ch1 (localhost [127.0.0.1]) by mail156-ch1-R.bigfish.com (Postfix) with ESMTP id 451FB601D8 for ; Wed, 29 May 2013 20:19:50 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); (null); H:CH1PRD0510HT003.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -20 X-BigFish: PS-20(zzc85fhzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL18c673h182cceh8275dhz31h2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1155h) Received-SPF: softfail (mail156-ch1: transitioning domain of juniper.net does not designate 157.56.244.213 as permitted sender) client-ip=157.56.244.213; envelope-from=rcallon@juniper.net; helo=CH1PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail156-ch1 (localhost.localdomain [127.0.0.1]) by mail156-ch1 (MessageSwitch) id 1369858787515134_11300; Wed, 29 May 2013 20:19:47 +0000 (UTC) Received: from CH1EHSMHS015.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.250]) by mail156-ch1.bigfish.com (Postfix) with ESMTP id 7B5503200AD; Wed, 29 May 2013 20:19:47 +0000 (UTC) Received: from CH1PRD0510HT003.namprd05.prod.outlook.com (157.56.244.213) by CH1EHSMHS015.bigfish.com (10.43.70.15) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 29 May 2013 20:19:46 +0000 Received: from CH1PRD0510MB355.namprd05.prod.outlook.com ([169.254.2.210]) by CH1PRD0510HT003.namprd05.prod.outlook.com ([10.255.150.38]) with mapi id 14.16.0311.000; Wed, 29 May 2013 20:19:46 +0000 From: Ross Callon To: "mpls@ietf.org" Thread-Topic: MPLS WG last call on draft-kompella-mpls-special-purpose-labels-04 Thread-Index: Ac5cqdtvgJ8flknDSPCwCyMkaO79tg== Date: Wed, 29 May 2013 20:19:44 +0000 Message-ID: <62CCD4C52ACDAD4481149BD5D8A72FD316C76D83@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: multipart/alternative; boundary="_000_62CCD4C52ACDAD4481149BD5D8A72FD316C76D83CH1PRD0510MB355_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ALCATEL-LUCENT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "draft-kompella-mpls-special-purpose-labels@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: [mpls] MPLS WG last call on draft-kompella-mpls-special-purpose-labels-04 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 20:24:11 -0000 --_000_62CCD4C52ACDAD4481149BD5D8A72FD316C76D83CH1PRD0510MB355_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Working Group, this is to start a two week Working Group last call on draft-kompella-mpls-special-purpose-labels-04. Please send your comments to the mpls working group mailing list (mpls@ietf.org). Please send both technical comments, and (if you are happy with the document as is) also send indications of support. There are no IPR claims against this draft. The co-authors have earlier stated that they are not aware of any IPR applicable to this draft. If anyone else in the working group are aware of IPRs claims against this draft, the time to disclose that is now. This working group last call will end on June 13, 2013. Ross for the wg co-chairs --_000_62CCD4C52ACDAD4481149BD5D8A72FD316C76D83CH1PRD0510MB355_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Working Group,
 
this is to start a two week Working Group last call on
draft-kompella-mpls-special-purpose-labels-04.
 
Please send your comments to the mpls working group
If anyone else in the working group are aware of IPRs claims against
this draft, the time to disclose that is now.
 
This working group last call will end on June 13, 2013.
 
Ross
for the wg co-chairs
 
&nbs= p;
&nbs= p;
 --_000_62CCD4C52ACDAD4481149BD5D8A72FD316C76D83CH1PRD0510MB355_-- From venkatflex@gmail.com Wed May 29 16:49:38 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C714021F962C for ; Wed, 29 May 2013 16:49:38 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cEf0IIpSttmm for ; Wed, 29 May 2013 16:49:38 -0700 (PDT) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 15B6C21F962A for ; Wed, 29 May 2013 16:49:38 -0700 (PDT) Received: by mail-pb0-f51.google.com with SMTP id jt11so9977281pbb.10 for ; Wed, 29 May 2013 16:49:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=BBiSUwI+wuIVp9FYGo9Ip+/rgbxoA2K3YKArQkOVkIA=; b=QjuOt7pC+U4rBnLUsZeHPkpCoz2lS9AZTx1cIFvb4EC37FVPs0XX9Dozd5mDiEZU2U swLav7Sqh28/Es8HhjoYitTXwdmhk6SU+LUwvIMQjYxt8LbsXHrlJT7B+w6k2QS9XHZy 5zEOoALt16o+m7KYbK086MOq/pKlr+QxUoPFgqf9nau7pHZKKl5UIalq7kXTcXiArMi9 ILq7U+ZlDC5/zIOgIQz91+jmad95c3crtuSLCmkAgYI+Z5RGJqIgSyAD1kowKhALNfaE AiNiSMAaJwoLTnM3k04U2u2/MTV3p0pJ0F61c+2ANTEIzGzEvVT5YolRfQmxSdrQbe9j yJuw== X-Received: by 10.66.150.226 with SMTP id ul2mr5803741pab.17.1369871375013; Wed, 29 May 2013 16:49:35 -0700 (PDT) Received: from [10.11.81.106] (64-186-164-204.static-ip.telepacific.net. [64.186.164.204]) by mx.google.com with ESMTPSA id ov2sm39095734pbc.34.2013.05.29.16.49.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 29 May 2013 16:49:33 -0700 (PDT) References: <51951C17.8010906@pi.nu> Mime-Version: 1.0 (1.0) In-Reply-To: <51951C17.8010906@pi.nu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <16128973-1B99-405A-9794-5E5FEDAB3AA2@gmail.com> X-Mailer: iPhone Mail (10B350) From: Venkat Date: Wed, 29 May 2013 16:49:34 -0700 To: Loa Andersson Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-jjb-mpls-rsvp-te-hsmp-lsp@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus to make draft-jjb-mpls-rsvp-te-hsmp-lsp an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 May 2013 23:49:38 -0000 Yes/Support Sent from my iPhone On May 16, 2013, at 10:49 AM, Loa Andersson wrote: > Working Group, > > This is to start a two week poll on adopting > draft-jjb-mpls-rsvp-te-hsmp-lsp-04 as an MPLS working > group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (mpls@ietf.org). Please give a technical > motivation for your support/not support, especially if you think that > the document should not be adopted as a working group document. > > This poll ends May 31, 2013. > > There are one IPR claim against this document, see IPR claim #1840. > > The authors has stated on the working group mailing list > that they are not aware of any other IPR claims against this draft. > However if you are on the the mpls working group mailing list and > aware of IPR that relates to this draft, the time to disclose > this is now. > > /Loa > (mpls wg co-chair) > -- > > > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From xuxiaohu@huawei.com Wed May 29 20:07:56 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 775EF11E80A4 for ; Wed, 29 May 2013 20:07:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.45 X-Spam-Level: ** X-Spam-Status: No, score=2.45 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BwbQyYQNzYu8 for ; Wed, 29 May 2013 20:07:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 714C721F8F11 for ; Wed, 29 May 2013 20:07:50 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATH64561; Thu, 30 May 2013 03:07:48 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 30 May 2013 04:07:14 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 30 May 2013 04:07:46 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.134]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.01.0323.007; Thu, 30 May 2013 11:07:41 +0800 From: Xuxiaohu To: MPLS WG Mailing List Thread-Topic: MPLS WG last call on draft-kompella-mpls-special-purpose-labels-04 Thread-Index: Ac5cqdtvgJ8flknDSPCwCyMkaO79tgALLcwA Date: Thu, 30 May 2013 03:07:40 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081C3B3E@NKGEML512-MBS.china.huawei.com> References: <62CCD4C52ACDAD4481149BD5D8A72FD316C76D83@CH1PRD0510MB355.namprd05.prod.outlook.com> In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316C76D83@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.130] Content-Type: multipart/alternative; boundary="_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081C3B3ENKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-kompella-mpls-special-purpose-labels@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: [mpls] =?gb2312?b?tPC4tDogTVBMUyBXRyBsYXN0IGNhbGwgb24JZHJhZnQt?= =?gb2312?b?a29tcGVsbGEtbXBscy1zcGVjaWFsLXB1cnBvc2UtbGFiZWxzLTA0?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 03:07:56 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081C3B3ENKGEML512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIHN1cHBvcnQuICBTb21lIG1pbm9yIGNvbW1lbnRzIGZvciBjb25zaWRlcmF0 aW9uOg0KDQoNCjEuICAgICAgIGl0IHNhaWQgaW4gc2VjdGlvbiAzLjEgobAgQSBsYWJlbCBhZnRl ciBMIChpZiBhbnkpIGlzIHBhcnNlZCBhcyB1c3VhbCwgYW5kIHRodXMgbWF5IGJlIGEgcmVndWxh ciAgbGFiZWwsIGEgc3BlY2lhbCBwdXJwb3NlIGxhYmVsIG9yIChpZiBwcmVmaXhlZCBieSBhbm90 aGVyIGV4dGVuc2lvbiAgbGFiZWwpIGFuIGV4dGVuZGVkIHNwZWNpYWwgcHVycG9zZSBsYWJlbC6h sQ0KDQpTaG91bGQgdGhlIGFib3ZlIGJlIG1vZGlmaWVkIGFzOg0KobBBIGxhYmVsIGFmdGVyIEwg KGlmIGFueSkgaXMgcGFyc2VkIGFzIHVzdWFsLCBhbmQgdGh1cyBtYXkgYmUgYSByZWd1bGFyICBs YWJlbCwgYSBzcGVjaWFsIHB1cnBvc2UgbGFiZWwgb3IgYW5vdGhlciBleHRlbnNpb24gIGxhYmVs LqGxDQoNCg0KMi4gICAgICAgIGl0IHNhaWQgaW4gc2VjdGlvbiAzLjE6ICAgobBWYWx1ZXMgMC02 IGFuZCA4LTE1IG9mIHRoZSBleHRlbmRlZCBzcGVjaWFsIHB1cnBvc2UgbGFiZWwgcmVnaXN0cnkg IGFyZSBzZXQgYXNpZGUgYXMgcmVzZXJ2ZWQ7IHRoZXNlIE1VU1QgTk9UIGFwcGVhciBpbiB0aGUg ZGF0YSBwbGFuZS4gIExhYmVsIDcgKHdoZW4gcmVjZWl2ZWQpIHJldGFpbnMgaXRzIG1lYW5pbmcg YXMgRUxJIHdoZXRoZXIgYSByZWd1bGFyICBvciBhbiBleHRlbmRlZCBzcGVjaWFsIHB1cnBvc2Ug bGFiZWw7IGhvd2V2ZXIsIGFuIGltcGxlbWVudGF0aW9uICBTSE9VTEQgTk9UIGluc2VydCBhIGxh YmVsIG9mIDcgYXMgYW4gZXh0ZW5kZWQgc3BlY2lhbCBwdXJwb3NlIGxhYmVsLCAgcHJlZmVycmlu ZyBpbnN0ZWFkIHRvIHNlbmQgNyBhcyBhIHJlZ3VsYXIgc3BlY2lhbCBwdXJwb3NlIGxhYmVsLqGx DQoNCkkgdW5kZXJzdGFuZCB0aGUgcmVndWxhciBzcGVjaWFsIHB1cnBvc2UgbGFiZWwgdmFsdWUg TVVTVCBOT1QgYXBwZWFyIGZvbGxvd2luZyB0aGUgRXh0ZW5zaW9uIExhYmVsIGluIHRoZSBNUExT IGxhYmVsIHN0YWNrLiBCdXQgd2hhdKGvcyB0aGUgc3BlY2lhbCB1c2FnZSBvZiBtYWtpbmcgdGhl IEVMSSBsYWJlbCBvZiChsDehsSBhcyBhbiBleGNlcHRpb24gKGkuZS4sIExhYmVsIDcgKHdoZW4g cmVjZWl2ZWQpIHJldGFpbnMgaXRzIG1lYW5pbmcgYXMgRUxJIHdoZXRoZXIgYSByZWd1bGFyICBv ciBhbiBleHRlbmRlZCBzcGVjaWFsIHB1cnBvc2UgbGFiZWwpPw0KDQoNCjMuICAgICAgICBpdCBz YWlkIGluIHNlY3Rpb24gNSwgobAgTm90ZTogYW55IG5ldyBhbGxvY2F0aW9uIGZyb20gdGhlIFNw ZWNpYWwgUHVycG9zZSBNUExTIExhYmVsICAgVmFsdWVzIHJlZ2lzdHJ5IE1VU1QgYmUgYWxzbyBz YXkgd2hldGhlciB0aGUgc2FtZSB2YWx1ZSBuZWVkcyB0byAgIGJlIHJlc2VydmVkIGluIHRoZSBF eHRlbmRlZCBTcGVjaWFsIFB1cnBvc2UgTVBMUyBMYWJlbCBWYWx1ZXMgIHJlZ2lzdHJ5LqGxDQoN CldvdWxkbqGvdCB0aGlzIGRlc2NyaXB0aW9uIGNvbmZsaWN0IHdpdGggdGhlIGFib3ZlIHN0YXRl bWVudCB0aGF0IKGwVmFsdWVzIDAtNiBhbmQgOC0xNSBvZiB0aGUgZXh0ZW5kZWQgc3BlY2lhbCBw dXJwb3NlIGxhYmVsIHJlZ2lzdHJ5ICBhcmUgc2V0IGFzaWRlIGFzIHJlc2VydmVkOyB0aGVzZSBN VVNUIE5PVCBhcHBlYXIgaW4gdGhlIGRhdGEgcGxhbmUuobEgQnkgdGhlIHdheSwgaW4gbXkgdW5k ZXJzdGFuZGluZywgYXMgbG9uZyBhcyB3ZSBoYXZlIHJlc2VydmVkIG9uZSByZWd1bGFyIHNwZWNp YWwgcHVycG9zZSBsYWJlbCAgKGkuZS4sIDE1KSBhcyB0aGUgRXh0ZW5zaW9uIExhYmVsLCB3ZSB3 b3VsZCBkZWZpbml0ZWx5IGhhdmUgdGhlIGNhcGFiaWxpdHkgdG8gdXNlIHRoZSBFeHRlbmRlZCBz cGVjaWFsIHB1cnBvc2UgbGFiZWwgc3BhY2UgaW4gdGhlIGZ1dHVyZSBpZiBORUVERUQuIER1ZSB0 byB0aGUgdW5jZXJ0YWludHkgb2YgdGhpcyBuZWVkIGZyb20gdG9kYXmhr3MgcG9pbnQgb2Ygdmll dywgaG93IGFib3V0IGV4cGxpY2l0bHkgc3RhdGluZyB0aGF0IKGwVGhlIEV4dGVuZGVkIHNwZWNp YWwgcHVycG9zZSBsYWJlbHMgU0hPVUxEIE5PVCBiZSBhbGxvY2F0ZWQgYnkgSUFOQSB1bnRpbCB0 aGUgcmVndWxhciBzcGVjaWFsIHB1cnBvc2UgbGFiZWwgc3BhY2UgKDAtMTQpIGhhcyBiZWVuIGFs bW9zdCB1c2VkIG91dC6hsSBvciBzb21ldGhpbmcgbGlrZSB0aGF0Lg0KDQpCZXN0IHJlZ2FyZHMs DQpYaWFvaHUNCg0Kt6K8/sjLOiBtcGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJv dW5jZXNAaWV0Zi5vcmddILT6se0gUm9zcyBDYWxsb24NCreiy83KsbzkOiAyMDEzxOo11MIzMMjV IDQ6MjANCsrVvP7IyzogbXBsc0BpZXRmLm9yZw0Ks63LzTogZHJhZnQta29tcGVsbGEtbXBscy1z cGVjaWFsLXB1cnBvc2UtbGFiZWxzQHRvb2xzLmlldGYub3JnOyBtcGxzLWNoYWlyc0B0b29scy5p ZXRmLm9yZw0K1vfM4jogW21wbHNdIE1QTFMgV0cgbGFzdCBjYWxsIG9uIGRyYWZ0LWtvbXBlbGxh LW1wbHMtc3BlY2lhbC1wdXJwb3NlLWxhYmVscy0wNA0KDQpXb3JraW5nIEdyb3VwLA0KDQp0aGlz IGlzIHRvIHN0YXJ0IGEgdHdvIHdlZWsgV29ya2luZyBHcm91cCBsYXN0IGNhbGwgb24NCmRyYWZ0 LWtvbXBlbGxhLW1wbHMtc3BlY2lhbC1wdXJwb3NlLWxhYmVscy0wNC4NCg0KUGxlYXNlIHNlbmQg eW91ciBjb21tZW50cyB0byB0aGUgbXBscyB3b3JraW5nIGdyb3VwDQptYWlsaW5nIGxpc3QgKG1w bHNAaWV0Zi5vcmc8bWFpbHRvOm1wbHNAaWV0Zi5vcmc+KS4NCg0KUGxlYXNlIHNlbmQgYm90aCB0 ZWNobmljYWwgY29tbWVudHMsIGFuZCAoaWYgeW91IGFyZSBoYXBweQ0Kd2l0aCB0aGUgZG9jdW1l bnQgYXMgaXMpIGFsc28gc2VuZCBpbmRpY2F0aW9ucyBvZiBzdXBwb3J0Lg0KDQpUaGVyZSBhcmUg bm8gSVBSIGNsYWltcyBhZ2FpbnN0IHRoaXMgZHJhZnQuDQoNClRoZSBjby1hdXRob3JzIGhhdmUg ZWFybGllciBzdGF0ZWQgdGhhdCB0aGV5IGFyZSBub3QgYXdhcmUNCm9mIGFueSBJUFIgYXBwbGlj YWJsZSB0byB0aGlzIGRyYWZ0Lg0KDQpJZiBhbnlvbmUgZWxzZSBpbiB0aGUgd29ya2luZyBncm91 cCBhcmUgYXdhcmUgb2YgSVBScyBjbGFpbXMgYWdhaW5zdA0KdGhpcyBkcmFmdCwgdGhlIHRpbWUg dG8gZGlzY2xvc2UgdGhhdCBpcyBub3cuDQoNClRoaXMgd29ya2luZyBncm91cCBsYXN0IGNhbGwg d2lsbCBlbmQgb24gSnVuZSAxMywgMjAxMy4NCg0KUm9zcw0KZm9yIHRoZSB3ZyBjby1jaGFpcnMN Cg0KDQoNCg== --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081C3B3ENKGEML512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all,

 = ;

I support.=  Some minor comments for consideration:

 = ;

1.       it= said in section 3.1 =A1=B0 A label after L (if any) is parsed as usual, an= d thus may be a regular  label, a special purpose label or (if prefixed by another extension  label) an extended special purpose lab= el.=A1=B1

 = ;

Should the= above be modified as:

=A1=B0A label after L (if any) is parsed as usual, and t= hus may be a regular  label, a special purpose label or another extens= ion  label.=A1=B1

 = ;

2.       &n= bsp;it said in section 3.1:   =A1=B0Values 0-6 and 8-15 of the ex= tended special purpose label registry  are set aside as reserved; thes= e MUST NOT appear in the data plane.  Label 7 (when received) retains its me= aning as ELI whether a regular  or an extended special purpose label; = however, an implementation  SHOULD NOT insert a label of 7 as an exten= ded special purpose label,  preferring instead to send 7 as a regular special purpose label.=A1=B1

 = ;

I understa= nd the regular special purpose label value MUST NOT appear following the Ex= tension Label in the MPLS label stack. But what=A1=AFs the special usage of making the ELI label of =A1=B07=A1=B1 as an exception (i.e., Labe= l 7 (when received) retains its meaning as ELI whether a regular  or a= n extended special purpose label)?

 = ;

3.       &n= bsp;it said in section 5, =A1=B0 Note: any new allocation from the Special = Purpose MPLS Label   Values registry MUST be also say whether the same value needs to   be reserved in the Extended Special Purpos= e MPLS Label Values  registry.=A1=B1

 = ;

Wouldn=A1= =AFt this description conflict with the above statement that =A1=B0Values 0= -6 and 8-15 of the extended special purpose label registry  are set as= ide as reserved; these MUST NOT appear in the data plane.=A1=B1 By the way, in= my understanding, as long as we have reserved one regular special purpose = label  (i.e., 15) as the Extension Label, we would definitely have the= capability to use the Extended special purpose label space in the future if NEEDED. Due to the uncertainty of this need f= rom today=A1=AFs point of view, how about explicitly stating that =A1=B0The= Extended special purpose labels SHOULD NOT be allocated by IANA until the = regular special purpose label space (0-14) has been almost used out.=A1=B1 or something like that.<= /p>

 = ;

Best regar= ds,

Xiaohu

 = ;

=B7=A2=BC=FE=C8=CB: mpls-bo= unces@ietf.org [mailto:mpls-bounces@ietf.org] =B4=FA= =B1=ED Ross Callon
=B7=A2= =CB=CD=CA=B1=BC=E4: 2013=C4=EA5=D4=C230=C8=D5 4:20
=CA=D5=BC=FE=C8=CB: mpls@ietf.org
=B3=AD=CB=CD: draft-kompella-mpls-special-purpose-labels@tools.ietf.org; mpls-chairs@to= ols.ietf.org
=D6=F7=CC=E2: [mpls] MPLS WG last call on draft-kompella-mpls-special-purpose-labels-04=

 

Working Group,

 

this is to start a two week Working Group last call on

draft-kompella-mpls-special-purpose-labels-04.<= /span>

 

Please send your comments to the mpls working group

mailing list (mpls@ietf.o= rg).

 

Please send both technical comments, and (if you are happy=

with the document as is) also send indications of support.=

 

There are no IPR claims against this draft.

 

The co-authors have earlier stated that they are not aware=

of any IPR applicable to this draft.

 

If anyone else in the working group are aware of IPRs clai= ms against

this draft, the time to disclose that is now.

 

This working group last call will end on June 13, 2013.

 

Ross

for the wg co-chairs

 

 

 

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081C3B3ENKGEML512MBSchi_-- From tochio@jp.fujitsu.com Wed May 29 22:29:54 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E46A21F930C for ; Wed, 29 May 2013 22:29:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.49 X-Spam-Level: X-Spam-Status: No, score=-1.49 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tGQzFBTCPqL6 for ; Wed, 29 May 2013 22:29:50 -0700 (PDT) Received: from fgwmail5.fujitsu.co.jp (fgwmail5.fujitsu.co.jp [192.51.44.35]) by ietfa.amsl.com (Postfix) with ESMTP id 298A421F9301 for ; Wed, 29 May 2013 22:29:50 -0700 (PDT) Received: from m1.gw.fujitsu.co.jp (unknown [10.0.50.71]) by fgwmail5.fujitsu.co.jp (Postfix) with ESMTP id AF5343EE0C1 for ; Thu, 30 May 2013 14:29:48 +0900 (JST) Received: from smail (m1 [127.0.0.1]) by outgoing.m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 9F9C345DE3E for ; Thu, 30 May 2013 14:29:48 +0900 (JST) Received: from s1.gw.fujitsu.co.jp (s1.gw.fujitsu.co.jp [10.0.50.91]) by m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 8A54245DE56 for ; Thu, 30 May 2013 14:29:48 +0900 (JST) Received: from s1.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 7EE5F1DB8046 for ; Thu, 30 May 2013 14:29:48 +0900 (JST) Received: from flabmail.flab.fujitsu.co.jp (flabmail.flab.fujitsu.co.jp [10.25.192.37]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 2B0B6E08006 for ; Thu, 30 May 2013 14:29:48 +0900 (JST) Received: from vskawa.flab.fujitsu.co.jp (vskawa.flab.fujitsu.co.jp [10.25.192.39]) by flabmail.flab.fujitsu.co.jp (8.14.4/8.14.4/110310-Fujitsu Labs. Domain Mail Master) with ESMTP id r4U5ThJN011518 for ; Thu, 30 May 2013 14:29:48 +0900 (JST) X-AuditID: 0a19c027-b7f866d00000132d-5c-51a6e3cbd2e1 Received: from dm.kawasaki.flab.fujitsu.co.jp (dm.kawasaki.flab.fujitsu.co.jp [10.25.192.105]) by vskawa.flab.fujitsu.co.jp (Symantec Messaging Gateway) with SMTP id 33.BB.04909.BC3E6A15; Thu, 30 May 2013 14:29:48 +0900 (JST) Received: from [127.0.0.1] (dhcp92.dream.flab.fujitsu.co.jp [10.25.144.163]) by dm.kawasaki.flab.fujitsu.co.jp (8.14.4/8.14.4/110311-Fujitsu Labs. Kawasaki Domain Mail Master) with ESMTP id r4U5ThDG017913 for ; Thu, 30 May 2013 14:29:47 +0900 (JST) X-SecurityPolicyCheck: OK by SHieldMailChecker v1.8.4 Message-ID: <51A6E3A0.5050107@jp.fujitsu.com> Date: Thu, 30 May 2013 14:29:04 +0900 From: Yuji Tochio User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: mpls@ietf.org References: <20ECF67871905846A80F77F8F4A2757210150296@xmb-rcd-x09.cisco.com> <22257C41A415324A984CD03D63344E270A4750F7@TELMBB002RM001.telecomitalia.local> <20ECF67871905846A80F77F8F4A275721019F7F7@xmb-rcd-x09.cisco.com> <518C1431.70204@labn.net> In-Reply-To: <518C1431.70204@labn.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprILMWRmVeSWpSXmKPExsXCJXkgU/fM42WBBu/vMFrcWrqS1YHRY8mS n0wBjFFcNimpOZllqUX6dglcGc0Tp7EVnDSoWNB0lKWB8Yh6FyMnh4SAicTR+T+YIWwxiQv3 1rN1MXJxCAk8ZpQ40biLHcLpZpI4cXQTI0SVqcTEdc/AbF4BXYlHV5qAOjg4WARUJV79LAEJ swloSlybeQesRFQgWOL7trvMEOWCEidnPmEBsUWA7GlXj4LZwgJWEgf3bWGC2PWVUaLl3Bw2 kASngJrExwNTwGxmATOJrq1djBC2vETz1tnMExgFZiGZOwtJ2SwkZQsYmVcxSpYVZyeWJ+ql 5SQm6aWVZmWWFJfqJefrZRVsYoQEo/oOxmeLNA8xCnAwKvHwfuleFijEmlhWXJl7iFGCg1lJ hHf+XqAQb0piZVVqUX58UWlOavEhRiYOTqkGRlYfo0nv1HRPBu6a5tS4vSP3BMvkE28d5c2P qLGWclus+DqN/4x20ezfYlkqBXvn+LC+ehX+bOMr34xd02rvyp6pvhva3yTb1JUS/Wp95Nri 5/YL5861WfFkBzunfW8F+43jK67y/maT5L0+jW2/zOJL925/sZc3/rKmxNWgU9h9SnDJu/CM 2UosxRmJhlrMRcWJALM1iTIkAgAA Subject: Re: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 05:29:54 -0000 Hi, Reading Lou's comment and LS to ITU-T ( http://datatracker.ietf.org/liaison/1256/ ), I had read RFC 6372 again. As well as the comments below, I also found at the last paragraph in section 4.1.1 as: -- <..> o Force a switchover from a working path to a recovery path or vice versa. Forced switchover may be performed for network optimization purposes with minimal service interruption, <..> -- My question is "Is this rational for the priority between FS and SF-P?" My understanding it should be swapped and update should be in RFC 6378 as I addressed before. So I would like to ask for clarification on this point. If this has been already pointed out and discussed please ignore , but the last sentence of the last paragraph in section 4.1.1 in RFC 6372 should be fixed as editoral (s/Section 4.12/Section 4.13/, since 4.12 is Failure Reporting ) Just my 2c, Yuji (2013/05/10 6:25), Lou Berger wrote: > Eric, > I think you might have missed that rfc6372 section 6.1.2 is consistent > with RFC4427. So perhaps it would be best to have a standalone > draft/rfc that updates both rfc6372 and rfc4427 on this specific point > alone. If this is done, no change to rfc5654 is needed. > > Lou > > On 5/9/2013 11:40 AM, Eric Osborne (eosborne) wrote: >> Hi Alessandro, see inline. >> >>> -----Original Message----- >>> From: D'Alessandro Alessandro Gerardo >>> [mailto:alessandro.dalessandro@telecomitalia.it] >>> Sent: Tuesday, May 07, 2013 3:27 PM >>> To: Eric Osborne (eosborne); mpls@ietf.org >>> Cc: Cavazzoni Carlo; Allasia Andrea; Nervo Giacolino; Morro Roberto; >>> ryoo@etri.re.kr; lifang@catr.cn; cts@etri.re.kr >>> Subject: R: PSC: draft-rhd-mpls-tp-psc-priority-00 >>> >>> Hi Eric, >>> You wrote "is it appropriate to make this priority swap?" >>> My answer is yes, it shall be done for the reasons explained in liaison >>> 1205, bullet 1. >> Let me paraphrase the three points in those bullets, I want to make sure I understand them: >> >> a. If the protection path fails then the removal of the FS will not be seen because the channel used to provide it is gone. >> b. If there is SF-P and FS is issued by accident then this will cause an outage, which is Bad >> c. (points to Annex 1): similar to (a) above, the loss of the protection channel means there will be an inconsistency in the protection state >> >> Is that an accurate paraphrase? >> >>> You wrote "- what do we need to change? rfc5654? rfc4427? " >>> No I don't believe it is required to change any RFC but RFC 6378 >> To me this decision is a matter of process rather than of technical behavior. >> I believe the current set of opinions is this: >> >> a) some believe that rfc4427 requires the current set of priorities, as per LS1174 point #1 (http://datatracker.ietf.org/liaison/1174/) >> b) some believe it does not, and that rfc6378 misinterpreted rfc4427 >> >> I think we all agree that the chain here is: 6378 must obey 5654, and that 5654 requires 4427. >> >> So it's going to come down to - is 4427 written wrong but interpreted correctly, or written correctly but misinterpreted? >> If we decide the former, we need to change 4427 and/or 5654 to clarify the requirement. >> If we decide the latter, we do not need to change 4427 and can probably just change 6378. >> >> Does that sound right? >> >> >> >> eric >> >>> Best regards, >>> Alessandro >>> >>> ------------------------------------------------------------------ >>> Telecom Italia >>> Alessandro Gerardo D'Alessandro >>> Transport Innovation >>> Via Reiss Romoli, 274 - 10148 Torino >>> phone: +39 011 228 5887 >>> mobile: +39 335 766 9607 >>> fax: +39 06 418 639 07 >>> >>> >>> -----Messaggio originale----- >>> Da: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] Per conto di >>> Eric Osborne (eosborne) >>> Inviato: mercoledì 17 aprile 2013 14:16 >>> A: mpls@ietf.org >>> Oggetto: [mpls] PSC: draft-rhd-mpls-tp-psc-priority-00 >>> >>> This thread is for discussing draft-rhd-mpls-tp-psc-priority-00. In >>> brief, the draft proposes swapping the priorities between FS and SF-P >>> (see section 4.3.2 of rfc6378). This proposed swap has a long history, >>> dating back to when PSC was an ID. For some history, see >>> >>> http://datatracker.ietf.org/liaison/1229/ >>> and >>> http://datatracker.ietf.org/liaison/1234/ >>> >>> The questions that I think are relevant here are: >>> >>> - is it appropriate to make this priority swap? >>> - are there alternative approaches? >>> - what do we need to change? rfc5654? rfc4427? >>> - if we don't make the change, does this expose implementation to >>> problems? >>> - if we do make the change, how do we go about it? >>> >>> but of course any and all discussion is welcome. >>> >>> As with the other threads I'm going to leave my two cents out of this >>> introductory email but I'll chime in when discussion starts. >>> >>> >>> >>> >>> >>> eric >>> _______________________________________________ >>> mpls mailing list >>> mpls@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls >>> >>> Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle >>> persone indicate. La diffusione, copia o qualsiasi altra azione >>> derivante dalla conoscenza di queste informazioni sono rigorosamente >>> vietate. Qualora abbiate ricevuto questo documento per errore siete >>> cortesemente pregati di darne immediata comunicazione al mittente e di >>> provvedere alla sua distruzione, Grazie. >>> >>> This e-mail and any attachments is confidential and may contain >>> privileged information intended for the addressee(s) only. >>> Dissemination, copying, printing or use by anybody else is unauthorised. >>> If you are not the intended recipient, please delete this message and >>> any attachments and advise the sender by return e-mail, Thanks. >> _______________________________________________ >> 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 mach.chen@huawei.com Wed May 29 23:15:03 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B23921F9588 for ; Wed, 29 May 2013 23:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GjCdF9oX3Kdd for ; Wed, 29 May 2013 23:14:59 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D9B4B21F86CE for ; Wed, 29 May 2013 23:14:57 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARX92511; Thu, 30 May 2013 06:14:56 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 30 May 2013 07:14:19 +0100 Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 30 May 2013 07:14:51 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.243]) by szxeml422-hub.china.huawei.com ([10.82.67.161]) with mapi id 14.01.0323.007; Thu, 30 May 2013 14:13:15 +0800 From: Mach Chen To: "George Swallow (swallow)" Thread-Topic: [mpls] Meaning of sub-TLVs for TLV 21 in Return Path Specified Thread-Index: AQHOVj9xsbdxNWyKhUe07sOydMXSapkQbk2ggAs4YACAAWaaQA== Date: Thu, 30 May 2013 06:13:14 +0000 Message-ID: References: <2FE467D3673DCE409A84D67EC2F607BB0FA82512@xmb-rcd-x10.cisco.com>, In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BAA7A4szxeml558mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" , "draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org" Subject: Re: [mpls] Meaning of sub-TLVs for TLV 21 in Return Path Specified X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 06:15:03 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BAA7A4szxeml558mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi George, Thanks for your reply! I just re-read the draft, and compare the two usages, the only sub-TLV tha= t may not suitable for specifying (in echo request) return path is the Nil = sub-TLV. And you still can find in the IANA registry page, it did explicit= ly list some of the sub-TLVs of TLV 1 for TLV 21, this is proposed in the e= arly version of this draft, just as you suggested below. But eventually found TLV 21 could actually apply all the sub-TLVs (of cause= , Nil sub-TLV should be excluded) of TLV 1, and also found there is a prece= dent of such usage (TLV 16), this will largely reduce the redefinition of s= ub-TLVs. In addition, if we list sub-TLVs one by one, it may lose sub-TLVs = and cannot automatically inherit future defined sub-TLVs. These are the rea= son and motivation for current choice. So, if just to solve the allocation issue TLV 21 faced, I am personally fi= ne with each way of those proposed solutions. But I still believe that dra= ft-pac is a better way, it makes the allocation easier and clearer. Best regards, Mach From: George Swallow (swallow) [mailto:swallow@cisco.com] Sent: Wednesday, May 29, 2013 9:02 PM To: Mach Chen Cc: draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org; mpls= @ietf.org Subject: Re: [mpls] Meaning of sub-TLVs for TLV 21 in Return Path Specified Mach - Sorry for the delay. So you have two different uses for one tlv. That in itself is not all that = bad. But apparently what you have is two uses where; 1. The semantics of the sub-tlvs change completely depending on which way y= ou are you are using the tlv. 2. The allowable sub-tlvs vary with the usage of the tlv. Further, on re-reading the draft these two uses are not clearly delineated. It would be a much better protocol design to have two tlvs. In what you cal= l case 2 below, the Tlv could reuse the sub-tlvs of tlv 1. In what you call= case one, the sub-tlvs would go into a registry specific to the tlv for ca= se 1. This would list only those sub-tlvs of tlv 1 that are valid for this= case. By list I mean explicitly list (not reference). It would also list = the new tlvs you have defined. George On May 22, 2013, at 1:39 AM, "Mach Chen" > wrote: Hi George, I guess your question is that why TLV 21 have to apply all the sub-TLVs of = TLV 1. For TLV 21, there are at least two usages, one is for specifying the return= path of the echo reply, and if just for specifying the return path of echo= reply, yes, it may not necessary to use all sub-TLVs of TLV 1. The other i= s for testing and validating the specified return path by carrying TLV 21( = just as the FEC Stack TLV for forward path). For usage 2, the TLV 21 should= have the same semantics as TLV 1, thus applying all sub-TLVs of TLV 1 is r= easonable. Many thanks, Mach From: mpls-bounces@ietf.org [mailto:mpls-boun= ces@ietf.org] On Behalf Of George Swallow (swallow) Sent: Wednesday, May 22, 2013 12:23 AM To: draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org Cc: mpls@ietf.org Subject: [mpls] Meaning of sub-TLVs for TLV 21 in Return Path Specified Mach, et al. - In section 4.1. Sending an Echo Request, it is stated: The Reply Path TLV includes one or several reply path sub-TLV(s) to identify the return path(s) the egress LSR should use for its reply. It would appear that the semantics of TLV 21 are very different than the se= mantics of TLV 1. Since TLV 1 defines a FEC stack which maps to a single L= SP. Why do you want the NIL FEC which only makes sense as part of a FEC st= ack? Under what circumstances would you ever use one of the multicast FECs (sub-= TLVs 17, 18, 19, 20)? What is the meaning of a return path to a VPN IPv4 prefix, or VPN IPv6 pre= fix? Note that if the prefix is multi-homed it may not even return to the = originating PE! What is the meaning of a return path to an L2 VPN endpoint? George _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BAA7A4szxeml558mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Hi George,

=  

= Th= anks for your reply!

=  

= I just re-read the draft,  and = compare the two usages, the only sub-TLV that may not suitable for specifyi= ng (in echo request) return path is the Nil sub-TLV.  And you still can find in the= IANA registry page, it did explicitly list some of the sub-TLVs of TLV 1 f= or TLV 21, this is proposed in the early version of this draft, just as you= suggested below.

=  

= Bu= t eventually found TLV 21 could actually apply all the sub-TLVs (of cause, N= il sub-TLV should be excluded) of TLV 1, and also found there is a preceden= t of such usage (TLV 16), this will largely reduce the redefinition of sub-= TLVs. In addition, if we list sub-TLVs one by one, it may lose sub-TLVs and cannot automatically inherit future d= efined sub-TLVs. These are the reason and motivation for current choice.

=  

= So= , if just to solve the allocation issue TLV 21 faced,  I am personally fine with each way of those proposed solutions= .  But I still believe that draft-pac is a better way, it makes the allocation easier and clearer.  

=  

= Be= st regards,

= Ma= ch

=  

From: George Swallow (swallow) [mailto:swallow@cisco.com]
Sent: Wednesday, May 29, 201= 3 9:02 PM
To: Mach Chen
Cc: draft-ietf-mpls-return-p= ath-specified-lsp-ping.all@tools.ietf.org; mpls@ietf.org
Subject: Re: [mpls] Meaning = of sub-TLVs for TLV 21 in Return Path Specified

 

Mach -

 

Sorry for the delay.  

 

So you have two different uses for one tlv. That in itself i= s not all that bad. But apparently what you have is two uses where;

 

1. The semantics of the sub-tlvs change completely depending= on which way you are you are using the tlv. =

 

2. The allowable sub-tlvs vary with the usage of the tlv.&nb= sp;

 

Further, on re-reading the draft these two uses are not clea= rly delineated. 

 

It would be a much better protocol design to have two tlvs. = In what you call case 2 below, the Tlv could reuse the sub-tlvs of tlv 1. In what you call case one, the sub-tlvs would go into a= registry specific to the tlv for case 1.  This would list only those = sub-tlvs of tlv 1 that are valid for this case.  By list I mean explic= itly list (not reference). It would also list the new tlvs you have defined. 

 

George


On May 22, 2013, at 1:39 AM, "Mach Chen" <mach.chen@huawei.com> wrote:

= Hi George,

=  

= I guess your question is that why TLV 21 have to apply all the sub-TLVs of TLV 1.

=  

= For TLV 21, there are at least tw= o usages, one is for specifying the return path of the echo reply, and if ju= st for specifying the return path of echo reply, yes, it may not necessary = to use all sub-TLVs of TLV 1. The other is for testing and validating the s= pecified return path by carrying TLV 21( just as the FEC Stack TLV for forward path). For usage 2, the TLV = 21 should have the same semantics as TLV 1, thus applying all sub-TLVs of T= LV 1 is reasonable.

=  

= Many thanks,

= Mach

=  

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of George Swallow = (swallow)
Sent: Wednesday, May 22, 201= 3 12:23 AM
To: draft-ietf-mpls-return-path-specified-lsp-ping.all@tools.ietf.org
Cc: mpls@ietf.org
Subject: [mpls] Meaning of s= ub-TLVs for TLV 21 in Return Path Specified

 

Mach, et al. -<= /span>

 

In section 4.1. Sending an Echo Request, it is stated:

The Reply Path T=
LV includes one or several reply path sub-TLV(s) to
identify the ret=
urn path(s) the egress LSR should use for its reply.
It would=
 appear that the semantics of TLV 21 are very different than the semantics =
of TLV 1.  Since TLV 1 defines=
 a FEC stack which maps to a single LSP.&n=
bsp; Why do you want the NIL FEC which only makes sense as part of a=
 FEC stack?
Under wh=
at circumstances would you ever use one of the multicast FECs (sub-TLVs 17,=
 18, 19, 20)?
What is =
the meaning of a return path to a VPN IPv4 prefix, or  VPN IPv6 prefix?&=
nbsp; Note that if the prefix is multi-homed it may not even return =
to the originating PE!=

What is =
the meaning of a return path to an L2 VPN endpoint?
George

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org= /mailman/listinfo/mpls

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BAA7A4szxeml558mbschi_-- From loa@pi.nu Thu May 30 00:53:52 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D00D21F977D for ; Thu, 30 May 2013 00:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.749 X-Spam-Level: X-Spam-Status: No, score=-101.749 tagged_above=-999 required=5 tests=[AWL=0.851, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lw5-VoC3UULG for ; Thu, 30 May 2013 00:53:46 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0439221F9775 for ; Thu, 30 May 2013 00:53:46 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id CC8091802D34; Thu, 30 May 2013 09:53:44 +0200 (CEST) Message-ID: <51A70589.10708@pi.nu> Date: Thu, 30 May 2013 09:53:45 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" References: <639CE511-1B0E-47D8-9D9D-1A48964467E2@verisign.com> In-Reply-To: <639CE511-1B0E-47D8-9D9D-1A48964467E2@verisign.com> X-Forwarded-Message-Id: <639CE511-1B0E-47D8-9D9D-1A48964467E2@verisign.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] Fwd: Oooops CORRECTION Reply to This - Re: Nomcom 2013-14 Volunteering - 2nd Call X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 07:53:52 -0000 Working Group, Second call for Nomcom volunteers. Please consider volunteering for the the Nomcom. IETF depends greatly on Nomcom and it is an excellent opportunity to contribute to the IETF. /Loa mpls wg co-chair -------- Original Message -------- Subject: Oooops CORRECTION Reply to This - Re: Nomcom 2013-14 Volunteering - 2nd Call Date: Wed, 29 May 2013 21:08:56 +0000 From: Mankin, Allison Reply-To: ietf@ietf.org, "Mankin, Allison" To: ietf-announce@ietf.org CC: Sorry - my eye was on entering the reply-to field and then I forgot....apologies in advance for pain that may result from this lapse. On May 29, 2013, at 5:04 PM, "Mankin, Allison" wrote: > Hi, everyone, > > Remember that I'm challenging the IETF to come up with 200 volunteers for > the upcoming nomcom. You can volunteer just by hitting Reply to this email. > > What are you waiting for?? The more volunteers we get, the better chance we > have of choosing a random yet representative cross section of the IETF > population. Respond to the 200-volunteer challenge and hit Reply right now. > (Well, much as I want you to do this, please look below at the posts being > filled and be sure you are willing to forgo trying for any of them this year). > > The official information: > The IETF nominating committee (nomcom) process for 2013-14 is under way. The > IETF nomcom appoints folks to fill the open slots on the IAOC, the IAB, > and the IESG. Ten voting members for the nomcom are selected in a verifiably > random way from a pool of volunteers. > > The details of the selection and operation of the nomcom can be found > in RFCs 3777, 5078, 5633, 5680, and 6859. Four of those RFCs (3777, 5633, > 5680 and 6859) comprise BCP 10. We will also reference RFC 3797. > > Volunteers must have attended 3 of the past 5 IETF meetings. As specified in > RFC 3777, that means three out of the five past meetings up to the time this > email announcement goes out to start the solicitation of volunteers. The five > meetings out of which you must have attended three are IETF 82, 83, 84, 85, 86. > > If you qualify, reply to this email and volunteer. > > The list of people and posts whose terms end with the March 2014 IETF > meeting, and thus the positions for which this nomcom is responsible, are > IAOC: > Chris Griffiths > > IAB: > Bernard Aboba > Marc Blanchet > Ross Callon > Eliot Lear > Hannes Tschofenig > > IESG: > Barry Leiba (Applications) > Brian Haberman (Internet) > Benoit Claise (Operations and Management) > Gonzalo Camarillo (RAI) > Stewart Bryant (Routing) > Sean Turner (Security) > Martin Stiemerling (Transport) > > The primary activity for this nomcom will begin in July 2013 and should be > completed in January 2014. Being a nomcom member will require some time > commitment - there will be interviews with candidates at meetings, regularly > scheduled conference calls to ensure progress, collection and review of > requirements from the commitment, review of candidate questionnaires and > of community feedback. A more detailed timetable for the nomcom tasks > will appear soon. > > Please respond to this email before 11:59 pm EDT (UTC -4 hours) > June 16, 2013. In the body include: > 1. your Given Name as you enter it when you register for the IETF > 2. your Family Name as you enter it when you register for the IETF > 3. your current primary affilation (the information you enter into the Company field) > 4. any/all email addresses you've used to register for IETF meetings > 5. which email address you prefer > 6. your phone number (for our use in confirming you if selected). > > You should expect an email response from me within 3 business days stating > whether or not you are qualified (and added to the list). If you don't receive this > response, please re-send your email adding the tag "RESEND" to the subject line. > > Participating in the IETF nomcom is a meaningful and fun way to contribute to the IETF. > Please help us meet the 200-volunteer challenge by hitting Reply to this message today. > > Allison > > Allison Mankin > Nomcom Chair 2013-2014 From loa@pi.nu Thu May 30 01:02:46 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F3C21F9787 for ; Thu, 30 May 2013 01:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.919 X-Spam-Level: X-Spam-Status: No, score=-101.919 tagged_above=-999 required=5 tests=[AWL=0.680, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ji1CresVge+6 for ; Thu, 30 May 2013 01:02:40 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id BFE7821F9782 for ; Thu, 30 May 2013 01:02:40 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id F19251802D34; Thu, 30 May 2013 10:02:39 +0200 (CEST) Message-ID: <51A707A0.7050704@pi.nu> Date: Thu, 30 May 2013 10:02:40 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "" , "VIGOUREUX, MARTIN (MARTIN)" , draft-ietf-mpls-ldp-applicability-label-adv@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] IPR poll on draft-ietf-mpls-ldp-applicability-label-adv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 08:02:46 -0000 Working Group and authors; The authors of draft-ietf-mpls-ldp-applicability-label-adv and the working group chairs are working to prepare the draft for working group last call. We IPR poll on this draft before accepting it as a working group document. Since this is sometime ago we will do a new before starting the working group last call to check whether there is IPR on the document that needs to be disclosed. This mail starts that IPR poll. Are you aware of any IPR that applies to draft-ietf-mpls-ldp- applicability-label-adv? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details). If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the MPLS wg mailing list.* The documents will not advance to the next stage until a response has been received from each author and contributor. If you are on the MPLS WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules. Thanks, Loa (as MPLS WG co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From loa@pi.nu Thu May 30 01:11:40 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E7821F9738 for ; Thu, 30 May 2013 01:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.032 X-Spam-Level: X-Spam-Status: No, score=-102.032 tagged_above=-999 required=5 tests=[AWL=0.567, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFBRcK1CLUIm for ; Thu, 30 May 2013 01:11:34 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id 4CAEA21F96A9 for ; Thu, 30 May 2013 01:11:33 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 5C9CB1802D34; Thu, 30 May 2013 10:11:30 +0200 (CEST) Message-ID: <51A709B2.6000505@pi.nu> Date: Thu, 30 May 2013 10:11:30 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "" , "VIGOUREUX, MARTIN (MARTIN)" , draft-ietf-mpls-ldp-applicability-label-adv@tools.ietf.org References: <51A707A0.7050704@pi.nu> In-Reply-To: <51A707A0.7050704@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] OOOOPPS - Sorry Correction - Re: IPR poll on draft-ietf-mpls-ldp-applicability-label-adv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 08:11:40 -0000 Working Group, a typo :(. We are not preparing this document for wglc, but we are preparing the request for publication. The IPR are poll is still on. /Loa On 2013-05-30 10:02, Loa Andersson wrote: > Working Group and authors; > > The authors of draft-ietf-mpls-ldp-applicability-label-adv and > the working group chairs are working to prepare the draft for working > group last call. > > We IPR poll on this draft before accepting it as a working group > document. Since this is sometime ago we will do a new before > starting the working group last call to check whether there is IPR > on the document that needs to be disclosed. > > This mail starts that IPR poll. > > Are you aware of any IPR that applies to draft-ietf-mpls-ldp- > applicability-label-adv? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > If you are listed as a document author or contributor please respond to > this email regardless of whether or not you are aware of any relevant > IPR. *The response needs to be sent to the MPLS wg mailing list.* The > documents will not advance to the next stage until a response > has been received from each author and contributor. > > If you are on the MPLS WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of any > IPR that has not yet been disclosed in conformance with IETF rules. > > > Thanks, Loa > (as MPLS WG co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From stbryant@cisco.com Thu May 30 03:33:10 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 831C721F961C for ; Thu, 30 May 2013 03:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.372 X-Spam-Level: X-Spam-Status: No, score=-110.372 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSjWwzLcdqSF for ; Thu, 30 May 2013 03:33:05 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 636E721F962A for ; Thu, 30 May 2013 03:33:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4509; q=dns/txt; s=iport; t=1369909986; x=1371119586; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=naTfo4qGPmTRliHYSS4Ed9gVb4Dt1y2hzDBCEIGdIBQ=; b=iU8B+i2IAGsKaqq2/VWWNKoNkuzzfFu+zG6WHaVNFTDrXUEit5iecPol kUa7KHc7TTsN9O4H5FY5c2TXw5grdrLG20AeQ62N4SZIeH6AwHygXRlV+ 1pJdq+mKTYbEo+sVZTXoBdZH5qNFSkRRMeSrTAzkQ2CY2H0/6syWaE8jK U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0MAFMqp1GQ/khM/2dsb2JhbABZgkVEg2uFXrYIglcTexZ0giMBAQEEIwpLARAJAhgJFgsCAgkDAgECAToLBg0BBwEBiAmMO5sokhGPEweCQ4EUA5c7kUCBWIE4 X-IronPort-AV: E=Sophos;i="4.87,770,1363132800"; d="scan'208,217";a="13866591" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 30 May 2013 10:33:05 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4UAX1Fe029894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 May 2013 10:33:01 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r4UAWxga018591; Thu, 30 May 2013 11:32:59 +0100 (BST) Message-ID: <51A72ADB.9090009@cisco.com> Date: Thu, 30 May 2013 11:32:59 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Xuxiaohu References: <62CCD4C52ACDAD4481149BD5D8A72FD316C76D83@CH1PRD0510MB355.namprd05.prod.outlook.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081C3B3E@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081C3B3E@NKGEML512-MBS.china.huawei.com> Content-Type: multipart/alternative; boundary="------------060602000604070804070303" Cc: MPLS WG Mailing List , "mpls-chairs@tools.ietf.org" , "draft-kompella-mpls-special-purpose-labels@tools.ietf.org" Subject: Re: [mpls] =?utf-8?b?562U5aSNOiBNUExTIFdHIGxhc3QgY2FsbCBvbiBkcmFmdC1r?= =?utf-8?q?ompella-mpls-special-purpose-labels-04?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 10:33:10 -0000 This is a multi-part message in MIME format. --------------060602000604070804070303 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 30/05/2013 04:07, Xuxiaohu wrote: > how about explicitly stating that “The Extended special purpose labels > SHOULD NOT be allocated by IANA until the regular special purpose > label space (0-14) has been almost used out.†or something like that. > I would disagree with that. There are far more of the new SP labels than the old, and the old one's take less stack space and less parsing, so I think the right think to do is to consider each application on its own merits. Stewart (AD hat off) --------------060602000604070804070303 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 30/05/2013 04:07, Xuxiaohu wrote:
how about explicitly stating that “The Extended special purpose labels SHOULD NOT be allocated by IANA until the regular special purpose label space (0-14) has been almost used out.†or something like that.

 

I would disagree with that. There are far more of the new SP labels than the old, and the old one's take less stack space and less parsing, so I think the right think to do is to consider each application on its own merits.

Stewart (AD hat off)


--------------060602000604070804070303-- From loa@pi.nu Thu May 30 05:44:35 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB2E21F9397 for ; Thu, 30 May 2013 05:44:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.147 X-Spam-Level: X-Spam-Status: No, score=-102.147 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KhGL6trTY3w for ; Thu, 30 May 2013 05:44:29 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id B7ED521F93A3 for ; Thu, 30 May 2013 05:44:15 -0700 (PDT) Received: from [10.4.144.116] (pat.acreo.se [217.151.195.214]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 6D58D1802D34; Thu, 30 May 2013 14:44:14 +0200 (CEST) Message-ID: <51A7499F.1050000@pi.nu> Date: Thu, 30 May 2013 14:44:15 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: stbryant@cisco.com References: <62CCD4C52ACDAD4481149BD5D8A72FD316C76D83@CH1PRD0510MB355.namprd05.prod.outlook.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081C3B3E@NKGEML512-MBS.china.huawei.com> <51A72ADB.9090009@cisco.com> In-Reply-To: <51A72ADB.9090009@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: MPLS WG Mailing List , "mpls-chairs@tools.ietf.org" , "draft-kompella-mpls-special-purpose-labels@tools.ietf.org" Subject: Re: [mpls] =?utf-8?b?562U5aSNOiBNUExTIFdHIGxhc3QgY2FsbCBvbiBkcmFmdC1r?= =?utf-8?q?ompella-mpls-special-purpose-labels-04?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 12:44:35 -0000 All, I agree with Stewart, how the label will be parsed, will have a lot of impact when we decide how to allocate a new special purspose label. /Loa On 2013-05-30 12:32, Stewart Bryant wrote: > On 30/05/2013 04:07, Xuxiaohu wrote: >> how about explicitly stating that “The Extended special purpose labels >> SHOULD NOT be allocated by IANA until the regular special purpose >> label space (0-14) has been almost used out.†or something like that. >> > I would disagree with that. There are far more of the new SP labels than > the old, and the old one's take less stack space and less parsing, so I > think the right think to do is to consider each application on its own > merits. > > Stewart (AD hat off) > > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From rcallon@juniper.net Thu May 30 08:02:05 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D5F21F86F4 for ; Thu, 30 May 2013 08:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.966 X-Spam-Level: X-Spam-Status: No, score=-101.966 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b68z-rkodRdm for ; Thu, 30 May 2013 08:01:58 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 0F59A21F87BB for ; Thu, 30 May 2013 08:01:38 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKUadpxkgGjhkWDb+QOo/2xz7H3cQvUl9I@postini.com; Thu, 30 May 2013 08:01:39 PDT Received: from P-CLDFE01-HQ.jnpr.net (172.24.192.59) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 30 May 2013 07:58:34 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.59) with Microsoft SMTP Server id 14.1.355.2; Thu, 30 May 2013 07:58:33 -0700 Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.12) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Thu, 30 May 2013 08:01:54 -0700 Received: from mail222-tx2-R.bigfish.com (10.9.14.250) by TX2EHSOBE011.bigfish.com (10.9.40.31) with Microsoft SMTP Server id 14.1.225.23; Thu, 30 May 2013 14:58:32 +0000 Received: from mail222-tx2 (localhost [127.0.0.1]) by mail222-tx2-R.bigfish.com (Postfix) with ESMTP id 957323C0206 for ; Thu, 30 May 2013 14:58:32 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); (null); H:CH1PRD0510HT001.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -22 X-BigFish: PS-22(zz9371Ic85fh4015Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL18c673h182cceh8275dhz31h2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1155h) Received-SPF: softfail (mail222-tx2: transitioning domain of juniper.net does not designate 157.56.244.213 as permitted sender) client-ip=157.56.244.213; envelope-from=rcallon@juniper.net; helo=CH1PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail222-tx2 (localhost.localdomain [127.0.0.1]) by mail222-tx2 (MessageSwitch) id 1369925909153318_15174; Thu, 30 May 2013 14:58:29 +0000 (UTC) Received: from TX2EHSMHS006.bigfish.com (unknown [10.9.14.246]) by mail222-tx2.bigfish.com (Postfix) with ESMTP id 20CB640006F; Thu, 30 May 2013 14:58:29 +0000 (UTC) Received: from CH1PRD0510HT001.namprd05.prod.outlook.com (157.56.244.213) by TX2EHSMHS006.bigfish.com (10.9.99.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 30 May 2013 14:58:26 +0000 Received: from CH1PRD0510MB355.namprd05.prod.outlook.com ([169.254.2.41]) by CH1PRD0510HT001.namprd05.prod.outlook.com ([10.255.150.36]) with mapi id 14.16.0311.000; Thu, 30 May 2013 14:58:25 +0000 From: Ross Callon To: Ross Callon , "mpls@ietf.org" Thread-Topic: OOps, Poll for adoption (was: MPLS WG last call on draft-kompella-mpls-special-purpose-labels-04) Thread-Index: AQHOXUYiZ/qQsTTb6EC4pTEFAGKP3w== Date: Thu, 30 May 2013 14:58:25 +0000 Message-ID: <62CCD4C52ACDAD4481149BD5D8A72FD316C8C753@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: multipart/alternative; boundary="_000_62CCD4C52ACDAD4481149BD5D8A72FD316C8C753CH1PRD0510MB355_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%ALCATEL-LUCENT.COM$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "draft-kompella-mpls-special-purpose-labels@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: [mpls] OOps, Poll for adoption (was: MPLS WG last call on draft-kompella-mpls-special-purpose-labels-04) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 15:02:05 -0000 --_000_62CCD4C52ACDAD4481149BD5D8A72FD316C8C753CH1PRD0510MB355_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Oops. I meant to say "poll for adoption". The message should be: This is to start a "two week" poll on adopting draft-kompella-mpls-special-purpose-labels-04 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end June 13, 2013. Thanks, Ross _____________________________________________ From: Ross Callon Sent: Wednesday, May 29, 2013 4:20 PM To: mpls@ietf.org Cc: 'draft-kompella-mpls-special-purpose-labels@tools.ietf.org'; mpls-chair= s@tools.ietf.org; 'VIGOUREUX, MARTIN (MARTIN)' Subject: MPLS WG last call on draft-kompella-mpls-special-purpose-labels-04 Working Group, this is to start a two week Working Group last call on draft-kompella-mpls-special-purpose-labels-04. Please send your comments to the mpls working group mailing list (mpls@ietf.org). Please send both technical comments, and (if you are happy with the document as is) also send indications of support. There are no IPR claims against this draft. The co-authors have earlier stated that they are not aware of any IPR applicable to this draft. If anyone else in the working group are aware of IPRs claims against this draft, the time to disclose that is now. This working group last call will end on June 13, 2013. Ross for the wg co-chairs --_000_62CCD4C52ACDAD4481149BD5D8A72FD316C8C753CH1PRD0510MB355_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Oops. I meant to say “poll for adoption”. The message shou= ld be:
 
This is to start a "two week" poll on adopting
draft-kompella-mpls-special-purpose-labels-04
as an MPLS working group document.
 
Please send your comments (support/not support) to the mpls working
group mailing list (mpls@ietf.org<= /u>).
 
This poll will end June 13, 2013.
 
Thanks, Ross
_____= ________________________________________
From: Ross Callon
Sent: Wednesday, May 29, 2013 4:20 PM
To: mpls@ietf.org
Cc: 'draft-kompella-mpls-special-purpose-labels@tools.ietf.org'; mpl= s-chairs@tools.ietf.org; 'VIGOUREUX, MARTIN (MARTIN)'
Subject: MPLS WG last call on draft-kompella-mpls-special-purpose-la= bels-04
&nbs= p;
&nbs= p;
W= orking Group,
&= nbsp;
t= his is to start a two week Working Group last call on
d= raft-kompella-mpls-special-purpose-labels-04.
&= nbsp;
P= lease send your comments to the mpls working group
m= ailing list (mpls@= ietf.org).
&= nbsp;
P= lease send both technical comments, and (if you are happy
w= ith the document as is) also send indications of support.
&= nbsp;
T= here are no IPR claims against this draft.
&= nbsp;
T= he co-authors have earlier stated that they are not aware
o= f any IPR applicable to this draft.
&= nbsp;
I= f anyone else in the working group are aware of IPRs claims against<= /font>
t= his draft, the time to disclose that is now.
&= nbsp;
T= his working group last call will end on June 13, 2013.
&= nbsp;
R= oss
f= or the wg co-chairs
&= nbsp;
&nbs= p;
&nbs= p;
 --_000_62CCD4C52ACDAD4481149BD5D8A72FD316C8C753CH1PRD0510MB355_-- From prvs=186219d05f=jeff.tantsura@ericsson.com Thu May 30 08:20:51 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB08F21F9436 for ; Thu, 30 May 2013 08:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ur4RE6W3p+We for ; Thu, 30 May 2013 08:20:45 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id C888C21F9318 for ; Thu, 30 May 2013 08:20:44 -0700 (PDT) X-AuditID: c6180641-b7f0e6d0000015f1-e9-51a76e4b742a Received: from EUSAAHC003.ericsson.se (Unknown_Domain [147.117.188.81]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id CE.E0.05617.B4E67A15; Thu, 30 May 2013 17:20:44 +0200 (CEST) Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC003.ericsson.se ([147.117.188.81]) with mapi id 14.02.0328.009; Thu, 30 May 2013 11:20:42 -0400 From: Jeff Tantsura To: Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] OOps, Poll for adoption (was: MPLS WG last call on draft-kompella-mpls-special-purpose-labels-04) Thread-Index: AQHOXUYiZ/qQsTTb6EC4pTEFAGKP35kdpaSA Date: Thu, 30 May 2013 15:20:42 +0000 Message-ID: <60DEDD93F5E54B4AB55647B8B6C74839376E82@eusaamb109.ericsson.se> In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316C8C753@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_60DEDD93F5E54B4AB55647B8B6C74839376E82eusaamb109ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZXLonUNcnb3mgwbufLBZ3/v1ls/h+aQmL xa2lK1kt/q64wuLA4rFkyU8mj+tNV9k9vlz+zBbAHMVtk5RYUhacmZ6nb5fAnfHz7wPmgp0B Fb+ezWRsYFzl0cXIySEhYCKx8dt1dghbTOLCvfVsXYxcHEICRxkldm19yAzhLGeUOHJyMxNI FZuAgcT/b8dZQGwRATeJOf0nmECKmAV2MUqs2HWFDSQhLFAu0f/7EhtEUYXEzhctQCs4gGwj id8/RUHCLAKqEstXTAabwyvgLbFrThMriM0pkCjxoa8ZbBcj0EXfT60Bs5kFxCVuPZnPBHGp gMSSPeeZIWxRiZeP/4H1igroSbQdOwP1jbLE9zmPWCB68yV+HX7ICLFLUOLkzCcsExhFZyEZ OwtJ2SwkZRBxA4n35+YzQ9jaEssWvoay9SU2fjnLCGFbS9z+uJoJWc0CRo5VjBylxalluelG hpsYgfF4TILNcQfjgk+WhxilOViUxHl1eBcHCgmkJ5akZqemFqQWxReV5qQWH2Jk4uAEEVxS DYwsCrkCh9ueBe2Sivw7s5Y5WsKU8dUlBV/7v8/jbzzMfnU43Gj3mh6BlcaGayaE3W+f1xa6 4kBi+lbm80xtD56KzDolM/XJTkn7v20zpsxbUPT+k5qN9aJzPByux81WxJ8RWrMuUtJ4a52y cvUZ1aB6p+xA9f/xT/d3O69tczu4bMXWRQ9crY8psRRnJBpqMRcVJwIAYtT7nZoCAAA= Cc: "draft-kompella-mpls-special-purpose-labels@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] OOps, Poll for adoption (was: MPLS WG last call on draft-kompella-mpls-special-purpose-labels-04) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 15:20:51 -0000 --_000_60DEDD93F5E54B4AB55647B8B6C74839376E82eusaamb109ericsso_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Yes/support Cheers, Jeff From: Ross Callon > Date: Thursday, May 30, 2013 7:58 AM To: Ross Callon >, "mpls@ie= tf.org" > Cc: "draft-kompella-mpls-special-purpose-labels@tools.ietf.org" >, "mpls-chairs@tools.ietf.org" > Subject: [mpls] OOps, Poll for adoption (was: MPLS WG last call on draft-ko= mpella-mpls-special-purpose-labels-04) Oops. I meant to say =93poll for adoption=94. The message should be: This is to start a "two week" poll on adopting draft-kompella-mpls-special-purpose-labels-04 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end June 13, 2013. Thanks, Ross _____________________________________________ From: Ross Callon Sent: Wednesday, May 29, 2013 4:20 PM To: mpls@ietf.org Cc: 'draft-kompella-mpls-special-purpose-labels@tools.ietf.org'; mpls-chairs@tools.= ietf.org; 'VIGOUREUX, MARTIN (MARTIN)' Subject: MPLS WG last call on draft-kompella-mpls-special-purpose-labels-04 Working Group, this is to start a two week Working Group last call on draft-kompella-mpls-special-purpose-labels-04. Please send your comments to the mpls working group mailing list (mpls@ietf.org). Please send both technical comments, and (if you are happy with the document as is) also send indications of support. There are no IPR claims against this draft. The co-authors have earlier stated that they are not aware of any IPR applicable to this draft. If anyone else in the working group are aware of IPRs claims against this draft, the time to disclose that is now. This working group last call will end on June 13, 2013. Ross for the wg co-chairs --_000_60DEDD93F5E54B4AB55647B8B6C74839376E82eusaamb109ericsso_ Content-Type: text/html; charset="Windows-1252" Content-ID: <11532B82881E3544A785969A7E92915A@ericsson.com> Content-Transfer-Encoding: quoted-printable
Yes/support

Cheers,
Jeff

From: Ross Callon <rcallon@juniper.net>
Date: Thursday, May 30, 2013 7:58 A= M
To: Ross Callon <rcallon@juniper.net>, "mpls@ietf.org" <mpls@ietf.org>
Cc: "draft-kompella-mpls-spe= cial-purpose-labels@tools.ietf.org" <draft-kompella-mpls-spec= ial-purpose-labels@tools.ietf.org>, "mpls-chairs@tools.ietf= .org" <mpls-chair= s@tools.ietf.org>
Subject: [mpls] OOps, Poll for adop= tion (was: MPLS WG last call on draft-kompella-mpls-special-purpose-labels-= 04)

Oops. I meant to say =93poll for adoption=94. The message should be:
 
This is to start a "two week" poll on adopting
draft-kompella-mpls-special-purpose-labels-04
as an MPLS working group document.
 
Please send your comments (support/not support) to the mpls working
group mailing list (mpls@ietf.org<= /u>).
 
This poll will end June 13, 2013.
 
Thanks, Ross
_____= ________________________________________
From: Ross Callon
Sent: Wednesday, May 29, 2013 4:20 PM
To: mpls@ietf.org
Cc: 'draft-kompella-mpls-special-purpose-labels@tools.ietf.org'; mpls-chairs@tools.ietf.org; 'VIGOUREUX, MARTIN (MARTIN)'
Subject: MPLS WG last call on draft-kompella-mpls-special-purpose-la= bels-04
&nbs= p;
&nbs= p;
W= orking Group,
&= nbsp;
t= his is to start a two week Working Group last call on
d= raft-kompella-mpls-special-purpose-labels-04.
&= nbsp;
P= lease send your comments to the mpls working group
m= ailing list (mpls@= ietf.org).
&= nbsp;
P= lease send both technical comments, and (if you are happy
w= ith the document as is) also send indications of support.
&= nbsp;
T= here are no IPR claims against this draft.
&= nbsp;
T= he co-authors have earlier stated that they are not aware
o= f any IPR applicable to this draft.
&= nbsp;
I= f anyone else in the working group are aware of IPRs claims against<= /font>
t= his draft, the time to disclose that is now.
&= nbsp;
T= his working group last call will end on June 13, 2013.
&= nbsp;
R= oss
f= or the wg co-chairs
&= nbsp;
&nbs= p;
&nbs= p;
 --_000_60DEDD93F5E54B4AB55647B8B6C74839376E82eusaamb109ericsso_-- From ietf-ipr@ietf.org Thu May 30 08:59:57 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9760C21F960D; Thu, 30 May 2013 08:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.436 X-Spam-Level: X-Spam-Status: No, score=-102.436 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1fAsCpcsYys6; Thu, 30 May 2013 08:59:56 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CFD021F95E5; Thu, 30 May 2013 08:59:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: swallow@cisco.com, vlim@cisco.com, aldrin.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 4.50 Message-ID: <20130530155945.23679.11258.idtracker@ietfa.amsl.com> Date: Thu, 30 May 2013 08:59:45 -0700 Cc: mpls@ietf.org, rcallon@juniper.net, ipr-announce@ietf.org, loa@pi.nu Subject: [mpls] IPR Disclosure: Cisco's Statement of IPR Related to draft-lim-mpls-proxy-lsp-ping-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 15:59:58 -0000 Dear George Swallow, Vanson Lim, Sam Aldrin: An IPR disclosure that pertains to your Internet-Draft entitled "Proxy MPLS Echo Request" (draft-lim-mpls-proxy-lsp-ping) was submitted to the IETF Secretariat on 2013-05-29 and has been posted on the "IETF Page of Intellec= tual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2087/). The = title of the IPR disclosure is "Cisco's Statement of IPR Related to draft-lim-mpl= s- proxy-lsp-ping-02.""); The IETF Secretariat From loa@pi.nu Thu May 30 09:35:12 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EE2221F968F for ; Thu, 30 May 2013 09:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.113 X-Spam-Level: X-Spam-Status: No, score=-102.113 tagged_above=-999 required=5 tests=[AWL=0.486, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vqSVTF93khNK for ; Thu, 30 May 2013 09:35:08 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id B0BAD21F968D for ; Thu, 30 May 2013 09:35:07 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id B11601802D4C; Thu, 30 May 2013 18:35:06 +0200 (CEST) Message-ID: <51A77FBD.6010605@pi.nu> Date: Thu, 30 May 2013 18:35:09 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "mpls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "mpls-chairs@tools.ietf.org" , "draft-lim-mpls-proxy-lsp-ping@tools.ietf.org" Subject: [mpls] Poll to see if we have consensus to make draft-lim-mpls-proxy-lsp-ping an MPLS working group document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 16:35:12 -0000 Working Group, This is to start a two week poll on adopting draft-lim-mpls-proxy-lsp-ping-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls at ietf.org). Please give a technical motivation for your support/not support, especially if you think that the document should not be adopted as a working group document. This poll ends June 14, 2013. There are two IPR claims against this document: https://datatracker.ietf.org/ipr/778/ https://datatracker.ietf.org/ipr/2087/ The authors has stated on the working group mailing list that they are not aware of any other IPR claims against this draft. However if you are on the the mpls working group mailing list and aware of IPR that relates to this draft, the time to disclose this is now. /Loa (mpls wg co-chair) -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From adrian@olddog.co.uk Thu May 30 09:35:19 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5A0A21F96EB for ; Thu, 30 May 2013 09:35:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.517 X-Spam-Level: X-Spam-Status: No, score=-1.517 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_SORBS_WEB=0.619, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHeOgE5GYtPA for ; Thu, 30 May 2013 09:35:14 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id CF14121F9607 for ; Thu, 30 May 2013 09:35:13 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4UGYndb015609; Thu, 30 May 2013 17:34:49 +0100 Received: from 950129200 ([220.109.211.58]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4UGYhrX015546 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 30 May 2013 17:34:45 +0100 From: "Adrian Farrel" To: "'Loa Andersson'" , References: <62CCD4C52ACDAD4481149BD5D8A72FD316C76D83@CH1PRD0510MB355.namprd05.prod.outlook.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081C3B3E@NKGEML512-MBS.china.huawei.com> <51A72ADB.9090009@cisco.com> <51A7499F.1050000@pi.nu> In-Reply-To: <51A7499F.1050000@pi.nu> Date: Thu, 30 May 2013 17:34:37 +0100 Message-ID: <013501ce5d53$98aebbe0$ca0c33a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHMDKeoFfRAZVE2wLG+gCviT5U7EwIApuziAfe0XTAB/z9Uypjy0HEQ Content-Language: en-gb Cc: 'MPLS WG Mailing List' , mpls-chairs@tools.ietf.org, draft-kompella-mpls-special-purpose-labels@tools.ietf.org Subject: Re: [mpls] =?utf-8?b?562U5aSNOiBNUExTIFdHIGxhc3QgY2FsbCBvbiBkcmFmdC1r?= =?utf-8?q?ompella-mpls-special-purpose-labels-04?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 16:35:20 -0000 I kind of agree with Stewart and Xiaohu, but I note that the regular = special purpose label space (0-14) *is*already* almost used out. Thus, making the statement would have no effect because we are already = passed the point. And hence there is no point in adding the text. Adrian (just a humble co-author) > -----Original Message----- > From: Loa Andersson [mailto:loa@pi.nu] > Sent: 30 May 2013 13:44 > To: stbryant@cisco.com > Cc: Xuxiaohu; MPLS WG Mailing List; = draft-kompella-mpls-special-purpose- > labels@tools.ietf.org; mpls-chairs@tools.ietf.org > Subject: Re: [mpls] =E7=AD=94=E5=A4=8D: MPLS WG last call on = draft-kompella-mpls-special- > purpose-labels-04 >=20 > All, >=20 > I agree with Stewart, how the label will be parsed, will have a lot > of impact when we decide how to allocate a new special purspose label. >=20 > /Loa >=20 > On 2013-05-30 12:32, Stewart Bryant wrote: > > On 30/05/2013 04:07, Xuxiaohu wrote: > >> how about explicitly stating that =E2=80=9CThe Extended special = purpose labels > >> SHOULD NOT be allocated by IANA until the regular special purpose > >> label space (0-14) has been almost used out.=E2=80=9D or something = like that. > >> > > I would disagree with that. There are far more of the new SP labels = than > > the old, and the old one's take less stack space and less parsing, = so I > > think the right think to do is to consider each application on its = own > > merits. > > > > Stewart (AD hat off) > > > > >=20 > -- >=20 >=20 > Loa Andersson email: loa@mail01.huawei.com > Senior MPLS Expert loa@pi.nu > Huawei Technologies (consultant) phone: +46 739 81 21 64 From gregory.mirsky@ericsson.com Thu May 30 10:11:08 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A150D21F9467 for ; Thu, 30 May 2013 10:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQzNtNdnzO+1 for ; Thu, 30 May 2013 10:11:02 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id EE8B421F93F1 for ; Thu, 30 May 2013 10:11:01 -0700 (PDT) X-AuditID: c618062d-b7f936d000004481-ea-51a788256912 Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id B1.A8.17537.52887A15; Thu, 30 May 2013 19:11:01 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.02.0328.009; Thu, 30 May 2013 13:11:00 -0400 From: Gregory Mirsky To: "mpls@ietf.org" Thread-Topic: [mpls] OOps, Poll for adoption (was: MPLS WG last call on draft-kompella-mpls-special-purpose-labels-04) Thread-Index: AQHOXUYiZ/qQsTTb6EC4pTEFAGKP35kd9qcQ Date: Thu, 30 May 2013 17:10:59 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B49F0D0@eusaamb103.ericsson.se> References: <62CCD4C52ACDAD4481149BD5D8A72FD316C8C753@CH1PRD0510MB355.namprd05.prod.outlook.com> In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316C8C753@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.135] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B49F0D0eusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyuXRPlK5qx/JAg3Pf5SxuLV3J6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujEN75zIXHHeuOHWrh7GB8Zt1FyMHh4SAicSbN9JdjJxAppjE hXvr2boYuTiEBI4yShz/+4MdwlnOKPGut5cRpIpNwEjixcYedhBbREBZ4sjEblYQW1igXGLR 55WsEPEKiZ0vWqBqjCSWrvvOBrKMRUBV4taWWBCTV8BXYtV5sAohgQSJCYtesYDYnAKJEh/6 mplAbEage76fWgNmMwuIS9x6Mp8J4k4BiSV7zjND2KISLx//Y4WwlSW+z3nEAlGfL9EytwEs zisgKHFy5hOWCYwis5CMmoWkbBaSMoi4jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KkaO0 OLUsN93IYBMjMEqOSbDp7mDc89LyEKM0B4uSOK8a7+JAIYH0xJLU7NTUgtSi+KLSnNTiQ4xM HJxSDYx+00/unVTgmCBxN3KmRva1BSbhbLe2a51v39Jr97j1qzxD9YqCpxFCd+P36z4Mjfj2 /qDPvUO3Kha96Gg4WXOmls9iguiEqHzRR1fCnYpvzpqpZfvwuJ62b0KPIofjvWm7ZmXpq9oK 39v9RmeGcOuu+hihiWoTTZetM35+dkFV552Ci6JtXiVKLMUZiYZazEXFiQDVxR4aYAIAAA== Subject: Re: [mpls] OOps, Poll for adoption (was: MPLS WG last call on draft-kompella-mpls-special-purpose-labels-04) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 17:11:08 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B49F0D0eusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable yes/support Regards, Greg ________________________________ From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ros= s Callon Sent: Thursday, May 30, 2013 7:58 AM To: Ross Callon; mpls@ietf.org Cc: draft-kompella-mpls-special-purpose-labels@tools.ietf.org; mpls-chairs@= tools.ietf.org Subject: [mpls] OOps, Poll for adoption (was: MPLS WG last call on draft-ko= mpella-mpls-special-purpose-labels-04) Oops. I meant to say "poll for adoption". The message should be: This is to start a "two week" poll on adopting draft-kompella-mpls-special-purpose-labels-04 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end June 13, 2013. Thanks, Ross _____________________________________________ From: Ross Callon Sent: Wednesday, May 29, 2013 4:20 PM To: mpls@ietf.org Cc: 'draft-kompella-mpls-special-purpose-labels@tools.ietf.org'; mpls-chair= s@tools.ietf.org; 'VIGOUREUX, MARTIN (MARTIN)' Subject: MPLS WG last call on draft-kompella-mpls-special-purpose-labels-04 Working Group, this is to start a two week Working Group last call on draft-kompella-mpls-special-purpose-labels-04. Please send your comments to the mpls working group mailing list (mpls@ietf.org). Please send both technical comments, and (if you are happy with the document as is) also send indications of support. There are no IPR claims against this draft. The co-authors have earlier stated that they are not aware of any IPR applicable to this draft. If anyone else in the working group are aware of IPRs claims against this draft, the time to disclose that is now. This working group last call will end on June 13, 2013. Ross for the wg co-chairs --_000_7347100B5761DC41A166AC17F22DF1121B49F0D0eusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
yes/support
 
    Regards,
     &nb= sp;  Greg

From: mpls-bounces@ietf.org [mailto= :mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Thursday, May 30, 2013 7:58 AM
To: Ross Callon; mpls@ietf.org
Cc: draft-kompella-mpls-special-purpose-labels@tools.ietf.org; mpls-= chairs@tools.ietf.org
Subject: [mpls] OOps, Poll for adoption (was: MPLS WG last call on d= raft-kompella-mpls-special-purpose-labels-04)

Oops. I meant to say “poll for adoption”. The message shou= ld be:
 
This is to start a "two week" poll on adopting
draft-kompella-mpls-special-purpose-labels-04
as an MPLS working group document.
 
Please send your comments (support/not support) to the mpls working
group mailing list (mpls@ietf.org<= /u>).
 
This poll will end June 13, 2013.
 
Thanks, Ross
_____= ________________________________________
From: Ross Callon
Sent: Wednesday, May 29, 2013 4:20 PM
To: mpls@ietf.org
Cc: 'draft-kompella-mpls-special-purpose-labels@tools.ietf.org'; mpl= s-chairs@tools.ietf.org; 'VIGOUREUX, MARTIN (MARTIN)'
Subject: MPLS WG last call on draft-kompella-mpls-special-purpose-la= bels-04
 
 
W= orking Group,
<= /span> 
t= his is to start a two week Working Group last call on
d= raft-kompella-mpls-special-purpose-labels-04.
<= /span> 
P= lease send your comments to the mpls working group
m= ailing list (mpls@= ietf.org).
<= /span> 
P= lease send both technical comments, and (if you are happy
w= ith the document as is) also send indications of support.
<= /span> 
T= here are no IPR claims against this draft.
<= /span> 
T= he co-authors have earlier stated that they are not aware
o= f any IPR applicable to this draft.
<= /span> 
I= f anyone else in the working group are aware of IPRs claims against<= /font>
t= his draft, the time to disclose that is now.
<= /span> 
T= his working group last call will end on June 13, 2013.
<= /span> 
R= oss
f= or the wg co-chairs
<= /span> 
 
 
 --_000_7347100B5761DC41A166AC17F22DF1121B49F0D0eusaamb103erics_-- From erosen@cisco.com Thu May 30 11:53:16 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42DE321F8F5D for ; Thu, 30 May 2013 11:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-6fE6DPViOz for ; Thu, 30 May 2013 11:53:07 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6D49121F859B for ; Thu, 30 May 2013 11:53:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=961; q=dns/txt; s=iport; t=1369939987; x=1371149587; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=cqnb2DbicQxsP+xQ9xpM6+PpVtvnFQb/f51As0EfOV4=; b=bvLmE1nvi21G7a2wLFjsc3bAycVPX0cIGRkha19qvI6YxQ4ra/13XyPb hIn8lm2noxW3qzGNEy8bkGc2DOUf80w7xbu/w01AkUHbrcqgcI51pQ2qN Pdh3iYbsoM0IjzDLhi5vyWz7Psk9x1Jp8cYUWIOscqtPPJ7cF+9B9tKxN U=; X-IronPort-AV: E=Sophos;i="4.87,772,1363132800"; d="scan'208";a="216905387" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 30 May 2013 18:53:07 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4UIr6rh031896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 May 2013 18:53:06 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id r4UIr5kH019589; Thu, 30 May 2013 14:53:05 -0400 From: Eric Rosen To: Kireeti Kompella In-reply-to: Your message of Fri, 24 May 2013 15:00:34 -0700. <37E234C8-8167-4375-8EE2-693E3041140A@gmail.com> Date: Thu, 30 May 2013 14:53:05 -0400 Message-ID: <19588.1369939985@erosen-linux> Cc: MPLS Subject: Re: [mpls] comments on draft-kompella-mpls-special-purpose-labels-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 18:53:17 -0000 Eric> I think it would be better to have a much smaller piece of the label Eric> space to be allocated under the "standards action" policy. Kireeti> Okay, will reduce. Question is, what to do with the rest of the Kireeti> label space: make reserved, or FCFS (or both)? If FCFS, how big? I think the range 16-63 should be ample for the "Standards Action" range, assuming that we don't really want to ever have too many of these. If the WG thinks this range is too small, perhaps 16-255. Usually I like the FCFS policy, but I don't think FCFS is appropriate for special purpose labels, so I would favor making the rest of the space reserved. I see the draft creates an "experimental" range 1048560-1048575. Was any consideration given to having a Standards Action range of something like 16-240 and an experimental range of 241-255? Then all the possible special purpose label values would be in a small and contiguous number space. From stbryant@cisco.com Thu May 30 13:02:46 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1023E21F92FC for ; Thu, 30 May 2013 13:02:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.341 X-Spam-Level: X-Spam-Status: No, score=-110.341 tagged_above=-999 required=5 tests=[AWL=-0.194, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLafT4kPXHxa for ; Thu, 30 May 2013 13:02:40 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 4A62021F92E8 for ; Thu, 30 May 2013 13:02:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2047; q=dns/txt; s=iport; t=1369944160; x=1371153760; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=yTjT+OcNGuHjOQGw3tRttLn+ngXaewEfOa8FkHJtUb4=; b=TMfa3E+VZWSHZrzYr3LvcFbBFMIk1XJezEHMIcAylZGPIisNGQrpHpHs axrx8dO8L8dEwZXFyMFZdQBwfrP5NqATXJMSPv5yqwktL6qk6AL8s7QId 2VLshOskilWZk7w3LJZyXBh6qf8g6QoHvNlLoevfDu3mqCxFzl1MPBln9 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsgKABGwp1GQ/khL/2dsb2JhbABZgwkwgzu+SQ8DAX4WdIIjAQEBBCMPAQUzAwoBDAICCQIRBAEBAQICBRYIAwICCQMCAQIBCSsGAwgTAQUCAQGICQyNcZs6kW4EgSKMNE9RIgcGEIItgRQDlz6RQIFYgTiBcA X-IronPort-AV: E=Sophos;i="4.87,772,1363132800"; d="scan'208";a="14354311" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 30 May 2013 20:02:29 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4UK2RTX008183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 May 2013 20:02:27 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r4UK2PR2019738; Thu, 30 May 2013 21:02:26 +0100 (BST) Message-ID: <51A7B051.7040306@cisco.com> Date: Thu, 30 May 2013 21:02:25 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <62CCD4C52ACDAD4481149BD5D8A72FD316C76D83@CH1PRD0510MB355.namprd05.prod.outlook.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081C3B3E@NKGEML512-MBS.china.huawei.com> <51A72ADB.9090009@cisco.com> <51A7499F.1050000@pi.nu> <013501ce5d53$98aebbe0$ca0c33a0$@olddog.co.uk> In-Reply-To: <013501ce5d53$98aebbe0$ca0c33a0$@olddog.co.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: 'MPLS WG Mailing List' , draft-kompella-mpls-special-purpose-labels@tools.ietf.org, mpls-chairs@tools.ietf.org, 'Loa Andersson' Subject: Re: [mpls] =?utf-8?b?562U5aSNOiBNUExTIFdHIGxhc3QgY2FsbCBvbiBkcmFmdC1r?= =?utf-8?q?ompella-mpls-special-purpose-labels-04?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: stbryant@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 May 2013 20:02:46 -0000 Adrian That would suggest that we prefer to allocate from the new range and keep the old range for critical new functions that really are stack size sensitive. Stewart On 30/05/2013 17:34, Adrian Farrel wrote: > I kind of agree with Stewart and Xiaohu, but I note that the regular special purpose label space (0-14) *is*already* almost used out. > Thus, making the statement would have no effect because we are already passed the point. > And hence there is no point in adding the text. > > Adrian (just a humble co-author) > > > > >> -----Original Message----- >> From: Loa Andersson [mailto:loa@pi.nu] >> Sent: 30 May 2013 13:44 >> To: stbryant@cisco.com >> Cc: Xuxiaohu; MPLS WG Mailing List; draft-kompella-mpls-special-purpose- >> labels@tools.ietf.org; mpls-chairs@tools.ietf.org >> Subject: Re: [mpls] ç­”å¤: MPLS WG last call on draft-kompella-mpls-special- >> purpose-labels-04 >> >> All, >> >> I agree with Stewart, how the label will be parsed, will have a lot >> of impact when we decide how to allocate a new special purspose label. >> >> /Loa >> >> On 2013-05-30 12:32, Stewart Bryant wrote: >>> On 30/05/2013 04:07, Xuxiaohu wrote: >>>> how about explicitly stating that “The Extended special purpose labels >>>> SHOULD NOT be allocated by IANA until the regular special purpose >>>> label space (0-14) has been almost used out.†or something like that. >>>> >>> I would disagree with that. There are far more of the new SP labels than >>> the old, and the old one's take less stack space and less parsing, so I >>> think the right think to do is to consider each application on its own >>> merits. >>> >>> Stewart (AD hat off) >>> >>> >> -- >> >> >> Loa Andersson email: loa@mail01.huawei.com >> Senior MPLS Expert loa@pi.nu >> Huawei Technologies (consultant) phone: +46 739 81 21 64 > . > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From mach.chen@huawei.com Thu May 30 18:21:24 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD7C21F9930 for ; Thu, 30 May 2013 18:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IyCjn0WwmffI for ; Thu, 30 May 2013 18:21:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1D90B21F9926 for ; Thu, 30 May 2013 18:21:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ARY63646; Fri, 31 May 2013 01:21:11 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 31 May 2013 02:20:35 +0100 Received: from SZXEML450-HUB.china.huawei.com (10.82.67.193) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 31 May 2013 02:21:10 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.243]) by szxeml450-hub.china.huawei.com ([10.82.67.193]) with mapi id 14.01.0323.007; Fri, 31 May 2013 09:21:07 +0800 From: Mach Chen To: Ross Callon , "mpls@ietf.org" Thread-Topic: [mpls] OOps, Poll for adoption (was: MPLS WG last call on draft-kompella-mpls-special-purpose-labels-04) Thread-Index: AQHOXUYiZ/qQsTTb6EC4pTEFAGKP35kefj/Q Date: Fri, 31 May 2013 01:21:06 +0000 Message-ID: References: <62CCD4C52ACDAD4481149BD5D8A72FD316C8C753@CH1PRD0510MB355.namprd05.prod.outlook.com> In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316C8C753@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.96.176] Content-Type: multipart/alternative; boundary="_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BAAE26szxeml558mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-kompella-mpls-special-purpose-labels@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] OOps, Poll for adoption (was: MPLS WG last call on draft-kompella-mpls-special-purpose-labels-04) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 01:21:24 -0000 --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BAAE26szxeml558mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes/support. In addition, regarding the range of the extended special label, I intend to= agree with Eric's suggestion in his reply to Kireeti. Best regards, Mach From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ros= s Callon Sent: Thursday, May 30, 2013 10:58 PM To: Ross Callon; mpls@ietf.org Cc: draft-kompella-mpls-special-purpose-labels@tools.ietf.org; mpls-chairs@= tools.ietf.org Subject: [mpls] OOps, Poll for adoption (was: MPLS WG last call on draft-ko= mpella-mpls-special-purpose-labels-04) Oops. I meant to say "poll for adoption". The message should be: This is to start a "two week" poll on adopting draft-kompella-mpls-special-purpose-labels-04 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end June 13, 2013. Thanks, Ross _____________________________________________ From: Ross Callon Sent: Wednesday, May 29, 2013 4:20 PM To: mpls@ietf.org Cc: 'draft-kompella-mpls-special-purpose-labels@tools.ietf.org'; mpls-chair= s@tools.ietf.org; 'VIGOUREUX, MARTIN (MARTIN)' Subject: MPLS WG last call on draft-kompella-mpls-special-purpose-labels-04 Working Group, this is to start a two week Working Group last call on draft-kompella-mpls-special-purpose-labels-04. Please send your comments to the mpls working group mailing list (mpls@ietf.org). Please send both technical comments, and (if you are happy with the document as is) also send indications of support. There are no IPR claims against this draft. The co-authors have earlier stated that they are not aware of any IPR applicable to this draft. If anyone else in the working group are aware of IPRs claims against this draft, the time to disclose that is now. This working group last call will end on June 13, 2013. Ross for the wg co-chairs --_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BAAE26szxeml558mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Yes/support.

=  

= In addition, regarding the range of the extended special label, I intend to agree with Eric’s suggest= ion in his reply to Kireeti.

=  

= Best regards,

= Mach

=  

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Thursday, May 30, 2013= 10:58 PM
To: Ross Callon; mpls@ietf.o= rg
Cc: draft-kompella-mpls-spec= ial-purpose-labels@tools.ietf.org; mpls-chairs@tools.ietf.org
Subject: [mpls] OOps, Poll f= or adoption (was: MPLS WG last call on draft-kompella-mpls-special-purpose-= labels-04)

 

Oops. I meant to s= ay “poll for adoption”. The message should be:

 <= /span>

This is to start a= "two week" poll on adopting

draft-kompella-mpl= s-special-purpose-labels-04

as an MPLS working= group document.

 <= /span>

Please send your c= omments (support/not support) to the mpls working<= /p>

group mailing list= (mpls@ietf.org).

 <= /span>

This poll will end= June 13, 2013.

 <= /span>

Thanks, Ross<= /o:p>

_______________= ______________________________
From: Ross Callon
Sent: Wednesday, May 29, 201= 3 4:20 PM
To: mpls@ietf.org
Cc: 'draft-kompella-mpls-spe= cial-purpose-labels@tools.ietf.org'; mpls-chairs@tools.ietf.org; 'VIGOUREUX= , MARTIN (MARTIN)'
Subject: MPLS WG last call o= n draft-kompella-mpls-special-purpose-labels-04

 =

 =

Working Group,<= /span>

 

this is to start a two week Working Group last= call on

draft-kompella-mpls-special-purpose-labels-04.=

 

Please send your comments to the mpls working = group

mailing list (mpls@ietf.org).

 

Please send both technical comments, and (if y= ou are happy

with the document as is) also send indications= of support.

 

There are no IPR claims against this draft.

 

The co-authors have earlier stated that they a= re not aware

of any IPR applicable to this draft.

 

If anyone else in the working group are aware = of IPRs claims against

this draft, the time to disclose that is now.<= /span>

 

This working group last call will end on June = 13, 2013.

 

Ross

for the wg co-chairs

 

 =

 =

--_000_F73A3CB31E8BE34FA1BBE3C8F0CB2AE255BAAE26szxeml558mbschi_-- From adrian@olddog.co.uk Thu May 30 19:31:45 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9216C21F8930 for ; Thu, 30 May 2013 19:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.373 X-Spam-Level: X-Spam-Status: No, score=-2.373 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiSmgcaYZhAw for ; Thu, 30 May 2013 19:31:40 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBF821F88EA for ; Thu, 30 May 2013 19:31:39 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4V2VXuX030552; Fri, 31 May 2013 03:31:33 +0100 Received: from 950129200 (HKRnf12760.tokyo-ip.dti.ne.jp [27.120.235.10]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4V2VRjc030517 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 31 May 2013 03:31:29 +0100 From: "Adrian Farrel" To: References: <62CCD4C52ACDAD4481149BD5D8A72FD316C76D83@CH1PRD0510MB355.namprd05.prod.outlook.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE081C3B3E@NKGEML512-MBS.china.huawei.com> <51A72ADB.9090009@cisco.com> <51A7499F.1050000@pi.nu> <013501ce5d53$98aebbe0$ca0c33a0$@olddog.co.uk> <51A7B051.7040306@cisco.com> In-Reply-To: <51A7B051.7040306@cisco.com> Date: Fri, 31 May 2013 03:31:23 +0100 Message-ID: <027601ce5da6$f51aed60$df50c820$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHMDKeoFfRAZVE2wLG+gCviT5U7EwIApuziAfe0XTAB/z9UygKSo8ZaAjbVvSyYzSmmMA== Content-Language: en-gb Cc: 'MPLS WG Mailing List' , draft-kompella-mpls-special-purpose-labels@tools.ietf.org, mpls-chairs@tools.ietf.org, 'Loa Andersson' Subject: Re: [mpls] =?utf-8?b?562U5aSNOiBNUExTIFdHIGxhc3QgY2FsbCBvbiBkcmFmdC1r?= =?utf-8?q?ompella-mpls-special-purpose-labels-04?= X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 02:31:45 -0000 Yes (or maybe). I think it suggests that we should consider this on a case-by-case = basis. Since the labels are allocated as Standards Action (after this I-D = becomes an RFC) it seems likely that "appropriate care" can be taken by = the working group on a case-by-case basis. Ciao, Adrian > -----Original Message----- > From: Stewart Bryant [mailto:stbryant@cisco.com] > Sent: 30 May 2013 21:02 > To: adrian@olddog.co.uk > Cc: 'Loa Andersson'; 'Xuxiaohu'; 'MPLS WG Mailing List'; = draft-kompella-mpls- > special-purpose-labels@tools.ietf.org; mpls-chairs@tools.ietf.org > Subject: Re: [mpls] =E7=AD=94=E5=A4=8D: MPLS WG last call on = draft-kompella-mpls-special- > purpose-labels-04 >=20 > Adrian >=20 > That would suggest that we prefer to allocate from the new range and > keep the > old range for critical new functions that really are stack size = sensitive. >=20 > Stewart >=20 >=20 >=20 > On 30/05/2013 17:34, Adrian Farrel wrote: > > I kind of agree with Stewart and Xiaohu, but I note that the regular = special > purpose label space (0-14) *is*already* almost used out. > > Thus, making the statement would have no effect because we are = already > passed the point. > > And hence there is no point in adding the text. > > > > Adrian (just a humble co-author) > > > > > > > > > >> -----Original Message----- > >> From: Loa Andersson [mailto:loa@pi.nu] > >> Sent: 30 May 2013 13:44 > >> To: stbryant@cisco.com > >> Cc: Xuxiaohu; MPLS WG Mailing List; = draft-kompella-mpls-special-purpose- > >> labels@tools.ietf.org; mpls-chairs@tools.ietf.org > >> Subject: Re: [mpls] =E7=AD=94=E5=A4=8D: MPLS WG last call on = draft-kompella-mpls-special- > >> purpose-labels-04 > >> > >> All, > >> > >> I agree with Stewart, how the label will be parsed, will have a lot > >> of impact when we decide how to allocate a new special purspose = label. > >> > >> /Loa > >> > >> On 2013-05-30 12:32, Stewart Bryant wrote: > >>> On 30/05/2013 04:07, Xuxiaohu wrote: > >>>> how about explicitly stating that =E2=80=9CThe Extended special = purpose labels > >>>> SHOULD NOT be allocated by IANA until the regular special purpose > >>>> label space (0-14) has been almost used out.=E2=80=9D or = something like that. > >>>> > >>> I would disagree with that. There are far more of the new SP = labels than > >>> the old, and the old one's take less stack space and less parsing, = so I > >>> think the right think to do is to consider each application on its = own > >>> merits. > >>> > >>> Stewart (AD hat off) > >>> > >>> > >> -- > >> > >> > >> Loa Andersson email: loa@mail01.huawei.com > >> Senior MPLS Expert loa@pi.nu > >> Huawei Technologies (consultant) phone: +46 739 81 21 64 > > . > > >=20 >=20 > -- > For corporate legal information go to: >=20 > http://www.cisco.com/web/about/doing_business/legal/cri/index.html From adrian@olddog.co.uk Thu May 30 20:32:32 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B94421F9678 for ; Thu, 30 May 2013 20:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvnhGTg4+3hH for ; Thu, 30 May 2013 20:32:26 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 1B85E21F96E1 for ; Thu, 30 May 2013 20:32:21 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4V3WEj0012941; Fri, 31 May 2013 04:32:14 +0100 Received: from 950129200 (HKRnf12760.tokyo-ip.dti.ne.jp [27.120.235.10]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r4V3W5WZ012902 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 31 May 2013 04:32:13 +0100 From: "Adrian Farrel" To: , "'Loa Andersson'" Date: Fri, 31 May 2013 04:32:02 +0100 Message-ID: <028501ce5daf$6fbd73f0$4f385bd0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac5drxxVoqxlH4QMSGWrxt9E8DmE6g== Content-Language: en-gb Cc: mpls@ietf.org, draft-kompella-mpls-special-purpose-labels-02@tools.ietf.org Subject: Re: [mpls] Concerns about draft-kompella-mpls-special-purpose-labels-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 03:32:32 -0000 Hi Eric, > Loa> However there is one (maybe two) things in the draft that is a little > Loa> more urgent than the extension of the special purpose label space. > > Loa> 1. the renaming of "reserved labels" to "special purpose labels", to > Loa> align with how IANA uses the word "reserved". > > Loa> 2. The procedures to deprecate and retire special purpose labels. > > What is the urgency? None that I can see. It is something that needs to be done before we run out of reserved labels. At current rate of burn we have a decade or so. >From my perspective, the urgency is simply that we have some people with the b/w to sort it out today, and we haven't lost all of the original MPLS clue yet. > Loa> if you find a special purpose label that you don't recognize you should > Loa> silently drop that packet. So a packet with an unrecognized extension > Loa> label should not get into the hashing at all. > > If an unrecognized label rises to the top of the label stack, the packet > should be dropped. However, I don't think there's any requirement for a > router to drop a packet just because there's an unrecognized special purpose > label somewhere in the stack. So if hashing is done on the entire stack, I > think Pablo is right that labels from the extended special purpose label > space will get into the hash. Absolutely! Anyone who suggests inspecting every label in the stack at every hop in case one is not recognised is certifiable :-) There are two questions: 1. The unrecognised label shows for active processing (i.e. top of stack). Drop packet it only option. 2. The unrecognised label shows for passive processing (e.g., hash). Just use it as normal and move on. If this is not clear from existing work and from this document, it should be clearly stated in a new revision. > Loa> I'd really would like to allocate 0-1023 after 15 for the extended > Loa> special purpose > > How about 0-63? Or 0-255? How much of what follows is just "here is another way of doing it" and how much is "there is a really good reason for this"? I think I see a request for any special purpose label (in this new space or in the old space) to just use the least significant bits. Is this a hardware implementation thing? This cuts back to something you said in a previous mail: to process a special purpose label, an implementation has never had to look up a 20-bit label, only a 4 bit label. This is true. But so what? To look up a special purpose label, an implementation has never had to look up an extended special purpose label, and we are changing that. So I think the argument might be that processing of special purpose labels is likely to require special hardware processing, with a sort of look-up table of functions (a jump table?). Such hardware would benefit from a relatively constrained set of potential label values. Do I have that right? > If the WG were to decide that Pablo's point is valid, one could deal with it > by treating several of the currently unused special purpose labels (I think > there are nine available) as extension labels, each identifying a new 4-bit > extended special purpose label space. That scheme would satisfy Pablo's > criteria, but would not require more than two label stack entries to > represent any of the special purpose labels. (I guess each such label space > would have to assign 7 as the entropy label.) > > I'm not advocating this scheme, but I do think it is better than using the > cardinality of a sequence of 15's to identify a particular special purpose > label space ;-) > > With regard to Jeff's suggestion to just expand the special purpose label > space by several bits, I think the problem is the following. There are > bound to be routers in the network that do not know that 17, say, is now a > special purpose label. Such routers may bind dynamically 17 to a FEC or > tunnel. This will add an exciting bit of unpredictability to the handling > of packets carrying that label. Exactly. That's why we had to use (at least) one old space label to say "another special label follows". I was sure we had said this in the I-D, but can't recall. > Jeff> Plenty of routers exist that are unwilling to look at a label stack > Jeff> deeper than 3..5 labels. > > I'm guessing that "unwilling to look at" means that the high speed memory > used to hold the packet header cannot hold more than 3 to 5 labels. This > would only be a problem for a P router if it had to interpret (in the fast > path) an extended special purpose label and 2-4 regular labels (or a couple > of special purpose labels) in order to dispatch the packet properly. It > might be interesting to examine such scenarios, if someone can present them > without getting overly emotional about it ;-) I am not convinced by Jeff's argument. Firstly, what does "look at" mean? Secondly, by publishing this now, there is a lead time of 7 special purpose label allocations before implementations have to be capable of this (maybe *that* is the urgency?) Ciao, Adrian (as co-author) From loa@pi.nu Fri May 31 01:34:05 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AC9B21F941F for ; Fri, 31 May 2013 01:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.174 X-Spam-Level: X-Spam-Status: No, score=-102.174 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zH+uhTxYtWMO for ; Fri, 31 May 2013 01:33:59 -0700 (PDT) Received: from pipi.pi.nu (pipi.pi.nu [83.168.239.141]) by ietfa.amsl.com (Postfix) with ESMTP id D180B21F9425 for ; Fri, 31 May 2013 01:33:58 -0700 (PDT) Received: from [192.168.1.133] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by pipi.pi.nu (Postfix) with ESMTPSA id 5CD5C180101A; Fri, 31 May 2013 10:33:56 +0200 (CEST) Message-ID: <51A86076.8090102@pi.nu> Date: Fri, 31 May 2013 10:33:58 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: adrian@olddog.co.uk References: <028501ce5daf$6fbd73f0$4f385bd0$@olddog.co.uk> In-Reply-To: <028501ce5daf$6fbd73f0$4f385bd0$@olddog.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org, draft-kompella-mpls-special-purpose-labels-02@tools.ietf.org Subject: Re: [mpls] Concerns about draft-kompella-mpls-special-purpose-labels-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 08:34:05 -0000 Adrian and Eric, On 2013-05-31 05:32, Adrian Farrel wrote: > Hi Eric, > >> Loa> However there is one (maybe two) things in the draft that is a little >> Loa> more urgent than the extension of the special purpose label space. >> >> Loa> 1. the renaming of "reserved labels" to "special purpose labels", to >> Loa> align with how IANA uses the word "reserved". >> >> Loa> 2. The procedures to deprecate and retire special purpose labels. >> >> What is the urgency? > > None that I can see. Maybe "urgency" was the wrong word :) . What I meant was that I want to be able to fix up the IANA registries so that our RFC and IDs use the terminology as the registries. We can do that now without having decided exactly on the the size and semantics of the extended purpose labels. Also retiring labels is something we can do already now - as soon as we agree on procedures. That has nothing to do with that the original special purpose expires or not, it mostly how we keep our IANA registries nice and tidy. /Loa > > It is something that needs to be done before we run out of reserved labels. At > current rate of burn we have a decade or so. > > From my perspective, the urgency is simply that we have some people with the b/w > to sort it out today, and we haven't lost all of the original MPLS clue yet. > >> Loa> if you find a special purpose label that you don't recognize you should >> Loa> silently drop that packet. So a packet with an unrecognized extension >> Loa> label should not get into the hashing at all. >> >> If an unrecognized label rises to the top of the label stack, the packet >> should be dropped. However, I don't think there's any requirement for a >> router to drop a packet just because there's an unrecognized special purpose >> label somewhere in the stack. So if hashing is done on the entire stack, I >> think Pablo is right that labels from the extended special purpose label >> space will get into the hash. > > Absolutely! > > Anyone who suggests inspecting every label in the stack at every hop in case one > is not recognised is certifiable :-) > > There are two questions: > 1. The unrecognised label shows for active processing (i.e. top of stack). Drop > packet it only option. > 2. The unrecognised label shows for passive processing (e.g., hash). Just use it > as normal and move on. > > If this is not clear from existing work and from this document, it should be > clearly stated in a new revision. > >> Loa> I'd really would like to allocate 0-1023 after 15 for the extended >> Loa> special purpose >> >> How about 0-63? Or 0-255? > > How much of what follows is just "here is another way of doing it" and how much > is "there is a really good reason for this"? > > I think I see a request for any special purpose label (in this new space or in > the old space) to just use the least significant bits. Is this a hardware > implementation thing? > > This cuts back to something you said in a previous mail: to process a special > purpose label, an implementation has never had to look up a 20-bit label, only a > 4 bit label. This is true. But so what? To look up a special purpose label, an > implementation has never had to look up an extended special purpose label, and > we are changing that. > > So I think the argument might be that processing of special purpose labels is > likely to require special hardware processing, with a sort of look-up table of > functions (a jump table?). Such hardware would benefit from a relatively > constrained set of potential label values. > > Do I have that right? > >> If the WG were to decide that Pablo's point is valid, one could deal with it >> by treating several of the currently unused special purpose labels (I think >> there are nine available) as extension labels, each identifying a new 4-bit >> extended special purpose label space. That scheme would satisfy Pablo's >> criteria, but would not require more than two label stack entries to >> represent any of the special purpose labels. (I guess each such label space >> would have to assign 7 as the entropy label.) >> >> I'm not advocating this scheme, but I do think it is better than using the >> cardinality of a sequence of 15's to identify a particular special purpose >> label space ;-) >> >> With regard to Jeff's suggestion to just expand the special purpose label >> space by several bits, I think the problem is the following. There are >> bound to be routers in the network that do not know that 17, say, is now a >> special purpose label. Such routers may bind dynamically 17 to a FEC or >> tunnel. This will add an exciting bit of unpredictability to the handling >> of packets carrying that label. > > Exactly. That's why we had to use (at least) one old space label to say "another > special label follows". > I was sure we had said this in the I-D, but can't recall. > >> Jeff> Plenty of routers exist that are unwilling to look at a label stack >> Jeff> deeper than 3..5 labels. >> >> I'm guessing that "unwilling to look at" means that the high speed memory >> used to hold the packet header cannot hold more than 3 to 5 labels. This >> would only be a problem for a P router if it had to interpret (in the fast >> path) an extended special purpose label and 2-4 regular labels (or a couple >> of special purpose labels) in order to dispatch the packet properly. It >> might be interesting to examine such scenarios, if someone can present them >> without getting overly emotional about it ;-) > > I am not convinced by Jeff's argument. > Firstly, what does "look at" mean? > Secondly, by publishing this now, there is a lead time of 7 special purpose > label allocations before implementations have to be capable of this (maybe > *that* is the urgency?) > > Ciao, > Adrian (as co-author) > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From rcallon@juniper.net Fri May 31 07:49:06 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485D121F8D2B for ; Fri, 31 May 2013 07:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.799 X-Spam-Level: X-Spam-Status: No, score=-101.799 tagged_above=-999 required=5 tests=[AWL=-0.334, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_RAND_6=2, UNRESOLVED_TEMPLATE=3.132, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vOEs2l4jYbH2 for ; Fri, 31 May 2013 07:48:59 -0700 (PDT) Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 6125F21F8D31 for ; Fri, 31 May 2013 07:48:59 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKUai4W8mNuMW+7JFaO6MyMhhYW/YSZ6Hu@postini.com; Fri, 31 May 2013 07:48:59 PDT Received: from P-CLDFE02-HQ.jnpr.net (172.24.192.60) by P-EMHUB01-HQ.jnpr.net (172.24.192.35) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 31 May 2013 07:47:32 -0700 Received: from o365mail.juniper.net (207.17.137.149) by o365mail.juniper.net (172.24.192.60) with Microsoft SMTP Server id 14.1.355.2; Fri, 31 May 2013 07:47:32 -0700 Received: from va3outboundpool.messaging.microsoft.com (216.32.180.12) by o365mail.juniper.net (207.17.137.149) with Microsoft SMTP Server (TLS) id 14.1.355.2; Fri, 31 May 2013 07:50:50 -0700 Received: from mail16-va3-R.bigfish.com (10.7.14.239) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Fri, 31 May 2013 14:47:31 +0000 Received: from mail16-va3 (localhost [127.0.0.1]) by mail16-va3-R.bigfish.com (Postfix) with ESMTP id 0CEE93A016F for ; Fri, 31 May 2013 14:47:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.244.213; KIP:(null); UIP:(null); (null); H:CH1PRD0510HT002.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -22 X-BigFish: PS-22(zz9371Ic85fh4015Izz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6hzz1033IL17326ah18c673h1c8fb4h8275bh8275dhz31h2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1155h) Received-SPF: softfail (mail16-va3: transitioning domain of juniper.net does not designate 157.56.244.213 as permitted sender) client-ip=157.56.244.213; envelope-from=rcallon@juniper.net; helo=CH1PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; Received: from mail16-va3 (localhost.localdomain [127.0.0.1]) by mail16-va3 (MessageSwitch) id 1370011648825559_10728; Fri, 31 May 2013 14:47:28 +0000 (UTC) Received: from VA3EHSMHS021.bigfish.com (unknown [10.7.14.252]) by mail16-va3.bigfish.com (Postfix) with ESMTP id C3D92220073; Fri, 31 May 2013 14:47:28 +0000 (UTC) Received: from CH1PRD0510HT002.namprd05.prod.outlook.com (157.56.244.213) by VA3EHSMHS021.bigfish.com (10.7.99.31) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 31 May 2013 14:47:27 +0000 Received: from CH1PRD0510MB355.namprd05.prod.outlook.com ([169.254.2.41]) by CH1PRD0510HT002.namprd05.prod.outlook.com ([10.255.150.37]) with mapi id 14.16.0311.000; Fri, 31 May 2013 14:47:27 +0000 From: Ross Callon To: "mpls@ietf.org" , "draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org" Thread-Topic: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 Thread-Index: Ac5KBNrRqy5GgTuxR1iRJSatXBuqdwUB+BlQ Date: Fri, 31 May 2013 14:47:27 +0000 Message-ID: <62CCD4C52ACDAD4481149BD5D8A72FD316C8FE8B@CH1PRD0510MB355.namprd05.prod.outlook.com> References: <62CCD4C52ACDAD4481149BD5D8A72FD316C3ED09@CH1PRD0510MB355.namprd05.prod.outlook.com> In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316C3ED09@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [66.129.232.2] Content-Type: multipart/alternative; boundary="_000_62CCD4C52ACDAD4481149BD5D8A72FD316C8FE8BCH1PRD0510MB355_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net X-FOPE-CONNECTOR: Id%12219$Dn%TOOLS.IETF.ORG$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net Cc: "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 14:49:06 -0000 --_000_62CCD4C52ACDAD4481149BD5D8A72FD316C8FE8BCH1PRD0510MB355_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This poll has ended. We do not currently have consensus on the way forward, and thus draft-pac-m= pls-lsp-ping-tlvs-and-sub-tlvs-registry-02 is not accepted as a WG draft at= the current time. However, it is clear that a solution, or at least some c= larification, is needed to address the issue that motivated draft-pac-mpls-= lsp-ping-tlvs-and-sub-tlvs-registry. As such authors of draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry are w= orking offline with authors of RFC 4379 to come up with a solution. We can = expect to have further discussion on the MPLS email list and possibly in Be= rlin. Thanks, Ross From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ros= s Callon Sent: Sunday, May 05, 2013 10:53 PM To: mpls@ietf.org; draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools= .ietf.org Cc: mpls-chairs@tools.ietf.org Subject: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlvs-and-s= ub-tlvs-registry-02 Working group, this is to start a "two week" poll on adopting draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group mailing list (mpls@ietf.org). This poll will end May 20th, 2013. Ross (as mpls wg co-chair) --_000_62CCD4C52ACDAD4481149BD5D8A72FD316C8FE8BCH1PRD0510MB355_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This poll has ended.

 <= /p>

We do not currently have = consensus on the way forward, and thus draft-pac-mpls-lsp-ping-tlvs-and-sub= -tlvs-registry-02 is not accepted as a WG draft at the current time. However, it is clear that a solution, or at least some clarification= , is needed to address the issue that motivated draft-pac-mpls-lsp-ping-tlv= s-and-sub-tlvs-registry.

 <= /p>

As such authors of draft-= pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry are working offline with autho= rs of RFC 4379 to come up with a solution. We can expect to have further discussion on the MPLS email list and possibly in Berlin. =

 <= /p>

Thanks, Ross

 <= /p>

From: mpls-bou= nces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ross Callon
Sent: Sunday, May 05, 2013 10:53 PM
To: mpls@ietf.org; draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registr= y@tools.ietf.org
Cc: mpls-chairs@tools.ietf.org
Subject: [mpls] Poll for WG adoption for draft-pac-mpls-lsp-ping-tlv= s-and-sub-tlvs-registry-02

 

Working group,

 

this is to start a "two week" poll on adopting

draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-02

as an MPLS working group document.

 

Please send your comments (support/not support) to the mpls working<= /o:p>

group mailing list (mpls@ietf.org).<= o:p>

 

This poll will end May 20th, 2013.

 

Ross

(as mpls wg co-chair)

 

 

--_000_62CCD4C52ACDAD4481149BD5D8A72FD316C8FE8BCH1PRD0510MB355_-- From erosen@cisco.com Fri May 31 07:50:32 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE20621F8D31 for ; Fri, 31 May 2013 07:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KJNeesNVfvCx for ; Fri, 31 May 2013 07:50:27 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 2FF4521F86D5 for ; Fri, 31 May 2013 07:50:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3202; q=dns/txt; s=iport; t=1370011827; x=1371221427; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=/HBKGssJYe1ZvT4VAmnOucdW9x3jOw9YswG8ChOkAPI=; b=cbDQdVnDZ4pAiRzzz3Tc+tgNyrLRk81woKZUCAykJcdYWN9Us+YvShYg h8XiPV/bD9LCRqLHQGRXgdemIUbX+GBIRoGmMNmz3PdtF+gBbbNp6Egwm Z6yK/2vSoywYxOMdq+rZ5wtN43CyxfBki48CWwiBqvsKnYqbdG54ikDQY A=; X-IronPort-AV: E=Sophos;i="4.87,779,1363132800"; d="scan'208";a="217231115" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 31 May 2013 14:50:25 +0000 Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4VEoOkk009818 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 31 May 2013 14:50:25 GMT Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id r4VEoN18007386; Fri, 31 May 2013 10:50:23 -0400 From: Eric Rosen To: adrian@olddog.co.uk In-reply-to: Your message of Fri, 31 May 2013 04:32:02 +0100. <028501ce5daf$6fbd73f0$4f385bd0$@olddog.co.uk> Date: Fri, 31 May 2013 10:50:23 -0400 Message-ID: <7385.1370011823@erosen-linux> Cc: mpls@ietf.org, draft-kompella-mpls-special-purpose-labels-02@tools.ietf.org, 'Loa Andersson' Subject: Re: [mpls] Concerns about draft-kompella-mpls-special-purpose-labels-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: erosen@cisco.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 14:50:33 -0000 Adrian> I think I see a request for any special purpose label (in this new Adrian> space or in the old space) to just use the least significant Adrian> bits. Is this a hardware implementation thing? Adrian> So I think the argument might be that processing of special purpose Adrian> labels is likely to require special hardware processing, with a sort Adrian> of look-up table of functions (a jump table?). Such hardware would Adrian> benefit from a relatively constrained set of potential label values. Adrian> Do I have that right? I don't want to make predictions about how hardware will be built in the future. However, I don't see any possible benefit to requiring the hardware to do a 20-bit lookup when we only expect to see a small number of codepoints (certainly less than 100) assigned. Keep the special purpose label values in the low order octet and let the hardware designers decide whether a full 20-bit lookup is the most cost-effective way to build the hardware. Another perspective: the WG might at some later time decide to use the higher order bits for something else. Eric> So if hashing is done on the entire stack, I think Pablo is right that Eric> labels from the extended special purpose label space will get into the Eric> hash. Adrian> [If the] unrecognised label shows for passive processing (e.g., Adrian> hash). Just use it as normal and move on. Adrian> If this is not clear from existing work and from this document, it Adrian> should be clearly stated in a new revision. This would put the draft at odds with RFC 6790, which says "reserved labels MUST NOT be used as keys for the load-balancing function". I can't tell whether the draft intends to update RFC 6790, because the "Updates:" line is truncated by the name of one of the authors ;-) Adrian> I am not convinced by Jeff's argument ... by publishing this now, Adrian> there is a lead time of 7 special purpose label allocations before Adrian> implementations have to be capable of this Now I'm quite confused about your position. Xiaohu stated: Xiaohu> how about explicitly stating that the Extended special purpose Xiaohu> labels SHOULD NOT be allocated by IANA until the regular special Xiaohu> purpose label space (0-14) has been almost used out You replied: Adrian> I note that the regular special purpose label space (0-14) Adrian> *is*already* almost used out. Thus, making the statement would have Adrian> no effect because we are already passed the point. Are you now saying that you've changed your mind? And that you disagree with Stewart's position: Stewart> That would suggest that we prefer to allocate from the new range Stewart> and keep the old range for critical new functions that really are Stewart> stack size sensitive. I tend to agree with Xiaohu (and thus disagree with the positions taken by Stewart and Loa). The new range is not useful until hardware/firmware support for it is ubiquitous, so I don't see how we can begin using it any time soon. Strictly speaking though, this is not an issue for IANA, because it is up to the WG to specify the registry from which an allocation is requested. From skraza@cisco.com Fri May 31 11:28:01 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9256821F91AB for ; Fri, 31 May 2013 11:28:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HaivS+Dlpmhj for ; Fri, 31 May 2013 11:27:55 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 152AC21F90F4 for ; Fri, 31 May 2013 11:27:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2035; q=dns/txt; s=iport; t=1370024875; x=1371234475; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=m2kt2qXrdGWjjzYHM0FkrFA4NS///urI/bRUXUahNX4=; b=VZ1vNpNEO3gAcrPIoG7Vx4QmEwGbo99BKo7rCuK3Lr+EW9DOmK1aJ6+l RnARHjlKXC+Fw0fTpgbwMPozEsLFwyyBYIUoR3Ij0tGqRTupCOW26Nz+s Lv/+0CK2iUgAo3wc9Udi/+O/uBYj2cjXCF41lgo/nOOTZwIuk/gCx8ufK w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlIFANTqqFGtJXG+/2dsb2JhbABagwm/HoEDFnSCIwEBAQMBOjEDBhMEAQgYChQrFyUCBAESCId/BroOBI1bEIEBOIJ2YQOofoFYgTeBcTY X-IronPort-AV: E=Sophos;i="4.87,780,1363132800"; d="scan'208";a="217353076" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 31 May 2013 18:27:54 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r4VIRslS007432 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 May 2013 18:27:54 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.219]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Fri, 31 May 2013 13:27:53 -0500 From: "Kamran Raza (skraza)" To: Loa Andersson , "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "" , "VIGOUREUX, MARTIN (MARTIN)" , "draft-ietf-mpls-ldp-applicability-label-adv@tools.ietf.org" Thread-Topic: OOOOPPS - Sorry Correction - Re: IPR poll on draft-ietf-mpls-ldp-applicability-label-adv Thread-Index: AQHOXQwQ072fGXobL06NDdaLZWIGA5kdtE0AgAH7eAA= Date: Fri, 31 May 2013 18:27:52 +0000 Message-ID: In-Reply-To: <51A709B2.6000505@pi.nu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [161.44.213.25] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [mpls] OOOOPPS - Sorry Correction - Re: IPR poll on draft-ietf-mpls-ldp-applicability-label-adv X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 18:28:01 -0000 >> Are you aware of any IPR that applies to draft-ietf-mpls-ldp- >> applicability-label-adv? As an author, I am not aware of any IPR that applies to this draft. Rgds, -- Kamran On 2013-05-30 4:11 AM, "Loa Andersson" wrote: >Working Group, > >a typo :(. We are not preparing this document for wglc, but we are >preparing the request for publication. > >The IPR are poll is still on. > >/Loa > >On 2013-05-30 10:02, Loa Andersson wrote: >> Working Group and authors; >> >> The authors of draft-ietf-mpls-ldp-applicability-label-adv and >> the working group chairs are working to prepare the draft for working >> group last call. >> >> We IPR poll on this draft before accepting it as a working group >> document. Since this is sometime ago we will do a new before >> starting the working group last call to check whether there is IPR >> on the document that needs to be disclosed. >> >> This mail starts that IPR poll. >> >> Are you aware of any IPR that applies to draft-ietf-mpls-ldp- >> applicability-label-adv? >> >> If so, has this IPR been disclosed in compliance with IETF IPR rules >> (see RFCs 3979, 4879, 3669 and 5378 for more details). >> >> If you are listed as a document author or contributor please respond to >> this email regardless of whether or not you are aware of any relevant >> IPR. *The response needs to be sent to the MPLS wg mailing list.* The >> documents will not advance to the next stage until a response >> has been received from each author and contributor. >> >> If you are on the MPLS WG email list but are not listed as an author or >> contributor, then please explicitly respond only if you are aware of any >> IPR that has not yet been disclosed in conformance with IETF rules. >> >> >> Thanks, Loa >> (as MPLS WG co-chair) > >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 From rajiva@cisco.com Fri May 31 13:54:48 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F72921F8F44 for ; Fri, 31 May 2013 13:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOZ2y1KSf+xK for ; Fri, 31 May 2013 13:54:41 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDDE21F8B98 for ; Fri, 31 May 2013 13:54:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1821; q=dns/txt; s=iport; t=1370033676; x=1371243276; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=dLXr6VdNjn+2t7q3MSOPAJQMW4LdVSVktqxe+T3gdw0=; b=Hnh/ArkVvuOHvEI3s7dIt2VoseoEjRfZAkwJwh9lYSbI4HdtlWTUbL18 k+iGZwmlGTTtU7ARPzh64spch3x+M2VadUF/sI8eq0bXdpaZ0lQ62SjcV Obgxf/KE3+A2AoFAXjnsy8XK1C6NDJHasMgR08UlK7bMRBBnoPOE2osqn 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQFAJ8NqVGtJXHB/2dsb2JhbABZgwkwvneBAxZ0giMBAQEDAQEBATc0CwUHBgEIEQMBAgsUMQYLFAkIAgQBDQUIh3MDCQYMsGcNiH8EjEiCKDEHBoJwYQOVWI4DhSODD4In X-IronPort-AV: E=Sophos;i="4.87,781,1363132800"; d="scan'208";a="217427503" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-3.cisco.com with ESMTP; 31 May 2013 20:54:30 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r4VKsUbQ006426 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 31 May 2013 20:54:30 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.154]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Fri, 31 May 2013 15:54:30 -0500 From: "Rajiv Asati (rajiva)" To: "Eric Rosen (erosen)" , Kireeti Kompella Thread-Topic: [mpls] comments on draft-kompella-mpls-special-purpose-labels-02 Thread-Index: AQHOXWb6vVlABmQyU0yXa2w15TWNJZkf2AUA Date: Fri, 31 May 2013 20:54:29 +0000 Message-ID: In-Reply-To: <19588.1369939985@erosen-linux> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 x-originating-ip: [10.82.220.169] Content-Type: text/plain; charset="us-ascii" Content-ID: <2DF8D1DAA9405D44B7D87281989B6170@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: MPLS Subject: Re: [mpls] comments on draft-kompella-mpls-special-purpose-labels-02 X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 31 May 2013 20:54:48 -0000 > I think the range 16-63 should be ample for the "Standards Action" range, > assuming that we don't really want to ever have too many of these. If >the > WG thinks this range is too small, perhaps 16-255. I don't think that 16-63 is too small, and do think that it is just good enough. What would prompt us to consider 16-255? Cheers, Rajiv -----Original Message----- From: "Eric Rosen (erosen)" Reply-To: "Eric Rosen (erosen)" Date: Thursday, May 30, 2013 2:53 PM To: Kireeti Kompella Cc: "mpls@ietf.org" Subject: Re: [mpls] comments on draft-kompella-mpls-special-purpose-labels-02 >Eric> I think it would be better to have a much smaller piece of the >label >Eric> space to be allocated under the "standards action" policy. > >Kireeti> Okay, will reduce. Question is, what to do with the rest of the >Kireeti> label space: make reserved, or FCFS (or both)? If FCFS, how >big?=20 > >I think the range 16-63 should be ample for the "Standards Action" range, >assuming that we don't really want to ever have too many of these. If the >WG thinks this range is too small, perhaps 16-255. > >Usually I like the FCFS policy, but I don't think FCFS is appropriate for >special purpose labels, so I would favor making the rest of the space >reserved. > >I see the draft creates an "experimental" range 1048560-1048575. Was any >consideration given to having a Standards Action range of something like >16-240 and an experimental range of 241-255? Then all the possible >special >purpose label values would be in a small and contiguous number space. > > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From agmalis@gmail.com Fri May 31 19:38:22 2013 Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 546F121F8D90 for ; Fri, 31 May 2013 19:38:22 -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, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nObOcJJ1L7ih for ; Fri, 31 May 2013 19:38:20 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5FB21F8E6E for ; Fri, 31 May 2013 19:38:19 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id p58so239541wes.12 for ; Fri, 31 May 2013 19:38:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=SojC3CiQMPvN9LY3gj0ZvcxZCVpI2RHFw37fbRCkCFs=; b=MTKc3Tdp9x2ekK3vqM9hXLjn7cEoTb6pqHcnc2ddo9NL7mQ8Kzt21Brd/4thE6+eBJ Tn91zzczFXY75004sde5x9gWsLW2MxIc+gBo4OnOrUSmP0ZPZhC2dzogk0/tLcvuwIJC x5AXtZdhRQRwuzPHWjgrJ6OgpPGLs0OEQqNjFwNUt7Q4jpc8Hnjqo4S5YwcsY4pFmEjU 8BXjL3DAlDhq7CwxvFaFvxg4lXIMzTec+9/Qvupymcn1fmgf6iiAi5Sk3i5hOITLMSHy QmpPJ2iWk8neJ90xRJmSPXdXV0LGgO0R4HRfW26KASQqhSGM3G8YkER3Z5lNbCX9uTfr 2c4A== X-Received: by 10.180.185.225 with SMTP id ff1mr5516200wic.36.1370054298730; Fri, 31 May 2013 19:38:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.83.5 with HTTP; Fri, 31 May 2013 19:37:58 -0700 (PDT) In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316C8C753@CH1PRD0510MB355.namprd05.prod.outlook.com> References: <62CCD4C52ACDAD4481149BD5D8A72FD316C8C753@CH1PRD0510MB355.namprd05.prod.outlook.com> From: "Andrew G. Malis" Date: Sat, 1 Jun 2013 11:37:58 +0900 Message-ID: To: Ross Callon Content-Type: multipart/alternative; boundary=001a11c34ed2cc862804de0e9f7c Cc: "mpls@ietf.org" , "mpls-chairs@tools.ietf.org" , "draft-kompella-mpls-special-purpose-labels@tools.ietf.org" Subject: Re: [mpls] OOps, Poll for adoption (was: MPLS WG last call on draft-kompella-mpls-special-purpose-labels-04) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Jun 2013 02:38:22 -0000 --001a11c34ed2cc862804de0e9f7c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Yes/support Cheers, Andy On Thu, May 30, 2013 at 11:58 PM, Ross Callon wrote: > Oops. I meant to say =93poll for adoption=94. The message should be: > > This is to start a "two week" poll on adopting > draft-kompella-mpls-special-purpose-labels-04 > as an MPLS working group document. > > Please send your comments (support/not support) to the mpls working > group mailing list (*mpls@ietf.org* ). > > This poll will end June 13, 2013. > > Thanks, Ross > _____________________________________________ > *From:* Ross Callon > *Sent:* Wednesday, May 29, 2013 4:20 PM > *To:* mpls@ietf.org > *Cc:* 'draft-kompella-mpls-special-purpose-labels@tools.ietf.org'; > mpls-chairs@tools.ietf.org; 'VIGOUREUX, MARTIN (MARTIN)' > *Subject:* MPLS WG last call on > draft-kompella-mpls-special-purpose-labels-04 > > > Working Group, > > this is to start a two week Working Group last call on > draft-kompella-mpls-special-purpose-labels-04. > > Please send your comments to the mpls working group > mailing list (*mpls@ietf.org* ). > > Please send both technical comments, and (if you are happy > with the document as is) also send indications of support. > > There are no IPR claims against this draft. > > The co-authors have earlier stated that they are not aware > of any IPR applicable to this draft. > > If anyone else in the working group are aware of IPRs claims against > this draft, the time to disclose that is now. > > This working group last call will end on June 13, 2013. > > Ross > for the wg co-chairs > > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > > --001a11c34ed2cc862804de0e9f7c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Yes/support

Cheers,
Andy



On Thu, May 30, = 2013 at 11:58 PM, Ross Callon <rcallon@juniper.net> wrote:=
Oops. I meant to say =93poll for adoption=94. The message should be:
=A0
This is to start a "two week" poll on adopting
draft-kompella-mpls-special-purpose-labels-04
as an MPLS working group document.
=A0
Please send your comments (support/not support) to the mpls working
group mailing list (mpls@ietf.org).
=A0
This poll will end June 13, 2013.
=A0
Thanks, Ross
_________________= ____________________________
From: Ross Callon
Sent: Wednesday, May 29, 2013 4:20 PM
To: mpls@ietf.org=
Cc: 'draft-kompella-mpls-special-purpose-lab= els@tools.ietf.org'; mpls-chairs@tools.ietf.org; 'VIGOUREUX, MARTIN (M= ARTIN)'
Subject: MPLS WG last call on draft-kompella-mpls-special-purpose-la= bels-04
=A0
=A0
Working Group= ,
=A0
this is to st= art a two week Working Group last call on
draft-kompell= a-mpls-special-purpose-labels-04.
=A0
Please send y= our comments to the mpls working group
mailing list = (mpls@ietf.org).
=A0
Please send b= oth technical comments, and (if you are happy
with the docu= ment as is) also send indications of support.
=A0
There are no = IPR claims against this draft.
=A0
The co-author= s have earlier stated that they are not aware
of any IPR ap= plicable to this draft.
=A0
If anyone els= e in the working group are aware of IPRs claims against
this draft, t= he time to disclose that is now.
=A0
This working = group last call will end on June 13, 2013.
=A0
Ross
for the wg co= -chairs
=A0
=A0
=A0

_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls

--001a11c34ed2cc862804de0e9f7c--
mailing list (mpls@ietf.org).
 
Please send both technical comments, and (if you are happy
with the document as is) also send indications of support.
 
There are no IPR claims against this draft.
 
The co-authors have earlier stated that they are not aware
of any IPR applicable to this draft.