From internet-drafts@ietf.org Mon Apr 1 00:21: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 8F9FD21F8801; Mon, 1 Apr 2013 00:21:55 -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 AteYDAZckbrI; Mon, 1 Apr 2013 00:21:54 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DFAB821F87D1; Mon, 1 Apr 2013 00:21: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.43 Message-ID: <20130401072154.23675.1908.idtracker@ietfa.amsl.com> Date: Mon, 01 Apr 2013 00:21:54 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-in-udp-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: Mon, 01 Apr 2013 07:21: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 : Encapsulating MPLS in UDP Author(s) : Xiaohu Xu Nischal Sheth Lucy Yong Carlos Pignataro Yongbing Fan Filename : draft-ietf-mpls-in-udp-01.txt Pages : 9 Date : 2013-04-01 Abstract: Existing technologies to encapsulate Multi-Protocol Label Switching (MPLS) over IP are not adequate for efficient load balancing of MPLS application traffic, such as MPLS-based Layer2 Virtual Private Network (L2VPN) or Layer3 Virtual Private Network (L3VPN) traffic across IP networks. This document specifies additional IP-based encapsulation technology, referred to as MPLS-in-User Datagram Protocol (UDP), which can facilitate the load balancing of MPLS application traffic across IP networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-in-udp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-in-udp-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-in-udp-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From xuxiaohu@huawei.com Mon Apr 1 01:19: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 CAB2021F8564 for ; Mon, 1 Apr 2013 01:19:20 -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 LIS7oTtspXMG for ; Mon, 1 Apr 2013 01:19:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E68AC21F88C0 for ; Mon, 1 Apr 2013 01:19:17 -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 ARH44474; Mon, 01 Apr 2013 08:19:17 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 1 Apr 2013 09:19:10 +0100 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 1 Apr 2013 16:19:16 +0800 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.50]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.01.0323.007; Mon, 1 Apr 2013 16:19:10 +0800 From: Xuxiaohu To: Lizhong Jin , Loa Andersson , "draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org" Thread-Topic: MPLS-RT review of draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-00.txt Thread-Index: AQHOK8DiDBQCLe3xqU+6H0+NcQI9WJjBCy6w Date: Mon, 1 Apr 2013 08:19:10 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F5968F@NKGEML512-MBS.china.huawei.com> References: <513E1C97.3050208@pi.nu> In-Reply-To: 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_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F5968FNKGEML512MBSchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-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: Mon, 01 Apr 2013 08:19:21 -0000 --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F5968FNKGEML512MBSchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkcmFmdCBhbmQgdGhpbmsgaXQgaXMgdXNl ZnVsIGFuZCByZWFkeSBmb3IgV0cgYWRvcHRpb24uDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0K DQq3orz+yMs6IExpemhvbmcgSmluIFttYWlsdG86bGl6aG8uamluQGdtYWlsLmNvbV0NCreiy83K sbzkOiAyMDEzxOoz1MIyOMjVIDIyOjMxDQrK1bz+yMs6IExvYSBBbmRlcnNzb247IGRyYWZ0LXBh Yy1tcGxzLWxzcC1waW5nLXRsdnMtYW5kLXN1Yi10bHZzLXJlZ2lzdHJ5QHRvb2xzLmlldGYub3Jn DQqzrcvNOiByYWppdmFAY2lzY28uY29tOyBkYW5pZWxAb2xkZG9nLmNvLnVrOyBYdXhpYW9odTsg bXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmc7IE1hcnRpbiBWaWdvdXJldXg7IG1wbHNAaWV0Zi5v cmcNCtb3zOI6IFJlOiBNUExTLVJUIHJldmlldyBvZiBkcmFmdC1wYWMtbXBscy1sc3AtcGluZy10 bHZzLWFuZC1zdWItdGx2cy1yZWdpc3RyeS0wMC50eHQNCg0KSGksIGFsbA0KSSByZXZpZXdlZCB0 aGlzIGRyYWZ0LCBhbmQgdGhpbmsgdGhlIGRvY3VtZW50IGlzIHVzZWZ1bCwgYW5kIGlzIHJlYWR5 IHRvIGJlIGNvbnNpZGVyZWQgZm9yIFdHIGFkb3B0aW9uLiBPbmUgbWlub3IgY29tbWVudHMsIHRo aXMgZHJhZnQgc2hvdWxkIGJlIGFuIHVwZGF0ZSB0byBSRkM0Mzc5LCBhbmQgc2hvdWxkIGJlIHJl ZmxlY3RlZCBhdCB0aGUgYmVnaW5uaW5nIG9mIHRoZSBkcmFmdC4gVGhlbiBkb2VzIHRoYXQgbWVh biB0aGlzIGRyYWZ0IHNob3VsZCBiZSBtb3ZlZCBmYXN0ZXIgdGhhbiBhbnkgb3RoZXIgZHJhZnRz IHRoYXQgcmVxdWlyZSBzdWItdGx2IGFsbG9jYXRpb24uDQoNClJlZ2FyZHMNCkxpemhvbmcNCg0K T24gVHVlLCBNYXIgMTIsIDIwMTMgYXQgMjowNCBBTSwgTG9hIEFuZGVyc3NvbiA8bG9hQHBpLm51 PG1haWx0bzpsb2FAcGkubnU+PiB3cm90ZToNCg0KRGFuLCBYdSwgTGl6aG9uZyBhbmQgUmFqaXYs DQoNCllvdSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMgYW4gTVBMUyBSZXZpZXcgdGVhbSByZXZpZXdl cnMgZm9yDQpkcmFmdC1wYWMtbXBscy1sc3AtcGluZy10bHZzLWFuZC1zdWItdGx2cy1yZWdpc3Ry eS0wMC4NCg0KTm90ZSB0byBhdXRob3JzOiBZb3UgaGF2ZSBiZWVuIENDJ2Qgb24gdGhpcyBlbWFp bCBzbyB0aGF0IHlvdSBjYW4ga25vdw0KdGhhdCB0aGlzIHJldmlldyBpcyBnb2luZyBvbi4gSG93 ZXZlciwgcGxlYXNlIGRvIG5vdCByZXZpZXcgeW91ciBvd24NCmRvY3VtZW50Lg0KDQpSZXZpZXdz IHNob3VsZCBjb21tZW50IG9uIHdoZXRoZXIgdGhlIGRvY3VtZW50IGlzIGNvaGVyZW50LCBpcyBp dA0KdXNlZnVsIChpZSwgaXMgaXQgbGlrZWx5IHRvIGJlIGFjdHVhbGx5IHVzZWZ1bCBpbiBvcGVy YXRpb25hbA0KbmV0d29ya3MpLCBhbmQgaXMgdGhlIGRvY3VtZW50IHRlY2huaWNhbGx5IHNvdW5k PyAgV2UgYXJlIGludGVyZXN0ZWQNCmluIGtub3dpbmcgd2hldGhlciB0aGUgZG9jdW1lbnQgaXMg cmVhZHkgdG8gYmUgY29uc2lkZXJlZCBmb3IgV0cNCmFkb3B0aW9uIChpZSwgaXQgZG9lc24ndCBo YXZlIHRvIGJlIHBlcmZlY3QgYXQgdGhpcyBwb2ludCwgYnV0IHNob3VsZCBiZQ0KYSBnb29kIHN0 YXJ0KS4NCg0KUmV2aWV3cyBzaG91bGQgYmUgc2VudCB0byB0aGUgZG9jdW1lbnQgYXV0aG9ycywg V0cgY28tY2hhaXJzIGFuZA0KV0cgc2VjcmV0YXJ5LCBhbmQgQ0MnZCB0byB0aGUgTVBMUyBXRyBl bWFpbCBsaXN0LiBJZiBuZWNlc3NhcnksIGNvbW1lbnRzDQptYXkgYmUgc2VudCBwcml2YXRlbHkg dG8gb25seSB0aGUgV0cgY2hhaXJzLg0KDQpBcmUgeW91IGFibGUgdG8gcmV2aWV3IHRoaXMgZHJh ZnQgYnkgQXByaWwgMiwgMjAxMz8NCg0KVGhhbmtzLCBMb2ENCihhcyBNUExTIFdHIGNoYWlyKQ0K DQovTG9hDQotLQ0KDQoNCkxvYSBBbmRlcnNzb24gICAgICAgICAgICAgICAgICAgICAgICBlbWFp bDogbG9hQG1haWwwMS5odWF3ZWkuY29tPG1haWx0bzpsb2FAbWFpbDAxLmh1YXdlaS5jb20+DQpT ZW5pb3IgTVBMUyBFeHBlcnQgICAgICAgICAgICAgICAgICAgICAgICAgIGxvYUBwaS5udTxtYWls dG86bG9hQHBpLm51Pg0KSHVhd2VpIFRlY2hub2xvZ2llcyAoY29uc3VsdCkgICAgICAgIHBob25l OiArNDYgNzM5IDgxIDIxIDY0PHRlbDolMkI0NiUyMDczOSUyMDgxJTIwMjElMjA2ND4NCg0K --_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F5968FNKGEML512MBSchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi all,

 = ;

I have rev= iewed this draft and think it is useful and ready for WG adoption.

 = ;

Best regar= ds,

Xiaohu

 = ;

=B7=A2=BC=FE=C8=CB: Lizhong Jin [mailto:l= izho.jin@gmail.com]
=B7=A2=CB=CD= =CA=B1=BC=E4: 2013=C4=EA3=D4=C2<= span lang=3D"EN-US">28=C8=D5 22:31
=CA=D5=BC=FE=C8=CB: Loa Andersson; draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@t= ools.ietf.org
=B3=AD=CB=CD: rajiva@cisco.com; daniel@olddog.co.uk; Xuxiaohu; mpls-chairs@tools.ietf.o= rg; Martin Vigoureux; mpls@ietf.org
=D6=F7=CC=E2: Re: MPLS-RT review of draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-= 00.txt

 

Hi, all

I reviewed this draft, and thin= k the document is useful, and is ready to be considered for WG&nb= sp;adoption. One minor comments, this draft should be an update to RFC4379,= and should be reflected at the beginning of the draft. Then does that mean this draft should be moved faster than any other draft= s that require sub-tlv allocation.

 

Regards

Lizhong

=  

On Tue, Mar 12, 2013 at 2:04 AM= , Loa Andersson <loa@pi.n= u> wrote:


Dan, Xu, Lizhong and Rajiv,

You have been selected as an MPLS Review team reviewers for
draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-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 April 2, 2013?

Thanks, Loa
(as MPLS WG chair)

/Loa
--


Loa Andersson                  = ;      email: loa@mail01.huawei.com
Senior MPLS Expert                 =          loa@pi.nu
Huawei Technologies (consult)        phone: +46 739 81 21 64

 

--_000_1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F5968FNKGEML512MBSchi_-- From loa@pi.nu Mon Apr 1 04:23:50 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 248C521F8801 for ; Mon, 1 Apr 2013 04:23:50 -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 m8ujiQP-T8OX for ; Mon, 1 Apr 2013 04:23:46 -0700 (PDT) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id D9BAE21F89B2 for ; Mon, 1 Apr 2013 04:23:45 -0700 (PDT) Received: from [192.168.10.100] (unknown [121.54.51.84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id 23940823B5; Mon, 1 Apr 2013 13:23:37 +0200 (CEST) Message-ID: <51596E34.4020408@pi.nu> Date: Mon, 01 Apr 2013 13:23:32 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; 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: "draft-villamizar-mpls-forwarding@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: [mpls] poll to see if we have consensus to make draft-villamizar-mpls-forwarding 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, 01 Apr 2013 11:23:50 -0000 Working Group, This is to start a two week poll on adopting draft-villamizar-mpls-forwarding-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 April 15, 2013. There are no IPR claim against this document. 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 gregory.mirsky@ericsson.com Mon Apr 1 10:59: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 8E5671F0C74 for ; Mon, 1 Apr 2013 10:59: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 IplX3sicMo74 for ; Mon, 1 Apr 2013 10:59:26 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id CD6EC1F0D12 for ; Mon, 1 Apr 2013 10:59:25 -0700 (PDT) X-AuditID: c6180641-b7faf6d00000096b-ba-5159cafcc0aa Received: from EUSAAHC007.ericsson.se (Unknown_Domain [147.117.188.93]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id B8.F4.02411.CFAC9515; Mon, 1 Apr 2013 19:59:25 +0200 (CEST) Received: from EUSAAMB106.ericsson.se ([147.117.188.123]) by EUSAAHC007.ericsson.se ([147.117.188.93]) with mapi id 14.02.0318.004; Mon, 1 Apr 2013 13:59:24 -0400 From: Gregory Mirsky To: "curtis@occnc.com" Thread-Topic: MPLS-RT review of draft-villamizar-mpls-forwarding Thread-Index: AQHOLYYi4BKS76tCWU2P10gtMdj67ZjBqIRg Date: Mon, 1 Apr 2013 17:59:23 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B47D122@eusaamb106.ericsson.se> References: Your message of "Thu, 28 Mar 2013 16:32:31 EDT." <201303282032.r2SKWVoG061570@gateway1.orleans.occnc.com> <201303302035.r2UKZbNP085509@gateway1.orleans.occnc.com> In-Reply-To: <201303302035.r2UKZbNP085509@gateway1.orleans.occnc.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupmkeLIzCtJLcpLzFFi42KZXLonVvfvqchAg19n+SwOH5jObtF1Ygar RdOczYwW/+bOYba4s+sLq8X3S0tYLG4tXclqcXdBE4vFw8mX2B04PVqf7WX1mPJ7I6vHkiU/ mTy2PlnC7rH4i5/HrOltbB5tLxU8vlz+zBbAEcVlk5Kak1mWWqRvl8CVsX/FNNaC/TIVHx9v ZGxg3CnWxcjJISFgItH0spUVwhaTuHBvPRuILSRwlFHizvTQLkYuIHsZo8SVczMYQRJsAkYS Lzb2sIPYIgKaEn8nbQazmQVWM0tseuIFYgsL2EsseDOJDaLGQWJqVz9LFyMHkG0ksfllDkiY RUBFYuf008wgNq+Ar8SsY88ZIXbtY5R497eNEaSeU8BV4sG+CpAaRqDbvp9awwSxSlzi1pP5 TBA3C0gs2XOeGcIWlXj5+B/UL8oSS57sZ4Go15FYsPsTG4StLbFs4WuovYISJ2c+YZnAKDYL ydhZSFpmIWmZhaRlASPLKkaO0uLUstx0I8NNjMAIPSbB5riDccEny0OM0hwsSuK8oa4XAoQE 0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw1k0/95l5g/UbG+vjfNOyZKbE3p12Jcr4xdF5K7b2 tmfkexTwqm49YqxZNiFx4uz9snPDFpUxua05+a3ktHwFb0YiCyv7hZ05k7iO7HUw37zqotwm lruZR7dp5y6cVrSDL6ejqUxjz9k3OpUprje9lN88jngsPeHrj00btH2O3J881WV53J3dB5VY ijMSDbWYi4oTAbbVwDSeAgAA Cc: "mpls@ietf.org" , "draft-villamizar-mpls-forwarding@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , Loa Andersson Subject: Re: [mpls] MPLS-RT review of draft-villamizar-mpls-forwarding 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, 01 Apr 2013 17:59:26 -0000 Hi Curtis, Thank you for careful consideration of my comments. I've re-read the 1588overmpls recently and I think that rather than spendin= g our time on wordsmithing what it does or should do in your document I'll = turn my attention to the 1588overmpls document. Especially since it is plan= ned for TICTOC WG LC this month. Regards, Greg=20 -----Original Message----- From: Curtis Villamizar [mailto:curtis@occnc.com]=20 Sent: Saturday, March 30, 2013 1:36 PM To: curtis@occnc.com Cc: Gregory Mirsky; mpls@ietf.org; draft-villamizar-mpls-forwarding@tools.i= etf.org; Loa Andersson; mpls-chairs@tools.ietf.org; Martin Vigoureux; Eric = Osborne (eosborne); Thomas Nadeau; Thomas Beckhaus Subject: Re: MPLS-RT review of draft-villamizar-mpls-forwarding Greg, I've added the following (new text following "+" signs): PTP or NTP may be carried over MPLS . Generally NTP will be carried within IP with IP carried in MPLS . Both PTP and NTP benefit from accurate time stamping of incoming packets and the ability to insert accurate time stamps in outgoing packets. + PTP correction which occurs when forwarding requires updating a =20 + timestamp compensation field based on the difference between packet =20 + arrival at an LSR and packet transmit time at that same LSR. Does this address any remaining PTP issues? Curtis In message <201303282032.r2SKWVoG061570@gateway1.orleans.occnc.com> Curtis Villamizar writes: In message <7347100B5761DC41A166AC17F22DF112075613@eusaamb103.ericsson.se> Gregory Mirsky writes: =20 > Hi Curtis, > =20 > back to our discussion on 1588overMPLS. I've attached slide from deck=20 > presented at TICTOC meeting in Orlando as illustration of what I mean=20 > by "PTP distribution through MPLS network". > =20 > PTP/NTP Transport over MPLS network can be done without any special=20 > PTP LSP (another slide from the same deck) > =20 > =20 > Regards, > Greg Greg, Perhaps I am missing your point. Unless the point it to marvel over the ar= twork in the otherwise not very informative slides. There are two encapsulations shown: LSP LSP IP PW UDP CW PTP Ethernet PTP This just makes it a little hard for the midpoint LSR to do the PTP correct= ion field update, but otherwise ... so what. If the LSP midpoint nodes make no corrections, then accuracy suffers. The midpoint LSR must either: 1) know that the payload is IP or know that t= he payload is PW (it doens't today), or guess based on CW or lack of, and 2= ) know that the packet might contain PTP, and 3) look at every packet in th= e LSP. I mentioned in the draft that a timestamp has to be captured when a packet = is received and generated and inserted when a packet is sent. I also mentioned that the offset is variable. For example in the PW case, = the Ethernet header could have a VLAN ID. The PTP forwarding correction requires updating a timestamp compensation fi= eld based on the difference between packet arrival and packet send times. = Perhaps what you are saying is that we don't call out the need to support t= hat difference plus offset (offset by the existing compensation). Of cours= e, the offset and receive stamp can be added together in software or in les= s critically time constrained hardware, with the send stamp subtracted as c= lose to packet transmit time as possible. If that is not what you meant, then what exactly is your point? Curtis From vishwas.ietf@gmail.com Mon Apr 1 16:20: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 1C9C621F8B49 for ; Mon, 1 Apr 2013 16:20:45 -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 xsOE2HA82ERb for ; Mon, 1 Apr 2013 16:20:42 -0700 (PDT) Received: from mail-qe0-f52.google.com (mail-qe0-f52.google.com [209.85.128.52]) by ietfa.amsl.com (Postfix) with ESMTP id 4841E21F8B35 for ; Mon, 1 Apr 2013 16:20:40 -0700 (PDT) Received: by mail-qe0-f52.google.com with SMTP id jy17so1523310qeb.39 for ; Mon, 01 Apr 2013 16:20:39 -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=kEGIn6dpn0rscrQUjv0lWym1xYbI72Zk53/gdlPfiOw=; b=CH1j28eRKKX+xrEXzr22/1qGHaTQvbD+r181wDkCHmMX/27g51scRZQ+9lfbhkbC83 1cB53jAmZZQol6lCH8bt/l6KFOCYNaVnXuU2nTdTBhaf3t97a2M4WeIhhQoiLwfZZ4PD tI87XDL/ssAZueC07OpAFEBNUs/FrcDj0cXR83iJXTAu6XUOgjxFUO0+mf0GWXjSjcrt peMSDd0JEL0ev72GceXe/0k0CHM+UKK8oHn1Fu0qFhREtufV5Ea+yaLxmWBg8Oc7Ek3f abW2QutR0CvivGjbzpJzhTXVXThb7f0yI97iLw241mRChCefY6VJCUBVqFb5zpTK0zkA xtXA== MIME-Version: 1.0 X-Received: by 10.229.72.130 with SMTP id m2mr3437273qcj.122.1364858439742; Mon, 01 Apr 2013 16:20:39 -0700 (PDT) Received: by 10.229.164.199 with HTTP; Mon, 1 Apr 2013 16:20:39 -0700 (PDT) Date: Mon, 1 Apr 2013 16:20:39 -0700 Message-ID: From: Vishwas Manral To: Loa Andersson , "hejia@huawei.com" , thomas.morin@orange-ftgroup.com, draft-kompella-mpls-special-purpose-labels@tools.ietf.org, "mpls-chairs@tools.ietf.org" , Martin Vigoureux Content-Type: multipart/alternative; boundary=001a11c2a274783ff904d954de0e Cc: "mpls@ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-kompella-mpls-special-purpose-labels-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, 01 Apr 2013 23:20:50 -0000 --001a11c2a274783ff904d954de0e Content-Type: text/plain; charset=ISO-8859-1 Hi Authors, Here is my review based on guidance from Loa. I have not been following MPLS work very closely lately, so feel free to point me to any relevant references I may have missed: Having worked on a draft in the past trying to allocate one of the reserved labels, I do think the problem is present and reserved labels should have a bigger range and that should help allocation policies to be more liberal than in the past. The document is certainly useful. The draft is well written, clear in its intent and is fairly cohesive. The document does a fairly good job technically trying to cover all technical issues that may arise. I think the document is ready to be considered for adoption by the Working Group. I had a few comments regarding some clarifications on the text of the document: 1. The whole difference/ name change between "Reserved" and "Special Purpose" labels which seems at the heart of the document is not clarified anywhere. Though I know answers 1.A and 1.B.probably talk about it - it should be explicitly specified. 2. Though I understand the idea of having consecutive Extension labels, that can create issues with ASIC hardware, just as TLV's create by moving the location of the following headers. We have talked of this in security considerations, I see that allowing an arbitrary depth stack may force implementations to send packets to the software path for processing, after some depth of labels, which can cause software path overloads. 3. With "Extended Special Purpose MPLS Label Values", I think we have created an Experimental range. The purpose of which is not clear nor is the idea of how it is used. I also have questions on any implementation currently using labels in the Experimental range, and how this change would affect those implementations. Thanks, Vishwas -----Original Message----- From: Loa Andersson [mailto:loa@pi.nu] Sent: Friday, March 15, 2013 4:01 PM To: Markus Jork; Manral, Vishwas; Jia He; Thomas Morin; draft-kompella-mpls-special-purpose-labels@tools.ietf.org; mpls-chairs@tools.ietf.org; Martin Vigoureux Subject: MPLS-RT review of draft-kompella-mpls-special-purpose-labels-02.txt Markus, Vishwas, Jia and Thomas, You have been selected as an MPLS Review team reviewers for draft-kompella-mpls-special-purpose-labels-02. 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 April 3, 2013? Thanks, Loa (as MPLS WG chair) /Loa -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 <#> --001a11c2a274783ff904d954de0e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Authors,

=A0

Here is my review based on guidance from Loa. = I have not been following MPLS work very closely lately, so feel free to point me to a= ny relevant references I may have missed:

=A0

Having worked on a draft in the past trying to= allocate one of the reserved labels, I do think the problem is present and reserved labels should have a bigger range and that should help allocation policies = to be more liberal than in the past. The document is certainly useful.<= /font>

=A0

The draft is well written, clear in its intent= and is fairly cohesive. The document does a fairly good job technically trying to cover all technical issues that may arise. I think the document is ready to= be considered for adoption by the Working Group.

=A0

I had a few comments regarding some clarificat= ions on the text of the document:

=A0

1. The whole difference/ name change between &= quot;Reserved" and "Special Purpose" labels which seems at the heart of the docu= ment is not clarified anywhere. Though I know answers 1.A and 1.B.probably talk about it - it should be explicitly specified.

=A0

2. Though I understand the idea of having cons= ecutive Extension labels, that can create issues with ASIC hardware, just as TLV= 9;s create by moving the location of the following headers. We have talked of t= his in security considerations, I see that allowing an arbitrary depth stack ma= y force implementations to send packets to the software path for processing, after some depth of labels, which can cause software path overloads.=

=A0

3. With "Extended Special Purpose MPLS La= bel Values", I think we have created an Experimental range. The purpose of which is not clear nor is the idea of how it is used. I also have questions= on any implementation currently using labels in the Experimental range, and ho= w this change would affect those implementations.

=A0

Thanks,

Vishwas

=A0

-----Original Message-----
From: Loa Andersson [mailto:loa@pi.nu] Sent: Friday, March 15, 2013 4:01 PM
To: Markus Jork; Manral, Vishwas; Jia He; Thomas Morin; draft-kompella-mpls-special-purpose-labels@tools.ietf.org; mpls-chairs@tools.ietf.org; Martin Vigoureux
Subject: MPLS-RT review of draft-kompella-mpls-special-purpose-labels-02.tx= t

=A0

=A0

Markus, Vishwas, Jia and Thomas,=

=A0

You have been selected as an MPLS Review team = reviewers for

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

=A0

Note to authors: You have been CC'd on thi= s email so that you can know

that this review is going on. However, please = do not review your own

document.

=A0

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 s= ound?=A0 We are interested

in knowing whether the document is ready to be= considered for WG

adoption (ie, it doesn't have to be perfec= t at this point, but should be

a good start).

=A0

Reviews should be sent to the document authors= , WG co-chairs and

WG secretary, and CC'd to the MPLS WG emai= l list. If necessary, comments

may be sent privately to only the WG chairs.

=A0

Are you able to review this draft by April 3, = 2013?

=A0

Thanks, Loa

(as MPLS WG chair)

=A0

/Loa

--

=A0

=A0

Loa Andersson=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 email: loa@mail01.huawei.com

Senior MPLS Expert=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 loa@pi.nu

Huawei Technologies (consultant)=A0=A0= =A0=A0 phone: +46 739 81 21 64

--001a11c2a274783ff904d954de0e-- From lufang@cisco.com Mon Apr 1 18:05: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 64E4411E811A; Mon, 1 Apr 2013 18:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.846 X-Spam-Level: X-Spam-Status: No, score=-8.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, 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 COllLp47q31a; Mon, 1 Apr 2013 18:05:29 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1665011E80F8; Mon, 1 Apr 2013 18:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12295; q=dns/txt; s=iport; t=1364864729; x=1366074329; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=FPyWT/s0hLgu4xm9JXKcQjXk/PAzMb0bdYobFBuoTDE=; b=eb59mU5XpNZIlTjUAlvzgaM29Xte96HQZOkfsJri2JWXGtqXW3KweZxr n37LH2f8b7JEz5SvjciZqoisX2lPvMpn0ModiZC5Z9tgQmbUcVWzuyQrp gL+hD4p2671aO/59yEtG02g9W+P44kLqkumcYkkug8XGi9ngkR/tCiaFJ E=; X-Files: default[4].xml : 3222 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFAI8tWlGtJXG8/2dsb2JhbABDgzuDILwhDXEWdIIfAQEBBAEBAWsLDAYBCBEDAQIBCiIEJQsdCAIEAQ0FCAaIBgyTS5p+BoJCj3aNeYEHIAYLBwaCIThhA49FiEWPbIMLgWo+ X-IronPort-AV: E=Sophos;i="4.87,390,1363132800"; d="xml'?rels'?scan'72,48,208";a="193830200" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-5.cisco.com with ESMTP; 02 Apr 2013 01:05:28 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r3215SVI029451 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Apr 2013 01:05:28 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.17]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Mon, 1 Apr 2013 20:05:27 -0500 From: "Luyuan Fang (lufang)" To: Russ Housley , "ietf@ietf.org" Thread-Topic: [mpls] Last Call: Thread-Index: AQHOLz4pe+S4mct/bEWgHAuKWl97qA== Date: Tue, 2 Apr 2013 01:05:27 +0000 Message-ID: <0DB8F45437AB844CBB5102F807A0AD93102CB212@xmb-rcd-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.131.12.86] Content-Type: multipart/mixed; boundary="_002_0DB8F45437AB844CBB5102F807A0AD93102CB212xmbrcdx03ciscoc_" MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Last 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: Tue, 02 Apr 2013 01:05:30 -0000 --_002_0DB8F45437AB844CBB5102F807A0AD93102CB212xmbrcdx03ciscoc_ Content-Type: text/plain; charset="euc-kr" Content-ID: <2ABE71F1A2CCC3498D35A3B97E6A0B1A@emea.cisco.com> Content-Transfer-Encoding: base64 SGkgUnVzcywNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLCB2ZXJ5IGdvb2QgcG9pbnRzLg0K U29ycnkgZm9yIHRoZSBkZWxheSBpbiByZXBseWluZywgSSB3YXMgb3V0IG9mIG9mZmljZS4NCg0K IA0KVGhlIGZvbGxvd2luZyBpcyBteSBwcm9wb3NlZCB0ZXh0IGZvciByZXBsYWNpbmcgdGhlIGN1 cnJlbnQgZmlyc3QNCnBhcmFncmFwaCBvZiBzZWN0aW9uIDEuMi4NCg0KIA0KVHJhZGl0aW9uYWwg dHJhbnNwb3J0IHRlY2hub2xvZ2llcyBpbmNsdWRlIFNPTkVUL1NESCwgVERNLCBhbmQgQVRNLiBU aGVyZQ0KaXMgYSB0cmFuc2l0aW9uIGF3YXkgZnJvbSB0aGVzZSB0cmFuc3BvcnQgdGVjaG5vbG9n aWVzIHRvIG5ldyBwYWNrZXQNCnRlY2hub2xvZ2llcy4NCkluIGFkZGl0aW9uIHRvIHRoZSBldmVy IGluY3JlYXNpbmcgZGVtYW5kIGZvciBiYW5kd2lkdGgsIHRoZSBwYWNrZXQNCnRlY2hub2xvZ2ll cyBvZmZlciB0aGVzZSBrZXkgYWR2YW50YWdlczoNCg0KIA0KQmFuZHdpZHRoIGVmZmljaWVuY3k6 IFRyYW5zcG9ydCB0ZWNobm9sb2dpZXMgc3VwcG9ydHMgZml4ZWQgQmFuZHdpZHRoDQpvbmx5LCBu byBwYWNrZXQgc3RhdGlzdGljYWwgbXVsdGlwbGV4aW5nLCBiYW5kd2lkdGggaXMgcmVzZXJ2ZWQg aW4NCnRyYW5zcG9ydA0Kd2hldGhlciB1c2VkIG9yIG5vdCBieSBjbGllbnRzLiBQYWNrZXQgdGVj aG5vbG9naWVzIHN1cHBvcnQgc3RhdGlzdGljYWwNCm11bHRpcGxleGluZywNCnRoaXMgaXMgdGhl IG1vc3QgaW1wb3J0YW50IG1vdGl2YXRpb24gZm9yIHRoZSB0cmFuc2l0aW9uIGZyb20gdHJhZGl0 aW9uYWwNCnRyYW5zcG9ydCB0ZWNobm9sb2dpZXMgdG8gcGFja2V0IHRlY2hub2xvZ2llcy4gVGhl IHByb2xpZmVyYXRpb24gb2YgbmV3DQpkaXN0cmlidXRlZCBhcHBsaWNhdGlvbnMgd2hpY2ggY29t bXVuaWNhdGUgd2l0aCBzZXJ2ZXJzIG92ZXIgdGhlIG5ldHdvcmsNCmluIGENCmJ1cnN0eSBmYXNo aW9uIGhhcyBiZWVuIGRyaXZpbmcgdGhlIGFkb3B0aW9uIG9mIHBhY2tldCB0cmFuc3BvcnQNCnRl Y2huaXF1ZXMsIHNpbmNlDQptdWx0aXBsZXhpbmcgb2YgYnVyc3R5IHNvdXJjZXMgaXMgZmFyIG1v cmUgZWZmaWNpZW50IG92ZXIgdHJhZGl0aW9uYWwNCmNpcmN1aXQtYmFzZWQNClRETSB0ZWNobm9s b2dpZXMuDQoNCiANCkZsZXhpYmxlIGRhdGEgcmF0ZSBjb25uZWN0aW9uczogVHJhZGl0aW9uYWwg dHJhbnNwb3J0IGNvbm5lY3Rpb24NCmdyYW51bGFyaXR5DQppcyBsaW1pdGVkIHRvIHRoZSByaWdp ZCBQREggb3IgU09ORVQgaGllcmFyY2h5IChlLmcuLCBEUzEsIERTMywgT0MzLCBPQzEyLA0KZXRj LikuDQpQYWNrZXQgdGVjaG5vbG9naWVzIHN1cHBvcnQgZmxleGlibGUgZGF0YSByYXRlIGNvbm5l Y3Rpb25zLiBUaGUgc3VwcG9ydCBvZg0KZmluZXIgZGF0YSByYXRlIGdyYW51bGFyaXR5IGlzIGlt cG9ydGFudCBmb3IgdG9kYXmp9nMgd2lyZWxpbmUgYW5kIHdpcmVsZXNzDQpzZXJ2aWNlcyBhbmQg YXBwbGljYXRpb25zLg0KDQogDQpRb1Mgc3VwcG9ydDogV2hpbGUgdHJhZGl0aW9uYWwgdHJhbnNw b3J0LCBzdWNoIGFzIFRETSB0cmFuc3BvcnQgaGFzDQp2ZXJ5IGxpbWl0ZWQgUW9TIHN1cHBvcnQs IHBhY2tldCB0cmFuc3BvcnQgY2FuIHByb3ZpZGUgbmVlZGVkIFFvUw0KdHJlYXRtZW50IGZvcg0K SVBUViwgVm9pY2UgYW5kIFZpZGVvIG92ZXIgSVAgYXBwbGljYXRpb25zLg0KDQogDQpUaGUgcm9v dCBjYXVzZSBmb3IgdHJhbnNwb3J0IG1vdmluZyB0byBwYWNrZXQgdHJhbnNwb3J0IGlzIHRoZSBz aGlmdA0Kb2YgYXBwbGljYXRpb24gZnJvbSBURE0gdG8gcGFja2V0LiBGb3IgZXhhbXBsZSwgVm9p Y2UgVERNIHRvIFZvSVA7IFZpZGVvIHRvDQpWaWRlbyBvdmVyIElQOyBURE0gYWNjZXNzIGxpbmVz IHRvIEV0aGVybmV0OyBURE0gVlBOcyB0byBJUCBWUE5zIGFuZA0KRXRoZXJuZXQNClZQTnMuIElu IGFkZGl0aW9uLCBuZXR3b3JrIGNvbnZlcmdlbmNlIGFuZCB0ZWNobm9sb2d5IHJlZnJlc2hlcyBk ZW1hbmQgZm9yDQpjb21tb24gYW5kIGZsZXhpYmxlIGluZnJhc3RydWN0dXJlIHRoYXQgcHJvdmlk ZXMgbXVsdGlwbGUgc2VydmljZXMuDQoNCiANClRoYW5rcywNCkx1eXVhbg0KDQoNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJ1c3MgSG91c2xleSA8aG91c2xleUB2aWdpbHNl Yy5jb20+DQpEYXRlOiBTYXR1cmRheSwgTWFyY2ggMjMsIDIwMTMgMzoxNiBQTQ0KVG86ICJpZXRm QGlldGYub3JnIiA8aWV0ZkBpZXRmLm9yZz4NCkNjOiAibXBsc0BpZXRmLm9yZyIgPG1wbHNAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW21wbHNdIExhc3QNCkNhbGw6CTxkcmFmdC1pZXRmLW1wbHMt dHAtdXNlLWNhc2VzLWFuZC1kZXNpZ24tMDYudHh0Pg0KDQo+SSB3b25kZXIgaWYgdGhlIGRpcmVj dGlvbiBvZiBTZWN0aW9uIDEuMiBjYW4gYmUgcmV2aXNlZCB0byBtYWtlIGl0IG1vcmUNCj5vZiBh biBlbmdpbmVlcmluZyBkb2N1bWVudC4NCj4NCj5JdCBjdXJyZW50bHkgc2F5czoNCj4NCj4gICBJ biByZWNlbnQgeWVhcnMsIHRoZSB1cmdlbmN5IGZvciBtb3ZpbmcgZnJvbSB0cmFkaXRpb25hbCB0 cmFuc3BvcnQNCj4gICB0ZWNobm9sb2dpZXMsIHN1Y2ggYXMgU09ORVQvU0RILCBURE0sIGFuZCBB VE0sIHRvIG5ldyBwYWNrZXQNCj4gICB0ZWNobm9sb2dpZXMgaGFzIGJlZW4gcmlzaW5nLiBUaGlz IGlzIGxhcmdlbHkgZHVlIHRvIHRoZSBmYXN0IGdyb3dpbmcNCj4gICBkZW1hbmQgZm9yIGJhbmR3 aWR0aCwgd2hpY2ggaGFzIGJlZW4gZnVlbGVkIGJ5IHRoZSBmb2xsb3dpbmcgZmFjdG9yczoNCj4g ICAuLi4NCj4NCj5QbGVhc2UgY29uc2lkZXIgYW4gYXBwcm9hY2ggdGhhdCBkZXNjcmliZXMgdGhl IHRoZSByZWFzb25zIGJlaGluZCB0aGUNCj50cmFuc2l0aW9uIGZyb20gdGhlIG5ldHdvcmsgb3Bl cmF0b3IgYW5kIG5ldHdvcmsgdXNlciBwZXJzcGVjdGl2ZXM6DQo+DQo+ICAgVHJhZGl0aW9uYWwg dHJhbnNwb3J0IHRlY2hub2xvZ2llcyBpbmNsdWRlIFNPTkVUL1NESCwgVERNLCBhbmQgQVRNLg0K PiAgIFRoZXJlIGlzIGEgdHJhbnNpdGlvbiBhd2F5IGZyb20gdGhlc2UgdHJhbnNwb3J0IHRlY2hu b2xvZ2llcyB0byBuZXcNCj4gICBwYWNrZXQgdGVjaG5vbG9naWVzLiBJbiBhZGRpdGlvbiB0byB0 aGUgZXZlciBpbmNyZWFzaW5nIGRlbWFuZCBmb3INCj4gICBiYW5kd2lkdGgsIHRoZSBwYWNrZXQg dGVjaG5vbG9naWVzIG9mZmVyIHRoZXNlIGFkdmFudGFnZXM6DQo+ICAgLi4uDQo+DQo+VGhlIGZh Y3QgdGhhdCBJUCBuZXR3b3JrcyBhcmUgYmVpbmcgdXNlZCBmb3IgbmV3IGFwcGxpY2F0aW9ucyBh bmQgdGhhdA0KPnRoZSBsZWdhY3kgZGV2aWNlcyBhcmUgZ2V0dGluZyBvbGQgZG9lcyBub3QgbW90 aXZhdGUgdGhlIHRyYW5zaXRpb24gdG8NCj5wYWNrZXQgdGVjaG5vbG9naWVzLiAgVGhlIGFkdmFu dGFnZXMgdGhhdCBwYWNrZXQgdGVjaG5vbG9naWVzIG9mZmVyIGZvcg0KPnRoZXNlIG5ldyBhcHBs aWNhdGlvbnMgaXMgdGhlIHRoaW5nIHRoYXQgbmVlZHMgdG8gYmUgaGlnaGxpZ2h0ZWQgaGVyZSwN Cj5ldmVuIGlmIGl0IGlzIGp1c3QgYSBsaXN0IG9mIGJ1bGxldHMuDQo+DQo+SXQgc2VlbXMgbGlr ZSB0aGUgb25seSBzZW50ZW5jZSB0aGF0IGFkZHJlc3NlcyB0aGlzIHBvaW50IGluIFNlY3Rpb24g MS4yDQo+aXM6ICJJdCBzdHJlYW1saW5lcyB0aGUgb3BlcmF0aW9uLCByZWR1Y2VzIHRoZSBvdmVy YWxsIGNvbXBsZXhpdHksIGFuZA0KPmltcHJvdmVzIGVuZC10by1lbmQgY29udmVyZ2VuY2UuIg0K Pg0KPlRoYW5rcywNCj4gIFJ1c3MNCj4NCj5PbiBKYW4gMjgsIDIwMTMsIGF0IDM6MDEgUE0sIFRo ZSBJRVNHIHdyb3RlOg0KPg0KPj4gVGhlIElFU0cgaGFzIHJlY2VpdmVkIGEgcmVxdWVzdCBmcm9t IHRoZSBNdWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGluZw0KPj5XRw0KPj4gKG1wbHMpIHRvIGNv bnNpZGVyIHRoZSBmb2xsb3dpbmcgZG9jdW1lbnQ6DQo+PiAtICdNUExTLVRQIEFwcGxpY2FiaWxp dHk7IFVzZSBDYXNlcyBhbmQgRGVzaWduJw0KPj4gIDxkcmFmdC1pZXRmLW1wbHMtdHAtdXNlLWNh c2VzLWFuZC1kZXNpZ24tMDYudHh0PiBhcyBJbmZvcm1hdGlvbmFsIFJGQw0KPj4gDQo+PiBUaGUg SUVTRyBwbGFucyB0byBtYWtlIGEgZGVjaXNpb24gaW4gdGhlIG5leHQgZmV3IHdlZWtzLCBhbmQg c29saWNpdHMNCj4+IGZpbmFsIGNvbW1lbnRzIG9uIHRoaXMgYWN0aW9uLiBQbGVhc2Ugc2VuZCBz dWJzdGFudGl2ZSBjb21tZW50cyB0byB0aGUNCj4+IGlldGZAaWV0Zi5vcmcgbWFpbGluZyBsaXN0 cyBieSAyMDEzLTAyLTExLiBFeGNlcHRpb25hbGx5LCBjb21tZW50cyBtYXkNCj4+YmUNCj4+IHNl bnQgdG8gaWVzZ0BpZXRmLm9yZyBpbnN0ZWFkLiBJbiBlaXRoZXIgY2FzZSwgcGxlYXNlIHJldGFp biB0aGUNCj4+IGJlZ2lubmluZyBvZiB0aGUgU3ViamVjdCBsaW5lIHRvIGFsbG93IGF1dG9tYXRl ZCBzb3J0aW5nLg0KPj4gDQo+PiBBYnN0cmFjdA0KPj4gDQo+PiAgIFRoaXMgZG9jdW1lbnQgcHJv dmlkZXMgYXBwbGljYWJpbGl0eSwgdXNlIGNhc2Ugc3R1ZGllcyBhbmQgbmV0d29yaw0KPj4gICBk ZXNpZ24gY29uc2lkZXJhdGlvbnMgZm9yIHRoZSBNdWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGlu ZyBUcmFuc3BvcnQNCj4+ICAgUHJvZmlsZSAoTVBMUy1UUCkuIFRoZSB1c2UgY2FzZXMgaW5jbHVk ZSBNZXRybyBFdGhlcm5ldCBhY2Nlc3MgYW5kDQo+PiAgIGFnZ3JlZ2F0aW9uIHRyYW5zcG9ydCwg TW9iaWxlIGJhY2toYXVsLCBhbmQgcGFja2V0IG9wdGljYWwgdHJhbnNwb3J0Lg0KPj4gDQo+PiBU aGUgZmlsZSBjYW4gYmUgb2J0YWluZWQgdmlhDQo+PiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtbXBscy10cC11c2UtY2FzZXMtYW5kLWRlc2lnbi8NCj4+IA0KPj4g SUVTRyBkaXNjdXNzaW9uIGNhbiBiZSB0cmFja2VkIHZpYQ0KPj4gDQo+Pmh0dHA6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1tcGxzLXRwLXVzZS1jYXNlcy1hbmQtZGVzaWdu L2INCj4+YWxsb3QvDQo+PiANCj4+IA0KPj4gTm8gSVBSIGRlY2xhcmF0aW9ucyBoYXZlIGJlZW4g c3VibWl0dGVkIGRpcmVjdGx5IG9uIHRoaXMgSS1ELg0KPg0KPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+bXBscyBtYWlsaW5nIGxpc3QNCj5tcGxzQGll dGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQoNCg== --_002_0DB8F45437AB844CBB5102F807A0AD93102CB212xmbrcdx03ciscoc_ Content-Type: application/xml; name="default[4].xml" Content-Description: default[4].xml Content-Disposition: attachment; filename="default[4].xml"; size=3222; creation-date="Tue, 02 Apr 2013 01:05:27 GMT"; modification-date="Tue, 02 Apr 2013 01:05:27 GMT" Content-ID: <7C3E371EA94B6A438481022DB9CCAD88@emea.cisco.com> Content-Transfer-Encoding: base64 UEsDBBQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAW0NvbnRlbnRfVHlwZXNdLnhtbKyRy2rDMBBF 94X+g9C22HK6KKXYzqKPXR+L9AMGeWyL2CMhTULy9x07LpQSAoVuBNLMvffMqFwfxkHtMSbnqdKr vNAKyfrGUVfpz81Ldq9VYqAGBk9Y6SMmva6vr8rNMWBSoqZU6Z45PBiTbI8jpNwHJKm0Po7Aco2d CWC30KG5LYo7Yz0xEmc8eei6fMIWdgOr54M8n0hErtXjqW+KqjSEMDgLLKBmqpqzuohDuiDcU/OL LlvIclHO5ql3Id0sCe+ymugaVB8Q+Q1G4TAsQ+LP8xVIRov5ZeYz0b5tncXG290o68hn48XsTwCr /4n+zjTz39ZfAAAA//8DAFBLAwQUAAYACAAAACEApdan58AAAAA2AQAACwAAAF9yZWxzLy5yZWxz hI/PasMwDIfvhb2D0X1R0sMYJXYvpZBDL6N9AOEof2giG9sb69tPxwYKuwiEpO/3qT3+rov54ZTn IBaaqgbD4kM/y2jhdj2/f4LJhaSnJQhbeHCGo3vbtV+8UNGjPM0xG6VItjCVEg+I2U+8Uq5CZNHJ ENJKRds0YiR/p5FxX9cfmJ4Z4DZM0/UWUtc3YK6PqMn/s8MwzJ5PwX+vLOVFBG43lExp5GKhqC/j U72QqGWq1B7Qtbj51v0BAAD//wMAUEsDBBQABgAIAAAAIQBreZYWgwAAAIoAAAAcAAAAdGhlbWUv dGhlbWUvdGhlbWVNYW5hZ2VyLnhtbAzMTQrDIBBA4X2hd5DZN2O7KEVissuuu/YAQ5waQceg0p/b 1+XjgzfO3xTVm0sNWSycBw2KZc0uiLfwfCynG6jaSBzFLGzhxxXm6XgYybSNE99JyHNRfSPVkIWt td0g1rUr1SHvLN1euSRqPYtHV+jT9yniResrJgoCOP0BAAD//wMAUEsDBBQABgAIAAAAIQAhWqKE IQcAANsdAAAWAAAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbOxZT28bRRS/I/EdRnsvsRMnTaI6VezY DbRpo9gt6nG8O/ZOM7uzmhkn8Q21RyQkREEcqMSNAwIqtRKX8mkCRVCkfgXezOyud+Jxk5QAFTSH 1jv7e2/e+70/82evXD1KGDogQlKeNoP6e7UAkTTkEU1HzeB2v3tpNUBS4TTCjKekGUyIDK5uvPvO FbyuYpIQBPKpXMfNIFYqW19YkCEMY/kez0gK74ZcJFjBoxgtRAIfgt6ELSzWaisLCaZpgFKcgNpb wyENCeprlcFGobzD4DFVUg+ETPS0auJIGGy0X9cIOZFtJtABZs0A5on4YZ8cqQAxLBW8aAY18xcs bFxZwOu5EFNzZCtyXfOXy+UC0f6imVOMBuWk9W5j7fJWqd8AmJrFdTqddqde6jMAHIbgqbWlqrPR Xa23Cp0VkP05q7tdW641XHxF/9KMzWutVmt5LbfFKjUg+7Mxg1+trTQ2Fx28AVn88gy+0dpst1cc vAFZ/MoMvnt5baXh4g0oZjTdn0HrgHa7ufYSMuRs2wtfBfhqLYdPUZANZXbpKYY8VfNyLcH3uOgC QAMZVjRFapKRIQ4hi9uY0YGgegK8TnDljR0K5cyQngvJUNBMNYMPMgwVMdX38tl3L589Qcf3nx7f //H4wYPj+z9YRY7UNk5HVakX33z6x6OP0O9Pvn7x8HM/Xlbxv3z/8c8/feYHQvlMzXn+xeNfnz5+ /uUnv3370APfFHhQhfdpQiS6SQ7RHk/AMcOKazkZiPNJ9GNMqxKb6UjiFOtZPPo7KnbQNyeYYQ+u RVwG7whoHz7gtfE9x+BeLMYqj7fj2fU4cYA7nLMWF14Wruu5KjT3x+nIP7kYV3F7GB/45m7j1Ilv Z5xB36Q+le2YOGbuMpwqPCIpUUi/4/uEePi6S6nD6w4NBZd8qNBdilqYeinp04GTTVOhbZpAXCY+ AyHeDjc7d1CLM5/XW+TARUJVYOYxvk+YQ+M1PFY48ans44RVCb+BVewzsjcRYRXXkQoiPSKMo05E pPTJ3BLgbyXo16F1+MO+wyaJixSK7vt03sCcV5FbfL8d4yTzYXs0javY9+U+pChGu1z54DvcrRD9 DHHA6dxw36HECffp3eA2HTkmTRNEvxkLTyyvEe7kb2/ChpiYVgNN3enVCU1f1bgT6Nu54xfXuKFV Pv/qkcfuN7VlbwIJvprZPtGo5+FOtuc2FxF987vzFh6nuwQKYnaJetuc3zbn4D/fnOfV88W35GkX hgatt0x2o2223cncXfeQMtZTE0ZuSLPxlrD2RF0Y1HLmxEnKU1gWw09dyTCBgxsJbGSQ4OpDquJe jDPYtNcDrWQkc9UjiTIu4bBohr26NR42/soeNZf1IcR2DonVDo/s8JIeLs4apRpj1cgcaIuJlrSC s062dDlXCr69zmR1bdSZZ6sb00xTdGYrXdYUm0M5UF66BoMlm7CpQbAVApZX4Myvp4bDDmYk0rzb GBVhMVH4e0KUe20diXFEbIic4QqbdRO7IoVm/NPu2Rw5H5sla0Da6UaYtJifP2ckuVAwJRkET1YT S6u1xVJ02AzWlheXAxTirBkM4ZgLP5MMgib1NhCzEdwVhUrYrD21Fk2RTj1e82dVHW4u5hSMU8aZ kGoLy9jG0LzKQ8VSPZO1f3G5oZPtYhzwNJOzWbG0Cinyr1kBoXZDS4ZDEqpqsCsjmjv7mHdCPlZE 9OLoEA3YWOxhCD9wqv2JqITbClPQ+gGu1jTb5pXbW/NOU73QMjg7jlkW47xb6quZouIs3PST0gbz VDEPfPPabpw7vyu64i/KlWoa/89c0csBXB4sRToCIdzsCox0pTQDLlTMoQtlMQ27AtZ90zsgW+B6 Fl4D+XC/bP4X5ED/b2vO6jBlDWdAtUdHSFBYTlQsCNmFtmSy7xRl9XzpsSpZrshkVMVcmVmzB+SA sL7ugSu6BwcohlQ33SRvAwZ3Mv/c57yCBiO9R6nWm9PJyqXT1sA/vXGxxQxOndhL6Pwt+C9NLFf3 6epn5Y14sUZWHdEvprukRlEVzuK3tpZP9ZomnGUBrqy1tmPNeLy4XBgHUZz1GAbL/UwGV0BI/wPr HxUhsx8r9ILa53vQWxF8e7D8IcjqS7qrQQbpBml/DWDfYwdtMmlVltp856NZKxbrC96olvOeIFtb dpZ4n5PschPlTufU4kWSnTPscG3H5lINkT1ZojA0LM4hJjDmK1f1QxQf3INAb8GV/5jZT1MygydT B9muMNk14NEk/8mkXXBt1ukzjEaydI8MEY2OivNHyYQtIft5pNgiG7QW04lWCi75Dg2uYI7Xona1 LIUXTxcuJczM0LJLYXOX5lMAH8fyxq2PdoC3TdZ6rYurYIqlf4WyMxjvp8x78jkrZfag+MpAvQZl 6ujVlOVMAXmziQefNwWGo1fP9F9YdGymm5Td+BMAAP//AwBQSwMEFAAGAAgAAAAhAA3RkJ+2AAAA GwEAACcAAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIueG1sLnJlbHOEj00KwjAUhPeC dwhvb9O6EJEm3YjQrdQDhOQ1DTY/JFHs7Q2uLAguh2G+mWm7l53JE2My3jFoqhoIOumVcZrBbbjs jkBSFk6J2TtksGCCjm837RVnkUsoTSYkUiguMZhyDidKk5zQilT5gK44o49W5CKjpkHIu9BI93V9 oPGbAXzFJL1iEHvVABmWUJr/s/04GolnLx8WXf5RQXPZhQUoosbM4CObqkwEylu6usTfAAAA//8D AFBLAQItABQABgAIAAAAIQCb6HBP/AAAABwCAAATAAAAAAAAAAAAAAAAAAAAAABbQ29udGVudF9U eXBlc10ueG1sUEsBAi0AFAAGAAgAAAAhAKXWp+fAAAAANgEAAAsAAAAAAAAAAAAAAAAALQEAAF9y ZWxzLy5yZWxzUEsBAi0AFAAGAAgAAAAhAGt5lhaDAAAAigAAABwAAAAAAAAAAAAAAAAAFgIAAHRo ZW1lL3RoZW1lL3RoZW1lTWFuYWdlci54bWxQSwECLQAUAAYACAAAACEAIVqihCEHAADbHQAAFgAA AAAAAAAAAAAAAADTAgAAdGhlbWUvdGhlbWUvdGhlbWUxLnhtbFBLAQItABQABgAIAAAAIQAN0ZCf tgAAABsBAAAnAAAAAAAAAAAAAAAAACgKAAB0aGVtZS90aGVtZS9fcmVscy90aGVtZU1hbmFnZXIu eG1sLnJlbHNQSwUGAAAAAAUABQBdAQAAIwsAAAAA --_002_0DB8F45437AB844CBB5102F807A0AD93102CB212xmbrcdx03ciscoc_-- From ietfc@btconnect.com Tue Apr 2 01:36: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 632DC21F98A3 for ; Tue, 2 Apr 2013 01:36:43 -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 28KeCmclGjGK for ; Tue, 2 Apr 2013 01:36:42 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id B8A9E21F98A1 for ; Tue, 2 Apr 2013 01:36:39 -0700 (PDT) Received: from mail23-ch1-R.bigfish.com (10.43.68.234) by CH1EHSOBE010.bigfish.com (10.43.70.60) with Microsoft SMTP Server id 14.1.225.23; Tue, 2 Apr 2013 08:36:38 +0000 Received: from mail23-ch1 (localhost [127.0.0.1]) by mail23-ch1-R.bigfish.com (Postfix) with ESMTP id A945636016D; Tue, 2 Apr 2013 08:36:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.249.85; KIP:(null); UIP:(null); IPV:NLI; H:AMSPRD0710HT005.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -17 X-BigFish: PS-17(zz98dI9371I542I1432I4015I62a3I15c7mzz1f42h1fc6h1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL8275dh8275bhz2dh2a8h5a9h668h839h947hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah304l1155h) Received: from mail23-ch1 (localhost.localdomain [127.0.0.1]) by mail23-ch1 (MessageSwitch) id 1364891796585301_4647; Tue, 2 Apr 2013 08:36:36 +0000 (UTC) Received: from CH1EHSMHS016.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.227]) by mail23-ch1.bigfish.com (Postfix) with ESMTP id 82BE020006E; Tue, 2 Apr 2013 08:36:36 +0000 (UTC) Received: from AMSPRD0710HT005.eurprd07.prod.outlook.com (157.56.249.85) by CH1EHSMHS016.bigfish.com (10.43.70.16) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 2 Apr 2013 08:36:36 +0000 Received: from DB3PRD0511HT003.eurprd05.prod.outlook.com (157.56.254.213) by pod51017.outlook.com (10.255.160.168) with Microsoft SMTP Server (TLS) id 14.16.275.6; Tue, 2 Apr 2013 08:36:22 +0000 Message-ID: <01b801ce2f7c$8a4ee700$4001a8c0@gateway.2wire.net> From: t.petch To: Lizhong Jin , Loa Andersson References: <513E1C97.3050208@pi.nu> Date: Tue, 2 Apr 2013 09:31:51 +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.254.213] X-FOPE-CRA-SourceIpAddress: 157.56.249.85 X-FOPE-CRA-DRYRUN: 1207119;1 X-FOPE-BFA-SENDER: ietfc@btconnect.com X-FOPE-BFA-RECEIVER: mpls@ietf.org X-FOPE-BFA-RECEIVER: loa@pi.nu X-FOPE-BFA-RECEIVER: lizho.jin@gmail.com X-OriginatorOrg: btconnect.com Cc: mpls Subject: Re: [mpls] MPLS-RT review of draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-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, 02 Apr 2013 08:36:43 -0000 Lizhong Thank you for the review - yes, you are right to point out that the start of the draft should state that it updates RFC4379 Tom Petch ----- Original Message ----- From: "Lizhong Jin" To: "Loa Andersson" ; Cc: ; ; ; ; "Martin Vigoureux" ; Sent: Thursday, March 28, 2013 3:30 PM > Hi, all > I reviewed this draft, and think the document is useful, and is ready to be > considered for WG adoption. One minor comments, this draft should be an > update to RFC4379, and should be reflected at the beginning of the draft. > Then does that mean this draft should be moved faster than any other drafts > that require sub-tlv allocation. > > Regards > Lizhong > > > On Tue, Mar 12, 2013 at 2:04 AM, Loa Andersson wrote: > > > > > Dan, Xu, Lizhong and Rajiv, > > > > You have been selected as an MPLS Review team reviewers for > > draft-pac-mpls-lsp-ping-tlvs-**and-sub-tlvs-registry-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 April 2, 2013? > > > > Thanks, Loa > > (as MPLS WG chair) > > > > /Loa > > -- > > > > > > Loa Andersson email: loa@mail01.huawei.com > > Senior MPLS Expert loa@pi.nu > > Huawei Technologies (consult) phone: +46 739 81 21 64 > > > From paul.doolan@nsn.com Tue Apr 2 05:00: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 A3A0B21F9777; Tue, 2 Apr 2013 05:00:08 -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 Vyrr2vaXMhmI; Tue, 2 Apr 2013 05:00:07 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 634D521F9756; Tue, 2 Apr 2013 05:00:07 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id r32C02gC022611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Apr 2013 14:00:03 +0200 Received: from SGSIHTC002.nsn-intra.net ([10.159.225.19]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id r32BwVug015124 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Apr 2013 14:00:01 +0200 Received: from SGSIHTC004.nsn-intra.net (10.159.225.21) by SGSIHTC002.nsn-intra.net (10.159.225.19) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 2 Apr 2013 19:58:34 +0800 Received: from SGSIMBX001.nsn-intra.net ([169.254.1.109]) by SGSIHTC004.nsn-intra.net ([10.159.225.21]) with mapi id 14.03.0123.003; Tue, 2 Apr 2013 19:58:34 +0800 From: "Doolan, Paul (NSN - US/Irving)" To: "ext Luyuan Fang (lufang)" , Russ Housley , "ietf@ietf.org" Thread-Topic: [mpls] Last Call: Thread-Index: AQHOLz41gpocwnlmdkCids41O+SOypjC0o8w Date: Tue, 2 Apr 2013 11:58:33 +0000 Message-ID: <0D9D63ECB53A1449B376D2196ADC34159B2D43@SGSIMBX001.nsn-intra.net> References: <0DB8F45437AB844CBB5102F807A0AD93102CB212@xmb-rcd-x03.cisco.com> In-Reply-To: <0DB8F45437AB844CBB5102F807A0AD93102CB212@xmb-rcd-x03.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.121] X-TM-AS-Product-Ver: SMEX-10.0.0.4238-6.000.1038-15056.000 X-TM-AS-Result: No--9.880300-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 6332 X-purgate-ID: 151667::1364904003-000077CC-F50D59F9/0-0/0-0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Last 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: Tue, 02 Apr 2013 12:00:08 -0000 Hi Luyuan, You wrote (in part): ......since multiplexing of bursty sources is far more efficient over tradi= tional circuit-based TDM technologies. Which is not true and probably not what you meant.=20 A better formulation might be "since packet multiplexing of traffic from bu= rsty sources provides more efficient use of bandwidth than traditional circ= uit-based TDM technologies". To be honest however, I'd cut the traditional and use only TDM (since some = 'circuit' based technologies also offer packet multiplexing) so I'd reduce = it to: A better formulation might be "since packet multiplexing of traffic from bu= rsty sources provides more efficient use of bandwidth than TDM technologies= ". cheers, pd -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext= Luyuan Fang (lufang) Sent: Monday, April 01, 2013 9:05 PM To: Russ Housley; ietf@ietf.org Cc: mpls@ietf.org Subject: Re: [mpls] Last Call: Hi Russ, Thanks for your comments, very good points. Sorry for the delay in replying, I was out of office. =20 The following is my proposed text for replacing the current first paragraph of section 1.2. =20 Traditional transport technologies include SONET/SDH, TDM, and ATM. There is a transition away from these transport technologies to new packet technologies. In addition to the ever increasing demand for bandwidth, the packet technologies offer these key advantages: =20 Bandwidth efficiency: Transport technologies supports fixed Bandwidth only, no packet statistical multiplexing, bandwidth is reserved in transport whether used or not by clients. Packet technologies support statistical multiplexing, this is the most important motivation for the transition from traditional transport technologies to packet technologies. The proliferation of new distributed applications which communicate with servers over the network in a bursty fashion has been driving the adoption of packet transport techniques, since multiplexing of bursty sources is far more efficient over traditional circuit-based TDM technologies. =20 Flexible data rate connections: Traditional transport connection granularity is limited to the rigid PDH or SONET hierarchy (e.g., DS1, DS3, OC3, OC12, etc.). Packet technologies support flexible data rate connections. The support of finer data rate granularity is important for today=B9s wireline and wireles= s services and applications. =20 QoS support: While traditional transport, such as TDM transport has very limited QoS support, packet transport can provide needed QoS treatment for IPTV, Voice and Video over IP applications. =20 The root cause for transport moving to packet transport is the shift of application from TDM to packet. For example, Voice TDM to VoIP; Video to Video over IP; TDM access lines to Ethernet; TDM VPNs to IP VPNs and Ethernet VPNs. In addition, network convergence and technology refreshes demand for common and flexible infrastructure that provides multiple services. =20 Thanks, Luyuan -----Original Message----- From: Russ Housley Date: Saturday, March 23, 2013 3:16 PM To: "ietf@ietf.org" Cc: "mpls@ietf.org" Subject: Re: [mpls] Last Call: >I wonder if the direction of Section 1.2 can be revised to make it more >of an engineering document. > >It currently says: > > In recent years, the urgency for moving from traditional transport > technologies, such as SONET/SDH, TDM, and ATM, to new packet > technologies has been rising. This is largely due to the fast growing > demand for bandwidth, which has been fueled by the following factors: > ... > >Please consider an approach that describes the the reasons behind the >transition from the network operator and network user perspectives: > > Traditional transport technologies include SONET/SDH, TDM, and ATM. > There is a transition away from these transport technologies to new > packet technologies. In addition to the ever increasing demand for > bandwidth, the packet technologies offer these advantages: > ... > >The fact that IP networks are being used for new applications and that >the legacy devices are getting old does not motivate the transition to >packet technologies. The advantages that packet technologies offer for >these new applications is the thing that needs to be highlighted here, >even if it is just a list of bullets. > >It seems like the only sentence that addresses this point in Section 1.2 >is: "It streamlines the operation, reduces the overall complexity, and >improves end-to-end convergence." > >Thanks, > Russ > >On Jan 28, 2013, at 3:01 PM, The IESG wrote: > >> The IESG has received a request from the Multiprotocol Label Switching >>WG >> (mpls) to consider the following document: >> - 'MPLS-TP Applicability; Use Cases and Design' >> as Informational RFC >>=20 >> 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-02-11. Exceptionally, comments may >>be >> sent to iesg@ietf.org instead. In either case, please retain the >> beginning of the Subject line to allow automated sorting. >>=20 >> Abstract >>=20 >> This document provides applicability, use case studies and network >> design considerations for the Multiprotocol Label Switching Transport >> Profile (MPLS-TP). The use cases include Metro Ethernet access and >> aggregation transport, Mobile backhaul, and packet optical transport. >>=20 >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-use-cases-and-design/ >>=20 >> IESG discussion can be tracked via >>=20 >>http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-use-cases-and-design/b >>allot/ >>=20 >>=20 >> No IPR declarations have been submitted directly on this I-D. > >_______________________________________________ >mpls mailing list >mpls@ietf.org >https://www.ietf.org/mailman/listinfo/mpls From lufang@cisco.com Tue Apr 2 05:46: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 40E8321F978D; Tue, 2 Apr 2013 05:46:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.846 X-Spam-Level: X-Spam-Status: No, score=-8.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, 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 RKDYmmUCKGOW; Tue, 2 Apr 2013 05:46:16 -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 51E4621F978C; Tue, 2 Apr 2013 05:46:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9398; q=dns/txt; s=iport; t=1364906774; x=1366116374; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=aYWAoLw7Z9Galx9QK5qGK8gyVfVKWtRUAJTH8kQGKFc=; b=bY25OYe3DIm96I7joRjmSdMKiI0qe/uELBof4IEGi9/83mkYlLyM0/AL d9IMveetJlgZVqH7px9fWKUV9lxT4kX/vEz1gWxHyIj5tSTOcBvFV3wFC JIdTFCvZdDP+YZcE3+x4WEDKgJzGeKMx8r9Rk0XhofEgq9jsewikqJShB Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAJPSWlGtJV2d/2dsb2JhbABDgzuDILwkDXcWdIIfAQEBBAEBATE6CwwGAQgRAwEBAQEEBh0FBCULFAkIAgQBDQUIiAwMk16afgaCQpAQgR2MVYEFAgYgCwcCAgKCIThhA5gKj2yDC4FqPg X-IronPort-AV: E=Sophos;i="4.87,393,1363132800"; d="scan'208";a="194076017" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 02 Apr 2013 12:46:13 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r32CkDf6018299 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Apr 2013 12:46:13 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.17]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Tue, 2 Apr 2013 07:46:13 -0500 From: "Luyuan Fang (lufang)" To: "Doolan, Paul (NSN - US/Irving)" , Russ Housley , "ietf@ietf.org" Thread-Topic: [mpls] Last Call: Thread-Index: AQHOLz4pe+S4mct/bEWgHAuKWl97qJjDKCGA///KQAA= Date: Tue, 2 Apr 2013 12:46:12 +0000 Message-ID: <0DB8F45437AB844CBB5102F807A0AD93102CB82D@xmb-rcd-x03.cisco.com> In-Reply-To: <0D9D63ECB53A1449B376D2196ADC34159B2D43@SGSIMBX001.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.21.92.107] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "mpls@ietf.org" Subject: Re: [mpls] Last 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: Tue, 02 Apr 2013 12:46:17 -0000 V29ya3MgZm9yIG1lLiBUaGFua3MsIFBhdWwuDQpMdXl1YW4NCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IDxEb29sYW4+LCAiUGF1bCAgIChOU04gLSBVUy9JcnZpbmcpIiA8cGF1 bC5kb29sYW5AbnNuLmNvbT4NCkRhdGU6IFR1ZXNkYXksIEFwcmlsIDIsIDIwMTMgNzo1OCBBTQ0K VG86IEx1eXVhbiBGYW5nIDxsdWZhbmdAY2lzY28uY29tPiwgUnVzcyBIb3VzbGV5IDxob3VzbGV5 QHZpZ2lsc2VjLmNvbT4sDQoiaWV0ZkBpZXRmLm9yZyIgPGlldGZAaWV0Zi5vcmc+DQpDYzogIm1w bHNAaWV0Zi5vcmciIDxtcGxzQGlldGYub3JnPg0KU3ViamVjdDogUkU6IFttcGxzXSBMYXN0IENh bGw6DQo8ZHJhZnQtaWV0Zi1tcGxzLXRwLXVzZS1jYXNlcy1hbmQtZGVzaWduLTA2LnR4dD4NCg0K PkhpIEx1eXVhbiwNCj4NCj5Zb3Ugd3JvdGUgKGluIHBhcnQpOg0KPg0KPi4uLi4uLnNpbmNlIG11 bHRpcGxleGluZyBvZiBidXJzdHkgc291cmNlcyBpcyBmYXIgbW9yZSBlZmZpY2llbnQgb3Zlcg0K PnRyYWRpdGlvbmFsIGNpcmN1aXQtYmFzZWQNCj5URE0gdGVjaG5vbG9naWVzLg0KPg0KPldoaWNo IGlzIG5vdCB0cnVlIGFuZCBwcm9iYWJseSBub3Qgd2hhdCB5b3UgbWVhbnQuDQo+DQo+QSBiZXR0 ZXIgZm9ybXVsYXRpb24gbWlnaHQgYmUgInNpbmNlIHBhY2tldCBtdWx0aXBsZXhpbmcgb2YgdHJh ZmZpYyBmcm9tDQo+YnVyc3R5IHNvdXJjZXMgcHJvdmlkZXMgbW9yZSBlZmZpY2llbnQgdXNlIG9m IGJhbmR3aWR0aCB0aGFuIHRyYWRpdGlvbmFsDQo+Y2lyY3VpdC1iYXNlZCBURE0gdGVjaG5vbG9n aWVzIi4NCj4NCj5UbyBiZSBob25lc3QgaG93ZXZlciwgSSdkIGN1dCB0aGUgdHJhZGl0aW9uYWwg YW5kIHVzZSBvbmx5IFRETSAoc2luY2UNCj5zb21lICdjaXJjdWl0JyBiYXNlZCB0ZWNobm9sb2dp ZXMgYWxzbyBvZmZlciBwYWNrZXQgbXVsdGlwbGV4aW5nKSBzbyBJJ2QNCj5yZWR1Y2UgaXQgdG86 DQo+DQo+QSBiZXR0ZXIgZm9ybXVsYXRpb24gbWlnaHQgYmUgInNpbmNlIHBhY2tldCBtdWx0aXBs ZXhpbmcgb2YgdHJhZmZpYyBmcm9tDQo+YnVyc3R5IHNvdXJjZXMgcHJvdmlkZXMgbW9yZSBlZmZp Y2llbnQgdXNlIG9mIGJhbmR3aWR0aCB0aGFuIFRETQ0KPnRlY2hub2xvZ2llcyIuDQo+DQo+DQo+ Y2hlZXJzLA0KPnBkDQo+DQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBt cGxzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzptcGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJl aGFsZiBPZg0KPmV4dCBMdXl1YW4gRmFuZyAobHVmYW5nKQ0KPlNlbnQ6IE1vbmRheSwgQXByaWwg MDEsIDIwMTMgOTowNSBQTQ0KPlRvOiBSdXNzIEhvdXNsZXk7IGlldGZAaWV0Zi5vcmcNCj5DYzog bXBsc0BpZXRmLm9yZw0KPlN1YmplY3Q6IFJlOiBbbXBsc10gTGFzdCBDYWxsOg0KPjxkcmFmdC1p ZXRmLW1wbHMtdHAtdXNlLWNhc2VzLWFuZC1kZXNpZ24tMDYudHh0Pg0KPg0KPkhpIFJ1c3MsDQo+ DQo+VGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLCB2ZXJ5IGdvb2QgcG9pbnRzLg0KPlNvcnJ5IGZv ciB0aGUgZGVsYXkgaW4gcmVwbHlpbmcsIEkgd2FzIG91dCBvZiBvZmZpY2UuDQo+DQo+IA0KPlRo ZSBmb2xsb3dpbmcgaXMgbXkgcHJvcG9zZWQgdGV4dCBmb3IgcmVwbGFjaW5nIHRoZSBjdXJyZW50 IGZpcnN0DQo+cGFyYWdyYXBoIG9mIHNlY3Rpb24gMS4yLg0KPg0KPiANCj5UcmFkaXRpb25hbCB0 cmFuc3BvcnQgdGVjaG5vbG9naWVzIGluY2x1ZGUgU09ORVQvU0RILCBURE0sIGFuZCBBVE0uIFRo ZXJlDQo+aXMgYSB0cmFuc2l0aW9uIGF3YXkgZnJvbSB0aGVzZSB0cmFuc3BvcnQgdGVjaG5vbG9n aWVzIHRvIG5ldyBwYWNrZXQNCj50ZWNobm9sb2dpZXMuDQo+SW4gYWRkaXRpb24gdG8gdGhlIGV2 ZXIgaW5jcmVhc2luZyBkZW1hbmQgZm9yIGJhbmR3aWR0aCwgdGhlIHBhY2tldA0KPnRlY2hub2xv Z2llcyBvZmZlciB0aGVzZSBrZXkgYWR2YW50YWdlczoNCj4NCj4gDQo+QmFuZHdpZHRoIGVmZmlj aWVuY3k6IFRyYW5zcG9ydCB0ZWNobm9sb2dpZXMgc3VwcG9ydHMgZml4ZWQgQmFuZHdpZHRoDQo+ b25seSwgbm8gcGFja2V0IHN0YXRpc3RpY2FsIG11bHRpcGxleGluZywgYmFuZHdpZHRoIGlzIHJl c2VydmVkIGluDQo+dHJhbnNwb3J0DQo+d2hldGhlciB1c2VkIG9yIG5vdCBieSBjbGllbnRzLiBQ YWNrZXQgdGVjaG5vbG9naWVzIHN1cHBvcnQgc3RhdGlzdGljYWwNCj5tdWx0aXBsZXhpbmcsDQo+ dGhpcyBpcyB0aGUgbW9zdCBpbXBvcnRhbnQgbW90aXZhdGlvbiBmb3IgdGhlIHRyYW5zaXRpb24g ZnJvbSB0cmFkaXRpb25hbA0KPnRyYW5zcG9ydCB0ZWNobm9sb2dpZXMgdG8gcGFja2V0IHRlY2hu b2xvZ2llcy4gVGhlIHByb2xpZmVyYXRpb24gb2YgbmV3DQo+ZGlzdHJpYnV0ZWQgYXBwbGljYXRp b25zIHdoaWNoIGNvbW11bmljYXRlIHdpdGggc2VydmVycyBvdmVyIHRoZSBuZXR3b3JrDQo+aW4g YQ0KPmJ1cnN0eSBmYXNoaW9uIGhhcyBiZWVuIGRyaXZpbmcgdGhlIGFkb3B0aW9uIG9mIHBhY2tl dCB0cmFuc3BvcnQNCj50ZWNobmlxdWVzLCBzaW5jZQ0KPm11bHRpcGxleGluZyBvZiBidXJzdHkg c291cmNlcyBpcyBmYXIgbW9yZSBlZmZpY2llbnQgb3ZlciB0cmFkaXRpb25hbA0KPmNpcmN1aXQt YmFzZWQNCj5URE0gdGVjaG5vbG9naWVzLg0KPg0KPiANCj5GbGV4aWJsZSBkYXRhIHJhdGUgY29u bmVjdGlvbnM6IFRyYWRpdGlvbmFsIHRyYW5zcG9ydCBjb25uZWN0aW9uDQo+Z3JhbnVsYXJpdHkN Cj5pcyBsaW1pdGVkIHRvIHRoZSByaWdpZCBQREggb3IgU09ORVQgaGllcmFyY2h5IChlLmcuLCBE UzEsIERTMywgT0MzLCBPQzEyLA0KPmV0Yy4pLg0KPlBhY2tldCB0ZWNobm9sb2dpZXMgc3VwcG9y dCBmbGV4aWJsZSBkYXRhIHJhdGUgY29ubmVjdGlvbnMuIFRoZSBzdXBwb3J0IG9mDQo+ZmluZXIg ZGF0YSByYXRlIGdyYW51bGFyaXR5IGlzIGltcG9ydGFudCBmb3IgdG9kYXmp9nMgd2lyZWxpbmUg YW5kIHdpcmVsZXNzDQo+c2VydmljZXMgYW5kIGFwcGxpY2F0aW9ucy4NCj4NCj4gDQo+UW9TIHN1 cHBvcnQ6IFdoaWxlIHRyYWRpdGlvbmFsIHRyYW5zcG9ydCwgc3VjaCBhcyBURE0gdHJhbnNwb3J0 IGhhcw0KPnZlcnkgbGltaXRlZCBRb1Mgc3VwcG9ydCwgcGFja2V0IHRyYW5zcG9ydCBjYW4gcHJv dmlkZSBuZWVkZWQgUW9TDQo+dHJlYXRtZW50IGZvcg0KPklQVFYsIFZvaWNlIGFuZCBWaWRlbyBv dmVyIElQIGFwcGxpY2F0aW9ucy4NCj4NCj4gDQo+VGhlIHJvb3QgY2F1c2UgZm9yIHRyYW5zcG9y dCBtb3ZpbmcgdG8gcGFja2V0IHRyYW5zcG9ydCBpcyB0aGUgc2hpZnQNCj5vZiBhcHBsaWNhdGlv biBmcm9tIFRETSB0byBwYWNrZXQuIEZvciBleGFtcGxlLCBWb2ljZSBURE0gdG8gVm9JUDsgVmlk ZW8NCj50bw0KPlZpZGVvIG92ZXIgSVA7IFRETSBhY2Nlc3MgbGluZXMgdG8gRXRoZXJuZXQ7IFRE TSBWUE5zIHRvIElQIFZQTnMgYW5kDQo+RXRoZXJuZXQNCj5WUE5zLiBJbiBhZGRpdGlvbiwgbmV0 d29yayBjb252ZXJnZW5jZSBhbmQgdGVjaG5vbG9neSByZWZyZXNoZXMgZGVtYW5kIGZvcg0KPmNv bW1vbiBhbmQgZmxleGlibGUgaW5mcmFzdHJ1Y3R1cmUgdGhhdCBwcm92aWRlcyBtdWx0aXBsZSBz ZXJ2aWNlcy4NCj4NCj4gDQo+VGhhbmtzLA0KPkx1eXVhbg0KPg0KPg0KPg0KPi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogUnVzcyBIb3VzbGV5IDxob3VzbGV5QHZpZ2lsc2VjLmNv bT4NCj5EYXRlOiBTYXR1cmRheSwgTWFyY2ggMjMsIDIwMTMgMzoxNiBQTQ0KPlRvOiAiaWV0ZkBp ZXRmLm9yZyIgPGlldGZAaWV0Zi5vcmc+DQo+Q2M6ICJtcGxzQGlldGYub3JnIiA8bXBsc0BpZXRm Lm9yZz4NCj5TdWJqZWN0OiBSZTogW21wbHNdIExhc3QNCj5DYWxsOgk8ZHJhZnQtaWV0Zi1tcGxz LXRwLXVzZS1jYXNlcy1hbmQtZGVzaWduLTA2LnR4dD4NCj4NCj4+SSB3b25kZXIgaWYgdGhlIGRp cmVjdGlvbiBvZiBTZWN0aW9uIDEuMiBjYW4gYmUgcmV2aXNlZCB0byBtYWtlIGl0IG1vcmUNCj4+ b2YgYW4gZW5naW5lZXJpbmcgZG9jdW1lbnQuDQo+Pg0KPj5JdCBjdXJyZW50bHkgc2F5czoNCj4+ DQo+PiAgIEluIHJlY2VudCB5ZWFycywgdGhlIHVyZ2VuY3kgZm9yIG1vdmluZyBmcm9tIHRyYWRp dGlvbmFsIHRyYW5zcG9ydA0KPj4gICB0ZWNobm9sb2dpZXMsIHN1Y2ggYXMgU09ORVQvU0RILCBU RE0sIGFuZCBBVE0sIHRvIG5ldyBwYWNrZXQNCj4+ICAgdGVjaG5vbG9naWVzIGhhcyBiZWVuIHJp c2luZy4gVGhpcyBpcyBsYXJnZWx5IGR1ZSB0byB0aGUgZmFzdCBncm93aW5nDQo+PiAgIGRlbWFu ZCBmb3IgYmFuZHdpZHRoLCB3aGljaCBoYXMgYmVlbiBmdWVsZWQgYnkgdGhlIGZvbGxvd2luZyBm YWN0b3JzOg0KPj4gICAuLi4NCj4+DQo+PlBsZWFzZSBjb25zaWRlciBhbiBhcHByb2FjaCB0aGF0 IGRlc2NyaWJlcyB0aGUgdGhlIHJlYXNvbnMgYmVoaW5kIHRoZQ0KPj50cmFuc2l0aW9uIGZyb20g dGhlIG5ldHdvcmsgb3BlcmF0b3IgYW5kIG5ldHdvcmsgdXNlciBwZXJzcGVjdGl2ZXM6DQo+Pg0K Pj4gICBUcmFkaXRpb25hbCB0cmFuc3BvcnQgdGVjaG5vbG9naWVzIGluY2x1ZGUgU09ORVQvU0RI LCBURE0sIGFuZCBBVE0uDQo+PiAgIFRoZXJlIGlzIGEgdHJhbnNpdGlvbiBhd2F5IGZyb20gdGhl c2UgdHJhbnNwb3J0IHRlY2hub2xvZ2llcyB0byBuZXcNCj4+ICAgcGFja2V0IHRlY2hub2xvZ2ll cy4gSW4gYWRkaXRpb24gdG8gdGhlIGV2ZXIgaW5jcmVhc2luZyBkZW1hbmQgZm9yDQo+PiAgIGJh bmR3aWR0aCwgdGhlIHBhY2tldCB0ZWNobm9sb2dpZXMgb2ZmZXIgdGhlc2UgYWR2YW50YWdlczoN Cj4+ICAgLi4uDQo+Pg0KPj5UaGUgZmFjdCB0aGF0IElQIG5ldHdvcmtzIGFyZSBiZWluZyB1c2Vk IGZvciBuZXcgYXBwbGljYXRpb25zIGFuZCB0aGF0DQo+PnRoZSBsZWdhY3kgZGV2aWNlcyBhcmUg Z2V0dGluZyBvbGQgZG9lcyBub3QgbW90aXZhdGUgdGhlIHRyYW5zaXRpb24gdG8NCj4+cGFja2V0 IHRlY2hub2xvZ2llcy4gIFRoZSBhZHZhbnRhZ2VzIHRoYXQgcGFja2V0IHRlY2hub2xvZ2llcyBv ZmZlciBmb3INCj4+dGhlc2UgbmV3IGFwcGxpY2F0aW9ucyBpcyB0aGUgdGhpbmcgdGhhdCBuZWVk cyB0byBiZSBoaWdobGlnaHRlZCBoZXJlLA0KPj5ldmVuIGlmIGl0IGlzIGp1c3QgYSBsaXN0IG9m IGJ1bGxldHMuDQo+Pg0KPj5JdCBzZWVtcyBsaWtlIHRoZSBvbmx5IHNlbnRlbmNlIHRoYXQgYWRk cmVzc2VzIHRoaXMgcG9pbnQgaW4gU2VjdGlvbiAxLjINCj4+aXM6ICJJdCBzdHJlYW1saW5lcyB0 aGUgb3BlcmF0aW9uLCByZWR1Y2VzIHRoZSBvdmVyYWxsIGNvbXBsZXhpdHksIGFuZA0KPj5pbXBy b3ZlcyBlbmQtdG8tZW5kIGNvbnZlcmdlbmNlLiINCj4+DQo+PlRoYW5rcywNCj4+ICBSdXNzDQo+ Pg0KPj5PbiBKYW4gMjgsIDIwMTMsIGF0IDM6MDEgUE0sIFRoZSBJRVNHIHdyb3RlOg0KPj4NCj4+ PiBUaGUgSUVTRyBoYXMgcmVjZWl2ZWQgYSByZXF1ZXN0IGZyb20gdGhlIE11bHRpcHJvdG9jb2wg TGFiZWwgU3dpdGNoaW5nDQo+Pj5XRw0KPj4+IChtcGxzKSB0byBjb25zaWRlciB0aGUgZm9sbG93 aW5nIGRvY3VtZW50Og0KPj4+IC0gJ01QTFMtVFAgQXBwbGljYWJpbGl0eTsgVXNlIENhc2VzIGFu ZCBEZXNpZ24nDQo+Pj4gIDxkcmFmdC1pZXRmLW1wbHMtdHAtdXNlLWNhc2VzLWFuZC1kZXNpZ24t MDYudHh0PiBhcyBJbmZvcm1hdGlvbmFsIFJGQw0KPj4+IA0KPj4+IFRoZSBJRVNHIHBsYW5zIHRv IG1ha2UgYSBkZWNpc2lvbiBpbiB0aGUgbmV4dCBmZXcgd2Vla3MsIGFuZCBzb2xpY2l0cw0KPj4+ IGZpbmFsIGNvbW1lbnRzIG9uIHRoaXMgYWN0aW9uLiBQbGVhc2Ugc2VuZCBzdWJzdGFudGl2ZSBj b21tZW50cyB0byB0aGUNCj4+PiBpZXRmQGlldGYub3JnIG1haWxpbmcgbGlzdHMgYnkgMjAxMy0w Mi0xMS4gRXhjZXB0aW9uYWxseSwgY29tbWVudHMgbWF5DQo+Pj5iZQ0KPj4+IHNlbnQgdG8gaWVz Z0BpZXRmLm9yZyBpbnN0ZWFkLiBJbiBlaXRoZXIgY2FzZSwgcGxlYXNlIHJldGFpbiB0aGUNCj4+ PiBiZWdpbm5pbmcgb2YgdGhlIFN1YmplY3QgbGluZSB0byBhbGxvdyBhdXRvbWF0ZWQgc29ydGlu Zy4NCj4+PiANCj4+PiBBYnN0cmFjdA0KPj4+IA0KPj4+ICAgVGhpcyBkb2N1bWVudCBwcm92aWRl cyBhcHBsaWNhYmlsaXR5LCB1c2UgY2FzZSBzdHVkaWVzIGFuZCBuZXR3b3JrDQo+Pj4gICBkZXNp Z24gY29uc2lkZXJhdGlvbnMgZm9yIHRoZSBNdWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGluZyBU cmFuc3BvcnQNCj4+PiAgIFByb2ZpbGUgKE1QTFMtVFApLiBUaGUgdXNlIGNhc2VzIGluY2x1ZGUg TWV0cm8gRXRoZXJuZXQgYWNjZXNzIGFuZA0KPj4+ICAgYWdncmVnYXRpb24gdHJhbnNwb3J0LCBN b2JpbGUgYmFja2hhdWwsIGFuZCBwYWNrZXQgb3B0aWNhbCB0cmFuc3BvcnQuDQo+Pj4gDQo+Pj4g VGhlIGZpbGUgY2FuIGJlIG9idGFpbmVkIHZpYQ0KPj4+IA0KPj4+aHR0cDovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1wbHMtdHAtdXNlLWNhc2VzLWFuZC1kZXNpZ24vDQo+ Pj4gDQo+Pj4gSUVTRyBkaXNjdXNzaW9uIGNhbiBiZSB0cmFja2VkIHZpYQ0KPj4+IA0KPj4+aHR0 cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW1wbHMtdHAtdXNlLWNhc2Vz LWFuZC1kZXNpZ24vDQo+Pj5iDQo+Pj5hbGxvdC8NCj4+PiANCj4+PiANCj4+PiBObyBJUFIgZGVj bGFyYXRpb25zIGhhdmUgYmVlbiBzdWJtaXR0ZWQgZGlyZWN0bHkgb24gdGhpcyBJLUQuDQo+Pg0K Pj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj5tcGxz IG1haWxpbmcgbGlzdA0KPj5tcGxzQGlldGYub3JnDQo+Pmh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vbXBscw0KPg0KDQo= From hejia@huawei.com Tue Apr 2 06:37: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 410D221F88FB for ; Tue, 2 Apr 2013 06:37:42 -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 8as5KXu8kG6b for ; Tue, 2 Apr 2013 06:37:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DEA9D21F8895 for ; Tue, 2 Apr 2013 06:37:40 -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 ARI51218; Tue, 02 Apr 2013 13:37:39 +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; Tue, 2 Apr 2013 14:37:23 +0100 Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 2 Apr 2013 14:37:33 +0100 Received: from SZXEML505-MBX.china.huawei.com ([169.254.1.173]) by szxeml403-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Tue, 2 Apr 2013 21:37:08 +0800 From: "Hejia (Jia)" To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] working group last call on draft-ietf-mpls-tp-temporal-hitless-psm Thread-Index: AQHOIMXsGeE84CgodkKMY6z7RhzmKZjC8vSA Date: Tue, 2 Apr 2013 13:37:07 +0000 Message-ID: <735916399E11684EAF4EB4FB376B71952BF8EA4F@SZXEML505-MBX.china.huawei.com> References: <5141E7EC.3090901@pi.nu> In-Reply-To: <5141E7EC.3090901@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-chairs@tools.ietf.org" , "draft-ietf-mpls-tp-temporal-hitless-psm@tools.ietf.org" Subject: Re: [mpls] working group last call on 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: Tue, 02 Apr 2013 13:37:42 -0000 RGVhciBhdXRob3JzLA0KDQpJIGdlbmVyYWxseSBzdXBwb3J0IHRoZSBjb25zaWRlcmF0aW9ucyBk ZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudC4gQnV0IEkgaGF2ZSB0d28gbWlub3IgcG9pbnRzIGZv ciBjbGFyaWZpY2F0aW9uLg0KDQoxKSBJbiBTZWN0aW9uIDQsIGl0IG1pZ2h0IGJlIG5vdCBwcm9w ZXIgdG8gc2F5ICJUaGVyZSBpcyBubyBzdGFuZGFyZGl6ZWQgd2F5IHRvIGlkZW50aWZ5IGEgbGF5 ZXIiLiBJIHRoaW5rIFJGQyA2MzcwIChNUExTLVRQIGlkZW50aWZpZXJzKSBpcyBkZWZpbmluZyBp ZGVudGlmaWVycyBpbmNsdWRpbmcgdGhvc2Ugb2YgU1BNRXMuIEJ1dCBJIGRvIGFncmVlIHdpdGgg UHJvYmxlbSAoUC0yKSBpdHNlbGYgdGhhdCB0aGUgY29uZmlndXJhdGlvbiBvZiBNRVBzIGFuZCBN SVBzIHdpbGwgY2F1c2UgY29tcGxleGl0eSBpbiBjYXNlIG9mIHBhdGggc2VnbWVudCBtb25pdG9y aW5nLg0KDQoyKSBNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhpcyBkcmFmdCBpcyBhIHByb2Js ZW0gc3RhdGVtZW50IGFuZCByZXF1aXJlbWVudCBkb2N1bWVudCB3aGlsZSB0aGUgc29sdXRpb24g Zm9yIEhQU00gd2lsbCBiZSBhZGRyZXNzZWQgaW4gYW5vdGhlciBkb2N1bWVudC4gQW0gSSByaWdo dD8gQnV0IGl0IHNlZW1zIFNlY3Rpb24gNi40IGlzIGltcGx5aW5nIHNvbHV0aW9ucyBmb3IgSFBT TSAoVFRMLWJhc2VkKS4gDQoNClRoYW5rcyENCg0KQi5SLg0KSmlhDQoNCg0KDQotLS0tLdPKvP7U rbz+LS0tLS0NCreivP7IyzogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3Vu Y2VzQGlldGYub3JnXSC0+rHtIExvYSBBbmRlcnNzb24NCreiy83KsbzkOiAyMDEzxOoz1MIxNMjV IDIzOjA4DQrK1bz+yMs6IG1wbHNAaWV0Zi5vcmcNCrOty806IG1wbHMtY2hhaXJzQHRvb2xzLmll dGYub3JnOyBkcmFmdC1pZXRmLW1wbHMtdHAtdGVtcG9yYWwtaGl0bGVzcy1wc21AdG9vbHMuaWV0 Zi5vcmcNCtb3zOI6IFttcGxzXSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbiBkcmFmdC1pZXRm LW1wbHMtdHAtdGVtcG9yYWwtaGl0bGVzcy1wc20NCg0KV29ya2luZyBHcm91cCwNCg0KdGhpcyBp cyB0byBzdGFydCBhIHR3byB3ZWVrIFdvcmtpbmcgR3JvdXAgbGFzdCBjYWxsIG9uDQpkcmFmdC1p ZXRmLW1wbHMtdHAtdGVtcG9yYWwtaGl0bGVzcy1wc20tMDIudHh0Lg0KDQpQbGVhc2Ugc2VuZCB5 b3VyIGNvbW1lbnRzIHRvIHRoZSBtcGxzIHdvcmtpbmcgZ3JvdXANCm1haWxpbmcgbGlzdCAobXBs c0BpZXRmLm9yZykuDQoNClBsZWFzZSBzZW5kIGJvdGggdGVjaG5pY2FsIGNvbW1lbnRzLCBhbmQg aWYgeW91IGFyZSBoYXBweQ0Kd2l0aCB0aGUgZG9jdW1lbnQgYXMgaXMgYWxzbyBpbmRpY2F0aW9u cyBvZiBzdXBwb3J0Lg0KDQpUaGVyZSBhcmUgbm8gSVBSIGNsYWltcyBhZ2FpbnN0IHRoaXMgZHJh ZnQuDQoNClRoZSBjby1hdXRob3JzIGhhdmUgZWFybGllciBzdGF0ZWQgdGhhdCB0aGV5IGFyZSBu b3QgYXdhcmUNCm9mIGFueSBJUFJzIGFwcGxpY2FibGUgdG8gdGhpcyBkcmFmdC4NCg0KSWYgYW55 b25lIGVsc2UgaW4gdGhlIHdvcmtpbmcgZ3JvdXAgYXJlIGF3YXJlIG9mIElQUnMgY2xhaW1zIGFn YWluc3QNCnRoaXMgZHJhZnQsIHRoZSB0aW1lIHRvIGRpc2Nsb3NlIHRoYXQgaXMgbm93Lg0KDQpU aGlzIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIHdpbGwgZW5kIG9uIEFwcmlsIDIsIDIwMTMuDQoN Ci9Mb2ENCmZvciB0aGUgd2cgY28tY2hhaXJzDQotLSANCg0KDQpMb2EgQW5kZXJzc29uICAgICAg ICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbQ0KU2VuaW9yIE1Q TFMgRXhwZXJ0ICAgICAgICAgICAgICAgICAgICAgICAgICBsb2FAcGkubnUNCkh1YXdlaSBUZWNo bm9sb2dpZXMgKGNvbnN1bHQpICAgICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1wbHMgbWFpbGluZyBs aXN0DQptcGxzQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L21wbHMNCg== From ietf-ipr@ietf.org Tue Apr 2 09:02: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 62A8021F8CE5; Tue, 2 Apr 2013 09:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.243 X-Spam-Level: X-Spam-Status: No, score=-102.243 tagged_above=-999 required=5 tests=[AWL=0.357, 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 eMAnx0EnRURc; Tue, 2 Apr 2013 09:02:11 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 12ECE21F8576; Tue, 2 Apr 2013 09:02:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: raggarwa_1@yahoo.com, yakov@juniper.net X-Test-IDTracker: no X-IETF-IDTracker: 4.43 Message-ID: <20130402160211.21091.31745.idtracker@ietfa.amsl.com> Date: Tue, 02 Apr 2013 09:02:11 -0700 Cc: mpls@ietf.org, rcallon@juniper.net, ipr-announce@ietf.org, loa@pi.nu Subject: [mpls] IPR Disclosure: Juniper's Statement of IPR related to draft-ietf-mpls-seamless-mcast-06 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, 02 Apr 2013 16:02:11 -0000 Dear Rahul Aggarwal, Yakov Rekhter: An IPR disclosure that pertains to your Internet-Draft entitled "Inter-Area P2MP Segmented LSPs" (draft-ietf-mpls-seamless-mcast) was submitted to the = IETF Secretariat on 2013-04-01 and has been posted on the "IETF Page of Intellec= tual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2047/). The = title of the IPR disclosure is "Juniper's Statement of IPR related to draft-ietf-= mpls- seamless-mcast-06.""); The IETF Secretariat From internet-drafts@ietf.org Tue Apr 2 15:36: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 2CDE421F8A09; Tue, 2 Apr 2013 15:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.535 X-Spam-Level: X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.065, 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 bbayBcKyuG-B; Tue, 2 Apr 2013 15:36:25 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D88621F8A08; Tue, 2 Apr 2013 15:36: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.43 Message-ID: <20130402223625.5301.92928.idtracker@ietfa.amsl.com> Date: Tue, 02 Apr 2013 15:36:25 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-mip-mep-map-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, 02 Apr 2013 22:36:26 -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 : Per-Interface MIP Addressing Requirements and Design Con= siderations Author(s) : Adrian Farrel Hideki Endo Rolf Winter Yoshinori Koike Manuel Paul Filename : draft-ietf-mpls-tp-mip-mep-map-06.txt Pages : 13 Date : 2013-04-02 Abstract: The Framework for Operations, Administration and Maintenance (OAM) within the MPLS Transport Profile (MPLS-TP) describes how Maintenance Entity Group Intermediate Points (MIPs) may be situated within network nodes at the incoming and outgoing interfaces. This document elaborates on important considerations for internal MIP addressing. More precisely it describes important restrictions for any mechanism that specifies a way of forming OAM messages so that they can be targeted at MIPs on incoming or MIPs on outgoing interfaces and forwarded correctly through the forwarding engine. Furthermore, the document includes considerations for node implementations where there is no distinction between the incoming and outgoing MIP. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-mip-mep-map There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-mip-mep-map-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-mip-mep-map-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From loa@pi.nu Tue Apr 2 20:55: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 E5CEF21F8881 for ; Tue, 2 Apr 2013 20:55:13 -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 g52tDw-HoOXT for ; Tue, 2 Apr 2013 20:55:08 -0700 (PDT) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCED21F8859 for ; Tue, 2 Apr 2013 20:55:08 -0700 (PDT) Received: from [192.168.10.101] (unknown [121.54.51.84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id 5D42A823B5; Wed, 3 Apr 2013 05:55:05 +0200 (CEST) Message-ID: <515BA818.9020305@pi.nu> Date: Wed, 03 Apr 2013 05:55:04 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "mpls@ietf.org" References: <5141E7EC.3090901@pi.nu> In-Reply-To: <5141E7EC.3090901@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: [mpls] Closed - Re: working group last call on 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, 03 Apr 2013 03:55:14 -0000 Worki8ng group, this working group has been closed. There is a small number of comments that needs to be addressed. Authors, Could you work through the comments, suggested resolution and make sure that the people who made the comments are comfortable with the resolution. I will place this document in Waiting for WG Go-Ahead::Revised ID needed /Loa On 2013-03-14 16:08, Loa Andersson wrote: > Working Group, > > this is to start a two week Working Group last call on > draft-ietf-mpls-tp-temporal-hitless-psm-02.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 2, 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 Tue Apr 2 22:59: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 D2D5721F86B2 for ; Tue, 2 Apr 2013 22:59: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 ni7Xz2yK2M4S for ; Tue, 2 Apr 2013 22:59:27 -0700 (PDT) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9D121F867E for ; Tue, 2 Apr 2013 22:59:26 -0700 (PDT) Received: from [192.168.10.101] (unknown [121.54.51.84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id 9D1B07FE07; Wed, 3 Apr 2013 07:59:15 +0200 (CEST) Message-ID: <515BC52E.6020207@pi.nu> Date: Wed, 03 Apr 2013 07:59:10 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: mpls@ietf.org, Jeff Wheeler References: <201303281411.r2SEBHJk058442@gateway1.orleans.occnc.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Wed, 03 Apr 2013 05:59:27 -0000 Jeff, replacing 0..15 with 0..N gives you a red flag day. All LSRs in your network needs to be updated a the same time. And if you have MPLS inter-connectivity between your mpls network and someone other networkz, you have to update all LSRs in all networks at the same time. Time is no remedy, you can do it now, in a year or in ten years. /Loa On 2013-03-28 23:08, Jeff Wheeler wrote: > On Thu, Mar 28, 2013 at 10:11 AM, Curtis Villamizar wrote: >> If something like GAL is proposed, then an upgraded LSR could >> potentially send a special purpose label to an older LSR that is using >> that label as a forwarding label. > > I don't agree. An SP label shouldn't end up at top-of-stack unless > the receiving LSR has signalled support for that extension. > > The problem is not top-of-stack issues, but middle-of-stack. If PE2 > is legacy and assigns label 17 for an application label, but P1, P2, > etc. are aware that is a new SP label that has some defined purpose, > they may take action on that packet based on the specification of SP > 17. > > All that needs to happen here is 0..15 be replaced with 0..N and > enough time to pass before the 0..15 space is exhausted that you can > reasonably expect all PEs in a network to receive software upgrades > before any features are specified and deployed to P nodes using SP > values > 15. This is a very reasonable expectation given the likely > huge lead-time before any such extended SP labels are required to be > allocated (if ever.) > > The question is, which of these is more likely: > 1) networks depend on PE that can't receive this software upgrade in > many years time; or > 2) networks depend on P that can't gain hardware ability to process > deeper label stack in many years time > > In both cases, the time-frame is years; but #2 is where hardware > limitations on label stack depth arise. Folks in this WG have argued > that hardware limits are an issue for changing 0..15 to 0..N and there > is no evidence of that. There is a large body of evidence that many > routers have degraded or unspecified behavior once label stack grows > beyond a certain depth, and these routers continue to be sold into > customer networks today. I do not expect that will change, or grow by > 2 labels, because of this draft. Do you? > > Quite simply, to have extended SP labels based on my suggestion, all a > customer must do is request his vendor produce software updates to not > use 16..N as forwarding labels. To have them based on this draft, he > may need to replace all of his hardware. I think we can all agree > that software updates are more realistic. > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From jsw@inconcepts.biz Tue Apr 2 23:38: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 DDD0421F86B7 for ; Tue, 2 Apr 2013 23:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.479 X-Spam-Level: X-Spam-Status: No, score=0.479 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RCVD_IN_PBL=0.905, 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 OX7+Qi9kZDxd for ; Tue, 2 Apr 2013 23:38:07 -0700 (PDT) Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 45E1C21F86AF for ; Tue, 2 Apr 2013 23:38:04 -0700 (PDT) Received: by mail-ie0-f176.google.com with SMTP id x14so1290159ief.7 for ; Tue, 02 Apr 2013 23:38:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=a6B4x6QYgPKhkEksh2yZ5vtErjp2hz4QDowZo4x3XKw=; b=pt1VTEEqjeo/42UNHx6fu+W5Fr+OEgkGamD3BeVJtMeGNR7j38xOmTop4FP39x7M4B JRkP3XgGO1QGkLg700VhSWBK0hRVQLt7UgWWfi2EnlQeywLcq2eG7kSIayxOoR5V4Z13 zEL0EiJ7dLD2x3vvLuC5arfZBkDAOn6+gGgLCBfE9Wrgz4ahOwmkGQL/yptQbOsOfQ8Y 78DEpySkLzWEWodgoOu4sINC5A3FnTDUvLYihIbzHqRHb3HdtEC4bIj2TsbaeDmX8m0P S3/VCTCboRl4GMKtMTB16DiWWGmO0+a6gSHx9N6w8qMjO9y8bVD/IIj/ZsPyBtYRUk1U efHQ== MIME-Version: 1.0 X-Received: by 10.50.180.197 with SMTP id dq5mr6388303igc.22.1364971083660; Tue, 02 Apr 2013 23:38:03 -0700 (PDT) Received: by 10.50.85.81 with HTTP; Tue, 2 Apr 2013 23:38:03 -0700 (PDT) X-Originating-IP: [74.134.22.105] In-Reply-To: <515BC52E.6020207@pi.nu> References: <201303281411.r2SEBHJk058442@gateway1.orleans.occnc.com> <515BC52E.6020207@pi.nu> Date: Wed, 3 Apr 2013 02:38:03 -0400 Message-ID: From: Jeff Wheeler To: Loa Andersson Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkvqls5I0K4j1ubC/c8O/27Rvilr8P1mpYfpCLppuK0Jb4EBTWH5+4DE14Fug4karbTZpSR Cc: mpls@ietf.org 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: Wed, 03 Apr 2013 06:38:08 -0000 On Wed, Apr 3, 2013 at 1:59 AM, Loa Andersson wrote: > replacing 0..15 with 0..N gives you a red flag day. All LSRs in > your network needs to be updated a the same time. And if you have > MPLS inter-connectivity between your mpls network and someone > other networkz, you have to update all LSRs in all networks at > the same time. Time is no remedy, you can do it now, in a year or > in ten years. That is an easily solved control-plane problem. An easily solved control-plane problem is greatly preferable to the problem you are creating, which increases the heat/power/density challenges of building future LSRs, and makes existing ones unable to implement new features due to the deeper label stack. Was there no consideration of what problems are caused by a deeper label stack? That seems to be the case. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From loa@pi.nu Wed Apr 3 03:45: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 DF9B521F85E8 for ; Wed, 3 Apr 2013 03:45:24 -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 DKNPWdH78F+n for ; Wed, 3 Apr 2013 03:45:24 -0700 (PDT) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 4D56621F858B for ; Wed, 3 Apr 2013 03:45:24 -0700 (PDT) Received: from [192.168.10.101] (unknown [121.54.51.84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id C80BC823B5; Wed, 3 Apr 2013 12:45:21 +0200 (CEST) Message-ID: <515C0840.8080301@pi.nu> Date: Wed, 03 Apr 2013 12:45:20 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Jeff Wheeler References: <201303281411.r2SEBHJk058442@gateway1.orleans.occnc.com> <515BC52E.6020207@pi.nu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: mpls@ietf.org Subject: [mpls] Relation between the number of special purpose labels and the depth of the label stack - Was:Re: 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: Wed, 03 Apr 2013 10:45:25 -0000 Jeff, I want to see separate discussions on separate problems. The way I read some of the mails in this discussion is that if we increase the number of with one, the label stack will be one label deeper. I seriously doubts this, it is potentially not true even in the were the new special purpose label is present in the label stack. Some special purpose labels changes what is in the stack in such a way that there are fewer labels. Do we have any hard figures on the relationship between the number of available number of special purpose labels and the depth of the label stack? Same for the number of labels to be processed, do we know which effect special purpose labels have on how many labels that need to be processed. /Loa On 2013-04-03 08:38, Jeff Wheeler wrote: > > An easily solved control-plane problem is greatly preferable to the > problem you are creating, which increases the heat/power/density > challenges of building future LSRs, and makes existing ones unable to > implement new features due to the deeper label stack. > > Was there no consideration of what problems are caused by a deeper > label stack? That seems to be the case. > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From hejia@huawei.com Wed Apr 3 06:18: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 2806221F8C10 for ; Wed, 3 Apr 2013 06:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.328 X-Spam-Level: X-Spam-Status: No, score=-4.328 tagged_above=-999 required=5 tests=[AWL=2.271, 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 gpG54v-ZddrP for ; Wed, 3 Apr 2013 06:18:38 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9796D21F8BBD for ; Wed, 3 Apr 2013 06:18:37 -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 AQA58258; Wed, 03 Apr 2013 13:18:23 +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; Wed, 3 Apr 2013 14:18:06 +0100 Received: from SZXEML450-HUB.china.huawei.com (10.82.67.193) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 3 Apr 2013 14:18:18 +0100 Received: from SZXEML505-MBX.china.huawei.com ([169.254.1.173]) by szxeml450-hub.china.huawei.com ([10.82.67.193]) with mapi id 14.01.0323.007; Wed, 3 Apr 2013 21:18:12 +0800 From: "Hejia (Jia)" To: "draft-kompella-mpls-special-purpose-labels@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , Martin Vigoureux Thread-Topic: [mpls] MPLS-RT review of draft-kompella-mpls-special-purpose-labels-02.txt Thread-Index: AQHOIdD5prGbDaYRlkqV362konpHqJiu8CiAgBWmGkA= Date: Wed, 3 Apr 2013 13:18:11 +0000 Message-ID: <735916399E11684EAF4EB4FB376B71952BF8F315@SZXEML505-MBX.china.huawei.com> References: <5143A82D.8010204@pi.nu> <4DDE473A58262547A699C1E7C7AAF2742A4651AB@BL2PRD0511MB435.namprd05.prod.outlook.com> In-Reply-To: <4DDE473A58262547A699C1E7C7AAF2742A4651AB@BL2PRD0511MB435.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.66.76.169] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-kompella-mpls-special-purpose-labels-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, 03 Apr 2013 13:18:39 -0000 Dear authors, I have finished reviewing draft-kompella-mpls-special-purpose-labels-02.txt= as the member of MPLS Review team and have the following comments: * Is the document coherent? Yes. The document describes a problem statement followed by solution propos= als, which is easy to understand.=20 * Is it useful (i.e., is it likely to be actually useful in operational net= works), and is the document technically sound? =20 I believe this document is useful in general. It is good to revisit the usa= ge policy of "reserved labels" and provide a place for discussion. There is= no doubt about the scarcity of reserved labels. But the solutions (includi= ng those proposed on the mailing list) may need more time for discussion. * Is the document ready to be considered for WG adoption? I think the document is ready to be considered for WG adoption. But more di= scussion and input from the group is appreciated, especially for solutions. Thanks! B.R. Jia From jsw@inconcepts.biz Thu Apr 4 00:30: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 0C13F21F95EA for ; Thu, 4 Apr 2013 00:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.479 X-Spam-Level: X-Spam-Status: No, score=0.479 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, RCVD_IN_PBL=0.905, 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 FVM3SWQYzAyf for ; Thu, 4 Apr 2013 00:30:07 -0700 (PDT) Received: from mail-ie0-x22b.google.com (mail-ie0-x22b.google.com [IPv6:2607:f8b0:4001:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 74B7921F95E3 for ; Thu, 4 Apr 2013 00:30:07 -0700 (PDT) Received: by mail-ie0-f171.google.com with SMTP id e14so2707465iej.30 for ; Thu, 04 Apr 2013 00:30:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=uEt+hWtIoXewitMYSV+ATCIXFCY0Ltbs+lcZCaJjEUA=; b=hbysE/FZpGB/7zoWCEzmNfGnhlZzvDlr8tBCBdeua3M7gmVBJJocjSmbFdu1Bm1imT YjYMQ8iAe+npoqbJGD/mYkikA8iDB6JZbHChlOy3d8NGdrkxCeNvGg/2PYnc7EQBb8JI lBtO8v08+xsFdYh3+BcR4S9jFg8zqJl3bUvu36fKq596DklX8ZTtFGNfeU0u/SVEfVoD IePkZz6B0wHX3giyK+C0FemG59VtXw6jIjmUXQvPeoISXkphJ+TJfDkKcTlPS2yy4fAJ tVdwlxn9OZLrLu6fJOGDL1eXiLlMnUELBsffsNMACo4AZ5FV9g0WM9ha+67E5C1YClZS oSzg== MIME-Version: 1.0 X-Received: by 10.50.180.197 with SMTP id dq5mr9193219igc.22.1365060606884; Thu, 04 Apr 2013 00:30:06 -0700 (PDT) Received: by 10.50.85.81 with HTTP; Thu, 4 Apr 2013 00:30:06 -0700 (PDT) X-Originating-IP: [74.134.22.105] In-Reply-To: <515C0840.8080301@pi.nu> References: <201303281411.r2SEBHJk058442@gateway1.orleans.occnc.com> <515BC52E.6020207@pi.nu> <515C0840.8080301@pi.nu> Date: Thu, 4 Apr 2013 03:30:06 -0400 Message-ID: From: Jeff Wheeler To: Loa Andersson Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkejLgyw0ZYBp0Xf+IGy8DKu2MiH/7q81SxHO+3atMz0+aDtyMoeiJSieHBeW8fynGPM0m+ Cc: mpls@ietf.org Subject: Re: [mpls] Relation between the number of special purpose labels and the depth of the label stack - Was:Re: 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: Thu, 04 Apr 2013 07:30:08 -0000 On Wed, Apr 3, 2013 at 6:45 AM, Loa Andersson wrote: > I want to see separate discussions on separate problems. There are only two proposals which create different, related problems. Discussing them separately is only useful to understand what those problems are. I think that's been thoroughly dealt with. Thus, you are left with a choice: which problems are the lesser set of evils? There is no point in handling them separately at this stage. > The way I read some of the mails in this discussion is that if we > increase the number of with one, the label stack will be one label > deeper. > I seriously doubts this, it is potentially not true even in the > were the new special purpose label is present in the label stack. You don't know what future special-purpose labels will be used for. None of us do. If one is needed for something like a future iteration of Entropy Labels, then the cost of forwarding all traffic using that feature will be increased. That means the data-plane needs more power, area, and produces more heat; all of which decrease the useful forwarding density. You should only have a doubt about this if you foresee a system that reserves all the remaining "legacy" special-purpose labels (not needing 15 prefix) for high traffic-bearing features, and allocates the extended ones (requiring 15 prefix) to future features that are unlikely to be included in packets with enough frequency to impact data-plane performance or density. You have not proposed such a system yet. Do you think one is needed? If so, then every "legacy" value handed out now decreases the number available for future high-traffic special purpose labels before the costs get high. This dramatically changes the urgency of this draft. > Do we have any hard figures on the relationship between the number > of available number of special purpose labels and the depth of the > label stack? I do not understand your question. > Same for the number of labels to be processed, do we know which > effect special purpose labels have on how many labels that need to > be processed. Yes, we do know this. If your proposal is adopted, then every packet labeled with an extended special-purpose label must process one additional label. This is obvious. Did I misunderstand your question again? This is a very simple issue. Imagine if the [7] Entropy Label Indicator were, in fact, [15][7]. Then, every packet using Entropy Labels for hashing would have a larger size (uses bandwidth) and would require more NPU time to process, unless the LSR is already beyond its maximum label processing depth, in which case the forwarding behavior might be unspecified because it will not be able to find the Bottom of Stack. I hope you can understand why I am so concerned about this. It is at least *possible* to upgrade control-plane software and implement my suggestion. It is *impossible* to make deployed hardware able to process a deeper label stack than its original design requirement. It is further *impossible* to process a deeper label stack in FUTURE LSRs without additional costs (head/power/area.) That's why I think your proposed solution is, frankly, very foolish. -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts From internet-drafts@ietf.org Thu Apr 4 11:01: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 5CF1621F964A; Thu, 4 Apr 2013 11:01:45 -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 Q3qXMfgiyRhq; Thu, 4 Apr 2013 11:01:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D564B21F963B; Thu, 4 Apr 2013 11:01:44 -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.43 Message-ID: <20130404180144.20095.69039.idtracker@ietfa.amsl.com> Date: Thu, 04 Apr 2013 11:01:44 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-ring-protection-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: Thu, 04 Apr 2013 18:01: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 : Applicability of MPLS-TP Linear Protection for Ring Topo= logies Author(s) : Yaacov Weingarten Stewart Bryant Danielle Ceccarelli Diego Caviglia Francesco Fondelli Marco Corsi Bo Wu Xuehui Dai Filename : draft-ietf-mpls-tp-ring-protection-05.txt Pages : 29 Date : 2013-04-04 Abstract: 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. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-ring-protection There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-ring-protection-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-ring-protection-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From iesg-secretary@ietf.org Thu Apr 4 11:52: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 7DDAB21F8F00; Thu, 4 Apr 2013 11:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.080, 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 4gMyTDcYhSGn; Thu, 4 Apr 2013 11:52:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 08ADB21F8E4C; Thu, 4 Apr 2013 11:52:29 -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.43 Message-ID: <20130404185225.26613.93366.idtracker@ietfa.amsl.com> Date: Thu, 04 Apr 2013 11:52:25 -0700 Cc: mpls@ietf.org Subject: [mpls] Last Call: (Applicability of MPLS-TP Linear Protection for Ring Topologies) to Informational RFC 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: Thu, 04 Apr 2013 18:52:29 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Applicability of MPLS-TP Linear Protection for Ring Topologies' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-04-18. 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 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. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-ring-protection/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-ring-protection/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1872/ From iesg-secretary@ietf.org Thu Apr 4 11:52: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 A8A5021F8F0F for ; Thu, 4 Apr 2013 11:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.52 X-Spam-Level: X-Spam-Status: No, score=-102.52 tagged_above=-999 required=5 tests=[AWL=0.080, 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 9G2fAgb4mpRp; Thu, 4 Apr 2013 11:52:29 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 11C3621F8E7E; Thu, 4 Apr 2013 11:52:29 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IANA X-Test-IDTracker: no X-IETF-IDTracker: 4.43 X-IETF-Draft-string: draft-ietf-mpls-tp-ring-protection X-IETF-Draft-revision: 05 Message-ID: <20130404185229.26613.63724.idtracker@ietfa.amsl.com> Date: Thu, 04 Apr 2013 11:52:29 -0700 Cc: mpls@ietf.org Subject: [mpls] Last Call: (Applicability of MPLS-TP Linear Protection for Ring Topologies) to Informational RFC X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: noreply@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 18:52:29 -0000 The IESG has received a request from the Multiprotocol Label Switching WG (mpls) to consider the following document: - 'Applicability of MPLS-TP Linear Protection for Ring Topologies' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-04-18. 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 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. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-ring-protection/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-ring-protection/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1872/ From yakov@juniper.net Fri Apr 5 06:04: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 841B821F9754 for ; Fri, 5 Apr 2013 06:04:44 -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 02oL+qRapmCQ for ; Fri, 5 Apr 2013 06:04:43 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3194921F9768 for ; Fri, 5 Apr 2013 06:04:40 -0700 (PDT) Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKUV7L55xZj+VkGVxbf2389PS7+Lm1uBkj@postini.com; Fri, 05 Apr 2013 06:04:40 PDT Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 5 Apr 2013 06:02:08 -0700 Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r35D28314861 for ; Fri, 5 Apr 2013 06:02:08 -0700 (PDT) (envelope-from yakov@juniper.net) Message-ID: <201304051302.r35D28314861@magenta.juniper.net> To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2703.1365166928.1@juniper.net> Date: Fri, 5 Apr 2013 06:02:08 -0700 From: Yakov Rekhter Subject: [mpls] IPR Disclosure: Juniper's Statement of IPR related to draft-ietf-mpls-seamless-mcast-06 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, 05 Apr 2013 13:04:44 -0000 Folks, This email is regarding the recent Juniper's Statement of IPR related to draft-ietf-mpls-seamless-mcast-06. Due to an administrative error, the IPR statement was not submitted to the IETF in June 2011 at the time of the publication of version 00 of the draft, and this error is being rectified by the disclosure now. The error happened due to an unfortunate combination of an administrative error along with changes in the affiliation of the primary Juniper author of the original draft-ietf-mpls-seamless-mcast-00, although as an inventor on the patent and an author on the draft, I should have noticed that the disclosure has not been made. I deeply regret this unfortunate error. I would like to apologize on behalf of Juniper, hope that no damage has been done, and want to let you know that the a process is being put in place to avoid such issues in the future. Yakov. From stbryant@cisco.com Fri Apr 5 11:02: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 4CABF21F9865; Fri, 5 Apr 2013 11:02:04 -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 3TUKDNd3Kk5k; Fri, 5 Apr 2013 11:02:03 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5765121F9863; Fri, 5 Apr 2013 11:02:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6479; q=dns/txt; s=iport; t=1365184922; x=1366394522; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=T0DRyczVvExjmGtArYJr+6XEZeIQN42LckVe8xleX9M=; b=JvTvPQm3bH3Kw1WBzui3W8AhAN7kqszQVS/auciawfI24xDcIf/ZIuzo 4hsa1U4qp+ICXzf4VjMgyOYvnvB7/opHiui9UqyUfdn4w0IOdNrRcTOJb iqx30w5j7CvzuPTFNWQIETqQYR8c5I7YF1FfdexX+mByyA2lrG4/A4fFz g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAJcQX1GQ/khN/2dsb2JhbABLgwY2wSWBDRZ0gh8BAQEDAThAARALDgYECRYPCQMCAQIBRQYNAQcBAQWIBQYMwX+PGweDQAOTKINGkQ2DDA X-IronPort-AV: E=Sophos;i="4.87,416,1363132800"; d="scan'208";a="152559307" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 05 Apr 2013 18:01:58 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r35I1us0032606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 5 Apr 2013 18:01:56 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r35I1te6004298; Fri, 5 Apr 2013 19:01:55 +0100 (BST) Message-ID: <515F1193.8070305@cisco.com> Date: Fri, 05 Apr 2013 19:01:55 +0100 From: Stewart Bryant User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Lou Berger References: <5120E158.8080705@labn.net> In-Reply-To: <5120E158.8080705@labn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, mpls@ietf.org, draft-ietf-mpls-tp-ethernet-addressing.all@tools.ietf.org, "rtg-ads@tools.ietf.org" Subject: Re: [mpls] [RTG-DIR] RtgDir review: draft-ietf-mpls-tp-ethernet-addressing-05.txt 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: Fri, 05 Apr 2013 18:02:04 -0000 Lou Thanks for the review. Please see inline. On 17/02/2013 13:55, Lou Berger wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this draft. > The Routing Directorate seeks to review all routing or routing-related > drafts as they pass through IETF last call and IESG review, and > sometimes on special request. The purpose of the review is to provide > assistance to the Routing ADs. For more information about the Routing > Directorate, please see http://www.ietf.org/iesg/directorate/routing.html > > Although these comments are primarily for the use of the Routing ADs, it > would be helpful if you could consider them along with any other IETF > Last Call comments that you receive, and strive to resolve them through > discussion or by updating the draft. > > Document: draft-ietf-mpls-tp-ethernet-addressing-05.txt > Reviewer: Lou Berger > Review Date: 2013-02-17 > IETF LC End Date: 2013-02-18 > Intended Status: Standards Track > > Summary: > > I have some minor concerns about this document that I think should be > resolved before publication. > > Comments: > > This document is pretty straight forward and I don't have any major > issues with it. I found the "MAC address discovery" a bit thinly > defined. This document relies on the mechanisms defined in > draft-ietf-mpls-gach-adv which has just entered last call. > > > Major Issues: > > I think the "MAC address discovery" mechanisms defined in Section 4, > need some additional details in order to ensure independent > interoperable implementations. I don't think any of these issues should > difficult or controversial, but I think they should be blocking. > > I think the following really needs to be covered: > > - The frequency in which the discovery information needs to be (re)sent > & retained. (I think this is simply 1 or 2 sentences that relate back > to Lifetime defined in gach-adv.) I have added The choice of lifetime for the TLV is an operational issue and not an inter-working issue, and thus the operator is free to set the lifetime according to their own preference. There is no requirement for the lifetime to be symmetric. To expedite the initialization of a link it is RECOMMENDED that a node that has been reconfigured, rebooted or is aware that it have been disconnected from its peer send a GAP Ethernet Interface Parameter message, and that it issues a GAP request message for the Ethernet parameters at the earliest opportunity. > > - Some guidance on how address changes should be handled. I have added When the MAC address in the received Source MAC Address TLV changes the new MAC address MUST be used (see Section 5.2 of [I-D.ietf-mpls-gach-adv]. > > - Some guidance on how MTU changes should be handled. I have added If a minimum MTU is configured for a link and the MTU advertised by the peer is lower than that minimum, the link the NMS MUST notified of the event. Under these circumstances the operator may choose to configure the LSR to shut the link and trigger thereby triggereing a fault and causing the end-to-end path to be repaired, or they may choose to leave the link up so that an OAM message can is used to verify the actual MTU. > > - MTU scope needs to be defined. It is completely unclear if MTU is > intended to be the MTU based on the maximum frame size supported by the > sending physical interface represented in the Source MAC Address TLV, or > the MTU supported by the logical (IP) interface associated with the > Source Address TLV. The ability to advertise the latter is IMO the > minimum required, which I assume was the intent of the document, and > just needs to be clarified. Also the basic term should be defined (via > appropriate reference). The MTU definition now says: MTU (type = 1, length = 4): The Value of this object is a 32-bit unsigned integer encoded in network byte order that specifies the maximum transmission unit size in octets of an MPLS label stack plus payload that can be sent over the sending interface. I am unconvinced that a reference is needed, although if you can find one that fits this description I am not averse to including it. However the new definition seems self defining. > > > Minor Issues: > > Section 4: > - since assignment of the mac address is not in this document: > s/01-00-5e-80-00-0d/defined in Section 7 of [mpls-gach-adv] Ref added > > - TLV formats should be provided for the defined TLVs Done > > - "Persistent loss" should be defined in quantitative terms. Also which > GAP messages, all? What about handling of the case where GAP messages > are received, but no MAC address TLVs are included? The degree of loss is a matter for the operator. The latter point is already covered in the text. > > Section 5: > - Earlier in Section 4 you say, "...must behave as configured for this > eventuality.", but such configuration isn't mentioned in section 5. I am beginning to think that manageability consideration sections are more of a liability than they are worth. I would assume that the implementer will read the whole text and provide the required controls without the need to list them in this section. This section is a reminder of text in the GAP protocol document and could if you prefer be deleted. > > - Reporting of MTU mismatch counts and/or details is probably worth > mentioning (and optionally reporting). That is now with the MTU text. > > Section 6: > - I think it would be worth mentioning that Section 5 based Address > Discovery allows the advertised MAC to be different than the MAC frame > source address, and covering related security implications. That would surely be a strange thing to do, but presumably is what the operator intended. I would leave it to the implementation to choose if and how it logged such an event. > > Nits: > > Section 2: > - for clarity, > s/these forms of/broadcast or multicast > in > "not known to be point-to-point, these forms of addressing MUST ..." done. > > One final comment: While I'm sure it's too late to make such a change, I > think including MTU in the [mpls-gach-adv] Source Address TLV (in place > of the reserved field) would have simplified the protocol. -- clearly > this is not a blocking comment or one that really needs to be addressed. It is a bit late, but will discuss with the others. - Stewart From curtis@occnc.com Sun Apr 7 09: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 7419D21F8EC7 for ; Sun, 7 Apr 2013 09:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 fkFXM5zNwk3j for ; Sun, 7 Apr 2013 09:06:31 -0700 (PDT) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id D859121F8EBF for ; Sun, 7 Apr 2013 09:06:30 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r37G5CRd078301; Sun, 7 Apr 2013 12:05:12 -0400 (EDT) (envelope-from curtis@occnc.com) Message-Id: <201304071605.r37G5CRd078301@gateway1.orleans.occnc.com> To: Loa Andersson From: Curtis Villamizar In-reply-to: Your message of "Mon, 01 Apr 2013 13:23:32 +0200." <51596E34.4020408@pi.nu> Date: Sun, 07 Apr 2013 12:05:12 -0400 Cc: "mpls@ietf.org" , "draft-villamizar-mpls-forwarding@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus to make draft-villamizar-mpls-forwarding an MPLS wg document X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 16:06:31 -0000 Loa, support (as co-author) motivation: It is helpful to chip vendors and system vendors to have one place to look to find references at least most of the MPLS forwarding requirements. Curtis In message <51596E34.4020408@pi.nu> Loa Andersson writes: Working Group, This is to start a two week poll on adopting draft-villamizar-mpls-forwarding-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 April 15, 2013. There are no IPR claim against this document. 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 ping@pingpan.org Sun Apr 7 09:09: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 C524421F8536 for ; Sun, 7 Apr 2013 09:09:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.976 X-Spam-Level: X-Spam-Status: No, score=-5.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 YfCog-MA4kuY for ; Sun, 7 Apr 2013 09:09:04 -0700 (PDT) Received: from exprod7og125.obsmtp.com (exprod7og125.obsmtp.com [64.18.2.28]) by ietfa.amsl.com (Postfix) with SMTP id E4DF021F8533 for ; Sun, 7 Apr 2013 09:09:03 -0700 (PDT) Received: from mail-gh0-f199.google.com ([209.85.160.199]) (using TLSv1) by exprod7ob125.postini.com ([64.18.6.12]) with SMTP ID DSNKUWGaH4JUwRh0F4/TOYgFl7CclROzIICB@postini.com; Sun, 07 Apr 2013 09:09:04 PDT Received: by mail-gh0-f199.google.com with SMTP id r16so7152207ghr.2 for ; Sun, 07 Apr 2013 09:09:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:x-received:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=/TYUSzUx9aMsJgTqbz9K/788gB6J4VJEyZDkfsUL03Y=; b=A3alvq1zGDPa6P8EK9mcc7tuIBjBEDshP3TecsSl5oMitxQfKliHyCZrfw5M+6oTEU Zn+/Ey/oGQWK/zQjXj9QcyBUuMg++vSuGbF3xJ0w8d72TMYn/1JfuaSgTpmLj/mJnfru XeO/xY2oW+Ekt0RSj185yNxwPjsazuhluG6DCZAf44/yVFWrcBZqBgeVS8paHL9w4/y2 Kpr6tEex3o06ECohg6482POXFVD7qwFFxJYWB74bSpvl+vEmkUMQ2X7gfHmDYGX86EYF 4P412nMVZXqMcMx4lrg3m0ewRsMIaGFbmOvWFYpfzk/zcfhWlWcKz7L1iEjWncQ1yeXh 4apw== X-Received: by 10.52.28.101 with SMTP id a5mr11400724vdh.92.1365350943108; Sun, 07 Apr 2013 09:09:03 -0700 (PDT) X-Received: by 10.52.28.101 with SMTP id a5mr11400718vdh.92.1365350942986; Sun, 07 Apr 2013 09:09:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.30.7 with HTTP; Sun, 7 Apr 2013 09:08:22 -0700 (PDT) In-Reply-To: <201304071605.r37G5CRd078301@gateway1.orleans.occnc.com> References: <51596E34.4020408@pi.nu> <201304071605.r37G5CRd078301@gateway1.orleans.occnc.com> From: Ping Pan Date: Sun, 7 Apr 2013 09:08:22 -0700 Message-ID: To: Curtis Villamizar Content-Type: multipart/alternative; boundary=20cf307d064ef36f9204d9c7891d X-Gm-Message-State: ALoCoQnmslqUOfb8e9e3KeGuAyTnc357k84pdTGSiVLxy/t73x177HdRxfoc6+SdTJMRImioTQRWXVTkjCUhh0KVXPjpa4PEeMmA9ftx9WxyjVpHr7LsiUE0vricyduqip1DTaTMMEvQR/54RAcXaXbZizRiR3ASYA== Cc: "mpls@ietf.org" , "draft-villamizar-mpls-forwarding@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , Loa Andersson Subject: Re: [mpls] poll to see if we have consensus to make draft-villamizar-mpls-forwarding 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: Sun, 07 Apr 2013 16:09:07 -0000 --20cf307d064ef36f9204d9c7891d Content-Type: text/plain; charset=UTF-8 +1 On Sun, Apr 7, 2013 at 9:05 AM, Curtis Villamizar wrote: > > Loa, > > support > > (as co-author) > > motivation: It is helpful to chip vendors and system vendors to have > one place to look to find references at least most of the MPLS > forwarding requirements. > > Curtis > > > In message <51596E34.4020408@pi.nu> > Loa Andersson writes: > > Working Group, > > This is to start a two week poll on adopting > draft-villamizar-mpls-forwarding-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 April 15, 2013. > > There are no IPR claim against this document. > > 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 > --20cf307d064ef36f9204d9c7891d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1


On Sun, Apr 7, 2013 at 9:05 AM, Curtis Villamizar <curtis@occnc= .com> wrote:

Loa,

support

(as co-author)

motivation: =C2=A0It is helpful to chip vendors and system vendors to have<= br> one place to look to find references at least most of the MPLS
forwarding requirements.

Curtis


In message <51596E34.4020408@p= i.nu>
Loa Andersson writes:

Working Group,

This is to start a two week poll on adopting
draft-villamizar-mpls-forwarding-02 as an MPLS working
group document.

Please send your comments (support/not support) to the mpls working
group mailing list (mpls at i= etf.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 April 15, 2013.

There are no IPR claim against this document.

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 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

--20cf307d064ef36f9204d9c7891d-- From internet-drafts@ietf.org Mon Apr 8 04:09: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 843EF21F93A9; Mon, 8 Apr 2013 04:09:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.115, 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 OjNt3i1CBT0Q; Mon, 8 Apr 2013 04:09:37 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 27EF921F8FD5; Mon, 8 Apr 2013 04:09:37 -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.43.p3 Message-ID: <20130408110937.8559.94540.idtracker@ietfa.amsl.com> Date: Mon, 08 Apr 2013 04:09:37 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-ethernet-addressing-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, 08 Apr 2013 11:09: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 : MPLS-TP Next-Hop Ethernet Addressing Author(s) : Dan Frost Stewart Bryant Matthew Bocci Filename : draft-ietf-mpls-tp-ethernet-addressing-06.txt Pages : 9 Date : 2013-04-08 Abstract: The Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet-switched transport networks. This document presents considerations for link-layer addressing of Ethernet frames carrying MPLS-TP packets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-ethernet-addressing There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-ethernet-addressing-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-ethernet-addressing-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Apr 8 10:19: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 EC3F621F904B; Mon, 8 Apr 2013 10:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.475 X-Spam-Level: X-Spam-Status: No, score=-102.475 tagged_above=-999 required=5 tests=[AWL=0.125, 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 Pkft9VWdNGhu; Mon, 8 Apr 2013 10:19:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B0F21F8FC7; Mon, 8 Apr 2013 10:19:34 -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.43.p3 Message-ID: <20130408171934.22393.99266.idtracker@ietfa.amsl.com> Date: Mon, 08 Apr 2013 10:19:34 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-p2mp-framework-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: Mon, 08 Apr 2013 17:19:35 -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 : A Framework for Point-to-Multipoint MPLS in Transport Ne= tworks Author(s) : Dan Frost Stewart Bryant Matthew Bocci Lou Berger Filename : draft-ietf-mpls-tp-p2mp-framework-01.txt Pages : 11 Date : 2013-04-08 Abstract: The Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP) is the common set of MPLS protocol functions defined to enable the construction and operation of packet transport networks. The MPLS-TP supports both point-to-point and point-to-multipoint transport paths. This document defines the elements and functions of the MPLS-TP architecture applicable specifically to supporting point-to- multipoint transport paths. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functions of a packet transport network. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-p2mp-framework There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-p2mp-framework-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-p2mp-framework-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Apr 8 11:13: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 C710821F8266; Mon, 8 Apr 2013 11:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=0.116, 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 Pq8S14MsZXFj; Mon, 8 Apr 2013 11:13:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0697821F8265; Mon, 8 Apr 2013 11:13:57 -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.43.p3 Message-ID: <20130408181352.24388.57450.idtracker@ietfa.amsl.com> Date: Mon, 08 Apr 2013 11:13:52 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-ethernet-addressing-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, 08 Apr 2013 18:13:58 -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 Next-Hop Ethernet Addressing Author(s) : Dan Frost Stewart Bryant Matthew Bocci Filename : draft-ietf-mpls-tp-ethernet-addressing-07.txt Pages : 9 Date : 2013-04-08 Abstract: The Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet-switched transport networks. This document presents considerations for link-layer addressing of Ethernet frames carrying MPLS-TP packets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-ethernet-addressing There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-ethernet-addressing-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-ethernet-addressing-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From scott.mansfield@ericsson.com Mon Apr 8 22:43: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 3BDE921F8B49; Mon, 8 Apr 2013 22:43:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.099, 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 VhaQsScqWfh0; Mon, 8 Apr 2013 22:43:05 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 1D31521F8B25; Mon, 8 Apr 2013 22:43:05 -0700 (PDT) X-AuditID: c6180641-b7faf6d00000096b-1c-5163aa684908 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id C4.8B.02411.86AA3615; Tue, 9 Apr 2013 07:43:04 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.004; Tue, 9 Apr 2013 01:43:03 -0400 From: Scott Mansfield To: "mpls@ietf.org" Thread-Topic: MPLS related liaison from ITU-T SG15 Thread-Index: Ac405Rmb3zdg4nn9RKG+pm3W94QHWg== Date: Tue, 9 Apr 2013 05:43:02 +0000 Message-ID: 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_EF35EE4B92789843B1DECBC0E24558642195EDeusaamb105ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsUyuXRPuG7GquRAg6vL5S2ezLnBYnFr6UpW i75PW1gcmD2WLPnJFMAYxWWTkpqTWZZapG+XwJWxavVHloKPEhX79y1jamDsEuti5OSQEDCR +Lmwix3CFpO4cG89WxcjF4eQwFFGieczd7JDOMsYJW7fe88MUsUG1LF113RGEFtEQFniyMRu VhCbWcBN4svj/0ANHBzCAroSrXfYIUqMJPZfW8EGYetJnFl1hQnEZhFQkdjT2gHWyivgLXH+ 3DmwOCPQEd9PrWGCGCkucevJfCaI4wQkluw5zwxhi0q8fPyPFcJWlvg+5xELRH2+xNsDe6Bm CkqcnPmEZQKj8Cwko2YhKZuFpAwiriOxYPcnNghbW2LZwtfMMPaZA4+ZkMUXMLKvYuQoLU4t y003MtzECIySYxJsjjsYF3yyPMQozcGiJM4b6nohQEggPbEkNTs1tSC1KL6oNCe1+BAjEwen VAOjGtdikXM268X0NT/P3/xzn6/q/Cc5L3hWTtv7Ykl/3Qc395jS9yefPwrI8HhsKZhx/Mvk ohds5zrrH6smzvPPXNHob+vDHr1kfobjfS9/42u7Hra9ehNTzb1k3rSfRonXMg0E7QoezS74 enGxMvcl+XNct8XjBBLL2B9yHpaRPsl2gsl66uQzSizFGYmGWsxFxYkAtGclxWACAAA= Cc: "ccamp@ietf.org" , "pwe3@ietf.org" Subject: [mpls] MPLS related liaison from ITU-T SG15 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, 09 Apr 2013 05:43:06 -0000 --_000_EF35EE4B92789843B1DECBC0E24558642195EDeusaamb105ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Please see the informational liaison http://datatracker.ietf.org/liaison/12= 49/ from the ITU-T SG15. The liaison provides a list of the new and revised MPLS-TP related document= s that will enter the approval process at the next SG15 plenary meeting (1-= 15 July 2013). Regards, -scott. Scott Mansfield Ericsson Inc. +1 724 931 9316 --_000_EF35EE4B92789843B1DECBC0E24558642195EDeusaamb105ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Please see the informational liaison http://datatracker.ietf.org/liaison/1249/ from the ITU-T SG15.

The liaison provides a list of the new and revised M= PLS-TP related documents that will enter the approval process at the next S= G15 plenary meeting (1-15 July 2013).

 

Regards,

-scott.

 

Scott Mansfield

Ericsson Inc.

+1 724 931 9316

 

--_000_EF35EE4B92789843B1DECBC0E24558642195EDeusaamb105ericsso_-- From stbryant@cisco.com Tue Apr 9 00:23: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 7FB8C21F905A; Tue, 9 Apr 2013 00:23:28 -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=[AWL=-0.000, 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 jMOJvsdyt-CV; Tue, 9 Apr 2013 00:23:27 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 188AC21F9184; Tue, 9 Apr 2013 00:23:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4228; q=dns/txt; s=iport; t=1365492201; x=1366701801; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=MRxN+5O822QUVAplYSQ6kr6A21D+WUNm3c3M/NLGBfg=; b=MtjCSzbmC6oHPhBS+7n6oDmN/n8b/CWiDqKPp5IbcGB9XLax4aRE6nDh 4sG0DKFCcri8BJ3kKaNlaF8VvKEEDY1F4Oybn+GakfgGEjxzoOYRqqHSX QSBLsRYXSMb3Wq+FnK8TXP89ZlMwVTNrsbyKd/Vqeh84xzgE+vJSmYhfk c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAP3AY1GQ/khR/2dsb2JhbABOA4JCRDaJCbg3gREWdIIfAQEBBAEBASpBCgEQCxgJFg8JAwIBAgEVMAYNAQUCAQGIEAytVpAviQqGCBAHEYMwA5Z0gSGPbIMM X-IronPort-AV: E=Sophos;i="4.87,436,1363132800"; d="scan'208,217";a="81852224" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 09 Apr 2013 07:23:14 +0000 Received: from cisco.com (mrwint.cisco.com [64.103.70.36]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r397NCAM014048 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Apr 2013 07:23:12 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r397NB4a004176; Tue, 9 Apr 2013 08:23:11 +0100 (BST) Message-ID: <5163C1DF.1080006@cisco.com> Date: Tue, 09 Apr 2013 08:23:11 +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: Scott Mansfield References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------020106090003050807050009" Cc: "mpls@ietf.org" , "ccamp@ietf.org" , "pwe3@ietf.org" Subject: Re: [mpls] MPLS related liaison from ITU-T SG15 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, 09 Apr 2013 07:23:29 -0000 This is a multi-part message in MIME format. --------------020106090003050807050009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 09/04/2013 06:43, Scott Mansfield wrote: > > Please see the informational liaison > http://datatracker.ietf.org/liaison/1249/ > from the ITU-T SG15. > > The liaison provides a list of the new and revised MPLS-TP related > documents that will enter the approval process at the next SG15 > plenary meeting (1-15 July 2013). > > Regards, > > -scott. > > Scott Mansfield > > Ericsson Inc. > > +1 724 931 9316 > > > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls Scott, I see a list of document names, but no document text to review. Stewart --------------020106090003050807050009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 09/04/2013 06:43, Scott Mansfield wrote:

 

Please see the informational liaison http://datatracker.ietf.org/liaison/1249/ from the ITU-T SG15.

The liaison provides a list of the new and revised MPLS-TP related documents that will enter the approval process at the next SG15 plenary meeting (1-15 July 2013).

 

Regards,

-scott.

 

Scott Mansfield

Ericsson Inc.

+1 724 931 9316

 



_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
Scott, I see a list of document names, but no document text to review.

Stewart
--------------020106090003050807050009-- From scott.mansfield@ericsson.com Tue Apr 9 01:37: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 4F58C21F8F24; Tue, 9 Apr 2013 01:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, 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 PSrbSI8k62Gu; Tue, 9 Apr 2013 01:37:47 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4D821F88BF; Tue, 9 Apr 2013 01:37:47 -0700 (PDT) X-AuditID: c618062d-b7f0d6d00000097e-b2-5163d35a5227 Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 7E.47.02430.A53D3615; Tue, 9 Apr 2013 10:37:46 +0200 (CEST) Received: from EUSAAMB105.ericsson.se ([147.117.188.122]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.02.0318.004; Tue, 9 Apr 2013 04:37:45 -0400 From: Scott Mansfield To: "stbryant@cisco.com" Thread-Topic: [mpls] MPLS related liaison from ITU-T SG15 Thread-Index: Ac405Rmb3zdg4nn9RKG+pm3W94QHWgAL4SWAAAYB3xA= Date: Tue, 9 Apr 2013 08:37:44 +0000 Message-ID: References: <5163C1DF.1080006@cisco.com> In-Reply-To: <5163C1DF.1080006@cisco.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_EF35EE4B92789843B1DECBC0E2455864219FE2eusaamb105ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyuXRPuG7U5eRAg5M/ZS2ezLnBYnFr6UpW i75PW1gszj2dw+jA4jHl90ZWjyVLfjIFMEVx2aSk5mSWpRbp2yVwZSzYdZC9oMe6YuW6/awN jOeNuxg5OCQETCR2LM3uYuQEMsUkLtxbz9bFyMUhJHCUUeLs5Z+sIAkhgWWMEgs/m4PYbED1 W3dNZwSxRQR0JWZvuAFmMwtkSqw6fIcNxBYWsJCY+WoyE0SNpcThFfOYIWwriebHT8HiLAIq Ek+u/mABsXkFvCUOHdnHDLErS2LBvedsILdxCmhK7LhsCxJmBLrt+6k1TBCrxCVuPZnPBHGz gMSSPeeZIWxRiZeP/7FC2MoS3+c8YoGoz5eYufwtM8QqQYmTM5+wTGAUnYVk1CwkZbOQlEHE dSQW7P7EBmFrSyxb+JoZxj5z4DETsvgCRvZVjBylxalluelGBpsYgVF2TIJNdwfjnpeWhxil OViUxHmDXC8ECAmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamDsMOzvSi62e9nH1ya49sfhLf3z X9UYvV37qDzd587J2MjMKU627+8UxPEZFEz8aM97MWKPmHL2gY/xn87OSVNbHC+4knVO2AIx 9YTML3+X+Gcyhy2dqxjj/iibuyDqcXjaG53Fy1RqTpyffUqh/YPatuNzY6zUN1z9oF76QcLo T1Tl/ursdRZKLMUZiYZazEXFiQDYg4HAgAIAAA== Cc: "mpls@ietf.org" , "ccamp@ietf.org" , "pwe3@ietf.org" Subject: Re: [mpls] MPLS related liaison from ITU-T SG15 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, 09 Apr 2013 08:37:48 -0000 --_000_EF35EE4B92789843B1DECBC0E2455864219FE2eusaamb105ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The liaison is simply listing the documents that will be considered at the = meeting. The text will be available about 1 month before the meeting. The= text was not liaised, as the liaison states, the normal ITU-T process will= be used. Which means that only members of the ITU will have access to the= text and have the ability to comment. We can try asking for access for no= n-ITU-T members if there is interest in reviewing the documents. We can ex= ercise section 2.4 of RFC 6756 for those that are not ITU-T members, but th= is will have to be done on a case-by-case basis. Regards, -scott. From: Stewart Bryant [mailto:stbryant@cisco.com] Sent: Tuesday, April 09, 2013 3:23 AM To: Scott Mansfield Cc: mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org Subject: Re: [mpls] MPLS related liaison from ITU-T SG15 On 09/04/2013 06:43, Scott Mansfield wrote: Please see the informational liaison http://datatracker.ietf.org/liaison/12= 49/ from the ITU-T SG15. The liaison provides a list of the new and revised MPLS-TP related document= s that will enter the approval process at the next SG15 plenary meeting (1-= 15 July 2013). Regards, -scott. Scott Mansfield Ericsson Inc. +1 724 931 9316 _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls Scott, I see a list of document names, but no document text to review. Stewart --_000_EF35EE4B92789843B1DECBC0E2455864219FE2eusaamb105ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The liaison is simply = listing the documents that will be considered at the meeting.  The tex= t will be available about 1 month before the meeting.  The text was no= t liaised, as the liaison states, the normal ITU-T process will be used.  Which means that only members of the ITU will = have access to the text and have the ability to comment.  We can try a= sking for access for non-ITU-T members if there is interest in reviewing th= e documents.  We can exercise section 2.4 of RFC 6756 for those that are not ITU-T members, but this will have to be= done on a case-by-case basis.

 

Regards,

-scott.

 

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Tuesday, April 09, 2013 3:23 AM
To: Scott Mansfield
Cc: mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org
Subject: Re: [mpls] MPLS related liaison from ITU-T SG15<= /span>

 

On 09/04/2013 06:43, Scott Mansfield wrote:

 

Please see the informational liaison http://datatracker.ietf.org/liaison/1249/ from the ITU-T SG15.

The liaison provides a list of the new and revised M= PLS-TP related documents that will enter the approval process at the next S= G15 plenary meeting (1-15 July 2013).

 

Regards,

-scott.

 

Scott Mansfield

Ericsson Inc.

+1 724 931 9316

 




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

Scott, I see a list of document name= s, but no document text to review.

Stewart

--_000_EF35EE4B92789843B1DECBC0E2455864219FE2eusaamb105ericsso_-- From stbryant@cisco.com Tue Apr 9 02:34: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 43D6E21F91B7; Tue, 9 Apr 2013 02:34:30 -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=[AWL=-0.000, 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 dI2x4XcPa019; Tue, 9 Apr 2013 02:34:29 -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 6923621F913C; Tue, 9 Apr 2013 02:34:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10177; q=dns/txt; s=iport; t=1365500068; x=1366709668; h=message-id:date:from:reply-to:mime-version:to:cc:subject: references:in-reply-to; bh=8aMBvqdgZ2tknEB9/WnaoEdaUkvDh1PW7ZAszJ37AO4=; b=DHfHisrERuDTPUpuF0R3/gkSBuwgV9hJCwHtYHkAuW4mj2Oaj3e1Et7y 8R3mMRsvM6vfYpvPfz14VLh5dC7XiBoQPmvLOIteznGQMxzupPQvaUS0Z ztjA78NkdZ/eNYWtqZbzEXLWY1mVsVxcLCbvKs+5QfdZd2ditMcRgqiOi c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAHzfY1GQ/khM/2dsb2JhbABOA4JCRDaJCbg3gRIWdIIfAQEBBAEBASpBCgEQCxEEAQEBCRYIBwkDAgECARUfCQgGDQEFAgEBiBAMrgOQPYkKhggFCwYBEYMwA5Z0gSGPbIMM X-IronPort-AV: E=Sophos;i="4.87,437,1363132800"; d="scan'208,217";a="13203158" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-4.cisco.com with ESMTP; 09 Apr 2013 09:34:27 +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 r399YPk4005455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 9 Apr 2013 09:34:25 GMT Received: from [IPv6:::1] (localhost [127.0.0.1]) by cisco.com (8.14.4+Sun/8.8.8) with ESMTP id r399YNSC010508; Tue, 9 Apr 2013 10:34:24 +0100 (BST) Message-ID: <5163E09F.4060105@cisco.com> Date: Tue, 09 Apr 2013 10:34:23 +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: Scott Mansfield References: <5163C1DF.1080006@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------000907090609060609030206" Cc: "mpls@ietf.org" , "ccamp@ietf.org" , "pwe3@ietf.org" Subject: Re: [mpls] MPLS related liaison from ITU-T SG15 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, 09 Apr 2013 09:34:30 -0000 This is a multi-part message in MIME format. --------------000907090609060609030206 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit So I believe the correct response is: Thank you for your liaison. Please can you make the text of these documents available to the IETF in sufficient time that members of the IETF who are not also members of the ITU can pass any review comments that they have to IETF colleagues who are members of the ITU for possible incorporation into their own review comments. - Stewart On 09/04/2013 09:37, Scott Mansfield wrote: > > The liaison is simply listing the documents that will be considered at > the meeting. The text will be available about 1 month before the > meeting. The text was not liaised, as the liaison states, the normal > ITU-T process will be used. Which means that only members of the ITU > will have access to the text and have the ability to comment. We can > try asking for access for non-ITU-T members if there is interest in > reviewing the documents. We can exercise section 2.4 of RFC 6756 for > those that are not ITU-T members, but this will have to be done on a > case-by-case basis. > > Regards, > > -scott. > > *From:*Stewart Bryant [mailto:stbryant@cisco.com] > *Sent:* Tuesday, April 09, 2013 3:23 AM > *To:* Scott Mansfield > *Cc:* mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org > *Subject:* Re: [mpls] MPLS related liaison from ITU-T SG15 > > On 09/04/2013 06:43, Scott Mansfield wrote: > > Please see the informational liaison > http://datatracker.ietf.org/liaison/1249/ > from the ITU-T SG15. > > The liaison provides a list of the new and revised MPLS-TP related > documents that will enter the approval process at the next SG15 > plenary meeting (1-15 July 2013). > > Regards, > > -scott. > > Scott Mansfield > > Ericsson Inc. > > +1 724 931 9316 > > > > > _______________________________________________ > > mpls mailing list > > mpls@ietf.org > > https://www.ietf.org/mailman/listinfo/mpls > > Scott, I see a list of document names, but no document text to review. > > Stewart > -- For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html --------------000907090609060609030206 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
So I believe the correct response is:

Thank you for your liaison.

Please can you make the text of these documents available to the IETF in sufficient time that members of the IETF who are not also members of the ITU can pass any review comments that they have to IETF colleagues who are members of the ITU for possible incorporation into their own review comments.

- Stewart



On 09/04/2013 09:37, Scott Mansfield wrote:

The liaison is simply listing the documents that will be considered at the meeting.  The text will be available about 1 month before the meeting.  The text was not liaised, as the liaison states, the normal ITU-T process will be used.  Which means that only members of the ITU will have access to the text and have the ability to comment.  We can try asking for access for non-ITU-T members if there is interest in reviewing the documents.  We can exercise section 2.4 of RFC 6756 for those that are not ITU-T members, but this will have to be done on a case-by-case basis.

 

Regards,

-scott.

 

From: Stewart Bryant [mailto:stbryant@cisco.com]
Sent: Tuesday, April 09, 2013 3:23 AM
To: Scott Mansfield
Cc: mpls@ietf.org; ccamp@ietf.org; pwe3@ietf.org
Subject: Re: [mpls] MPLS related liaison from ITU-T SG15

 

On 09/04/2013 06:43, Scott Mansfield wrote:

 

Please see the informational liaison http://datatracker.ietf.org/liaison/1249/ from the ITU-T SG15.

The liaison provides a list of the new and revised MPLS-TP related documents that will enter the approval process at the next SG15 plenary meeting (1-15 July 2013).

 

Regards,

-scott.

 

Scott Mansfield

Ericsson Inc.

+1 724 931 9316

 




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

Scott, I see a list of document names, but no document text to review.

Stewart



-- 
For corporate legal information go to:

http://www.cisco.com/web/about/doing_business/legal/cri/index.html
--------------000907090609060609030206-- From rcallon@juniper.net Tue Apr 9 08:13: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 14FED21F9371 for ; Tue, 9 Apr 2013 08:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.674 X-Spam-Level: X-Spam-Status: No, score=-100.674 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, 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 qA8WrUL5TcXz for ; Tue, 9 Apr 2013 08:13:03 -0700 (PDT) Received: from exprod7og112.obsmtp.com (exprod7og112.obsmtp.com [64.18.2.177]) by ietfa.amsl.com (Postfix) with ESMTP id 6A1FB21F905C for ; Tue, 9 Apr 2013 08:13:03 -0700 (PDT) Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP ID DSNKUWQv/1tffzmBscvyR5zDTV3N1xXT1z3i@postini.com; Tue, 09 Apr 2013 08:13:03 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; Tue, 9 Apr 2013 08:10:39 -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; Tue, 9 Apr 2013 08:10:38 -0700 Received: from db3outboundpool.messaging.microsoft.com (213.199.154.144) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 9 Apr 2013 08:20:37 -0700 Received: from mail20-db3-R.bigfish.com (10.3.81.241) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.23; Tue, 9 Apr 2013 15:10:36 +0000 Received: from mail20-db3 (localhost [127.0.0.1]) by mail20-db3-R.bigfish.com (Postfix) with ESMTP id 40CBC1602C3 for ; Tue, 9 Apr 2013 15:10:36 +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: -1 X-BigFish: PS-1(zzc85fh4015Izz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz18c673hz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1155h) Received: from mail20-db3 (localhost.localdomain [127.0.0.1]) by mail20-db3 (MessageSwitch) id 1365520233589846_14595; Tue, 9 Apr 2013 15:10:33 +0000 (UTC) Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.251]) by mail20-db3.bigfish.com (Postfix) with ESMTP id 8609A4A0049; Tue, 9 Apr 2013 15:10:33 +0000 (UTC) Received: from CH1PRD0510HT002.namprd05.prod.outlook.com (157.56.244.213) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 9 Apr 2013 15:10:24 +0000 Received: from CH1PRD0510MB355.namprd05.prod.outlook.com ([169.254.2.10]) by CH1PRD0510HT002.namprd05.prod.outlook.com ([10.255.150.37]) with mapi id 14.16.0287.008; Tue, 9 Apr 2013 15:10:20 +0000 From: Ross Callon To: Kireeti Kompella , Loa Andersson , Adrian Farrel , "mpls@ietf.org" Thread-Topic: IPR poll on draft-kompella-mpls-special-purpose-labels Thread-Index: Ac41NFk+7S9hSU5uQhqMaALzMPBDPw== Date: Tue, 9 Apr 2013 15:10:20 +0000 Message-ID: <62CCD4C52ACDAD4481149BD5D8A72FD316BABC49@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_62CCD4C52ACDAD4481149BD5D8A72FD316BABC49CH1PRD0510MB355_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%PI.NU$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net 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: [mpls] IPR poll on draft-kompella-mpls-special-purpose-labels 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, 09 Apr 2013 15:13:04 -0000 --_000_62CCD4C52ACDAD4481149BD5D8A72FD316BABC49CH1PRD0510MB355_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Working Group and authors; The authors of draft-kompella-mpls-special-purpose-labels have indicated that the draft is ready to be adopted as a working group document. Before starting the poll to see if there is wg consensus to make the draft a working group document we will do an IPR poll 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-kompella-mpls-special-purpos= e-labels? 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) --_000_62CCD4C52ACDAD4481149BD5D8A72FD316BABC49CH1PRD0510MB355_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Working Group and authors;
 
The authors of draft-kompella-mpls-special-purpose-labels have indicat= ed
that the draft is ready to be adopted as a working group document.
 
Before starting the poll to see if there is wg consensus to make the
draft a working group document we will do an IPR poll 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-kompella-mpls-special-p= urpose-labels?
 
If so, has this IPR been disclosed in compliance with IETF IPR  r= ules
(see RFCs 3979, 4879, 3669 and 5378 for more details).
 
If you are listed as a document author or contributor please respond t= o
this email regardless of whether or not you are aware of any relevant<= /div>
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 o= r
contributor, then please explicitly respond only if you are aware of a= ny
IPR that has not yet been disclosed in conformance with IETF rules.
 
 
Thanks, Ross
(as = MPLS WG co-chair)
&nbs= p;
 --_000_62CCD4C52ACDAD4481149BD5D8A72FD316BABC49CH1PRD0510MB355_-- From loa@pi.nu Tue Apr 9 08:46: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 07EEF21F919D for ; Tue, 9 Apr 2013 08:46:42 -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 jH9CZOdot-hs for ; Tue, 9 Apr 2013 08:46:41 -0700 (PDT) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 59B1A21F8E7A for ; Tue, 9 Apr 2013 08:46:41 -0700 (PDT) Received: from [10.5.7.46] (unknown [202.106.79.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id 7C0277FE07; Tue, 9 Apr 2013 17:46:35 +0200 (CEST) Message-ID: <516437D8.7030005@pi.nu> Date: Tue, 09 Apr 2013 17:46:32 +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: <62CCD4C52ACDAD4481149BD5D8A72FD316BABC49@CH1PRD0510MB355.namprd05.prod.outlook.com> In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316BABC49@CH1PRD0510MB355.namprd05.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Kireeti Kompella , "mpls@ietf.org" Subject: Re: [mpls] IPR poll on draft-kompella-mpls-special-purpose-labels 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, 09 Apr 2013 15:46:42 -0000 WG, I'm not aware of any IPR on this draft. /Loa On 2013-04-09 17:10, Ross Callon wrote: > Working Group and authors; > The authors of draft-kompella-mpls-special-purpose-labels have indicated > that the draft is ready to be adopted as a working group document. > Before starting the poll to see if there is wg consensus to make the > draft a working group document we will do an IPR poll 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-kompella-mpls-special-purpose-labels? > 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 adrian@olddog.co.uk Tue Apr 9 08:48: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 3F5CD21F937E for ; Tue, 9 Apr 2013 08:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.299, 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 dh6w0JjD9Y48 for ; Tue, 9 Apr 2013 08:48:38 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id C31DB21F97AC for ; Tue, 9 Apr 2013 08:48:37 -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 r39FmZ3p004555; Tue, 9 Apr 2013 16:48:36 +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 r39FmYrn004540 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 9 Apr 2013 16:48:35 +0100 From: "Adrian Farrel" To: "'Ross Callon'" , "'Kireeti Kompella'" , "'Loa Andersson'" , References: <62CCD4C52ACDAD4481149BD5D8A72FD316BABC49@CH1PRD0510MB355.namprd05.prod.outlook.com> In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316BABC49@CH1PRD0510MB355.namprd05.prod.outlook.com> Date: Tue, 9 Apr 2013 16:48:33 +0100 Message-ID: <016701ce3539$b15615e0$140241a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0168_01CE3542.131EEAB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGCfCvRJ289FWn8v/F7rWRkRde2NplleuVA Content-Language: en-gb Subject: Re: [mpls] IPR poll on draft-kompella-mpls-special-purpose-labels 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, 09 Apr 2013 15:48:39 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0168_01CE3542.131EEAB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I am not aware of any IPR relating to the content of this draft. Adrian From: Ross Callon [mailto:rcallon@juniper.net] Sent: 09 April 2013 16:10 To: Kireeti Kompella; Loa Andersson; Adrian Farrel; mpls@ietf.org Subject: IPR poll on draft-kompella-mpls-special-purpose-labels Working Group and authors; The authors of draft-kompella-mpls-special-purpose-labels have indicated that the draft is ready to be adopted as a working group document. Before starting the poll to see if there is wg consensus to make the draft a working group document we will do an IPR poll 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-kompella-mpls-special-purpose-labels? 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) ------=_NextPart_000_0168_01CE3542.131EEAB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am not aware of any IPR = relating to the content of this draft.

 

Adrian

 

From: Ross Callon = [mailto:rcallon@juniper.net]
Sent: 09 April 2013 = 16:10
To: Kireeti Kompella; Loa Andersson; Adrian Farrel; = mpls@ietf.org
Subject: IPR poll on = draft-kompella-mpls-special-purpose-labels

 

Working Group and = authors;

 

The authors of = draft-kompella-mpls-special-purpose-labels have = indicated

that the draft is ready to be adopted as a working = group document.

 

Before starting the poll to see if there is wg = consensus to make the

draft a working group document we will do an IPR poll = 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-kompella-mpls-special-purpose-labels?

 

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)

 

------=_NextPart_000_0168_01CE3542.131EEAB0-- From kireeti@juniper.net Tue Apr 9 08:55: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 59E5521F936C for ; Tue, 9 Apr 2013 08:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.466 X-Spam-Level: X-Spam-Status: No, score=-3.466 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 4N4pdNfKdYQ5 for ; Tue, 9 Apr 2013 08:55:11 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by ietfa.amsl.com (Postfix) with ESMTP id 4A57521F9389 for ; Tue, 9 Apr 2013 08:55:11 -0700 (PDT) Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKUWQ53wwxbShQD2HpX+E4GYBWpMhLWlQT@postini.com; Tue, 09 Apr 2013 08:55:11 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; Tue, 9 Apr 2013 08:41:50 -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; Tue, 9 Apr 2013 08:41:50 -0700 Received: from tx2outboundpool.messaging.microsoft.com (65.55.88.13) by o365mail.juniper.net (207.17.137.224) with Microsoft SMTP Server (TLS) id 14.1.355.2; Tue, 9 Apr 2013 08:51:49 -0700 Received: from mail108-tx2-R.bigfish.com (10.9.14.240) by TX2EHSOBE006.bigfish.com (10.9.40.26) with Microsoft SMTP Server id 14.1.225.23; Tue, 9 Apr 2013 15:41:49 +0000 Received: from mail108-tx2 (localhost [127.0.0.1]) by mail108-tx2-R.bigfish.com (Postfix) with ESMTP id 408F83C00F8 for ; Tue, 9 Apr 2013 15:41:49 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.234.117; KIP:(null); UIP:(null); (null); H:SN2PRD0510HT004.namprd05.prod.outlook.com; R:internal; EFV:INT X-SpamScore: -2 X-BigFish: PS-2(zz98dIc85fh4015Izz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz18c673h8275chz2dh2a8h668h839hbe3hd25he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1155h) Received: from mail108-tx2 (localhost.localdomain [127.0.0.1]) by mail108-tx2 (MessageSwitch) id 1365522106552887_32377; Tue, 9 Apr 2013 15:41:46 +0000 (UTC) Received: from TX2EHSMHS038.bigfish.com (unknown [10.9.14.226]) by mail108-tx2.bigfish.com (Postfix) with ESMTP id 77B921A005F; Tue, 9 Apr 2013 15:41:46 +0000 (UTC) Received: from SN2PRD0510HT004.namprd05.prod.outlook.com (157.56.234.117) by TX2EHSMHS038.bigfish.com (10.9.99.138) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 9 Apr 2013 15:41:46 +0000 Received: from SN2PRD0510MB384.namprd05.prod.outlook.com ([169.254.8.162]) by SN2PRD0510HT004.namprd05.prod.outlook.com ([10.255.116.39]) with mapi id 14.16.0287.008; Tue, 9 Apr 2013 15:41:45 +0000 From: Kireeti Kompella To: Ross Callon Thread-Topic: IPR poll on draft-kompella-mpls-special-purpose-labels Thread-Index: Ac41NFk+7S9hSU5uQhqMaALzMPBDPwABGPLQ Date: Tue, 9 Apr 2013 15:41:44 +0000 Message-ID: <935EBAEF-98A7-445B-832E-823CB644EBE1@juniper.net> References: <62CCD4C52ACDAD4481149BD5D8A72FD316BABC49@CH1PRD0510MB355.namprd05.prod.outlook.com> In-Reply-To: <62CCD4C52ACDAD4481149BD5D8A72FD316BABC49@CH1PRD0510MB355.namprd05.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.137.187.175] Content-Type: multipart/alternative; boundary="_000_935EBAEF98A7445B832E823CB644EBE1junipernet_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%12219$Dn%PI.NU$RO%2$TLS%5$FQDN%onpremiseedge-1018244.customer.frontbridge.com$TlsDn%o365mail.juniper.net 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 Cc: "mpls@ietf.org" , Loa Andersson Subject: Re: [mpls] IPR poll on draft-kompella-mpls-special-purpose-labels 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, 09 Apr 2013 15:55:12 -0000 --_000_935EBAEF98A7445B832E823CB644EBE1junipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Not aware of any IPR related to this draft. Kireeti On Apr 9, 2013, at 8:10, "Ross Callon" > wrote: Working Group and authors; The authors of draft-kompella-mpls-special-purpose-labels have indicated that the draft is ready to be adopted as a working group document. Before starting the poll to see if there is wg consensus to make the draft a working group document we will do an IPR poll 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-kompella-mpls-special-purpos= e-labels? 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) --_000_935EBAEF98A7445B832E823CB644EBE1junipernet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Not aware of any IPR related to this draft. 

Kireeti

On Apr 9, 2013, at 8:10, "Ross Callon" <rcallon@juniper.net> wrote:

Working Group and authors;
 
The authors of draft-kompella-mpls-special-purpose-labels have indicat= ed
that the draft is ready to be adopted as a working group document.
 
Before starting the poll to see if there is wg consensus to make the
draft a working group document we will do an IPR poll 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-kompella-mpls-special-p= urpose-labels?
 
If so, has this IPR been disclosed in compliance with IETF IPR  r= ules
(see RFCs 3979, 4879, 3669 and 5378 for more details).
 
If you are listed as a document author or contributor please respond t= o
this email regardless of whether or not you are aware of any relevant<= /div>
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 o= r
contributor, then please explicitly respond only if you are aware of a= ny
IPR that has not yet been disclosed in conformance with IETF rules.
 
 
Thanks, Ross
(as = MPLS WG co-chair)
&nbs= p;
--_000_935EBAEF98A7445B832E823CB644EBE1junipernet_-- From xuxiaohu@huawei.com Tue Apr 9 20:13: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 B123521F92DC for ; Tue, 9 Apr 2013 20:13:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.192 X-Spam-Level: X-Spam-Status: No, score=-3.192 tagged_above=-999 required=5 tests=[AWL=-1.136, 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 aIvcDx6otTX5 for ; Tue, 9 Apr 2013 20:13:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0736321F8FED for ; Tue, 9 Apr 2013 20:13:17 -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 ARQ84670; Wed, 10 Apr 2013 03:13:03 +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; Wed, 10 Apr 2013 04:12:32 +0100 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 10 Apr 2013 04:13:01 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.50]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.01.0323.007; Wed, 10 Apr 2013 11:12:58 +0800 From: Xuxiaohu To: "curtis@occnc.com" , Loa Andersson Thread-Topic: [mpls] poll to see if we have consensus to make draft-villamizar-mpls-forwarding an MPLS wg document Thread-Index: AQHOM6npoNhLxW5PqEKrcS0DKcLX4pjOyxYg Date: Wed, 10 Apr 2013 03:12:57 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F5BB9C@NKGEML512-MBS.china.huawei.com> References: Your message of "Mon, 01 Apr 2013 13:23:32 +0200." <51596E34.4020408@pi.nu> <201304071605.r37G5CRd078301@gateway1.orleans.occnc.com> In-Reply-To: <201304071605.r37G5CRd078301@gateway1.orleans.occnc.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: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" , "draft-villamizar-mpls-forwarding@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus to make draft-villamizar-mpls-forwarding 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, 10 Apr 2013 03:13:19 -0000 U3VwcG9ydC4NCg0KWGlhb2h1DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogbXBs cy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSC0+rHtIEN1 cnRpcw0KPiBWaWxsYW1pemFyDQo+ILeiy83KsbzkOiAyMDEzxOo01MI4yNUgMDowNQ0KPiDK1bz+ yMs6IExvYSBBbmRlcnNzb24NCj4gs63LzTogbXBsc0BpZXRmLm9yZzsgZHJhZnQtdmlsbGFtaXph ci1tcGxzLWZvcndhcmRpbmdAdG9vbHMuaWV0Zi5vcmc7DQo+IG1wbHMtY2hhaXJzQHRvb2xzLmll dGYub3JnDQo+INb3zOI6IFJlOiBbbXBsc10gcG9sbCB0byBzZWUgaWYgd2UgaGF2ZSBjb25zZW5z dXMgdG8gbWFrZQ0KPiBkcmFmdC12aWxsYW1pemFyLW1wbHMtZm9yd2FyZGluZyBhbiBNUExTIHdn IGRvY3VtZW50DQo+IA0KPiANCj4gTG9hLA0KPiANCj4gc3VwcG9ydA0KPiANCj4gKGFzIGNvLWF1 dGhvcikNCj4gDQo+IG1vdGl2YXRpb246ICBJdCBpcyBoZWxwZnVsIHRvIGNoaXAgdmVuZG9ycyBh bmQgc3lzdGVtIHZlbmRvcnMgdG8gaGF2ZQ0KPiBvbmUgcGxhY2UgdG8gbG9vayB0byBmaW5kIHJl ZmVyZW5jZXMgYXQgbGVhc3QgbW9zdCBvZiB0aGUgTVBMUw0KPiBmb3J3YXJkaW5nIHJlcXVpcmVt ZW50cy4NCj4gDQo+IEN1cnRpcw0KPiANCj4gDQo+IEluIG1lc3NhZ2UgPDUxNTk2RTM0LjQwMjA0 MDhAcGkubnU+DQo+IExvYSBBbmRlcnNzb24gd3JpdGVzOg0KPiANCj4gV29ya2luZyBHcm91cCwN Cj4gDQo+IFRoaXMgaXMgdG8gc3RhcnQgYSB0d28gd2VlayBwb2xsIG9uIGFkb3B0aW5nDQo+IGRy YWZ0LXZpbGxhbWl6YXItbXBscy1mb3J3YXJkaW5nLTAyIGFzIGFuIE1QTFMgd29ya2luZw0KPiBn cm91cCBkb2N1bWVudC4NCj4gDQo+IFBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgKHN1cHBvcnQv bm90IHN1cHBvcnQpIHRvIHRoZSBtcGxzIHdvcmtpbmcNCj4gZ3JvdXAgbWFpbGluZyBsaXN0ICht cGxzIGF0IGlldGYub3JnKS4gUGxlYXNlIGdpdmUgYSB0ZWNobmljYWwNCj4gbW90aXZhdGlvbiBm b3IgeW91ciBzdXBwb3J0L25vdCBzdXBwb3J0LCBlc3BlY2lhbGx5IGlmIHlvdSB0aGluayB0aGF0 DQo+IHRoZSBkb2N1bWVudCBzaG91bGQgbm90IGJlIGFkb3B0ZWQgYXMgYSB3b3JraW5nIGdyb3Vw IGRvY3VtZW50Lg0KPiANCj4gVGhpcyBwb2xsIGVuZHMgQXByaWwgMTUsIDIwMTMuDQo+IA0KPiBU aGVyZSBhcmUgbm8gSVBSIGNsYWltIGFnYWluc3QgdGhpcyBkb2N1bWVudC4NCj4gDQo+IFRoZSBh dXRob3JzIGhhcyBzdGF0ZWQgb24gdGhlIHdvcmtpbmcgZ3JvdXAgbWFpbGluZyBsaXN0DQo+IHRo YXQgdGhleSBhcmUgbm90IGF3YXJlIG9mIGFueSBvdGhlciBJUFIgY2xhaW1zIGFnYWluc3QgdGhp cyBkcmFmdC4NCj4gSG93ZXZlciBpZiB5b3UgYXJlIG9uIHRoZSB0aGUgbXBscyB3b3JraW5nIGdy b3VwIG1haWxpbmcgbGlzdCBhbmQNCj4gYXdhcmUgb2YgSVBSIHRoYXQgcmVsYXRlcyB0byB0aGlz IGRyYWZ0LCB0aGUgdGltZSB0byBkaXNjbG9zZQ0KPiB0aGlzIGlzIG5vdy4NCj4gDQo+IC9Mb2EN Cj4gKG1wbHMgd2cgY28tY2hhaXIpDQo+IC0tDQo+IA0KPiANCj4gTG9hIEFuZGVyc3NvbiAgICAg ICAgICAgICAgICAgICAgICAgIGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5jb20NCj4gU2VuaW9y IE1QTFMgRXhwZXJ0ICAgICAgICAgICAgICAgICAgICAgICAgICBsb2FAcGkubnUNCj4gSHVhd2Vp IFRlY2hub2xvZ2llcyAoY29uc3VsdGFudCkgICAgIHBob25lOiArNDYgNzM5IDgxIDIxIDY0DQo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG1wbHMg bWFpbGluZyBsaXN0DQo+IG1wbHNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9tcGxzDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQo+IG1wbHMgbWFpbGluZyBsaXN0DQo+IG1wbHNAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQo= From xuxiaohu@huawei.com Tue Apr 9 21:17: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 BF93F21F8F22 for ; Tue, 9 Apr 2013 21:17:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.193 X-Spam-Level: X-Spam-Status: No, score=-0.193 tagged_above=-999 required=5 tests=[AWL=-4.136, BAYES_00=-2.599, CN_BODY_35=0.339, GB_SUMOF=5, J_BACKHAIR_11=1, 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 AkhClvzlNzkv for ; Tue, 9 Apr 2013 21:17:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5061821F8E59 for ; Tue, 9 Apr 2013 21:17:18 -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 AQF61660; Wed, 10 Apr 2013 04:17:16 +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; Wed, 10 Apr 2013 05:16:40 +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, 10 Apr 2013 05:17:11 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.50]) by nkgeml405-hub.china.huawei.com ([10.98.56.36]) with mapi id 14.01.0323.007; Wed, 10 Apr 2013 12:17:05 +0800 From: Xuxiaohu To: Loa Andersson , "Dutta, Pranjal K (Pranjal)" , Sriganesh Kini , "Rajiv Asati (rajiva)" , "draft-atlas-mpls-te-express-path@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Thread-Topic: MPLS-RT review of draft-atlas-mpls-te-express-path Thread-Index: AQHOMoJeN4bJTlYtCkKAElY9Zwc7o5jKdc8A Date: Wed, 10 Apr 2013 04:17:05 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F5BBD3@NKGEML512-MBS.china.huawei.com> References: <515FA9AF.7080705@pi.nu> In-Reply-To: <515FA9AF.7080705@pi.nu> 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: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [mpls] MPLS-RT review of draft-atlas-mpls-te-express-path 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, 10 Apr 2013 04:17:20 -0000 SGkgYWxsLA0KDQpJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2MuIEkgYmVsaWV2ZSB0aGlzIGRvYyBp cyB1c2VmdWwsIGJ1dCBJIGhhdmUgYSBmZXcgY29tbWVudHMgYXMgZm9sbG93cyBmb3IgY29uc2lk ZXJhdGlvbjoNCg0KMS4gaW4gc2VjdGlvbiAyLjEsIGl0IHNhaWQgIiBXaGlsZSBpdCBoYXMgYmVl biBwb3NzaWJsZSB0byBjb21wdXRlIGEgQ1NQRiB3aGVyZSB0aGUgbGluayBsYXRlbmN5DQogICB2 YWx1ZXMgYXJlIHVzZWQgaW5zdGVhZCBvZiBURSBtZXRyaWNzLCB0aGlzIHJlc3VsdHMgaW4gaWdu b3JpbmcgdGhlDQogICBURSBtZXRyaWNzIGFuZCBjYXVzaW5nIExTUHMgdG8gcHJlZmVyIHRoZSBs b3dlc3QtbGF0ZW5jeSBwYXRocy4NCiAgIEluc3RlYWQgb2YgdGhpcyBhcHByb2FjaCB0byBtaW5p bWl6ZSBwYXRoIGxhdGVuY3ksIGFuIGVuZC10by1lbmQNCiAgIGxhdGVuY3kgYm91bmQgbWVyZWx5 IHJlcXVpcmVzIHRoYXQgdGhlIHBhdGggY29tcHV0ZWQgYmUgbm8gbW9yZSB0aGFuDQogICB0aGF0 IGJvdW5kIHdpdGhvdXQgYmVpbmcgdGhlIG1pbmltdW0uICBUaGlzIGJvdW5kIGNhbiBiZSB1c2Vk IGFzIGENCiAgIGNvbnN0cmFpbnQgaW4gQ1NQRiB0byBwcmV2ZW50IGV4cGxvcmluZyBsaW5rcyB0 aGF0IHdvdWxkIGNyZWF0ZSBhDQogICBwYXRoIG92ZXIgdGhlIGVuZC10by1lbmQgbGF0ZW5jeSBi b3VuZC4NCg0KICAgVGhpcyBpcyBpbGx1c3RyYXRlZCBhcyBmb2xsb3dzLiAgTGV0IHRoZSBMU1Ag aGF2ZSBhbiBlbmQtdG8tZW5kDQogICBsYXRlbmN5IGJvdW5kIG9mIDIwbXMuICBBc3N1bWUgdGhh dCB0aGUgcGF0aCB0byBub2RlIFggaGFzIGJlZW4NCiAgIG1pbmltaXplZCBhbmQgaXRzIGxhdGVu Y3kgaXMgMTJtcy4gIFdoZW4gWCdzIGxpbmtzIGFyZSB0byBiZQ0KICAgZXhwbG9yZWQsIHRoZSBs aW5rIFg8LT5ZIGhhcyBhIGxpbmsgbGF0ZW5jeSBvZiA1bXMgYW5kIHRoZSBsaW5rIFg8LT5aDQog ICBoYXMgYSBsaW5rIGxhdGVuY3kgb2YgOW1zLiAgVGhlIHBhdGggdmlhIFggdG8gWSBhbG9uZyBs aW5rIFg8LT5ZDQogICB3b3VsZCBoYXZlIGEgcGF0aCBsYXRlbmN5IG9mIDEybXMgKyA1bXMgPSAx N21zIDwgMjBtczsgdGhlcmVmb3JlLCB0aGUNCiAgIGxpbmsgWDwtPlkgY2FuIGJlIGV4cGxvcmVk LiAgSW4gY29udHJhc3QsIHJlYWNoaW5nIFogdmlhIGxpbmsgWDwtPloNCiAgIHdvdWxkIHJlc3Vs dCBpbiBhIHBhdGggbGF0ZW5jeSBvZiAxMm1zICsgOW1zID0gMjFtcyA+IDIwbXM7IHRoZXJlZm9y ZQ0KICAgdGhlIGxpbmsgWDwtPlogd291bGQgbm90IGJlIGV4cGxvcmVkIGluIHRoZSBDU1BGLiIN Cg0KICAgQ29tbWVudDogQWNjb3JkaW5nIHRvIGFuIGFib3ZlIHN0YXRlbWVudCBvZiAiIGFuIGVu ZC10by1lbmQgbGF0ZW5jeSBib3VuZCBtZXJlbHkgcmVxdWlyZXMgdGhhdCB0aGUgcGF0aCBjb21w dXRlZCBiZSBubyBtb3JlIHRoYW4gdGhhdCBib3VuZCB3aXRob3V0IGJlaW5nIHRoZSBtaW5pbXVt ICIsIGl0IHNlZW1zIHRoYXQgbGF0ZW5jeSBpcyBub3QgdXNlZCBhcyBhIG1ldHJpYyBmb3IgU1BG IGFsZ29yaXRobSBidXQgb25seSB1c2VkIGFzIGEgY29uc3RyYWludC4gSWYgc28sIGhvdyBkbyB5 b3UgZGVjaWRlIHdoaWNoIHNwZWNpZmljIGxpbmsocykgb2YgdGhlIGZpcnN0LXJvdW5kIGNhbGN1 bGF0ZWQgU1BGIHBhdGggc2hvdWxkIGJlIHBydW5lZCBwcmlvciB0byBleGVjdXRpbmcgdGhlIHNl Y29uZC1yb3VuZCBTUEYgY2FsY3VsYXRpb24/ICBUaGUgc2FtZSBxdWVzdGlvbiBleGlzdHMgd2hl biBjb25zaWRlcmluZyBlbmQtdG8tZW5kIHBhY2tldCBsb3NzIHJhdGlvIGFuZCBsYXRlbmN5IHZh cmlhdGlvbiBib3VuZHMuIFRoZSBleGFtcGxlIGlsbHVzdHJhdGVkIGluIHRoZSBkcmFmdCBzZWVt cyBub3QgY2xlYXIgdG8gbWUuIFdvdWxkIGFueSBjby1hdXRob3IgcGxlYXNlIGNsYXJpZnkgdGhl IGFib3ZlIGRvdWJ0Pw0KDQoyLiAgaW4gc2VjdGlvbiAyLjEsIGl0IHNhaWQgIkZvciBsaW5rIGxv c3MsIHRoZSBwYXRoIGxvc3MgaXMgbm90IHRoZSBzdW0gb2YgdGhlIHVzZWQgbGlua3MnDQogICBs b3NzZXMuICBJbnN0ZWFkLCB0aGUgcGF0aCBsb3NzIHBlcmNlbnRhZ2UgaXMgKDEwMCAtIGxvc3Nf TDEpKigxMDAgLQ0KICAgbG9zc19MMikqLi4uKigxMDAgLSBsb3NzX0xuKSwgd2hlcmUgdGhlIGxp bmtzIGFsb25nIHRoZSBwYXRoIGFyZSBMMQ0KICAgdG8gTG4uICBUaGUgZW5kLXRvLWVuZCBsaW5r IGxvc3MgYm91bmQsIGNvbXB1dGVkIGluIHRoaXMgZmFzaGlvbiwgY2FuDQogICBhbHNvIGJlIHVz ZWQgYXMgYSBjb25zdHJhaW50IGluIHRoZSBDU1BGIG9uIHdoYXQgbGlua3MgdG8gZXhwbG9yZSIu IA0KDQogICBDb21tZW50OiBJIGd1ZXNzIGNvLWF1dGhvcnMgd2FudGVkIHRvIHNheSBwYWNrZXQg bG9zcyByYXRpbyBoZXJlLiBJZiBzbywgdGhlIGZvcm11bGEgb2YgcGFja2V0IGxvc3MgcmF0aW8g aGVyZSBuZWVkcyB0byBiZSBjb3JyZWN0bHkgZXhwcmVzc2VkLg0KDQozLiAgSW4gc2VjdGlvbiAy LjIsIGl0IHNhaWQgIiBXaGVuIGNvbXB1dGluZw0KICAgdGhlIHBhdGggZm9yIGEgVEUgdHVubmVs LCBvbmx5IGxpbmtzIHdpdGggYXQgbGVhc3QgYSBjb25maWd1cmFibGUNCiAgIGFtb3VudCBvZiBV bmlkaXJlY3Rpb25hbCBBdmFpbGFibGUgQmFuZHdpZHRoIG1pZ2h0IGJlIHBlcm1pdHRlZC4iDQog ICANCiAgIENvbW1lbnQ6IEkgd29uZGVyIHdoZXRoZXIgaXQgaXMgc3VpdGFibGUgdG8gY29uc2lk ZXIgUmVzaWR1YWwgQmFuZHdpZHRoIGFuZCBVbmlkaXJlY3Rpb25hbCBBdmFpbGFibGUgQmFuZHdp ZHRoIHBhcmFtZXRlcnMgYXMgcGVyZm9ybWFuY2UgbWV0cmljcyBhbmQgdGhlcmVmb3JlIGRpc2N1 c3MgdGhlbSBpbiB0aGlzIGRvYy4gRnVydGhlcm1vcmUsIHdoZXRoZXIgb3Igbm90IHRoZSBtZWFz dXJlZCBiYW5kd2lkdGggdXNlZCBmb3IgdGhlIGFjdHVhbCBmb3J3YXJkaW5nIG9mIG5vbi0NCiAg IFJTVlAtVEUgTFNQIHBhY2tldHMgc2hvdWxkIGJlIGEgY29uc3RyYWludCBmb3IgQ1NQRiBkZXBl bmRzIG9uIG1hbnkgZmFjdG9ycywgc3VjaCBhcyB3aGV0aGVyIG9yIG5vdCB0aGlzIGJhbmR3aWR0 aCBjYW4gYmUgb2NjdXBpZWQgYnkgZnV0dXJlIFJTVlAtVEUgTFNQIHRyYWZmaWMuIEhlbmNlLCBt YXliZSBpdCdzIG1vcmUgc3VpdGFibGUgdG8gZGlzY3VzcyBpbiBkZXRhaWxzIHRoZSBiYW5kd2lk dGggY29uc3RyYWludCByZWxhdGVkIGlzc3VlcyBpbiBhIHNlcGFyYXRlIGRvYy4gDQoNCkJlc3Qg cmVnYXJkcywNClhpYW9odQ0KDQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogTG9h IEFuZGVyc3NvbiBbbWFpbHRvOmxvYUBwaS5udV0NCj4gt6LLzcqxvOQ6IDIwMTPE6jTUwjbI1SAx Mjo1MQ0KPiDK1bz+yMs6IER1dHRhLCBQcmFuamFsIEsgKFByYW5qYWwpOyBTcmlnYW5lc2ggS2lu aTsgUmFqaXYgQXNhdGkgKHJhaml2YSk7IFh1eGlhb2h1Ow0KPiBkcmFmdC1hdGxhcy1tcGxzLXRl LWV4cHJlc3MtcGF0aEB0b29scy5pZXRmLm9yZzsgbXBscy1jaGFpcnNAdG9vbHMuaWV0Zi5vcmcN Cj4g1vfM4jogTVBMUy1SVCByZXZpZXcgb2YgZHJhZnQtYXRsYXMtbXBscy10ZS1leHByZXNzLXBh dGgNCj4gDQo+IFhpYW9odSwgU3JpLCBSYWppdiBhbmQgUHJhbmphbCwNCj4gDQo+IFlvdSBoYXZl IGJlZW4gc2VsZWN0ZWQgYXMgYW4gTVBMUyBSZXZpZXcgdGVhbSByZXZpZXdlcnMgZm9yDQo+IGRy YWZ0LWF0bGFzLW1wbHMtdGUtZXhwcmVzcy1wYXRoLTAyLg0KPiANCj4gTm90ZSB0byBhdXRob3Jz OiBZb3UgaGF2ZSBiZWVuIENDJ2Qgb24gdGhpcyBlbWFpbCBzbyB0aGF0IHlvdSBjYW4ga25vdw0K PiB0aGF0IHRoaXMgcmV2aWV3IGlzIGdvaW5nIG9uLiBIb3dldmVyLCBwbGVhc2UgZG8gbm90IHJl dmlldyB5b3VyIG93bg0KPiBkb2N1bWVudC4NCj4gDQo+IFJldmlld3Mgc2hvdWxkIGNvbW1lbnQg b24gd2hldGhlciB0aGUgZG9jdW1lbnQgaXMgY29oZXJlbnQsIGlzIGl0DQo+IHVzZWZ1bCAoaWUs IGlzIGl0IGxpa2VseSB0byBiZSBhY3R1YWxseSB1c2VmdWwgaW4gb3BlcmF0aW9uYWwNCj4gbmV0 d29ya3MpLCBhbmQgaXMgdGhlIGRvY3VtZW50IHRlY2huaWNhbGx5IHNvdW5kPyAgV2UgYXJlIGlu dGVyZXN0ZWQNCj4gaW4ga25vd2luZyB3aGV0aGVyIHRoZSBkb2N1bWVudCBpcyByZWFkeSB0byBi ZSBjb25zaWRlcmVkIGZvciBXRw0KPiBhZG9wdGlvbiAoaWUsIGl0IGRvZXNuJ3QgaGF2ZSB0byBi ZSBwZXJmZWN0IGF0IHRoaXMgcG9pbnQsIGJ1dCBzaG91bGQgYmUNCj4gYSBnb29kIHN0YXJ0KS4N Cj4gDQo+IFJldmlld3Mgc2hvdWxkIGJlIHNlbnQgdG8gdGhlIGRvY3VtZW50IGF1dGhvcnMsIFdH IGNvLWNoYWlycyBhbmQNCj4gV0cgc2VjcmV0YXJ5LCBhbmQgQ0MnZCB0byB0aGUgTVBMUyBXRyBl bWFpbCBsaXN0LiBJZiBuZWNlc3NhcnksIGNvbW1lbnRzDQo+IG1heSBiZSBzZW50IHByaXZhdGVs eSB0byBvbmx5IHRoZSBXRyBjaGFpcnMuDQo+IA0KPiBBcmUgeW91IGFibGUgdG8gcmV2aWV3IHRo aXMgZHJhZnQgYnkgQXByaWwgMjAsIDIwMTM/DQo+IA0KPiBUaGFua3MsIExvYQ0KPiAoYXMgTVBM UyBXRyBjaGFpcikNCj4gDQo+IC9Mb2ENCj4gLS0NCj4gDQo+IA0KPiBMb2EgQW5kZXJzc29uICAg ICAgICAgICAgICAgICAgICAgICAgZW1haWw6IGxvYUBtYWlsMDEuaHVhd2VpLmNvbQ0KPiBTZW5p b3IgTVBMUyBFeHBlcnQgICAgICAgICAgICAgICAgICAgICAgICAgIGxvYUBwaS5udQ0KPiBIdWF3 ZWkgVGVjaG5vbG9naWVzIChjb25zdWx0YW50KSAgICAgcGhvbmU6ICs0NiA3MzkgODEgMjEgNjQN Cg== From agmalis@gmail.com Wed Apr 10 05:30: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 E727421F961A for ; Wed, 10 Apr 2013 05:30:14 -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 iV5uMhayonyY for ; Wed, 10 Apr 2013 05:30:14 -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 2BE0921F9610 for ; Wed, 10 Apr 2013 05:30:14 -0700 (PDT) Received: by mail-qe0-f47.google.com with SMTP id w7so187110qeb.20 for ; Wed, 10 Apr 2013 05:30:13 -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=N+LmFDmguVtulr+/R3ZJYTevdm52TbkBWaYzYvvhro0=; b=UXORW0S38uRAcO4QAHC4wygovrb6cV0uRX0ETmNgpF20ibtViHYcnGJfLMtIR9GTiR YqGgfPSAUoUwkhEYqgFRce/N1Z/G6zo+/sBydMksTO3tf9DkBJQGtK4a4j43uRbxQOOn tR5gGt3eXNRFQyKbcr5VqyPklep1jIqzEM/poF19Ns2Jy2rghz+No+EPdo4NOop8LPta F8FaPtDD1pGyuxX4pkLWpQq+d1FMZvmkpwhAjDTL/gUXhMRkun9gnA1Vrg4AjaTEuSAo +jYn1AofOqWklW+ie9qrdlx2eUjHoXcoQcuyYl9ZIlAJFAhUJ294cLFDX9O0wKK1/rrg jomQ== X-Received: by 10.224.119.76 with SMTP id y12mr2136573qaq.37.1365597013686; Wed, 10 Apr 2013 05:30:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.138.145 with HTTP; Wed, 10 Apr 2013 05:29:53 -0700 (PDT) In-Reply-To: <201304071605.r37G5CRd078301@gateway1.orleans.occnc.com> References: <51596E34.4020408@pi.nu> <201304071605.r37G5CRd078301@gateway1.orleans.occnc.com> From: "Andrew G. Malis" Date: Wed, 10 Apr 2013 08:29:53 -0400 Message-ID: To: Curtis Villamizar Content-Type: multipart/alternative; boundary=047d7b6d878ae85b4a04da00d462 Cc: "mpls@ietf.org" , "draft-villamizar-mpls-forwarding@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , Loa Andersson Subject: Re: [mpls] poll to see if we have consensus to make draft-villamizar-mpls-forwarding 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, 10 Apr 2013 12:30:15 -0000 --047d7b6d878ae85b4a04da00d462 Content-Type: text/plain; charset=ISO-8859-1 I also support as a co-author, for the same reasons as Curtis, plus including PW requirements as well. Cheers, Andy On Sun, Apr 7, 2013 at 12:05 PM, Curtis Villamizar wrote: > > Loa, > > support > > (as co-author) > > motivation: It is helpful to chip vendors and system vendors to have > one place to look to find references at least most of the MPLS > forwarding requirements. > > Curtis > > > In message <51596E34.4020408@pi.nu> > Loa Andersson writes: > > Working Group, > > This is to start a two week poll on adopting > draft-villamizar-mpls-forwarding-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 April 15, 2013. > > There are no IPR claim against this document. > > 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 > --047d7b6d878ae85b4a04da00d462 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I also support as a co-author, for the same reasons a= s Curtis, plus including PW requirements as well.

Cheers,
A= ndy

On Su= n, Apr 7, 2013 at 12:05 PM, Curtis Villamizar <curtis@occnc.com> wrote:

Loa,

support

(as co-author)

motivation: =A0It is helpful to chip vendors and system vendors to have
one place to look to find references at least most of the MPLS
forwarding requirements.

Curtis


In message <51596E34.4020408@p= i.nu>
Loa Andersson writes:

Working Group,

This is to start a two week poll on adopting
draft-villamizar-mpls-forwarding-02 as an MPLS working
group document.

Please send your comments (support/not support) to the mpls working
group mailing list (mpls at i= etf.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 April 15, 2013.

There are no IPR claim against this document.

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

--047d7b6d878ae85b4a04da00d462-- From shane@castlepoint.net Wed Apr 10 07:59: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 3D8AD21F97EF for ; Wed, 10 Apr 2013 07:59:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, 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 LPkyY-mKh6Hu for ; Wed, 10 Apr 2013 07:59:01 -0700 (PDT) Received: from mail.friendswithtools.org (unknown [64.78.239.70]) by ietfa.amsl.com (Postfix) with ESMTP id CB8D321F97E5 for ; Wed, 10 Apr 2013 07:59:01 -0700 (PDT) Received: from dspam (unknown [127.0.0.1]) by mail.friendswithtools.org (Postfix) with SMTP id 2296E300056 for ; Wed, 10 Apr 2013 14:59:01 +0000 (UTC) Received: from [10.9.0.10] (web.hollyman.com [64.78.239.73]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.friendswithtools.org (Postfix) with ESMTPSA id 8AB8B300054; Wed, 10 Apr 2013 08:59:00 -0600 (MDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Shane Amante In-Reply-To: <51596E34.4020408@pi.nu> Date: Wed, 10 Apr 2013 08:59:00 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <681C3CBA-7DCD-4B5B-9211-A753E9A354E8@castlepoint.net> References: <51596E34.4020408@pi.nu> To: Loa Andersson X-Mailer: Apple Mail (2.1503) X-DSPAM-Result: Innocent X-DSPAM-Processed: Wed Apr 10 08:59:01 2013 X-DSPAM-Confidence: 1.0000 X-DSPAM-Improbability: 1 in 98689409 chance of being spam X-DSPAM-Probability: 0.0023 X-DSPAM-Signature: 51657e3542078019632376 X-DSPAM-Factors: 27, not+#+#+#+you, 0.40000, working+#+#+#+mpls, 0.40000, 2013+at, 0.40000, 739+81, 0.40000, 2013+#+#+#+IPR, 0.40000, Mime-Version*Mail+6.3, 0.40000, mail01+#+com, 0.40000, are+#+#+of, 0.40000, that+#+document, 0.40000, list+#+#+ietf, 0.40000, This+#+#+start, 0.40000, ends+#+15, 0.40000, a+#+#+#+with, 0.40000, MPLS+#+requirements, 0.40000, Loa+#+loa, 0.40000, and+#+#+#+have, 0.40000, has+#+on, 0.40000, adopting+draft, 0.40000, think+that, 0.40000, have+#+#+#+reference, 0.40000, nu+#+Technologies, 0.40000, deployable+#+production, 0.40000, Subject*consensus+to, 0.40000, as+#+#+#+group, 0.40000, loa+#+#+Huawei, 0.40000, On+Apr, 0.40000, Subject*poll+#+#+#+we, 0.40000 Cc: "mpls@ietf.org" , "draft-villamizar-mpls-forwarding@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus to make draft-villamizar-mpls-forwarding 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, 10 Apr 2013 14:59:02 -0000 Loa, Support, (as co-author). This document is helpful for network equipment vendors (and, their = suppliers) to have a single, comprehensive reference, with respect to = crucial MPLS forwarding requirements, in order to ultimately be = deployable in production networks. -shane On Apr 1, 2013, at 5:23 AM, Loa Andersson wrote: > Working Group, >=20 > This is to start a two week poll on adopting > draft-villamizar-mpls-forwarding-02 as an MPLS working > group document. >=20 > 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. >=20 > This poll ends April 15, 2013. >=20 > There are no IPR claim against this document. >=20 > 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. >=20 > /Loa > (mpls wg co-chair) > --=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 yaakov_s@rad.com Wed Apr 10 08:19: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 7107621F984D for ; Wed, 10 Apr 2013 08:19:39 -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 g27ROqVklDFu for ; Wed, 10 Apr 2013 08:19:38 -0700 (PDT) Received: from rad.co.il (mailrelay01.rad.co.il [62.0.23.252]) by ietfa.amsl.com (Postfix) with ESMTP id 2950B21F9847 for ; Wed, 10 Apr 2013 08:19:35 -0700 (PDT) Received: from Internal Mail-Server by MailRelay01 (envelope-from yaakov?s@rad.com) with AES128-SHA encrypted SMTP; 10 Apr 2013 18:17:24 +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; Wed, 10 Apr 2013 18:19:32 +0300 From: Yaakov Stein To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] poll to see if we have consensus to make draft-villamizar-mpls-forwarding an MPLS wg document Thread-Index: AQHOLstp2uVwM8KCYkSY8qehvMBSNZjPn2tw Date: Wed, 10 Apr 2013 15:19:32 +0000 Message-ID: <07F7D7DED63154409F13298786A2ADC904CF7209@EXRAD5.ad.rad.co.il> References: <51596E34.4020408@pi.nu> In-Reply-To: <51596E34.4020408@pi.nu> 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.0A0C0201.51658305.0126,ss=1,fgs=0 Cc: "draft-villamizar-mpls-forwarding@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus to make draft-villamizar-mpls-forwarding 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, 10 Apr 2013 15:19:39 -0000 Support. An RFC-1812-style "walkthrough" of MPLS forwarding would be really useful. Y(J)S -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: 01 April, 2013 14:24 To: mpls@ietf.org Cc: draft-villamizar-mpls-forwarding@tools.ietf.org; mpls-chairs@tools.ietf= .org Subject: [mpls] poll to see if we have consensus to make draft-villamizar-m= pls-forwarding an MPLS wg document Working Group, This is to start a two week poll on adopting draft-villamizar-mpls-forwarding-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 April 15, 2013. There are no IPR claim against this document. 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 edc@google.com Wed Apr 10 09:05: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 07AE021F991B for ; Wed, 10 Apr 2013 09:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.311 X-Spam-Level: X-Spam-Status: No, score=-100.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, 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 1CqHbxG12cQy for ; Wed, 10 Apr 2013 09:05:28 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1A70621F98D2 for ; Wed, 10 Apr 2013 09:05:27 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hn17so4987539wib.16 for ; Wed, 10 Apr 2013 09:05:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=HO5Q+xQBvst+JpfVHJxvceRt7LmhxqNyygE02NOtOrs=; b=Le8oTuK2SJUtoQQ5MD5y6H5Od2qGwyFmp2tnm87sZqIpQNaNGb+We8Spc1qyxTy7Gx seZikwnPQRTE3lEY6q8vNLxbzUMWv/np47pChyCmnswCh6+vEaj2DrsV9EnMVx5F9rQx XiPXcEILyV8HXd55R/XF8MpHQOhN4UT/7B4diTbNQcV6dLkZR05ELDSY0gg+uIi33aCG lc3qK7iQrmBMolEgdTjyMbQziECXpeOB6zHNi3N0kMwmTHVTOR4LlGqcMjZFWGplruyl Pg9NqrEInl/TWkllPMHPAynf7N8VN9UexyPOvkY8qiP4PmZhHhzl0IDEI3ws03grpSGm I9rQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:x-gm-message-state; bh=HO5Q+xQBvst+JpfVHJxvceRt7LmhxqNyygE02NOtOrs=; b=Dfs6U5AHaG33Y+dz1mJXApytMOM/HoKqVVOXf/IJUE8OUa4zh8ZQSB/x+eCLoKwtwi 2JDDMr+zJRrMvmsFO4ElrLXH41upBylU598iBS1UsceJNDUuS7+fuLZakrwah841Bei0 TuXq94q0Me93FDA6ER/4r9/U/FyfdCmHBJXXO1mDdyDfAJRswiW5saqS7X0QXmUCkAus zqVowpZNhf3aMnO/7PPLBQA4HmU7I91bSrokljrY0lRUT4xWna7TdrrnKPKioZQwFtoq aNZ/b60q0SWs4AQyTEkdDOmDL4tUM6ZKjhtnhn8MPMm6mGYmXVvXpBjzBKXRtdRFZATP Vumw== X-Received: by 10.180.188.105 with SMTP id fz9mr3330877wic.21.1365609927199; Wed, 10 Apr 2013 09:05:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.28.132 with HTTP; Wed, 10 Apr 2013 09:04:47 -0700 (PDT) In-Reply-To: <51596E34.4020408@pi.nu> References: <51596E34.4020408@pi.nu> From: Edward Crabbe Date: Wed, 10 Apr 2013 09:04:47 -0700 Message-ID: To: Loa Andersson Content-Type: multipart/alternative; boundary=001a11c37b829ce2c004da03d655 X-Gm-Message-State: ALoCoQnAXRGl1166vl0Ww+YToBpjXgC22rDJWrBQsRFapZ0fGK3bI/GpEozWYM25kWcc0Llm6/+3urVsC8oeAErIUYzuQXrI00oSvOXJLLmjLXl7U0sjcLHI1XbGqDrZmluQ4kML/LU6iisNBzeY48txhgIKH36Y+Nq7hS4NkQR09ejFopVTPVvzISPsF4RcXjUWsAPol6s9 Cc: "mpls@ietf.org" , "draft-villamizar-mpls-forwarding@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus to make draft-villamizar-mpls-forwarding 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, 10 Apr 2013 16:05:29 -0000 --001a11c37b829ce2c004da03d655 Content-Type: text/plain; charset=ISO-8859-1 Support. -ed On Mon, Apr 1, 2013 at 4:23 AM, Loa Andersson wrote: > Working Group, > > This is to start a two week poll on adopting > draft-villamizar-mpls-**forwarding-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 April 15, 2013. > > There are no IPR claim against this document. > > 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 > --001a11c37b829ce2c004da03d655 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Support. =A0

=A0 =A0-ed


On Mon, Apr= 1, 2013 at 4:23 AM, Loa Andersson <loa@pi.nu> wrote:
Working Group,

This is to start a two week poll on adopting
draft-villamizar-mpls-forwarding-02 as an MPLS working
group document.

Please send your comments (support/not support) to the mpls working
group mailing list (mpls at i= etf.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 April 15, 2013.

There are no IPR claim against this document.

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

--001a11c37b829ce2c004da03d655-- From mach.chen@huawei.com Wed Apr 10 17:54: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 A7DEB21F8A38 for ; Wed, 10 Apr 2013 17:54:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kwlLuBb0GNf8 for ; Wed, 10 Apr 2013 17:54:19 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 13B9D21F8A2A for ; Wed, 10 Apr 2013 17:54:17 -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 ARR68727; Thu, 11 Apr 2013 00:54:11 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Apr 2013 01:53:38 +0100 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Apr 2013 01:54:09 +0100 Received: from szxeml558-mbs.china.huawei.com ([169.254.8.247]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Thu, 11 Apr 2013 08:54:04 +0800 From: Mach Chen To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] poll to see if we have consensus to make draft-villamizar-mpls-forwarding an MPLS wg document Thread-Index: AQHOLstoyd2nFd7FX0ixvdg8qayG/5jQQBvg Date: Thu, 11 Apr 2013 00:54:02 +0000 Message-ID: References: <51596E34.4020408@pi.nu> In-Reply-To: <51596E34.4020408@pi.nu> 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: "draft-villamizar-mpls-forwarding@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus to make draft-villamizar-mpls-forwarding 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, 11 Apr 2013 00:54:19 -0000 Support. Best regards, Mach > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of L= oa > Andersson > Sent: Monday, April 01, 2013 7:24 PM > To: mpls@ietf.org > Cc: draft-villamizar-mpls-forwarding@tools.ietf.org; mpls-chairs@tools.ie= tf.org > Subject: [mpls] poll to see if we have consensus to make > draft-villamizar-mpls-forwarding an MPLS wg document >=20 > Working Group, >=20 > This is to start a two week poll on adopting > draft-villamizar-mpls-forwarding-02 as an MPLS working > group document. >=20 > 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. >=20 > This poll ends April 15, 2013. >=20 > There are no IPR claim against this document. >=20 > 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. >=20 > /Loa > (mpls wg co-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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From gregory.mirsky@ericsson.com Wed Apr 10 17:57: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 9AD5321F8A66 for ; Wed, 10 Apr 2013 17:57:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 gjNRaGFk9IYV for ; Wed, 10 Apr 2013 17:57:36 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 4A31521F8A68 for ; Wed, 10 Apr 2013 17:57:36 -0700 (PDT) X-AuditID: c6180641-b7faf6d00000096b-de-51660a7f6d85 Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 91.90.02411.F7A06615; Thu, 11 Apr 2013 02:57:35 +0200 (CEST) Received: from EUSAAMB106.ericsson.se ([147.117.188.123]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0318.004; Wed, 10 Apr 2013 20:57:35 -0400 From: Gregory Mirsky To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] poll to see if we have consensus to make draft-villamizar-mpls-forwarding an MPLS wg document Thread-Index: AQHOLstm7Rm71Eysr0Kot+z5sMFvZZjQQW5w Date: Thu, 11 Apr 2013 00:57:34 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B482921@eusaamb106.ericsson.se> References: <51596E34.4020408@pi.nu> In-Reply-To: <51596E34.4020408@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+NgFrrHLMWRmVeSWpSXmKPExsUyuXRPiG49V1qgwenlRhZdJ2awWvybO4fZ 4vulJSwWt5auZHVg8Viy5CeTx6zpbWweXy5/ZgtgjuKySUnNySxLLdK3S+DKODLlEVPBH+6K 0z2nmRoYD3F2MXJySAiYSFw4fp0JwhaTuHBvPVsXIxeHkMBRRolfGz+wQjjLGSXaZv5lA6li EzCSeLGxhx3EFhGwk9j46h8jSBGzwDJGifV7brKCJIQFiiV+H/jBAlFUInGudzEbhG0ksWD6 AUYQm0VAVeLt399gNbwCvhIdXT/AaoQEVCTO9s9iBrE5gWpOnWwGsxmBzvt+ag3YqcwC4hK3 nsyHOltAYsme88wQtqjEy8f/WCFsZYklT/azQNTrSCzY/YkNwtaWWLbwNTPEXkGJkzOfsExg FJuFZOwsJC2zkLTMQtKygJFlFSNHaXFqWW66keEmRmAcHZNgc9zBuOCT5SFGaQ4WJXHeUNcL AUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYrS+fSdAqN9i76s7piWVLlL1VWyNZpt4Wuby3 8nTi0aD033eFrGtn7Q8MbZSY/OLDmTLbpT1SKfrbq7wPXGT/9WyaH/usKLaH79JslV2/HtNd v1oqSEMzQfXVmumvZY7WL72/LPWU8rx5Wr5fqnf5b/PM0sxjznApOL7oWpJshN9a041f1tom KLEUZyQaajEXFScCAJQ3cK5xAgAA Cc: "draft-villamizar-mpls-forwarding@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus to make draft-villamizar-mpls-forwarding 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, 11 Apr 2013 00:57:37 -0000 Support Regards, Greg=20 -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Loa= Andersson Sent: Monday, April 01, 2013 4:24 AM To: mpls@ietf.org Cc: draft-villamizar-mpls-forwarding@tools.ietf.org; mpls-chairs@tools.ietf= .org Subject: [mpls] poll to see if we have consensus to make draft-villamizar-m= pls-forwarding an MPLS wg document Working Group, This is to start a two week poll on adopting draft-villamizar-mpls-forwarding-02 as an MPLS working group document. Please send your comments (support/not support) to the mpls working group m= ailing 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 April 15, 2013. There are no IPR claim against this document. 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 xuxiaohu@huawei.com Wed Apr 10 23: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 B8E5D21F8E6E for ; Wed, 10 Apr 2013 23:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.635 X-Spam-Level: X-Spam-Status: No, score=0.635 tagged_above=-999 required=5 tests=[AWL=-3.308, BAYES_00=-2.599, CN_BODY_35=0.339, GB_SUMOF=5, J_BACKHAIR_11=1, 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 A--UK6erB1UV for ; Wed, 10 Apr 2013 23:50:12 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D886621F85F5 for ; Wed, 10 Apr 2013 23:50:10 -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 ARR88909; Thu, 11 Apr 2013 06:50:09 +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; Thu, 11 Apr 2013 07:49:16 +0100 Received: from nkgeml407-hub.china.huawei.com (10.98.56.38) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Apr 2013 07:49:51 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.50]) by nkgeml407-hub.china.huawei.com ([10.98.56.38]) with mapi id 14.01.0323.007; Thu, 11 Apr 2013 14:49:40 +0800 From: Xuxiaohu To: Xuxiaohu , Loa Andersson , "Dutta, Pranjal K (Pranjal)" , Sriganesh Kini , "Rajiv Asati (rajiva)" , "draft-atlas-mpls-te-express-path@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , "mpls@ietf.org" Thread-Topic: MPLS-RT review of draft-atlas-mpls-te-express-path Thread-Index: AQHOMoJeN4bJTlYtCkKAElY9Zwc7o5jKdc8AgAYTvLA= Date: Thu, 11 Apr 2013 06:49:39 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F5C097@NKGEML512-MBS.china.huawei.com> References: <515FA9AF.7080705@pi.nu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F5BBD3@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F5BBD3@NKGEML512-MBS.china.huawei.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: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [mpls] MPLS-RT review of draft-atlas-mpls-te-express-path 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, 11 Apr 2013 06:50:12 -0000 DQoNCj4gLS0tLS3Tyrz+1K28/i0tLS0tDQo+ILeivP7IyzogbXBscy1ib3VuY2VzQGlldGYub3Jn IFttYWlsdG86bXBscy1ib3VuY2VzQGlldGYub3JnXSC0+rHtDQo+IFh1eGlhb2h1DQo+ILeiy83K sbzkOiAyMDEzxOo01MIxMMjVIDEyOjE3DQo+IMrVvP7IyzogTG9hIEFuZGVyc3NvbjsgRHV0dGEs IFByYW5qYWwgSyAoUHJhbmphbCk7IFNyaWdhbmVzaCBLaW5pOyBSYWppdiBBc2F0aQ0KPiAocmFq aXZhKTsgZHJhZnQtYXRsYXMtbXBscy10ZS1leHByZXNzLXBhdGhAdG9vbHMuaWV0Zi5vcmc7DQo+ IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnOyBtcGxzQGlldGYub3JnDQo+INb3zOI6IFJlOiBb bXBsc10gTVBMUy1SVCByZXZpZXcgb2YgZHJhZnQtYXRsYXMtbXBscy10ZS1leHByZXNzLXBhdGgN Cj4gDQo+IEhpIGFsbCwNCj4gDQo+IEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvYy4gSSBiZWxpZXZl IHRoaXMgZG9jIGlzIHVzZWZ1bCwgYnV0IEkgaGF2ZSBhIGZldyBjb21tZW50cw0KPiBhcyBmb2xs b3dzIGZvciBjb25zaWRlcmF0aW9uOg0KPiANCj4gMS4gaW4gc2VjdGlvbiAyLjEsIGl0IHNhaWQg IiBXaGlsZSBpdCBoYXMgYmVlbiBwb3NzaWJsZSB0byBjb21wdXRlIGEgQ1NQRiB3aGVyZQ0KPiB0 aGUgbGluayBsYXRlbmN5DQo+ICAgIHZhbHVlcyBhcmUgdXNlZCBpbnN0ZWFkIG9mIFRFIG1ldHJp Y3MsIHRoaXMgcmVzdWx0cyBpbiBpZ25vcmluZyB0aGUNCj4gICAgVEUgbWV0cmljcyBhbmQgY2F1 c2luZyBMU1BzIHRvIHByZWZlciB0aGUgbG93ZXN0LWxhdGVuY3kgcGF0aHMuDQo+ICAgIEluc3Rl YWQgb2YgdGhpcyBhcHByb2FjaCB0byBtaW5pbWl6ZSBwYXRoIGxhdGVuY3ksIGFuIGVuZC10by1l bmQNCj4gICAgbGF0ZW5jeSBib3VuZCBtZXJlbHkgcmVxdWlyZXMgdGhhdCB0aGUgcGF0aCBjb21w dXRlZCBiZSBubyBtb3JlIHRoYW4NCj4gICAgdGhhdCBib3VuZCB3aXRob3V0IGJlaW5nIHRoZSBt aW5pbXVtLiAgVGhpcyBib3VuZCBjYW4gYmUgdXNlZCBhcyBhDQo+ICAgIGNvbnN0cmFpbnQgaW4g Q1NQRiB0byBwcmV2ZW50IGV4cGxvcmluZyBsaW5rcyB0aGF0IHdvdWxkIGNyZWF0ZSBhDQo+ICAg IHBhdGggb3ZlciB0aGUgZW5kLXRvLWVuZCBsYXRlbmN5IGJvdW5kLg0KPiANCj4gICAgVGhpcyBp cyBpbGx1c3RyYXRlZCBhcyBmb2xsb3dzLiAgTGV0IHRoZSBMU1AgaGF2ZSBhbiBlbmQtdG8tZW5k DQo+ICAgIGxhdGVuY3kgYm91bmQgb2YgMjBtcy4gIEFzc3VtZSB0aGF0IHRoZSBwYXRoIHRvIG5v ZGUgWCBoYXMgYmVlbg0KPiAgICBtaW5pbWl6ZWQgYW5kIGl0cyBsYXRlbmN5IGlzIDEybXMuICBX aGVuIFgncyBsaW5rcyBhcmUgdG8gYmUNCj4gICAgZXhwbG9yZWQsIHRoZSBsaW5rIFg8LT5ZIGhh cyBhIGxpbmsgbGF0ZW5jeSBvZiA1bXMgYW5kIHRoZSBsaW5rIFg8LT5aDQo+ICAgIGhhcyBhIGxp bmsgbGF0ZW5jeSBvZiA5bXMuICBUaGUgcGF0aCB2aWEgWCB0byBZIGFsb25nIGxpbmsgWDwtPlkN Cj4gICAgd291bGQgaGF2ZSBhIHBhdGggbGF0ZW5jeSBvZiAxMm1zICsgNW1zID0gMTdtcyA8IDIw bXM7IHRoZXJlZm9yZSwgdGhlDQo+ICAgIGxpbmsgWDwtPlkgY2FuIGJlIGV4cGxvcmVkLiAgSW4g Y29udHJhc3QsIHJlYWNoaW5nIFogdmlhIGxpbmsgWDwtPloNCj4gICAgd291bGQgcmVzdWx0IGlu IGEgcGF0aCBsYXRlbmN5IG9mIDEybXMgKyA5bXMgPSAyMW1zID4gMjBtczsgdGhlcmVmb3JlDQo+ ICAgIHRoZSBsaW5rIFg8LT5aIHdvdWxkIG5vdCBiZSBleHBsb3JlZCBpbiB0aGUgQ1NQRi4iDQo+ IA0KPiAgICBDb21tZW50OiBBY2NvcmRpbmcgdG8gYW4gYWJvdmUgc3RhdGVtZW50IG9mICIgYW4g ZW5kLXRvLWVuZCBsYXRlbmN5DQo+IGJvdW5kIG1lcmVseSByZXF1aXJlcyB0aGF0IHRoZSBwYXRo IGNvbXB1dGVkIGJlIG5vIG1vcmUgdGhhbiB0aGF0IGJvdW5kDQo+IHdpdGhvdXQgYmVpbmcgdGhl IG1pbmltdW0gIiwgaXQgc2VlbXMgdGhhdCBsYXRlbmN5IGlzIG5vdCB1c2VkIGFzIGEgbWV0cmlj IGZvcg0KPiBTUEYgYWxnb3JpdGhtIGJ1dCBvbmx5IHVzZWQgYXMgYSBjb25zdHJhaW50LiBJZiBz bywgaG93IGRvIHlvdSBkZWNpZGUgd2hpY2gNCj4gc3BlY2lmaWMgbGluayhzKSBvZiB0aGUgZmly c3Qtcm91bmQgY2FsY3VsYXRlZCBTUEYgcGF0aCBzaG91bGQgYmUgcHJ1bmVkIHByaW9yIHRvDQo+ IGV4ZWN1dGluZyB0aGUgc2Vjb25kLXJvdW5kIFNQRiBjYWxjdWxhdGlvbj8gIFRoZSBzYW1lIHF1 ZXN0aW9uIGV4aXN0cyB3aGVuDQo+IGNvbnNpZGVyaW5nIGVuZC10by1lbmQgcGFja2V0IGxvc3Mg cmF0aW8gYW5kIGxhdGVuY3kgdmFyaWF0aW9uIGJvdW5kcy4gVGhlDQo+IGV4YW1wbGUgaWxsdXN0 cmF0ZWQgaW4gdGhlIGRyYWZ0IHNlZW1zIG5vdCBjbGVhciB0byBtZS4gV291bGQgYW55IGNvLWF1 dGhvcg0KPiBwbGVhc2UgY2xhcmlmeSB0aGUgYWJvdmUgZG91YnQ/DQoNCkhlcmUgSSBtZWFudCB3 aGVuIHRoZSBmaXJzdC1yb3VuZCBjYWxjdWxhdGVkIFNQRiBwYXRoIHdpdGggZXhpc3RpbmcgY29u c3RyYWludHMgKGUuZy4sIGJhbmR3aWR0aCwgcmVzb3VyY2UgY29sb3IgZXRjKSBiZWluZyBtZXQg Y2FuJ3QgbWVldCB0aGUgZW5kLXRvLWVuZCBsYXRlbmN5IGJvdW5kIGNvbnN0cmFpbnQsIGhvdyBk byB5b3UgZGVjaWRlIHdoaWNoIHNwZWNpZmljIGxpbmsocykgb2YgdGhhdCBmaXJzdC1yb3VuZCBj YWxjdWxhdGVkIFNQRiBwYXRoIHNob3VsZCBiZSBwcnVuZWQgcHJpb3IgdG8NCmV4ZWN1dGluZyB0 aGUgc2Vjb25kLXJvdW5kIFNQRiBjYWxjdWxhdGlvbj8gSW4gb3RoZXIgd29yZHMsIGl0IHdvdWxk IGJlIHZlcnkgaGFyZCB0byB1c2UgYSBjdW11bGF0ZWQgdmFsdWUgb2YgYSBnaXZlbiB0eXBlIG9m IGxpbmsgbWV0cmljIChlLmcuLCBlbmQgdG8gZW5kIHBhdGggbGF0ZW5jeSwgZW5kIHRvIGVuZCBs YXRlbmN5IHZhcmlhdGlvbikgYXMgYSBjb25zdHJhaW50IGZvciB0aGUgQ1NQRiBhbGdvcml0aG0s IElNSE8uDQoNCkJlc3QgcmVnYXJkcywNClhpYW9odQ0KDQo+IDIuICBpbiBzZWN0aW9uIDIuMSwg aXQgc2FpZCAiRm9yIGxpbmsgbG9zcywgdGhlIHBhdGggbG9zcyBpcyBub3QgdGhlIHN1bSBvZiB0 aGUgdXNlZA0KPiBsaW5rcycNCj4gICAgbG9zc2VzLiAgSW5zdGVhZCwgdGhlIHBhdGggbG9zcyBw ZXJjZW50YWdlIGlzICgxMDAgLSBsb3NzX0wxKSooMTAwIC0NCj4gICAgbG9zc19MMikqLi4uKigx MDAgLSBsb3NzX0xuKSwgd2hlcmUgdGhlIGxpbmtzIGFsb25nIHRoZSBwYXRoIGFyZSBMMQ0KPiAg ICB0byBMbi4gIFRoZSBlbmQtdG8tZW5kIGxpbmsgbG9zcyBib3VuZCwgY29tcHV0ZWQgaW4gdGhp cyBmYXNoaW9uLCBjYW4NCj4gICAgYWxzbyBiZSB1c2VkIGFzIGEgY29uc3RyYWludCBpbiB0aGUg Q1NQRiBvbiB3aGF0IGxpbmtzIHRvIGV4cGxvcmUiLg0KPiANCj4gICAgQ29tbWVudDogSSBndWVz cyBjby1hdXRob3JzIHdhbnRlZCB0byBzYXkgcGFja2V0IGxvc3MgcmF0aW8gaGVyZS4gSWYgc28s DQo+IHRoZSBmb3JtdWxhIG9mIHBhY2tldCBsb3NzIHJhdGlvIGhlcmUgbmVlZHMgdG8gYmUgY29y cmVjdGx5IGV4cHJlc3NlZC4NCj4gDQo+IDMuICBJbiBzZWN0aW9uIDIuMiwgaXQgc2FpZCAiIFdo ZW4gY29tcHV0aW5nDQo+ICAgIHRoZSBwYXRoIGZvciBhIFRFIHR1bm5lbCwgb25seSBsaW5rcyB3 aXRoIGF0IGxlYXN0IGEgY29uZmlndXJhYmxlDQo+ICAgIGFtb3VudCBvZiBVbmlkaXJlY3Rpb25h bCBBdmFpbGFibGUgQmFuZHdpZHRoIG1pZ2h0IGJlIHBlcm1pdHRlZC4iDQo+IA0KPiAgICBDb21t ZW50OiBJIHdvbmRlciB3aGV0aGVyIGl0IGlzIHN1aXRhYmxlIHRvIGNvbnNpZGVyIFJlc2lkdWFs IEJhbmR3aWR0aA0KPiBhbmQgVW5pZGlyZWN0aW9uYWwgQXZhaWxhYmxlIEJhbmR3aWR0aCBwYXJh bWV0ZXJzIGFzIHBlcmZvcm1hbmNlIG1ldHJpY3MNCj4gYW5kIHRoZXJlZm9yZSBkaXNjdXNzIHRo ZW0gaW4gdGhpcyBkb2MuIEZ1cnRoZXJtb3JlLCB3aGV0aGVyIG9yIG5vdCB0aGUNCj4gbWVhc3Vy ZWQgYmFuZHdpZHRoIHVzZWQgZm9yIHRoZSBhY3R1YWwgZm9yd2FyZGluZyBvZiBub24tDQo+ICAg IFJTVlAtVEUgTFNQIHBhY2tldHMgc2hvdWxkIGJlIGEgY29uc3RyYWludCBmb3IgQ1NQRiBkZXBl bmRzIG9uIG1hbnkNCj4gZmFjdG9ycywgc3VjaCBhcyB3aGV0aGVyIG9yIG5vdCB0aGlzIGJhbmR3 aWR0aCBjYW4gYmUgb2NjdXBpZWQgYnkgZnV0dXJlDQo+IFJTVlAtVEUgTFNQIHRyYWZmaWMuIEhl bmNlLCBtYXliZSBpdCdzIG1vcmUgc3VpdGFibGUgdG8gZGlzY3VzcyBpbiBkZXRhaWxzIHRoZQ0K PiBiYW5kd2lkdGggY29uc3RyYWludCByZWxhdGVkIGlzc3VlcyBpbiBhIHNlcGFyYXRlIGRvYy4N Cj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gWGlhb2h1DQo+IA0KPiANCj4gPiAtLS0tLdPKvP7Urbz+ LS0tLS0NCj4gPiC3orz+yMs6IExvYSBBbmRlcnNzb24gW21haWx0bzpsb2FAcGkubnVdDQo+ID4g t6LLzcqxvOQ6IDIwMTPE6jTUwjbI1SAxMjo1MQ0KPiA+IMrVvP7IyzogRHV0dGEsIFByYW5qYWwg SyAoUHJhbmphbCk7IFNyaWdhbmVzaCBLaW5pOyBSYWppdiBBc2F0aSAocmFqaXZhKTsNCj4gWHV4 aWFvaHU7DQo+ID4gZHJhZnQtYXRsYXMtbXBscy10ZS1leHByZXNzLXBhdGhAdG9vbHMuaWV0Zi5v cmc7IG1wbHMtY2hhaXJzQHRvb2xzLmlldGYub3JnDQo+ID4g1vfM4jogTVBMUy1SVCByZXZpZXcg b2YgZHJhZnQtYXRsYXMtbXBscy10ZS1leHByZXNzLXBhdGgNCj4gPg0KPiA+IFhpYW9odSwgU3Jp LCBSYWppdiBhbmQgUHJhbmphbCwNCj4gPg0KPiA+IFlvdSBoYXZlIGJlZW4gc2VsZWN0ZWQgYXMg YW4gTVBMUyBSZXZpZXcgdGVhbSByZXZpZXdlcnMgZm9yDQo+ID4gZHJhZnQtYXRsYXMtbXBscy10 ZS1leHByZXNzLXBhdGgtMDIuDQo+ID4NCj4gPiBOb3RlIHRvIGF1dGhvcnM6IFlvdSBoYXZlIGJl ZW4gQ0MnZCBvbiB0aGlzIGVtYWlsIHNvIHRoYXQgeW91IGNhbiBrbm93DQo+ID4gdGhhdCB0aGlz IHJldmlldyBpcyBnb2luZyBvbi4gSG93ZXZlciwgcGxlYXNlIGRvIG5vdCByZXZpZXcgeW91ciBv d24NCj4gPiBkb2N1bWVudC4NCj4gPg0KPiA+IFJldmlld3Mgc2hvdWxkIGNvbW1lbnQgb24gd2hl dGhlciB0aGUgZG9jdW1lbnQgaXMgY29oZXJlbnQsIGlzIGl0DQo+ID4gdXNlZnVsIChpZSwgaXMg aXQgbGlrZWx5IHRvIGJlIGFjdHVhbGx5IHVzZWZ1bCBpbiBvcGVyYXRpb25hbA0KPiA+IG5ldHdv cmtzKSwgYW5kIGlzIHRoZSBkb2N1bWVudCB0ZWNobmljYWxseSBzb3VuZD8gIFdlIGFyZSBpbnRl cmVzdGVkDQo+ID4gaW4ga25vd2luZyB3aGV0aGVyIHRoZSBkb2N1bWVudCBpcyByZWFkeSB0byBi ZSBjb25zaWRlcmVkIGZvciBXRw0KPiA+IGFkb3B0aW9uIChpZSwgaXQgZG9lc24ndCBoYXZlIHRv IGJlIHBlcmZlY3QgYXQgdGhpcyBwb2ludCwgYnV0IHNob3VsZCBiZQ0KPiA+IGEgZ29vZCBzdGFy dCkuDQo+ID4NCj4gPiBSZXZpZXdzIHNob3VsZCBiZSBzZW50IHRvIHRoZSBkb2N1bWVudCBhdXRo b3JzLCBXRyBjby1jaGFpcnMgYW5kDQo+ID4gV0cgc2VjcmV0YXJ5LCBhbmQgQ0MnZCB0byB0aGUg TVBMUyBXRyBlbWFpbCBsaXN0LiBJZiBuZWNlc3NhcnksIGNvbW1lbnRzDQo+ID4gbWF5IGJlIHNl bnQgcHJpdmF0ZWx5IHRvIG9ubHkgdGhlIFdHIGNoYWlycy4NCj4gPg0KPiA+IEFyZSB5b3UgYWJs ZSB0byByZXZpZXcgdGhpcyBkcmFmdCBieSBBcHJpbCAyMCwgMjAxMz8NCj4gPg0KPiA+IFRoYW5r cywgTG9hDQo+ID4gKGFzIE1QTFMgV0cgY2hhaXIpDQo+ID4NCj4gPiAvTG9hDQo+ID4gLS0NCj4g Pg0KPiA+DQo+ID4gTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAgICAgICAgICAgIGVtYWlsOiBs b2FAbWFpbDAxLmh1YXdlaS5jb20NCj4gPiBTZW5pb3IgTVBMUyBFeHBlcnQgICAgICAgICAgICAg ICAgICAgICAgICAgIGxvYUBwaS5udQ0KPiA+IEh1YXdlaSBUZWNobm9sb2dpZXMgKGNvbnN1bHRh bnQpICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0KPiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBtcGxzIG1haWxpbmcgbGlzdA0KPiBtcGxzQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBscw0K From internet-drafts@ietf.org Fri Apr 12 05:17: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 5AA6221F8940; Fri, 12 Apr 2013 05:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.14 X-Spam-Level: X-Spam-Status: No, score=-99.14 tagged_above=-999 required=5 tests=[AWL=-2.823, BAYES_00=-2.599, FH_HAS_XAIMC=2.696, HELO_MISMATCH_COM=0.553, RCVD_IN_XBL=3.033, 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 Eth6uiKbai22; Fri, 12 Apr 2013 05:17:27 -0700 (PDT) Received: from jlonline.com (pip48.ptt.js.cn [61.155.13.224]) by ietfa.amsl.com (Postfix) with SMTP id 1D72121F891D; Fri, 12 Apr 2013 05:17:26 -0700 (PDT) Received: from jlonline.com([10.100.0.22]) by ptt.js.cn(AIMC 4.0.0.0) with SMTP id jm2651682fef; Fri, 12 Apr 2013 20:07:36 +0800 Received: from mail.ietf.org([12.22.58.30]) by ptt.js.cn(AIMC 4.0.0.0) with SMTP id jm7a516356b2; Tue, 09 Apr 2013 02:21:24 +0800 Received: from mail.ietf.org([12.22.58.30]) by ptt.js.cn(AIMC 4.0.0.0) with SMTP id AISP action; Tue, 09 Apr 2013 02:21:24 +0800 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 31AEA21F918C; Mon, 8 Apr 2013 11:14:01 -0700 (PDT) X-Original-To: i-d-announce@ietfa.amsl.com Delivered-To: i-d-announce@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C710821F8266; Mon, 8 Apr 2013 11:13:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 Pq8S14MsZXFj; Mon, 8 Apr 2013 11:13:57 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0697821F8265; Mon, 8 Apr 2013 11:13:57 -0700 (PDT) MIME-Version: 1.0 From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p3 Message-ID: <20130408181352.24388.57450.idtracker@ietfa.amsl.com> Date: Mon, 08 Apr 2013 11:13:52 -0700 X-BeenThere: i-d-announce@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: i-d-announce-bounces@ietf.org Errors-To: i-d-announce-bounces@ietf.org X-AIMC-AUTH: (null) X-AIMC-MAILFROM: i-d-announce-bounces@ietf.org X-AIMC-Msg-ID: CbChQZ4B X-AIMC-AUTH: (null) X-AIMC-MAILFROM: internet-drafts@ietf.org Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-ethernet-addressing-07.txt X-BeenThere: mpls@ietf.org Reply-To: internet-drafts@ietf.org List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 12:17:28 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiprotocol Label Switching Working Group of the IETF. Title : MPLS-TP Next-Hop Ethernet Addressing Author(s) : Dan Frost Stewart Bryant Matthew Bocci Filename : draft-ietf-mpls-tp-ethernet-addressing-07.txt Pages : 9 Date : 2013-04-08 Abstract: The Multiprotocol Label Switching (MPLS) Transport Profile (MPLS-TP) is the set of MPLS protocol functions applicable to the construction and operation of packet-switched transport networks. This document presents considerations for link-layer addressing of Ethernet frames carrying MPLS-TP packets. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-ethernet-addressing There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-ethernet-addressing-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-ethernet-addressing-07 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 internet-drafts@ietf.org Fri Apr 12 06:29: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 83E5421F8BB7; Fri, 12 Apr 2013 06:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.43 X-Spam-Level: X-Spam-Status: No, score=-102.43 tagged_above=-999 required=5 tests=[AWL=0.170, 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 FEdK+mX8x4Ee; Fri, 12 Apr 2013 06:29:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 183FD21F8A7E; Fri, 12 Apr 2013 06:29:36 -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.43.p4 Message-ID: <20130412132935.424.76598.idtracker@ietfa.amsl.com> Date: Fri, 12 Apr 2013 06:29:35 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp-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: Fri, 12 Apr 2013 13:29: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 : Signaling RSVP-TE P2MP LSPs in an Inter-domain Environme= nt Author(s) : Zafar Ali Rakesh Gandhi Tarek Saad Robert H. Venator Yuji Kamite Filename : draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp-01.txt Pages : 17 Date : 2013-04-12 Abstract: Point-to-MultiPoint (P2MP) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) are established using signaling procedures defined in [RFC4875]. However, [RFC4875] does not address several issues that arise when a P2MP-TE LSP is signaled in inter-domain networks. One such issue is the computation of a loosely routed inter-domain P2MP- TE LSP paths that are re-merge free. Another issue is the reoptimization of the inter-domain P2MP-TE LSP tree vs. an individual destination(s), since the loosely routing domain ingress border node is not aware of the reoptimization scope. This document defines the required protocol extensions needed for establishing and reoptimizing P2MP MPLS and GMPLS TE LSPs in inter-domain networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-inter-domain-p2mp-rsvp-te-= lsp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-inter-domain-p2mp-rsvp-t= e-lsp-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From rgandhi@cisco.com Fri Apr 12 06:36: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 DCFDB21F8B13 for ; Fri, 12 Apr 2013 06:36:41 -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 7aUQlMjcL8Ch for ; Fri, 12 Apr 2013 06:36: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 174B121F8BE2 for ; Fri, 12 Apr 2013 06:36:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2510; q=dns/txt; s=iport; t=1365773801; x=1366983401; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vnRi79cgqOtO6tfslZRYQLtu5RyQrvKZICZ/fGjNIKA=; b=Ypk2P2zvQ9GULq6ZknzqeNsxSqHXCtDhhk6ZntgteCQiTGCVHUYM7Hp0 bNw/iYK/3l0H7zuEon55WdCZTLqc4STsMQNED5nNub4PDBrscJd/lAr3c nPDLVaxMC8gRzgz0x/2hptc7NcfJ1NVAdsrFTz5QpHrMIvuDLA40y3kDK Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFACMNaFGtJXHA/2dsb2JhbABQgwY2wWKBCxZ0gh8BAQEEAQEBNzQLDAQCAQgRBAEBCxQJBycLFAkIAgQOBQgBiAsMvT+OZiYLBwaCWmEDmCOPcIMLgig X-IronPort-AV: E=Sophos;i="4.87,462,1363132800"; d="scan'208";a="198072961" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 12 Apr 2013 13:36:40 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r3CDae7E009654 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 12 Apr 2013 13:36:40 GMT Received: from xmb-aln-x07.cisco.com ([169.254.2.115]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Fri, 12 Apr 2013 08:36:39 -0500 From: "Rakesh Gandhi (rgandhi)" To: "mpls-chairs@tools.ietf.org" Thread-Topic: [mpls] I-D Action: draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp-01.txt Thread-Index: AQHON4HmTI3OqKo+VUqz4dE62CsqqJjSlTlw Date: Fri, 12 Apr 2013 13:36:39 +0000 Message-ID: References: <20130412132935.424.76598.idtracker@ietfa.amsl.com> In-Reply-To: <20130412132935.424.76598.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.82.247.175] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "robert.h.venator.civ@mail.mil" , "Zafar Ali \(zali\)" , "Loa Andersson \(loa@pi.nu\)" Subject: Re: [mpls] I-D Action: draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp-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: Fri, 12 Apr 2013 13:36:42 -0000 Dear WG, Chairs, This new version of the draft has updated IANA section as per comments from= the WG chairs. Thanks, Rakesh -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of int= ernet-drafts@ietf.org Sent: Friday, April 12, 2013 9:30 AM To: i-d-announce@ietf.org Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp-0= 1.txt 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 : Signaling RSVP-TE P2MP LSPs in an Inter-domain Environme= nt Author(s) : Zafar Ali Rakesh Gandhi Tarek Saad Robert H. Venator Yuji Kamite Filename : draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp-01.txt Pages : 17 Date : 2013-04-12 Abstract: Point-to-MultiPoint (P2MP) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) are established using signaling procedures defined in [RFC4875]. However, [RFC4875] does not address several issues that arise when a P2MP-TE LSP is signaled in inter-domain networks. One such issue is the computation of a loosely routed inter-domain P2MP- TE LSP paths that are re-merge free. Another issue is the reoptimization of the inter-domain P2MP-TE LSP tree vs. an individual destination(s), since the loosely routing domain ingress border node is not aware of the reoptimization scope. This document defines the required protocol extensions needed for establishing and reoptimizing P2MP MPLS and GMPLS TE LSPs in inter-domain networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-inter-domain-p2mp-rsvp-te-= lsp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-inter-domain-p2mp-rsvp-t= e-lsp-01 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 From jcucchiara@mindspring.com Fri Apr 12 17:35: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 11C0221F8DC1; Fri, 12 Apr 2013 17:35:01 -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, STOX_REPLY_TYPE=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 sku+wzwDNMpC; Fri, 12 Apr 2013 17:34:59 -0700 (PDT) Received: from elasmtp-junco.atl.sa.earthlink.net (elasmtp-junco.atl.sa.earthlink.net [209.86.89.63]) by ietfa.amsl.com (Postfix) with ESMTP id B5EF321F8DA0; Fri, 12 Apr 2013 17:34:59 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=a5ufZyfbo2TVhHyPK2CKXehHjrvGzLWIzmyOz3QR38qG+nouizd9UVUvUT0VRyIY; h=Received:Message-ID:From:To:Cc:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.41.69.138] (helo=JoanPC) by elasmtp-junco.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1UQoQk-0001YO-S4; Fri, 12 Apr 2013 20:34:58 -0400 Message-ID: <010401ce37e7$15b17ed0$6f01a8c0@JoanPC> From: "Joan Cucchiara" To: , "MIB Doctors \(E-mail\)" , "Loa Andersson" , "Thomas Nadeau" , "Venkatesan Mahalingam" , "Kannan Sampath" Date: Fri, 12 Apr 2013 20:34:47 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654b4bb481d29095864ce7e922808684282a7ce0e8f8d31aa3f350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.69.138 Subject: [mpls] MIB Dr. review of draft-ietf-mpls-tp-te-mib-05 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, 13 Apr 2013 00:35:01 -0000 Sam, I am sorry for such a long delay....here is the MIB Dr. Review. Lots of progress on the draft! Please see the comments below. Thanks, -Joan smicng OUTPUT -------------- MPLS-LSR-EXT-STD-MIB ====================== W: f(MPLS-LSR-EXT-STD-MIB.my), (216,18) For "mplsXCExtTunnelPointer", syntax is identical W: f(MPLS-LSR-EXT-STD-MIB.my), (215,18) MIN-ACCESS value identical to access specified for "mplsXCExtTunnelPointer" W: f(MPLS-LSR-EXT-STD-MIB.my), (223,18) For "mplsXCExtOppositeDirXCPtr", syntax is identical *) The DESCRIPTION clauses related to these objects should be updated to include the information in this conformance section. MPLS-TE-EXT-STD-MIB ===================== E: f(MPLS-TE-EXT-STD-MIB.my), (284,17) Index item "mplsTunnelExtNodeIpMapNodeId" must be defined with syntax that includes a range I see the following in MPLS-TC-EXT-STD-MIB MplsNodeId ::= TEXTUAL-CONVENTION .... SYNTAX Unsigned32 -- the default range: (0..4294967295) my suggestion is to include the range as part of the SYNTAX in the TC. smilint ----------- MIBs compile cleanly. GENERAL COMMENTS ---------------- *) The terms augments/sparse augments/extensions are all used to describe relationships with tables in this document and tables in rfc3812 and rfc3813. For example, a table in this document says "sparse augments" but then has a value of noSuchInstance returned if the counter is not applicable for TP. Another part of the document says that a table in this document augments a table from elsewhere, but that does not seem to be the case when looking at the MIB module. The relationships beween tables in this document and the tables in rfc3812 and rfc3813 need to be specified clearly. I would ask that the authors please check these relationships between the tables. This may be (simply?) using the term 'sparse augments' consistently. *) Appendix D of rfc4181 (MIB guidelines) suggests: xxxMIB | +-- xxxNotifications(0) +-- xxxObjects(1) +-- xxxConformance(2) | +-- xxxCompliances(1) +-- xxxGroups(2) The MIB Modules in this doc: \-2 Conformance \-v-1 Groups \-2 Compliances So Groups and Compliances are not in the suggested order. Specific Comments ===================== *) Introduction "This MIB module should be used...." Which MIB module are you referring to? (Do you mean "These MIB modules"??) *) Same Section (Intro) "...for MPLS based traffic engineering configuration and management." I don't understand completely, but seems like MPLS TP is probably what is meant. *) 4. Motivations s/used in non-IP environment./used in non-IP environments. awkward sentence: This MIB also defines three other MIB modules within this document. Maybe: This document defines 4 MIB modules: (and then list all 4) 5. Feature List Could you refer to the MIB module by name? So, instead of "MPLS transport profile MIB module" use the MPLS-TE-EXT-STD-MIB and so forth. 6. Brief description of MIB Objects This section focuses on MPLS-TE-EXT-STD-MIB, so maybe rename the section or also include the other MIB modules in this document. 6.5 mplsTunnelExtReversePerfTable "This table augments the mplsTunnelTable..." If it augments, then why is AUGMENTS not used in the MPLS-TE-EXT-STD-MIB? I think this relationship is a sparce augments, not an actual augments? Please explain. MPLS-TC-EXT-MIB ================== *) Why is the CC ID not represented in this MIB Module? Basically, the question has to do with the following from draft-ietf-mpls-tp-itu-t-identifiers, specifically: "Together, the CC and the ICC form the ICC_Operator_ID as: CC::ICC The ICC_Operator_ID is used as a replacement for the Global_ID as specified in [RFC6370], i.e. its purpose is to provide a globally unique context for other MPLS-TP identifiers." ICC_Operator_ID appears to be the counterpart to GLOBAL_ID. In other words, these both uniquely identify an operator. Whereas, ICC by itself does not. MPLS-ID-STD-MIB ================= *)What is the relationship between mplsIdGlobalId and mplsIdNodeId? Specifically, if mplsIdGlobalId has been set, can mplsIdNodeId be set to a different value? *) NIT: Could the order reflect the same order as in MPLS-TC-EXT-STD-MIB? The reason is that GLobal_ID and NODE_ID are related so think would be logical to have them near each other. *) Also, I'm not really sure why you want a MIB module with only 3 scalars in it? As far as I can see these scalars are only used in the MPLS-TE-EXT-STD-MIB, so why separate them? *) Error: FullCompliance and ReadOnlyCompliance is EXACTLY the same. MPLS-LSR-EXT-STD-MIB ===================== Compliance: OBJECT mplsXCExtTunnelPointer SYNTAX RowPointer MIN-ACCESS read-only DESCRIPTION "The only valid value for Tunnel Pointer is mplsTunnelTable entry." *) This object is read-only, so no need for a read-only compliance since object is already read-only. *) The above DESCRIPTION needs to be included in the object's DESCRIPTION. OBJECT mplsXCExtOppositeDirXCPtr SYNTAX RowPointer MIN-ACCESS read-only DESCRIPTION "The only valid value for XC Pointer is mplsXCTable entry." ::= { mplsLsrExtCompliances 2 } *) The above DESCRIPTION needs to be included in the object's DESCRIPTION. *) There is nothing here that specifies the readOnly compliance. Would expect something like: OBJECT nameOfObject MIN-ACCESS read-only DESCRIPTION "Write access is not required." MPLS-TE-EXT-STD-MIB =================== *) DESCRIPTION "This object indicates the Global Operator Identifier. This object value should be zero when mplsTunnelExtNodeConfigIccId is configured with non-null value." DESCRIPTION should state that the object has no meaning when mplsTunnelExtNodeConfigIccId is valid. Same comment for mplsTunnelExtNodeConfigId. In other words, maybe an additional object is needed to indicate Global or ICC? What if a 3rd TP id is created, then what happens? Better to be explicite I think, than to try and overload these objects with values that they shouldn't have. mplsTunnelExtNodeConfigNodeId OBJECT-TYPE SYNTAX MplsNodeId MAX-ACCESS read-create STATUS current DESCRIPTION "This object indicates the Node_ID within the operator. *) Sentence is awkward. mplsTunnelExtNodeConfigIccId Similar comment to the above. Additionally, how can an OCTET STRING of size (1..6) have a zero value? *) mplsTunnelExtNodeConfigStorageType Not sure I see the advantage of having this as it is already in the MplsTunnelTable. Why have 2 StorageType objects for the same row? *) mplsTunnelExtIngressLSRLocalIdValid and mplsTunnelExtEgressLSRLocalIdValid Please fix the DESCRIPTION and REFERENCE. (Looks like the DESCRIPTION clause has been continued after the REF clause.) *) mplsTunnelExtReversePerfTable I would like to understand why noSuchInstance would be needed. This table is a sparse augments, so either the entry would be there or it wouldn't, right? *) Probably could remove the following (comment applies to other MIB Modules also.) -- Notifications mplsTeExtNotifications OBJECT IDENTIFIER ::= { mplsTeExtStdMIB 0 } -- Notifications. -- Notification objects need to be added here. -- End of notifications. *) Compliance Section ReadOnly compliance is the same as the Full Compliance. In other words, readonly compliance does not really exist. Please fix this. 14. Security Considerations ============================ Should specify which objects would jeopardize security. 15. IANA Considerations ======================== Where is it? This section needs to be done. -- the end -- From loa@pi.nu Sat Apr 13 05:43: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 C09DD21F8A85 for ; Sat, 13 Apr 2013 05:43:41 -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 2bxJmUJ1KKHB for ; Sat, 13 Apr 2013 05:43:41 -0700 (PDT) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id F1D2B21F896D for ; Sat, 13 Apr 2013 05:43:40 -0700 (PDT) Received: from [10.5.7.46] (unknown [202.106.79.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id D34BE7FE07; Sat, 13 Apr 2013 14:43:35 +0200 (CEST) Message-ID: <516952F8.4090407@pi.nu> Date: Sat, 13 Apr 2013 14:43:36 +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" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [mpls] 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: Sat, 13 Apr 2013 12:43:41 -0000 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 Sat Apr 13 06:35: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 6A87421F877B for ; Sat, 13 Apr 2013 06:35:17 -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 LqF2zDrmDohO for ; Sat, 13 Apr 2013 06:35:17 -0700 (PDT) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id D7E1721F86CE for ; Sat, 13 Apr 2013 06:35:16 -0700 (PDT) Received: from [10.5.7.46] (unknown [202.106.79.7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id C05CB823B5; Sat, 13 Apr 2013 15:35:12 +0200 (CEST) Message-ID: <51695F10.1090804@pi.nu> Date: Sat, 13 Apr 2013 15:35:12 +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] Update: 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: Sat, 13 Apr 2013 13:35:17 -0000 Working Group, One of the author correctly pointed out that there were an IPR disclosure against draft-ali-mpls-inter-domain-p2mp-rsvp-te-lsp-08. Since this was pointed out by an author from the same company that made the original IPR disclosure I think it is safe to assume that https://datatracker.ietf.org/ipr/1861/ is still relevant for draft-ietf-mpls-inter-domain-p2mp-rsvp-te-lsp. /Loa for the wg co-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 aldrin.ietf@gmail.com Sat Apr 13 23:05: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 BF49A21F8F50; Sat, 13 Apr 2013 23:05:18 -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 lrVNNU8jf7CV; Sat, 13 Apr 2013 23:05:17 -0700 (PDT) Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by ietfa.amsl.com (Postfix) with ESMTP id C7A4621F8F0F; Sat, 13 Apr 2013 23:05:17 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id mc17so2040212pbc.28 for ; Sat, 13 Apr 2013 23:05:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:subject:mime-version:content-type:from:x-priority :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=Ou0kdD1ZPY+NXI8OXFJolrOgjUfDbfHj00mdz7hU5Xs=; b=pdA/vakUOxye0gpUhEz0bF+tfjzAjZ60F3gGvzPwjays/hGNOsxBuNeC6G6oPWDwmn 9vO9YvHaoAl0+FVC6K83l/sz29RMLWWBd0O+cmC5tM91gcWPQx7rsF2KDVF73MitDrzy g2wtoP/8ErCsM4xvpvpSv770/wbcinf6mnUNnelJkysEqy1MWuhfhN6NLvviAFxedt0R Ntftj5ogryqci22Hnuy6LsHX2Zj3XkBBj4bZGFiB6tbor6N1Kc/y+qK5eWYAly1ob5L+ ymTp0QflqGoe6EbY7m04reaMOdBX1bnjmE0ZfWYSJWwXVnvoBVndzwk+NPCLVWhkTHXF QiFA== X-Received: by 10.68.212.168 with SMTP id nl8mr10384166pbc.43.1365919517486; Sat, 13 Apr 2013 23:05:17 -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 ESMTPS id ce16sm16613383pac.5.2013.04.13.23.05.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 13 Apr 2013 23:05:16 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) Content-Type: text/plain; charset=iso-8859-1 From: Sam Aldrin X-Priority: 3 In-Reply-To: <010401ce37e7$15b17ed0$6f01a8c0@JoanPC> Date: Sat, 13 Apr 2013 23:05:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1A9C31CE-51E6-4BC4-A505-DB5EEDF10545@gmail.com> References: <010401ce37e7$15b17ed0$6f01a8c0@JoanPC> To: Joan Cucchiara X-Mailer: Apple Mail (2.1503) Cc: mpls@ietf.org, Kannan Sampath , "MIB Doctors \(E-mail\)" , Venkatesan Mahalingam , Loa Andersson Subject: Re: [mpls] MIB Dr. review of draft-ietf-mpls-tp-te-mib-05 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, 14 Apr 2013 06:05:18 -0000 Hi Joan, Thank you for your detailed review. Will address all the comments you have raised. An updated version with appropriate changes will be sent for your = review, prior to publishing the new version. thanks again. -sam On Apr 12, 2013, at 6:34 PM, Joan Cucchiara = wrote: > Sam, >=20 > I am sorry for such a long delay....here is the MIB Dr. Review. Lots = of progress on the draft! >=20 > Please see the comments below. >=20 > Thanks, > -Joan >=20 >=20 > smicng OUTPUT > -------------- >=20 > MPLS-LSR-EXT-STD-MIB > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > W: f(MPLS-LSR-EXT-STD-MIB.my), (216,18) For "mplsXCExtTunnelPointer", = syntax is identical > W: f(MPLS-LSR-EXT-STD-MIB.my), (215,18) MIN-ACCESS value identical to = access specified for "mplsXCExtTunnelPointer" > W: f(MPLS-LSR-EXT-STD-MIB.my), (223,18) For = "mplsXCExtOppositeDirXCPtr", syntax is identical >=20 > *) The DESCRIPTION clauses related to these objects > should be updated to include the information in this > conformance section. >=20 >=20 >=20 >=20 > MPLS-TE-EXT-STD-MIB > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > E: f(MPLS-TE-EXT-STD-MIB.my), (284,17) Index item = "mplsTunnelExtNodeIpMapNodeId" must be defined with syntax that includes = a range >=20 > I see the following in MPLS-TC-EXT-STD-MIB > MplsNodeId ::=3D TEXTUAL-CONVENTION > .... > SYNTAX Unsigned32 -- the default range: (0..4294967295) >=20 > my suggestion is to include the range as part of the SYNTAX in the TC. >=20 >=20 > smilint > ----------- > MIBs compile cleanly. >=20 >=20 > GENERAL COMMENTS > ---------------- > *) The terms augments/sparse augments/extensions are all used to > describe relationships with tables in this document and > tables in rfc3812 and rfc3813. For example, > a table in this document says "sparse augments" but then has > a value of noSuchInstance returned if the counter is not applicable > for TP. >=20 > Another part of the document says that a table in this document > augments a table from elsewhere, but that does not seem to be the > case when looking at the MIB module. >=20 > The relationships beween tables in this document and > the tables in rfc3812 and rfc3813 need to be specified clearly. > I would ask that the authors please check these relationships between > the tables. This may be (simply?) using the term > 'sparse augments' consistently. >=20 >=20 >=20 > *) Appendix D of rfc4181 (MIB guidelines) suggests: >=20 >=20 > xxxMIB > | > +-- xxxNotifications(0) > +-- xxxObjects(1) > +-- xxxConformance(2) > | > +-- xxxCompliances(1) > +-- xxxGroups(2) >=20 > The MIB Modules in this doc: >=20 > \-2 Conformance > \-v-1 Groups >=20 > \-2 Compliances >=20 > So Groups and Compliances are not in the suggested order. >=20 >=20 > Specific Comments > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > *) Introduction >=20 > "This MIB module should be used...." >=20 > Which MIB module are you referring to? (Do you mean "These MIB = modules"??) >=20 > *) Same Section (Intro) > "...for MPLS based traffic engineering configuration and management." >=20 > I don't understand completely, but seems like MPLS TP is probably what = is meant. >=20 >=20 > *) 4. Motivations >=20 > s/used in non-IP environment./used in non-IP environments. >=20 > awkward sentence: This MIB also defines three other MIB modules = within this document. > Maybe: This document defines 4 MIB modules: (and then list all 4) >=20 >=20 > 5. Feature List > Could you refer to the MIB module by name? So, instead of > "MPLS transport profile MIB module" use the MPLS-TE-EXT-STD-MIB > and so forth. >=20 >=20 > 6. Brief description of MIB Objects > This section focuses on MPLS-TE-EXT-STD-MIB, so maybe rename the = section > or also include the other MIB modules in this document. >=20 > 6.5 mplsTunnelExtReversePerfTable >=20 > "This table augments the mplsTunnelTable..." >=20 > If it augments, then why is AUGMENTS not used in the > MPLS-TE-EXT-STD-MIB? I think this relationship is a > sparce augments, not an actual augments? Please > explain. >=20 >=20 > MPLS-TC-EXT-MIB > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > *) Why is the CC ID not represented in this MIB Module? >=20 > Basically, the question has to do with the following from > draft-ietf-mpls-tp-itu-t-identifiers, specifically: >=20 > "Together, the CC and the ICC form the ICC_Operator_ID as: >=20 > CC::ICC >=20 > The ICC_Operator_ID is used as a replacement for the Global_ID as > specified in [RFC6370], i.e. its purpose is to provide a globally > unique context for other MPLS-TP identifiers." >=20 > ICC_Operator_ID appears to be the counterpart to GLOBAL_ID. In other > words, these both uniquely identify an operator. Whereas, ICC by = itself > does not. >=20 >=20 > MPLS-ID-STD-MIB > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > *)What is the relationship between mplsIdGlobalId and mplsIdNodeId? > Specifically, if mplsIdGlobalId has been set, can mplsIdNodeId be > set to a different value? >=20 >=20 > *) NIT: Could the order reflect the same order as in = MPLS-TC-EXT-STD-MIB? > The reason is that GLobal_ID and NODE_ID are related so think would be > logical to have them near each other. >=20 > *) Also, I'm not really sure why you want a MIB module with only 3 = scalars > in it? As far as I can see these scalars are only used in the > MPLS-TE-EXT-STD-MIB, so why separate them? >=20 > *) Error: FullCompliance and ReadOnlyCompliance is EXACTLY the same. >=20 > MPLS-LSR-EXT-STD-MIB > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Compliance: > OBJECT mplsXCExtTunnelPointer > SYNTAX RowPointer > MIN-ACCESS read-only > DESCRIPTION > "The only valid value for Tunnel Pointer is > mplsTunnelTable entry." >=20 > *) This object is read-only, so no need for a read-only compliance > since object is already read-only. >=20 > *) The above DESCRIPTION needs to be included in the > object's DESCRIPTION. >=20 >=20 > OBJECT mplsXCExtOppositeDirXCPtr > SYNTAX RowPointer > MIN-ACCESS read-only > DESCRIPTION > "The only valid value for XC Pointer is > mplsXCTable entry." >=20 > ::=3D { mplsLsrExtCompliances 2 } >=20 > *) The above DESCRIPTION needs to be included in the > object's DESCRIPTION. >=20 > *) There is nothing here that specifies the readOnly compliance. > Would expect something like: >=20 > OBJECT nameOfObject > MIN-ACCESS read-only > DESCRIPTION "Write access is not required." >=20 >=20 > MPLS-TE-EXT-STD-MIB > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > *) DESCRIPTION > "This object indicates the Global Operator Identifier. > This object value should be zero when > mplsTunnelExtNodeConfigIccId is configured with non-null > value." >=20 > DESCRIPTION should state that the object has no meaning when > mplsTunnelExtNodeConfigIccId is valid. Same comment for > mplsTunnelExtNodeConfigId. >=20 > In other words, maybe an additional object is needed to indicate > Global or ICC? What if a 3rd TP id is created, then what happens? >=20 > Better to be explicite I think, than to try and overload these > objects with values that they shouldn't have. >=20 > mplsTunnelExtNodeConfigNodeId OBJECT-TYPE > SYNTAX MplsNodeId > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "This object indicates the Node_ID within the operator. >=20 > *) Sentence is awkward. >=20 > mplsTunnelExtNodeConfigIccId > Similar comment to the above. Additionally, how can an OCTET STRING > of size (1..6) have a zero value? >=20 > *) mplsTunnelExtNodeConfigStorageType >=20 > Not sure I see the advantage of having this as it is > already in the MplsTunnelTable. Why have 2 StorageType objects > for the same row? >=20 > *) mplsTunnelExtIngressLSRLocalIdValid and > mplsTunnelExtEgressLSRLocalIdValid > Please fix the DESCRIPTION and REFERENCE. > (Looks like the DESCRIPTION clause has been continued after the > REF clause.) >=20 >=20 >=20 > *) mplsTunnelExtReversePerfTable >=20 > I would like to understand why noSuchInstance would be needed. > This table is a sparse augments, > so either the entry would be there or it wouldn't, right? >=20 > *) Probably could remove the following (comment applies to other > MIB Modules also.) >=20 > -- Notifications > mplsTeExtNotifications OBJECT IDENTIFIER > ::=3D { mplsTeExtStdMIB 0 } >=20 > -- Notifications. > -- Notification objects need to be added here. > -- End of notifications. >=20 >=20 > *) Compliance Section > ReadOnly compliance is the same as the Full Compliance. > In other words, readonly compliance does not really exist. > Please fix this. >=20 >=20 > 14. Security Considerations > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > Should specify which objects would jeopardize security. >=20 > 15. IANA Considerations > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= >=20 > Where is it? This section needs to be done. >=20 >=20 > -- the end -- >=20 From lucy.yong@huawei.com Sun Apr 14 04:54: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 62E3921F8FF5 for ; Sun, 14 Apr 2013 04:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.178 X-Spam-Level: X-Spam-Status: No, score=-4.178 tagged_above=-999 required=5 tests=[AWL=-2.121, 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 gcKF2V1z2KUT for ; Sun, 14 Apr 2013 04:54:08 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id C93BB21F8FDB for ; Sun, 14 Apr 2013 04:54:07 -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 AQJ09038; Sun, 14 Apr 2013 11:54:02 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sun, 14 Apr 2013 12:53:57 +0100 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sun, 14 Apr 2013 12:53:59 +0100 Received: from DFWEML509-MBX.china.huawei.com ([169.254.11.204]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.007; Sun, 14 Apr 2013 04:53:53 -0700 From: Lucy yong To: Loa Andersson Thread-Topic: [mpls] poll to see if we have consensus to make draft-villamizar-mpls-forwarding an MPLS wg document Thread-Index: AQHOM6npoNhLxW5PqEKrcS0DKcLX4pjOyxYggAW94WA= Date: Sun, 14 Apr 2013 11:53:52 +0000 Message-ID: <2691CE0099834E4A9C5044EEC662BB9D45251414@dfweml509-mbx.china.huawei.com> References: Your message of "Mon, 01 Apr 2013 13:23:32 +0200." <51596E34.4020408@pi.nu> <201304071605.r37G5CRd078301@gateway1.orleans.occnc.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F5BB9C@NKGEML512-MBS.china.huawei.com> In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F5BB9C@NKGEML512-MBS.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.218.222] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "mpls@ietf.org" , "draft-villamizar-mpls-forwarding@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus to make draft-villamizar-mpls-forwarding 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: Sun, 14 Apr 2013 11:54:09 -0000 U3VwcG9ydCENCg0KQ2hlZXJzLA0KTHVjeQ0KDQo+IA0KPiA+IC0tLS0t08q8/tStvP4tLS0tLQ0K PiA+ILeivP7IyzogbXBscy1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86bXBscy1ib3VuY2VzQGll dGYub3JnXSC0+rHtDQo+IEN1cnRpcw0KPiA+IFZpbGxhbWl6YXINCj4gPiC3osvNyrG85DogMjAx M8TqNNTCOMjVIDA6MDUNCj4gPiDK1bz+yMs6IExvYSBBbmRlcnNzb24NCj4gPiCzrcvNOiBtcGxz QGlldGYub3JnOyBkcmFmdC12aWxsYW1pemFyLW1wbHMtZm9yd2FyZGluZ0B0b29scy5pZXRmLm9y ZzsNCj4gPiBtcGxzLWNoYWlyc0B0b29scy5pZXRmLm9yZw0KPiA+INb3zOI6IFJlOiBbbXBsc10g cG9sbCB0byBzZWUgaWYgd2UgaGF2ZSBjb25zZW5zdXMgdG8gbWFrZQ0KPiA+IGRyYWZ0LXZpbGxh bWl6YXItbXBscy1mb3J3YXJkaW5nIGFuIE1QTFMgd2cgZG9jdW1lbnQNCj4gPg0KPiA+DQo+ID4g TG9hLA0KPiA+DQo+ID4gc3VwcG9ydA0KPiA+DQo+ID4gKGFzIGNvLWF1dGhvcikNCj4gPg0KPiA+ IG1vdGl2YXRpb246ICBJdCBpcyBoZWxwZnVsIHRvIGNoaXAgdmVuZG9ycyBhbmQgc3lzdGVtIHZl bmRvcnMgdG8gaGF2ZQ0KPiA+IG9uZSBwbGFjZSB0byBsb29rIHRvIGZpbmQgcmVmZXJlbmNlcyBh dCBsZWFzdCBtb3N0IG9mIHRoZSBNUExTDQo+ID4gZm9yd2FyZGluZyByZXF1aXJlbWVudHMuDQo+ ID4NCj4gPiBDdXJ0aXMNCj4gPg0KPiA+DQo+ID4gSW4gbWVzc2FnZSA8NTE1OTZFMzQuNDAyMDQw OEBwaS5udT4NCj4gPiBMb2EgQW5kZXJzc29uIHdyaXRlczoNCj4gPg0KPiA+IFdvcmtpbmcgR3Jv dXAsDQo+ID4NCj4gPiBUaGlzIGlzIHRvIHN0YXJ0IGEgdHdvIHdlZWsgcG9sbCBvbiBhZG9wdGlu Zw0KPiA+IGRyYWZ0LXZpbGxhbWl6YXItbXBscy1mb3J3YXJkaW5nLTAyIGFzIGFuIE1QTFMgd29y a2luZw0KPiA+IGdyb3VwIGRvY3VtZW50Lg0KPiA+DQo+ID4gUGxlYXNlIHNlbmQgeW91ciBjb21t ZW50cyAoc3VwcG9ydC9ub3Qgc3VwcG9ydCkgdG8gdGhlIG1wbHMgd29ya2luZw0KPiA+IGdyb3Vw IG1haWxpbmcgbGlzdCAobXBscyBhdCBpZXRmLm9yZykuIFBsZWFzZSBnaXZlIGEgdGVjaG5pY2Fs DQo+ID4gbW90aXZhdGlvbiBmb3IgeW91ciBzdXBwb3J0L25vdCBzdXBwb3J0LCBlc3BlY2lhbGx5 IGlmIHlvdSB0aGluayB0aGF0DQo+ID4gdGhlIGRvY3VtZW50IHNob3VsZCBub3QgYmUgYWRvcHRl ZCBhcyBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuDQo+ID4NCj4gPiBUaGlzIHBvbGwgZW5kcyBB cHJpbCAxNSwgMjAxMy4NCj4gPg0KPiA+IFRoZXJlIGFyZSBubyBJUFIgY2xhaW0gYWdhaW5zdCB0 aGlzIGRvY3VtZW50Lg0KPiA+DQo+ID4gVGhlIGF1dGhvcnMgaGFzIHN0YXRlZCBvbiB0aGUgd29y a2luZyBncm91cCBtYWlsaW5nIGxpc3QNCj4gPiB0aGF0IHRoZXkgYXJlIG5vdCBhd2FyZSBvZiBh bnkgb3RoZXIgSVBSIGNsYWltcyBhZ2FpbnN0IHRoaXMgZHJhZnQuDQo+ID4gSG93ZXZlciBpZiB5 b3UgYXJlIG9uIHRoZSB0aGUgbXBscyB3b3JraW5nIGdyb3VwIG1haWxpbmcgbGlzdCBhbmQNCj4g PiBhd2FyZSBvZiBJUFIgdGhhdCByZWxhdGVzIHRvIHRoaXMgZHJhZnQsIHRoZSB0aW1lIHRvIGRp c2Nsb3NlDQo+ID4gdGhpcyBpcyBub3cuDQo+ID4NCj4gPiAvTG9hDQo+ID4gKG1wbHMgd2cgY28t Y2hhaXIpDQo+ID4gLS0NCj4gPg0KPiA+DQo+ID4gTG9hIEFuZGVyc3NvbiAgICAgICAgICAgICAg ICAgICAgICAgIGVtYWlsOiBsb2FAbWFpbDAxLmh1YXdlaS5jb20NCj4gPiBTZW5pb3IgTVBMUyBF eHBlcnQgICAgICAgICAgICAgICAgICAgICAgICAgIGxvYUBwaS5udQ0KPiA+IEh1YXdlaSBUZWNo bm9sb2dpZXMgKGNvbnN1bHRhbnQpICAgICBwaG9uZTogKzQ2IDczOSA4MSAyMSA2NA0KPiA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gbXBscyBt YWlsaW5nIGxpc3QNCj4gPiBtcGxzQGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9tcGxzDQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPiBtcGxzIG1haWxpbmcgbGlzdA0KPiA+IG1wbHNAaWV0Zi5v cmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMNCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gbXBscyBtYWls aW5nIGxpc3QNCj4gbXBsc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL21wbHMNCg== From jie.dong@huawei.com Sun Apr 14 21:45: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 043DC21F9183 for ; Sun, 14 Apr 2013 21:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[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 Sc7iEGDvrpet for ; Sun, 14 Apr 2013 21:45:43 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 31D4121F90CC for ; Sun, 14 Apr 2013 21:45:41 -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 ARV54219; Mon, 15 Apr 2013 04:45:40 +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, 15 Apr 2013 05:45:32 +0100 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 15 Apr 2013 05:45:35 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.76]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.01.0323.007; Mon, 15 Apr 2013 12:45:32 +0800 From: Jie Dong To: Loa Andersson , "mpls@ietf.org" Thread-Topic: [mpls] poll to see if we have consensus to make draft-villamizar-mpls-forwarding an MPLS wg document Thread-Index: AQHOLstqvddOtfUyf0qydDz/iwu9nJjWyZvw Date: Mon, 15 Apr 2013 04:45:31 +0000 Message-ID: <76CD132C3ADEF848BD84D028D243C927331B7E9C@nkgeml512-mbx.china.huawei.com> References: <51596E34.4020408@pi.nu> In-Reply-To: <51596E34.4020408@pi.nu> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.194.242] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "draft-villamizar-mpls-forwarding@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus to make draft-villamizar-mpls-forwarding 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, 15 Apr 2013 04:45:44 -0000 Support. Best regards, Jie > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of > Loa Andersson > Sent: Monday, April 01, 2013 2:24 PM > To: mpls@ietf.org > Cc: draft-villamizar-mpls-forwarding@tools.ietf.org; mpls-chairs@tools.ie= tf.org > Subject: [mpls] poll to see if we have consensus to make > draft-villamizar-mpls-forwarding an MPLS wg document >=20 > Working Group, >=20 > This is to start a two week poll on adopting > draft-villamizar-mpls-forwarding-02 as an MPLS working group document. >=20 > Please send your comments (support/not support) to the mpls working group > mailing list (mpls at ietf.org). Please give a technical motivation for y= our > support/not support, especially if you think that the document should not= be > adopted as a working group document. >=20 > This poll ends April 15, 2013. >=20 > There are no IPR claim against this document. >=20 > The authors has stated on the working group mailing list that they are no= t > aware of any other IPR claims against this draft. > However if you are on the the mpls working group mailing list and aware o= f IPR > that relates to this draft, the time to disclose this is now. >=20 > /Loa > (mpls wg co-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 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls From rajiva@cisco.com Mon Apr 15 13: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 4F89121F93E5 for ; Mon, 15 Apr 2013 13:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, 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 fliq3kU2RaW6 for ; Mon, 15 Apr 2013 13:04:16 -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 0CA0121F93C6 for ; Mon, 15 Apr 2013 13:04:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9417; q=dns/txt; s=iport; t=1366056256; x=1367265856; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=yF0v5eSzbhx0/VciR+Totyse4zCRvi2PDj/P1uKftvc=; b=TjcZ1vAqAkaoFl9pW89g2GzlRDaDjeMLP5PzKrXY6MZRfnkS7WVTP+EK CnCvPJYN5WwnuTZwLtINEtw/V0WlsRjVpjJrY0AK+Tt+pAilFK7VB+gf1 3slKKQD30ucumlTpP5tfUbOAgULp7vmzRT4yMJjqRz1iqvguMJmnlQXVP A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFACRcbFGtJXG8/2dsb2JhbABQgwbBOoEHFnSCHwEBAQRrDg4EAQgYCh0iFxQRAgQOBQiIDLtvBI1RgRExB4JgYQOoFoMLgXM1 X-IronPort-AV: E=Sophos;i="4.87,479,1363132800"; d="scan'208";a="196054185" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-9.cisco.com with ESMTP; 15 Apr 2013 20:04:15 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r3FK4FNS031771 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 15 Apr 2013 20:04:15 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.247]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Mon, 15 Apr 2013 15:04:15 -0500 From: "Rajiv Asati (rajiva)" To: Loa Andersson , "draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry@tools.ietf.org" Thread-Topic: MPLS-RT review of draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-00.txt Thread-Index: AQHOK8DlhBRuYYpSS0ez0ec0g6aMU5jXvIQA Date: Mon, 15 Apr 2013 20:04:14 +0000 Message-ID: In-Reply-To: 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.21.66.109] Content-Type: text/plain; charset="Windows-1252" Content-ID: <017316A37476D049927195514AB6121E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , Lizhong Jin , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-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: Mon, 15 Apr 2013 20:04:17 -0000 Hi, I have reviewed this draft and found it ready for the WG adoption. No doubt that it is useful in the context of LSP Pings. I do have a two Q for the authors and a comment/suggestion - 1. what's the rationale for including section 3.3.2 and 3.3.3> I suggest moving them to the appendix (since there is nothing new in there). 2. Shouldn't there be some text that discussed any possible challenges with having reusable sub-TLVs (with exact meaning) that may be defined in the future, given that RFC4379 implicitly prohibited such a re-usage? I do think that this draft could benefit from several editorial changes (especially in section 2 and 3) to make it concise and clear. I have taken the liberty of suggesting the text for section 1, 2 and 3 along for your consideration (and moving some of the text into the Appendix). Of course, this document MUST mention updating RFC4379 at various places (e.g. header, abstract, introduction). Cheers, Rajiv PS: Suggested text for section 1, 2 and 3 1. Introduction=20 This document revises the structure and allocation policies in the use of the TLVs and sub-TLVs of the MPLS LSP Ping Parameters, as defined in [RFC4379]. =20 This document specifies that the future allocations of sub-TLVs (aka sub-types) will come from a single namespace that is common to all TLVs of MPLS LSP Ping Parameters, thereby allowing the re-usage of future sub-TLVs, and mandates the sub-type value greater than 32 to be used for any future allocations. The document that specifies any future allocation should state which all TLVs the sub-TLV may appear under and indicate any other future use which seems appropriate or inappropriate. This document does not change any existing allocations for TLVs and sub-TLVs (aka Type and Sub-type) of [RFC4379] and maintains their structure e.g. sub-TLV 1 (or any allocated sub-TLVs) continues to be dependent on the TLV under which it appears, to ensure the backward compatibility. 2. Current Sub-TLV Allocation & Registry 2.1 Current Sub-TLV (and TLV) Allocations Currently, the allocation policy by IANA for all TLVs and sub-TLVs is the same, as illustrated by the table 2 below. Note that the table is meant to illustrate the allocation policy as described in RFC4379 section 7.2. What's not clear in the above allocation policy is that [RFC4379] also specified the sub-TLVs to be scoped by the TLVs, i.e. A sub-TLV defined for one TLV was valid for that TLV only. This has become somewhat confusing, since the practice to re-use sub-TLV value(s) defined for one TLV for another TLV with the same meaning has been introduced since the publication of RFC4379. 2.2 Current Sub-TLV (and TLV) Registry Structure Currently, all TLVs and sub-TLVs are found in a single registry, as illustrated in the table 1 below. Note that the table is meant to illustrate the allocation policy as described in RFC4379 section 7.2 and other RFCs that updated RFC4379. =20 We have chosen not to just copy the current registry here, but instead build a model that shows how the allocation policies work.
Please see the appendix for understanding this model row-by-row (row numbers appear on the right most column). 2.3 Current Sub-TLV Allocation & Structure - Issues (I) Confusion : A single registry table illustrated above might have been a good idea early on, but over time, with an increasing number of TLVs, and with few sub-TLV values shared across TLVs, it has become increasingly difficult (or confusing) to understand how the allocation policies interact and the meaning of a sub-TLV value without knowing the parent TLV. Consider these two examples : - TLVs Types 1, 16 and 21 reuse sub-TLV 1 with the same meaning. - sub-TLV 1 appears under TLV Type 1 as LDP IPv4 Prefix, under TLV Type 11 as IPv4 Egress Address P2MP Responder and under TLV Type 20 as Multipath data.=20 One must rely on careful reading of [RFC4379] and other RFCs that updated it to sort out the confusion. (II) Large sub-TLV value range - The current name space of sub-TLVs (65 535 potential TLVs times 65 535 sub-TLVs per TLV) is a maximum of 4 294 836 335 sub-TLVs. This is way to large space. There seems no reason why that number of sub-TLVs should be needed;rather, 65 535 sub-TLVs shared among all TLVs would seem to have been more than sufficient. 3. New sub-TLV Allocation & Registry Structure This draft prescribes having one IANA registry for TLVs and another for sub-TLVs to benefit the future allocations & registration of sub-TLVs. In other words, the future policy for the registration of sub-TLVs is to have a single registry regardless of which TLV the sub-TLV appears under. This would result in registries and allocation policies that are much easier to understand and comprehend (and avoid confusion). For example, a sub-TLV (to be) defined for an IPv6 address can be used wherever such an address is required e.g. in any TLV. 3.1 New TLV Allocation & Registry Structure As illustrated below, the new TLV registry follows the same pattern as that of the existing registries. < table showing TLV allocation > Please see the Appendix XYZ for the current (LSP Ping) TLV allocations in the IANA registry so far as of January 2013. 3.2 New sub-TLV Allocation & Registry Structure As illustrated below, the new sub-TLV registry follows the same pattern as that of the existing registries with an exception that range 0 to 31 is not reserved and MUST NOT be assigned lest there is an overlap with existing definitions. choice of 32 is somewhat greater than the greatest, existing, defined sub-TLV, 25 for TLV Type 1, and is chosen to be a more user-friendly, easier to remember, number than, say, 26 or 29. < table showing sub-TLV allocation> Please see the Appendix XYZ for the current sub-TLV allocations for TLV Type=3D1 in the IANA registry so far as of January 2013. 4. Security =8A /// ~~~~~~~~~~~~~ If you consider the above text, then please ignore the below comments (as I thought that it would be easier to rewrite these sections than add comments one-by-one): 0) Reference to 'IANA registry' is mentioned at several places, without including the relevant informative reference. I suggest to include that and update. 1) Section 2 refers to 'a single table', but doesn't specify what this single table is. I suggest using 'a single IANA registry table' 2) Section 2 - This could benefit from reorganization of the text quite a bit.=20 * Section 2.1 Change the title to 'Current Sub-TLV Allocation & Structure' * Section 2.2 change the title to 'Current Sub-TLV Allocation & Structure - Issues'=20 * Move section 2.3 into the Appendix 3) The first few paras of section 3.1 well clarify the problem and I would suggest to move it early on in section 2. 4) Section 2.1 - It would be good to add a reference to section 7.2 of RFC4379 5) section 2.2 - change title to "Current Model - Allocation policies and Scope // [RFC4379] also says that the sub-TLVs are scoped by the TLVs, i.e. a sub-TLV defined for one TLV is valid for that TLV only. Later the practice to re-define (a block of) sub-TLVs defined for one TLV for another TLV was introduced. // The above para doesn't parse well. Did you mean to say re-use instead of re-define? Also, it seems to suggest that RFC4379 later introduced the practice of re-using... Could it instead be rephrased to read - [RFC4379] also suggested that the sub-TLVs were scoped by the TLVs, i.e. a sub-TLV defined for one TLV was valid for that TLV only. This has become incorrect, since the practice to re-use (a block of) sub-TLV values defined for one TLV for another TLV has been introduced since the publication of RFC4379. > >On Tue, Mar 12, 2013 at 2:04 AM, Loa Andersson > wrote: > > >Dan, Xu, Lizhong and Rajiv, > >You have been selected as an MPLS Review team reviewers for >draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-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 April 2, 2013? > >Thanks, Loa >(as MPLS WG chair) > >/Loa >--=20 > > >Loa Andersson email: >loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consult) phone: >+46 739 81 21 64 > > > > > > From loa@pi.nu Mon Apr 15 18:06: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 8677921F9436 for ; Mon, 15 Apr 2013 18:06:33 -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 d+XYGDSDiU5y for ; Mon, 15 Apr 2013 18:06:32 -0700 (PDT) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id 4598821F9434 for ; Mon, 15 Apr 2013 18:06:31 -0700 (PDT) Received: from [10.5.7.46] (unknown [202.106.79.10]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.pi.nu (Postfix) with ESMTPSA id 71660823B5; Tue, 16 Apr 2013 03:06:23 +0200 (CEST) Message-ID: <516CA40C.6010409@pi.nu> Date: Tue, 16 Apr 2013 03:06:20 +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: <51596E34.4020408@pi.nu> In-Reply-To: <51596E34.4020408@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "draft-villamizar-mpls-forwarding@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Subject: Re: [mpls] poll to see if we have consensus to make draft-villamizar-mpls-forwarding 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, 16 Apr 2013 01:06:33 -0000 Working Group, this poll has ended - and we have a new working group document. Could the authors please republish the draft as: draft-ietf-mpls-forwarding-00 without any other changes than the administrative info (date, version number, etc) as compared to the draft we polled. /Loa for the wg co-chairs On 2013-04-01 13:23, Loa Andersson wrote: > Working Group, > > This is to start a two week poll on adopting > draft-villamizar-mpls-forwarding-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 April 15, 2013. > > There are no IPR claim against this document. > > 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 eosborne@cisco.com Tue Apr 16 05:15: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 28D6C21F96DD for ; Tue, 16 Apr 2013 05:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.396 X-Spam-Level: X-Spam-Status: No, score=-6.396 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 qtqm7Z6dT2PN for ; Tue, 16 Apr 2013 05:15:14 -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 13C4A21F96DA for ; Tue, 16 Apr 2013 05:15:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6250; q=dns/txt; s=iport; t=1366114514; x=1367324114; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=YiJZgyzb+m22bgyHtRcgTtYltAGAs/4ce4kaFhlcV2o=; b=m8cfB3FMUdGGAL8OaLhvU3Hujv9Sjn0Kla2cwRdfU0O2jWmfw0lJKpO8 TbsnysnHgoKmU9sL2Sh6AomdY0QcBFyatsGrXOkO99tKJsPB8mkL+0oTg YpQ4AbueJ4rGzdRhdVTmpYgIYIaFd8V3YjR5x14GjDtOZykPY7zXpkTY4 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikFAI0/bVGtJV2c/2dsb2JhbABQgwY2wQYNfxZ0gh8BAQEENDoLDAYBBgIRBAEBCyYfER0JAQQOBQgTh2cDDwyOeJ1Ehl0NiV2MPIIiJgsNglthA5UigwaKVYUcgwuCKA X-IronPort-AV: E=Sophos;i="4.87,485,1363132800"; d="scan'208";a="199283716" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 16 Apr 2013 12:15:13 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r3GCFDui032764 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 16 Apr 2013 12:15:13 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.83]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Tue, 16 Apr 2013 07:15:12 -0500 From: "Eric Osborne (eosborne)" To: "mpls@ietf.org" Thread-Topic: Resolving the most recent ITU liaison statement on PSC Thread-Index: Ac4fbEFygXKfAcxcSDOcaerIb5nsSgbLE8Aw Date: Tue, 16 Apr 2013 12:15:12 +0000 Message-ID: <20ECF67871905846A80F77F8F4A275721014F115@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.86.253.4] Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "Huub van Helvoort \(huubatwork@gmail.com\)" Subject: Re: [mpls] Resolving the most recent ITU liaison statement on 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: Tue, 16 Apr 2013 12:15:15 -0000 V0ctDQoNCiAgVGhlIG1pbmkgcmV2aWV3IHRlYW0gaGFzIGdvbmUgb3ZlciB0aGUgZHJhZnRzIG1l bnRpb25lZCBpbiB0aGlzIHRocmVhZC4gIFdlIGdlbmVyYWxseSBhZ3JlZWQgdGhhdCB0aGUgZm91 ciBkcmFmdHMgdW5kZXIgZGlzY3Vzc2lvbiBhZGRyZXNzIHRoZSByZXF1aXJlbWVudHMgdGhleSBp bnRlbmQgdG8gcmVxdWVzdCwgc28gSSB0aGluayBpdCdzIGEgZ29vZCBpZGVhIHRvIGJyaW5nIHRo ZSBkcmFmdHMgdG8gdGhlIFdHIGZvciBicm9hZGVyIGRpc2N1c3Npb24uICBJJ20gZ29pbmcgdG8g c3RhcnQgZm91ciBzZXBhcmF0ZSB0aHJlYWRzLCBvbmUgb24gZWFjaCBkcmFmdC4gIElmIHRoZXJl J3Mgb25lIHRoaW5nIEkga25vdyB0aGUgSUVURiBpcyByaWZlIHdpdGggaXQncyBvcGluaW9ucywg c28gcGxlYXNlIHBhcnRpY2lwYXRlOyBJJ2QgaGF0ZSB0byBzZWUgdXMgY29tZSB0byBjbG9zdXJl IG9uZSB3YXkgb3IgdGhlIG90aGVyIGFzIGEgcmVzdWx0IG9mICJtZWgiIHJhdGhlciB0aGFuIGRp c2N1c3Npb24uDQoNCg0KDQoNCmVyaWMNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IEVyaWMgT3Nib3JuZSAoZW9zYm9ybmUpDQo+IFNlbnQ6IFR1ZXNkYXksIE1hcmNo IDEyLCAyMDEzIDY6MTQgUE0NCj4gVG86IG1wbHNAaWV0Zi5vcmcNCj4gQ2M6IEh1dWIgdmFuIEhl bHZvb3J0IChodXViYXR3b3JrQGdtYWlsLmNvbSk7IE1hbGNvbG0uQkVUVFNAenRlLmNvbS5jbjsN Cj4gU2NvdHQgTWFuc2ZpZWxkOyBZb3NoaW5vcmkgS29pa2U7IEQnQWxlc3NhbmRybyBBbGVzc2Fu ZHJvIEdlcmFyZG8NCj4gKGFsZXNzYW5kcm8uZGFsZXNzYW5kcm9AdGVsZWNvbWl0YWxpYS5pdCk7 IMGkxcK9xDsgJ1J5b28sIEplb25nLWRvbmcnOyBZYWFjb3YNCj4gV2VpbmdhcnRlbiAod3lhYWNv dkBnbWFpbC5jb20pOyBZdWppIFRvY2hpbw0KPiBTdWJqZWN0OiBSZXNvbHZpbmcgdGhlIG1vc3Qg cmVjZW50IElUVSBsaWFpc29uIHN0YXRlbWVudCBvbiBQU0MNCj4gDQo+IFdHLQ0KPiANCj4gICBB cyB5b3UgcHJvYmFibHkga25vdywgdGhlcmUgaGF2ZSBiZWVuIGEgc2VyaWVzIG9mIGxpYWlzb24g c3RhdGVtZW50cw0KPiBleGNoYW5nZWQgYmV0d2VlbiB0aGUgSVRVIGFuZCB0aGUgTVBMUyBXRyBv biBQU0MuICBUaGUgbW9zdCByZWNlbnQgTFMgaXMNCj4gdGhpcyBvbmU6DQo+IGh0dHA6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9saWFpc29uLzEyMzQvDQo+IA0KPiBhbmQgdGhlIGluZGV4IG9mIGFs bCBvZiB0aGVtIGlzIGhlcmU6DQo+IGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9saWFpc29u Lw0KPiANCj4gKEkgd2lsbCByZWZlciB0byB0aGUgbW9zdCByZWNlbnQgbGlhaXNvbiBhcyBMUzAw NSBhcyB0aGF0J3Mgd2hhdCB0aGUgSVRVIGNhbGxlZCBpdCkNCj4gDQo+IExTMDA1IHJhaXNlZCB0 ZW4gcG9pbnRzIHRoYXQgd2UgbmVlZCB0byBjb21lIHRvIGNsb3N1cmUgb24uICAnY29tZSB0byBj bG9zdXJlJw0KPiBkb2VzIG5vdCBtZWFuICJhZ3JlZSB0byBpbXBsZW1lbnQiIG9yICJkaWcgaW4g YWdhaW5zdCIuICBJdCBtZWFucyAiYXMgYSBXRywNCj4gZmlndXJlIG91dCB3aGF0LCBpZiBhbnl0 aGluZywgd2Ugc2hvdWxkIGRvIHdpdGggdGhvc2UgcG9pbnRzIi4NCj4gDQo+IEEgbnVtYmVyIG9m IHVzIG1ldCBlYXJsaWVyIHRvZGF5IHRvIGRpc2N1c3MgdGhlIHRlbiBwb2ludHMgYW5kIHZhcmlv dXMgZHJhZnRzDQo+IGFuZCBzdGVwcyBiZWluZyB0YWtlbi4gIEhlcmUncyB3aGVyZSB3ZSBzdGFu ZCAodGhhbmtzIHRvIEplb25nLURvbmcgZm9yIHRoZQ0KPiBsaXN0KToNCj4gDQo+IC0gUG9pbnQg MTogZHJhZnQtcmhkLW1wbHMtdHAtcHNjLXByaW9yaXR5LTAwIChzdWJtaXR0ZWQgaW4gMjAxMy0w Mi0xOCkNCj4gLSBQb2ludCAyOiBkcmFmdC1vc2Jvcm5lLW1wbHMtcHNjLXVwZGF0ZXMtMDAgKHN1 Ym1pdHRlZCBpbiAyMDEzLTAyLTExKQ0KPiAtIFBvaW50IDM6IGRyYWZ0LWRqLW1wbHMtdHAtZXhl ci1wc2MtMDAgKHN1Ym1pdHRlZCBpbiAyMDEzLTAyLTEzKQ0KPiAtIFBvaW50IDQ6IGRyYWZ0LXJo ZC1tcGxzLXRwLXBzYy1zZC0wMCAoc3VibWl0dGVkIGluIDIwMTMtMDMtMTIpDQo+IC0gUG9pbnQg NTogTm90IGFuIGlzc3VlIGFueSBtb3JlDQo+IC0gUG9pbnQgNjogTm90IGFuIGlzc3VlIGFueSBt b3JlDQo+IC0gUG9pbnQgNzogVG8gYmUgY292ZXJlZCBpbiBkcmFmdC1vc2Jvcm5lLW1wbHMtcHNj LXVwZGF0ZXMtMDENCj4gLSBQb2ludCA4OiBkcmFmdC1vc2Jvcm5lLW1wbHMtcHNjLXVwZGF0ZXMt MDAgKHN1Ym1pdHRlZCBpbiAyMDEzLTAyLTExKQ0KPiAtIFBvaW50IDk6IGRyYWZ0LXJoZC1tcGxz LXRwLXBzYy1wcmlvcml0eS0wMCAoc3VibWl0dGVkIGluIDIwMTMtMDItMTggdG8gc3VwcG9ydA0K PiBGcmVlemUpDQo+ICAgICAgICAgICAgICAgIGRyYWZ0LWNkaC1tcGxzLXRwLXBzYy1ub24tcmV2 ZXJ0aXZlLTAwICh3aWxsIGJlIHN1Ym1pdHRlZCBpbiAyMDEzLTAzLQ0KPiAxMSB0byBzdXBwb3J0 IE1TLVcNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYW5kIGZ1cnRoZXIgY2xhcmlmeSB0aGUg bm9uLQ0KPiByZXZlcnRpdmUgb3BlcmF0aW9uKQ0KPiAtIFBvaW50IDEwOiBkcmFmdC1yaGQtbXBs cy10cC1wc2MtcHJpb3JpdHktMDAgKHN1Ym1pdHRlZCBpbiAyMDEzLTAyLTE4KQ0KPiANCj4gSXQg d29ya3Mgb3V0IGxpa2UgdGhpczoNCj4gLSB0d28gcG9pbnRzICg1LCA2KSBhcmUgbm9uaXNzdWVz DQo+IC0gdHdvIHBvaW50cyAoMiwgOCkgYXJlIGFkZHJlc3NlZCBpbiBkcmFmdC1vc2Jvcm5lLW1w bHMtcHNjLXVwZGF0ZXMtMDAgd2hpY2ggSQ0KPiBwcmVzZW50ZWQgeWVzdGVyZGF5DQo+IC0gdGhl IHJlbWFpbmluZ3Mgc2l4IHBvaW50cyBhcmUgY292ZXJlZCBpbiB0aGUgZm91ciByZW1haW5pbmcg ZHJhZnRzDQo+IA0KPiBUaGVzZSBkcmFmdHMgbmVlZCB0byBiZSByZWFkIGFuZCBjb21tZW50ZWQg dXBvbi4gIFdlIGhhdmUgYSBzbWFsbCBncm91cCBvZg0KPiBpbnRlcmVzdGVkIHBhcnRpZXMgdGhh dCBuZWVkIHRvIHJlYWQgdGhlbSBhbGwgYW5kIG1ha2Ugc3VyZSB0aGF0IHRoZXkncmUgc291bmQu DQo+IFRoZSBnb2FsIG9mIHRoaXMgZ3JvdXAgaXMgKm5vdCogdG8gZGVjaWRlIHdoZXRoZXIgdGhl IHNvbHV0aW9ucyBhcmUgcmlnaHQgb3INCj4gd3JvbmcsIG9yIGV2ZW4gd2hldGhlciB0aGUgcHJv YmxlbXMgdGhleSBhZGRyZXNzIHNob3VsZCBiZSBzb2x2ZWQuICBUaGluayBvZg0KPiBpdCBhcyBh IG1pbmktcmV2aWV3IHRlYW0gdGhhdCB3aWxsIGdvIG92ZXIgdGhlIGRyYWZ0cyB0byBtYWtlIHN1 cmUgdGhleSBhcmUNCj4gY29oZXJlbnQgYW5kIGFkZHJlc3MgdGhlIHByb2JsZW0ocykgdGhleSBw dXJwb3J0IHRvIGFkZHJlc3MuDQo+IA0KPiBPbmNlIHRoYXQgaXMgZG9uZSAoaG9wZWZ1bGx5IG5l eHQgd2VlaywgbWF5YmUgdGhlIHdlZWsgYWZ0ZXIpLCBhc3N1bWluZyB0aGUNCj4gZHJhZnRzIGFy ZSBzb3VuZCB3ZSB3aWxsIHN0YXJ0IHRocmVhZHMgb24gdGhlIG1haWxpbmcgbGlzdCwgb25lIGZv ciBlYWNoIGRyYWZ0LCB0bw0KPiBkaXNjdXNzIHRoZSBwcm9ibGVtIGFuZCBwcm9wb3NlZCBzb2x1 dGlvbi4gIFRoaXMgbWFrZXMgaXQgZWFzeSBmb3IgYW55b25lIHRvDQo+IGZpbHRlciBvdXQgdGhl IHRocmVhZHMgdGhleSBkb24ndCB3YW50IGFuZCB0byBwYXkgcmFwdCBhdHRlbnRpb24gdG8gdGhl IG9uZXMgdGhleQ0KPiBkby4NCj4gDQo+IFJpZ2h0IG5vdywgdGhlIGVuZCBnb2FsIGlzIHRvIHBy b2R1Y2UgYSBzaW5nbGUgZG9jdW1lbnQgd2hpY2ggaW5jb3Jwb3JhdGVzIGFsbA0KPiBvZiB0aG9z ZSBkcmFmdHMgc28gdGhhdCB3ZSBvbmx5IGhhdmUgdG8gdG91Y2ggUFNDIG9uY2UuICBUaGF0IG1h eSBvciBtYXkgbm90DQo+IGhhcHBlbiBkZXBlbmRpbmcgb24gd2hldGhlciB0aGUgZG9jcyBtb3Zl IGZvcndhcmQgYXQgdGhlIHNhbWUgcmF0ZSwgd2UnbGwNCj4gaGF2ZSB0byBmaWd1cmUgdGhhdCBw YXJ0IG91dCBhcyB3ZSBnZXQgdGhlcmUuDQo+IA0KPiBUaGUgY3VycmVudCBsaXN0IG9mIG1pbmkt cmV2aWV3IHRlYW0gbWVtYmVycyBpcyBjYydkLiAgV291bGQgYW55b25lIGVsc2UgbGlrZQ0KPiB0 byBiZSBvbiB0aGlzIGxpc3Q/ICAoWWFhY292LCBJIGFzc3VtZSB5b3Ugd291bGQgbGlrZSB0byBi ZSB0aGVyZSkuICBJIHBsYW4gdG8gc3RhcnQNCj4gdGhlIHRocmVhZCBlYXJseSBuZXh0IHdlZWsg c28gcGxlYXNlIHRyeSB0byBsZXQgbWUga25vdyBieSB0aGVuLCBidXQgbGF0ZXIgaXMNCj4gYWx3 YXlzIGJldHRlciB0aGFuIG5ldmVyLiAgSXQgc2hvdWxkbid0IGJlIHRoYXQgbXVjaCB3b3JrICho YWghKSwgd2UgaW50ZW5kIGZvcg0KPiB0aGUgdmFzdCBtYWpvcml0eSBvZiB0aGUgdGVjaG5pY2Fs IGRpc2N1c3Npb24gdG8gaGFwcGVuIG9uIHRoZSBtYWlsaW5nIGxpc3QuDQo+IA0KPiBUaGFua3Mg dG8gZXZlcnlvbmUgd2hvIG1ldCB0aGlzIGFmdGVybm9vbiENCj4gDQo+IA0KPiANCj4gDQo+IGVy aWMNCg== From ietfc@btconnect.com Tue Apr 16 10:22: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 E65E221F9725 for ; Tue, 16 Apr 2013 10:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_66=0.6, 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 RP16M41t0f0c for ; Tue, 16 Apr 2013 10:22:28 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 6F32A21F971D for ; Tue, 16 Apr 2013 10:22:28 -0700 (PDT) Received: from mail109-ch1-R.bigfish.com (10.43.68.252) by CH1EHSOBE015.bigfish.com (10.43.70.65) with Microsoft SMTP Server id 14.1.225.23; Tue, 16 Apr 2013 17:22:27 +0000 Received: from mail109-ch1 (localhost [127.0.0.1]) by mail109-ch1-R.bigfish.com (Postfix) with ESMTP id A3A9B360422; Tue, 16 Apr 2013 17:22:27 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.250.69; KIP:(null); UIP:(null); IPV:NLI; H:AMXPRD0711HT002.eurprd07.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -16 X-BigFish: PS-16(zz98dI9371I542I1432I4015I15c7mzz1f42h1fc6h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ahzz1033IL8275bh8275dhz2dh2a8h5a9h668h839h946hd24hf0ah1177h1179h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1758h17f1h184fh1898h18e1h1946h19b5h19ceh1ad9h1b0ah304l1155h) Received: from mail109-ch1 (localhost.localdomain [127.0.0.1]) by mail109-ch1 (MessageSwitch) id 1366132944776291_4134; Tue, 16 Apr 2013 17:22:24 +0000 (UTC) Received: from CH1EHSMHS002.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.247]) by mail109-ch1.bigfish.com (Postfix) with ESMTP id BAB8220060; Tue, 16 Apr 2013 17:22:24 +0000 (UTC) Received: from AMXPRD0711HT002.eurprd07.prod.outlook.com (157.56.250.69) by CH1EHSMHS002.bigfish.com (10.43.70.2) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 16 Apr 2013 17:22:24 +0000 Received: from AMXPRD0111HT001.eurprd01.prod.exchangelabs.com (157.56.250.117) by pod51017.outlook.com (10.242.9.163) with Microsoft SMTP Server (TLS) id 14.16.293.5; Tue, 16 Apr 2013 17:22:23 +0000 Message-ID: <03fe01ce3ac6$4bad3060$4001a8c0@gateway.2wire.net> From: t.petch To: "Rajiv Asati (rajiva)" , Loa Andersson References: Date: Tue, 16 Apr 2013 17:48:13 +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-SourceIpAddress: 157.56.250.69 X-FOPE-CRA-DRYRUN: 1207119;1 X-FOPE-BFA-SENDER: ietfc@btconnect.com X-FOPE-BFA-RECEIVER: lizho.jin@gmail.com X-FOPE-BFA-RECEIVER: mach.chen@huawei.com X-FOPE-BFA-RECEIVER: mpls@ietf.org X-FOPE-BFA-RECEIVER: rajiva@cisco.com X-FOPE-BFA-RECEIVER: loa@pi.nu Content-Transfer-Encoding: quoted-printable X-OriginatorOrg: btconnect.com Cc: mpls , Lizhong Jin Subject: Re: [mpls] MPLS-RT review of draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-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, 16 Apr 2013 17:22:30 -0000 Rajiv Thank you for your careful review; some thoughts inline. Tom Petch ----- Original Message ----- From: "Rajiv Asati (rajiva)" To: "Loa Andersson" ; Cc: ; "Lizhong Jin" ; Sent: Monday, April 15, 2013 9:04 PM Hi, I have reviewed this draft and found it ready for the WG adoption. No doubt that it is useful in the context of LSP Pings. I do have a two Q for the authors and a comment/suggestion - 1. what's the rationale for including section 3.3.2 and 3.3.3> I suggest moving them to the appendix (since there is nothing new in there). Don't know - the I-D could just be Section 5 and, having been immersed in this for two years, would be all I would need right now. But in future, trying to sort out what came from where, I would probably value those sections, along with 3.3.4, to refresh my memory. I am unsure what challenges you have in mind. If a reusable sub-TLV is imprecisely defined, then it could be (mis-)used in different ways, or perhaps even if it were precisely defined. Is this an IPv4 address, or a 32-bit dotted decimal Area ID from OSPF? That debate has taken place on other lists and I think the key is getting a decent definition to start with, being reviewed by people with a wide enough background. At present, we do have a strong wish to reuse, as where the sub-TLVs of TLV Type 1 are needed in several places, so I incline towards being flexible. I do think that this draft could benefit from several editorial changes (especially in section 2 and 3) to make it concise and clear. I have taken the liberty of suggesting the text for section 1, 2 and 3 along for your consideration (and moving some of the text into the Appendix). Of course, this document MUST mention updating RFC4379 at various places (e.g. header, abstract, introduction). Whoops Cheers, Rajiv PS: Suggested text for section 1, 2 and 3 1. Introduction This document revises the structure and allocation policies in the use of the TLVs and sub-TLVs of the MPLS LSP Ping Parameters, as defined in [RFC4379]. This document specifies that the future allocations of sub-TLVs (aka sub-types) will come from a single namespace that is common to all TLVs of MPLS LSP Ping Parameters, thereby allowing the re-usage of future sub-TLVs, and mandates the sub-type value greater than 32 to be used for any future allocations. This seems to me not just editorial. The intent of the I-D is that new allocations start with 32, not greater than 32; if that is unclear, then yes, an editorial change is required. The document that specifies any future allocation should state which all TLVs the sub-TLV may appear under and indicate any other future use which seems appropriate or inappropriate. This seems to me not just editorial, making it "all TLVs" is nailing things down more than I would want. Currently we have a rigid policy and the result is complexity; I would not want to preclude people from seeing a good use that was never anticipated by the first definer of a sub-TLV. Any I-D proposing any use is likely to be reviewed on this list which I trust to catch any misuse. This document does not change any existing allocations for TLVs and sub-TLVs (aka Type and Sub-type) of [RFC4379] and maintains their structure e.g. sub-TLV 1 (or any allocated sub-TLVs) continues to be dependent on the TLV under which it appears, to ensure the backward compatibility. 2. Current Sub-TLV Allocation & Registry 2.1 Current Sub-TLV (and TLV) Allocations Currently, the allocation policy by IANA for all TLVs and sub-TLVs is the same, as illustrated by the table 2 below. Note that the table is meant to illustrate the allocation policy as described in RFC4379 section 7.2.
What's not clear in the above allocation policy is that [RFC4379] also specified the sub-TLVs to be scoped by the TLVs, i.e. A sub-TLV defined for one TLV was valid for that TLV only. This has become somewhat confusing, since the practice to re-use sub-TLV value(s) defined for one TLV for another TLV with the same meaning has been introduced since the publication of RFC4379. 2.2 Current Sub-TLV (and TLV) Registry Structure Currently, all TLVs and sub-TLVs are found in a single registry, as illustrated in the table 1 below. Note that the table is meant to illustrate the allocation policy as described in RFC4379 section 7.2 and other RFCs that updated RFC4379. We have chosen not to just copy the current registry here, but instead build a model that shows how the allocation policies work.
Please see the appendix for understanding this model row-by-row (row numbers appear on the right most column). 2.3 Current Sub-TLV Allocation & Structure - Issues (I) Confusion : A single registry table illustrated above might have been a good idea early on, but over time, with an increasing number of TLVs, and with few sub-TLV values shared across TLVs, it has become increasingly difficult (or confusing) to understand how the allocation policies interact and the meaning of a sub-TLV value without knowing the parent TLV. Consider these two examples : - TLVs Types 1, 16 and 21 reuse sub-TLV 1 with the same meaning. - sub-TLV 1 appears under TLV Type 1 as LDP IPv4 Prefix, under TLV Type 11 as IPv4 Egress Address P2MP Responder and under TLV Type 20 as Multipath data. One must rely on careful reading of [RFC4379] and other RFCs that updated it to sort out the confusion. (II) Large sub-TLV value range - The current name space of sub-TLVs (65 535 potential TLVs times 65 535 sub-TLVs per TLV) is a maximum of 4 294 836 335 sub-TLVs. This is way to large space. There seems no reason why that number of sub-TLVs should be needed;rather, 65 535 sub-TLVs shared among all TLVs would seem to have been more than sufficient. 3. New sub-TLV Allocation & Registry Structure This draft prescribes having one IANA registry for TLVs and another for sub-TLVs to benefit the future allocations & registration of sub-TLVs. In other words, the future policy for the registration of sub-TLVs is to have a single registry regardless of which TLV the sub-TLV appears under. This would result in registries and allocation policies that are much easier to understand and comprehend (and avoid confusion). For example, a sub-TLV (to be) defined for an IPv6 address can be used wherever such an address is required e.g. in any TLV. 3.1 New TLV Allocation & Registry Structure As illustrated below, the new TLV registry follows the same pattern as that of the existing registries. < table showing TLV allocation > Please see the Appendix XYZ for the current (LSP Ping) TLV allocations in the IANA registry so far as of January 2013. 3.2 New sub-TLV Allocation & Registry Structure As illustrated below, the new sub-TLV registry follows the same pattern as that of the existing registries with an exception that range 0 to 31 is not reserved and MUST NOT be assigned lest there is an overlap with existing definitions. choice of 32 is somewhat greater than the greatest, existing, defined sub-TLV, 25 for TLV Type 1, and is chosen to be a more user-friendly, easier to remember, number than, say, 26 or 29. < table showing sub-TLV allocation> Please see the Appendix XYZ for the current sub-TLV allocations for TLV Type=3D1 in the IANA registry so far as of January 2013. 4. Security =8A /// ~~~~~~~~~~~~~ If you consider the above text, then please ignore the below comments (as I thought that it would be easier to rewrite these sections than add comments one-by-one): 0) Reference to 'IANA registry' is mentioned at several places, without including the relevant informative reference. I suggest to include that and update. yes, reference needed 1) Section 2 refers to 'a single table', but doesn't specify what this single table is. I suggest using 'a single IANA registry table' 2) Section 2 - This could benefit from reorganization of the text quite a bit. * Section 2.1 Change the title to 'Current Sub-TLV Allocation & Structure' * Section 2.2 change the title to 'Current Sub-TLV Allocation & Structure - Issues' * Move section 2.3 into the Appendix 3) The first few paras of section 3.1 well clarify the problem and I would suggest to move it early on in section 2. 4) Section 2.1 - It would be good to add a reference to section 7.2 of RFC4379 5) section 2.2 - change title to "Current Model - Allocation policies and Scope // [RFC4379] also says that the sub-TLVs are scoped by the TLVs, i.e. a sub-TLV defined for one TLV is valid for that TLV only. Later the practice to re-define (a block of) sub-TLVs defined for one TLV for another TLV was introduced. // The above para doesn't parse well. Did you mean to say re-use instead of re-define? Also, it seems to suggest that RFC4379 later introduced the practice of re-using... Could it instead be rephrased to read - [RFC4379] also suggested that the sub-TLVs were scoped by the TLVs, i.e. a sub-TLV defined for one TLV was valid for that TLV only. This has become incorrect, since the practice to re-use (a block of) sub-TLV values defined for one TLV for another TLV has been introduced since the publication of RFC4379. mmmmm yes it could be clearer but .. You are right to point out that we are not redefining sub-TLV Type values but then we are not reusing them either. RFC4379 is clear, that each TLV has its own namespace of sub-TLV Type values. What we are doing is reusing the definition of a sub-TLV and assigning it a new sub-TLV Type value under a different TLV. The fact that the old sub-TLV Type value is 'x' and the new sub-TLV Type value is also 'x' is most convenient for us; perhaps the authors of RFC4379 had this in mind when they limited the scope of sub-TLV Type values:-) >On Tue, Mar 12, 2013 at 2:04 AM, Loa Andersson > wrote: > > >Dan, Xu, Lizhong and Rajiv, > >You have been selected as an MPLS Review team reviewers for >draft-pac-mpls-lsp-ping-tlvs-and-sub-tlvs-registry-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 April 2, 2013? > >Thanks, Loa >(as MPLS WG chair) > >/Loa >-- >Loa Andersson email: >loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consult) phone: >+46 739 81 21 64 From davari@broadcom.com Tue Apr 16 13:34: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 7BC1321F9759 for ; Tue, 16 Apr 2013 13:34:46 -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 YZufy6ARRbEp for ; Tue, 16 Apr 2013 13:34:45 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCF921F971A for ; Tue, 16 Apr 2013 13:34:45 -0700 (PDT) Received: from [10.9.208.53] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Tue, 16 Apr 2013 13:29:15 -0700 X-Server-Uuid: 4500596E-606A-40F9-852D-14843D8201B2 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, 16 Apr 2013 13:34:29 -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, 16 Apr 2013 13:34:29 -0700 From: "Shahram Davari" To: "Kireeti Kompella" Thread-Topic: What is the Range of Special Labels in draft-kompella-mpls-special-purpose-labels? Thread-Index: Ac464NcO0glUm+GMQGGKNMjjGfPmjQ== Date: Tue, 16 Apr 2013 20:34:30 +0000 Message-ID: <4A6CE49E6084B141B15C0713B8993F281BDC3ADB@SJEXCHMB12.corp.ad.broadcom.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: 7D736B113942907942-01-01 Content-Type: multipart/alternative; boundary=_000_4A6CE49E6084B141B15C0713B8993F281BDC3ADBSJEXCHMB12corpa_ Cc: "mpls@ietf.org" , Loa Andersson Subject: [mpls] What is the Range of Special Labels in draft-kompella-mpls-special-purpose-labels? 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, 16 Apr 2013 20:34:47 -0000 --_000_4A6CE49E6084B141B15C0713B8993F281BDC3ADBSJEXCHMB12corpa_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Kireeti, I have a couple of questions regarding this draft. 1) What is the range of extended Special Purpose label suggested by th= is draft? Table 1 basically has all the labels in 2^10 range. Does the draf= t suggest that another RFC is required to define the Range? 2) Section 5.3 suggests that a label could be in Special Purpose regis= try but not in Extended Special purpose label space. This conflicts with se= ction 3.1 that suggests the Extended Range must include the Special purpose= labels. So which one is correct? Thanks Shahram From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Kir= eeti Kompella Sent: Tuesday, April 09, 2013 8:42 AM To: Ross Callon Cc: mpls@ietf.org; Loa Andersson Subject: Re: [mpls] IPR poll on draft-kompella-mpls-special-purpose-labels Not aware of any IPR related to this draft. Kireeti On Apr 9, 2013, at 8:10, "Ross Callon" > wrote: Working Group and authors; The authors of draft-kompella-mpls-special-purpose-labels have indicated that the draft is ready to be adopted as a working group document. Before starting the poll to see if there is wg consensus to make the draft a working group document we will do an IPR poll 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-kompella-mpls-special-purpos= e-labels? 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) --_000_4A6CE49E6084B141B15C0713B8993F281BDC3ADBSJEXCHMB12corpa_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Hi Kireeti,

 <= /p>

I have a couple of questi= ons regarding this draft.

 <= /p>

1) = ;     What is the range= of extended Special Purpose label suggested by this draft? Table 1 basical= ly has all the labels in 2^10 range. Does the draft suggest that another RFC is required to define the Range?

2) = ;     Section 5.3 sugge= sts that a label could be in Special Purpose registry but not in Extended S= pecial purpose label space. This conflicts with section 3.1 that suggests the Extended Range must include the Special purpose labe= ls. So which one is correct?

 <= /p>

Thanks<= /p>

Shahram=

 <= /p>

From: mpls-bou= nces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Kireeti Kompella
Sent: Tuesday, April 09, 2013 8:42 AM
To: Ross Callon
Cc: mpls@ietf.org; Loa Andersson
Subject: Re: [mpls] IPR poll on draft-kompella-mpls-special-purpose-= labels

 

Not aware of any IPR related to this draft. 

 

Kireeti

On Apr 9, 2013, at 8:10, "Ross Callon" <rcallon@juniper.net> wrote:

Working Group and authors;

 

The authors of draft-kompella-mpls-special-purpose-labels have indicated<= o:p>

that the draft is ready to be adopted as a working group document.

 

Before starting the poll to see if there is wg consensus to make the=

draft a working group document we will do an IPR poll 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-kompella-mpls-special-purp= ose-labels?

 

If so, has this IPR been disclosed in compliance with IETF IPR  rule= s

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

 

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<= /span>

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<= o:p>

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

 

 

Thanks, Ross

(as MPLS WG co-chair)

 

--_000_4A6CE49E6084B141B15C0713B8993F281BDC3ADBSJEXCHMB12corpa_-- From internet-drafts@ietf.org Tue Apr 16 22:08: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 4985A21F93B4; Tue, 16 Apr 2013 22:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.515 X-Spam-Level: X-Spam-Status: No, score=-102.515 tagged_above=-999 required=5 tests=[AWL=0.085, 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 JZ7T5wNw+oIC; Tue, 16 Apr 2013 22:08:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 68E8921F8991; Tue, 16 Apr 2013 22:08: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.43.p4 Message-ID: <20130417050813.32180.51304.idtracker@ietfa.amsl.com> Date: Tue, 16 Apr 2013 22:08:13 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-forwarding-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: Wed, 17 Apr 2013 05:08: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 : MPLS Forwarding Compliance and Performance Requirements Author(s) : Curtis Villamizar Kireeti Kompella Shane Amante Andrew Malis Carlos Pignataro Filename : draft-ietf-mpls-forwarding-00.txt Pages : 50 Date : 2013-04-16 Abstract: This document provides guidelines for implementors regarding MPLS forwarding and a basis for evaluations of forwarding implementations. Guidelines cover many aspects of MPLS forwarding. Topics are highlighted where implementors might potentially overlook practical requirements which are unstated or underemphasized or are optional for conformance to RFCs. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-forwarding There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-forwarding-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From eosborne@cisco.com Wed Apr 17 05:16: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 D594F21F8D46 for ; Wed, 17 Apr 2013 05:16:14 -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 UXLzgya5IVJQ for ; Wed, 17 Apr 2013 05:16:14 -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 3631B21F8C8C for ; Wed, 17 Apr 2013 05:16:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=905; q=dns/txt; s=iport; t=1366200974; x=1367410574; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=0iUxLclvlKn915zKUCnaT+Ui/wOg1ICrbMCzh1U7K3w=; b=fcO3YwIDNq8kqe+FRhfmXcaIID7Zv54F3AGTk4Bm2m6ztNwexNyHHSAk pkwsAqeaGsCx/f06HMJM2GKISaMBpG3v7xo3HIaGYN1J+hbnqa1s5Dy+K H3WRb6s5bALk5j9DFJLSS1Hlj1NACKAwVDGMlGtMDJa0CIIwY3ZBd80hx Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AicFAKqRblGtJV2c/2dsb2JhbABQgwY2gmq+IoEFFnSCIQEEOlEBKhRCJgEEG4gMDJwioR+NWIERgx1hA5gpj3GDC4FzNQ X-IronPort-AV: E=Sophos;i="4.87,492,1363132800"; d="scan'208";a="199557726" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 17 Apr 2013 12:16:13 +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 r3HCGDVi005749 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 17 Apr 2013 12:16:13 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; Wed, 17 Apr 2013 07:16:13 -0500 From: "Eric Osborne (eosborne)" To: "mpls@ietf.org" Thread-Topic: PSC: draft-rhd-mpls-tp-psc-priority-00 Thread-Index: Ac47ZD1tB/jb+CaKQqOehjxMIOgzIg== Date: Wed, 17 Apr 2013 12:16:13 +0000 Message-ID: <20ECF67871905846A80F77F8F4A2757210150296@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.66.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [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: Wed, 17 Apr 2013 12:16:15 -0000 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? =20 - 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 From eosborne@cisco.com Wed Apr 17 05:22: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 7646121F8D28 for ; Wed, 17 Apr 2013 05:22:10 -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 evufoHlF2rKg for ; Wed, 17 Apr 2013 05:22:09 -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 80DF921F8D29 for ; Wed, 17 Apr 2013 05:21:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=919; q=dns/txt; s=iport; t=1366201319; x=1367410919; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=b8fRpL1j+FgLIiOQAH7YrfzGFztqdUB++kLqUTN8Kk8=; b=gmWxeJZ5E+YKk0ZeLMlt5QNdeKr9VeMsEh/HtaugQj38FlUMs9cYw7ho tLJ7smMS51JYHVpBCwxkSW03bKyb0/prrET411n4MNN0mu6XR0Xnk0hGa LTLdGeNfV27LpDiaU0JMdhLDdOAG7iJTWz5nXnRNxzjw1DzbzVVouOY7s E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAPSRblGtJXG8/2dsb2JhbABQgwbBQoEFFnSCIQEEOlEBKhRCJgEEG4gMnC6hH45pgx1hA6gagwuCKA X-IronPort-AV: E=Sophos;i="4.87,492,1363132800"; d="scan'208";a="199838814" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 17 Apr 2013 12:21:59 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r3HCLx2E004599 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 17 Apr 2013 12:21:59 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.83]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Wed, 17 Apr 2013 07:21:58 -0500 From: "Eric Osborne (eosborne)" To: "mpls@ietf.org" Thread-Topic: PSC: draft-dj-mpls-tp-exer-psc Thread-Index: Ac47ZWRjRJBAvDu6T4ia+zSmFq3r6Q== Date: Wed, 17 Apr 2013 12:21:58 +0000 Message-ID: <20ECF67871905846A80F77F8F4A27572101502A9@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.66.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [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, 17 Apr 2013 12:22:10 -0000 This thread is for discussing draft-dj-mpls-tp-exer-psc. We started with -= 00, but there is now a -01. =20 The draft proposes adding the EXER/RR commands found in some ITU linear pro= tection protocols to PSC. =20 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 fa= r-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 awareness = through existing mechanisms? is this testing and awareness desirable or ne= cessary? but of course any and all discussion is welcome. eric From eosborne@cisco.com Wed Apr 17 05:26: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 89C4821F8A2A for ; Wed, 17 Apr 2013 05:26:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.498 X-Spam-Level: X-Spam-Status: No, score=-8.498 tagged_above=-999 required=5 tests=[AWL=2.102, 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 Xs0G9DEMTudZ for ; Wed, 17 Apr 2013 05:26:08 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id AB5F121F8A1B for ; Wed, 17 Apr 2013 05:26:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=808; q=dns/txt; s=iport; t=1366201566; x=1367411166; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=zCzaX2aD57Txz3cw4ZGiT+DCK8xk2TixwtQqm7MaCBY=; b=jKqhcJlbmr8afKZ9uscx2C235hPqUzUJmYxeVRi+PXyRmLWaoWFhslJh iUaSHN3DakP7Id3DxITDjXbQwR2CnPIMu+cmOjThUR4b1hzAZZ7Sb0YG9 ESRzO+P7QuIqMpV3Q3Behfn/tIge9mRPxNzUroO8I3ooZ1zHZBRlLo8Iv w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAPSRblGtJXG//2dsb2JhbABQgwbBQoEFFnSCIQEEOlEBKhRCJgEEG4gMnC6hH45pgx1hA6gagwuCKA X-IronPort-AV: E=Sophos;i="4.87,492,1363132800"; d="scan'208";a="199761297" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-5.cisco.com with ESMTP; 17 Apr 2013 12:26:06 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r3HCQ5D2002760 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 17 Apr 2013 12:26:05 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.83]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Wed, 17 Apr 2013 07:26:05 -0500 From: "Eric Osborne (eosborne)" To: "mpls@ietf.org" Thread-Topic: PSC: draft-rhd-mpls-tp-psc-sd-00 Thread-Index: Ac47ZjCR0vbHo3uJROyqNlG6qZXPnw== Date: Wed, 17 Apr 2013 12:26:04 +0000 Message-ID: <20ECF67871905846A80F77F8F4A27572101502B9@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.66.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mpls] PSC: draft-rhd-mpls-tp-psc-sd-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, 17 Apr 2013 12:26:09 -0000 This thread is for discussing draft-rhd-mpls-tp-psc-sd-00. The draft provi= ded extensions to the PSC state machine to handle Signal Degrade (SD). It = does not define SD or provide scope around where or how SD may be used. Th= ere are some expired drafts that touch on the definition and use of SD, inc= luding: draft-zhl-mpls-tp-sd-03 draft-rkhd-mpls-tp-sd-03 (this is not an exhaustive list. It's the top two google hits.) The questions I think are relevant are: - do we need an SD mechanism in MPLS-TP? - if so, is it reasonable to define state transitions for it before we have= defined SD itself? - if yes to both of the above, does this draft provide the right behavior? = Are there alternative approaches? but of course any and all discussion is welcome. eric From eosborne@cisco.com Wed Apr 17 05:31: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 B629E21F8D31 for ; Wed, 17 Apr 2013 05:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.548 X-Spam-Level: X-Spam-Status: No, score=-9.548 tagged_above=-999 required=5 tests=[AWL=1.051, 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 JqiONed1Ugd4 for ; Wed, 17 Apr 2013 05:31:56 -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 1A61A21F8D2A for ; Wed, 17 Apr 2013 05:31:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=867; q=dns/txt; s=iport; t=1366201916; x=1367411516; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=XARGg9BUHf03jj1Ut3BTfkaTEPLf3N2Ad2tWFK0E5Gc=; b=CycTpzdKxkbBU5yYeHDOSvqgLPYF092Ke8+3N55c5Nnuy/tj0oDTOj3O 22tWjMy7NgLlf4afUFcwO6c9d8pd4fUgSkd1Lu7c2Qnyyj17+bREX3HwP zJR5CcGb+JcTph3lE9kfk3wo8schnuQCnUWXh9USOqiqsIMv2G4z0yr9x k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEFAHCVblGtJXG+/2dsb2JhbABQgwbBQoEFFnSCIQEEOlEBKhRCJgEEG4gMnDGhH45pgx1hA6gagwuCKA X-IronPort-AV: E=Sophos;i="4.87,492,1363132800"; d="scan'208";a="199842063" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 17 Apr 2013 12:31:54 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r3HCVoDi023614 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 17 Apr 2013 12:31:50 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.83]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Wed, 17 Apr 2013 07:31:50 -0500 From: "Eric Osborne (eosborne)" To: "mpls@ietf.org" Thread-Topic: PSC: draft-cdh-mpls-tp-psc-non-revertive-00 Thread-Index: Ac47ZsOxMP4Mlxa+RfSrBXzaGXDaFA== Date: Wed, 17 Apr 2013 12:31:49 +0000 Message-ID: <20ECF67871905846A80F77F8F4A27572101502D8@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.98.66.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [mpls] 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: Wed, 17 Apr 2013 12:31:56 -0000 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 From turners@ieca.com Thu Apr 18 13:43: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 0FEFB21F91B4 for ; Thu, 18 Apr 2013 13:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.307 X-Spam-Level: X-Spam-Status: No, score=-102.307 tagged_above=-999 required=5 tests=[AWL=-0.042, 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 B7BYkjmmRLpJ for ; Thu, 18 Apr 2013 13:43:14 -0700 (PDT) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [67.18.21.25]) by ietfa.amsl.com (Postfix) with ESMTP id 72B9121F91BF for ; Thu, 18 Apr 2013 13:43:13 -0700 (PDT) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id 95EB4D24A0B48; Thu, 18 Apr 2013 15:43:09 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway14.websitewelcome.com (Postfix) with ESMTP id 86041D24A0B0B for ; Thu, 18 Apr 2013 15:43:09 -0500 (CDT) Received: from [108.18.174.101] (port=61688 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1USvfk-0006uP-RZ; Thu, 18 Apr 2013 15:43:12 -0500 Message-ID: <51705AE0.1080809@ieca.com> Date: Thu, 18 Apr 2013 16:43:12 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: rsvp-dir@ietf.org, mpls@ietf.org, ccamp@ietf.org, tsvwg@ietf.org References: <20130418203231.18593.73338.idtracker@ietfa.amsl.com> In-Reply-To: <20130418203231.18593.73338.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130418203231.18593.73338.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.18.174.101]:61688 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 7 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [mpls] Fwd: I-D Action: draft-turner-rsvp-auth-update-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: Thu, 18 Apr 2013 20:43:15 -0000 Apologies for those who get this multiple times, but I wanted to cover all the bases proposed by the TSV AD and the RTG ADs. draft-turner-rsvp-auth-update is a first attempt at adding cryptographic agility to RSVP. It's primarily motivated as a response to: https://datatracker.ietf.org/doc/draft-mahesh-karp-rsvp-te-analysis/ which highlights the need to provide cryptographic agility. draft-turner-rsvp-auth-update does *not* address automated key management. Comments are welcome. Note that we're not yet asking any WG to adopt it as we're still in the stages of determining if there's interest. However, my expectation was that assuming there was interest we'd target the tsvwg WG. spt -------- Original Message -------- Subject: I-D Action: draft-turner-rsvp-auth-update-01.txt Date: Thu, 18 Apr 2013 13:32:31 -0700 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Cryptographic Agility for the RSVP INTEGRITY Object Author(s) : Sean Turner Lou Berger Mahesh Jethanandani Keyur Patel Dacheng Zhang Filename : draft-turner-rsvp-auth-update-01.txt Pages : 7 Date : 2013-04-18 Abstract: This document modifies the RSVP INTEGRITY object to support algorithm agility by explicitly indicating the algorithm used. It also provides rationale for the design choices. Finally, it updates the mandatory to implement algorithm. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-turner-rsvp-auth-update There's also a htmlized version available at: http://tools.ietf.org/html/draft-turner-rsvp-auth-update-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-turner-rsvp-auth-update-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 internet-drafts@ietf.org Fri Apr 19 08:11: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 97C1921F8FED; Fri, 19 Apr 2013 08:11:35 -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 39WYNsUfY+Ny; Fri, 19 Apr 2013 08:11:34 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 49B8621F8C10; Fri, 19 Apr 2013 08:11:34 -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.p3 Message-ID: <20130419151134.31492.65545.idtracker@ietfa.amsl.com> Date: Fri, 19 Apr 2013 08:11:34 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-mldp-hsmp-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: Fri, 19 Apr 2013 15:11:35 -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 Hub & Spoke Multipoint Label Switched= Path Author(s) : Lizhong Jin Frederic Jounay IJsbrand Wijnands Nicolai Leymann Filename : draft-ietf-mpls-mldp-hsmp-01.txt Pages : 13 Date : 2013-04-19 Abstract: This draft introduces a hub & spoke multipoint LSP (short for HSMP LSP), which allows traffic both from root to leaf through P2MP LSP and also leaf to root along the co-routed reverse path. That means traffic entering the HSMP LSP from application/customer at the root node travels downstream, exactly as if it was traveling downstream along a P2MP LSP to each leaf node, and traffic entering the HSMP LSP at any leaf node travels upstream along the tree to the root as if it is unicast to the root, except that it follows the path of the tree rather than ordinary unicast to the root. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-mldp-hsmp There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-mldp-hsmp-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-mldp-hsmp-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From jcucchiara@mindspring.com Sat Apr 20 06:53: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 E62E221F9019; Sat, 20 Apr 2013 06:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.139 X-Spam-Level: X-Spam-Status: No, score=-0.139 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, J_CHICKENPOX_26=0.6, STOX_REPLY_TYPE=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 W-vQjwrql-VU; Sat, 20 Apr 2013 06:53:54 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 81F2921F8FF8; Sat, 20 Apr 2013 06:53:54 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=GPkhXQbzx9y6ceKCR0KX+3h2kAdBKx+bxMcyGRlOL+khzMCtpOAwxIUba/YgTz80; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [24.41.69.138] (helo=JoanPC) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1UTYEY-0006wx-6U; Sat, 20 Apr 2013 09:53:42 -0400 Message-ID: <004801ce3dce$771f7270$6f01a8c0@JoanPC> From: "Joan Cucchiara" To: "venkatesan mahalingam" References: <010401ce37e7$15b17ed0$6f01a8c0@JoanPC> Date: Sat, 20 Apr 2013 08:53:40 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654ede62bd470296b33c5952077de9b43a5b07bc47b65cfebd7350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 24.41.69.138 Cc: Kannan Sampath , mpls@ietf.org, "MIB Doctors \(E-mail\)" , Sam Aldrin Subject: Re: [mpls] MIB Dr. review of draft-ietf-mpls-tp-te-mib-05 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, 20 Apr 2013 13:53:56 -0000 Venkat, Thank you for your quick response. Would like to close on some questions/comments, see below. I have cc'd MIB Drs. and MPLS WGs also. I think these WGs should be included as part of the ongoing review. Thanks, -Joan > > ----- Original Message ----- > From: venkatesan mahalingam > To: jcucchiara@mindspring.com > Cc: Sam Aldrin ; Kannan Sampath ; Thomas Nadeau > Sent: Friday, April 19, 2013 10:10 PM > Subject: Fwd: [mpls] MIB Dr. review of draft-ietf-mpls-tp-te-mib-05 > > > > > ---------- Forwarded message ---------- > From: Joan Cucchiara > Date: Fri, Apr 12, 2013 at 6:34 PM > Subject: [mpls] MIB Dr. review of draft-ietf-mpls-tp-te-mib-05 > To: mpls@ietf.org, "MIB Doctors (E-mail)" , Loa > Andersson , Thomas Nadeau , Venkatesan > Mahalingam , Kannan Sampath > > > > Sam, > > I am sorry for such a long delay....here is the MIB Dr. Review. Lots of > progress on the draft! > > Please see the comments below. > > Thanks, > -Joan > > > smicng OUTPUT > -------------- > > MPLS-LSR-EXT-STD-MIB > ====================== > W: f(MPLS-LSR-EXT-STD-MIB.my), (216,18) For "mplsXCExtTunnelPointer", > syntax > is identical > W: f(MPLS-LSR-EXT-STD-MIB.my), (215,18) MIN-ACCESS value identical to > access > specified for "mplsXCExtTunnelPointer" > W: f(MPLS-LSR-EXT-STD-MIB.my), (223,18) For "mplsXCExtOppositeDirXCPtr", > syntax is identical > > *) The DESCRIPTION clauses related to these objects > should be updated to include the information in this > conformance section. > > > VM> Not fixed yet, how to get this warnings in smilint compiler, what's > the > severity level to be used? Do you have any suggestion to fix this kind of > issue? > This is a problem with compliance (see below). Additionally, the DESCRIPTION clause is information I would expect to see in the object's DESCRIPTION, rather than as part of the Compliance Statement. > > > MPLS-TE-EXT-STD-MIB > ===================== > E: f(MPLS-TE-EXT-STD-MIB.my), (284,17) Index item > "mplsTunnelExtNodeIpMapNodeId" must be defined with syntax that includes a > range > > I see the following in MPLS-TC-EXT-STD-MIB > MplsNodeId ::= TEXTUAL-CONVENTION > .... > SYNTAX Unsigned32 -- the default range: (0..4294967295) > > my suggestion is to include the range as part of the SYNTAX in the TC. > > > VM>Edited. NIT: The value of zero is reserved, so more appropriate specification would be (0|1..4294967295), so NIT, but would serve to enforce the DESCRIPTION clause. > > smilint > ----------- > MIBs compile cleanly. > > > GENERAL COMMENTS > ---------------- > *) The terms augments/sparse augments/extensions are all used to > describe relationships with tables in this document and > tables in rfc3812 and rfc3813. For example, > a table in this document says "sparse augments" but then has > a value of noSuchInstance returned if the counter is not applicable > for TP. > > Another part of the document says that a table in this document > augments a table from elsewhere, but that does not seem to be the > case when looking at the MIB module. > > The relationships beween tables in this document and > the tables in rfc3812 and rfc3813 need to be specified clearly. > I would ask that the authors please check these relationships between > the tables. This may be (simply?) using the term > 'sparse augments' consistently. > > > VM>Edited. > > > *) Appendix D of rfc4181 (MIB guidelines) suggests: > > > xxxMIB > | > +-- xxxNotifications(0) > +-- xxxObjects(1) > +-- xxxConformance(2) > | > +-- xxxCompliances(1) > +-- xxxGroups(2) > > The MIB Modules in this doc: > > \-2 Conformance > \-v-1 Groups > > \-2 Compliances > > So Groups and Compliances are not in the suggested order. > > > VM>Edited. > > > Specific Comments > ===================== > > *) Introduction > > "This MIB module should be used...." > > Which MIB module are you referring to? (Do you mean "These MIB > modules"??) > > > VM>Edited. > > > *) Same Section (Intro) > "...for MPLS based traffic engineering configuration and management." > > I don't understand completely, but seems like MPLS TP is probably what is > meant. > > > VM>Edited. > > > *) 4. Motivations > > s/used in non-IP environment./used in non-IP environments. > > awkward sentence: This MIB also defines three other MIB modules within > this > document. > Maybe: This document defines 4 MIB modules: (and then list all 4) > > > VM>Edited. > > > 5. Feature List > Could you refer to the MIB module by name? So, instead of > "MPLS transport profile MIB module" use the MPLS-TE-EXT-STD-MIB > and so forth. > > > VM>Edited. > > > 6. Brief description of MIB Objects > This section focuses on MPLS-TE-EXT-STD-MIB, so maybe rename the section > or also include the other MIB modules in this document. > > > VM>Edited. > > > 6.5 mplsTunnelExtReversePerfTable > > "This table augments the mplsTunnelTable..." > > If it augments, then why is AUGMENTS not used in the > MPLS-TE-EXT-STD-MIB? I think this relationship is a > sparce augments, not an actual augments? Please > explain. > > > VM>Edited. > > > MPLS-TC-EXT-MIB > ================== > *) Why is the CC ID not represented in this MIB Module? > > Basically, the question has to do with the following from > draft-ietf-mpls-tp-itu-t-identifiers, specifically: > > "Together, the CC and the ICC form the ICC_Operator_ID as: > > CC::ICC > > The ICC_Operator_ID is used as a replacement for the Global_ID as > specified in [RFC6370], i.e. its purpose is to provide a globally > unique context for other MPLS-TP identifiers." > > ICC_Operator_ID appears to be the counterpart to GLOBAL_ID. In other > words, these both uniquely identify an operator. Whereas, ICC by itself > does not. > > > VM>Edited. > > > MPLS-ID-STD-MIB > ================= > > *)What is the relationship between mplsIdGlobalId and mplsIdNodeId? > Specifically, if mplsIdGlobalId has been set, can mplsIdNodeId be > set to a different value? > > VM> NodeId is defined within the scope of GlobalId. Yes, NodeId can be set > to different value if the GlobalId has the valid value already. > The impact of these scalars need to be explained to a user. How would changing this value after establishing a TP Tunnel impact the network (for example)? > > *) NIT: Could the order reflect the same order as in MPLS-TC-EXT-STD-MIB? > The reason is that GLobal_ID and NODE_ID are related so think would be > logical to have them near each other. > > > VM>Edited. > > > *) Also, I'm not really sure why you want a MIB module with only 3 scalars > in it? As far as I can see these scalars are only used in the > MPLS-TE-EXT-STD-MIB, so why separate them? > > > VM> These scalars will be used for MPLS-TP PWE3 extension also. So, it is > better to be in the separate MIB module. > I kind of have a problem with this. If there is another MIB Module that depends on these scalars, shouldn't that other MIB Module be reviewed as part of this process? What is the state of this other MIB Module? Additionally, these TCs and associated scalars are dependent on a draft in the MPLS WG. So, these could change in theory. > > *) Error: FullCompliance and ReadOnlyCompliance is EXACTLY the same. > > > VM> OK. > > MPLS-LSR-EXT-STD-MIB > ===================== > > Compliance: > OBJECT mplsXCExtTunnelPointer > SYNTAX RowPointer > MIN-ACCESS read-only > DESCRIPTION > "The only valid value for Tunnel Pointer is > mplsTunnelTable entry." > > *) This object is read-only, so no need for a read-only compliance > since object is already read-only. > This is the cause of the SMICNG warning. Should be fixed as this adds nothing and is redundant. > *) The above DESCRIPTION needs to be included in the > object's DESCRIPTION. > > > OBJECT mplsXCExtOppositeDirXCPtr > SYNTAX RowPointer > MIN-ACCESS read-only > DESCRIPTION > "The only valid value for XC Pointer is > mplsXCTable entry." > > ::= { mplsLsrExtCompliances 2 } > > *) The above DESCRIPTION needs to be included in the > object's DESCRIPTION. > > *) There is nothing here that specifies the readOnly compliance. > Would expect something like: > > OBJECT nameOfObject > MIN-ACCESS read-only > DESCRIPTION "Write access is not required." > > > VM>Edited. > > > MPLS-TE-EXT-STD-MIB > =================== > > *) DESCRIPTION > "This object indicates the Global Operator Identifier. > This object value should be zero when > mplsTunnelExtNodeConfigIccId is configured with non-null > value." > > DESCRIPTION should state that the object has no meaning when > mplsTunnelExtNodeConfigIccId is valid. Same comment for > mplsTunnelExtNodeConfigId. > > In other words, maybe an additional object is needed to indicate > Global or ICC? What if a 3rd TP id is created, then what happens? > > Better to be explicite I think, than to try and overload these > objects with values that they shouldn't have. > > > VM>Edited. > > > mplsTunnelExtNodeConfigNodeId OBJECT-TYPE > SYNTAX MplsNodeId > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "This object indicates the Node_ID within the operator. > > *) Sentence is awkward. > > VM> Corrected. > > mplsTunnelExtNodeConfigIccId > Similar comment to the above. Additionally, how can an OCTET STRING > of size (1..6) have a zero value? > > VM> Corrected. > > *) mplsTunnelExtNodeConfigStorageType > > Not sure I see the advantage of having this as it is > already in the MplsTunnelTable. Why have 2 StorageType objects > for the same row? > > VM> NodeConfig table is a separate table used to map the Global_Node_ID > and > CC::ICC identifiers with the local-id. > So, I don't see 2 Storage types. Sorry, my error. You are correct. > > *) mplsTunnelExtIngressLSRLocalIdValid and > mplsTunnelExtEgressLSRLocalIdValid > Please fix the DESCRIPTION and REFERENCE. > (Looks like the DESCRIPTION clause has been continued after the > REF clause.) > > > VM> I don't understand this comment. Do you expect the reference clause > for > these two objects? > When I look at this, I see: DESCRIPTION "This object denotes whether the mplsTunnelIngressLSRId contains the local value, which is used to reference the complete Ingress Global_ID::Node_ID or ICC from the mplsTunnelExtNodeConfigTable." REFERENCE "MPLS-TE-STD-MIB [RFC3812], Section 11. mplsTunnelIngressLSRId object in mplsTunnelTable. If this object is set to FALSE, mplsTunnelExtNodeConfigTable will not contain an entry to reference local identifier with Global_ID::Node_ID or ICC value. This object is set to FALSE for legacy implementations like MPLS TE tunnels where mplsTunnelIngressId itself provides complete Ingress LSRId." So, if you look at the DESCRIPTION clause and REFERENCE clause, you can see that some of the text in the REFERENCE clause is more descriptive, specifically: ".....mplsTunnelIngressLSRId object in mplsTunnelTable. If this object is set to FALSE, mplsTunnelExtNodeConfigTable will not contain an entry to reference local identifier with Global_ID::Node_ID or ICC value. This object is set to FALSE for legacy implementations like MPLS TE tunnels where mplsTunnelIngressId itself provides complete Ingress LSRId." I would not expect to find the above text in a REFERENCE clause. Does my original comment make sense now? Thanks, -Joan > > *) mplsTunnelExtReversePerfTable > > I would like to understand why noSuchInstance would be needed. > This table is a sparse augments, > so either the entry would be there or it wouldn't, right? > > VM> Yes. Corrected. > > *) Probably could remove the following (comment applies to other > MIB Modules also.) > > -- Notifications > mplsTeExtNotifications OBJECT IDENTIFIER > ::= { mplsTeExtStdMIB 0 } > > -- Notifications. > -- Notification objects need to be added here. > -- End of notifications. > > > VM> Removed. > > *) Compliance Section > ReadOnly compliance is the same as the Full Compliance. > In other words, readonly compliance does not really exist. > Please fix this. > > > VM> Updated. > > > 14. Security Considerations > ============================ > Should specify which objects would jeopardize security. > > > VM> Edited. > > 15. IANA Considerations > ======================== > > Where is it? This section needs to be done. > > > VM> Edited. > > -- the end -- > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls > From venkatflex@gmail.com Sat Apr 20 12:03: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 81C0321F9265; Sat, 20 Apr 2013 12:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, 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 NcoaSQcykJJZ; Sat, 20 Apr 2013 12:03:51 -0700 (PDT) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 9E78A21F925B; Sat, 20 Apr 2013 12:03:50 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id u3so1844159wey.38 for ; Sat, 20 Apr 2013 12:03:47 -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=r6cRICL47/k10SfccNwpoQVHDd7BMrvsv6aVy2HiWIo=; b=TSgiq8CGfi6qihW0ZqbO8XDuVCEXTBI+hstaY2YG1uLEhlPQ8Wyx+0Ym3rGcrU/wtD twV8QwxQgHRChXJqT4c+VXT2/1uTWJW7NCPVgRy9KOunHkQRjUIQPKWZwLejfuPat69N XkETYPydP6JGrPEknkZKDpdG4dVRj6K/F0ynYTWJakEMbk07GYg2gljdJpHO0o830s2n LzIXyHR71q5SvoUDP22KIus220LBhnvkOh5c2snVuBxHfG+3ybM+VFZbp9lANalyinRO 2Wp5UxJVY6+vsI205XbUX62XYkhmhM4nUAG7qQ2Lk1ecn7ihLRsxiLWIdj38bE5UCXsz KMbw== MIME-Version: 1.0 X-Received: by 10.194.177.200 with SMTP id cs8mr36937962wjc.22.1366484627031; Sat, 20 Apr 2013 12:03:47 -0700 (PDT) Received: by 10.194.85.196 with HTTP; Sat, 20 Apr 2013 12:03:46 -0700 (PDT) In-Reply-To: <004801ce3dce$771f7270$6f01a8c0@JoanPC> References: <010401ce37e7$15b17ed0$6f01a8c0@JoanPC> <004801ce3dce$771f7270$6f01a8c0@JoanPC> Date: Sat, 20 Apr 2013 12:03:46 -0700 Message-ID: From: venkatesan mahalingam To: Joan Cucchiara Content-Type: multipart/alternative; boundary=089e014940b0c90d9f04dacf7e95 Cc: Kannan Sampath , mpls , "MIB Doctors \(E-mail\)" , Sam Aldrin Subject: Re: [mpls] MIB Dr. review of draft-ietf-mpls-tp-te-mib-05 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, 20 Apr 2013 19:03:53 -0000 --089e014940b0c90d9f04dacf7e95 Content-Type: text/plain; charset=ISO-8859-1 Joan, I appreciate your quick response on my comments. Please find below my in-lined response with the tag VM1>. -Venkat. On Sat, Apr 20, 2013 at 6:53 AM, Joan Cucchiara wrote: > Venkat, > > Thank you for your quick response. Would like to close on some > questions/comments, see below. > I have cc'd MIB Drs. and MPLS WGs also. I think these WGs should be > included as part of the > ongoing review. > > Thanks, > -Joan > > > >> ----- Original Message ----- From: venkatesan mahalingam >> To: jcucchiara@mindspring.com >> Cc: Sam Aldrin ; Kannan Sampath ; Thomas Nadeau >> Sent: Friday, April 19, 2013 10:10 PM >> Subject: Fwd: [mpls] MIB Dr. review of draft-ietf-mpls-tp-te-mib-05 >> >> > > >> >> >> ---------- Forwarded message ---------- >> From: Joan Cucchiara >> Date: Fri, Apr 12, 2013 at 6:34 PM >> Subject: [mpls] MIB Dr. review of draft-ietf-mpls-tp-te-mib-05 >> To: mpls@ietf.org, "MIB Doctors (E-mail)" , Loa >> Andersson , Thomas Nadeau , Venkatesan >> Mahalingam **, Kannan Sampath >> >> >> >> Sam, >> >> I am sorry for such a long delay....here is the MIB Dr. Review. Lots of >> progress on the draft! >> >> Please see the comments below. >> >> Thanks, >> -Joan >> >> >> smicng OUTPUT >> -------------- >> >> MPLS-LSR-EXT-STD-MIB >> ====================== >> W: f(MPLS-LSR-EXT-STD-MIB.my), (216,18) For "mplsXCExtTunnelPointer", >> syntax >> is identical >> W: f(MPLS-LSR-EXT-STD-MIB.my), (215,18) MIN-ACCESS value identical to >> access >> specified for "mplsXCExtTunnelPointer" >> W: f(MPLS-LSR-EXT-STD-MIB.my), (223,18) For "mplsXCExtOppositeDirXCPtr", >> syntax is identical >> >> *) The DESCRIPTION clauses related to these objects >> should be updated to include the information in this >> conformance section. >> >> >> VM> Not fixed yet, how to get this warnings in smilint compiler, what's >> the >> severity level to be used? Do you have any suggestion to fix this kind of >> issue? >> >> > This is a problem with compliance (see below). Additionally, the > DESCRIPTION > clause is information I would expect to see in the object's DESCRIPTION, > rather than as part of > the Compliance Statement. > > VM1> Edited. > >> >> >> MPLS-TE-EXT-STD-MIB >> ===================== >> E: f(MPLS-TE-EXT-STD-MIB.my), (284,17) Index item >> "mplsTunnelExtNodeIpMapNodeId" must be defined with syntax that includes a >> range >> >> I see the following in MPLS-TC-EXT-STD-MIB >> MplsNodeId ::= TEXTUAL-CONVENTION >> .... >> SYNTAX Unsigned32 -- the default range: (0..4294967295) >> >> my suggestion is to include the range as part of the SYNTAX in the TC. >> >> >> VM>Edited. >> > > NIT: The value of zero is reserved, so more appropriate specification > would be (0|1..4294967295), so NIT, but > would serve to enforce the DESCRIPTION clause. > > VM1> Edited. > > >> smilint >> ----------- >> MIBs compile cleanly. >> >> >> GENERAL COMMENTS >> ---------------- >> *) The terms augments/sparse augments/extensions are all used to >> describe relationships with tables in this document and >> tables in rfc3812 and rfc3813. For example, >> a table in this document says "sparse augments" but then has >> a value of noSuchInstance returned if the counter is not applicable >> for TP. >> >> Another part of the document says that a table in this document >> augments a table from elsewhere, but that does not seem to be the >> case when looking at the MIB module. >> >> The relationships beween tables in this document and >> the tables in rfc3812 and rfc3813 need to be specified clearly. >> I would ask that the authors please check these relationships between >> the tables. This may be (simply?) using the term >> 'sparse augments' consistently. >> >> >> VM>Edited. >> >> >> *) Appendix D of rfc4181 (MIB guidelines) suggests: >> >> >> xxxMIB >> | >> +-- xxxNotifications(0) >> +-- xxxObjects(1) >> +-- xxxConformance(2) >> | >> +-- xxxCompliances(1) >> +-- xxxGroups(2) >> >> The MIB Modules in this doc: >> >> \-2 Conformance >> \-v-1 Groups >> >> \-2 Compliances >> >> So Groups and Compliances are not in the suggested order. >> >> >> VM>Edited. >> >> >> Specific Comments >> ===================== >> >> *) Introduction >> >> "This MIB module should be used...." >> >> Which MIB module are you referring to? (Do you mean "These MIB >> modules"??) >> >> >> VM>Edited. >> >> >> *) Same Section (Intro) >> "...for MPLS based traffic engineering configuration and management." >> >> I don't understand completely, but seems like MPLS TP is probably what is >> meant. >> >> >> VM>Edited. >> >> >> *) 4. Motivations >> >> s/used in non-IP environment./used in non-IP environments. >> >> awkward sentence: This MIB also defines three other MIB modules within >> this >> document. >> Maybe: This document defines 4 MIB modules: (and then list all 4) >> >> >> VM>Edited. >> >> >> 5. Feature List >> Could you refer to the MIB module by name? So, instead of >> "MPLS transport profile MIB module" use the MPLS-TE-EXT-STD-MIB >> and so forth. >> >> >> VM>Edited. >> >> >> 6. Brief description of MIB Objects >> This section focuses on MPLS-TE-EXT-STD-MIB, so maybe rename the section >> or also include the other MIB modules in this document. >> >> >> VM>Edited. >> >> >> 6.5 mplsTunnelExtReversePerfTable >> >> "This table augments the mplsTunnelTable..." >> >> If it augments, then why is AUGMENTS not used in the >> MPLS-TE-EXT-STD-MIB? I think this relationship is a >> sparce augments, not an actual augments? Please >> explain. >> >> >> VM>Edited. >> >> >> MPLS-TC-EXT-MIB >> ================== >> *) Why is the CC ID not represented in this MIB Module? >> >> Basically, the question has to do with the following from >> draft-ietf-mpls-tp-itu-t-**identifiers, specifically: >> >> "Together, the CC and the ICC form the ICC_Operator_ID as: >> >> CC::ICC >> >> The ICC_Operator_ID is used as a replacement for the Global_ID as >> specified in [RFC6370], i.e. its purpose is to provide a globally >> unique context for other MPLS-TP identifiers." >> >> ICC_Operator_ID appears to be the counterpart to GLOBAL_ID. In other >> words, these both uniquely identify an operator. Whereas, ICC by itself >> does not. >> >> >> VM>Edited. >> >> >> MPLS-ID-STD-MIB >> ================= >> >> *)What is the relationship between mplsIdGlobalId and mplsIdNodeId? >> Specifically, if mplsIdGlobalId has been set, can mplsIdNodeId be >> set to a different value? >> >> VM> NodeId is defined within the scope of GlobalId. Yes, NodeId can be set >> to different value if the GlobalId has the valid value already. >> >> > The impact of these scalars need to be explained to a user. How would > changing this value after > establishing a TP Tunnel impact the network (for example)? > > VM1> Edited. > > > >> *) NIT: Could the order reflect the same order as in MPLS-TC-EXT-STD-MIB? >> The reason is that GLobal_ID and NODE_ID are related so think would be >> logical to have them near each other. >> >> >> VM>Edited. >> >> >> *) Also, I'm not really sure why you want a MIB module with only 3 scalars >> in it? As far as I can see these scalars are only used in the >> MPLS-TE-EXT-STD-MIB, so why separate them? >> >> >> VM> These scalars will be used for MPLS-TP PWE3 extension also. So, it is >> better to be in the separate MIB module. >> >> > I kind of have a problem with this. If there is another MIB Module that > depends on these scalars, shouldn't that > other MIB Module be reviewed as part of this process? What is the > state of this other MIB Module? > > Additionally, these TCs and associated scalars are dependent on a draft in > the MPLS WG. So, these could change > in theory. > > VM1> This comment alone is not fixed, I would like to discuss this further > with co-authors and let you know you our stand on this next week. > > >> *) Error: FullCompliance and ReadOnlyCompliance is EXACTLY the same. >> >> >> VM> OK. >> >> MPLS-LSR-EXT-STD-MIB >> ===================== >> >> Compliance: >> OBJECT mplsXCExtTunnelPointer >> SYNTAX RowPointer >> MIN-ACCESS read-only >> DESCRIPTION >> "The only valid value for Tunnel Pointer is >> mplsTunnelTable entry." >> >> *) This object is read-only, so no need for a read-only compliance >> since object is already read-only. >> >> > This is the cause of the SMICNG warning. Should be fixed as this adds > nothing and is redundant. > > VM1> Edited. > > > *) The above DESCRIPTION needs to be included in the >> object's DESCRIPTION. >> >> >> OBJECT mplsXCExtOppositeDirXCPtr >> SYNTAX RowPointer >> MIN-ACCESS read-only >> DESCRIPTION >> "The only valid value for XC Pointer is >> mplsXCTable entry." >> >> ::= { mplsLsrExtCompliances 2 } >> >> *) The above DESCRIPTION needs to be included in the >> object's DESCRIPTION. >> >> *) There is nothing here that specifies the readOnly compliance. >> Would expect something like: >> >> OBJECT nameOfObject >> MIN-ACCESS read-only >> DESCRIPTION "Write access is not required." >> >> >> VM>Edited. >> >> >> MPLS-TE-EXT-STD-MIB >> =================== >> >> *) DESCRIPTION >> "This object indicates the Global Operator Identifier. >> This object value should be zero when >> mplsTunnelExtNodeConfigIccId is configured with non-null >> value." >> >> DESCRIPTION should state that the object has no meaning when >> mplsTunnelExtNodeConfigIccId is valid. Same comment for >> mplsTunnelExtNodeConfigId. >> >> In other words, maybe an additional object is needed to indicate >> Global or ICC? What if a 3rd TP id is created, then what happens? >> >> Better to be explicite I think, than to try and overload these >> objects with values that they shouldn't have. >> >> >> VM>Edited. >> >> >> mplsTunnelExtNodeConfigNodeId OBJECT-TYPE >> SYNTAX MplsNodeId >> MAX-ACCESS read-create >> STATUS current >> DESCRIPTION >> "This object indicates the Node_ID within the operator. >> >> *) Sentence is awkward. >> >> VM> Corrected. >> >> mplsTunnelExtNodeConfigIccId >> Similar comment to the above. Additionally, how can an OCTET STRING >> of size (1..6) have a zero value? >> >> VM> Corrected. >> >> *) mplsTunnelExtNodeConfigStorage**Type >> >> Not sure I see the advantage of having this as it is >> already in the MplsTunnelTable. Why have 2 StorageType objects >> for the same row? >> >> VM> NodeConfig table is a separate table used to map the Global_Node_ID >> and >> CC::ICC identifiers with the local-id. >> So, I don't see 2 Storage types. >> > > > Sorry, my error. You are correct. > > VM1> OK, No problem. > > > >> *) mplsTunnelExtIngressLSRLocalId**Valid and >> mplsTunnelExtEgressLSRLocalIdV**alid >> Please fix the DESCRIPTION and REFERENCE. >> (Looks like the DESCRIPTION clause has been continued after the >> REF clause.) >> >> >> VM> I don't understand this comment. Do you expect the reference clause >> for >> these two objects? >> >> > When I look at this, I see: > > DESCRIPTION > "This object denotes whether the mplsTunnelIngressLSRId > contains the local value, which is used to reference > the complete Ingress Global_ID::Node_ID or ICC from > the mplsTunnelExtNodeConfigTable." > REFERENCE > "MPLS-TE-STD-MIB [RFC3812], Section 11. mplsTunnelIngressLSRId > object in mplsTunnelTable. > > If this object is set to FALSE, mplsTunnelExtNodeConfigTable > will not contain an entry to reference local identifier with > Global_ID::Node_ID or ICC value. > > This object is set to FALSE for legacy implementations like > MPLS TE tunnels where mplsTunnelIngressId itself provides > complete Ingress LSRId." > > So, if you look at the DESCRIPTION clause and REFERENCE clause, you can > see that > some of the text in the REFERENCE clause is more descriptive, specifically: > ".....mplsTunnelIngressLSRId > object in mplsTunnelTable. > > If this object is set to FALSE, mplsTunnelExtNodeConfigTable > will not contain an entry to reference local identifier with > Global_ID::Node_ID or ICC value. > > This object is set to FALSE for legacy implementations like > MPLS TE tunnels where mplsTunnelIngressId itself provides > complete Ingress LSRId." > > I would not expect to find the above text in a REFERENCE clause. Does my > original comment make sense now? > > VM1> Yes, edited. > Thanks, > -Joan > > > > >> *) mplsTunnelExtReversePerfTable >> >> I would like to understand why noSuchInstance would be needed. >> This table is a sparse augments, >> so either the entry would be there or it wouldn't, right? >> >> VM> Yes. Corrected. >> >> *) Probably could remove the following (comment applies to other >> MIB Modules also.) >> >> -- Notifications >> mplsTeExtNotifications OBJECT IDENTIFIER >> ::= { mplsTeExtStdMIB 0 } >> >> -- Notifications. >> -- Notification objects need to be added here. >> -- End of notifications. >> >> >> VM> Removed. >> >> *) Compliance Section >> ReadOnly compliance is the same as the Full Compliance. >> In other words, readonly compliance does not really exist. >> Please fix this. >> >> >> VM> Updated. >> >> >> 14. Security Considerations >> ============================ >> Should specify which objects would jeopardize security. >> >> >> VM> Edited. >> >> 15. IANA Considerations >> ======================== >> >> Where is it? This section needs to be done. >> >> >> VM> Edited. >> >> -- the end -- >> >> ______________________________**_________________ >> mpls mailing list >> mpls@ietf.org >> https://www.ietf.org/mailman/**listinfo/mpls >> >> > --089e014940b0c90d9f04dacf7e95 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Joan,

I appreciate yo= ur quick response on my comments. Please find below my in-lined response wi= th the tag VM1>.

-Venkat.


On Sat, Apr 20, 2013 at 6:53 AM, Joan Cu= cchiara <jcucchiara@mindspring.com> wrote:
Venkat,

Thank you for your quick response. =A0Would like to close on some questions= /comments, see below.
I have cc'd MIB Drs. and MPLS WGs also. =A0 I think these WGs should be= included as part of the
ongoing review.

Thanks,
=A0-Joan



----- Original Message ----- From: venkatesan mahalingam
To: jcucchia= ra@mindspring.com
Cc: Sam Aldrin ; Kannan Sampath ; Thomas Nadeau
Sent: Friday, April 19, 2013 10:10 PM
Subject: Fwd: [mpls] MIB Dr. review of draft-ietf-mpls-tp-te-mib-05

<snip>




---------- Forwarded message ----------
From: Joan Cucchiara <jcucchiara@mindspring.com>
Date: Fri, Apr 12, 2013 at 6:34 PM
Subject: [mpls] MIB Dr. review of draft-ietf-mpls-tp-te-mib-05
To: mpls@ietf.org, &= quot;MIB Doctors (E-mail)" <mib-doctors@ietf.org>, Loa
Andersson <loa@pi.nu&= gt;, Thomas Nadeau <tnadeau@juniper.net>, Venkatesan
Mahalingam <venkat.mahalingams@gmail.com>, Kannan Sampath
<kannankvs@gmai= l.com>


Sam,

I am sorry for such a long delay....here is the MIB Dr. Review. =A0 Lots of=
progress on the draft!

Please see the comments below.

Thanks,
-Joan


smicng OUTPUT
--------------

MPLS-LSR-EXT-STD-MIB
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
W: f(MPLS-LSR-EXT-STD-MIB.my), (216,18) For "mplsXCExtTunnelPointer&qu= ot;, syntax
is identical
W: f(MPLS-LSR-EXT-STD-MIB.my), (215,18) MIN-ACCESS value identical to acces= s
specified for "mplsXCExtTunnelPointer"
W: f(MPLS-LSR-EXT-STD-MIB.my), (223,18) For "mplsXCExtOppositeDirXCPtr= ",
syntax is identical

*) The DESCRIPTION clauses related to these objects
should be updated to include the information in this
conformance section.


VM> Not fixed yet, how to get this warnings in smilint compiler, what= 9;s the
severity level to be used? Do you have any suggestion to fix this kind of issue?


This is a problem with compliance (see below). =A0 =A0 Additionally, the DE= SCRIPTION
clause is information I would expect to see in the object's DESCRIPTION= , rather than as part of
the Compliance Statement.

VM1> Edited.


MPLS-TE-EXT-STD-MIB
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
E: f(MPLS-TE-EXT-STD-MIB.my), (284,17) Index item
"mplsTunnelExtNodeIpMapNodeId" must be defined with syntax that i= ncludes a
range

I see the following in MPLS-TC-EXT-STD-MIB
=A0MplsNodeId ::=3D TEXTUAL-CONVENTION
=A0....
=A0 =A0 SYNTAX =A0Unsigned32 =A0-- the default range: (0..4294967295)

my suggestion is to include the range as part of the SYNTAX in the TC.


VM>Edited.

NIT: =A0 The value of zero is reserved, so more appropriate specification w= ould be (0|1..4294967295), so NIT, but
would serve to enforce the DESCRIPTION clause.

VM1> Edited.


smilint
-----------
MIBs compile cleanly.


GENERAL COMMENTS
----------------
*) The terms augments/sparse augments/extensions are all used to
describe relationships with tables in this document and
tables in rfc3812 and rfc3813. =A0For example,
a table in this document says "sparse augments" but then has
a value of noSuchInstance returned if the counter is not applicable
for TP.

Another part of the document says that a table in this document
augments a table from elsewhere, but that does not seem to be the
case when looking at the MIB module.

The relationships beween tables in this document and
the tables in rfc3812 and rfc3813 need to be specified clearly.
I would ask that the authors please check these relationships between
the tables. =A0 This may be (simply?) using the term
'sparse augments' consistently.


VM>Edited.


*) Appendix D of rfc4181 (MIB guidelines) suggests:


=A0 =A0 =A0 =A0xxxMIB
=A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0+-- xxxNotifications(0)
=A0 =A0 =A0 =A0+-- xxxObjects(1)
=A0 =A0 =A0 =A0+-- xxxConformance(2)
=A0 =A0 =A0 =A0 =A0 =A0|
=A0 =A0 =A0 =A0 =A0 =A0+-- xxxCompliances(1)
=A0 =A0 =A0 =A0 =A0 =A0+-- xxxGroups(2)

The MIB Modules in this doc:

=A0\-2 Conformance
=A0 =A0\-v-1 Groups

=A0 =A0 =A0\-2 Compliances

So Groups and Compliances are not in the suggested order.


VM>Edited.


Specific Comments
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

*) Introduction

"This MIB module should be used...."

Which MIB module are you referring to? =A0 (Do you mean "These MIB mod= ules"??)


VM>Edited.


*) Same Section (Intro)
"...for MPLS based traffic engineering configuration and management.&q= uot;

I don't understand completely, but seems like MPLS TP is probably what = is
meant.


VM>Edited.


*) 4. Motivations

s/used in non-IP environment./used in non-IP environments.

awkward sentence: =A0This MIB also defines three other MIB modules within t= his
document.
Maybe: =A0This document defines 4 MIB modules: (and then list all 4)


VM>Edited.


5. Feature List
Could you refer to the MIB module by name? =A0So, instead of
"MPLS transport profile MIB module" use the MPLS-TE-EXT-STD-MIB and so forth.


VM>Edited.


6. Brief description of MIB Objects
This section focuses on MPLS-TE-EXT-STD-MIB, so maybe rename the section or also include the other MIB modules in this document.


VM>Edited.


6.5 mplsTunnelExtReversePerfTable

"This table augments the mplsTunnelTable..."

If it augments, then why is AUGMENTS not used in the
MPLS-TE-EXT-STD-MIB? =A0 I think this relationship is a
sparce augments, not an actual augments? =A0 Please
explain.


VM>Edited.


MPLS-TC-EXT-MIB
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
*) =A0Why is the CC ID not represented in this MIB Module?

Basically, the question has to do with the following from
draft-ietf-mpls-tp-itu-t-identifiers, specifically:

"Together, the CC and the ICC form the ICC_Operator_ID as:

=A0 =A0 CC::ICC

=A0The ICC_Operator_ID is used as a replacement for the Global_ID as
=A0specified in [RFC6370], i.e. its purpose is to provide a globally
=A0unique context for other MPLS-TP identifiers."

ICC_Operator_ID appears to be the counterpart to GLOBAL_ID. =A0In other
words, these both uniquely identify an operator. Whereas, ICC by itself
does not.


VM>Edited.


MPLS-ID-STD-MIB
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

*)What is the relationship between mplsIdGlobalId and mplsIdNodeId?
Specifically, if mplsIdGlobalId has been set, can mplsIdNodeId be
set to a different value?

VM> NodeId is defined within the scope of GlobalId. Yes, NodeId can be s= et
to different value if the GlobalId has the valid value already.


The impact of these scalars need to be explained to a user. =A0 How would c= hanging this value after
establishing a TP Tunnel =A0impact the network (for example)?

VM1> Edited.



*) NIT: =A0Could the order reflect the same order as in MPLS-TC-EXT-STD-MIB= ?
The reason is that GLobal_ID and NODE_ID are related so think would be
logical to have them near each other.


VM>Edited.


*) Also, I'm not really sure why you want a MIB module with only 3 scal= ars
in it? =A0As far as I can see these scalars are only used in the
MPLS-TE-EXT-STD-MIB, so why separate them?


VM> These scalars will be used for MPLS-TP PWE3 extension also. So, it i= s
better to be in the separate MIB module.


I kind of have a problem with this. =A0 If there is another MIB Module that= depends on these scalars, shouldn't that
other MIB Module be reviewed as part of this process? =A0 =A0 What is the s= tate of this other MIB Module?

Additionally, these TCs and associated scalars are dependent on a draft in = the MPLS WG. =A0So, these could change
in theory.

VM1> This comment alone is not fixed, I would like to discuss this furth= er with co-authors and let you know you our stand on this next week.


*) Error: =A0FullCompliance and ReadOnlyCompliance is EXACTLY the same.


VM> OK.

MPLS-LSR-EXT-STD-MIB
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Compliance:
=A0 =A0OBJECT =A0 =A0 =A0mplsXCExtTunnelPointer
=A0 =A0SYNTAX =A0 =A0 =A0RowPointer
=A0 =A0MIN-ACCESS =A0read-only
=A0 =A0DESCRIPTION
=A0 =A0 =A0 "The only valid value for Tunnel Pointer is
=A0 =A0 =A0 =A0mplsTunnelTable entry."

*) This object is read-only, so no need for a read-only compliance
since object is already read-only.


This is the cause of the SMICNG warning. =A0 Should be fixed as this adds n= othing and is redundant.

VM1> Edited.=A0


*) The above DESCRIPTION needs to be included in the
object's DESCRIPTION.


=A0 =A0OBJECT =A0 =A0 =A0mplsXCExtOppositeDirXCPtr
=A0 =A0SYNTAX =A0 =A0 =A0RowPointer
=A0 =A0MIN-ACCESS =A0read-only
=A0 =A0DESCRIPTION
=A0 =A0 =A0 "The only valid value for XC Pointer is
=A0 =A0 =A0 =A0mplsXCTable entry."

=A0 =A0::=3D { mplsLsrExtCompliances 2 }

*) The above DESCRIPTION needs to be included in the
object's DESCRIPTION.

*) There is nothing here that specifies the readOnly compliance.
Would expect something like:

OBJECT nameOfObject
MIN-ACCESS =A0read-only
DESCRIPTION "Write access is not required."


VM>Edited.


MPLS-TE-EXT-STD-MIB
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

*) =A0 =A0 =A0 =A0 =A0DESCRIPTION
=A0 =A0 =A0 =A0 =A0"This object indicates the Global Operator Identifi= er.
=A0 =A0 =A0 =A0 =A0 This object value should be zero when
=A0 =A0 =A0 =A0 =A0 mplsTunnelExtNodeConfigIccId is configured with non-nul= l
=A0 =A0 =A0 =A0 =A0 value."

DESCRIPTION should state that the object has no meaning when
mplsTunnelExtNodeConfigIccId is valid. =A0Same comment for
mplsTunnelExtNodeConfigId.

In other words, maybe an additional object is needed to indicate
Global or ICC? =A0What if a 3rd TP id is created, then what happens?

Better to be explicite I think, than to try and overload these
objects with values that they shouldn't have.


VM>Edited.


mplsTunnelExtNodeConfigNodeId =A0OBJECT-TYPE
=A0 =A0 =A0 =A0SYNTAX =A0 =A0 =A0 =A0MplsNodeId
=A0 =A0 =A0 =A0MAX-ACCESS =A0 =A0read-create
=A0 =A0 =A0 =A0STATUS =A0 =A0 =A0 =A0current
=A0 =A0 =A0 =A0DESCRIPTION
=A0 =A0 =A0 =A0 =A0 "This object indicates the Node_ID within the oper= ator.

*) Sentence is awkward.

VM> Corrected.

mplsTunnelExtNodeConfigIccId
Similar comment to the above. =A0Additionally, how can an OCTET STRING
of size (1..6) have a zero value?

VM> Corrected.

*) mplsTunnelExtNodeConfigStorageType

Not sure I see the advantage of having this as it is
already in the MplsTunnelTable. =A0Why have 2 StorageType objects
for the same row?

VM> NodeConfig table is a separate table used to map the Global_Node_ID = and
CC::ICC identifiers with the local-id.
So, I don't see 2 Storage types.


Sorry, my error. =A0 You are correct.

VM1> OK, No problem.



*) mplsTunnelExtIngressLSRLocalIdValid and
mplsTunnelExtEgressLSRLocalIdValid
Please fix the DESCRIPTION and REFERENCE.
(Looks like the DESCRIPTION clause has been continued after the
REF clause.)


VM> I don't understand this comment. Do you expect the reference cla= use for
these two objects?


When I look at this, I see:

DESCRIPTION
=A0 =A0 =A0 =A0 =A0"This object denotes whether the mplsTunnelIngressL= SRId
=A0 =A0 =A0 =A0 =A0 contains the local value, which is used to reference =A0 =A0 =A0 =A0 =A0 the complete Ingress Global_ID::Node_ID or ICC from
=A0 =A0 =A0 =A0 =A0 the mplsTunnelExtNodeConfigTable."
=A0 =A0 =A0 =A0 REFERENCE
=A0 =A0 =A0 =A0 =A0"MPLS-TE-STD-MIB [RFC3812], Section 11. mplsTunnelI= ngressLSRId
=A0 =A0 =A0 =A0 =A0 object in mplsTunnelTable.

=A0 =A0 =A0 =A0 =A0 If this object is set to FALSE, mplsTunnelExtNodeConfig= Table
=A0 =A0 =A0 =A0 =A0 will not contain an entry to reference local identifier= with
=A0 =A0 =A0 =A0 =A0 Global_ID::Node_ID or ICC value.

=A0 =A0 =A0 =A0 =A0 This object is set to FALSE for legacy implementations = like
=A0 =A0 =A0 =A0 =A0 MPLS TE tunnels where mplsTunnelIngressId itself provid= es
=A0 =A0 =A0 =A0 =A0 complete Ingress LSRId."

So, if you look at the DESCRIPTION clause and REFERENCE clause, you can see= that
some of the text in the REFERENCE clause is more descriptive, specifically:=
=A0 =A0 =A0 =A0 =A0".....mplsTunnelIngressLSRId
=A0 =A0 =A0 =A0 =A0 object in mplsTunnelTable.

=A0 =A0 =A0 =A0 =A0 If this object is set to FALSE, mplsTunnelExtNodeConfig= Table
=A0 =A0 =A0 =A0 =A0 will not contain an entry to reference local identifier= with
=A0 =A0 =A0 =A0 =A0 Global_ID::Node_ID or ICC value.

=A0 =A0 =A0 =A0 =A0 This object is set to FALSE for legacy implementations = like
=A0 =A0 =A0 =A0 =A0 MPLS TE tunnels where mplsTunnelIngressId itself provid= es
=A0 =A0 =A0 =A0 =A0 complete Ingress LSRId."

I would not expect to find the above text in a REFERENCE clause. =A0 Does m= y original comment make sense now?

VM1> Yes, edited.=A0
Thanks,
=A0-Joan




*) mplsTunnelExtReversePerfTable

I would like to understand why noSuchInstance would be needed.
This table is a sparse augments,
so either the entry would be there or it wouldn't, right?

VM> Yes. Corrected.

*) Probably could remove the following (comment applies to other
MIB Modules also.)

=A0 =A0-- Notifications
=A0 =A0mplsTeExtNotifications OBJECT IDENTIFIER
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ::= =3D { mplsTeExtStdMIB 0 }

=A0 =A0-- Notifications.
=A0 =A0-- Notification objects need to be added here.
=A0 =A0-- End of notifications.


VM> Removed.

*) Compliance Section
ReadOnly compliance is the same as the Full Compliance.
In other words, readonly compliance does not really exist.
Please fix this.


VM> Updated.


14. Security Considerations
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
Should specify which objects would jeopardize security.


VM> Edited.

15. IANA Considerations
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Where is it? =A0This section needs to be done.


VM> Edited.

-- the end --

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



--089e014940b0c90d9f04dacf7e95-- From internet-drafts@ietf.org Sat Apr 20 13:58: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 4C27621F91C4; Sat, 20 Apr 2013 13:58:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.421 X-Spam-Level: X-Spam-Status: No, score=-102.421 tagged_above=-999 required=5 tests=[AWL=0.179, 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 VJ7ecZwBpfgN; Sat, 20 Apr 2013 13:58:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D8BE021F8D2A; Sat, 20 Apr 2013 13:58:44 -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.p3 Message-ID: <20130420205844.17818.52472.idtracker@ietfa.amsl.com> Date: Sat, 20 Apr 2013 13:58:44 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-lsp-ping-ttl-tlv-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: Sat, 20 Apr 2013 20:58: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 : Definition of Time-to-Live TLV for LSP-Ping Mechanisms Author(s) : Sami Boutros Siva Sivabalan George Swallow Shaleen Saxena Vishwas Manral Sam Aldrin Filename : draft-ietf-mpls-lsp-ping-ttl-tlv-05.txt Pages : 8 Date : 2013-04-20 Abstract: LSP-Ping is a widely deployed Operation, Administration, and Maintenance (OAM) mechanism in MPLS networks. However, in the present form, this mechanism is inadequate to verify connectivity of a segment of a Multi-Segment PseudoWire (MS-PW) from any node on the path of the MS-PW. This document defines a TLV to address this shortcoming. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-ttl-tlv There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-lsp-ping-ttl-tlv-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-lsp-ping-ttl-tlv-05 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From venkatflex@gmail.com Sat Apr 20 14:10: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 F0BF621F8607; Sat, 20 Apr 2013 14:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.333 X-Spam-Level: X-Spam-Status: No, score=-0.333 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, 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 07RTRbEB9OGO; Sat, 20 Apr 2013 14:10:53 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) by ietfa.amsl.com (Postfix) with ESMTP id D49EA21F85FC; Sat, 20 Apr 2013 14:10:52 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id h11so2475579wiv.1 for ; Sat, 20 Apr 2013 14:10:52 -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=AD9fXn5QHg4TctHnx7wa7L4RcRUxm9Cn50gNCyeZjb4=; b=O8o9HdpX36fANvV48oycZPF/ucCtD0obFr3GzD9Z/v13xKRkWYiaRm5wO/lfOnQLs8 /kZfSfnk8RrWzVzlpTNnpRC8J2eDX9xbFK+6GI8JEq2CVgg6iZOBDrUCev6xhZAqd0B0 X2Y5jmEfF9KKo1XQsCWDMiJThBx/9RCU6YT36xWE9PHvkud395TsbsrlYhcGF4F7YOQC lCstwA6kCnxo2t5sKeyhTdPt78e+BeEevLURLlBQ9L+vMbkt7OEg0klf3/K+CRychGc8 P8PLM+sImzaod/jPc477KRMETlCEc8yz+QMAXVkNbTUjk+niY1RJ5uA+w+YC7ndbeOLZ DnWw== MIME-Version: 1.0 X-Received: by 10.194.122.166 with SMTP id lt6mr24433355wjb.14.1366492252009; Sat, 20 Apr 2013 14:10:52 -0700 (PDT) Received: by 10.194.85.196 with HTTP; Sat, 20 Apr 2013 14:10:51 -0700 (PDT) In-Reply-To: <00fe01ce1ed2$72981ce0$6801a8c0@JoanPC> References: <00fe01ce1ed2$72981ce0$6801a8c0@JoanPC> Date: Sat, 20 Apr 2013 14:10:51 -0700 Message-ID: From: venkatesan mahalingam To: Joan Cucchiara Content-Type: multipart/alternative; boundary=089e01227ed844fb0a04dad145eb Cc: mpls , "MIB Doctors \(E-mail\)" , ppan@infinera.com, Sami Boutros , Kannan Sampath , Venkatesan Mahalingam , Loa Andersson Subject: Re: [mpls] MIB Doctor Review of draft-ietf-mpls-tp-oam-id-mib-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: Sat, 20 Apr 2013 21:10:55 -0000 --089e01227ed844fb0a04dad145eb Content-Type: text/plain; charset=ISO-8859-1 Joan, Please find below my comments with the tag VM>. We will publish the new version of this draft soon. -Venkat. On Mon, Mar 11, 2013 at 8:34 PM, Joan Cucchiara wrote: > > Authors, > > Most of the comments during the LC have been addressed. > Thank you for that. Please see some follow-up comments below. > > Thanks, > -Joan > > > > > * MIB compiles cleanly with smicng and smilint > > > Specific Comments: > ==================== > > Section 3.3 Acronyms > > > * MIP is specified slightly differently in the referenced docs. > Please be consistant. > VM> OK. > > > Section 6. > > This example, specifies the mplsOamIdMeMpEntry as a MEP, but why > isn't the SourceMepIndex or SinkMepIndex == mplsOamIdMeMpIndex? > > Also, there are at least 2 MEPs in an ME, and at least one ME > in a MEG and these relationships are not completely evolved > in this example. I think the example should be expanded > to agree with what is stated in the first paragraph. > > VM> OK, the example will be expanded to represent MEG->ME->Source/Sink MEPs clearly. As per this MIB module, MEG->ME->MPIndex([Source and Sink MEP] or MIP index) For example, If we have multiple MEPs in a single ME within an MEG node. MEG index - 1 ME index - 1 MP index - 1 (Source and Sink MEPs1) MP index - 2 (Source and Sink MEPs2) *Entry-1:* ME Table - 1,1,1 mplsOamIdMeSourceMepIndex - 2 mplsOamIdMeSinkMepIndex - 3 *Entry-2:* ME Table - 1,1,2 mplsOamIdMeSourceMepIndex - 4 mplsOamIdMeSinkMepIndex - 5 *MIP entry:* MEG index - 1 ME index - 1 MP index - 3 (MIP index) ME Table - 1,1,3 mplsOamIdMeMpIfIndex - MPLS incoming/outgoing interface. > MIB Module comments > ------------------- > > * TC: MplsOamPhbTCValue > > > MplsOamPhbTCValue ::= TEXTUAL-CONVENTION > STATUS current > DESCRIPTION > "This is the Per-hop Behavior (PHB) traffic class values > for the MPLS OAM operations." > SYNTAX INTEGER { > be (1), > af1 (2), > af2 (3), > af3 (4), > af4 (5), > ef (6), > cs6 (7), > cs7 (8) > } > > VM> As MPLS header traffic class (TC) field has only 3 bits, we derived the above TC values (8 possible values to represent it in 3 bits) from the below TC values. > Rfc3270, "Multi-Protocol Label Switching (MPLS) Support of > Differentiated Services", specifies that MPLS TP will use DSCP as per > rfc2474 and other specs. Is that the intent wrt this TC? > > If not, please explain where these values are defined, otherwise, > if these values are as per rfc3270, then please be consistant with the > labels. > > TC labels should correspond more closely to DiffServ BHB traffic class > values. > In other words, > > http://www.iana.org/**assignments/dscp-registry/**dscp-registry.xml > > Name Space Reference > CS0 000000 [RFC2474] > CS1 001000 [RFC2474] > CS2 010000 [RFC2474] > CS3 011000 [RFC2474] > CS4 100000 [RFC2474] > CS5 101000 [RFC2474] > CS6 110000 [RFC2474] > CS7 111000 [RFC2474] > AF11 001010 [RFC2597] > AF12 001100 [RFC2597] > AF13 001110 [RFC2597] > AF21 010010 [RFC2597] > AF22 010100 [RFC2597] > AF23 010110 [RFC2597] > AF31 011010 [RFC2597] > AF32 011100 [RFC2597] > AF33 011110 [RFC2597] > AF41 100010 [RFC2597] > AF42 100100 [RFC2597] > AF43 100110 [RFC2597] > EF PHB 101110 [RFC3246] > VOICE-ADMIT 101100 [RFC5865] > > > Continuing with that thought: I believe this TC could (and should) be > formalized into an IANA-Maintained MIB if these values are the same > as the above IANA-Maintained assignments for DFCPs. > (NOTE: this was mentioned also in the LC comments.) Please discuss. > > Also, this TC should have a REFERENCE clause. > > > > * mplsOamIdMegIndex > There is no information about how to employ mplsOamIdMegIndexNext to > obtain a value for this index. Please update the DESCRIPTION accordingly. > > > VM> Edited. > > * mplsOamIdMegOperatorType > Why does this say "should have valid values...", isn't this a MUST? > Also, s/while making/when/ > > * mplsOamIdMegIdCc > > s/contains non-null ICC/MUST contain a/ > > s/otherwise null ICC value/otherwise a null ICC value/ > > s/should be assigned/MUST be assigned/ > > * mplsOamIdMegIdIcc > > Same comments as above. Please use MUST. > > * mplsOamIdMegIdUmc > Same comments as above. Please use MUST. > > > VM> Edited. > * mplsOamIdMegServiceType > Could you please specify the service pointer by the object's name? > > Also, the references are within the DESCRIPTION which is fine, but > they should also be in a REFERENCE clause. > > > VM> Edited. > * mplsOamIdMeIndexNext and mplsOamIdMpIndexNext > These objects are not referred to by mplsOamIdMeIndex or > mplsOamIdMeMpIndex. > There is not enough description to understand how the IndexNext objects > are to be used. > > VM> Edited. > > * MplsOamIdMeTable > > The mplsOamIdMeEntry states "An entry in this table > represents MPLS-TP maintenance entity." Yet, looking at the > INDEX { mplsOamIdMegIndex, > mplsOamIdMeIndex, > mplsOamIdMeMpIndex > } > > This is not an ME because an ME by definition has 2 (source/sink)MEPs. > An entry in this table represents either a MEP or MIP, not an ME. > > VM> Yes, this is not an ME but it contains ME information (MEPs/MIP). Would it make more sense if we change it to mplsOamIdMeInfoEntry? > > *) What is the benefit of combining MEP and MIP (i.e. the objects > which contain "Mp" as part of their object name)? > Many other objects in this table, need to figure out if the entry > is describing a MEP or MIP before the value can be interpreted correctly. > Additionally, there is duplicate info in the form of having a Source and > Sink specified for each Mp. Could you elaborate on what the > benefit is of having listing MEPs and MIPs in this way? > > It seems like the original intent may have been to specify an ME > as being an entry in this table. However, that would mean the table > should probably be indexed by MEG index, a ME index, a source MEP index > and a sink MEP index. > > This would greatly simplify many of the object descriptions. > > Have you considered specifying MIPs in a 3rd table, such that each > ME would have 2 MEPs and zero or more MIPs? > > Please discuss. > > VM> We thought through all the possible options, it looks like lot of informations are duplicated unnecessarily if we have the seperate tables for MEP/MIP configurations. For up/down MEPs configurations, all the informations in the ME table will be used but for MIP, except the Source/Sink MEPs objects, all other objects will be used. So, we wanted to combine MEP/MIP in a single table for better management. So, we will certainly improvise the existing MEG&ME tables example to provide all possible configuration options. > > > *) mplsOamIdMeMpIfIndex > > Rfc6370, Section 4.discusses an IF_NUM and an IF_ID and states > "Note that IF_Num had no relation with the ifNum object defined in > RFC2863. Further, no mapping is mandated between IF_Num and ifIndex in > RFC 2863." > > I don't see any mention of ifIndex in RFC 6371, so could you tell me what > Section? Is this object supposed to represent IF_NUM in rfc6370? > VM> Reference should be replaced with rfc-6370 section4. and RFC2863 should be removed. Good catch. Thanks. > > *) mplsOamIdMeServicePointer > > The DESCRIPTION contains wording which is very loose. Could you > please use wording which specifies a "SHOULD" or "MUST"? > Under what circumstances should this be 0.0? > > VM> Edited. > > Compliance Statement of the MIB > > *) Compliance (This has been asked before and I have not seen any > discussion about it.) > > There is no read-only compliance. Has it been made clear > to the WGs (MPLS and PWE3) that SNMP sets will need to > be supported in order to be compliant with the MIB? > > VM> Not yet, sorry for the delay. We will make read-only compliance clear to WG after this draft submission. > > *) question above, about whether the intention is to support > ifIndex as per rfc2863 or IF_ID (or IF_NUM) as per rfc6370 may > affect this. > > "MODULE IF-MIB -- The Interfaces Group MIB, RFC 2863. > MANDATORY-GROUPS { > ifGeneralInformationGroup, > ifCounterDiscontinuityGroup" > > > *) mplsOamIdNotificationObjectsGr**oup OBJECT-GROUP > > I don't see a need to make a specific group for > these objects. They are already specified by mplsOamIdGroups. > > VM> Edited. > > Section 8. Security Section > > Need to reference specific read-create objects and also read-only which > could impact the network. > > Additionally, the incomplete sentence: > "These are the tables and objects and their sensitivity/vulnerability: " > needs to be completed. > > VM> Edited. > > Section 9. IANA Considerations > > s/specified this document/specified in this document/ > missing the word "in" > > > VM> Edited. > Section 11. > Thank you for the ack! > > ______________________________**_________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/**listinfo/mpls > --089e01227ed844fb0a04dad145eb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Joan,

Please find below my commen= ts with the tag VM>. We will publish the new version of this draft soon.=

-Venkat.


On Mon, Mar 11, 2013 at 8:34 PM, Joan Cu= cchiara <jcucchiara@mindspring.com> wrote:

Authors,

Most of the comments during the LC have been addressed.
Thank you for that. =A0 Please see some follow-up comments below.

Thanks,
-Joan




* MIB compiles cleanly with smicng and smilint


Specific Comments:
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Section 3.3 Acronyms


* MIP is specified slightly differently in the referenced docs.
Please be consistant.
VM> OK.=A0


Section 6.

This example, specifies the mplsOamIdMeMpEntry as a MEP, but why
isn't the SourceMepIndex or SinkMepIndex =3D=3D mplsOamIdMeMpIndex?

Also, there are at least 2 MEPs in an ME, and at least one ME
in a MEG and these relationships are not completely evolved
in this example. =A0I think the example should be expanded
to agree with what is stated in the first paragraph.

VM> OK, the example will be expanded to represent MEG->ME-&g= t;Source/Sink MEPs clearly.
As per this MIB module,
MEG->ME->MPIndex([Source and Sink MEP] or MIP index)
=
For example,

If we have mul= tiple MEPs in a single ME within an MEG node.
MEG index - 1=
ME index - 1
MP index - 1 (Source and Sink MEPs1= )
MP index - 2 (Source and Sink MEPs2)
=
Entry-1:
ME Table - 1,1,1
mplsOamIdMeSourceMepIndex - 2
mplsOamI= dMeSinkMepIndex - 3

Entry-2:
ME Table - 1,1,2
mplsOamIdMe= SourceMepIndex - 4
mplsOamIdMeSinkMepIndex - 5

<= u>MIP entry:

MEG index - 1
ME index - 1
MP index - 3 (MIP index)
ME Table - 1,1,3
mplsOamIdMeMpIfIndex - MPLS incom= ing/outgoing interface.

=A0
MIB Module comments
-------------------

* TC: =A0MplsOamPhbTCValue


=A0 =A0 =A0 =A0 MplsOamPhbTCValue ::=3D TEXTUAL-CONVENTION
=A0 =A0 =A0 =A0 =A0 =A0STATUS =A0 =A0 =A0 =A0 =A0 =A0 =A0current
=A0 =A0 =A0 =A0 =A0 =A0DESCRIPTION
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"This is the Per-hop Behavior (PHB) tra= ffic class values
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 for the MPLS OAM operations."
=A0 =A0 =A0 =A0 =A0 =A0SYNTAX =A0 =A0 =A0 =A0INTEGER {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0be (1),
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0af1 (2),
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0af2 (3),
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0af3 (4),
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0af4 (5),
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ef (6),
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cs6 (7),
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0cs7 (8)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}

VM> As MPLS header traffic class (TC) field has only 3 bits, we= derived the above TC values (8 possible values to represent it in 3 bits) = from the below TC values.
=A0
Rfc3270, "Multi-Protocol Label Switching (MPLS) Support of
Differentiated Services", specifies that MPLS TP will use DSCP as per<= br> rfc2474 and other specs. =A0 Is that the intent wrt this TC?

If not, please explain where these values are defined, otherwise,
if these values are as per rfc3270, then please be consistant with the labe= ls.

TC labels should correspond more closely to DiffServ BHB traffic class valu= es.
In other words,

http://www.iana.org/assignments/dscp-registry/= dscp-registry.xml

=A0 Name =A0 =A0 Space =A0Reference
=A0 CS0 =A0 =A0 =A0 =A0 000000 [RFC2474]
=A0 CS1 =A0 =A0 =A0 =A0 001000 [RFC2474]
=A0 CS2 =A0 =A0 =A0 =A0 010000 [RFC2474]
=A0 CS3 =A0 =A0 =A0 =A0 011000 [RFC2474]
=A0 CS4 =A0 =A0 =A0 =A0 100000 [RFC2474]
=A0 CS5 =A0 =A0 =A0 =A0 101000 [RFC2474]
=A0 CS6 =A0 =A0 =A0 =A0 110000 [RFC2474]
=A0 CS7 =A0 =A0 =A0 =A0 111000 [RFC2474]
=A0 AF11 =A0 =A0 =A0 =A0001010 [RFC2597]
=A0 AF12 =A0 =A0 =A0 =A0001100 [RFC2597]
=A0 AF13 =A0 =A0 =A0 =A0001110 [RFC2597]
=A0 AF21 =A0 =A0 =A0 =A0010010 [RFC2597]
=A0 AF22 =A0 =A0 =A0 =A0010100 [RFC2597]
=A0 AF23 =A0 =A0 =A0 =A0010110 [RFC2597]
=A0 AF31 =A0 =A0 =A0 =A0011010 [RFC2597]
=A0 AF32 =A0 =A0 =A0 =A0011100 [RFC2597]
=A0 AF33 =A0 =A0 =A0 =A0011110 [RFC2597]
=A0 AF41 =A0 =A0 =A0 =A0100010 [RFC2597]
=A0 AF42 =A0 =A0 =A0 =A0100100 [RFC2597]
=A0 AF43 =A0 =A0 =A0 =A0100110 [RFC2597]
=A0 EF PHB =A0 =A0 =A0101110 [RFC3246]
=A0 VOICE-ADMIT 101100 [RFC5865]


Continuing with that thought: I believe this TC could (and should) be
formalized into an IANA-Maintained MIB if these values are the same
as the above IANA-Maintained assignments for DFCPs.
(NOTE: this was mentioned also in the LC comments.) =A0Please discuss.

Also, this TC should have a REFERENCE clause.



* mplsOamIdMegIndex
There is no information about how to employ mplsOamIdMegIndexNext to
obtain a value for this index. =A0 Please update the DESCRIPTION accordingl= y.


VM> Edited.=A0

* mplsOamIdMegOperatorType
Why does this say "should have valid values...", isn't this a= MUST?
Also, s/while making/when/

* mplsOamIdMegIdCc

s/contains non-null ICC/MUST contain a/

s/otherwise null ICC value/otherwise a null ICC value/

s/should be assigned/MUST be assigned/

* mplsOamIdMegIdIcc

Same comments as above. =A0 Please use MUST.

* mplsOamIdMegIdUmc
Same comments as above. =A0Please use MUST.


VM> Edited.=A0
* mplsOamIdMegServiceType
Could you please specify the service pointer by the object's name?

Also, the references are within the DESCRIPTION which is fine, but
they should also be in a REFERENCE clause.


VM> Edited.=A0
* mplsOamIdMeIndexNext and mplsOamIdMpIndexNext
These objects are not referred to by mplsOamIdMeIndex or mplsOamIdMeMpIndex= .
There is not enough description to understand how the IndexNext objects
are to be used.

VM> Edited.=A0

* MplsOamIdMeTable

The mplsOamIdMeEntry states "An entry in this table
represents MPLS-TP maintenance entity." =A0 Yet, looking at the
=A0 =A0 =A0 =A0 =A0 =A0 =A0INDEX { mplsOamIdMegIndex,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mplsOamIdMeIndex,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0mplsOamIdMeMpIndex
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}

This is not an ME because an ME by definition has 2 (source/sink)MEPs.
An entry in this table represents either a MEP or MIP, not an ME.

VM> Yes, this is not an ME but it contains M= E information (MEPs/MIP).=A0
Would it make more sense if we= change it to mplsOamIdMeInfoEntry?=A0

*) What is the benefit of combining MEP and MIP (i.e. the objects
which contain "Mp" as part of their object name)?
Many other objects in this table, need to figure out if the entry
is describing a MEP or MIP before the value can be interpreted correctly. Additionally, there is duplicate info in the form of having a Source and Sink specified for each Mp. Could you elaborate on what the
benefit is of having listing MEPs and MIPs in this way?

It seems like the original intent may have been to specify an ME
as being an entry in this table. =A0However, that would mean the table
should probably be indexed by MEG index, a ME index, a source MEP index
and a sink MEP index.

This would =A0greatly simplify many of the object descriptions.

Have you considered specifying MIPs in a 3rd table, such that each
ME would have 2 MEPs and zero or more MIPs?

Please discuss.

VM> We thought through all the possible options, i= t looks like lot of informations are duplicated=A0unnecessarily if we have = the seperate tables for MEP/MIP configurations. For up/down MEPs configurat= ions, all the informations in the ME table will be used but for MIP, except= the Source/Sink MEPs objects, all other objects will be used. So, we wante= d to combine MEP/MIP in a single table for better management.

So, we will certainly improvise the existing MEG&ME= tables example to provide all possible configuration options.=A0


*) mplsOamIdMeMpIfIndex

Rfc6370, Section 4.discusses an IF_NUM and an IF_ID and states
"Note that IF_Num had no relation with the ifNum object defined in
RFC2863. =A0Further, no mapping is mandated between IF_Num and ifIndex in RFC 2863."

I don't see any mention of ifIndex in RFC 6371, so could you tell me wh= at
Section? =A0 Is this object supposed to represent IF_NUM in rfc6370?
VM> Reference should be replaced with rfc-6370 sect= ion4.=A0
and RFC2863 should be removed. Good catch. Thanks.=

*) mplsOamIdMeServicePointer

The DESCRIPTION contains wording which is very loose. =A0Could you
please use wording which specifies a "SHOULD" or "MUST"= ?
Under what circumstances should this be 0.0?

VM> Edited.=A0

Compliance Statement of the MIB

*) Compliance (This has been asked before and I have not seen any discussio= n about it.)

There is no read-only compliance. Has it been made clear
to the WGs (MPLS and PWE3) that SNMP sets will need to
be supported in order to be compliant with the MIB?

VM> Not yet, sorry for the delay. We will ma= ke read-only compliance clear to WG after this draft submission.=A0

*) question above, about whether the intention is to support
ifIndex as per rfc2863 or IF_ID (or IF_NUM) as per rfc6370 may
affect this.

=A0 =A0 =A0"MODULE IF-MIB -- The Interfaces Group MIB, RFC 2863.
=A0 =A0 =A0MANDATORY-GROUPS {
=A0 =A0 =A0 =A0 ifGeneralInformationGroup,
=A0 =A0 =A0 =A0 ifCounterDiscontinuityGroup"


*) =A0 =A0mplsOamIdNotificationObjectsGroup =A0OBJECT-GROUP

I don't see a need to make a specific group for
these objects. =A0They are already specified by mplsOamIdGroups.

VM> Edited.=A0

Section 8. Security Section

Need to reference specific read-create objects and also read-only which
could impact the network.

Additionally, the incomplete sentence:
"These are the tables and objects and their sensitivity/vulnerability:= "
needs to be completed.

VM> Edited.=A0

Section 9. =A0IANA Considerations

s/specified this document/specified in this document/
missing the word "in"


VM> Edited.=A0
Section 11.
Thank you for the ack!

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

--089e01227ed844fb0a04dad145eb-- From Alexander.Vainshtein@ecitele.com Sun Apr 21 08:45: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 3F3A321F8D6A for ; Sun, 21 Apr 2013 08:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, 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 AI5pw8hAakjz for ; Sun, 21 Apr 2013 08:45:43 -0700 (PDT) Received: from mail1.bemta5.messagelabs.com (mail1.bemta5.messagelabs.com [195.245.231.152]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0C621F8C1A for ; Sun, 21 Apr 2013 08:45:40 -0700 (PDT) Received: from [85.158.139.211:63290] by server-16.bemta-5.messagelabs.com id 2C/0F-02543-89904715; Sun, 21 Apr 2013 15:45:28 +0000 X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-2.tower-206.messagelabs.com!1366559127!19460713!2 X-Originating-IP: [147.234.242.234] X-StarScan-Received: X-StarScan-Version: 6.8.6.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 27442 invoked from network); 21 Apr 2013 15:45:28 -0000 Received: from ilptbmg01-out.ecitele.com (HELO ilptbmg01-out.ecitele.com) (147.234.242.234) by server-2.tower-206.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 21 Apr 2013 15:45:28 -0000 X-AuditID: 93eaf2e7-b7f2e6d000002815-9f-51740996ed48 Received: from ILPTEXCH02.ecitele.com ( [147.234.245.181]) by ilptbmg01-out.ecitele.com (Symantec Messaging Gateway) with SMTP id 7C.30.10261.69904715; Sun, 21 Apr 2013 18:45:27 +0300 (IDT) Received: from ILPTWPVEXCA01.ecitele.com (172.31.244.224) by ILPTEXCH02.ecitele.com (147.234.245.181) with Microsoft SMTP Server (TLS) id 8.3.264.0; Sun, 21 Apr 2013 18:45:26 +0300 Received: from ILPTWPVEXMB02.ecitele.com ([fe80::5979:ca8d:419f:56df]) by ILPTWPVEXCA01.ecitele.com ([fe80::ac15:43ab:d541:dfa7%12]) with mapi id 14.02.0328.009; Sun, 21 Apr 2013 18:45:26 +0300 From: Alexander Vainshtein To: "Eric Osborne (eosborne)" Thread-Topic: PSC: draft-rhd-mpls-tp-psc-sd-00 Thread-Index: Ac47ZjCR0vbHo3uJROyqNlG6qZXPnwDP/26g Date: Sun, 21 Apr 2013 15:45:25 +0000 Message-ID: References: <20ECF67871905846A80F77F8F4A27572101502B9@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A27572101502B9@xmb-rcd-x09.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.4.33.32] Content-Type: text/plain; charset="us-ascii" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Brightmail-Tracker: H4sIAAAAAAAAA3VTbUgUURTl7azrrDn6WjXfLlHjWCtka24WGLUWhKiQpRQU9aOm3dfu1O7s tDNaRj+UMMigEtlSqaywMhUqDVIrNu1TpQ8qsaQySAo/IFujMrKacdSEaH6d+85559x53EsS hqJQE8nxEvbxrJvRhWnLBoJfLCf0Um7y7UEytef8pZBVILO6elSTAzYXghUsz3slVsK0A4t2 G5Pj4/JZewFDcw4bY2Vowc3asQfzko1hBQHzDiYtjP7nWyHLOJ7GvN3r4Hinjclav86Smrp0 mcXKpJnjrSnLwza4OJHGFg/LuWkPFkXWiWn5ZNs1wnX8WDsQOiP3fhvuJwpBU3gJ0JMILkGf x66GqngWevr2sq4EhJEGGADo5J06oBZNAI09eDZR3APoUOcHoFzRQRtqqHujU3A0XIyOXg9o FBEBuwEKPvipUYgomIRayt5rVdEi9LrmEZi8cLrzZkgJIEktnI9etBqVYwrmoIP3i8flBrgG 1dceGPfXw2zU2/p7HAO51W8d9eP2BIxFPX1VGvUXIKq++YRQcQzqf/8rRMVzUN9dP6HqF6Iz N4I6FSeiC2cHCTV3Jmqv6JvItaCOhyUTnkbUWvNSewwYK6fFVU6zqpxmVTnN6gzQ1oIYzi1I 2z3OZGsStnMSduMku9fTANSZ+dgEflTNawOQBEw4JXz35RpC2HyxwNMGjKSGiaHEUCnXELHd 6yhwsaJrqy/PjcU2gEiCiabW6GSOcrAF+7DPO0mly49ZSphm2L3ydPLS1pTk5P8XTCx1sXDj OgN0yrO5C2MB+yZ9ZpMkgyg/KUfM9GEn3ruDc0t/aQ2pV9oIl9uoUzSUKLAekXOqfAewkDWN /YPAoOW9PDbFUg2KCCoiVx4/5TO5OQMgVn6AKKpRUYXLezXlNCCHaOSQkRm7lRB5h6YoUyFo ZzKKzK/K1z5Oyx7TV+QOPYV9zUdPsXFF77Z83RSZ3hsMBs75/c3mjIquw/tLXS1XyRpvy/Py H/GfupqWb2se3Xdg+G7WhcY497XMK4Q5kHg9ISLTPLpzXs+etpHAo+fG2o/dWfTi4nO3hlI7 VjbvF4L+6N6E1W8WHEmYa4KjYxsYrehirQsIn8j+AZ8n7bYUBAAA Cc: "mpls@ietf.org" , Shell Nakash , Gideon Agmon Subject: Re: [mpls] PSC: draft-rhd-mpls-tp-psc-sd-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: Sun, 21 Apr 2013 15:45:44 -0000 Eric, and all, The issue has been discussed actively in the past. I can only re-state my position during these discussions, namely that there= is no way to define a reasonable analog of Signal Degrade (SD) in MPLS and,= by implication, in the MPLS-TP data plane. By "reasonable" here I mean a me= thod that does not depend on the actual traffic going thru the LSP. The fact that we could not reach any consensus for such a definition in the= past is not, of course, a mathematical proof of non-existence of SD. But it is a good indication of a fundamental problem IMO. As a consequence, IMHO and FWIW, there is no need in defining SD-related sta= te transitions, behavior etc. My 2c, Sasha > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Er= ic > Osborne (eosborne) > Sent: Wednesday, April 17, 2013 3:26 PM > To: mpls@ietf.org > Subject: [mpls] PSC: draft-rhd-mpls-tp-psc-sd-00 > > This thread is for discussing draft-rhd-mpls-tp-psc-sd-00. The draft prov= ided > extensions to the PSC state machine to handle Signal Degrade (SD). It doe= s not > define SD or provide scope around where or how SD may be used. There are > some expired drafts that touch on the definition and use of SD, including: > > draft-zhl-mpls-tp-sd-03 > draft-rkhd-mpls-tp-sd-03 > > (this is not an exhaustive list. It's the top two google hits.) > > > The questions I think are relevant are: > > - do we need an SD mechanism in MPLS-TP? > - if so, is it reasonable to define state transitions for it before we hav= e defined > SD itself? > - if yes to both of the above, does this draft provide the right behavior?= Are > there alternative approaches? > > but of course any and all discussion is welcome. > > > > eric > > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls 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 Mon Apr 22 01: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 813A821F8CA5; Mon, 22 Apr 2013 01:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.010, 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 axpo-4BtFa1x; Mon, 22 Apr 2013 01:03:36 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE69121F8CDD; Mon, 22 Apr 2013 01:03:36 -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.p3 Message-ID: <20130422080336.24639.47174.idtracker@ietfa.amsl.com> Date: Mon, 22 Apr 2013 01:03:36 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-tp-mip-mep-map-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, 22 Apr 2013 08:03: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 : Per-Interface MIP Addressing Requirements and Design Con= siderations Author(s) : Adrian Farrel Hideki Endo Rolf Winter Yoshinori Koike Manuel Paul Filename : draft-ietf-mpls-tp-mip-mep-map-07.txt Pages : 12 Date : 2013-04-22 Abstract: The Framework for Operations, Administration and Maintenance (OAM) within the MPLS Transport Profile (MPLS-TP) describes how Maintenance Entity Group Intermediate Points (MIPs) may be situated within network nodes at the incoming and outgoing interfaces. This document elaborates on important considerations for internal MIP addressing. More precisely it describes important restrictions for any mechanism that specifies a way of forming OAM messages so that they can be targeted at MIPs on incoming or MIPs on outgoing interfaces and forwarded correctly through the forwarding engine. Furthermore, the document includes considerations for node implementations where there is no distinction between the incoming and outgoing MIP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-mip-mep-map There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-mip-mep-map-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-mip-mep-map-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From sriganesh.kini@ericsson.com Mon Apr 22 01:32: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 04C0321F8E74 for ; Mon, 22 Apr 2013 01:32:11 -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 FEOwpd10U+zi for ; Mon, 22 Apr 2013 01:32:10 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3D04E21F8E42 for ; Mon, 22 Apr 2013 01:32:10 -0700 (PDT) X-AuditID: c618062d-b7f0d6d00000097e-0d-5174f588ad79 Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 9D.14.02430.885F4715; Mon, 22 Apr 2013 10:32:08 +0200 (CEST) Received: from EUSAAMB101.ericsson.se ([147.117.188.118]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.02.0318.004; Mon, 22 Apr 2013 04:32:07 -0400 From: Sriganesh Kini To: Loa Andersson , "Dutta, Pranjal K (Pranjal)" , "Rajiv Asati (rajiva)" , Xuxiaohu , "draft-atlas-mpls-te-express-path@tools.ietf.org" , "mpls-chairs@tools.ietf.org" Thread-Topic: MPLS-RT review of draft-atlas-mpls-te-express-path Thread-Index: AQHOMoJaE1WUA/f8Qk27UW4gIXh46Jjh4TQA Date: Mon, 22 Apr 2013 08:32:06 +0000 Message-ID: <95453A37E413464E93B5ABC0F8164C4D06CA10@eusaamb101.ericsson.se> In-Reply-To: <515FA9AF.7080705@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: [147.117.188.134] Content-Type: text/plain; charset="us-ascii" Content-ID: <6FEED7B085F1A3498763F2119277E0EF@ericsson.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyuXSPt27H15JAg28rVCx2XjjEZPFv7hxm i++XlrBY3Fq6ktXizpxVbBZ//z5itth6fhWjA7tH67O9rB5Tfm9k9Wg58pbVY8mSn0wes6a3 sXl8ufyZLYAtissmJTUnsyy1SN8ugStj387dLAVrpCrePJ/H3MD4QqSLkZNDQsBEYu7RfkYI W0ziwr31bF2MXBxCAkcZJX5/vsYC4SxnlHh1agU7SBWbgJHEhbvzWUBsEYHLTBI3+oHiHBzM AsoSp+7KgISFBewlOi4vYQQJiwg4SMyeHA1RbSRxaFELM4jNIqAq8ezaFzYQm1fAW+Lhs7tg 0zmB4n9O3WYCsRmB7vl+ag2YzSwgLnHryXwmiDsFJJbsOc8MYYtKvHz8jxXEFhXQk2g7doYd Iq4sseTJfhaIXh2JBbs/sUHY1hJzVv5lhLC1JZYtfM0McYOgxMmZT1gmMIrPQrJuFpL2WUja ZyFpn4WkfQEj6ypGjtLi1LLcdCODTYzAaD0mwaa7g3HPS8tDjNIcLErivEGuFwKEBNITS1Kz U1MLUovii0pzUosPMTJxcEo1MO6RD+RWS7wWt28ZW+U9h+NZ0V+0rzgX7muPqlB5ZL5WqXCC 25f5oednHBUMrnzGEp/6q2riYW+Xf8YewWvq9uv9LDiVtz1q3mWLMzmZ708Xfp68IdHD+5lq k8JeDUWlkwaaX0/LB/ncj3pp7sCbI+O3e1luXGjyglau/K3pSfUaXzcvYQpvVGIpzkg01GIu Kk4EAEsHAQ6kAgAA Cc: "mpls@ietf.org" Subject: Re: [mpls] MPLS-RT review of draft-atlas-mpls-te-express-path 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, 22 Apr 2013 08:32:11 -0000 Hello Loa, Overall I think the document is addressing a useful problem but needs an update to make it more coherent and sound before going to WG acceptance call. My comments are listed below - 1. The filename "mpls-te-express-path" has no correlation to the title and content of the draft. I would suggest a more appropriate filename such as "mpls-te-path-selection-mechanism". 2. The "Short Title" should be changed to reflect that this is a path selection mechanism. Suggest "Simple path selection mechanism". 3. Abstract last sentence is better worded as "This document specifies a computationally simpler mechanism to select performance-constraint-bounded paths by using performance data advertised via an IGP" 4. It is not clear why there is a dependence on the performance data being advertised via IGP. Can't it come from other sources. E.g. a management system ? 5. The limitations of the path computed due to the scope of link-state advertisements should be stated. E.g. if the referenced docs for IGP extensions have area scoped performance-data advertisements, then the head-end may not be able to compute paths beyond the area. 6. Section 1.1 enum 3 - s/perforance/performance 7. Section 1.1 enum 4 suggest s/configuration/constraints 8. Section 2.1 - Need a reference for CSPF algorithm being referred to. It may be of value to write an appendix that gives pseudocode on how the constraint checking is inserted into the CSPF. 9. Section 2.1 - In the paragraph starting with "This is illustrated as follows.". It may be useful to state that there are cases where all the links of X when explored may violate the bounded constraint the algorithm should backtrack from the point where the bounded constraint was still being satisfied. 10. Sec 2.3.3 - Is this an optimization of when to re-optimize ? Because any link coming out of Anomalous may provide a better path, not just a link that caused LSPs to change when it went to the Anomalous state. If so, it may be useful to state it. Also this document should be posted to the PCE WG for comments. Thanks -- Sri On 4/5/13 9:50 PM, "Loa Andersson" wrote: >Xiaohu, Sri, Rajiv and Pranjal, > >You have been selected as an MPLS Review team reviewers for >draft-atlas-mpls-te-express-path-02. > >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 April 20, 2013? > >Thanks, Loa >(as MPLS WG chair) > >/Loa >--=20 > > >Loa Andersson email: loa@mail01.huawei.com >Senior MPLS Expert loa@pi.nu >Huawei Technologies (consultant) phone: +46 739 81 21 64 From martin.vigoureux@alcatel-lucent.com Mon Apr 22 08:30: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 F419D21F902B for ; Mon, 22 Apr 2013 08:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.449 X-Spam-Level: X-Spam-Status: No, score=-109.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_NAIL=2.3, 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 ETnZduuST6eo for ; Mon, 22 Apr 2013 08:30:11 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 2697B21F8D70 for ; Mon, 22 Apr 2013 08:30:11 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r3MFU711027116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 22 Apr 2013 10:30:08 -0500 (CDT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id r3MFU5MY002062 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Apr 2013 11:30:07 -0400 Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by US70TWXCHHUB04.zam.alcatel-lucent.com (135.5.2.36) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 22 Apr 2013 11:30:06 -0400 Received: from [172.27.205.176] (135.239.27.40) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 22 Apr 2013 17:29:46 +0200 Message-ID: <5175576A.5030700@alcatel-lucent.com> Date: Mon, 22 Apr 2013 17:29:46 +0200 From: Martin Vigoureux Organization: Alcatel-Lucent User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: , , , Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [135.239.27.40] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 Cc: mpls@ietf.org Subject: [mpls] MPLS-RT review of draft-wijnands-mpls-mldp-node-protection-02 and of draft-zhao-mpls-mldp-protections-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: Mon, 22 Apr 2013 15:30:12 -0000 Hello, I have reviewed draft-wijnands-mpls-mldp-node-protection-02 and draft-zhao-mpls-mldp-protections-03 Relating to the specific question asked to the reviewers: The documents describe two different ways of achieving the same useful thing (mLDP node protection). * I do not think the two documents should be merged * draft-wijnands-mpls-mldp-node-protection-02 is more ready to be progressed as WG document than draft-zhao-mpls-mldp-protections-03 is. * If both documents were to be progressed as WG documents, an applicability document providing for example information on the situations in which a solution is more desirable than the other, if relevant, and/or a discussion on the scalability of the approaches, and/or on the capability to effectively find disjoint paths in such contexts, and/or on the use of such mechanism(s) in conjunction with other protection mechanisms, ..., might be valuable for those wishing to deploy such technology/ies. Note that the last two points are relevant even if a single document is progressed. Please see below my observations for the two documents. -m --- draft-wijnands-mpls-mldp-node-protection-02 General * well written and quite concise but at the expense of a perfectly clear description of the procedures which would thus benefit from extra clarification * the document is coherent, useful and technically sound, yet it could benefit from a discussion on the scalability of the proposed solution especially with regards to the t-ldp sessions. * the document is ready to be considered for WG adoption. * Some "must" might need to be capitalized Section 2.2 s/N's/N/ In order to protect node N, all the members of the MP2MP must participate in protecting node N by acting both as PLR and MPT LSR. Is it really all the members of the MP2MP LSP or only the LDP peers of the root? Confusion can come from the fact that figure 2 shows a very simple MP2MP LSP where all members of the LSP are also directly-connected-to-N members Section 2.3 s/If the PLR address on N changes for a give MP LSP/If the PLR address on N changes for a given MP LSP/ Section 3 s/the PLR would have assign a Label Mapping/the PLR would have assigned a Label Mapping/ Section 4 and Section 5 These sections need a bit more work to clarify the procedures and sequence of events, so as to lift potential misunderstandings. With regards to the reachability of N. Beginning of Section 4 the text says: When LSR1 discovered that node N is unreachable, it can't determine whether it is the 'LSR1 - N' link or node N that failed. but first paragraph of Section 5 says: The procedures following are depending on whether the link 'LSR1 - N' has failed or node N itself. The two pieces of text seem contradictory. Information should be given on how (and when?) the distinction could be made. Also, with regards to the reachability of N, it should be clarified if it is only considered through the 'LSR1 - N' link or not. Also, the two following sentences seem to contradict each other: If only the link failed, LSR2 and LSR3 will receive duplicate packets due to the two protection mechanisms. To prevent duplicate packets to be forwarded to LSR2 and LSR3, either the primary upstream LSRs or the secondary upstream LSRs should be forwarding MPLS packets, but never both at the same time. The first one says that duplicate packets will be received while the second says that duplicate packets should not be received. Strictly speaking it seems that duplicate packets will be received by LSR2 and LSR3 but be dropped and that it will be the case until label is withdrawn, and from that point on no duplicate traffic will be received. Also, in Section 4 the use of forwarding is somehow misleading. Indeed, rather than which primary or secondary LSR forwards the packets, the point seems to be more about which primary or secondary LSR do the MPTs decide to receive traffic from. Section 5.1 and 5.2 Similarly to a previous remark, it appears that LSR2 and LSR3 need to be able to make a distinction between 'LSR1 - N' link failure and node N failure. While I understand that both the capability to detect that N is unreachable and the capability to make a distinction between the two types of failures is outside of the scope of the document, I believe that the described procedures strongly depends on this capability. If so, I would suggest to add somewhere something like "It MUST be possible to distinguish 'LSR1 - N' link failure from node N failure". One could wonder why Section 5.1 and 5.2 are not in Section 4. Section 5.2 If N is still reachable why does LSR1 invoke the node protection mechanism? More generally, the procedures described in the document are based on the fact that both protection mechanisms are invoked while Section 4 states that is is only a MAY. Section 5.3 LSR1 will find that M is its new primary upstream LSR to reach the Root and LSR3 will find Q. I guess what was meant is: LSR2 will find that P is its new primary upstream LSR to reach the Root and LSR3 will find Q. Also I tend to think that M should be switched to P in: As soon as the new primary upstream LSRs M and Q are activated, Section 10.1 Update reference for draft-napierala-mpls-targeted-mldp --- --- draft-zhao-mpls-mldp-protections-03 * The document substantially lacks coherency and clarity. It seems that the intent was to be exhaustive in the cases/options covered but this is at the expense of readability/understandability. * Also, and more importantly, there are indications that parts of the solution are still incomplete from a design perspective (qualified as "TBD" or requiring further research, e.g., Section 4.2, 4.3.1, 5.). * Also, while the discussion on disjointness is in principle interesting and valuable, the way it is currently covered in the document participates to making it hard to read. * The document would also benefit from resolving a good number of phrasing/wording/editorial issues. As such, I do not think the document is ready to be considered for WG adoption. A substantial revision seems necessary before being able to appropriately assess the document. --- From eosborne@cisco.com Mon Apr 22 10:45: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 6EBEB21F912C for ; Mon, 22 Apr 2013 10:45:21 -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 b7gEneQnUbQe for ; Mon, 22 Apr 2013 10:45:20 -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 5F8B021F8E99 for ; Mon, 22 Apr 2013 10:45:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3398; q=dns/txt; s=iport; t=1366652720; x=1367862320; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4kBAWN1uyZusmDw5N60QLjPrUujeaRcvvCywHvdymxU=; b=eLh1K7AhQhwSQbwdZnBHweS64NSZuK0BC3wEOBV5+NULbF8p+HJousRC 1QvBhwPsCb1c9wRlaEubQ2f8CguvLYtgQ28SowKgrbH9OmnwZ25EmyY9Z YWwj4XFd0mwkpfnkaqny6RLbBvR80hOEAAuXm4eiyw+H10nRNQ3A9pIQU g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAN12dVGtJXG//2dsb2JhbABPgwY2wQGBBhZ0gh8BAQEEAQEBNzQLDAQCAQgRBAEBCxQJBycLFAkIAQEEDgUIiAwMu00Ejg2BATEHBoJgYQOoL4MMgXM1 X-IronPort-AV: E=Sophos;i="4.87,528,1363132800"; d="scan'208";a="201602278" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 22 Apr 2013 17:45:08 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r3MHj8JQ007013 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Apr 2013 17:45:08 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.83]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Mon, 22 Apr 2013 12:45:07 -0500 From: "Eric Osborne (eosborne)" To: Alexander Vainshtein Thread-Topic: PSC: draft-rhd-mpls-tp-psc-sd-00 Thread-Index: Ac47ZjCR0vbHo3uJROyqNlG6qZXPnwDP/26gADajjMA= Date: Mon, 22 Apr 2013 17:45:06 +0000 Message-ID: <20ECF67871905846A80F77F8F4A275721015649D@xmb-rcd-x09.cisco.com> References: <20ECF67871905846A80F77F8F4A27572101502B9@xmb-rcd-x09.cisco.com> In-Reply-To: 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 Cc: "mpls@ietf.org" , Shell Nakash , Gideon Agmon Subject: Re: [mpls] PSC: draft-rhd-mpls-tp-psc-sd-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: Mon, 22 Apr 2013 17:45:21 -0000 Hi Sasha- I tend to agree. I fully admit that PSC is a little inconsistent in these= matters, in that it provides a place for SD in the alarm hierarchy but not= in the state machine. However, I see little point in adding all the SD st= ate machinery before we have some sort of SD mechanism. It may be that we = come up with an SD mechanism that is more powerful than its analog in the t= ransport world, and it might provide operators with significant flexibility= that wouldn't be possible with the current proposal. Why come up with highway legislation that describes the rules of the road= for flying hovercars prior to inventing the flying hovercar? eric > -----Original Message----- > From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] > Sent: Sunday, April 21, 2013 11:45 AM > To: Eric Osborne (eosborne) > Cc: mpls@ietf.org; Rotem Cohen; Gideon Agmon; Yechiel Rosengarten; Shell > Nakash > Subject: RE: PSC: draft-rhd-mpls-tp-psc-sd-00 >=20 > Eric, and all, > The issue has been discussed actively in the past. >=20 > I can only re-state my position during these discussions, namely that the= re is no > way to define a reasonable analog of Signal Degrade (SD) in MPLS and, by > implication, in the MPLS-TP data plane. By "reasonable" here I mean a met= hod > that does not depend on the actual traffic going thru the LSP. >=20 > The fact that we could not reach any consensus for such a definition in t= he past > is not, of course, a mathematical proof of non-existence of SD. > But it is a good indication of a fundamental problem IMO. >=20 > As a consequence, IMHO and FWIW, there is no need in defining SD-related > state transitions, behavior etc. >=20 > My 2c, > Sasha >=20 > > -----Original Message----- > > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf > > Of Eric Osborne (eosborne) > > Sent: Wednesday, April 17, 2013 3:26 PM > > To: mpls@ietf.org > > Subject: [mpls] PSC: draft-rhd-mpls-tp-psc-sd-00 > > > > This thread is for discussing draft-rhd-mpls-tp-psc-sd-00. The draft > > provided extensions to the PSC state machine to handle Signal Degrade > > (SD). It does not define SD or provide scope around where or how SD > > may be used. There are some expired drafts that touch on the definitio= n and > use of SD, including: > > > > draft-zhl-mpls-tp-sd-03 > > draft-rkhd-mpls-tp-sd-03 > > > > (this is not an exhaustive list. It's the top two google hits.) > > > > > > The questions I think are relevant are: > > > > - do we need an SD mechanism in MPLS-TP? > > - if so, is it reasonable to define state transitions for it before we > > have defined SD itself? > > - if yes to both of the above, does this draft provide the right > > behavior? Are there alternative approaches? > > > > 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 > This e-mail message is intended for the recipient only and contains infor= mation > which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you > have received this transmission in error, please inform us by e-mail, pho= ne or > fax, and then delete the original and all copies thereof. From gregory.mirsky@ericsson.com Mon Apr 22 10:57: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 E407C21F93CC for ; Mon, 22 Apr 2013 10:57:39 -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 pCbtkN8EYoHN for ; Mon, 22 Apr 2013 10:57:39 -0700 (PDT) Received: from usevmg20.ericsson.net (usevmg20.ericsson.net [198.24.6.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2877F21F93BE for ; Mon, 22 Apr 2013 10:57:39 -0700 (PDT) X-AuditID: c618062d-b7f0d6d00000097e-13-51757a12ceef Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg20.ericsson.net (Symantec Mail Security) with SMTP id 11.2C.02430.21A75715; Mon, 22 Apr 2013 19:57:38 +0200 (CEST) Received: from EUSAAMB106.ericsson.se ([147.117.188.123]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.02.0318.004; Mon, 22 Apr 2013 13:57:38 -0400 From: Gregory Mirsky To: Alexander Vainshtein , "Eric Osborne (eosborne)" Thread-Topic: PSC: draft-rhd-mpls-tp-psc-sd-00 Thread-Index: Ac47ZjCR0vbHo3uJROyqNlG6qZXPnwDP/26gADbl9CA= Date: Mon, 22 Apr 2013 17:57:36 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B48605B@eusaamb106.ericsson.se> References: <20ECF67871905846A80F77F8F4A27572101502B9@xmb-rcd-x09.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+NgFnrILMWRmVeSWpSXmKPExsUyuXRPiK5QVWmgwarZuhZTt35gtmias5nR om3xIjaLW0tXslq8ezOLyYHVY8rvjawem/4dZ/RYsuQnUwBzFJdNSmpOZllqkb5dAlfG64mn 2Ap+iVdcWP2VpYFxm3AXIyeHhICJRNfudUwQtpjEhXvr2UBsIYGjjBIHN5h1MXIB2csZJT7/ OccMkmATMJJ4sbGHHcQWEciVeLJ6J1ADBwezQLnEv2mCIGFhAT2JXZMfs0CU6EvcWXGWEcK2 kjh4YBYriM0ioCpx4vt9sJG8Ar4SR37tY4HYNZlR4uPMnWANnAKBEntausBsRqDjvp9aA3Yo s4C4xK0n86GOFpBYsuc8M4QtKvHy8T9WCFtZYsmT/SwQ9ToSC3Z/YoOwtSWWLXwNtVhQ4uTM JywTGMVmIRk7C0nLLCQts5C0LGBkWcXIUVqcWpabbmSwiREYTcck2HR3MO55aXmIUZqDRUmc N8j1QoCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxuoXpTpXTS6mS04zuC+XwKy2ekJf0u9g hwkMYbOUJr6JebrhA6OUxIKmqsaeHmk+4+ScEpk1RaWpWz5s+PqTJzxHSaqvJjPsscSOG2F7 q42t3ZLlt/fUWfK/+hYj0fD4vN3dFJbfl3ce/l75Wi2e4eeek0YOqyPYZOLDeIO429Y/aFOu 3fNBiaU4I9FQi7moOBEAYYNDMnQCAAA= Cc: "mpls@ietf.org" , Gideon Agmon , Shell Nakash Subject: Re: [mpls] PSC: draft-rhd-mpls-tp-psc-sd-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: Mon, 22 Apr 2013 17:57:40 -0000 Dear Sasha, Eric, et al., I too share Sasha's concern in regard to SD in packet transport networks. I= think that before we as WG discuss SD handling by PSC, the SD in Packet Tr= ansport Network must be clearly defined. Otherwise it looks as we've been a= sked to discuss Something Happens and You Must React. Regards, Greg -----Original Message----- From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of Ale= xander Vainshtein Sent: Sunday, April 21, 2013 8:45 AM To: Eric Osborne (eosborne) Cc: mpls@ietf.org; Shell Nakash; Gideon Agmon Subject: Re: [mpls] PSC: draft-rhd-mpls-tp-psc-sd-00 Eric, and all, The issue has been discussed actively in the past. I can only re-state my position during these discussions, namely that there= is no way to define a reasonable analog of Signal Degrade (SD) in MPLS and= , by implication, in the MPLS-TP data plane. By "reasonable" here I mean a = method that does not depend on the actual traffic going thru the LSP. The fact that we could not reach any consensus for such a definition in the= past is not, of course, a mathematical proof of non-existence of SD. But it is a good indication of a fundamental problem IMO. As a consequence, IMHO and FWIW, there is no need in defining SD-related st= ate transitions, behavior etc. My 2c, Sasha > -----Original Message----- > From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf=20 > Of Eric Osborne (eosborne) > Sent: Wednesday, April 17, 2013 3:26 PM > To: mpls@ietf.org > Subject: [mpls] PSC: draft-rhd-mpls-tp-psc-sd-00 >=20 > This thread is for discussing draft-rhd-mpls-tp-psc-sd-00. The draft=20 > provided extensions to the PSC state machine to handle Signal Degrade=20 > (SD). It does not define SD or provide scope around where or how SD=20 > may be used. There are some expired drafts that touch on the definition = and use of SD, including: >=20 > draft-zhl-mpls-tp-sd-03 > draft-rkhd-mpls-tp-sd-03 >=20 > (this is not an exhaustive list. It's the top two google hits.) >=20 >=20 > The questions I think are relevant are: >=20 > - do we need an SD mechanism in MPLS-TP? > - if so, is it reasonable to define state transitions for it before we=20 > have defined SD itself? > - if yes to both of the above, does this draft provide the right=20 > behavior? Are there alternative approaches? >=20 > but of course any and all discussion is welcome. >=20 >=20 >=20 > eric >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls This e-mail message is intended for the recipient only and contains informa= tion which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If = you have received this transmission in error, please inform us by e-mail, p= hone or fax, and then delete the original and all copies thereof. _______________________________________________ mpls mailing list mpls@ietf.org https://www.ietf.org/mailman/listinfo/mpls From liu.guoman@zte.com.cn Mon Apr 22 19:44: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 4730421E80CB for ; Mon, 22 Apr 2013 19:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.663 X-Spam-Level: X-Spam-Status: No, score=-99.663 tagged_above=-999 required=5 tests=[AWL=-1.268, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 Ggx474+aTGGO for ; Mon, 22 Apr 2013 19:44:21 -0700 (PDT) Received: from zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id C8F8321E80B0 for ; Mon, 22 Apr 2013 19:44:20 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.120]) by Websense Email Security Gateway with ESMTP id 1B8421275F69 for ; Tue, 23 Apr 2013 10:43:57 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 545C3CBD68F for ; Tue, 23 Apr 2013 10:43:55 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id r3N2hpZV055915 for ; Tue, 23 Apr 2013 10:43:51 +0800 (GMT-8) (envelope-from liu.guoman@zte.com.cn) To: "mpls@ietf.org" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: liu.guoman@zte.com.cn Date: Tue, 23 Apr 2013 10:43:49 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP1 HF212|May 23, 2012) at 2013-04-23 10:43:49, Serialize complete at 2013-04-23 10:43:49 Content-Type: multipart/alternative; boundary="=_alternative 000F49B648257B56_=" X-MAIL: mse01.zte.com.cn r3N2hpZV055915 Subject: Re: [mpls] New Version Notification for draft-liu-mpls-tp-interconnected-ring-protection-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: Tue, 23 Apr 2013 02:44:22 -0000 This is a multipart message in MIME format. --=_alternative 000F49B648257B56_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 QWxsLGhpDQpJIGhhdmUgdXBsb2FkIGEgbmV3IHZlcnNpb24gMDQgb2YgDQpkcmFmdC1saXUtbXBs cy10cC1pbnRlcmNvbm5lY3RlZC1yaW5nLXByb3RlY3Rpb24uIA0KaW4gdGhpcyB2ZXJzaW9uLCBh ZGRpbmcgY29udGV4dCBvZiByZWNvdmVyeSBtZWNoYW5pc20gZm9yIGludGVyY29ubmVjdGlvbiAN Cm5vZGUgZmFpbHVyZQ0KaW4gdGhlIHNjZW5hcmlvIG9mIGNoYWluZWQgaW50ZXJjb25uZWN0aW9u IGluIHNlY3Rpb24gMy4yIGFuZCBjb3JyZWN0IGEgDQpmZXcgZXJyb3Igd29yZA0KaW4gdGhpcyBk b2N1bWVudC4NCndlbGNvbWUgbW9yZSBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMgZm9yIHRoaXMg ZHJhZnQsIHRoYW5rIHlvdSENCg0KYmVzdCByZWdhcmRzDQpsaXUNCg0KDQoNCmludGVybmV0LWRy YWZ0c0BpZXRmLm9yZyANCjIwMTMtMDQtMjIgMjI6MzcNCg0KytW8/sjLDQpNYXNhaGlybyBEYWlr b2t1IDxtcy1kYWlrb2t1QGtkZGkuY29tPiwgVGFrZXNoaSBNYXJ1eWFtYSANCjx0YS1tYXJ1eWFt YUBrZGRpLmNvbT4sIEd1b21hbiBMaXUgPGZ1LnpoZW50YW9AenRlLmNvbS5jbj4sIEd1b21hbiBM aXUgDQo8bGl1Lmd1b21hbkB6dGUuY29tLmNuPg0Ks63LzQ0KDQrW98ziDQpOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIA0KZHJhZnQtbGl1LW1wbHMtdHAtaW50ZXJjb25uZWN0ZWQtcmluZy1w cm90ZWN0aW9uLTA0LnR4dA0KDQoNCg0KDQoNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgDQpk cmFmdC1saXUtbXBscy10cC1pbnRlcmNvbm5lY3RlZC1yaW5nLXByb3RlY3Rpb24tMDQudHh0DQpo YXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEd1b21hbiBMaXUgYW5kIHBvc3RlZCB0 byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6ICAgICAgICAgICAgICAgICBkcmFm dC1saXUtbXBscy10cC1pbnRlcmNvbm5lY3RlZC1yaW5nLXByb3RlY3Rpb24NClJldmlzaW9uOiAg ICAgICAgICAgICAgICAgMDQNClRpdGxlOiAgICAgICAgICAgICAgICAgICAgICAgICAgICBNUExT LVRQIHByb3RlY3Rpb24gZm9yIGludGVyY29ubmVjdGVkIA0KcmluZ3MNCkNyZWF0aW9uIGRhdGU6 ICAgICAgICAgICAgMjAxMy0wNC0xOQ0KR3JvdXA6ICAgICAgICAgICAgICAgICAgICAgICAgICAg IEluZGl2aWR1YWwgU3VibWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxMg0KVVJMOiAgICAgICAg ICAgICANCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxpdS1tcGxz LXRwLWludGVyY29ubmVjdGVkLXJpbmctcHJvdGVjdGlvbi0wNC50eHQNCg0KU3RhdHVzOiAgICAg ICAgICANCmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGl1LW1wbHMtdHAt aW50ZXJjb25uZWN0ZWQtcmluZy1wcm90ZWN0aW9uDQoNCkh0bWxpemVkOiAgICAgICAgDQpodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1saXUtbXBscy10cC1pbnRlcmNvbm5lY3RlZC1y aW5nLXByb3RlY3Rpb24tMDQNCg0KRGlmZjogICAgICAgICAgICANCmh0dHA6Ly93d3cuaWV0Zi5v cmcvcmZjZGlmZj91cmwyPWRyYWZ0LWxpdS1tcGxzLXRwLWludGVyY29ubmVjdGVkLXJpbmctcHJv dGVjdGlvbi0wNA0KDQoNCkFic3RyYWN0Og0KICAgVGhlIHJlcXVpcmVtZW50cyBmb3IgTVBMUyBU cmFuc3BvcnQgUHJvZmlsZSBpbmNsdWRlIGEgcmVxdWlyZW1lbnQNCiAgIChSOTMpIHRoYXQgcmVx dWlyZXMgTVBMUy1UUCBtdXN0IHN1cHBvcnQgcmVjb3ZlcnkgbWVjaGFuaXNtcyBmb3IgYQ0KICAg bmV0d29yayBjb25zdHJ1Y3RlZCBmcm9tIGludGVyY29ubmVjdGVkIHJpbmdzIHRoYXQgcHJvdGVj dCB1c2VyIGRhdGENCiAgIHRoYXQgdHJhdmVyc2VzIG1vcmUgdGhhbiBvbmUgcmluZy4gIEluIHBh cnRpY3VsYXIsIFRoaXMgaW5jbHVkZXMNCiAgIHByb3RlY3RpbmcgYWdhaW5zdCBjYXNlcyBvZiBm YWlsdXJlIGF0IHRoZSByaW5nLWludGVyY29ubmVjdCBub2Rlcw0KICAgYW5kIGxpbmtzLiAgVGhp cyBkb2N1bWVudCBwcmVzZW50cyBkaWZmZXJlbnQgc2NlbmFyaW8gb2YNCiAgIGludGVyY29ubmVj dGVkIHJpbmdzIGFuZCBzcGVjaWFsIG1lY2hhbmlzbSB0byBhZGRyZXNzIHJlY292ZXJ5IG9mIHRo ZQ0KICAgZmFpbHVyZSBvZiByaW5nLWludGVyY29ubmVjdCBub2RlcyBhbmQgbGlua3MuICAuDQoN CiAgIFRoaXMgZG9jdW1lbnQgaXMgYSBwcm9kdWN0IG9mIGEgam9pbnQgSW50ZXJuZXQgRW5naW5l ZXJpbmcgVGFzaw0KICAgRm9yY2UoSUVURikgLyBJbnRlcm5hdGlvbmFsIFRlbGVjb21tdW5pY2F0 aW9ucyBVbmlvbg0KICAgVGVsZWNvbW11bmljYXRpb25zIFN0YW5kYXJkaXphdGlvbiBTZWN0b3Ig KElUVS1UKSBlZmZvcnQgdG8gaW5jbHVkZQ0KICAgYW4gTVBMUyBUcmFuc3BvcnQgUHJvZmlsZSB3 aXRoaW4gdGhlIElFVEYgTVBMUyBhbmQgUFdFMyBhcmNoaXRlY3R1cmVzDQogICB0byBzdXBwb3J0 IHRoZSBjYXBhYmlsaXRpZXMgYW5kIGZ1bmN0aW9uYWxpdGllcyBvZiBhIHBhY2tldCB0cmFuc3Bv cnQNCiAgIG5ldHdvcmsgYXMgZGVmaW5lZCBieSB0aGUgSVRVLVQuDQoNCiAgDQoNCg0KVGhlIElF VEYgU2VjcmV0YXJpYXQNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0 cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBp cyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElm IHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJv ZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90 aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQg dHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQg aXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJ ZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXBy b2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0 aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5v dGlmeSB1cyBpbW1lZGlhdGVseS4NCg== --=_alternative 000F49B648257B56_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkFsbCxoaTwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSBoYXZlIHVwbG9hZCBhIG5ldyB2ZXJzaW9u IDA0IG9mIGRyYWZ0LWxpdS1tcGxzLXRwLWludGVyY29ubmVjdGVkLXJpbmctcHJvdGVjdGlvbi4N CjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+aW4gdGhpcyB2ZXJz aW9uLCBhZGRpbmcgY29udGV4dCBvZiByZWNvdmVyeQ0KbWVjaGFuaXNtIGZvciBpbnRlcmNvbm5l Y3Rpb24gbm9kZSBmYWlsdXJlPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5pbiB0aGUgc2NlbmFyaW8gb2YgY2hhaW5lZCBpbnRlcmNvbm5lY3Rpb24NCmluIHNlY3Rp b24gMy4yIGFuZCBjb3JyZWN0IGEgZmV3IGVycm9yIHdvcmQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmluIHRoaXMgZG9jdW1lbnQuPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj53ZWxjb21lIG1vcmUgY29tbWVudHMgYW5kIHN1Z2dl c3Rpb25zDQpmb3IgdGhpcyBkcmFmdCwgdGhhbmsgeW91ITwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+YmVzdCByZWdhcmRzPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5saXU8YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8 dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM2JT48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPC9iPg0K PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTMtMDQtMjIgMjI6 Mzc8L2ZvbnQ+DQo8dGQgd2lkdGg9NjMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+TWFzYWhpcm8gRGFpa29rdSAmbHQ7bXMtZGFpa29rdUBrZGRpLmNvbSZndDssDQpUYWtlc2hp IE1hcnV5YW1hICZsdDt0YS1tYXJ1eWFtYUBrZGRpLmNvbSZndDssIEd1b21hbiBMaXUgJmx0O2Z1 LnpoZW50YW9AenRlLmNvbS5jbiZndDssDQpHdW9tYW4gTGl1ICZsdDtsaXUuZ3VvbWFuQHp0ZS5j b20uY24mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0 Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPg0K PHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj5OZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yICZuYnNwOw0KJm5ic3A7ICZu YnNwOyAmbmJzcDtkcmFmdC1saXUtbXBscy10cC1pbnRlcmNvbm5lY3RlZC1yaW5nLXByb3RlY3Rp b24tMDQudHh0PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yPjx0dD48YnI+DQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGl1LW1wbHMtdHAt aW50ZXJjb25uZWN0ZWQtcmluZy1wcm90ZWN0aW9uLTA0LnR4dDxicj4NCmhhcyBiZWVuIHN1Y2Nl c3NmdWxseSBzdWJtaXR0ZWQgYnkgR3VvbWFuIExpdSBhbmQgcG9zdGVkIHRvIHRoZTxicj4NCklF VEYgcmVwb3NpdG9yeS48YnI+DQo8YnI+DQpGaWxlbmFtZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ZHJhZnQtbGl1LW1wbHMt dHAtaW50ZXJjb25uZWN0ZWQtcmluZy1wcm90ZWN0aW9uPGJyPg0KUmV2aXNpb246ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOzA0 PGJyPg0KVGl0bGU6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7DQpNUExTLVRQIHByb3RlY3Rpb24gZm9yIGludGVyY29ubmVjdGVk IHJpbmdzPGJyPg0KQ3JlYXRpb24gZGF0ZTogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7MjAxMy0wNC0xOTxicj4NCkdyb3VwOiAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQom bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOw0KSW5kaXZpZHVhbCBTdWJtaXNzaW9uPGJyPg0KTnVtYmVyIG9mIHBhZ2VzOiAxMjxicj4N ClVSTDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgaHR0cDovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbGl1LW1wbHMtdHAtaW50ZXJjb25uZWN0 ZWQtcmluZy1wcm90ZWN0aW9uLTA0LnR4dDxicj4NClN0YXR1czogJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO2h0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGl1 LW1wbHMtdHAtaW50ZXJjb25uZWN0ZWQtcmluZy1wcm90ZWN0aW9uPGJyPg0KSHRtbGl6ZWQ6ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2h0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LWxpdS1tcGxzLXRwLWludGVyY29ubmVjdGVkLXJpbmctcHJvdGVjdGlvbi0wNDxicj4NCkRpZmY6 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aHR0cDovL3d3dy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbGl1LW1wbHMtdHAtaW50ZXJjb25uZWN0ZWQtcmluZy1w cm90ZWN0aW9uLTA0PGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KICZuYnNwOyBUaGUgcmVxdWly ZW1lbnRzIGZvciBNUExTIFRyYW5zcG9ydCBQcm9maWxlIGluY2x1ZGUgYSByZXF1aXJlbWVudDxi cj4NCiAmbmJzcDsgKFI5MykgdGhhdCByZXF1aXJlcyBNUExTLVRQIG11c3Qgc3VwcG9ydCByZWNv dmVyeSBtZWNoYW5pc21zIGZvcg0KYTxicj4NCiAmbmJzcDsgbmV0d29yayBjb25zdHJ1Y3RlZCBm cm9tIGludGVyY29ubmVjdGVkIHJpbmdzIHRoYXQgcHJvdGVjdCB1c2VyDQpkYXRhPGJyPg0KICZu YnNwOyB0aGF0IHRyYXZlcnNlcyBtb3JlIHRoYW4gb25lIHJpbmcuICZuYnNwO0luIHBhcnRpY3Vs YXIsIFRoaXMgaW5jbHVkZXM8YnI+DQogJm5ic3A7IHByb3RlY3RpbmcgYWdhaW5zdCBjYXNlcyBv ZiBmYWlsdXJlIGF0IHRoZSByaW5nLWludGVyY29ubmVjdCBub2Rlczxicj4NCiAmbmJzcDsgYW5k IGxpbmtzLiAmbmJzcDtUaGlzIGRvY3VtZW50IHByZXNlbnRzIGRpZmZlcmVudCBzY2VuYXJpbyBv Zjxicj4NCiAmbmJzcDsgaW50ZXJjb25uZWN0ZWQgcmluZ3MgYW5kIHNwZWNpYWwgbWVjaGFuaXNt IHRvIGFkZHJlc3MgcmVjb3ZlcnkNCm9mIHRoZTxicj4NCiAmbmJzcDsgZmFpbHVyZSBvZiByaW5n LWludGVyY29ubmVjdCBub2RlcyBhbmQgbGlua3MuICZuYnNwOy48YnI+DQo8YnI+DQogJm5ic3A7 IFRoaXMgZG9jdW1lbnQgaXMgYSBwcm9kdWN0IG9mIGEgam9pbnQgSW50ZXJuZXQgRW5naW5lZXJp bmcgVGFzazxicj4NCiAmbmJzcDsgRm9yY2UoSUVURikgLyBJbnRlcm5hdGlvbmFsIFRlbGVjb21t dW5pY2F0aW9ucyBVbmlvbjxicj4NCiAmbmJzcDsgVGVsZWNvbW11bmljYXRpb25zIFN0YW5kYXJk aXphdGlvbiBTZWN0b3IgKElUVS1UKSBlZmZvcnQgdG8gaW5jbHVkZTxicj4NCiAmbmJzcDsgYW4g TVBMUyBUcmFuc3BvcnQgUHJvZmlsZSB3aXRoaW4gdGhlIElFVEYgTVBMUyBhbmQgUFdFMyBhcmNo aXRlY3R1cmVzPGJyPg0KICZuYnNwOyB0byBzdXBwb3J0IHRoZSBjYXBhYmlsaXRpZXMgYW5kIGZ1 bmN0aW9uYWxpdGllcyBvZiBhIHBhY2tldCB0cmFuc3BvcnQ8YnI+DQogJm5ic3A7IG5ldHdvcmsg YXMgZGVmaW5lZCBieSB0aGUgSVRVLVQuPGJyPg0KPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YnI+DQo8YnI+DQo8YnI+ DQpUaGUgSUVURiBTZWNyZXRhcmlhdDxicj4NCjxicj4NCjwvdHQ+PC9mb250Pg0KDQo8YnI+PHBy ZT48Zm9udCBjb2xvcj0iYmx1ZSI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTog VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVu dCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFu ZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4g IElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJl cHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9m IHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQg bm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KDQo8L2ZvbnQ+PC9wcmU+PGJyPg0KDQo8YnI+PHByZT48 Zm9udCBjb2xvcj0iYmx1ZSI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0 cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBp cyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElm IHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJv ZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90 aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KDQo8L2ZvbnQ+PC9wcmU+PGJyPg0K --=_alternative 000F49B648257B56_=-- From curtis@ipv6.occnc.com Tue Apr 23 10:00: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 0C2A221F9661 for ; Tue, 23 Apr 2013 10:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.005 X-Spam-Level: ** X-Spam-Status: No, score=2.005 tagged_above=-999 required=5 tests=[AWL=-2.500, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_SUMOF=5, HELO_MISMATCH_COM=0.553, 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 MxBVZBty9i1S for ; Tue, 23 Apr 2013 10:00:06 -0700 (PDT) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 07BD221F9298 for ; Tue, 23 Apr 2013 10:00:02 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r3NGwjGK063708; Tue, 23 Apr 2013 12:58:46 -0400 (EDT) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201304231658.r3NGwjGK063708@gateway1.orleans.occnc.com> To: MPLS WG Mailing List , draft-atlas-mpls-te-express-path authors , The Great and Mighty MPLS Co-Chairs From: Curtis Villamizar Date: Tue, 23 Apr 2013 12:58:45 -0400 Subject: [mpls] draft-atlas-mpls-te-express-path-02 (was MPLS-RT review of ...) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 17:00:08 -0000 Loa, authors, et al, So far I have seen two of the four MPLS-RT reviews (maybe I missed the others). I've commented before on the mailing list about this draft but at this point I would like to provide a detailed review. I think there are very major issues with this document as it now stands. IMO these issues should be addressed before the draft is even accepted as a WG document. You can choose to consider this during MPLS-RT review or after. Curtis Major issues: Jitter and loss are very close to meaningless if queueing delays and loss are not considered. Links that are losing packets at the link layer are generally taken down. Oscillations can occur if queueing delay and loss is considered, such as measurements at a low priority and therefore possible to congest or measurements which are otherwise affected by traffic load. Unless there is adequate discussion of stability and mechanisms to insure stability, then jitter and loss should be removed. General: It needs to be much more clearly stated that the NPO (s/SLA/NPO/g, see nits below) is specific to a link, and not an NPO per LSP. A "non-conformance to NPO" flag in the IGP link advertisement is intractable if there are multiple NPO being applied to the link. The use of a "non-conformance to NPO" flag as the only means to alert the set of LSP ingress of a significant change is also at best a poor solution. For example, a change from 2 msec to 15 msec may be a problem for some LSP. That same change may not be a problem for others, such as LSPs where only this one hop is needed. So advertising out of NPO in the IGP doesn't help the second case. LSP ingress must evaluate the path delay constraint, each time a change in IGP link advertised delay is received. The use of a "non-conformance to NPO" flag solely as a constraint makes sense, where some LSP are configured to exclude links with this flag set. For path delay computation it would also be useful if the NPO threshhold were advertised. In some cases, it may make sense to minimize or place bounds on the sum of NPO delays. Specific: Abstract: Remove mention of jitter and loss. 1. Introduction: This sentence is awkward but I think I know what you are trying to say. The method suggested is not optimal for both minimizing path cost and additional constraints, such as latency; optimal solutions are computationally complex. Please consider this replacement. Methods of optimizing path selection for multiple parameters are generally computationally complex. The method proposed here are to make use of either a single metric in path selection, such as minimal path delay, or to make use of another single metric, such as the existing TE metric with additional constraints, such as target link delay bounds and target path delay bounds. Please note: The path selection mechanisms described in this document apply to paths that are fully computed by the head-end of the LSP and then signaled in an ERO where every sub-object is strict. This allows the head-end to consider IGP-distributed performance data without requiring the ability to signal the performance constraints in an object of the RSVP Path message. There is work in MPLS or CCAMP by George Swallow and others on cummulative metrics in RSVP-TE with delay as a major motivation. Perhaps that work should be considered. This paragraph could use rewording: When considering performance-based data, it is obvious that there are additional contributors beyond just the links. Clearly end-to-end latency is a combination of router latency, queuing latency, physical link latency and other factors. However, if application traffic requires paths to be selected based upon latency constraints, the same traffic might be in an Expedited Forwarding Per-Hop- Behavior[RFC3246] with minimal queuing delay or another PHB with known maximal per-hop queuing delay. While traversing a router can cause delay, that can be included in the advertised link delay. What you are getting at is that where traffic levels can't possibly have a significant impact the measurements, such as low levels of EF traffic in a WAN with high geographic delays, and delay meansured with EF priority, stability is not impacted if delay measurements are considered. In this case, loss MUST be zero or the EF service is broken (replace routers and try again). OTOH jitter will increase as traffic levels increase, even in such a case where the traffic is only a few percent, potentially causing oscillations and impacting stability. For this reason, jitter and loss should not be considered. I will leave the rewording up to you. I suggest that you create a subsection of "Introduction" which discusses potential oscillations and stability in greater detail. If you like, I will provide some text. 1.1. Basic Requirements: Drop "packet loss, jitter" from the first numeric item. Otherwise OK except use of the word SLA. See nits below. After the list please state that "For existing MPLS constraints, corresponding RSVP-TE signaling allows midpoint LSR to use Path Tear and/or notification and would use this mechanism to accomplish items 3-6. In the absense of RSVP-TE signaling corresponding to these new constraints, new mechanisms at the LSP ingress are needed." Alternately, consider citing the work by George Swallow et al and explain how that solves it in the same way that a change in admin attr of a link would (or should, poor implementations not withstanding). 2.1. End-to-End Constraints: Note: I've requested that jitter and loss be dropped from draft-ietf-ospf-te-metric-extensions and draft-previdi-isis-te-metric-extensions for the same potential oscillations and stability reasons cited above. s/While it has been possible to compute a CSPF/It is possible to compute a CSPF/ s/Instead of this approach to minimize path latency, an/An alternative to this approach to minimize path latency is an approach to place a upper bound on path latency. An/ Note: both approaches are valid. Delete next paragraph starting with "This is illustrated as follows." This seems to be taken from email and is good email discussion but not needed in the draft. Delete next paragraph starting with "An end-to-end bound on delay variation". Lets get rid of jitter altogether. (Let the old SNA networks be damned. :) Delete next paragraph starting with "For link loss". Get rid of link loss altogether. 2.2. Link Constraints: Drop delay variation and link loss. If we are dealing with EF traffic then using Unidirectional Available Bandwidth and Residual Bandwidth makes no sense. If we are dealing with low priority traffic and we are using Unidirectional Available Bandwidth and Residual Bandwidth in path selection will be prone to oscillations and network instability. Therefore delete the entire second paragraph (the one starting with "When doing path selection for TE tunnels,". Also delete the entire third paragraph (starting with "Similarly, only links whose loss is"). As stated earlier, use of loss is either a NOOP (low volume of EF traffic) or can lead to oscillations. Get rid of loss entirely. 2.3. Links out of SLA: s/SLA/NPO/g (see nits below). General: A better mechanism than an "Anomalous State" flag is needed to provide notifications of change. One mechanism would be to put the commulative constraint and the cummulative total in the ERO and RRO. A link adding delay can then notify the ingress of any LSP for which the commulative constraint is violated. See work by Swallow et al and perhaps align with that work. The "Anomalous State" flag is helpful for c in the list, but not for b. The case where a link is out of NPO by 1 msec then changes to out of NPO by 10s of msec is an example. The flag is already set and therefore the trigger is unavailable. 2.3.1. Use of Anomalous Links for New Paths Delete second paragraph regarding jitter and loss. 2.3.2. Links entering the Anomalous State This section ignores two cases in which the Anomalous State does not change but a change makes the path violate a delay constraint. The first is where all of the links are within NPO but a change to a link has make the path delay sum exceed the path delay constraint. The second is where a link which is already in the Anomalous State by a small margin but the path delay is still within the constraint. A large change in delay at that point will not affect the Anomalous State since it is already set. A better means of handling case (b) in "2.3. Links out of SLA" is needed. 2.3.3. Links leaving the Anomalous State Same issue as in "2.3.2. Links entering the Anomalous State". A better means of handling case (b) in "2.3. Links out of SLA" is needed. XML version nits: CV: you really should remove the template comments. You should also enable strict mode. For example, you have one author too many and strict would catch that. Other nits: The "A" in SLA is "Agreement" as in contract. The acronym NPO for network performance objective seems to be in vogue for that reason. IETF since diffserv has wanted to steer clear of making recommendations regarding provider contracts (agreements) with customers, peer, or anyone else. I agree with Sri on the suggestions to change the title, short name and document filename but I'm not fond of his suggested new names. Authors please suggest new title, short name, and filename. ------- Forwarded Message On 4/5/13 9:50 PM, "Loa Andersson" wrote: > >Xiaohu, Sri, Rajiv and Pranjal, > >You have been selected as an MPLS Review team reviewers for >draft-atlas-mpls-te-express-path-02. > >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 April 20, 2013? > >Thanks, Loa >(as MPLS WG chair) > >/Loa >-- > > >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 ------- End of Forwarded Message From curtis@ipv6.occnc.com Tue Apr 23 11:24: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 A2BD421F94DF for ; Tue, 23 Apr 2013 11:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.152 X-Spam-Level: ** X-Spam-Status: No, score=2.152 tagged_above=-999 required=5 tests=[AWL=-2.353, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_SUMOF=5, HELO_MISMATCH_COM=0.553, 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 8hRwvHpGTEfT for ; Tue, 23 Apr 2013 11:24:51 -0700 (PDT) Received: from gateway1.orleans.occnc.com (unknown [173.9.106.132]) by ietfa.amsl.com (Postfix) with ESMTP id 797EB21F964D for ; Tue, 23 Apr 2013 11:24:50 -0700 (PDT) Received: from harbor1.ipv6.occnc.com (harbor1.ipv6.occnc.com [IPv6:2001:470:1f07:1545::2:819]) (authenticated bits=0) by gateway1.orleans.occnc.com (8.14.5/8.14.5) with ESMTP id r3NINRGf064678; Tue, 23 Apr 2013 14:23:27 -0400 (EDT) (envelope-from curtis@ipv6.occnc.com) Message-Id: <201304231823.r3NINRGf064678@gateway1.orleans.occnc.com> To: curtis@ipv6.occnc.com From: Curtis Villamizar In-reply-to: Your message of "Tue, 23 Apr 2013 12:58:45 EDT." <201304231658.r3NGwjGK063708@gateway1.orleans.occnc.com> Date: Tue, 23 Apr 2013 14:23:27 -0400 Cc: MPLS WG Mailing List , The Great and Mighty MPLS Co-Chairs , draft-atlas-mpls-te-express-path authors Subject: Re: [mpls] draft-atlas-mpls-te-express-path-02 (was MPLS-RT review of ...) X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: curtis@ipv6.occnc.com List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 18:24:52 -0000 BTW- I think the draft mentioned below by Swallow et al is: Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) extension for recording TE Metric of a Label Switched Path draft-ietf-ccamp-te-metric-recording-01.txt I think there is other related work. George - help. Please. Curtis In message <201304231658.r3NGwjGK063708@gateway1.orleans.occnc.com> Curtis Villamizar writes: Loa, authors, et al, So far I have seen two of the four MPLS-RT reviews (maybe I missed the others). I've commented before on the mailing list about this draft but at this point I would like to provide a detailed review. I think there are very major issues with this document as it now stands. IMO these issues should be addressed before the draft is even accepted as a WG document. You can choose to consider this during MPLS-RT review or after. Curtis Major issues: Jitter and loss are very close to meaningless if queueing delays and loss are not considered. Links that are losing packets at the link layer are generally taken down. Oscillations can occur if queueing delay and loss is considered, such as measurements at a low priority and therefore possible to congest or measurements which are otherwise affected by traffic load. Unless there is adequate discussion of stability and mechanisms to insure stability, then jitter and loss should be removed. General: It needs to be much more clearly stated that the NPO (s/SLA/NPO/g, see nits below) is specific to a link, and not an NPO per LSP. A "non-conformance to NPO" flag in the IGP link advertisement is intractable if there are multiple NPO being applied to the link. The use of a "non-conformance to NPO" flag as the only means to alert the set of LSP ingress of a significant change is also at best a poor solution. For example, a change from 2 msec to 15 msec may be a problem for some LSP. That same change may not be a problem for others, such as LSPs where only this one hop is needed. So advertising out of NPO in the IGP doesn't help the second case. LSP ingress must evaluate the path delay constraint, each time a change in IGP link advertised delay is received. The use of a "non-conformance to NPO" flag solely as a constraint makes sense, where some LSP are configured to exclude links with this flag set. For path delay computation it would also be useful if the NPO threshhold were advertised. In some cases, it may make sense to minimize or place bounds on the sum of NPO delays. Specific: Abstract: Remove mention of jitter and loss. 1. Introduction: This sentence is awkward but I think I know what you are trying to say. The method suggested is not optimal for both minimizing path cost and additional constraints, such as latency; optimal solutions are computationally complex. Please consider this replacement. Methods of optimizing path selection for multiple parameters are generally computationally complex. The method proposed here are to make use of either a single metric in path selection, such as minimal path delay, or to make use of another single metric, such as the existing TE metric with additional constraints, such as target link delay bounds and target path delay bounds. Please note: The path selection mechanisms described in this document apply to paths that are fully computed by the head-end of the LSP and then signaled in an ERO where every sub-object is strict. This allows the head-end to consider IGP-distributed performance data without requiring the ability to signal the performance constraints in an object of the RSVP Path message. There is work in MPLS or CCAMP by George Swallow and others on cummulative metrics in RSVP-TE with delay as a major motivation. Perhaps that work should be considered. This paragraph could use rewording: When considering performance-based data, it is obvious that there are additional contributors beyond just the links. Clearly end-to-end latency is a combination of router latency, queuing latency, physical link latency and other factors. However, if application traffic requires paths to be selected based upon latency constraints, the same traffic might be in an Expedited Forwarding Per-Hop- Behavior[RFC3246] with minimal queuing delay or another PHB with known maximal per-hop queuing delay. While traversing a router can cause delay, that can be included in the advertised link delay. What you are getting at is that where traffic levels can't possibly have a significant impact the measurements, such as low levels of EF traffic in a WAN with high geographic delays, and delay meansured with EF priority, stability is not impacted if delay measurements are considered. In this case, loss MUST be zero or the EF service is broken (replace routers and try again). OTOH jitter will increase as traffic levels increase, even in such a case where the traffic is only a few percent, potentially causing oscillations and impacting stability. For this reason, jitter and loss should not be considered. I will leave the rewording up to you. I suggest that you create a subsection of "Introduction" which discusses potential oscillations and stability in greater detail. If you like, I will provide some text. 1.1. Basic Requirements: Drop "packet loss, jitter" from the first numeric item. Otherwise OK except use of the word SLA. See nits below. After the list please state that "For existing MPLS constraints, corresponding RSVP-TE signaling allows midpoint LSR to use Path Tear and/or notification and would use this mechanism to accomplish items 3-6. In the absense of RSVP-TE signaling corresponding to these new constraints, new mechanisms at the LSP ingress are needed." Alternately, consider citing the work by George Swallow et al and explain how that solves it in the same way that a change in admin attr of a link would (or should, poor implementations not withstanding). 2.1. End-to-End Constraints: Note: I've requested that jitter and loss be dropped from draft-ietf-ospf-te-metric-extensions and draft-previdi-isis-te-metric-extensions for the same potential oscillations and stability reasons cited above. s/While it has been possible to compute a CSPF/It is possible to compute a CSPF/ s/Instead of this approach to minimize path latency, an/An alternative to this approach to minimize path latency is an approach to place a upper bound on path latency. An/ Note: both approaches are valid. Delete next paragraph starting with "This is illustrated as follows." This seems to be taken from email and is good email discussion but not needed in the draft. Delete next paragraph starting with "An end-to-end bound on delay variation". Lets get rid of jitter altogether. (Let the old SNA networks be damned. :) Delete next paragraph starting with "For link loss". Get rid of link loss altogether. 2.2. Link Constraints: Drop delay variation and link loss. If we are dealing with EF traffic then using Unidirectional Available Bandwidth and Residual Bandwidth makes no sense. If we are dealing with low priority traffic and we are using Unidirectional Available Bandwidth and Residual Bandwidth in path selection will be prone to oscillations and network instability. Therefore delete the entire second paragraph (the one starting with "When doing path selection for TE tunnels,". Also delete the entire third paragraph (starting with "Similarly, only links whose loss is"). As stated earlier, use of loss is either a NOOP (low volume of EF traffic) or can lead to oscillations. Get rid of loss entirely. 2.3. Links out of SLA: s/SLA/NPO/g (see nits below). General: A better mechanism than an "Anomalous State" flag is needed to provide notifications of change. One mechanism would be to put the commulative constraint and the cummulative total in the ERO and RRO. A link adding delay can then notify the ingress of any LSP for which the commulative constraint is violated. See work by Swallow et al and perhaps align with that work. The "Anomalous State" flag is helpful for c in the list, but not for b. The case where a link is out of NPO by 1 msec then changes to out of NPO by 10s of msec is an example. The flag is already set and therefore the trigger is unavailable. 2.3.1. Use of Anomalous Links for New Paths Delete second paragraph regarding jitter and loss. 2.3.2. Links entering the Anomalous State This section ignores two cases in which the Anomalous State does not change but a change makes the path violate a delay constraint. The first is where all of the links are within NPO but a change to a link has make the path delay sum exceed the path delay constraint. The second is where a link which is already in the Anomalous State by a small margin but the path delay is still within the constraint. A large change in delay at that point will not affect the Anomalous State since it is already set. A better means of handling case (b) in "2.3. Links out of SLA" is needed. 2.3.3. Links leaving the Anomalous State Same issue as in "2.3.2. Links entering the Anomalous State". A better means of handling case (b) in "2.3. Links out of SLA" is needed. XML version nits: CV: you really should remove the template comments. You should also enable strict mode. For example, you have one author too many and strict would catch that. Other nits: The "A" in SLA is "Agreement" as in contract. The acronym NPO for network performance objective seems to be in vogue for that reason. IETF since diffserv has wanted to steer clear of making recommendations regarding provider contracts (agreements) with customers, peer, or anyone else. I agree with Sri on the suggestions to change the title, short name and document filename but I'm not fond of his suggested new names. Authors please suggest new title, short name, and filename. ------- Forwarded Message On 4/5/13 9:50 PM, "Loa Andersson" wrote: > >Xiaohu, Sri, Rajiv and Pranjal, > >You have been selected as an MPLS Review team reviewers for >draft-atlas-mpls-te-express-path-02. > >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 April 20, 2013? > >Thanks, Loa >(as MPLS WG chair) > >/Loa >-- > > >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 ------- End of Forwarded Message From xuxiaohu@huawei.com Tue Apr 23 18:44: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 6C7AC21F9120 for ; Tue, 23 Apr 2013 18:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.489 X-Spam-Level: X-Spam-Status: No, score=-5.489 tagged_above=-999 required=5 tests=[AWL=1.110, 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 bbmgKgt9bUrV for ; Tue, 23 Apr 2013 18:44:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CED4421F90F1 for ; Tue, 23 Apr 2013 18:44:14 -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 AQS97933; Wed, 24 Apr 2013 01:44:13 +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, 24 Apr 2013 02:43:44 +0100 Received: from NKGEML408-HUB.china.huawei.com (10.98.56.39) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 24 Apr 2013 02:44:12 +0100 Received: from NKGEML512-MBS.china.huawei.com ([169.254.8.243]) by nkgeml408-hub.china.huawei.com ([10.98.56.39]) with mapi id 14.01.0323.007; Wed, 24 Apr 2013 09:44:07 +0800 From: Xuxiaohu To: "curtis@ipv6.occnc.com" , MPLS WG Mailing List , draft-atlas-mpls-te-express-path authors , The Great and Mighty MPLS Co-Chairs Thread-Topic: [mpls] draft-atlas-mpls-te-express-path-02 (was MPLS-RT review of ...) Thread-Index: AQHOQEQNQ9iL0cl/nUiQqrZZEVUQipjklSUQ Date: Wed, 24 Apr 2013 01:44:05 +0000 Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE07F6409D@NKGEML512-MBS.china.huawei.com> References: <201304231658.r3NGwjGK063708@gateway1.orleans.occnc.com> In-Reply-To: <201304231658.r3NGwjGK063708@gateway1.orleans.occnc.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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [mpls] draft-atlas-mpls-te-express-path-02 (was MPLS-RT review of ...) 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, 24 Apr 2013 01:44:16 -0000 > s/While it has been possible to compute a CSPF/It is possible to > compute a CSPF/ > s/Instead of this approach to minimize path latency, an/An > alternative to this approach to minimize path latency is an > approach to place a upper bound on path latency. An/ > Note: both approaches are valid. I think the alternative approach (i.e., to compute a CSPF path based on the= TE metric while placing a upper bound on the path latency) is not a practi= cal approach due to computationally complexity. Best regards, Xiaohu From loa@pi.nu Wed Apr 24 00:26: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 B231C21F8BD4 for ; Wed, 24 Apr 2013 00:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.048 X-Spam-Level: X-Spam-Status: No, score=-96.048 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_SUMOF=5, 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 aEF5zZa0PX97 for ; Wed, 24 Apr 2013 00:26:50 -0700 (PDT) Received: from mail.pi.nu (unknown [195.206.248.139]) by ietfa.amsl.com (Postfix) with ESMTP id DA15221F8A08 for ; Wed, 24 Apr 2013 00:26:49 -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) by mail.pi.nu (Postfix) with ESMTPSA id E50EB823B5; Wed, 24 Apr 2013 09:26:47 +0200 (CEST) Message-ID: <5177893F.6030606@pi.nu> Date: Wed, 24 Apr 2013 09:26: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-atlas-mpls-te-express-path authors References: <201304231658.r3NGwjGK063708@gateway1.orleans.occnc.com> In-Reply-To: <201304231658.r3NGwjGK063708@gateway1.orleans.occnc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: MPLS WG Mailing List , The Great and Mighty MPLS Co-Chairs Subject: Re: [mpls] draft-atlas-mpls-te-express-path-02 (was MPLS-RT review of ...) 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, 24 Apr 2013 07:26:54 -0000 Authors, Please consider and address Curtis' comments as if they were part of the MPLS-RT review. We will have the third MPLS-RT review later today, and hope to have the last showing soon. Please wait to re-spin the draft until we tell you to do so, discussing and resolving comments on the wg mailing list is OK. /Loa for the The Great and Mighty MPLS Co-Chairs ;) On 2013-04-23 18:58, Curtis Villamizar wrote: > Loa, authors, et al, > > So far I have seen two of the four MPLS-RT reviews (maybe I missed the > others). I've commented before on the mailing list about this draft > but at this point I would like to provide a detailed review. > > I think there are very major issues with this document as it now > stands. IMO these issues should be addressed before the draft is even > accepted as a WG document. > > You can choose to consider this during MPLS-RT review or after. > > Curtis > > > > > Major issues: > > Jitter and loss are very close to meaningless if queueing delays and > loss are not considered. Links that are losing packets at the link > layer are generally taken down. Oscillations can occur if queueing > delay and loss is considered, such as measurements at a low priority > and therefore possible to congest or measurements which are > otherwise affected by traffic load. Unless there is adequate > discussion of stability and mechanisms to insure stability, then > jitter and loss should be removed. > > General: > > It needs to be much more clearly stated that the NPO (s/SLA/NPO/g, > see nits below) is specific to a link, and not an NPO per LSP. A > "non-conformance to NPO" flag in the IGP link advertisement is > intractable if there are multiple NPO being applied to the link. > > The use of a "non-conformance to NPO" flag as the only means to > alert the set of LSP ingress of a significant change is also at best > a poor solution. For example, a change from 2 msec to 15 msec may > be a problem for some LSP. That same change may not be a problem > for others, such as LSPs where only this one hop is needed. So > advertising out of NPO in the IGP doesn't help the second case. LSP > ingress must evaluate the path delay constraint, each time a change > in IGP link advertised delay is received. > > The use of a "non-conformance to NPO" flag solely as a constraint > makes sense, where some LSP are configured to exclude links with > this flag set. > > For path delay computation it would also be useful if the NPO > threshhold were advertised. In some cases, it may make sense to > minimize or place bounds on the sum of NPO delays. > > Specific: > > Abstract: > > Remove mention of jitter and loss. > > 1. Introduction: > > This sentence is awkward but I think I know what you are trying to > say. > > The method suggested is not optimal for both minimizing path > cost and additional constraints, such as latency; optimal > solutions are computationally complex. > > Please consider this replacement. > > Methods of optimizing path selection for multiple parameters are > generally computationally complex. The method proposed here are > to make use of either a single metric in path selection, such as > minimal path delay, or to make use of another single metric, > such as the existing TE metric with additional constraints, such > as target link delay bounds and target path delay bounds. > > Please note: > > The path selection mechanisms described in this document apply > to paths that are fully computed by the head-end of the LSP and > then signaled in an ERO where every sub-object is strict. This > allows the head-end to consider IGP-distributed performance data > without requiring the ability to signal the performance > constraints in an object of the RSVP Path message. > > There is work in MPLS or CCAMP by George Swallow and others on > cummulative metrics in RSVP-TE with delay as a major motivation. > Perhaps that work should be considered. > > This paragraph could use rewording: > > When considering performance-based data, it is obvious that > there are additional contributors beyond just the links. > Clearly end-to-end latency is a combination of router latency, > queuing latency, physical link latency and other factors. > However, if application traffic requires paths to be selected > based upon latency constraints, the same traffic might be in an > Expedited Forwarding Per-Hop- Behavior[RFC3246] with minimal > queuing delay or another PHB with known maximal per-hop queuing > delay. While traversing a router can cause delay, that can be > included in the advertised link delay. > > What you are getting at is that where traffic levels can't > possibly have a significant impact the measurements, such as low > levels of EF traffic in a WAN with high geographic delays, and > delay meansured with EF priority, stability is not impacted if > delay measurements are considered. In this case, loss MUST be > zero or the EF service is broken (replace routers and try again). > OTOH jitter will increase as traffic levels increase, even in such > a case where the traffic is only a few percent, potentially > causing oscillations and impacting stability. For this reason, > jitter and loss should not be considered. > > I will leave the rewording up to you. I suggest that you create a > subsection of "Introduction" which discusses potential > oscillations and stability in greater detail. If you like, I will > provide some text. > > 1.1. Basic Requirements: > > Drop "packet loss, jitter" from the first numeric item. Otherwise > OK except use of the word SLA. See nits below. > > After the list please state that "For existing MPLS constraints, > corresponding RSVP-TE signaling allows midpoint LSR to use Path > Tear and/or notification and would use this mechanism to > accomplish items 3-6. In the absense of RSVP-TE signaling > corresponding to these new constraints, new mechanisms at the LSP > ingress are needed." Alternately, consider citing the work by > George Swallow et al and explain how that solves it in the same > way that a change in admin attr of a link would (or should, poor > implementations not withstanding). > > 2.1. End-to-End Constraints: > > Note: I've requested that jitter and loss be dropped from > draft-ietf-ospf-te-metric-extensions and > draft-previdi-isis-te-metric-extensions for the same potential > oscillations and stability reasons cited above. > > s/While it has been possible to compute a CSPF/It is possible to > compute a CSPF/ > s/Instead of this approach to minimize path latency, an/An > alternative to this approach to minimize path latency is an > approach to place a upper bound on path latency. An/ > Note: both approaches are valid. > > Delete next paragraph starting with "This is illustrated as > follows." This seems to be taken from email and is good email > discussion but not needed in the draft. > > Delete next paragraph starting with "An end-to-end bound on delay > variation". Lets get rid of jitter altogether. (Let the old SNA > networks be damned. :) > > Delete next paragraph starting with "For link loss". Get rid of > link loss altogether. > > 2.2. Link Constraints: > > Drop delay variation and link loss. > > If we are dealing with EF traffic then using Unidirectional > Available Bandwidth and Residual Bandwidth makes no sense. If we > are dealing with low priority traffic and we are using > Unidirectional Available Bandwidth and Residual Bandwidth in path > selection will be prone to oscillations and network instability. > Therefore delete the entire second paragraph (the one starting > with "When doing path selection for TE tunnels,". > > Also delete the entire third paragraph (starting with "Similarly, > only links whose loss is"). As stated earlier, use of loss is > either a NOOP (low volume of EF traffic) or can lead to > oscillations. Get rid of loss entirely. > > 2.3. Links out of SLA: > > s/SLA/NPO/g (see nits below). > > General: A better mechanism than an "Anomalous State" flag is > needed to provide notifications of change. One mechanism would be > to put the commulative constraint and the cummulative total in the > ERO and RRO. A link adding delay can then notify the ingress of > any LSP for which the commulative constraint is violated. See > work by Swallow et al and perhaps align with that work. > > The "Anomalous State" flag is helpful for c in the list, but not > for b. The case where a link is out of NPO by 1 msec then changes > to out of NPO by 10s of msec is an example. The flag is already > set and therefore the trigger is unavailable. > > 2.3.1. Use of Anomalous Links for New Paths > > Delete second paragraph regarding jitter and loss. > > 2.3.2. Links entering the Anomalous State > > This section ignores two cases in which the Anomalous State does > not change but a change makes the path violate a delay > constraint. The first is where all of the links are within NPO > but a change to a link has make the path delay sum exceed the path > delay constraint. The second is where a link which is already in > the Anomalous State by a small margin but the path delay is still > within the constraint. A large change in delay at that point will > not affect the Anomalous State since it is already set. > > A better means of handling case (b) in "2.3. Links out of SLA" is > needed. > > 2.3.3. Links leaving the Anomalous State > > Same issue as in "2.3.2. Links entering the Anomalous State". A > better means of handling case (b) in "2.3. Links out of SLA" is > needed. > > XML version nits: > > CV: you really should remove the template comments. > > You should also enable strict mode. For example, you have one > author too many and strict would catch that. > > Other nits: > > The "A" in SLA is "Agreement" as in contract. The acronym NPO for > network performance objective seems to be in vogue for that reason. > IETF since diffserv has wanted to steer clear of making > recommendations regarding provider contracts (agreements) with > customers, peer, or anyone else. > > I agree with Sri on the suggestions to change the title, short name > and document filename but I'm not fond of his suggested new names. > Authors please suggest new title, short name, and filename. > > > ------- Forwarded Message > > On 4/5/13 9:50 PM, "Loa Andersson" wrote: >> >> Xiaohu, Sri, Rajiv and Pranjal, >> >> You have been selected as an MPLS Review team reviewers for >> draft-atlas-mpls-te-express-path-02. >> >> 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 April 20, 2013? >> >> Thanks, Loa >> (as MPLS WG chair) >> >> /Loa >> -- >> >> >> 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 > > ------- End of Forwarded Message > -- Loa Andersson email: loa@mail01.huawei.com Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 From internet-drafts@ietf.org Fri Apr 26 16:07: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 6921A21F9D05; Fri, 26 Apr 2013 16:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.084, 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 PwKOwslG0Snw; Fri, 26 Apr 2013 16:07:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B3FD721F9909; Fri, 26 Apr 2013 16:07:52 -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: <20130426230752.2807.23315.idtracker@ietfa.amsl.com> Date: Fri, 26 Apr 2013 16:07:52 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: draft-ietf-mpls-gach-adv-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: Fri, 26 Apr 2013 23:07:53 -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 Generic Associated Channel (G-ACh) Advertisement Pr= otocol Author(s) : Dan Frost Stewart Bryant Matthew Bocci Filename : draft-ietf-mpls-gach-adv-07.txt Pages : 21 Date : 2013-04-26 Abstract: The MPLS Generic Associated Channel (G-ACh) provides an auxiliary logical data channel associated with a Label Switched Path (LSP), a pseudowire, or a section (link) over which a variety of protocols may flow. These protocols are commonly used to provide Operations, Administration, and Maintenance (OAM) mechanisms associated with the primary data channel. This document specifies simple procedures by which an endpoint of an LSP, pseudowire, or section may inform the other endpoints of its capabilities and configuration parameters, or other application-specific information. This information may then be used by the receiver to validate or adjust its local configuration, and by the network operator for diagnostic purposes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-gach-adv There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-gach-adv-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-gach-adv-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From lizho.jin@gmail.com Sat Apr 27 01:27: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 D937B21F9894 for ; Sat, 27 Apr 2013 01:27:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.299 X-Spam-Level: X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_TOOL=2.3, 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 5At-215RUa7e for ; Sat, 27 Apr 2013 01:27:11 -0700 (PDT) Received: from mail-qa0-x234.google.com (mail-qa0-x234.google.com [IPv6:2607:f8b0:400d:c00::234]) by ietfa.amsl.com (Postfix) with ESMTP id 0090921F988A for ; Sat, 27 Apr 2013 01:27:10 -0700 (PDT) Received: by mail-qa0-f52.google.com with SMTP id hg5so465286qab.18 for ; Sat, 27 Apr 2013 01:27:10 -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=ftJKYWphVsT91MYG02lQmYQWm6DsthyOpOBjYaf9kXM=; b=T8DqVxlXzEPGj/Abz8zr6V8PGxS0RLjuZcIs94cPFKiEtUtmKXxaS7gVm3ASelCwoP UkTtBTuexDDZVi+f3Mvbvu7o+w8z2NogRx3aVtCpbuEdgxgfd/0D8cxXwGfXGQK5GYwP TJI20XnAEJ7WTabnlOKOz/3MEAtepaFAbOJDnQ7Sqiyf7RLjdasLav+JVazEEzPOClb/ rFOZf/3ogmxnb8ymtLPp/uP51LCkKNeOIpWVu0Uq1AQeqXAo43/WiS02H7rZYaLBL800 YHZKoN13xFYEoSFHUE/S2bnHDpPG7j3xFfxhbFe6OFIjfffsgDSRc5PFWoAjQoHuqJ54 00+A== MIME-Version: 1.0 X-Received: by 10.224.168.140 with SMTP id u12mr16725908qay.43.1367051230409; Sat, 27 Apr 2013 01:27:10 -0700 (PDT) Received: by 10.49.16.197 with HTTP; Sat, 27 Apr 2013 01:27:10 -0700 (PDT) Date: Sat, 27 Apr 2013 16:27:10 +0800 Message-ID: From: Lizhong Jin To: "mpls@ietf.org" Content-Type: multipart/alternative; boundary=20cf3074b684fa7c2c04db536a0d Subject: Re: [mpls] New Version Notification for draft-ietf-mpls-mldp-hsmp-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: Sat, 27 Apr 2013 08:27:12 -0000 --20cf3074b684fa7c2c04db536a0d Content-Type: text/plain; charset=ISO-8859-1 Hi all, We update this draft to 01, and section 8 is a newly added part for failure dection of HSMP LSP. We receive this comments from Pranjal, and thank Pranjal again. Any more comments are welcome. Regards Lizhong On Fri, Apr 19, 2013 at 11:11 PM, wrote: > > A new version of I-D, draft-ietf-mpls-mldp-hsmp-01.txt > has been successfully submitted by Lizhong Jin and posted to the > IETF repository. > > Filename: draft-ietf-mpls-mldp-hsmp > Revision: 01 > Title: LDP Extensions for Hub & Spoke Multipoint Label Switched > Path > Creation date: 2013-04-18 > Group: mpls > Number of pages: 13 > URL: > http://www.ietf.org/internet-drafts/draft-ietf-mpls-mldp-hsmp-01.txt > Status: http://datatracker.ietf.org/doc/draft-ietf-mpls-mldp-hsmp > Htmlized: http://tools.ietf.org/html/draft-ietf-mpls-mldp-hsmp-01 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-mldp-hsmp-01 > > Abstract: > This draft introduces a hub & spoke multipoint LSP (short for HSMP > LSP), which allows traffic both from root to leaf through P2MP LSP > and also leaf to root along the co-routed reverse path. That means > traffic entering the HSMP LSP from application/customer at the root > node travels downstream, exactly as if it was traveling downstream > along a P2MP LSP to each leaf node, and traffic entering the HSMP LSP > at any leaf node travels upstream along the tree to the root as if it > is unicast to the root, except that it follows the path of the tree > rather than ordinary unicast to the root. > > > > > > The IETF Secretariat > > --20cf3074b684fa7c2c04db536a0d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi all,
We update this draft to 01, and section 8 is a newly added part fo= r failure dection of HSMP LSP. We receive this comments from Pranjal, and t= hank Pranjal again. Any more comments are welcome.
=A0
Regards
Lizhong

On Fri, Apr 19, 2013 at 11:11 PM, <internet-drafts@ietf.org&g= t; wrote:

A new version of I-D, draft-ietf-mpls-mldp-hsmp-01.txt
has been successfully submitted by Lizhong Jin and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-ietf-mpls-mldp-hsmp
Revision: =A0 =A0 =A0 =A001
Title: =A0 =A0 =A0 =A0 =A0 LDP Extensions for Hub & Spoke Multipoint La= bel Switched Path
Creation date: =A0 2013-04-18
Group: =A0 =A0 =A0 =A0 =A0 mpls
Number of pages: 13
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/in= ternet-drafts/draft-ietf-mpls-mldp-hsmp-01.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/dra= ft-ietf-mpls-mldp-hsmp
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-ietf-m= pls-mldp-hsmp-01
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/rfcdiff= ?url2=3Ddraft-ietf-mpls-mldp-hsmp-01

Abstract:
=A0 =A0This draft introduces a hub & spoke multipoint LSP (short for HS= MP
=A0 =A0LSP), which allows traffic both from root to leaf through P2MP LSP =A0 =A0and also leaf to root along the co-routed reverse path. =A0That mean= s
=A0 =A0traffic entering the HSMP LSP from application/customer at the root<= br> =A0 =A0node travels downstream, exactly as if it was traveling downstream =A0 =A0along a P2MP LSP to each leaf node, and traffic entering the HSMP LS= P
=A0 =A0at any leaf node travels upstream along the tree to the root as if i= t
=A0 =A0is unicast to the root, except that it follows the path of the tree<= br> =A0 =A0rather than ordinary unicast to the root.





The IETF Secretariat


--20cf3074b684fa7c2c04db536a0d-- From johnsonhammond1@hushmail.com Sat Apr 27 14:08: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 21FBD21F9921 for ; Sat, 27 Apr 2013 14:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 1yMSN47mgeK9 for ; Sat, 27 Apr 2013 14:08:05 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by ietfa.amsl.com (Postfix) with ESMTP id 584E121F993C for ; Sat, 27 Apr 2013 14:08:05 -0700 (PDT) Received: from smtp1.hushmail.com (smtp1a.hushmail.com [65.39.178.236]) by smtp1.hushmail.com (Postfix) with SMTP id 78AD43098C for ; Sat, 27 Apr 2013 17:36:51 +0000 (UTC) X-hush-relay-time: 213 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w5.hushmail.com [65.39.178.80]) by smtp1.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:36:51 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 42C4BE6739; Sat, 27 Apr 2013 17:36:51 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:36:51 -0400 To: mpls@ietf.org From: johnsonhammond1@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427173651.42C4BE6739@smtp.hushmail.com> Subject: [mpls] Biggest Fake Conference in Computer Science 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, 27 Apr 2013 21:08:06 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links. From tochio@jp.fujitsu.com Mon Apr 29 16:52: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 8966C21F9AFF for ; Mon, 29 Apr 2013 16:52:06 -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 gqaSFvJfcttD for ; Mon, 29 Apr 2013 16:52:02 -0700 (PDT) Received: from fgwmail6.fujitsu.co.jp (fgwmail6.fujitsu.co.jp [192.51.44.36]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0C521F9B01 for ; Mon, 29 Apr 2013 16:52:02 -0700 (PDT) Received: from m2.gw.fujitsu.co.jp (unknown [10.0.50.72]) by fgwmail6.fujitsu.co.jp (Postfix) with ESMTP id 4EFAB3EE0BB for ; Tue, 30 Apr 2013 08:52:01 +0900 (JST) Received: from smail (m2 [127.0.0.1]) by outgoing.m2.gw.fujitsu.co.jp (Postfix) with ESMTP id 418F145DE4E for ; Tue, 30 Apr 2013 08:52:01 +0900 (JST) Received: from s2.gw.fujitsu.co.jp (s2.gw.fujitsu.co.jp [10.0.50.92]) by m2.gw.fujitsu.co.jp (Postfix) with ESMTP id 2774645DD6C for ; Tue, 30 Apr 2013 08:52:01 +0900 (JST) Received: from s2.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s2.gw.fujitsu.co.jp (Postfix) with ESMTP id 1BB6E1DB803A for ; Tue, 30 Apr 2013 08:52:01 +0900 (JST) Received: from flabmail.flab.fujitsu.co.jp (flabmail.flab.fujitsu.co.jp [10.25.192.37]) by s2.gw.fujitsu.co.jp (Postfix) with ESMTP id C11A01DB802C for ; Tue, 30 Apr 2013 08:52:00 +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 r3TNq0Bn018049 for ; Tue, 30 Apr 2013 08:52:00 +0900 (JST) X-AuditID: 0a19c027-b7f866d00000132d-31-517f07a0ccc9 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 AE.60.04909.0A70F715; Tue, 30 Apr 2013 08:52:00 +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 r3TNptNk028373 for ; Tue, 30 Apr 2013 08:52:00 +0900 (JST) X-SecurityPolicyCheck: OK by SHieldMailChecker v1.8.4 Message-ID: <517F078E.5030002@jp.fujitsu.com> Date: Tue, 30 Apr 2013 08:51:42 +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: mpls@ietf.org References: <20ECF67871905846A80F77F8F4A27572101502A9@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A27572101502A9@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprALMWRmVeSWpSXmKPExsXCJXkgU3cBe32gwf8DGha3lq5kdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxsMtPxgLGrgqPvbPZG9g/MPexcjJISFgInH3yi82CFtM4sK9 9UA2F4eQwGNGif6vsxkhnG4miYZLjVAdphIT1z1jBLF5BXQlFj89DBTn4GARUJWYdo0JJMwm oClxbeYdsBJRgWCJnx1TocoFJU7OfMICYosA2dOuHgWzhQWMgOyNYL1CAj4SE7YsYwWxOQV8 JfofPwazmYFW3TzxkQnClpfY/nYO8wRGgVlIxs5CUjYLSdkCRuZVjJJlxdmJ5Yl6aTmJSXpp pVmZJcWlesn5elkFmxghoai+g/HZIs1DjAIcjEo8vF/+1QUKsSaWFVfmHmKU4GBWEuE9fRMo xJuSWFmVWpQfX1Sak1p8iJGJg1OqgbG4Sd/K/qqnNu9UqSVXSwzSd2+1z1d7J7v1dzfbQ//C iX+/HWSduvXWrKlzz/W3TJqWuKAl207ib1Lmzf6/1+8I1FWssNzaefzU4mlLZ/y+sbvzGBdz pxdz74Jt7DfKzB19Lz7VlHjMXXB8Z5hRwC9msd2M7z8s+5n4cmLQ57/x33cae9dw6XQqsRRn JBpqMRcVJwIAYXAuaiMCAAA= 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: Mon, 29 Apr 2013 23:52:06 -0000 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 > From tochio@jp.fujitsu.com Mon Apr 29 17:09: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 AE8F821F9B79 for ; Mon, 29 Apr 2013 17:09:43 -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 j0nfj9OqmRTF for ; Mon, 29 Apr 2013 17:09: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 67A1921F9B7D for ; Mon, 29 Apr 2013 17:09:39 -0700 (PDT) Received: from m4.gw.fujitsu.co.jp (unknown [10.0.50.74]) by fgwmail5.fujitsu.co.jp (Postfix) with ESMTP id 77B283EE0AE for ; Tue, 30 Apr 2013 09:09:37 +0900 (JST) Received: from smail (m4 [127.0.0.1]) by outgoing.m4.gw.fujitsu.co.jp (Postfix) with ESMTP id 66D9C45DE50 for ; Tue, 30 Apr 2013 09:09:37 +0900 (JST) Received: from s4.gw.fujitsu.co.jp (s4.gw.fujitsu.co.jp [10.0.50.94]) by m4.gw.fujitsu.co.jp (Postfix) with ESMTP id 4F6B645DE4E for ; Tue, 30 Apr 2013 09:09:37 +0900 (JST) Received: from s4.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s4.gw.fujitsu.co.jp (Postfix) with ESMTP id 4141A1DB8037 for ; Tue, 30 Apr 2013 09:09:37 +0900 (JST) Received: from flabmail.flab.fujitsu.co.jp (flabmail.flab.fujitsu.co.jp [10.25.192.37]) by s4.gw.fujitsu.co.jp (Postfix) with ESMTP id E50E5E08001 for ; Tue, 30 Apr 2013 09:09:36 +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 r3U09ano019918 for ; Tue, 30 Apr 2013 09:09:36 +0900 (JST) X-AuditID: 0a19c027-b7f866d00000132d-ae-517f0bc01681 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 C2.A0.04909.0CB0F715; Tue, 30 Apr 2013 09:09:36 +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 r3U09WlV029505 for ; Tue, 30 Apr 2013 09:09:36 +0900 (JST) X-SecurityPolicyCheck: OK by SHieldMailChecker v1.8.4 Message-ID: <517F0BB1.4020208@jp.fujitsu.com> Date: Tue, 30 Apr 2013 09:09:21 +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: mpls@ietf.org References: <20ECF67871905846A80F77F8F4A2757210150296@xmb-rcd-x09.cisco.com> In-Reply-To: <20ECF67871905846A80F77F8F4A2757210150296@xmb-rcd-x09.cisco.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprILMWRmVeSWpSXmKPExsXCJXkgU/cAd32gwcV3Rha3lq5kdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxs7Ou+wFp7grjj64wNzAOJ+zi5GTQ0LAROL89XeMELaYxIV7 69m6GLk4hAQeM0q0nPsJ5XQzSbx88ZcFospUYuK6Z2AdvAK6Et9P3GMDsVkEVCV+tVwEi7MJ aEpcm3kHzBYVCJb42TEVql5Q4uTMJ2BzRIDsaVePgtnCAlYSB/dtYQKxhQR8JLrOfAObySng K/HiaQuYzQy06+aJj0wQtrzE9rdzmCcwCsxCMnYWkrJZSMoWMDKvYpQsK85OLE/US8tJTNJL K83KLCku1UvO18sq2MQICUb1HYzPFmkeYhTgYFTi4f3yry5QiDWxrLgy9xCjBAezkgjv6ZtA Id6UxMqq1KL8+KLSnNTiQ4xMHJxSDYw6Yne3Vm2tVFENyHuRGftMfL35m8LVWSps3M66didm La3Jkc+70fZ8do9lspoIz8L2WVJuTw+tt2a82nVy9exAYf0t61Zc8kivaQr1bW1Te/w0JM+k 5NtXr+t+Rcvi3dgmzqjscvn56N/Kfw1W017ns11+s/DKxUXu3yXimD1mXFvmWFe65LoSS3FG oqEWc1FxIgDvalKOJAIAAA== 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, 30 Apr 2013 00:09:43 -0000 Hi Eric O, and all Sorry for replying late. As my opinion, The first bullet below is Yes (to be swapped). The reason is in LS (liaison/1234) where the definition of FS is introduced (3.2.29, ITU-T G.870) And I would like to address the modification should be done within RFC 6378 (without specific updating RFC 5654 and RFC 4427). Thanks, Yuji (2013/04/17 21:16), Eric Osborne (eosborne) wrote: > 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 > From internet-drafts@ietf.org Tue Apr 30 11:15: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 A147821F9A98; Tue, 30 Apr 2013 11:15:28 -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 nt9F0xZCUT3M; Tue, 30 Apr 2013 11:15:28 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CCC9D21F9A71; Tue, 30 Apr 2013 11:15:27 -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: <20130430181527.3682.54685.idtracker@ietfa.amsl.com> Date: Tue, 30 Apr 2013 11:15:27 -0700 Cc: mpls@ietf.org Subject: [mpls] I-D Action: 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, 30 Apr 2013 18:15:28 -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 : Applicability of MPLS-TP Linear Protection for Ring Topo= logies Author(s) : Yaacov Weingarten Stewart Bryant Danielle Ceccarelli Diego Caviglia Francesco Fondelli Marco Corsi Bo Wu Xuehui Dai Filename : draft-ietf-mpls-tp-ring-protection-06.txt Pages : 30 Date : 2013-04-30 Abstract: 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. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-ring-protection There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-mpls-tp-ring-protection-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-mpls-tp-ring-protection-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From wyaacov@gmail.com Tue Apr 30 11:21: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 B69A621F9AAB for ; Tue, 30 Apr 2013 11:21: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 lfM8kyfgyRbh for ; Tue, 30 Apr 2013 11:21:21 -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 672A221F9AA7 for ; Tue, 30 Apr 2013 11:21:18 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id h11so4531979wiv.0 for ; Tue, 30 Apr 2013 11:21:17 -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:content-type; bh=IPMtyehVXasNgAFMbmXHyFik1CRCEgPwcsoJwOkNvTE=; b=z4yjvMTX9r7sSX4UwfyeO9KlAG3Owy0vT7uAU8IJO5gizxny8yTqQcE7nPP28EvUPu EYqd5L0HBfLQXpTuHOX+zGO7bsR7sz6NKIK2NMdqYCjTeuhxwBY0IQCS3u5d8nC6DSBq JY9oZsiRdZGft9NvgfK+7zbKTDpo5CocYQq8msvJ2O3FtL2RNgdk9vIMrNjCp+BDrKG+ eWFATwYoVvvgZNKtpZs5LSuxwUMH3jP90AVDkmDAsols8Frr/r3yCTLPuZJuAX0MWGrB 7ursRaZ45qc6Mn5IDDzfavU4xz8lexgvv/dVl9bys5ude3IwK4RuXFLuI/THKvpX/6e0 dPzA== MIME-Version: 1.0 X-Received: by 10.194.123.168 with SMTP id mb8mr105476691wjb.24.1367346077522; Tue, 30 Apr 2013 11:21:17 -0700 (PDT) Received: by 10.194.85.229 with HTTP; Tue, 30 Apr 2013 11:21:17 -0700 (PDT) In-Reply-To: <20130430181528.3682.6946.idtracker@ietfa.amsl.com> References: <20130430181528.3682.6946.idtracker@ietfa.amsl.com> Date: Tue, 30 Apr 2013 21:21:17 +0300 Message-ID: From: Yaacov Weingarten To: mpls@ietf.org, "draft-ietf-mpls-tp-ring-protection@tools.ietf.org" , "rtg-ads@tools-ietf.org" Content-Type: multipart/alternative; boundary=089e011831123c620204db9811d8 Subject: [mpls] Fwd: New Version Notification for 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, 30 Apr 2013 18:21:22 -0000 --089e011831123c620204db9811d8 Content-Type: text/plain; charset=ISO-8859-1 The latest version of the Applicability of MPLS-TP Linear Protection for Ring Topologies draft has been submitted to address the comments that were received during the IESG Last Call FYI Best Regards, yaacov weingarten ---------- Forwarded message ---------- From: Date: Tue, Apr 30, 2013 at 9:15 PM Subject: New Version Notification for draft-ietf-mpls-tp-ring-protection-06.txt To: Xuehui Dai , Diego Caviglia < diego.caviglia@ericsson.com>, Bo Wu , Francesco Fondelli < francesco.fondelli@ericsson.com>, Yaacov Weingarten , Marco Corsi , Danielle Ceccarelli < daniele.ceccarelli@ericsson.com>, Stewart Bryant A new version of I-D, draft-ietf-mpls-tp-ring-protection-06.txt has been successfully submitted by Yaacov Weingarten and posted to the IETF repository. Filename: draft-ietf-mpls-tp-ring-protection Revision: 06 Title: Applicability of MPLS-TP Linear Protection for Ring Topologies Creation date: 2013-04-29 Group: mpls Number of pages: 30 URL: http://www.ietf.org/internet-drafts/draft-ietf-mpls-tp-ring-protection-06.txt Status: http://datatracker.ietf.org/doc/draft-ietf-mpls-tp-ring-protection Htmlized: http://tools.ietf.org/html/draft-ietf-mpls-tp-ring-protection-06 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-mpls-tp-ring-protection-06 Abstract: 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. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunications Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and PWE3 architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. The IETF Secretariat -- Thanx and BR, yaacov *Still looking for new opportunity* --089e011831123c620204db9811d8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The latest version of the Applicability of MPLS-TP Linear = Protection for Ring Topologies draft has been submitted to address the comm= ents that were received during the IESG Last Call

FYI

Best Regards,
yaacov weingarten

---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Tue, Apr= 30, 2013 at 9:15 PM
Subject: New Version Notification for draft-ietf-mpls-tp-ring-protection-06= .txt
To: Xuehui Dai <dai.xuehui@zte.com.cn>, Diego Caviglia <diego.caviglia@ericsson= .com>, Bo Wu <wu.bo@zte.com.cn>, Francesco Fondelli <francesco.fondelli@ericsson.c= om>, Yaacov Weingarten <wyaacov@gmail.com>, Marco Corsi <corsi.marco@gmail.com>, Dan= ielle Ceccarelli <daniele.ceccarelli@ericsson.com>, Stewart Bryant <= stbryant@cisco.com<= /a>>



A new version of I-D, draft-ietf-mpls-tp-ring-protection-06.txt
has been successfully submitted by Yaacov Weingarten and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-ietf-mpls-tp-ring-protection
Revision: =A0 =A0 =A0 =A006
Title: =A0 =A0 =A0 =A0 =A0 Applicability of MPLS-TP Linear Protection for R= ing Topologies
Creation date: =A0 2013-04-29
Group: =A0 =A0 =A0 =A0 =A0 mpls
Number of pages: 30
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ie= tf.org/internet-drafts/draft-ietf-mpls-tp-ring-protection-06.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.or= g/doc/draft-ietf-mpls-tp-ring-protection
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/dra= ft-ietf-mpls-tp-ring-protection-06
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.or= g/rfcdiff?url2=3Ddraft-ietf-mpls-tp-ring-protection-06

Abstract:
=A0 =A0This document presents an applicability of existing MPLS protection<= br> =A0 =A0mechanisms, both local and end-to-end, to Multi-Protocol Label
=A0 =A0Switching Transport Profile (MPLS-TP) in ring topologies. =A0This =A0 =A0document does not propose any new mechanisms or protocols.
=A0 =A0Protection on rings offers a number of opportunities for optimizatio= n
=A0 =A0as the protection choices are starkly limited (all traffic traveling=
=A0 =A0one way around a ring can only be switched to travel the other way o= n
=A0 =A0the ring), but also suffers from some complications caused by the =A0 =A0limitations of the topology.

=A0 =A0Requirements for MPLS-TP protection especially for protection in rin= g
=A0 =A0topologies are discussed in "Requirements of an MPLS Transport<= br> =A0 =A0Profile" (RFC 5654) and "MPLS Transport Profile (MPLS-TP)<= br> =A0 =A0Survivability Framework" (RFC 6372). =A0This document shows how= MPLS-TP
=A0 =A0linear protection as defined in RFC 6378 can be applied to single =A0 =A0ring topologies, discusses how most of the requirements are met, and=
=A0 =A0describes scenarios in which the function provided by applying linea= r
=A0 =A0protection in a ring topology falls short of some of the
=A0 =A0requirements.

=A0 =A0This document is a product of a joint Internet Engineering Task Forc= e
=A0 =A0(IETF) / International Telecommunications Union Telecommunications =A0 =A0Standardization Sector (ITU-T) effort to include an MPLS Transport =A0 =A0Profile within the IETF MPLS and PWE3 architectures to support the =A0 =A0capabilities and functionalities of a packet transport network as =A0 =A0defined by the ITU-T.




The IETF Secretariat




--
Thanx an= d BR,
yaacov

Still looking for new opportun= ity
--089e011831123c620204db9811d8-- From wwwrun@rfc-editor.org Tue Apr 30 22:32: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 A32B721F86C4; Tue, 30 Apr 2013 22:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.464 X-Spam-Level: X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.136, 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 se95BckKWHmp; Tue, 30 Apr 2013 22:32:48 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id D92A121F84E3; Tue, 30 Apr 2013 22:32:47 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9F535B1E00A; Tue, 30 Apr 2013 22:32:17 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130501053217.9F535B1E00A@rfc-editor.org> Date: Tue, 30 Apr 2013 22:32:17 -0700 (PDT) Cc: mpls@ietf.org, rfc-editor@rfc-editor.org Subject: [mpls] RFC 6941 on MPLS Transport Profile (MPLS-TP) Security Framework 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 05:32:48 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6941 Title: MPLS Transport Profile (MPLS-TP) Security Framework Author: L. Fang, Ed., B. Niven-Jenkins, Ed., S. Mansfield, Ed., R. Graveman, Ed. Status: Informational Stream: IETF Date: April 2013 Mailbox: lufang@cisco.com, ben@niven-jenkins.co.uk, scott.mansfield@ericsson.com, rfg@acm.org Pages: 15 Characters: 27119 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mpls-tp-security-framework-09.txt URL: http://www.rfc-editor.org/rfc/rfc6941.txt This document provides a security framework for the MPLS Transport Profile (MPLS-TP). MPLS-TP extends MPLS technologies and introduces new Operations, Administration, and Maintenance (OAM) capabilities, a transport-oriented path protection mechanism, and strong emphasis on static provisioning supported by network management systems. This document addresses the security aspects relevant in the context of MPLS-TP specifically. It describes potential security threats as well as mitigation procedures related to MPLS-TP networks and to MPLS-TP interconnection to other MPLS and GMPLS networks. This document is built on RFC 5920 ("Security Framework for MPLS and GMPLS Networks") by providing additional security considerations that are applicable to the MPLS-TP extensions. All the security considerations from RFC 5920 are assumed to apply. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunication Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionality of a packet transport network. This document is a product of the Multiprotocol Label Switching Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. 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