From lberger@labn.net Mon Jul 1 03:31:45 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A29DB21F9C95 for ; Mon, 1 Jul 2013 03:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.039 X-Spam-Level: X-Spam-Status: No, score=-102.039 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g8HsQ3IzMUI8 for ; Mon, 1 Jul 2013 03:31:41 -0700 (PDT) Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 5C64921F9B10 for ; Mon, 1 Jul 2013 03:31:40 -0700 (PDT) Received: (qmail 16391 invoked by uid 0); 1 Jul 2013 10:31:09 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy13.unifiedlayer.com with SMTP; 1 Jul 2013 10:31:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=XsG9SFSLVfOBQvqorxA4F3jSKGbD2z8GQGkE4+qYXpI=; b=J2UvU5O8LQLraBS8AycG/omcZUrSeY5r5oo6X3+uq9Dgi/XmJUdxTX5kZCeJK++5TnOYpEgmtBNmfz3BCF/DRHLVQkXX79XRaOgW1+T13tF1NwwQLa5ELEm8N+fZGUZC; Received: from box313.bluehost.com ([69.89.31.113]:57217 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UtbO1-0000vr-Fh; Mon, 01 Jul 2013 04:31:09 -0600 Message-ID: <51D15A6C.6000103@labn.net> Date: Mon, 01 Jul 2013 06:31:08 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Fatai Zhang References: <51A8CB9D.40009@labn.net> <51BB95F9.5000401@labn.net> <5DF87403A81B0C43AF3EB1626511B29272C4F270@RCHEXMBP1.fnc.net.local> <51C9DA43.90800@labn.net> <51CDBE76.9070503@labn.net> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] =?utf-8?b?562U5aSNOiAgSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1j?= =?utf-8?q?camp-gmpls-signaling-g709v3-10=2Etxt?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 10:31:45 -0000 Fatai, When to submit the current list of outstanding changes (see http://tools.ietf.org/wg/ccamp/trac/ticket/57) is really up to you/the authors. That said, this document is still waiting on http://trac.tools.ietf.org/wg/ccamp/trac/ticket/55 so if you want, there's still a window do to the update. Lou On 06/30/2013 01:27 PM, Fatai Zhang wrote: > Hi Lou, > > I have changed the text in my local document, but I am not sure if it is necessary to submit a new version for this minor editorial change this time. > > How about I provide a new revision to address this comment and IESG comments together during IESG review ( I think there must be some comments from IESG review stage)? > > Anyway, I think I will certainly defer to your (WG chairs') preference, so your guidance is appreciated. > > > > > > > > -----邮件原件----- > 发件人: Lou Berger [mailto:lberger@labn.net] > 发送时间: 2013年6月29日 0:49 > 收件人: Fatai Zhang > 抄送: Gruman, Fred; CCAMP > 主题: Re: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-signaling-g709v3-10.txt > > Fatai, > When do you expect to have this submitted? > > Thanks, > Lou > > On 6/25/2013 8:48 PM, Fatai Zhang wrote: >> Hi Lou, >> >> Thanks, recorded, I will fix it in the next revision. >> >> >> >> >> >> Best Regards >> >> Fatai >> >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Wednesday, June 26, 2013 1:58 AM >> To: Fatai Zhang >> Cc: Gruman, Fred; CCAMP >> Subject: Re: [CCAMP] I-D Action: >> draft-ietf-ccamp-gmpls-signaling-g709v3-10.txt >> >> Fatai, >> I think both my and Fred's comments can be addressed by the following: >> s/(2.5Gbps, +/-100ppm)/2.5Gbps >> s/no longer/not >> >> or in the long form: >> >> OLD >> As shown in Figure 1, assume there is an ODUflex(CBR) service >> requesting a bandwidth of (2.5Gbps, +/-100ppm) from node A to node C. >> In other words, the ODUflex Traffic Parameters indicate that Signal >> Type is 20 (ODUflex(CBR)), Bit_Rate is 2.5Gbps (Note that the >> tolerance is no longer signaled as explained above). >> NEW >> As shown in Figure 1, assume there is an ODUflex(CBR) service >> requesting a bandwidth of 2.5Gbps from node A to node C. >> In other words, the ODUflex Traffic Parameters indicate that Signal >> Type is 20 (ODUflex(CBR)), Bit_Rate is 2.5Gbps (Note that the >> tolerance is not signaled as explained above). >> >> Fred, >> Does this work for you? >> >> Lou >> >> On 6/24/2013 9:22 PM, Fatai Zhang wrote: >>> Hi Fred, >>> >>> I added this sentence because of a comment from Lou (It is "Tolerance no longer signaled. Suggest saying as much"). >>> >>> I am OK to remove this sentence, but I would like to hear from Lou (either remove or refine it). >>> >>> >>> >>> >>> >>> >>> Best Regards >>> >>> Fatai >>> >>> -----Original Message----- >>> From: Gruman, Fred [mailto:fred.gruman@us.fujitsu.com] >>> Sent: Monday, June 24, 2013 9:52 PM >>> To: Fatai Zhang; Lou Berger; CCAMP >>> Subject: RE: [CCAMP] I-D Action: >>> draft-ietf-ccamp-gmpls-signaling-g709v3-10.txt >>> >>> Hello Fatai, >>> >>> I have one comment on Section 5.1. In this section, there is the following text: "Note that the tolerance is no longer signaled as explained above". >>> >>> I believe this sentence should be removed as tolerance was never signaled in a published RFC, only in early versions of the G.709 signaling drafts. This may be confusing to the reader once the RFC is published as the context to early drafts is lost. >>> >>> Best Regards, >>> Fred >>> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>> Behalf Of Fatai Zhang >>> Sent: Tuesday, June 18, 2013 9:06 PM >>> To: Lou Berger; CCAMP >>> Subject: Re: [CCAMP] I-D Action: >>> draft-ietf-ccamp-gmpls-signaling-g709v3-10.txt >>> >>> Hi Lou and all, >>> >>> A new version has been submitted to address the 2nd WG Last Call comments on this draft. >>> >>> Please take a look and any further comments are appreciated. >>> >>> >>> >>> >>> Best Regards >>> >>> Fatai >>> >>> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On >>> Behalf Of Lou Berger >>> Sent: Saturday, June 15, 2013 6:15 AM >>> To: CCAMP; draft-ietf-ccamp-gmpls-signaling-g709v3@tools.ietf.org >>> Subject: [CCAMP] 2nd WG Last Call comments on signaling-g709v3 >>> (editorial only) >>> >>> Hi, >>> The following are comments as part of my LC review of >>> draft-ietf-ccamp-gmpls-signaling-g709v3-09. Note that I'm the >>> document shepherd, see RFC 4858 for more information. >>> >>> As with other documents: >>> - This and the other g709v3 documents should be consistent in usage >>> of "TS granularity" versus "TSG". Sometimes one is used rather than >>> the other, sometimes both are used in the same document (as is the >>> case in this document). Please pick either one and update the four >>> documents to be consistent. >>> >>> - Another and related comment is please define and use a consistent >>> plural form of "TS". You initially define "TSs" to expand to "Time >>> Slots", but then use "TS" as the plural form in many (but not all >>> cases). I personally think "TSs" in all plural cases makes the most sense. >>> >>> - Also same comment for TSGs. >>> >>> - Please be consistent in usage of "Gbps". Some inconsistent examples: >>> "1.25Gps", "1.25 Gbps" and "1.25 Gbps". (I personally prefer the >>> final form, but any common form is fine.) >>> >>> Please see >>> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-ietf- >>> ccamp-gmpls-signaling-g709v3-09.txt >>> for line numbers used in this message. >>> >>> Line 47: >>> s/updates/provides an alternative to >>> >>> Line 49: >>> s/evolving OTN addressing ODUk multiplexing and new/full set of OTN >>> >>> Line 97: >>> s/updates/provides an alternative to >>> >>> Line 132: >>> s/[G.709-V3]/[G709-2012] >>> >>> Line 143: >>> drop "needs to be updated because it" >>> >>> Line 330: >>> "Here:" what? Do you mean "Where:"? >>> >>> Line 373: >>> s/PATH/Path >>> >>> Line 379: >>> s/MAY not/may not >>> >>> Lines 388/9: >>> Tolerance no longer signaled. Suggest saying as much. >>> >>> Lines 581: >>> s/ignored/ignored on receipt. >>> >>> Section 6. >>> You should consistently use formal object names throughout this >>> section, which can be found at >>> http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml. >>> e.g, "Label Set" --> "LABEL_SET Object". >>> >>> Line 591: >>> s/MAY not/need not >>> >>> Line 611: >>> As repeating whats in 3473, suggest lower case usage of 2119 terms. >>> >>> Line 624,625,626/7: >>> s/TS type/TSG >>> >>> Line 879. >>> How about adding to the beginning of the paragraph something along >>> the lines of: >>> This document is a modification to [RFC3473] and [RFC4328], and only >>> differs in specific information communicated. As such, this document >>> ... >>> >>> Lines 888-897 >>> How about: >>> Upon approval of this document, IANA will make the following >>> assignments in the "Class Types or C-Types ‒ 9 FLOWSPEC" and >>> "Class Types or C-Types ‒ 12 SENDER_TSPEC" section of the "RSVP >>> Parameters" registry located at >>> >>> http://www.iana.org/assignments/rsvp-parameters/rsvp-parameters.xml >>> >>> Value Description Reference >>> 7* OTN-TDM [This.I-D] >>> >>> (*) Suggested value >>> >>> Lines 905-909: >>> Drop lines >>> >>> Line 911->928: >>> to match registry, Replace with: >>> Value Type Technology Reference >>> ===== ====================== ========== >>> 47 G.709 ODU-2.5G G.709 ODUk [RFC4328], >>> (IANA to update Type field) [This.I-D] >>> 56 SBCON/ESCON G.709 ODUk, [RFC4328], >>> (IANA to update Type field) Lambda, Fiber [This.I-D] >>> 59* Framed GFP G.709 ODUk [This.I-D] >>> 60* STM-1 G.709 ODUk [This.I-D] >>> 61* STM-4 G.709 ODUk [This.I-D] >>> 62* InfiniBand G.709 ODUflex [This.I-D] >>> 63* SDI (Serial Digital Interface) G.709 ODUk [This.I-D] >>> 64* SDI/1.001 G.709 ODUk [This.I-D] >>> 65* DVB_ASI G.709 ODUk [This.I-D] >>> 66* G.709 ODU-1.25G G.709 ODUk [This.I-D] >>> 67* G.709 ODU-Any G.709 ODUk [This.I-D] >>> 68* Null Test G.709 ODUk [This.I-D] >>> 69* Random Test G.709 ODUk [This.I-D] >>> 70* 64B/66B GFP-F Ethernet G.709 ODUk [This.I-D] >>> >>> Line 930: >>> Add "Upon approval of this document, IANA will define a "OTN >>> >>> Line 931/932 >>> Drop to end of sentence starting with "will be defined by ..." >>> >>> Line 956: >>> add: >>> New values are to be assigned via Standards Action as defined in >>> [RFC5226]. >>> >>> Lines 1006-1023: >>> Aren't these all normative references? >>> >>> That's it, >>> Lou >>> >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>> _______________________________________________ >>> CCAMP mailing list >>> CCAMP@ietf.org >>> https://www.ietf.org/mailman/listinfo/ccamp >>> From zhang.xian@huawei.com Mon Jul 1 07:59:45 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C44D511E811F for ; Mon, 1 Jul 2013 07:59:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.421 X-Spam-Level: X-Spam-Status: No, score=-5.421 tagged_above=-999 required=5 tests=[AWL=-1.176, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_38=0.6, MIME_BASE64_TEXT=1.753, 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 bnfSKsBewSdy for ; Mon, 1 Jul 2013 07:59:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B5C8911E80D7 for ; Mon, 1 Jul 2013 07:59:39 -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 AUO53239; Mon, 01 Jul 2013 14:59:37 +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, 1 Jul 2013 15:59:28 +0100 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 1 Jul 2013 15:59:34 +0100 Received: from SZXEML510-MBX.china.huawei.com ([169.254.3.176]) by szxeml404-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Mon, 1 Jul 2013 22:57:34 +0800 From: "Zhangxian (Xian)" To: "ccamp@ietf.org" Thread-Topic: Review request for draft-zhang-ccamp-gmpls-uni-app Thread-Index: Ac52a1GqutiGx/AISje9nHY7yrPgVg== Date: Mon, 1 Jul 2013 14:57:34 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.76.5] Content-Type: multipart/alternative; boundary="_000_C636AF2FA540124E9B9ACB5A6BECCE6B189C37D4szxeml510mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [CCAMP] Review request for draft-zhang-ccamp-gmpls-uni-app X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 14:59:45 -0000 --_000_C636AF2FA540124E9B9ACB5A6BECCE6B189C37D4szxeml510mbxchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RGVhciBDaGFpcnMgYW5kIFdvcmtpbmcgR3JvdXAsDQoNCiAgICAgICBkcmFmdC16aGFuZy1jY2Ft cC1nbXBscy11bmktYXBwIGlzIHByZXNlbnRlZCBsYXN0IHRpbWUgdG8gc2hvdyBob3cgdGVjaG5p cXVlcyBkZXZlbG9wZWQgYWZ0ZXIgUkZDNDIwOCBjYW4gaGVscCB3aXRoIHNjZW5hcmlvcyB1c2lu ZyBVTkksIHN1Y2ggYXMgUENFIGhlbHBpbmcgd2l0aCBwYXRoIGNvbXB1dGF0aW9uIGFjcm9zcyBV TkkuIEl0IGlzIHdlbGwgcmVjZWl2ZWQgYW5kIENoYWlyIHN1Z2dlc3RlZCBpdCBzaG91bGQgYmUg ZGlzY3Vzc2VkIHRvZ2V0aGVyIHdpdGggb3RoZXIgZHJhZnRzLiAgRGlmZmVyZW50IGZyb20gdGhl IG92ZXJsYXkgdG9waWMgd2hpY2ggd2FzIGRpc2N1c3NlZCBhIGxvdChhbGxvd2luZyByb3V0aW5n IGFuZCBzaWduYWxpbmcgbWVzc2FnZXMgYWNyb3NzIHRoZSBpbnRlcmZhY2UpLCB0aGUgZHJhZnQg Y29uZmluZXMgaXRzZWxmIGZvciBVTkkgKG9ubHkgc2lnbmFsaW5nKS4NCg0KICAgVGhpcyBkcmFm dCBoYXMgYWxyZWFkeSBwcm92aWRlIGEgcmljaCBzZXQgb2YgdXNlIGNhc2VzLiBIb3dldmVyLCBp biBsaWdodCBvZiB0aGUgZXh0ZW5zaW9ucyBtYWRlIHRvIFJTVlAtVEUgaW4gdGhlIHdvcmtpbmcg Z3JvdXAsIHdlIGFsc28gcGxhbiB0byBhZGQgYSBzZWN0aW9uIG9uIHRoZSBmb2xsb3dpbmcgZnVu Y3Rpb25zIHdoaWNoIGNhbiBiZSBwZXJmb3JtZWQgb3ZlciBVTkk6DQoxKSAgUmVxdWlyaW5nIFRF LW1ldHJpYyBjb2xsZWN0aW9uLCBzdWNoIGFzIGRlbGF5LCBTUkxHIGV0Yy4NCjIpICBTcGVjaWZ5 aW5nIGNvbnN0cmFpbnRzIG9uIHRoZSBMU1AgZXN0YWJsaXNoZWQgYWNyb3NzIFVOSTsgc3VjaCBh cyBkZWxheSBldGMuDQoNCiAgSXMgdGhlcmUgb3RoZXIgdXNlIGNhc2VzIHRoaXMgZHJhZnQgc2hv dWxkIGFsc28gY29udGFpbj8gV2Ugd291bGQgbGlrZSB0byByZXF1ZXN0IGZvciBjb21tZW50cy9z dWdnZXN0aW9ucyBvbiBtb3ZpbmcgdGhpcyBkcmFmdCBmb3J3YXJkLiBQbGVhc2UgZmVlbCBmcmVl IHRvIGRpc2N1c3Mgb25saW5lL29mZmxpbmUuIFRoYW5rIHlvdS4NCg0KQmVzdCBSZWdhcmRzLA0K WGlhbiAob24gYmVoYWxmIG9mIGFsbCBhdXRob3JzKQ0K --_000_C636AF2FA540124E9B9ACB5A6BECCE6B189C37D4szxeml510mbxchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable
Dear = Chairs and Working Group,
 
 = ;      draft-zhang-ccamp-gmpls-uni-app is presente= d last time to show how techniques developed after RFC4208 can help with sc= enarios using UNI, such as PCE helping with path computation across UNI. It is wel= l received and Chair suggested it should be discussed together with ot= her drafts.  Different from the overlay topic which was disc= ussed a lot(allowing routing and signaling messages across the interface), the draft confines itself for UNI (only signaling).=
 
 = ;  This draft has already provide a rich set of use cases. Howeve= r, in light of the extensions made to RSVP-TE in the working group, we also plan to add a section on the foll= owing functions which can be performed over UNI:
1)&nb= sp; Requiring TE-metric collection, such as delay, SRLG etc.<= /font>
2)&nb= sp; Specifying constraints on the LSP established across UNI; such as delay= etc.
 
 = ; Is there other use cases this draft should also contain? We would li= ke to request for comments/suggestions on moving this draft forward. Please feel free to discuss online/offline. Thank you.
 
Xian = (on behalf of all authors)
--_000_C636AF2FA540124E9B9ACB5A6BECCE6B189C37D4szxeml510mbxchi_-- From internet-drafts@ietf.org Tue Jul 2 00:50:35 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661BA11E8411; Tue, 2 Jul 2013 00:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.471 X-Spam-Level: X-Spam-Status: No, score=-102.471 tagged_above=-999 required=5 tests=[AWL=0.129, 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 StJrkEdmXnYm; Tue, 2 Jul 2013 00:50:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EEF8111E8406; Tue, 2 Jul 2013 00:50: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.51.p2 Message-ID: <20130702075034.15749.61269.idtracker@ietfa.amsl.com> Date: Tue, 02 Jul 2013 00:50:34 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 07:50:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Generalized Multi-Protocol Label Switching (GMPLS) Signa= ling Extensions for the evolving G.709 Optical Transport Networks Control Author(s) : Fatai Zhang Guoying Zhang Sergio Belotti Daniele Ceccarelli Khuzema Pithewan Filename : draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt Pages : 28 Date : 2013-07-02 Abstract: ITU-T Recommendation G.709 [G709-2012] has introduced new Optical channel Data Unit (ODU) containers (ODU0, ODU4, ODU2e and ODUflex) and enhanced Optical Transport Networking (OTN) flexibility. This document updates the ODU-related portions of RFC4328 to to provide the extensions to the Generalized Multi-Protocol Label Switching (GMPLS) signaling to control the full set of OTN features including ODU0, ODU4, ODU2e and ODUflex. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-signaling-g709v3 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-gmpls-signaling-g709v3-= 11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From zhangfatai@huawei.com Tue Jul 2 00:55:18 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C44AF11E8417 for ; Tue, 2 Jul 2013 00:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.679 X-Spam-Level: X-Spam-Status: No, score=-1.679 tagged_above=-999 required=5 tests=[AWL=-4.468, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PXWaNdU12vhg for ; Tue, 2 Jul 2013 00:55:14 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D1DEA11E83D5 for ; Tue, 2 Jul 2013 00:55:13 -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 AUP09443; Tue, 02 Jul 2013 07:55: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; Tue, 2 Jul 2013 08:53:49 +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; Tue, 2 Jul 2013 08:54:47 +0100 Received: from SZXEML552-MBS.china.huawei.com ([169.254.2.94]) by szxeml401-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Tue, 2 Jul 2013 15:54:41 +0800 From: Fatai Zhang To: "ccamp@ietf.org" , Lou Berger Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt Thread-Index: AQHOdvkHaqRvgPGvp0Owg9hhufLfH5lRBCUg Date: Tue, 2 Jul 2013 07:54:40 +0000 Message-ID: References: <20130702075034.15749.61269.idtracker@ietfa.amsl.com> In-Reply-To: <20130702075034.15749.61269.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.71.228] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [CCAMP] =?gb2312?b?tPC4tDogIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2Nh?= =?gb2312?b?bXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0xMS50eHQ=?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 07:55:18 -0000 SGkgYWxsLA0KDQpBIG5ldyB2ZXJzaW9uIGhhcyBiZWVuIHN1Ym1pdHRlZCB0byBhZGRyZXNzIHRo ZSBjaGFuZ2VzIGZyb20gVHJhYyBUaWNrZXQgIzU3Lg0KDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcv d2cvY2NhbXAvdHJhYy90aWNrZXQvNTcNCg0KDQpUaGFua3MNCg0KRmF0YWkNCg0KLS0tLS3Tyrz+ 1K28/i0tLS0tDQq3orz+yMs6IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1i b3VuY2VzQGlldGYub3JnXSC0+rHtIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0Kt6LLzcqxvOQ6 IDIwMTPE6jfUwjLI1SAxNTo1MQ0KytW8/sjLOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCrOty806 IGNjYW1wQGlldGYub3JnDQrW98ziOiBbQ0NBTVBdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2Nh bXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0xMS50eHQNCg0KDQpBIE5ldyBJbnRlcm5ldC1EcmFm dCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3Jp ZXMuDQogVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQ29tbW9uIENvbnRyb2wgYW5k IE1lYXN1cmVtZW50IFBsYW5lIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQoNCglUaXRsZSAg ICAgICAgICAgOiBHZW5lcmFsaXplZCBNdWx0aS1Qcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgKEdN UExTKSBTaWduYWxpbmcgRXh0ZW5zaW9ucyBmb3IgdGhlIGV2b2x2aW5nIEcuNzA5IE9wdGljYWwg VHJhbnNwb3J0IE5ldHdvcmtzIENvbnRyb2wNCglBdXRob3IocykgICAgICAgOiBGYXRhaSBaaGFu Zw0KICAgICAgICAgICAgICAgICAgICAgICAgICBHdW95aW5nIFpoYW5nDQogICAgICAgICAgICAg ICAgICAgICAgICAgIFNlcmdpbyBCZWxvdHRpDQogICAgICAgICAgICAgICAgICAgICAgICAgIERh bmllbGUgQ2VjY2FyZWxsaQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBLaHV6ZW1hIFBpdGhl d2FuDQoJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWduYWxpbmct ZzcwOXYzLTExLnR4dA0KCVBhZ2VzICAgICAgICAgICA6IDI4DQoJRGF0ZSAgICAgICAgICAgIDog MjAxMy0wNy0wMg0KDQpBYnN0cmFjdDoNCiAgIElUVS1UIFJlY29tbWVuZGF0aW9uIEcuNzA5IFtH NzA5LTIwMTJdIGhhcyBpbnRyb2R1Y2VkIG5ldyBPcHRpY2FsDQogICBjaGFubmVsIERhdGEgVW5p dCAoT0RVKSBjb250YWluZXJzIChPRFUwLCBPRFU0LCBPRFUyZSBhbmQgT0RVZmxleCkNCiAgIGFu ZCBlbmhhbmNlZCBPcHRpY2FsIFRyYW5zcG9ydCBOZXR3b3JraW5nIChPVE4pIGZsZXhpYmlsaXR5 Lg0KDQogICBUaGlzIGRvY3VtZW50IHVwZGF0ZXMgdGhlIE9EVS1yZWxhdGVkIHBvcnRpb25zIG9m IFJGQzQzMjggdG8NCiAgIHRvIHByb3ZpZGUgdGhlIGV4dGVuc2lvbnMgdG8gdGhlIEdlbmVyYWxp emVkIE11bHRpLVByb3RvY29sIExhYmVsDQogICBTd2l0Y2hpbmcgKEdNUExTKSBzaWduYWxpbmcg dG8gY29udHJvbCB0aGUgZnVsbCBzZXQgb2YgT1ROIGZlYXR1cmVzDQogICBpbmNsdWRpbmcgT0RV MCwgT0RVNCwgT0RVMmUgYW5kIE9EVWZsZXguDQoNCg0KDQoNCg0KVGhlIElFVEYgZGF0YXRyYWNr ZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQpodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMNCg0KVGhl cmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6DQpodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLWNjYW1wLWdtcGxzLXNpZ25hbGluZy1nNzA5djMtMTEN Cg0KQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KaHR0 cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1zaWdu YWxpbmctZzcwOXYzLTExDQoNCg0KSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBi eSBhbm9ueW1vdXMgRlRQIGF0Og0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8N Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNDQU1Q IG1haWxpbmcgbGlzdA0KQ0NBTVBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vY2NhbXANCg== From lberger@labn.net Tue Jul 2 05:28:40 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F08E11E80E9 for ; Tue, 2 Jul 2013 05:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.507 X-Spam-Level: X-Spam-Status: No, score=-97.507 tagged_above=-999 required=5 tests=[AWL=-4.646, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RDNS_NONE=0.1, SARE_SUB_ENC_GB2312=1.345, 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 6jHQBYqlEIUs for ; Tue, 2 Jul 2013 05:28:35 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (unknown [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id D0CF321F9FFA for ; Tue, 2 Jul 2013 05:28:02 -0700 (PDT) Received: (qmail 15485 invoked by uid 0); 2 Jul 2013 12:26:46 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.bluehost.com with SMTP; 2 Jul 2013 12:26:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=DOSzAoCpThneWlkRA1+h/PP5Gt5j0KXdmOZPawSP7Uk=; b=oKUik3pvuU6UHYOUJFLTsM/sFUrgAs+Rn0aVrYZK8a3PPPdmnPSs1HEbmYz9FZWQSfKx7HLoN5HgUQbg0NsBcjgYkDY87530CUPgW55pHJgFkS/d7yOl59oL413lnYE6; Received: from [69.89.31.113] (port=53261 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UtzfS-0001rr-7Q; Tue, 02 Jul 2013 06:26:46 -0600 Message-ID: <51D2C6F3.4070306@labn.net> Date: Tue, 02 Jul 2013 08:26:27 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Fatai Zhang References: <20130702075034.15749.61269.idtracker@ietfa.amsl.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] =?gb2312?b?tPC4tDogIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2Nh?= =?gb2312?b?bXAtZ21wbHMtc2lnbmFsaW5nLWc3MDl2My0xMS50eHQ=?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2013 12:28:40 -0000 Fatai, Excellent. Now we just need the OSPF draft to be updated (http://www.ietf.org/mail-archive/web/ccamp/current/msg14925.html) and we can request publication! Lou On 7/2/2013 3:54 AM, Fatai Zhang wrote: > Hi all, > > A new version has been submitted to address the changes from Trac Ticket #57. > > http://tools.ietf.org/wg/ccamp/trac/ticket/57 > > > Thanks > > Fatai > > -----ʼԭ----- > : ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] internet-drafts@ietf.org > ʱ: 201372 15:51 > ռ: i-d-announce@ietf.org > : ccamp@ietf.org > : [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control > Author(s) : Fatai Zhang > Guoying Zhang > Sergio Belotti > Daniele Ceccarelli > Khuzema Pithewan > Filename : draft-ietf-ccamp-gmpls-signaling-g709v3-11.txt > Pages : 28 > Date : 2013-07-02 > > Abstract: > ITU-T Recommendation G.709 [G709-2012] has introduced new Optical > channel Data Unit (ODU) containers (ODU0, ODU4, ODU2e and ODUflex) > and enhanced Optical Transport Networking (OTN) flexibility. > > This document updates the ODU-related portions of RFC4328 to > to provide the extensions to the Generalized Multi-Protocol Label > Switching (GMPLS) signaling to control the full set of OTN features > including ODU0, ODU4, ODU2e and ODUflex. > > > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-signaling-g709v3 > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-signaling-g709v3-11 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-ccamp-gmpls-signaling-g709v3-11 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From internet-drafts@ietf.org Thu Jul 4 02:12:33 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1828221F9F6A; Thu, 4 Jul 2013 02:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.105, 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 1HOQj4J3IClB; Thu, 4 Jul 2013 02:12:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DF5421F9F5F; Thu, 4 Jul 2013 02:12:32 -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.51.p2 Message-ID: <20130704091232.12430.98055.idtracker@ietfa.amsl.com> Date: Thu, 04 Jul 2013 02:12:32 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-ospf-g709v3-08.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 09:12:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Traffic Engineering Extensions to OSPF for Generalized M= PLS (GMPLS) Control of Evolving G.709 OTN Networks Author(s) : Daniele Ceccarelli Diego Caviglia Fatai Zhang Dan Li Sergio Belotti Pietro Vittorio Grandi Rajan Rao Khuzema Pithewan John E Drake Filename : draft-ietf-ccamp-gmpls-ospf-g709v3-08.txt Pages : 34 Date : 2013-07-04 Abstract: This document describes Open Shortest Path First - Traffic Engineering (OSPF-TE) routing protocol extensions to support Generalized MPLS (GMPLS) control of Optical Transport Networks (OTN) specified in ITU-T Recommendation G.709 as published in 2012. It extends mechanisms defined in RFC4203. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-ospf-g709v3 There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-gmpls-ospf-g709v3-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-gmpls-ospf-g709v3-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From daniele.ceccarelli@ericsson.com Thu Jul 4 02:13:32 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B11F121F9F6B for ; Thu, 4 Jul 2013 02:13:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.424 X-Spam-Level: X-Spam-Status: No, score=-4.424 tagged_above=-999 required=5 tests=[AWL=1.825, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veyi-Y3QtQ6E for ; Thu, 4 Jul 2013 02:13:27 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 31ED721F9F5F for ; Thu, 4 Jul 2013 02:13:27 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-28-51d53cb448d1 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 23.43.19388.4BC35D15; Thu, 4 Jul 2013 11:13:24 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.30]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Thu, 4 Jul 2013 11:13:23 +0200 From: Daniele Ceccarelli To: Lou Berger Thread-Topic: 2nd WG Last Call comments on ospf-g709v3 (editorial only) Thread-Index: AQHOaT5Cf8xlCy0KhEe413e0mrGZ+Zk5kc0QgAADdACAAAOEYIANEauAgA2k98A= Date: Thu, 4 Jul 2013 09:13:22 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE480FD0A0@ESESSMB301.ericsson.se> References: <4A1562797D64E44993C5CBF38CF1BE480EEBF7@ESESSMB301.ericsson.se> <51C9DD01.2030605@labn.net> In-Reply-To: <51C9DD01.2030605@labn.net> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvre4Wm6uBBmu2yFg8mXODxeJvw2sW i47mtywOzB5Llvxk8viwqZnN48vlz2wBzFFcNimpOZllqUX6dglcGUd3yBUslKj4fWcXYwPj O6EuRk4OCQETicW3ZjNB2GISF+6tZ+ti5OIQEjjMKHF42VdGCGcRo8TphdtZuhg5ONgErCSe HPIBaRARUJT4+nERE0gNs0A7o8Ssho2sIAlhATeJla0XmCGK3CX+bboNZftJ9DQ/ZgGxWQRU JD6taAKr5xXwlti5thPsCiGBTIntJ6cwgticAhoSrae/sYHYjAKyEhN2LwKLMwuIS9x6Mh/q agGJJXvOM0PYohIvH/9jhbAVJXaebWeGqNeTuDF1ChuErS2xbOFrZoi9ghInZz5hmcAoNgvJ 2FlIWmYhaZmFpGUBI8sqRvbcxMyc9HLzTYzAuDm45bfBDsZN98UOMUpzsCiJ827WOxMoJJCe WJKanZpakFoUX1Sak1p8iJGJg1OqgTH62J+Otu32d5UPrAk1ve3bcOdMoaidsur7iz+sxZvt 322oPlzUk+fymkW0Y3J5n7bKh+MRL6+/9jd4Ly7+19YoK8f9ehevWfniMzoTLm3+z+7toRg6 T7A/bGH0Z1Nv5Xf7Tov2t26dE7b82y4D8ZergtbOKC+PfNb0Wsq28d0nhvi6ldN8niixFGck GmoxFxUnAgDZp6KiaQIAAA== Cc: CCAMP , "draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org" Subject: Re: [CCAMP] 2nd WG Last Call comments on ospf-g709v3 (editorial only) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 09:13:32 -0000 Hi Lou, CCAMP, A new version of the draft has been uploaded addressing the comments below. BR Daniele > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: marted=EC 25 giugno 2013 20:10 > To: Daniele Ceccarelli > Cc: CCAMP; draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org > Subject: Re: 2nd WG Last Call comments on ospf-g709v3 (editorial only) >=20 >=20 > Daniele, >=20 > Please see below. I trimmed the text down a bit, let me know if I missed= any > discussion points. >=20 > On 6/25/2013 5:59 AM, Daniele Ceccarelli wrote: > > Hi Lou, > > > > All comments addressed. Some comments in line below. > > >=20 > Much thanks: >=20 > The following nits will need to be fixed in the next rev (and before goin= g to > the IESG) >=20 > =3D=3D Missing Reference: 'RFC5226' is mentioned on line 1162, but not = defined >=20 > =3D=3D Unused Reference: 'RFC4202' is defined on line 1237, but no expl= icit > reference was found in the text >=20 done=20 >=20 > > BR > > Daniele > > > >> -----Original Message----- > >> From: Lou Berger [mailto:lberger@labn.net] > >> Sent: venerd=EC 14 giugno 2013 22.32 > >> To: CCAMP; draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org > >> Subject: 2nd WG Last Call comments on ospf-g709v3 (editorial only) > >> > >> Hi, > >> The following are comments as part of my LC review of > >> draft-ietf-ccamp-gmpls-ospf-g709v3-06. Note that I'm the document > >> shepherd, see RFC 4858 for more information. > >> > >> Please see > >> http://tools.ietf.org/idnits?url=3Dhttp://tools.ietf.org/id/draft > > -ietf-ccamp-gmpls-ospf-g709v3-06.txt > >> for line numbers used in this message. > ... >=20 > >> Lines 192/3: > >> "The TE-Link is referred to as OTUk-TE-Link." > >> This term is used just once in the document. Suggest dropping it. > >> > > > > OK > still TBD.=09 I don't know why it was still there. Removed now. >=20 > > > >> Lines 193/4: > >> Doesn't the TE link for an OTUk physical Link always provide ODUk > >> capacity? Either way this text needs to be fixed/clarified. > > > > What about dropping all of this text: > > The TE-Link is > > 193 referred to as OTUk-TE-Link. The OTUk-TE-Link advertises ODUj > > 194 switching capacity. The advertised capacity could include ODUk > > 195 switching capacity. > sure. >=20 > ... Done >=20 > >> > >> Lines 210-212,221: > >> ODUj vs ODUk. Isn't it the case that a multi hop TE link could > >> represent either ODUj or ODUk resources? This isn't clear from the > >> current text/usage of ODUj/k. > >> > > > > > > New text: > > > > It is possible to create TE-Links that span more than one hop > > by creating FA between non-adjacent nodes. > > As in the one hop case, these types of ODUk-TE-Links also advertise > > ODU switching capacity. >=20 > why not just align with the figure name and use "Multiple hop TE-Link" > rather than introduce a new otherwise unused term "ODUk-TE-Links"? >=20 > ... Agree. Modified accordingly >=20 > Thanks, > Lou From ogondio@tid.es Thu Jul 4 02:23:12 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B6C21F9F7C for ; Thu, 4 Jul 2013 02:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JYNJf3-ULeQ for ; Thu, 4 Jul 2013 02:23:07 -0700 (PDT) Received: from correo-bck.tid.es (correo-bck.tid.es [195.235.93.200]) by ietfa.amsl.com (Postfix) with ESMTP id 31B9321F9F7E for ; Thu, 4 Jul 2013 02:23:07 -0700 (PDT) Received: from sbrightmailg02.hi.inet (Sbrightmailg02.hi.inet [10.95.78.105]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0MPE00B0INEHS3@tid.hi.inet> for ccamp@ietf.org; Thu, 04 Jul 2013 11:23:05 +0200 (MEST) Received: from vanvan (vanvan.hi.inet [10.95.78.49]) by sbrightmailg02.hi.inet (Symantec Messaging Gateway) with SMTP id B5.52.02911.9FE35D15; Thu, 04 Jul 2013 11:23:05 +0200 (CEST) Received: from correo.tid.es (mailhost.hi.inet [10.95.64.100]) by tid.hi.inet (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0MPE00B0CNEHS3@tid.hi.inet> for ccamp@ietf.org; Thu, 04 Jul 2013 11:23:05 +0200 (MEST) Received: from EX10-MB2-MAD.hi.inet ([169.254.2.38]) by EX10-HTCAS8-MAD.hi.inet ([fe80::41c8:e965:8a6:de67%11]) with mapi id 14.02.0328.009; Thu, 04 Jul 2013 11:23:04 +0200 Date: Thu, 04 Jul 2013 09:23:04 +0000 From: =?iso-8859-1?Q?Oscar_Gonz=E1lez_de_Dios?= X-Originating-IP: [10.95.64.115] To: CCAMP Message-id: <7CFF94B047D8864CB6268315034E35DE2F5F34CD@EX10-MB2-MAD.hi.inet> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_JCEG7Msr25Aymxygss88QA)" Content-language: es-ES Accept-Language: es-ES, en-US Thread-topic: Question about partial SRLG collection flags Thread-index: AQHOeJgWX8WHlvXGlEewi62HEDVJAw== user-agent: Microsoft-MacOutlook/14.2.5.121010 X-AuditID: 0a5f4e69-b7f118e000000b5f-58-51d53ef99dd8 X-MS-Has-Attach: X-MS-TNEF-Correlator: X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsXCFe9nqPvT7mqgwesVJhZP5txgcWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrbV21gKphpXHH8zk7WB8blWFyMnh4SAiUTzhl9sELaYxIV7 64FsLg4hge2MEtef9bNDOD8ZJQ4/mM0CUiUksIFR4s+0cBCbRUBV4lvvUbBuNgEHiXWLesFs YQFTiZW3DjFCTFWQ+HPuMViviICUxM19t4CGcnDwCnhLHLmaChLmFRCU+DH5HgtImFkgV2Lm KbApzALiEnN+TWQFsRkFZCVWnj/NCDHFSuLTildQtp7Ewm8zwOpFgey2Y2fYIbYKSCzZc54Z whaVePn4H+sERpFZSLbNQtg2C8k2CFtP4sbUKVBxbYllC18zQ9i6EjP+HWKBsM0kWmfOQFGz gJFjFaNYcVJRZnpGSW5iZk66gZFeRqZeZl5qySZGSGRl7mBcvlPlEKMAB6MSD6+E1ZVAIdbE suLK3EOMEhzMSiK8ThxXA4V4UxIrq1KL8uOLSnNSiw8xMnFwSjUwLtGfKR7OnVyusekNf5t1 nGvBvOv//hz+a/iq3lhDrm+GzGcRSf5I11gjtogpLnW1/JdF+wOKFebbH867d/3LplPZ3bNC /1g6zlBtFn3sNL+2smdiwe+gm8IbvC97vWnXWjSL65bbqjm+D/gbjm245uOsk7yDWZVfaKXl 7bAbGeHsv17zfbyjxFKckWioxVxUnAgAxFXOnooCAAA= Subject: [CCAMP] Question about partial SRLG collection flags X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 09:23:12 -0000 --Boundary_(ID_JCEG7Msr25Aymxygss88QA) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Dear CCAMP WG chairs and CCAMPrs, In the last IETF meeting we presented RSVP-TE Extensions for Collecting SR= LG Information ( draft-ietf-ccamp-rsvp-te-srlg-collect-02). This draft is a= bout collecting SRLG information in the RRO. We included a couple of flags = in the new SRLG sub-object, one to indicate if the SRLG-list contained in t= he RRO sub-object has been edited in some way by a node during signaling in= accordance with that node's policy ,and another one to indicate if the hat= the SRLG-list contained in this RRO sub-object is known to be incomplete. After presenting , Lou mentioned that he partial SRLG-list flags nee= ds to be separated into an individual draft if it is a generic function. We= have been discussing this point and have some doubts that we would like to= share with the WG. First, the edited flag/partial flag could potentially a= pply to any collected sub-object, and thus can be considered generic. There= are at least two drafts now (the SRLG collection and the TE metric recordi= ng) where this functionality is useful. However, if we want to make the fla= gs generic, there are several issues: the RRO subjects are TLVs, and each = subobject is defined independently. Thus, there is no common RRO sub objec= t header where the generic flags could fit. Another potential problem is th= at all RRO TLVs defined so far have an 8-bit flags field; if we want to go = for something consistent, this will probably have to expand at some point. = In addition, there isn't a consistent place for the flags to go (e.g. the I= Pv4/6 address objects put them at the end of the TLV, whereas the others ha= ve them towards the beginning. We would like to know your opinion on the matter, so we can take the = decision of keeping the flags in the SRLG collection draft, and that if oth= er drafts use the same flags they define them again for their RRO sub objec= ts, or going for a draft to define this flags, but here we have the mention= ed doubts on the approach. Best Regards, Oscar on behalf of draft-ietf-ccamp-rsvp-te-srlg-collect authors. ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo. This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx --Boundary_(ID_JCEG7Msr25Aymxygss88QA) Content-id: <48BA4C2E58EB3345B3E60FE1A7B87112@hi.inet> Content-type: text/html; charset=iso-8859-1 Content-transfer-encoding: quoted-printable
Dear CCAMP WG chairs and CCAMPrs,

In the= last IETF meeting we presented  RSVP-TE Extensions for Collectin= g SRLG Information ( draft-ietf-ccamp-rsvp-te-srlg-collect-02). This d= raft is about collecting SRLG information in the RRO. We included a couple of flags in the new SRLG sub-object, one to indi= cate if the SRLG-list contained in the RRO sub-object has been ed= ited in some way by a node during signaling in accordance with that no= de's policy ,and another one to indicate if the hat the SRLG-list contained in this RRO sub-object is known to be incompl= ete. 
    
       After presenting , Lou mentioned that = he partial SRLG-list flags needs to be separated into an individu= al draft if it is a generic function. We have been discussing this point an= d have some doubts that we would like to share with the WG. First, the edited flag/partial flag could potentially apply to any collected sub-= object, and thus can be considered generic. There are at least two drafts n= ow (the SRLG collection and the TE metric recording) where this functionali= ty is useful. However, if we want to make the flags generic,  there are several issues: the RRO subject= s are TLVs, and each subobject is  defined independently. Thus, t= here is no common RRO sub object header where the generic flags could fit. = Another potential problem is that all RRO TLVs defined so far have an 8-bit flags field; if we want to go for someth= ing consistent, this will probably have to expand at some point. In ad= dition, there isn't a consistent place for the flags to go (e.g. the I= Pv4/6 address objects put them at the end of the TLV, whereas the others have them towards the beginning.

      We would like to know your opinion on the matter,= so we can take the decision of keeping the flags in the SRLG collection dr= aft, and that if other drafts use the same flags they define them again for= their RRO sub objects, or going for a draft to define this flags, but here we have the mentioned doubts on the approach.<= /div>

Best R= egards,

Oscar = on behalf of draft-ietf-ccamp-rsvp-te-srlg-collect authors. 




Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nu= estra pol=EDtica de env=EDo y recepci=F3n de correo electr=F3nico en el enl= ace situado m=E1s abajo.
This message is intended exclusively for its addressee. We only send and re= ceive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
 --Boundary_(ID_JCEG7Msr25Aymxygss88QA)-- From lberger@labn.net Thu Jul 4 08:15:23 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E27121F9F58 for ; Thu, 4 Jul 2013 08:15:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.279 X-Spam-Level: X-Spam-Status: No, score=-101.279 tagged_above=-999 required=5 tests=[AWL=0.986, 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 b8VRcfflP0wa for ; Thu, 4 Jul 2013 08:15:19 -0700 (PDT) Received: from oproxy13-pub.unifiedlayer.com (oproxy13-pub.unifiedlayer.com [69.89.16.30]) by ietfa.amsl.com (Postfix) with SMTP id 0ED6E21F9ED8 for ; Thu, 4 Jul 2013 08:15:18 -0700 (PDT) Received: (qmail 30982 invoked by uid 0); 4 Jul 2013 15:14:55 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy13.unifiedlayer.com with SMTP; 4 Jul 2013 15:14:55 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=XmEPNICHYjCkf1thOji80O4h4aNDh4PUQm8IK8RABwk=; b=A2CvBL6nOfEpP3wYoNQA/tyubpg9ljzKVyHKITqBHB+pVvFSkYQcrmyfIEVjnCF80WYRg8YZ8mXjny+YQSxS8ar+2gjEtnNN0C0P5hdCbnZN3BIBCTNtdL7TFBxPF0Lf; Received: from box313.bluehost.com ([69.89.31.113]:46652 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UulFG-0003CK-Ok; Thu, 04 Jul 2013 09:14:55 -0600 Message-ID: <51D59167.5050702@labn.net> Date: Thu, 04 Jul 2013 11:14:47 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Daniele Ceccarelli References: <4A1562797D64E44993C5CBF38CF1BE480EEBF7@ESESSMB301.ericsson.se> <51C9DD01.2030605@labn.net> <4A1562797D64E44993C5CBF38CF1BE480FD0A0@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE480FD0A0@ESESSMB301.ericsson.se> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP , "draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org" Subject: Re: [CCAMP] 2nd WG Last Call comments on ospf-g709v3 (editorial only) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 15:15:23 -0000 Thanks Daniele. On 7/4/2013 5:13 AM, Daniele Ceccarelli wrote: > Hi Lou, CCAMP, > > A new version of the draft has been uploaded addressing the comments below. > > BR > Daniele > >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: marted 25 giugno 2013 20:10 >> To: Daniele Ceccarelli >> Cc: CCAMP; draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org >> Subject: Re: 2nd WG Last Call comments on ospf-g709v3 (editorial only) >> >> >> Daniele, >> >> Please see below. I trimmed the text down a bit, let me know if I missed any >> discussion points. >> >> On 6/25/2013 5:59 AM, Daniele Ceccarelli wrote: >>> Hi Lou, >>> >>> All comments addressed. Some comments in line below. >>> >> >> Much thanks: >> >> The following nits will need to be fixed in the next rev (and before going to >> the IESG) >> >> == Missing Reference: 'RFC5226' is mentioned on line 1162, but not defined >> >> == Unused Reference: 'RFC4202' is defined on line 1237, but no explicit >> reference was found in the text >> > done > >> >>> BR >>> Daniele >>> >>>> -----Original Message----- >>>> From: Lou Berger [mailto:lberger@labn.net] >>>> Sent: venerd 14 giugno 2013 22.32 >>>> To: CCAMP; draft-ietf-ccamp-gmpls-ospf-g709v3@tools.ietf.org >>>> Subject: 2nd WG Last Call comments on ospf-g709v3 (editorial only) >>>> >>>> Hi, >>>> The following are comments as part of my LC review of >>>> draft-ietf-ccamp-gmpls-ospf-g709v3-06. Note that I'm the document >>>> shepherd, see RFC 4858 for more information. >>>> >>>> Please see >>>> http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft >>> -ietf-ccamp-gmpls-ospf-g709v3-06.txt >>>> for line numbers used in this message. >> ... >> >>>> Lines 192/3: >>>> "The TE-Link is referred to as OTUk-TE-Link." >>>> This term is used just once in the document. Suggest dropping it. >>>> >>> >>> OK >> still TBD. > I don't know why it was still there. Removed now. > >> >>> >>>> Lines 193/4: >>>> Doesn't the TE link for an OTUk physical Link always provide ODUk >>>> capacity? Either way this text needs to be fixed/clarified. >>> >>> What about dropping all of this text: >>> The TE-Link is >>> 193 referred to as OTUk-TE-Link. The OTUk-TE-Link advertises ODUj >>> 194 switching capacity. The advertised capacity could include ODUk >>> 195 switching capacity. >> sure. >> >> ... > Done > >> >>>> >>>> Lines 210-212,221: >>>> ODUj vs ODUk. Isn't it the case that a multi hop TE link could >>>> represent either ODUj or ODUk resources? This isn't clear from the >>>> current text/usage of ODUj/k. >>>> >>> >>> >>> New text: >>> >>> It is possible to create TE-Links that span more than one hop >>> by creating FA between non-adjacent nodes. >>> As in the one hop case, these types of ODUk-TE-Links also advertise >>> ODU switching capacity. >> >> why not just align with the figure name and use "Multiple hop TE-Link" >> rather than introduce a new otherwise unused term "ODUk-TE-Links"? >> >> ... > Agree. Modified accordingly >> >> Thanks, >> Lou > > > > From lberger@labn.net Thu Jul 4 08:35:45 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AFBD11E812C for ; Thu, 4 Jul 2013 08:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.444 X-Spam-Level: X-Spam-Status: No, score=-101.444 tagged_above=-999 required=5 tests=[AWL=0.821, 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 GhZuy-ApRRP6 for ; Thu, 4 Jul 2013 08:35:40 -0700 (PDT) Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 2366821F9D44 for ; Thu, 4 Jul 2013 08:35:38 -0700 (PDT) Received: (qmail 28803 invoked by uid 0); 4 Jul 2013 15:21:16 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy14.unifiedlayer.com with SMTP; 4 Jul 2013 15:21:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=37stXVaUoRTE6JxVMZh78/VmJXvhMpBnLe5sMKIlNLA=; b=rO4s2YkY0vFTijpQFsHNcFMxfSwXEcxEiXH1mXfR9lVkZzT9nFlVsz/etn/gU4Xm6NtvNnnfFnJt29P3aBDpRVO3N5Q4Ww39mnU5Q9HUEe4nmeBC0hWbCXA5v7WNUgIf; Received: from box313.bluehost.com ([69.89.31.113]:47702 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UulLP-0005kg-Mo for ccamp@ietf.org; Thu, 04 Jul 2013 09:21:16 -0600 Message-ID: <51D592E9.4070103@labn.net> Date: Thu, 04 Jul 2013 11:21:13 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: CCAMP References: <20130703051701.22549.85585.idtracker@ietfa.amsl.com> In-Reply-To: <20130703051701.22549.85585.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 X-Forwarded-Message-Id: <20130703051701.22549.85585.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [CCAMP] Fwd: Draft submission deadlines change X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 15:35:45 -0000 FYI - in case you missed this. Please keep in mind agenda requests are due July 14th and that it's unusual to get presentation time without a draft... Lou -------- Original Message -------- Subject: Draft submission deadlines change Date: Tue, 02 Jul 2013 22:17:01 -0700 From: IETF Chair Reply-To: ietf@ietf.org To: IETF Announcement List Please note that for IETF 87, there is only one deadline for draft submission: Monday 15th July. Previously, there had been two different deadlines, one for -00 and another one for other versions. The IESG has decided to experiment with just one deadline for now to simplify the set of deadlines and enable easier submission of new drafts. While we realise that the change comes near the deadline, we hope that you find the extra time useful. But please do note that working group chairs will continue to make smart decisions about what topics are worthwhile for discussing in a session in the upcoming meeting, and will also set their agendas in a timely manner and create deadlines for their working groups that must be adhered to. The earlier new drafts are submitted, the more time there is to talk about them on the mailing lists and consider them for the session agendas. This is particularly important for BoFs. Jari Arkko for the IESG From lberger@labn.net Thu Jul 4 09:05:23 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDEA621F9D7E for ; Thu, 4 Jul 2013 09:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.561 X-Spam-Level: X-Spam-Status: No, score=-101.561 tagged_above=-999 required=5 tests=[AWL=0.704, 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 TnmX5xdUx+Nf for ; Thu, 4 Jul 2013 09:05:10 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 63EA521F9D18 for ; Thu, 4 Jul 2013 09:05:10 -0700 (PDT) Received: (qmail 14091 invoked by uid 0); 4 Jul 2013 16:04:39 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 4 Jul 2013 16:04:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=kxlMfXlaqdwGtbYrl1KcCpQ9GUuLWEzEzkm+WUN7Ji8=; b=rvpoLOluo7dOgzC11Pr5dHwprPsmKgRh4E+jRML8dqlx9AUrhMC47tuWc16AWmCf3QQyQ6+OPOCvWhJGBadTHiyF+HsviOmM4u+bif5l+U5QlVHY/RSZHlNjMCUjSbnm; Received: from box313.bluehost.com ([69.89.31.113]:54824 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Uum1N-0005ZA-Nc; Thu, 04 Jul 2013 10:04:37 -0600 Message-ID: <51D59D16.7020301@labn.net> Date: Thu, 04 Jul 2013 12:04:38 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Adrian Farrel , The IESG X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: [CCAMP] Please publish draft-ietf-ccamp-gmpls-g709-framework-13 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 16:05:23 -0000 The shepherd writeup can be found at https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-g709-framework/shepherdwriteup/ Thank you! From lberger@labn.net Thu Jul 4 09:05:39 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E374F21F9E60 for ; Thu, 4 Jul 2013 09:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.772 X-Spam-Level: X-Spam-Status: No, score=-101.772 tagged_above=-999 required=5 tests=[AWL=0.493, 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 86qIOMl8oMiX for ; Thu, 4 Jul 2013 09:05:35 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id E0BCF21F9D7E for ; Thu, 4 Jul 2013 09:05:32 -0700 (PDT) Received: (qmail 16011 invoked by uid 0); 4 Jul 2013 16:05:10 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 4 Jul 2013 16:05:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=siLQev4bKCze+Qwe8xxai8hj4WGpSPQxitxY43C9TzY=; b=WVVDbDtKfWbXVMILQDmVaCwCL7YbFFuZd4+fqeS5qc9546A0RCrdbS88evEEHCUmNRZCFvuPEhD243jUdxV6WP2Msw53bg747NPoWsUQgxltWDvEWScB9ExLHnaazM2Z; Received: from box313.bluehost.com ([69.89.31.113]:54901 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Uum1t-0005qV-F0; Thu, 04 Jul 2013 10:05:09 -0600 Message-ID: <51D59D33.5070905@labn.net> Date: Thu, 04 Jul 2013 12:05:07 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Adrian Farrel , The IESG X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: [CCAMP] Please publish draft-ietf-ccamp-otn-g709-info-model-09 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 16:05:40 -0000 The shepherd writeup can be found at https://datatracker.ietf.org/doc/draft-ietf-ccamp-otn-g709-info-model/shepherdwriteup/ Thank you! From lberger@labn.net Thu Jul 4 09:06:03 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC1021F9D7E for ; Thu, 4 Jul 2013 09:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.817 X-Spam-Level: X-Spam-Status: No, score=-101.817 tagged_above=-999 required=5 tests=[AWL=0.448, 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 LZysGOadj2oT for ; Thu, 4 Jul 2013 09:05:59 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 8D15C11E812E for ; Thu, 4 Jul 2013 09:05:53 -0700 (PDT) Received: (qmail 21014 invoked by uid 0); 4 Jul 2013 16:05:29 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy6.bluehost.com with SMTP; 4 Jul 2013 16:05:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=4Q2HZems0sUFd35UYZH3cMV9FFSd0PRLcIc3lq9v4rQ=; b=y83hyldcYqosKdg2rE5k/DBp4AYX5ddJ7Nq7vawJxLZX6pv/3Fp/xi8/A3ejWPOjvq/3MDVPGrhH7tRnYufk8ngzgfvfG5lQxj2/Kdf5RPHB9X9mpz/bTCuROjDvIShI; Received: from box313.bluehost.com ([69.89.31.113]:54977 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Uum2D-00060G-Mv; Thu, 04 Jul 2013 10:05:29 -0600 Message-ID: <51D59D4B.4070602@labn.net> Date: Thu, 04 Jul 2013 12:05:31 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Adrian Farrel , The IESG X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: [CCAMP] Please publish draft-ietf-ccamp-gmpls-ospf-g709v3-08 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 16:06:03 -0000 The shepherd writeup can be found at https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-ospf-g709v3/shepherdwriteup/ Thank you! From lberger@labn.net Thu Jul 4 09:06:14 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E04321F9E3E for ; Thu, 4 Jul 2013 09:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.913 X-Spam-Level: X-Spam-Status: No, score=-101.913 tagged_above=-999 required=5 tests=[AWL=0.352, 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 HzIoKm0Ma7NA for ; Thu, 4 Jul 2013 09:06:10 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 1DD7011E8135 for ; Thu, 4 Jul 2013 09:06:09 -0700 (PDT) Received: (qmail 14724 invoked by uid 0); 4 Jul 2013 16:05:46 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 4 Jul 2013 16:05:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=vcQeYZyCUH15FD2F21ZBsSz9H3DjfjgTXbJQYZcCYb8=; b=cRT+aoE4lWGjc5wCt0nRt4ps4Z5DOL84hCXXDWfjwK8OlIcI2bH9yNOvNDTyaw3O6N9gN/9TSUvyTC2ZrwRPhh5wSShvQYm9JrDf0no48mR5GRpcSvKYbCfqSwTqsIzg; Received: from box313.bluehost.com ([69.89.31.113]:55028 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Uum2T-00065A-C8; Thu, 04 Jul 2013 10:05:46 -0600 Message-ID: <51D59D58.5080800@labn.net> Date: Thu, 04 Jul 2013 12:05:44 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Adrian Farrel , The IESG X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: [CCAMP] Please publish draft-ietf-ccamp-gmpls-signaling-g709v3-11 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 16:06:14 -0000 The shepherd writeup can be found at https://datatracker.ietf.org/doc/draft-ietf-ccamp-gmpls-signaling-g709v3/shepherdwriteup/ Thank you! From zhangfatai@huawei.com Fri Jul 5 00:34:45 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D77A21F9256 for ; Fri, 5 Jul 2013 00:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.554 X-Spam-Level: X-Spam-Status: No, score=0.554 tagged_above=-999 required=5 tests=[AWL=-2.234, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GVUa1eDaaQeY for ; Fri, 5 Jul 2013 00:34:41 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2FA7321F8FA1 for ; Fri, 5 Jul 2013 00:34: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 AUR85682; Fri, 05 Jul 2013 07:34:37 +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; Fri, 5 Jul 2013 08:34:12 +0100 Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 5 Jul 2013 15:34:29 +0800 Received: from SZXEML552-MBS.china.huawei.com ([169.254.2.94]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.007; Fri, 5 Jul 2013 15:34:25 +0800 From: Fatai Zhang To: Lou Berger , CCAMP Thread-Topic: [CCAMP] CAMP Agenda Requests for IETF 87 Thread-Index: AQHOdNfLBzE7M497QkqUXL/JPykpqZlVuY+Q Date: Fri, 5 Jul 2013 07:34:24 +0000 Message-ID: References: <51CEF3D4.3030303@labn.net> In-Reply-To: <51CEF3D4.3030303@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.66.184] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [CCAMP] =?gb2312?b?tPC4tDogIENBTVAgQWdlbmRhIFJlcXVlc3RzIGZvciBJ?= =?gb2312?b?RVRGIDg3?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 07:34:45 -0000 SGkgTG91LA0KDQpDb3VsZCB5b3UgY29uZmlybSBob3cgbWFueSBzZXNzaW9ucyB0aGF0IHdlIGhh dmUgaW4gdGhpcyBtZWV0aW5nPw0KDQpKdXN0IHdhbnQgdG8gZ2V0IHRoZSBjb25maXJtYXRpb24g dG8gZmFjaWxpdGF0ZSBib29raW5nIGZsaWdodC4NCg0KDQpUaGFua3MJDQoNCkZhdGFpDQoNCg0K DQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFtt YWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBMb3UgQmVyZ2VyDQq3osvNyrG85Dog MjAxM8TqNtTCMjnI1SAyMjo0OQ0KytW8/sjLOiBDQ0FNUA0K1vfM4jogW0NDQU1QXSBDQU1QIEFn ZW5kYSBSZXF1ZXN0cyBmb3IgSUVURiA4Nw0KDQpIZWxsbywNCg0KUGVyIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvbWVldGluZy84Ny9hZ2VuZGEuaHRtbA0KQ0NBTVAgaGFzIGJlZW4gKnRl bnRhdGl2ZWx5KiBzY2hlZHVsZWQgZm9yOg0KMTMwMC0xNTAwIENFU1QgCVdlZG5lc2RheSBBZnRl cm5vb24gU2Vzc2lvbiBJDQoxMTIwLTEzMzAgQ0VTVCAJRnJpZGF5IEFmdGVybm9vbiBTZXNzaW9u DQoNClllcywgd2UgYXJlIGN1cnJlbnRseSBzY2hlZHVsZWQgZm9yIGEgRnJpZGF5IGFmdGVybm9v biBtZWV0aW5nIGZvciB0aGUgc2Vjb25kIElFVEYgaW4gYSByb3cuICBHaXZlbiB0aGUgY3VycmVu dCBzZXQgb2YgY29uZmxpY3RzLCBhbmQgdGhhdCB0aGVyZSBhcmUgMTUgQm9Gcywgd2UgYXJlIHVu bGlrZWx5IHRvIHNlZSBhbnkgY2hhbmdlIGluIHRpbWUgc2xvdHMuIFdlIGFyZSBhbHNvIGdldHRp bmcgc29tZSBwcmVzc3VyZSAoZnJvbSBvdXIgQUQpIHRvIG1lZXQgb25seSAxIHNlc3Npb24uDQpP dXIgcGFzdCB3b3JrbG9hZCBjZXJ0YWlubHkgd291bGQgaGF2ZSBwcmVjbHVkZWQgdGhpcy4gQnV0 LCBnaXZlbiB0aGF0IHRoZSA3MDksIE9BTSBhbmQgKGhvcGVmdWxseSkgV1NPTiB0b3BpY3Mgc2hv dWxkIG5vdCBuZWVkIGFueSBtZWV0aW5nIHRpbWUgaW4gQmVybGluLCBhIHNpbmdsZSBzZXNzaW9u IG1heSBiZSBwb3NzaWJsZS4NCg0KS2VlcGluZyB0aGlzIGluIG1pbmQ6DQoNCkF1dGhvcnMgb2Yg YWN0aXZlIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnRzIHNob3VsZCBwbGFuIG9uIHByZXNlbnRpbmcg c3RhdHVzIChicmllZmx5LCBpbmNsdWRpbmcgcmVjZW50IGNoYW5nZXMpLCBvcGVuIGlzc3Vlcy9k aXNjdXNzaW9uIHRvcGljcyBhbmQgcGxhbm5lZCBuZXh0IHN0ZXBzIGF0IHRoZSBtZWV0aW5nLiAg QWx0ZXJuYXRpdmVseSwgYW4gdXBkYXRlIGNhbiBiZSBwcm92aWRlZCB2aWEgZS1tYWlsIHRvIHRo ZSBsaXN0IGluIHRoZSAqd2VlayBwcmlvciogdG8gdGhlIG1lZXRpbmcuDQoNCkFnZW5kYSBSZXF1 ZXN0czoNCi0gVG8gc3VibWl0IGEgcmVxdWVzdCwgcGxlYXNlIHJlcGx5IHRvIHRoaXMgbWVzc2Fn ZSwga2VlcGluZyBhbGwNCiAgaW5kaXZpZHVhbHMgbGlzdGVkLiAgSW5jbHVkZS9leGNsdWRlIGNj YW1wIGFzIHlvdSB3aXNoLg0KLSBQbGVhc2Ugc2VuZCB5b3VyIHJlcXVlc3Qgbm8gbGF0ZXIgdGhh biBTdW5kYXksIEp1bHkgMTQuDQogIEZvciBlYWNoIHNsb3QgcGxlYXNlIHN0YXRlOg0KICArIFBy ZXNlbnRlcg0KICArIERyYWZ0IHRpdGxlIChlLmcuICBUcmFmZmljIEVuZ2luZWVyaW5nIEV4dGVu c2lvbnMgdG8gT1NQRiBmb3INCiAgICBHZW5lcmFsaXplZCBNUExTIChHTVBMUylDb250cm9sIG9m IEV2b2x2aW5nIEcuNzA5IE9UTiBOZXR3b3JrcykNCiAgKyBEcmFmdCBVUkwgb24gdG9vbHMgc2Vy dmVyIChlLmcuIGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LQ0KICAgIGlldGYtY2Nh bXAtZ21wbHMtb3NwZi1nNzA5djMtMDUpDQogICsgRGVzaXJlZCBsZW5ndGggb2YgcHJlc2VudGF0 aW9uDQoNClByZXNlbnRhdGlvbnM6DQogIElmIHlvdSBhcmUgcHJlc2VudGluZyBzbGlkZXMgcGxl YXNlIG1ha2Ugc3VyZSB5b3Ugc2VuZCB0aGVtIHRvDQogIGFsbCAqaW5kaXZpZHVhbHMqIGxpc3Rl ZCBhYm92ZSAoYW5kIGV4Y2x1ZGUgY2NhbXApIG5vIGxhdGVyDQogIHRoYW4gU3VuZGF5LCBKdWx5 IDI4Lg0KDQpSZW1pbmRlciBhYm91dCBhIGZldyBpbXBvcnRhbnQgZGF0ZXM6DQotIDIwMTMtMDct MDggKE1vbmRheSk6IEludGVybmV0IERyYWZ0IEN1dC1vZmYgZm9yIGluaXRpYWwgZG9jdW1lbnQN CiAgICAgICAgICAgICAgICAgICAgICAoLTAwKSBzdWJtaXNzaW9uIGJ5IFVUQyAyNDowMCwNCi0g MjAxMy0wNy0xNSAoTW9uZGF5KTogSW50ZXJuZXQgRHJhZnQgZmluYWwgc3VibWlzc2lvbiBjdXQt b2ZmIGJ5DQogICAgICAgICAgICAgICAgICAgICAgIFVUQyAyNDowMA0KLSAyMDEzLTA3LTE3IChX ZWRuZXNkYXkpOiBEcmFmdCBXb3JraW5nIEdyb3VwIGFnZW5kYXMgZHVlIGJ5IFVUQyAyNDowMA0K LSAyMDEzLTA3LTIyIChNb25kYXkpOiBSZXZpc2VkIFdvcmtpbmcgR3JvdXAgYWdlbmRhcyBkdWUg YnkgVVRDIDI0OjAwDQoNCk11Y2ggdGhhbmtzLA0KTG91IChhbmQgRGVib3JhaCkNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpDQ0FNUCBtYWlsaW5nIGxp c3QNCkNDQU1QQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2NjYW1wDQo= From lberger@labn.net Fri Jul 5 10:32:19 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 107A211E813F for ; Fri, 5 Jul 2013 10:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.119 X-Spam-Level: X-Spam-Status: No, score=-98.119 tagged_above=-999 required=5 tests=[AWL=-3.488, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, IP_NOT_FRIENDLY=0.334, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, SARE_SUB_ENC_GB2312=1.345, 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 DkmfhA6GYz41 for ; Fri, 5 Jul 2013 10:32:14 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 9085011E80F3 for ; Fri, 5 Jul 2013 10:32:10 -0700 (PDT) Received: (qmail 17207 invoked by uid 0); 5 Jul 2013 17:31:48 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 5 Jul 2013 17:31:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=BUXhgBTh4LfwLazvrzGl4Mk039M8NnO04kj4xVuGoXY=; b=dV3Sh0+TcwVMBfDqZpXrythiHBFg9pHKtTgejH1/21PvH03BkEb6vWWIWq3L58oBK4poccIoEPeWz+Dp7u89vHBMe0VSagzfj9UYxlA/sKzltrnTvVMug/uYkcAJisni; Received: from box313.bluehost.com ([69.89.31.113]:46171 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1Uv9rH-0005Nb-R6; Fri, 05 Jul 2013 11:31:47 -0600 Message-ID: <51D70303.90807@labn.net> Date: Fri, 05 Jul 2013 13:31:47 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Fatai Zhang References: <51CEF3D4.3030303@labn.net> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: CCAMP Subject: Re: [CCAMP] =?gb2312?b?tPC4tDogIENBTVAgQWdlbmRhIFJlcXVlc3RzIGZvciBJ?= =?gb2312?b?RVRGIDg3?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 17:32:19 -0000 Fatai, (All) Perhaps in response to our marathon last meeting, there seems to be solid support for not holding a second session on Friday. There are some last minute discussions taking place before everything is finalized, but I think it's safe to plan based on no 2nd session on Friday. Lou On 07/05/2013 03:34 AM, Fatai Zhang wrote: > Hi Lou, > > Could you confirm how many sessions that we have in this meeting? > > Just want to get the confirmation to facilitate booking flight. > > > Thanks > > Fatai > > > > > -----ʼԭ----- > : ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Lou Berger > ʱ: 2013629 22:49 > ռ: CCAMP > : [CCAMP] CAMP Agenda Requests for IETF 87 > > Hello, > > Per https://datatracker.ietf.org/meeting/87/agenda.html > CCAMP has been *tentatively* scheduled for: > 1300-1500 CEST Wednesday Afternoon Session I > 1120-1330 CEST Friday Afternoon Session > > Yes, we are currently scheduled for a Friday afternoon meeting for the second IETF in a row. Given the current set of conflicts, and that there are 15 BoFs, we are unlikely to see any change in time slots. We are also getting some pressure (from our AD) to meet only 1 session. > Our past workload certainly would have precluded this. But, given that the 709, OAM and (hopefully) WSON topics should not need any meeting time in Berlin, a single session may be possible. > > Keeping this in mind: > > Authors of active working group documents should plan on presenting status (briefly, including recent changes), open issues/discussion topics and planned next steps at the meeting. Alternatively, an update can be provided via e-mail to the list in the *week prior* to the meeting. > > Agenda Requests: > - To submit a request, please reply to this message, keeping all > individuals listed. Include/exclude ccamp as you wish. > - Please send your request no later than Sunday, July 14. > For each slot please state: > + Presenter > + Draft title (e.g. Traffic Engineering Extensions to OSPF for > Generalized MPLS (GMPLS)Control of Evolving G.709 OTN Networks) > + Draft URL on tools server (e.g. http://tools.ietf.org/html/draft- > ietf-ccamp-gmpls-ospf-g709v3-05) > + Desired length of presentation > > Presentations: > If you are presenting slides please make sure you send them to > all *individuals* listed above (and exclude ccamp) no later > than Sunday, July 28. > > Reminder about a few important dates: > - 2013-07-08 (Monday): Internet Draft Cut-off for initial document > (-00) submission by UTC 24:00, > - 2013-07-15 (Monday): Internet Draft final submission cut-off by > UTC 24:00 > - 2013-07-17 (Wednesday): Draft Working Group agendas due by UTC 24:00 > - 2013-07-22 (Monday): Revised Working Group agendas due by UTC 24:00 > > Much thanks, > Lou (and Deborah) > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From adrian@olddog.co.uk Fri Jul 5 14:21:59 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9722C21F9EF8 for ; Fri, 5 Jul 2013 14:21:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 1DeSgjuvWFLD for ; Fri, 5 Jul 2013 14:21:53 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id 86C8221F9F02 for ; Fri, 5 Jul 2013 14:21:53 -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 r65LLpGg004108 for ; Fri, 5 Jul 2013 22:21:52 +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 r65LLo3k004099 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 5 Jul 2013 22:21:51 +0100 From: "Adrian Farrel" To: Date: Fri, 5 Jul 2013 22:21:49 +0100 Message-ID: <01b001ce79c5$a9f97820$fdec6860$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac55xagkmIpOWco5QZ+qYU4diU/eNQ== Content-Language: en-gb Subject: [CCAMP] AD review of four OTN/g.709 docs X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 21:21:59 -0000 Hi CCAMP, Thanks for these four documents. I will try to get through them all before Berlin. Timing is, of course, tricky because of other berlin prep, but with a following wind... Adrian From internet-drafts@ietf.org Fri Jul 5 15:03:07 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7778B21F9ECF; Fri, 5 Jul 2013 15:03:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.511 X-Spam-Level: X-Spam-Status: No, score=-102.511 tagged_above=-999 required=5 tests=[AWL=0.089, 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 Ak6X+dxlRtdH; Fri, 5 Jul 2013 15:03:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BA1F21F9E73; Fri, 5 Jul 2013 15:03:07 -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.51.p2 Message-ID: <20130705220306.3110.63113.idtracker@ietfa.amsl.com> Date: Fri, 05 Jul 2013 15:03:06 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signaling-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 22:03:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Signaling Extensions for Wavelength Switched Optical Net= works Author(s) : Greg M. Bernstein Sugang Xu Young Lee Giovanni Martinelli Hiroaki Harai Filename : draft-ietf-ccamp-wson-signaling-06.txt Pages : 17 Date : 2013-07-05 Abstract: This memo provides extensions to Generalized Multi-Protocol Label Switching (GMPLS) signaling for control of wavelength switched optical networks (WSON). Such extensions are necessary in WSONs under a number of conditions including: (a) when optional processing, such as regeneration, must be configured to occur at specific nodes along a path, (b) where equipment must be configured to accept an optical signal with specific attributes, or (c) where equipment must be configured to output an optical signal with specific attributes. In addition this memo provides mechanisms to support distributed wavelength assignment with bidirectional LSPs, and choice in distributed wavelength assignment algorithms. These extensions build on previous work for the control of lambda and G.709 based networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-signaling There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-wson-signaling-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From leeyoung@huawei.com Fri Jul 5 15:11:31 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07A021F9DCD for ; Fri, 5 Jul 2013 15:11:31 -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 D9sh8cRJbKVq for ; Fri, 5 Jul 2013 15:11:25 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 22A0521F9D8F for ; Fri, 5 Jul 2013 15:11:18 -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 AUS40595; Fri, 05 Jul 2013 22:11:16 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 5 Jul 2013 23:11:09 +0100 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 5 Jul 2013 23:11:15 +0100 Received: from dfweml511-mbs.china.huawei.com ([169.254.15.12]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.007; Fri, 5 Jul 2013 15:11:10 -0700 From: Leeyoung To: Lou Berger , "db3546@att.com" Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signaling-06.txt Thread-Index: AQHOecuGrd+FRdH6V0Gpp3H3IS014JlWpIEw Date: Fri, 5 Jul 2013 22:11:09 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172915AAFA@dfweml511-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.47.144.162] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ccamp@ietf.org" Subject: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signaling-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2013 22:11:31 -0000 Hi Lou and Deborah, The uploaded version (06) of WSON signaling draft is mainly editorial natur= e with readability enhancement. This resolved all the comments/pending issu= es as far as Giovanni and I are concerned. This is the last WSON related dr= aft that is ready for WG LC.=20 Let us know if you have any question on this draft.=20 Best Regards, Giovanni and Young -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of i= nternet-drafts@ietf.org Sent: Friday, July 05, 2013 5:03 PM To: i-d-announce@ietf.org Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signaling-06.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Signaling Extensions for Wavelength Switched Optical Net= works Author(s) : Greg M. Bernstein Sugang Xu Young Lee Giovanni Martinelli Hiroaki Harai Filename : draft-ietf-ccamp-wson-signaling-06.txt Pages : 17 Date : 2013-07-05 Abstract: This memo provides extensions to Generalized Multi-Protocol Label Switching (GMPLS) signaling for control of wavelength switched optical networks (WSON). Such extensions are necessary in WSONs under a number of conditions including: (a) when optional processing, such as regeneration, must be configured to occur at specific nodes along a path, (b) where equipment must be configured to accept an optical signal with specific attributes, or (c) where equipment must be configured to output an optical signal with specific attributes. In addition this memo provides mechanisms to support distributed wavelength assignment with bidirectional LSPs, and choice in distributed wavelength assignment algorithms. These extensions build on previous work for the control of lambda and G.709 based networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-signaling There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-wson-signaling-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-wson-signaling-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From adrian@olddog.co.uk Sat Jul 6 15:42:05 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1422021F9D08 for ; Sat, 6 Jul 2013 15:42:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[AWL=-1.010, BAYES_00=-2.599, LOCALPART_IN_SUBJECT=2.02] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KT2CnnFspTIk for ; Sat, 6 Jul 2013 15:41:59 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id EC4A121F9CE2 for ; Sat, 6 Jul 2013 15:41:58 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r66Mfvxk027674; Sat, 6 Jul 2013 23:41:57 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r66MftJJ027667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 6 Jul 2013 23:41:56 +0100 From: "Adrian Farrel" To: Date: Sat, 6 Jul 2013 23:41:55 +0100 Message-ID: <02c101ce7a9a$04c7ac70$0e570550$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac56mV7BgEZX072NQqGt5h3I0qbFZg== Content-Language: en-gb Cc: ccamp@ietf.org Subject: [CCAMP] draft-wright-ccamp-op-policy-prot-links X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jul 2013 22:42:05 -0000 Hi, As I read this I-D, you are saying two things. 1. You want a way to advertise in an IGP that a link is supposed to have some level of inherent protection, but that that protection is not currently present. This is, of course, easy to achieve, but not easy to understand or use. How will the path computing system understand the estimated repair time for the impaired protection? When a path is computed that wants some level of protection, it is possible that "allow impaired protection" is a computation constraint, but it would seem to be nonsense if the repair time is going to be long. Maybe you could add some flesh to the I-D in terms of a deployment example. 2. You want a way to notify the head end of an LSP that there has been a degradation of the LSP, and a way to let it know that things are back to normal. Have you considered: a. running OAM on your LSP b. using RFC 4783 Ciao, Adrian From dhruv.ietf@gmail.com Tue Jul 9 08:54:44 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9D9611E8140 for ; Tue, 9 Jul 2013 08:54:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.086, 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 q2cQzCz3y6m6 for ; Tue, 9 Jul 2013 08:54:39 -0700 (PDT) Received: from mail-ie0-x234.google.com (mail-ie0-x234.google.com [IPv6:2607:f8b0:4001:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id C68F121F9D09 for ; Tue, 9 Jul 2013 08:54:33 -0700 (PDT) Received: by mail-ie0-f180.google.com with SMTP id f4so12820691iea.39 for ; Tue, 09 Jul 2013 08:54:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=UDIWzaBHMeSngdTmkPVFotanzOomFkTHeU8qqXQAfWE=; b=Czvd4NYcQqEJhgxEJwrNQs49WSa7bpwdno+lsNNgXHOzLTM76QOtn1+VCGSs1hKfOf cMlRPspcztfRhr9fWlC5G5y0YUSIsLeHFDT6uvhVwuInKZmv+qJQXZ4XVhWDAUEE6XaW YxSI6c0jJM/69R56oH6tT6V6kegm2YXAA/vMnuxP8fM2CdXVp5P77riFZZppFiTS2Nwq a8SSuoQG+WpVAB+6diyRntm+YGFqiNp58fA28XTtqzmVw9NPLSD+hizTKBtIfqk0R/dG b+GOu13wJCkdoWYzYST8PDzixDKHXMiZaMqiuXwFc7uZ3h2DOof25kTywg5T+oyqzdVV jd1Q== MIME-Version: 1.0 X-Received: by 10.43.141.206 with SMTP id jf14mr9018045icc.8.1373385271756; Tue, 09 Jul 2013 08:54:31 -0700 (PDT) Received: by 10.50.152.176 with HTTP; Tue, 9 Jul 2013 08:54:31 -0700 (PDT) Received: by 10.50.152.176 with HTTP; Tue, 9 Jul 2013 08:54:31 -0700 (PDT) In-Reply-To: <20130709153149.15035.21869.idtracker@ietfa.amsl.com> References: <20130709153149.15035.21869.idtracker@ietfa.amsl.com> Date: Tue, 9 Jul 2013 21:24:31 +0530 Message-ID: From: Dhruv Dhody To: ccamp@ietf.org Content-Type: multipart/alternative; boundary=001a11c2d478434def04e1162d75 Subject: [CCAMP] Fwd: New Version Notification for draft-dhody-ccamp-rsvp-te-domain-subobjects-02.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 15:54:44 -0000 --001a11c2d478434def04e1162d75 Content-Type: text/plain; charset=ISO-8859-1 Hi, Please find an update to the domain subobject draft. Comments, questions and feedback are always welcome. Thanks, Dhruv (on behalf of co-authors) Note - this is a companion document to PCE WG ID draft-ietf-pce-pcep-domain-sequence ---------- Forwarded message ---------- From: Date: 9 Jul 2013 21:01 Subject: New Version Notification for draft-dhody-ccamp-rsvp-te-domain-subobjects-02.txt To: "Dhruv Dhody" , "Dhruv Dhody" < dhruv.dhody@huawei.com>, "Venugopal Reddy Kondreddy" < venugopalreddyk@huawei.com>, "Udayasree Palle" , "Ramon Casellas" Cc: > A new version of I-D, draft-dhody-ccamp-rsvp-te-domain-subobjects-02.txt > has been successfully submitted by Dhruv Dhody and posted to the > IETF repository. > > Filename: draft-dhody-ccamp-rsvp-te-domain-subobjects > Revision: 02 > Title: Domain Subobjects for Resource ReserVation Protocol - > Traffic Engineering (RSVP-TE) > Creation date: 2013-07-09 > Group: Individual Submission > Number of pages: 17 > URL: > http://www.ietf.org/internet-drafts/draft-dhody-ccamp-rsvp-te-domain-subobjects-02.txt > Status: > http://datatracker.ietf.org/doc/draft-dhody-ccamp-rsvp-te-domain-subobjects > Htmlized: > http://tools.ietf.org/html/draft-dhody-ccamp-rsvp-te-domain-subobjects-02 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-dhody-ccamp-rsvp-te-domain-subobjects-02 > > Abstract: > The Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) > specification [RFC3209] and the Generalized Multiprotocol Label > Switching (GMPLS) extensions to RSVP-TE [RFC3473] allow abstract > nodes and resources to be explicitly included in a path setup. > Further Exclude Routes extensions [RFC4874] allow abstract nodes and > resources to be explicitly excluded in a path setup. > > This document specifies new subobjects to include or exclude domains > during path setup where domain is a collection of network elements > within a common sphere of address management or path computational > responsibility (such as an Interior Gateway Protocol (IGP) area or an > Autonomous System (AS)). Note that the use of AS as an abstract node > representing domain is already defined in [RFC3209] and [RFC4874], > albeit with a 2-Byte AS number. > > > > > The IETF Secretariat > > --001a11c2d478434def04e1162d75 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

Please find an update to the domain subobject draft.

Comments, questions and feedback are always welcome.

Thanks,
Dhruv (on behalf of co-authors)

Note - this is a companion document to PCE WG ID=A0 draft-ie= tf-pce-pcep-domain-sequence

---------- Forwarded message ----------
From:= <internet-drafts@ietf.org<= /a>>
Date: 9 Jul 2013 21:01
Subject: New Version Notification for = draft-dhody-ccamp-rsvp-te-domain-subobjects-02.txt
To: "Dhruv Dhody" <dhr= uv.ietf@gmail.com>, "Dhruv Dhody" <dhruv.dhody@huawei.com>, "Venugopal Reddy= Kondreddy" <venugopa= lreddyk@huawei.com>, "Udayasree Palle" <udayasree.palle@huawei.com>, "Ra= mon Casellas" <ramon.case= llas@cttc.es>
Cc:


A new version of I-D, draft-dhody-ccamp-rsvp-te-domain-subobjects-02.txt has been successfully submitted by Dhruv Dhody and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-dhody-ccamp-rsvp-te-domain-subobjects
Revision: =A0 =A0 =A0 =A002
Title: =A0 =A0 =A0 =A0 =A0 Domain Subobjects for Resource ReserVation Proto= col - Traffic Engineering (RSVP-TE)
Creation date: =A0 2013-07-09
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 17
URL: =A0 =A0 =A0 =A0 =A0 =A0 http= ://www.ietf.org/internet-drafts/draft-dhody-ccamp-rsvp-te-domain-subobjects= -02.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracke= r.ietf.org/doc/draft-dhody-ccamp-rsvp-te-domain-subobjects
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org= /html/draft-dhody-ccamp-rsvp-te-domain-subobjects-02
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://ww= w.ietf.org/rfcdiff?url2=3Ddraft-dhody-ccamp-rsvp-te-domain-subobjects-02

Abstract:
=A0 =A0The Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) =A0 =A0specification [RFC3209] and the Generalized Multiprotocol Label
=A0 =A0Switching (GMPLS) extensions to RSVP-TE [RFC3473] allow abstract
=A0 =A0nodes and resources to be explicitly included in a path setup.
=A0 =A0Further Exclude Routes extensions [RFC4874] allow abstract nodes and=
=A0 =A0resources to be explicitly excluded in a path setup.

=A0 =A0This document specifies new subobjects to include or exclude domains=
=A0 =A0during path setup where domain is a collection of network elements =A0 =A0within a common sphere of address management or path computational =A0 =A0responsibility (such as an Interior Gateway Protocol (IGP) area or a= n
=A0 =A0Autonomous System (AS)). =A0Note that the use of AS as an abstract n= ode
=A0 =A0representing domain is already defined in [RFC3209] and [RFC4874], =A0 =A0albeit with a 2-Byte AS number.




The IETF Secretariat

--001a11c2d478434def04e1162d75-- From Ben.Wright@metaswitch.com Wed Jul 10 01:18:45 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD3121F9F89 for ; Wed, 10 Jul 2013 01:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8FaPfmVHFR7 for ; Wed, 10 Jul 2013 01:18:39 -0700 (PDT) Received: from ENFICSETS1.metaswitch.com (enficsets1.metaswitch.com [192.91.191.38]) by ietfa.amsl.com (Postfix) with ESMTP id 142F621F9F5E for ; Wed, 10 Jul 2013 01:18:39 -0700 (PDT) Received: from ENFIRHMBX1.datcon.co.uk (172.18.74.36) by ENFICSETS1.metaswitch.com (172.18.4.18) with Microsoft SMTP Server (TLS) id 14.2.342.3; Wed, 10 Jul 2013 09:18:02 +0100 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFIRHMBX1.datcon.co.uk ([fe80::b06d:4d13:5f63:3715%19]) with mapi id 14.02.0342.003; Wed, 10 Jul 2013 09:18:08 +0100 From: Ben Wright To: "adrian@olddog.co.uk" , "draft-wright-ccamp-op-policy-prot-links@tools.ietf.org" Thread-Topic: [CCAMP] draft-wright-ccamp-op-policy-prot-links Thread-Index: Ac56mV7BgEZX072NQqGt5h3I0qbFZgCRmqqA Date: Wed, 10 Jul 2013 08:18:07 +0000 Message-ID: References: <02c101ce7a9a$04c7ac70$0e570550$@olddog.co.uk> In-Reply-To: <02c101ce7a9a$04c7ac70$0e570550$@olddog.co.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.34.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] draft-wright-ccamp-op-policy-prot-links X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 08:18:45 -0000 Hi Adrian,=20 Thanks for your input.=20 On point 1, this is likely to be controlled by carrier policy. There are a= couple of use cases for this.=20 - Some carriers have policies which mean they are prepared to let some serv= ices traverse a link which is temporarily protection-impaired, with the ass= umption that the link will be repaired at some point. =20 - Carrier policy can choose to place some services (for which no protection= is required) over a protection-impaired link but avoid using that link for= other less-valuable services. This prevents less valuable services using = resources on links which, if repaired, could be used to carry protected tra= ffic. =20 Are these the sort of deployment example you were thinking of? I can add t= hese details to the I-D if that helps?=20 On point 2, thanks for pointing me at RFC4783. I think that solves the iss= ue - the node detecting a failure could use error value protectionPathFailu= re (60) to signal the fault and clear that when the fault condition clears.= You are correct that we could also run end-to-end OAM on the LSP, but tha= t was not necessarily going to be available for some of the cases I was con= sidering. =20 Cheers,=20 Ben -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of A= drian Farrel Sent: 06 July 2013 23:42 To: draft-wright-ccamp-op-policy-prot-links@tools.ietf.org Cc: ccamp@ietf.org Subject: [CCAMP] draft-wright-ccamp-op-policy-prot-links Hi, As I read this I-D, you are saying two things. 1. You want a way to advertise in an IGP that a link is supposed to have so= me level of inherent protection, but that that protection is not currently = present. This is, of course, easy to achieve, but not easy to understand or use. How= will the path computing system understand the estimated repair time for th= e impaired protection? When a path is computed that wants some level of pro= tection, it is possible that "allow impaired protection" is a computation c= onstraint, but it would seem to be nonsense if the repair time is going to = be long. Maybe you could add some flesh to the I-D in terms of a deployment example. 2. You want a way to notify the head end of an LSP that there has been a de= gradation of the LSP, and a way to let it know that things are back to norm= al. Have you considered: a. running OAM on your LSP b. using RFC 4783 Ciao, Adrian _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From julien.meuric@orange.com Wed Jul 10 08:40:57 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799EA21F9D4E for ; Wed, 10 Jul 2013 08:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.89 X-Spam-Level: X-Spam-Status: No, score=-5.89 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZTeIqV1IZ11X for ; Wed, 10 Jul 2013 08:40:52 -0700 (PDT) Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [195.101.245.15]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4C421F944F for ; Wed, 10 Jul 2013 08:40:52 -0700 (PDT) Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DA0794103E9 for ; Wed, 10 Jul 2013 17:40:50 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.orange.com (Postfix) with ESMTP id D504A4103E5 for ; Wed, 10 Jul 2013 17:40:50 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Jul 2013 17:40:50 +0200 Received: from [10.193.71.100] ([10.193.71.100]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 10 Jul 2013 17:40:50 +0200 Message-ID: <51DD8081.4040306@orange.com> Date: Wed, 10 Jul 2013 17:40:49 +0200 From: Julien Meuric Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: ccamp@ietf.org References: <02c101ce7a9a$04c7ac70$0e570550$@olddog.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2013 15:40:50.0993 (UTC) FILETIME=[DB127210:01CE7D83] Subject: Re: [CCAMP] draft-wright-ccamp-op-policy-prot-links X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 15:40:57 -0000 Hi Ben. Please see below. On 07/10/2013 10:18, Ben Wright wrote: [...] > - Some carriers have policies which mean they are prepared to let some services traverse a link which is temporarily protection-impaired, with the assumption that the link will be repaired at some point. I agree 100 %. The key-word here is *temporarily*. On the opposite TE-LSPs are typically provisioned for rather long times. As a result, I do not believe that adding a supplementary short-life link-protection state (i.e. "protection-impaired") would bring actual value to initial path computation. It is a matter of time scale. When it comes to traffic re-routing triggered by a failure, traffic recovery matters above all and an available link should typically be considered, whatever transient state a protected link may be facing. > > - Carrier policy can choose to place some services (for which no protection is required) over a protection-impaired link but avoid using that link for other less-valuable services. This prevents less valuable services using resources on links which, if repaired, could be used to carry protected traffic. I guess you meant "for which protection is required". The situation is not supposed to last for long. Should provisioning happen over a degraded network anyway and chose that link, constrained routing remains a proactive way to addresses the issue, re-routing (only once!) is a reactive one. I have also read the I-D and especially the "operator requirements" section: - R1 brings me back to my comment above: I do not feel comfortable in constraining path computation by temporary situations that do no affect traffic. - R2 looks really odd to me: except for planed maintenance, I fail to see why someone would want to temporarily re-route a perfectly flowing traffic, which means accept the traffic impact (twice, even if sub-50 ms...) and the risk that the new path is not better than the former. What prevails on operational networks is typically: "do no touch something working properly". Regards, Julien From huubatwork@gmail.com Fri Jul 12 01:22:11 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4429021F9E0D for ; Fri, 12 Jul 2013 01:22: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 6PMW5E1uTVQi for ; Fri, 12 Jul 2013 01:22:10 -0700 (PDT) Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 7458121F9F71 for ; Fri, 12 Jul 2013 01:22:07 -0700 (PDT) Received: by mail-ea0-f176.google.com with SMTP id z15so6191720ead.35 for ; Fri, 12 Jul 2013 01:22:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:subject:references:in-reply-to :x-forwarded-message-id:content-type:content-transfer-encoding; bh=Z34LJyNJLxn3atAzxd7dHFsH1LqBFX9lexIZ5i8XMLE=; b=GtbY+BwcK86dNh+rYiCfvlm+x3f4Nu9ga8xX7U4rH6vzUN9z50VkFM65vtUcGFw/jj w9kr5b+KeHFbjpglEvLJ7WI2ZPnmZrhsVNvmJoqGTShCD4godViuuFDr5MdNv97u7uG2 +0p6bL2P76YfE5uK7YFaNA1wVpxothkfzcCsWiikahW9Ynrkni5HMgJ1NunsxGqchVJT V6xr4Ez7J1CgVPSfWbIRJv6nT8h65GOdqmDNOFLfE3trspmQVLmTPhV/cW86s/MJx+5/ nzxOLMRCKnYLVMI6oWojAlV00IzhAj6vbxlhHO+RMcK4S/sx4YLrOMwFhXOApMB+NhQe zxsw== X-Received: by 10.15.99.2 with SMTP id bk2mr45977359eeb.76.1373617326582; Fri, 12 Jul 2013 01:22:06 -0700 (PDT) Received: from McAsterix.local ([156.106.232.227]) by mx.google.com with ESMTPSA id e44sm76275710eeh.11.2013.07.12.01.22.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Jul 2013 01:22:06 -0700 (PDT) Message-ID: <51DFBCAE.1090904@gmail.com> Date: Fri, 12 Jul 2013 10:22:06 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: CCAMP References: <20130712080139.11065.23579.idtracker@ietfa.amsl.com> In-Reply-To: <20130712080139.11065.23579.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130712080139.11065.23579.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [CCAMP] Fwd: I-D Action: draft-helvoort-ccamp-fs-priority-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 08:22:11 -0000 Hello CCAMP, Based on the messages on the MPLS list: http://www.ietf.org/mail-archive/web/mpls/current/msg09913.html http://www.ietf.org/mail-archive/web/mpls/current/msg09916.html I have created and uploaded the draft below. Comments are appreciated. Best regards, Huub. -------- Original Message -------- Subject: I-D Action: draft-helvoort-ccamp-fs-priority-00.txt Date: Fri, 12 Jul 2013 01:01:39 -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 : Update Forced Switch Priority Author(s) : Huub van Helvoort Filename : draft-helvoort-ccamp-fs-priority-00.txt Pages : 4 Date : 2013-07-12 Abstract: This document clarifies the definitions related to Manual Switch and Forced Switch. This document updates RFC 4427. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-helvoort-ccamp-fs-priority There's also a htmlized version available at: http://tools.ietf.org/html/draft-helvoort-ccamp-fs-priority-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From julien.meuric@orange.com Fri Jul 12 01:28:21 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41A1421F9D34 for ; Fri, 12 Jul 2013 01:28:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.099 X-Spam-Level: X-Spam-Status: No, score=-6.099 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hE+eQkg-zW04 for ; Fri, 12 Jul 2013 01:28:14 -0700 (PDT) Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by ietfa.amsl.com (Postfix) with ESMTP id AAC3321F9D4C for ; Fri, 12 Jul 2013 01:28:09 -0700 (PDT) Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C20DCA440E1; Fri, 12 Jul 2013 10:29:51 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.orange.com (Postfix) with ESMTP id B7C58A440DE; Fri, 12 Jul 2013 10:29:51 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 12 Jul 2013 10:28:07 +0200 Received: from [10.193.71.100] ([10.193.71.100]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 12 Jul 2013 10:28:07 +0200 Message-ID: <51DFBE16.1060005@orange.com> Date: Fri, 12 Jul 2013 10:28:06 +0200 From: Julien Meuric Organization: Orange User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Oscar_Gonz=E1lez_de_Dios?= References: <7CFF94B047D8864CB6268315034E35DE2F5F34CD@EX10-MB2-MAD.hi.inet> In-Reply-To: <7CFF94B047D8864CB6268315034E35DE2F5F34CD@EX10-MB2-MAD.hi.inet> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 12 Jul 2013 08:28:07.0258 (UTC) FILETIME=[BC4E63A0:01CE7ED9] Cc: CCAMP Subject: Re: [CCAMP] Question about partial SRLG collection flags X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 08:28:22 -0000 Hi Oscar. For the encoding, I do not have yet a strong opinion about a generic filed vs. a per sub-object, but I feel that you will not avoid a dedicated I-D to enable a generic discussion about the mechanism at large. Progressing this discussion would help defining: 1- if a generic mechanism is interesting, 2- if per sub-object encoding is the way to go (assuming that a sub-network would actually update those flags, I agree that one must remain capable of associating the information to the corresponding sub-objects). The answer to the latter would allow to know the impact on the SRLG collection I-D. My 2 cents, Julien Le 04/07/2013 11:23, Oscar Gonzlez de Dios a crit : > Dear CCAMP WG chairs and CCAMPrs, > > In the last IETF meeting we presented RSVP-TE Extensions for > Collecting SRLG Information > ( draft-ietf-ccamp-rsvp-te-srlg-collect-02). This draft is about > collecting SRLG information in the RRO. We included a couple of flags > in the new SRLG sub-object, one to indicate if the SRLG-list contained > in the RRO sub-object has been edited in some way by a node > during signaling in accordance with that node's policy ,and another > one to indicate if the hat the SRLG-list contained in this RRO > sub-object is known to be incomplete. > After presenting , Lou mentioned that he partial SRLG-list > flags needs to be separated into an individual draft if it is a > generic function. We have been discussing this point and have some > doubts that we would like to share with the WG. First, the edited > flag/partial flag could potentially apply to any collected sub-object, > and thus can be considered generic. There are at least two drafts now > (the SRLG collection and the TE metric recording) where this > functionality is useful. However, if we want to make the flags > generic, there are several issues: the RRO subjects are TLVs, and > each subobject is defined independently. Thus, there is no common RRO > sub object header where the generic flags could fit. Another potential > problem is that all RRO TLVs defined so far have an 8-bit flags field; > if we want to go for something consistent, this will probably have to > expand at some point. In addition, there isn't a consistent place for > the flags to go (e.g. the IPv4/6 address objects put them at the end > of the TLV, whereas the others have them towards the beginning. > > We would like to know your opinion on the matter, so we can take > the decision of keeping the flags in the SRLG collection draft, and > that if other drafts use the same flags they define them again for > their RRO sub objects, or going for a draft to define this flags, but > here we have the mentioned doubts on the approach. > > Best Regards, > > Oscar on behalf of draft-ietf-ccamp-rsvp-te-srlg-collect authors. > > > > ------------------------------------------------------------------------ > > Este mensaje se dirige exclusivamente a su destinatario. Puede > consultar nuestra poltica de envo y recepcin de correo electrnico > en el enlace situado ms abajo. > This message is intended exclusively for its addressee. We only send > and receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From Ben.Wright@metaswitch.com Fri Jul 12 01:28:38 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91CDD21F9D3B for ; Fri, 12 Jul 2013 01:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6EjyEebhSXne for ; Fri, 12 Jul 2013 01:28:33 -0700 (PDT) Received: from ENFIRHETS1.metaswitch.com (enfirhets1.metaswitch.com [192.91.191.166]) by ietfa.amsl.com (Postfix) with ESMTP id 837D221F9D49 for ; Fri, 12 Jul 2013 01:28:31 -0700 (PDT) Received: from ENFICSCAS1.datcon.co.uk (172.18.4.13) by ENFIRHETS1.metaswitch.com (172.18.209.22) with Microsoft SMTP Server (TLS) id 14.2.342.3; Fri, 12 Jul 2013 09:28:11 +0100 Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFICSCAS1.datcon.co.uk ([::1]) with mapi id 14.02.0342.003; Fri, 12 Jul 2013 09:28:30 +0100 From: Ben Wright To: Julien Meuric , "ccamp@ietf.org" Thread-Topic: [CCAMP] draft-wright-ccamp-op-policy-prot-links Thread-Index: Ac56mV7BgEZX072NQqGt5h3I0qbFZgCRmqqAACbrrYAAV3oEEA== Date: Fri, 12 Jul 2013 08:28:29 +0000 Message-ID: References: <02c101ce7a9a$04c7ac70$0e570550$@olddog.co.uk> <51DD8081.4040306@orange.com> In-Reply-To: <51DD8081.4040306@orange.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.72.107] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Verizon - Vishnu Shukla , =?iso-2022-jp?B?GyRCTXs9U1s/GyhCKEp1bmppZSBMaSk=?= , "draft-wright-ccamp-op-policy-prot-links@tools.ietf.org" Subject: Re: [CCAMP] draft-wright-ccamp-op-policy-prot-links X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 08:28:38 -0000 Hi Julien, Thanks for your comments. Your point of view is, of course, completely val= id. Let me try to rephrase the use case for R1. I've received input from some = carriers who see a need for a policy which means that they are *not* prepar= ed to let certain services traverse a protection-impaired link, no matter h= ow temporary the impairment is likely to be. Path computation would theref= ore need to take the impairment status of each link into account for those = services only. On R2, the required policy is that there are certain services that must not= be at risk from being taken out by a second failure on a protection-impair= ed link, even though that means re-routing the traffic when a failure occur= s. You are correct that traffic would not normally be re-routed from a wor= king connection, but my understanding is that these services are very much = a special case. I'm interested in whether these requirements are of wider interest, so than= ks for your feedback. Regards, Ben -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of J= ulien Meuric Sent: 10 July 2013 16:41 To: ccamp@ietf.org Subject: Re: [CCAMP] draft-wright-ccamp-op-policy-prot-links Hi Ben. Please see below. On 07/10/2013 10:18, Ben Wright wrote: [...] > - Some carriers have policies which mean they are prepared to let some se= rvices traverse a link which is temporarily protection-impaired, with the a= ssumption that the link will be repaired at some point. I agree 100 %. The key-word here is *temporarily*. On the opposite TE-LSPs = are typically provisioned for rather long times. As a result, I do not beli= eve that adding a supplementary short-life link-protection state (i.e. "pro= tection-impaired") would bring actual value to initial path computation. It= is a matter of time scale. When it comes to traffic re-routing triggered by a failure, traffic recover= y matters above all and an available link should typically be considered, w= hatever transient state a protected link may be facing. > =20 > - Carrier policy can choose to place some services (for which no protecti= on is required) over a protection-impaired link but avoid using that link f= or other less-valuable services. This prevents less valuable services usin= g resources on links which, if repaired, could be used to carry protected t= raffic. I guess you meant "for which protection is required". The situation is not = supposed to last for long. Should provisioning happen over a degraded netwo= rk anyway and chose that link, constrained routing remains a proactive way = to addresses the issue, re-routing (only once!) is a reactive one. I have also read the I-D and especially the "operator requirements" section= : - R1 brings me back to my comment above: I do not feel comfortable in const= raining path computation by temporary situations that do no affect traffic. - R2 looks really odd to me: except for planed maintenance, I fail to see w= hy someone would want to temporarily re-route a perfectly flowing traffic, = which means accept the traffic impact (twice, even if sub-50 ms...) and the risk that the new path is not better than the former.=20 What prevails on operational networks is typically: "do no touch something = working properly". Regards, Julien _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From internet-drafts@ietf.org Sat Jul 13 22:44:03 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E968311E80E3; Sat, 13 Jul 2013 22:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b20SrS9r5yUm; Sat, 13 Jul 2013 22:44:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E4811E80E0; Sat, 13 Jul 2013 22:44:03 -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.51.p2 Message-ID: <20130714054403.10946.40747.idtracker@ietfa.amsl.com> Date: Sat, 13 Jul 2013 22:44:03 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-te-metric-recording-02.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 05:44:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Resource ReserVation Protocol-Traffic Engineering (RSVP-= TE) extension for recording TE Metric of a Label Switched Path Author(s) : Zafar Ali George Swallow Clarence Filsfils Matt Hartley Kenji Kumaki Deutsche Telekom AG Filename : draft-ietf-ccamp-te-metric-recording-02.txt Pages : 12 Date : 2013-07-13 Abstract: There are many scenarios in which Traffic Engineering (TE) metrics such as cost, latency and latency variation associated with a Forwarding Adjacency (FA) or Routing Adjacency (RA) Label Switched Path (LSP) are not available to the ingress and egress nodes. This draft provides extensions for the Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) for the support of the discovery of cost, latency and latency variation of an LSP. = The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-te-metric-recording There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-te-metric-recording-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-te-metric-recording-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From amy.yemin@huawei.com Sun Jul 14 23:28:51 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0F421F9A0A for ; Sun, 14 Jul 2013 23:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_22=0.6, 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 71ngjTXsjp2L for ; Sun, 14 Jul 2013 23:28:47 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 84D4621F8449 for ; Sun, 14 Jul 2013 23:28:46 -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 ATL11059; Mon, 15 Jul 2013 06:28:39 +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; Mon, 15 Jul 2013 07:28:05 +0100 Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 15 Jul 2013 07:28:36 +0100 Received: from SZXEML548-MBX.china.huawei.com ([169.254.7.73]) by szxeml423-hub.china.huawei.com ([10.82.67.162]) with mapi id 14.01.0323.007; Mon, 15 Jul 2013 14:28:28 +0800 From: "Yemin (Amy)" To: "ccamp@ietf.org" Thread-Topic: New Version Notification for draft-long-ccamp-rsvp-te-bandwidth-availability-01.txt Thread-Index: AQHOfnblnT+Ib21/aE2rp9/RMxVp45llI1sA Date: Mon, 15 Jul 2013 06:28:27 +0000 Message-ID: <9C5FD3EFA72E1740A3D41BADDE0B461F6428C346@szxeml548-mbx.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.169.33.63] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Longhao Subject: [CCAMP] FWD: New Version Notification for draft-long-ccamp-rsvp-te-bandwidth-availability-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 06:28:51 -0000 RGVhciBDQ0FNUGVycywNCg0KVGhlIHVwZGF0ZWQgZHJhZnQgZGVzY3JpYmVzIGEgUlNWUC1URSBl eHRlbnNpb24gZm9yIGxpbmtzIHdpdGggdmFyaWFibGUgZGlzY3JldGUgYmFuZHdpZHRoLiBUd28g YWRkaXRpb25hbCBhdXRob3JzIGFyZSBhZGRlZCBpbiB0aGlzIHZlcnNpb24uDQoNCkEgcmVsYXRl ZCBJRCBpcyBPU1BGIFJvdXRpbmcgRXh0ZW5zaW9uIGZvciBsaW5rcyB3aXRoIHZhcmlhYmxlIGRp c2NyZXRlIGJhbmR3aWR0aCggaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh ZnQtbG9uZy1jY2FtcC1vc3BmLWF2YWlsYWJpbGl0eS1leHRlbnNpb24tMDAudHh0KSwgd2hpY2gg ZGVzY3JpYmVzIHRoZSByb3V0aW5nIGV4dGVuc2lvbi4NCg0KV2UgY291bGQgbGlrZSB0byBnZXQg eW91ciBmZWVkYmFjayBvbiB0aGVzZSBkcmFmdHMuDQoNClRoYW5rcyBhbmQgDQpCUiwNCk1pbiBZ ZShvbiBiZWhhbGYgb2YgY28tYXV0aG9ycykNCg0KDQotLS0tLemCruS7tuWOn+S7ti0tLS0tDQrl j5Hku7bkuro6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZ10gDQrlj5HpgIHml7bpl7Q6IDIwMTPlubQ35pyIMTLml6UgNDo0MA0K5pS25Lu2 5Lq6OiBHcmVnIE1pcnNreTsgWWVtaW4gKEFteSk7IEFsZXNzYW5kcm8gRCdBbGVzc2FuZHJvOyBM b25naGFvDQrkuLvpopg6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbG9uZy1j Y2FtcC1yc3ZwLXRlLWJhbmR3aWR0aC1hdmFpbGFiaWxpdHktMDEudHh0DQoNCg0KQSBuZXcgdmVy c2lvbiBvZiBJLUQsIGRyYWZ0LWxvbmctY2NhbXAtcnN2cC10ZS1iYW5kd2lkdGgtYXZhaWxhYmls aXR5LTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBNaW4gWWUgYW5k IHBvc3RlZCB0byB0aGUNCklFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFmdC1sb25n LWNjYW1wLXJzdnAtdGUtYmFuZHdpZHRoLWF2YWlsYWJpbGl0eQ0KUmV2aXNpb246CSAwMQ0KVGl0 bGU6CQkgUlNWUC1URSBTaWduYWxpbmcgRXh0ZW5zaW9uIGZvciBCYW5kd2lkdGggYXZhaWxhYmls aXR5DQpDcmVhdGlvbiBkYXRlOgkgMjAxMy0wNy0xMQ0KR3JvdXA6CQkgSW5kaXZpZHVhbCBTdWJt aXNzaW9uDQpOdW1iZXIgb2YgcGFnZXM6IDkNClVSTDogICAgICAgICAgICAgaHR0cDovL3d3dy5p ZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbG9uZy1jY2FtcC1yc3ZwLXRlLWJhbmR3aWR0 aC1hdmFpbGFiaWxpdHktMDEudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtbG9uZy1jY2FtcC1yc3ZwLXRlLWJhbmR3aWR0aC1hdmFpbGFi aWxpdHkNCkh0bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt bG9uZy1jY2FtcC1yc3ZwLXRlLWJhbmR3aWR0aC1hdmFpbGFiaWxpdHktMDENCkRpZmY6ICAgICAg ICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtbG9uZy1jY2FtcC1y c3ZwLXRlLWJhbmR3aWR0aC1hdmFpbGFiaWxpdHktMDENCg0KQWJzdHJhY3Q6DQogICBQYWNrZXQg c3dpdGNoaW5nIG5ldHdvcmsgdXN1YWxseSBjb250YWlucyBsaW5rcyB3aXRoIHZhcmlhYmxlDQog ICBiYW5kd2lkdGgsIGUuZy4sIGNvcHBlciwgcmFkaW8sIGV0Yy4gVGhlIGJhbmR3aWR0aCBvZiBz dWNoIGxpbmsgaXMNCiAgIHNlbnNpdGl2ZSB0byBleHRlcm5hbCBlbnZpcm9ubWVudC4gQXZhaWxh YmlsaXR5IGlzIHR5cGljYWxseSB1c2VkDQogICBmb3IgZGVzY3JpYmluZyB0aGUgbGluayBkdXJp bmcgbmV0d29yayBwbGFubmluZy4gVGhpcyBkb2N1bWVudA0KICAgZGVzY3JpYmVzIGFuIGV4dGVu c2lvbiBmb3IgUlNWUC1URSBzaWduYWxpbmcgZm9yIHNldHRpbmcgdXAgYSBsYWJlbA0KICAgc3dp dGNoaW5nIHBhdGggKExTUCkgaW4gYSBQYWNrZXQgU3dpdGNoZWQgTmV0d29yayAoUFNOKSBuZXR3 b3JrDQogICB3aGljaCBjb250YWlucyB2YXJpYWJsZSBiYW5kd2lkdGggbGluayBieSBpbnRyb2R1 Y2luZyBhbiBvcHRpb25hbA0KICAgYXZhaWxhYmlsaXR5IGZpZWxkIGluIFJTVlAtVEUgc2lnbmFs aW5nLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0YXJp YXQNCg0K From internet-drafts@ietf.org Mon Jul 15 03:59:43 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23DC611E80E8; Mon, 15 Jul 2013 03:59:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.533 X-Spam-Level: X-Spam-Status: No, score=-102.533 tagged_above=-999 required=5 tests=[AWL=0.067, 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 pCDDWJOfYEks; Mon, 15 Jul 2013 03:59:42 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A755E11E80DC; Mon, 15 Jul 2013 03:59:42 -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.51.p2 Message-ID: <20130715105942.22551.44997.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 03:59:42 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-lsp-diversity-02.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 10:59:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Resource ReserVation Protocol-Traffic Engineering (RSVP-= TE) Path Diversity using Exclude Routes Author(s) : Zafar Ali George Swallow Clarence Filsfils Matt Hartley Ori Gerstel Gabriele Maria Galimberti Kenji Kumaki Deutsche Telekom AG Julien Meuric Filename : draft-ietf-ccamp-lsp-diversity-02.txt Pages : 16 Date : 2013-07-15 Abstract: RFC 4874 specifies methods by which route exclusions may be communicated during RSVP-TE signaling in networks where precise explicit paths are not computed by the LSP source node. This document specifies signaling for additional route exclusions based on Paths currently existing or expected to exist within the network. = The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-diversity There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-lsp-diversity-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-lsp-diversity-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Jul 15 05:52:10 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1427C21F8947; Mon, 15 Jul 2013 05:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.064, 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 cx+yPVu-tYsB; Mon, 15 Jul 2013 05:52:09 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9351721F880F; Mon, 15 Jul 2013 05:52:09 -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.51.p2 Message-ID: <20130715125209.10054.79019.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2013 05:52:09 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-lsp-attribute-ro-02.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 12:52:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : LSP Attribute in ERO Author(s) : Cyril Margaria Giovanni Martinelli Steve Balls Ben Wright Filename : draft-ietf-ccamp-lsp-attribute-ro-02.txt Pages : 9 Date : 2013-07-15 Abstract: LSP attributes can be specified or recorded for whole path, but they cannot be targeted to a specific hop. This document proposes alternative ways to extend the semantic for RSVP ERO object to target LSP attributes to a specific hop. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-lsp-attribute-ro There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-lsp-attribute-ro-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-lsp-attribute-ro-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ietf-ipr@ietf.org Wed Jul 17 11:11:04 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 467A621E8085; Wed, 17 Jul 2013 11:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.435 X-Spam-Level: X-Spam-Status: No, score=-102.435 tagged_above=-999 required=5 tests=[AWL=0.165, 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 KPjrZ4o463Lg; Wed, 17 Jul 2013 11:11:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CD6521E8087; Wed, 17 Jul 2013 11:10:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: IETF Secretariat To: zhang.fei3@zte.com.cn, jingrq@ctbri.com.cn, rgandhi@cisco.com X-Test-IDTracker: no X-IETF-IDTracker: 4.53 Message-ID: <20130717181050.26668.66010.idtracker@ietfa.amsl.com> Date: Wed, 17 Jul 2013 11:10:50 -0700 Cc: ccamp@ietf.org, dbrungard@att.com, ipr-announce@ietf.org Subject: [CCAMP] IPR Disclosure: Cisco's Statement of IPR Related to draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-06 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 18:11:04 -0000 Dear Fei Zhang, Ruiquan Jing, Rakesh Gandhi: An IPR disclosure that pertains to your Internet-Draft entitled "RSVP-TE Extensions for Associated Bidirectional LSPs" (draft-ietf-ccamp-mpls-tp-rsv= pte- ext-associated-lsp) was submitted to the IETF Secretariat on 2013-07-16 and= has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/2139/). The title of the IPR disclosure is "Cisco's Statement of IPR Related to draft-ietf-ccamp-mpls-tp-rsvpte-ext- associated-lsp-06.""); The IETF Secretariat From lberger@labn.net Wed Jul 17 11:56:06 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9112821F9FE4 for ; Wed, 17 Jul 2013 11:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.141 X-Spam-Level: X-Spam-Status: No, score=-101.141 tagged_above=-999 required=5 tests=[AWL=-0.031, BAYES_05=-1.11, 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 aCpxobg7-ptY for ; Wed, 17 Jul 2013 11:55:59 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id 5906D21F8C40 for ; Wed, 17 Jul 2013 11:55:58 -0700 (PDT) Received: (qmail 4131 invoked by uid 0); 17 Jul 2013 18:55:30 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.bluehost.com with SMTP; 17 Jul 2013 18:55:30 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=llxoVwdfoHwN5hyUSGOYS1zIrD6Iyf958fBCJY+PeKA=; b=hMTVibKflThBpSxS4p2il96BbsCvdBLr4D6iiBM8ASwXixG6K2Ih78mqCKsOuURw5M8S8ayf8+HsvgV+amneZbFzvdXgvBbZWD2bdegS006MDSOcAOb8Ufd+rc8TWBRl; Received: from box313.bluehost.com ([69.89.31.113]:44841 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UzWsr-0002Ir-UG for ccamp@ietf.org; Wed, 17 Jul 2013 12:55:30 -0600 Message-ID: <51E6E8A1.4030905@labn.net> Date: Wed, 17 Jul 2013 14:55:29 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: CCAMP X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [CCAMP] IETF 87 Draft Agenda Posted X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 18:56:06 -0000 All, The draft agenda for Orlando is available at: http://www.ietf.org/proceedings/87/agenda/agenda-87-ccamp Unfortunately our hope for meeting just once this time will not be realized. Please let us (Daniele & Dan + chairs) know if you have comments or if we missed anything. We already have one wait listed draft, just in case someone wishes to give up their time;-) Authors of WG documents, As usual: If presenting, please plan to review (present) any changes that have been recently made, any open discussions or issues, as well as planned next steps. If you are not presenting, please send this information to the WG mail list *1 week* prior to the WG meeting. Much thanks, Lou (Deborah, Daniele & Dan) From giomarti@cisco.com Wed Jul 17 14:04:07 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA2CD21F9A8E for ; Wed, 17 Jul 2013 14:04:07 -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 gJO8WWcv9o75 for ; Wed, 17 Jul 2013 14:04:02 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id DA48821F8456 for ; Wed, 17 Jul 2013 14:04:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1065; q=dns/txt; s=iport; t=1374095042; x=1375304642; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zxrVD1eN49IX3opTBVOHVme9FCrpJ9+ROgRtsmNYX58=; b=Y9S0rb0Ge6H8PwwQvIGodAytjLOpJLFZneCRCyUztwm2SqAqux6gbiNZ bvLkpvqnb98i7EkpNfp7QCUNGGTc6SefLI7UFa1bPlc+5cUqu4CPHtK1G swH8h99I7O8QLYNC2wLJnx3PE2q800XqLs3K4XQfysDGowB13mrvyxS+x U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAAUG51GtJXHB/2dsb2JhbABagwY0UMA/gRIWdIIjAQEBAwEBAQE3NAsQAgEIDhQUECcLJQIEDgUIAYgBBgy2G45IgQExB4MNbgOpKYMSgWgHAhcg X-IronPort-AV: E=Sophos;i="4.89,687,1367971200"; d="scan'208";a="233144853" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 17 Jul 2013 21:04:02 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6HL421Y016211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 21:04:02 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.194]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Wed, 17 Jul 2013 16:04:01 -0500 From: "Giovanni Martinelli (giomarti)" To: Lou Berger Thread-Topic: [CCAMP] IETF 87 Draft Agenda Posted Thread-Index: AQHOgx9POp2UiD23yEaJuYpvwHu3U5lpr+kA Date: Wed, 17 Jul 2013 21:04:01 +0000 Message-ID: <0D7F95913F470A4B83AB5F5833A4390D0E1066F2@xmb-rcd-x14.cisco.com> References: <51E6E8A1.4030905@labn.net> In-Reply-To: <51E6E8A1.4030905@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.91.93] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: CCAMP Subject: Re: [CCAMP] IETF 87 Draft Agenda Posted X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 21:04:07 -0000 s/O(rl)a(n)do/\sBe$1i$2/g ;) ~G On Jul 17, 2013, at 20:55 , Lou Berger wrote: >=20 >=20 > All, > The draft agenda for Orlando is available at: > http://www.ietf.org/proceedings/87/agenda/agenda-87-ccamp >=20 > Unfortunately our hope for meeting just once this time will not be > realized. >=20 > Please let us (Daniele & Dan + chairs) know if you have comments or if > we missed anything. We already have one wait listed draft, just in case > someone wishes to give up their time;-) >=20 > Authors of WG documents, >=20 > As usual: >=20 > If presenting, please plan to review (present) any changes that have > been recently made, any open discussions or issues, as well as planned > next steps. >=20 > If you are not presenting, please send this information to the WG mail > list *1 week* prior to the WG meeting. >=20 > Much thanks, > Lou (Deborah, Daniele & Dan) >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From lberger@labn.net Thu Jul 18 12:04:26 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 651FA11E81D2 for ; Thu, 18 Jul 2013 12:04:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.717 X-Spam-Level: X-Spam-Status: No, score=-101.717 tagged_above=-999 required=5 tests=[AWL=0.548, 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 RhlLWL2mmV2A for ; Thu, 18 Jul 2013 12:04:22 -0700 (PDT) Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id D017311E81CB for ; Thu, 18 Jul 2013 12:04:21 -0700 (PDT) Received: (qmail 22041 invoked by uid 0); 18 Jul 2013 19:04:20 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy14.unifiedlayer.com with SMTP; 18 Jul 2013 19:04:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=oxCkszfHxzVB9q/B16EqdqKs+UtsoRsep6szmlCA0/M=; b=B0kvJlQzjbYvwJ1I98H2v3VzOrVKAHg/thTh+cb/U5uZuqH7aNiB6JX8lq3lenwBwx5rl6zTzORSj1PKxbWx3vG0V6DdYv5I9Q8cj+3yyOCmAw+vI0E+uHtreKY+aHZM; Received: from box313.bluehost.com ([69.89.31.113]:36515 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UztUx-0001D5-Vq; Thu, 18 Jul 2013 13:04:20 -0600 Message-ID: <51E83C33.7010802@labn.net> Date: Thu, 18 Jul 2013 15:04:19 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: diego.caviglia@ericsson.com, anders.gavler@acreo.se, jonas.martensson@acreo.se, i-nishioka@cb.jp.nec.com, rrao@infinera.com, giomarti@cisco.com, remi.theillaud@marben-products.com, gregb@grotto-networking.com, ylee@huawei.com, danli@huawei.com, imajuku.wataru@lab.ntt.co.jp, hanjianrui@huawei.com X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ccamp@ietf.org Subject: [CCAMP] Regarding IPR on draft-ietf-ccamp-general-constraint-encode X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 19:04:26 -0000 Authors, Contributors, (CCAMP) As part of the preparation for WG Last Call: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. From lberger@labn.net Thu Jul 18 12:04:41 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9BD21E8162 for ; Thu, 18 Jul 2013 12:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.717 X-Spam-Level: X-Spam-Status: No, score=-101.717 tagged_above=-999 required=5 tests=[AWL=0.548, 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 DAI01-pRvQke for ; Thu, 18 Jul 2013 12:04:41 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id B6DC721E8167 for ; Thu, 18 Jul 2013 12:04:40 -0700 (PDT) Received: (qmail 19675 invoked by uid 0); 18 Jul 2013 19:04:12 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.bluehost.com with SMTP; 18 Jul 2013 19:04:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=oxCkszfHxzVB9q/B16EqdqKs+UtsoRsep6szmlCA0/M=; b=uh2mfdSF2prI59lhFxPiGfttfbe19iRGj6wB4Ft0R4cYq0CB+eK0c5a1CnslpXYgVSno1CF+rjdmLUMK8BHZHXZT32p5FTIeG0g3CLedG+N/2NXU40KPTRkpx2pHAFdO; Received: from box313.bluehost.com ([69.89.31.113]:36474 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UztUq-000184-Nm; Thu, 18 Jul 2013 13:04:12 -0600 Message-ID: <51E83C26.2090302@labn.net> Date: Thu, 18 Jul 2013 15:04:06 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: diego.caviglia@ericsson.com, anders.gavler@acreo.se, jonas.martensson@acreo.se, i-nishioka@cb.jp.nec.com, lyong@ciena.com, cyril.margaria@nsn.com, gregb@grotto-networking.com, leeyoung@huawei.com, danli@huawei.com, imajuku.wataru@lab.ntt.co.jp X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ccamp@ietf.org Subject: [CCAMP] Regarding IPR on draft-ietf-ccamp-rwa-info X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 19:04:42 -0000 Authors, Contributors, (CCAMP) As part of the preparation for WG Last Call: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. From lberger@labn.net Thu Jul 18 12:04:50 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F44B21E8167 for ; Thu, 18 Jul 2013 12:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.717 X-Spam-Level: X-Spam-Status: No, score=-101.717 tagged_above=-999 required=5 tests=[AWL=0.548, 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 mvSqHhViK74y for ; Thu, 18 Jul 2013 12:04:49 -0700 (PDT) Received: from oproxy14-pub.unifiedlayer.com (oproxy14-pub.unifiedlayer.com [67.222.51.224]) by ietfa.amsl.com (Postfix) with SMTP id 92DB321E8162 for ; Thu, 18 Jul 2013 12:04:49 -0700 (PDT) Received: (qmail 24233 invoked by uid 0); 18 Jul 2013 19:04:49 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy14.unifiedlayer.com with SMTP; 18 Jul 2013 19:04:49 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=oxCkszfHxzVB9q/B16EqdqKs+UtsoRsep6szmlCA0/M=; b=bWj/bTGtDAtjzy1QVL+9EKdn7TLJgqjDkIg9f6TaBoA9QrVOqq/nT2aKbAe64J7SVKuqqMt96pXuB5LNUcR1imQCn16oIVk76reVa4LXtTV0WX39KmMBdApXGlhByZIi; Received: from box313.bluehost.com ([69.89.31.113]:36648 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UztVR-0001Vm-2M; Thu, 18 Jul 2013 13:04:49 -0600 Message-ID: <51E83C4F.8090502@labn.net> Date: Thu, 18 Jul 2013 15:04:47 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: diego.caviglia@ericsson.com, anders.gavler@acreo.se, jonas.martensson@acreo.se, i-nishioka@cb.jp.nec.com, pierre.peloso@alcatel-lucent.com, cyril.margaria@nsn.com, giomarti@cisco.com, ggalimbe@cisco.com, lyong@ciena.com, daniele.ceccarelli@ericsson.com, gregb@grotto-networking.com, leeyoung@huawei.com, danli@huawei.com, imajuku.wataru@lab.ntt.co.jp, hanjianrui@huawei.com X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ccamp@ietf.org Subject: [CCAMP] Regarding IPR on draft-ietf-ccamp-rwa-wson-encode X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 19:04:50 -0000 Authors, Contributors, (CCAMP) As part of the preparation for WG Last Call: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. From lberger@labn.net Thu Jul 18 12:05:24 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1C221E8186 for ; Thu, 18 Jul 2013 12:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.717 X-Spam-Level: X-Spam-Status: No, score=-101.717 tagged_above=-999 required=5 tests=[AWL=0.548, 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 OeM93bhM2CNS for ; Thu, 18 Jul 2013 12:05:24 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id A373B21E8162 for ; Thu, 18 Jul 2013 12:05:23 -0700 (PDT) Received: (qmail 22917 invoked by uid 0); 18 Jul 2013 19:04:57 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.bluehost.com with SMTP; 18 Jul 2013 19:04:57 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=oxCkszfHxzVB9q/B16EqdqKs+UtsoRsep6szmlCA0/M=; b=0XlDzOSApzhNa07THbN6LEdag/4EaZ7onXpEr3s3m9BHDu9g90s70UNtziLAn6wxgRgDYaItyphiQDh7OTmq+CTxsEQzyZd8UO+0zcsYK4rYvkCfRqVL9pUwa0IxCL6N; Received: from box313.bluehost.com ([69.89.31.113]:36680 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UztVZ-0001Yo-9w; Thu, 18 Jul 2013 13:04:57 -0600 Message-ID: <51E83C58.6010602@labn.net> Date: Thu, 18 Jul 2013 15:04:56 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: zhangfatai@huawei.com, ylee@huawei.com, hanjianrui@huawei.com, gregb@grotto-networking.com, xuyunbin@mail.ritt.com.cn, zhangguoying@mail.ritt.com.cn, danli@huawei.com, minc@huawei.com, yabin.ye@huawei.com X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ccamp@ietf.org Subject: [CCAMP] Regarding IPR on draft-ietf-ccamp-gmpls-general-constraints-ospf-te X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 19:05:25 -0000 Authors, Contributors, (CCAMP) As part of the preparation for WG Last Call: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. From lberger@labn.net Thu Jul 18 12:05:28 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2446E21E816E for ; Thu, 18 Jul 2013 12:05:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.717 X-Spam-Level: X-Spam-Status: No, score=-101.717 tagged_above=-999 required=5 tests=[AWL=0.548, 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 O529DBx9CLtQ for ; Thu, 18 Jul 2013 12:05:28 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id C147121E8178 for ; Thu, 18 Jul 2013 12:05:24 -0700 (PDT) Received: (qmail 23613 invoked by uid 0); 18 Jul 2013 19:05:03 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.bluehost.com with SMTP; 18 Jul 2013 19:05:03 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=oxCkszfHxzVB9q/B16EqdqKs+UtsoRsep6szmlCA0/M=; b=n0NRD8Iu9WlqNTUizxaEazPLU1W5281tTvACvx6XI2MbBT8tmf5zpXLMVhOSs4CjrmBpWcvz0uL+ThnT7DboLIJCD6jChhcHXQUi3oHH/Ovna3jmRHANXiw6fWtCN4NR; Received: from box313.bluehost.com ([69.89.31.113]:36707 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UztVf-0001gQ-8k; Thu, 18 Jul 2013 13:05:03 -0600 Message-ID: <51E83C5F.9020304@labn.net> Date: Thu, 18 Jul 2013 15:05:03 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: ylee@huawei.com, gregb@grotto-networking.com X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ccamp@ietf.org Subject: [CCAMP] Regarding IPR on draft-ietf-ccamp-wson-signal-compatibility-ospf X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 19:05:28 -0000 Authors, Contributors, (CCAMP) As part of the preparation for WG Last Call: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. From lberger@labn.net Thu Jul 18 12:05:33 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E30A621E8186 for ; Thu, 18 Jul 2013 12:05:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.717 X-Spam-Level: X-Spam-Status: No, score=-101.717 tagged_above=-999 required=5 tests=[AWL=0.548, 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 UNaBTBG+ptYg for ; Thu, 18 Jul 2013 12:05:32 -0700 (PDT) Received: from oproxy6-pub.bluehost.com (oproxy6-pub.bluehost.com [67.222.54.6]) by ietfa.amsl.com (Postfix) with SMTP id 174D121E8191 for ; Thu, 18 Jul 2013 12:05:31 -0700 (PDT) Received: (qmail 16345 invoked by uid 0); 18 Jul 2013 19:05:10 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy6.bluehost.com with SMTP; 18 Jul 2013 19:05:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=oxCkszfHxzVB9q/B16EqdqKs+UtsoRsep6szmlCA0/M=; b=Tf4yUh8pR4ryUWVVolwAXckxq7ZP+m7YZOgikOsItogd5yVmX7W9LJV8sZPo4mUqe8bxqVlRFDunyGpd7bCpFcxS4TYmUfKYFY097bmXroVRMr/AERfdtsEE4OVTzJn+; Received: from box313.bluehost.com ([69.89.31.113]:36751 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1UztVl-0001mx-Nu; Thu, 18 Jul 2013 13:05:09 -0600 Message-ID: <51E83C64.2040105@labn.net> Date: Thu, 18 Jul 2013 15:05:08 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: gregb@grotto-networking.com, nick@sssup.it, a.giorgetti@sssup.it, guolintom@gmail.com, harai@nict.go.jp, jyf@bupt.edu.cn, daniel@olddog.co.uk, leeyoung@huawei.com, xsg@nict.go.jp, giomarti@cisco.com X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ccamp@ietf.org Subject: [CCAMP] Regarding IPR on draft-ietf-ccamp-wson-signaling X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 19:05:33 -0000 Authors, Contributors, (CCAMP) As part of the preparation for WG Last Call: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. From rrao@infinera.com Thu Jul 18 12:21:27 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9F5111E81EB for ; Thu, 18 Jul 2013 12:21: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 7UyqS9osdMVj for ; Thu, 18 Jul 2013 12:21:21 -0700 (PDT) Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id 98F3F11E81E2 for ; Thu, 18 Jul 2013 12:21:09 -0700 (PDT) Received: from SV-EXDB-PROD2.infinera.com ([fe80::1d05:1822:aaea:ff52]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.03.0123.003; Thu, 18 Jul 2013 12:21:08 -0700 From: Rajan Rao To: Lou Berger , "diego.caviglia@ericsson.com" , "anders.gavler@acreo.se" , "jonas.martensson@acreo.se" , "i-nishioka@cb.jp.nec.com" , "giomarti@cisco.com" , "remi.theillaud@marben-products.com" , "gregb@grotto-networking.com" , "ylee@huawei.com" , "danli@huawei.com" , "imajuku.wataru@lab.ntt.co.jp" , "hanjianrui@huawei.com" Thread-Topic: Regarding IPR on draft-ietf-ccamp-general-constraint-encode Thread-Index: AQHOg+mcWrVpf6sYBEivQMvRcU5ozJlqzVjQ Date: Thu, 18 Jul 2013 19:21:07 +0000 Message-ID: <650AA355E323C34D9D4AAEED952E053D3FBB83BC@SV-EXDB-PROD2.infinera.com> References: <51E83C33.7010802@labn.net> In-Reply-To: <51E83C33.7010802@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-general-constraint-encode X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 19:21:27 -0000 Hi, "No, I'm not aware of any IPR that applies to this draft" Thx Rajan -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Thursday, July 18, 2013 12:04 PM To: diego.caviglia@ericsson.com; anders.gavler@acreo.se; jonas.martensson@a= creo.se; i-nishioka@cb.jp.nec.com; Rajan Rao; giomarti@cisco.com; remi.thei= llaud@marben-products.com; gregb@grotto-networking.com; ylee@huawei.com; da= nli@huawei.com; imajuku.wataru@lab.ntt.co.jp; hanjianrui@huawei.com Cc: ccamp@ietf.org Subject: Regarding IPR on draft-ietf-ccamp-general-constraint-encode Authors, Contributors, (CCAMP) As part of the preparation for WG Last Call: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the abo= ve by responding to this email regardless of whether or not you are aware o= f any relevant IPR. This document will not advance to the next stage until= a response has been received from each author and listed contributor. NOT= E: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or co= ntributor, we remind you of your obligations under the IETF IPR rules which= encourages you to notify the IETF if you are aware of IPR of others on an = IETF contribution, or to refrain from participating in any contribution or = discussion related to your undisclosed IPR. For more information, please s= ee the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wik= i/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your respons= e. From leeyoung@huawei.com Thu Jul 18 12:42:55 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8763E11E81ED for ; Thu, 18 Jul 2013 12:42:55 -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 bA6Ge9QcmkhB for ; Thu, 18 Jul 2013 12:42:51 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB4921E815A for ; Thu, 18 Jul 2013 12:42:50 -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 ATO58064; Thu, 18 Jul 2013 19:42:47 +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; Thu, 18 Jul 2013 20:42:06 +0100 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 18 Jul 2013 20:42:47 +0100 Received: from dfweml511-mbs.china.huawei.com ([169.254.15.12]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.007; Thu, 18 Jul 2013 12:42:42 -0700 From: Leeyoung To: Lou Berger , "gregb@grotto-networking.com" Thread-Topic: Regarding IPR on draft-ietf-ccamp-wson-signal-compatibility-ospf Thread-Index: AQHOg+m5MPA6QqWKqkaSHsnc02D1eZlq1Wyw Date: Thu, 18 Jul 2013 19:42:41 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172916264D@dfweml511-mbs.china.huawei.com> References: <51E83C5F.9020304@labn.net> In-Reply-To: <51E83C5F.9020304@labn.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.135.235] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-wson-signal-compatibility-ospf X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 19:42:55 -0000 Hi, Yes, I'm aware of IPR that applies to this draft & the IPR has been disclos= ed in compliance with IETF IPR rules as follows: http://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id_documen= t_tag=3Ddraft-ietf-ccamp-gmpls-general-constraints-ospf-te Thanks. Young -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Thursday, July 18, 2013 2:05 PM To: Leeyoung; gregb@grotto-networking.com Cc: ccamp@ietf.org Subject: Regarding IPR on draft-ietf-ccamp-wson-signal-compatibility-ospf Authors, Contributors, (CCAMP) As part of the preparation for WG Last Call: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the abo= ve by responding to this email regardless of whether or not you are aware o= f any relevant IPR. This document will not advance to the next stage until= a response has been received from each author and listed contributor. NOT= E: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or co= ntributor, we remind you of your obligations under the IETF IPR rules which= encourages you to notify the IETF if you are aware of IPR of others on an = IETF contribution, or to refrain from participating in any contribution or = discussion related to your undisclosed IPR. For more information, please s= ee the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wik= i/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your respons= e. From leeyoung@huawei.com Thu Jul 18 12:46:00 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DDED21E8096 for ; Thu, 18 Jul 2013 12:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MeB+9Gghh80b for ; Thu, 18 Jul 2013 12:45:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 70F0621E8189 for ; Thu, 18 Jul 2013 12:45:55 -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 AVE36846; Thu, 18 Jul 2013 19:45:50 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 18 Jul 2013 20:44:53 +0100 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 18 Jul 2013 20:45:50 +0100 Received: from dfweml511-mbs.china.huawei.com ([169.254.15.12]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.007; Thu, 18 Jul 2013 12:45:39 -0700 From: Leeyoung To: Lou Berger , "diego.caviglia@ericsson.com" , "anders.gavler@acreo.se" , "jonas.martensson@acreo.se" , "i-nishioka@cb.jp.nec.com" , "lyong@ciena.com" , "cyril.margaria@nsn.com" , "gregb@grotto-networking.com" , "Lidan (Dan)" , "imajuku.wataru@lab.ntt.co.jp" Thread-Topic: Regarding IPR on draft-ietf-ccamp-rwa-info Thread-Index: AQHOg+mfGB/wHRqS40CA5j+Dz/Ncm5lq1nSA Date: Thu, 18 Jul 2013 19:45:38 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172916265D@dfweml511-mbs.china.huawei.com> References: <51E83C26.2090302@labn.net> In-Reply-To: <51E83C26.2090302@labn.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.135.235] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-rwa-info X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 19:46:00 -0000 Hi, Yes, I'm aware of IPRs that apply to this draft & the IPRs have been disclo= sed in compliance with IETF IPR rules as follows: http://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id_documen= t_tag=3Ddraft-ietf-ccamp-rwa-info Thanks. Young -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Thursday, July 18, 2013 2:04 PM To: diego.caviglia@ericsson.com; anders.gavler@acreo.se; jonas.martensson@a= creo.se; i-nishioka@cb.jp.nec.com; lyong@ciena.com; cyril.margaria@nsn.com;= gregb@grotto-networking.com; Leeyoung; Lidan (Dan); imajuku.wataru@lab.ntt= .co.jp Cc: ccamp@ietf.org Subject: Regarding IPR on draft-ietf-ccamp-rwa-info Authors, Contributors, (CCAMP) As part of the preparation for WG Last Call: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the abo= ve by responding to this email regardless of whether or not you are aware o= f any relevant IPR. This document will not advance to the next stage until= a response has been received from each author and listed contributor. NOT= E: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or co= ntributor, we remind you of your obligations under the IETF IPR rules which= encourages you to notify the IETF if you are aware of IPR of others on an = IETF contribution, or to refrain from participating in any contribution or = discussion related to your undisclosed IPR. For more information, please s= ee the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wik= i/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your respons= e. From leeyoung@huawei.com Thu Jul 18 12:49:14 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7216611E81F0 for ; Thu, 18 Jul 2013 12:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h9-66Qp-JDqZ for ; Thu, 18 Jul 2013 12:49:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7DB4B11E81E1 for ; Thu, 18 Jul 2013 12:49:08 -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 AVE36990; Thu, 18 Jul 2013 19:49:07 +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, 18 Jul 2013 20:48:09 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 18 Jul 2013 20:49:06 +0100 Received: from dfweml511-mbs.china.huawei.com ([169.254.15.12]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Thu, 18 Jul 2013 12:49:00 -0700 From: Leeyoung To: Lou Berger , "gregb@grotto-networking.com" , "nick@sssup.it" , "a.giorgetti@sssup.it" , "guolintom@gmail.com" , "harai@nict.go.jp" , "jyf@bupt.edu.cn" , "daniel@olddog.co.uk" , "xsg@nict.go.jp" , "giomarti@cisco.com" Thread-Topic: Regarding IPR on draft-ietf-ccamp-wson-signaling Thread-Index: AQHOg+m/PtnVHWyriESFNR7KKwrXoZlq17oA Date: Thu, 18 Jul 2013 19:49:00 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729162677@dfweml511-mbs.china.huawei.com> References: <51E83C64.2040105@labn.net> In-Reply-To: <51E83C64.2040105@labn.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.135.235] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-wson-signaling X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 19:49:14 -0000 No, I am not aware of any IPR that applies to this draft. Young -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Thursday, July 18, 2013 2:05 PM To: gregb@grotto-networking.com; nick@sssup.it; a.giorgetti@sssup.it; guoli= ntom@gmail.com; harai@nict.go.jp; jyf@bupt.edu.cn; daniel@olddog.co.uk; Lee= young; xsg@nict.go.jp; giomarti@cisco.com Cc: ccamp@ietf.org Subject: Regarding IPR on draft-ietf-ccamp-wson-signaling Authors, Contributors, (CCAMP) As part of the preparation for WG Last Call: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the abo= ve by responding to this email regardless of whether or not you are aware o= f any relevant IPR. This document will not advance to the next stage until= a response has been received from each author and listed contributor. NOT= E: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or co= ntributor, we remind you of your obligations under the IETF IPR rules which= encourages you to notify the IETF if you are aware of IPR of others on an = IETF contribution, or to refrain from participating in any contribution or = discussion related to your undisclosed IPR. For more information, please s= ee the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wik= i/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your respons= e. From leeyoung@huawei.com Thu Jul 18 12:49:49 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E025921E8096 for ; Thu, 18 Jul 2013 12:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdFB+QBBP5bQ for ; Thu, 18 Jul 2013 12:49:45 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2154311E80F4 for ; Thu, 18 Jul 2013 12:49:44 -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 ATO58307; Thu, 18 Jul 2013 19:49:44 +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, 18 Jul 2013 20:49:02 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 18 Jul 2013 20:49:43 +0100 Received: from dfweml511-mbs.china.huawei.com ([169.254.15.12]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.007; Thu, 18 Jul 2013 12:49:35 -0700 From: Leeyoung To: Lou Berger , Fatai Zhang , Hanjianrui , "gregb@grotto-networking.com" , "xuyunbin@mail.ritt.com.cn" , "zhangguoying@mail.ritt.com.cn" , "Lidan (Dan)" , "Chenming (NWResearch)" , "Yeyabin (Yabin)" Thread-Topic: Regarding IPR on draft-ietf-ccamp-gmpls-general-constraints-ospf-te Thread-Index: AQHOg+m42dgnSTSvY0iwm25rPko3Y5lq2AAA Date: Thu, 18 Jul 2013 19:49:35 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E1729162684@dfweml511-mbs.china.huawei.com> References: <51E83C58.6010602@labn.net> In-Reply-To: <51E83C58.6010602@labn.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.135.235] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-gmpls-general-constraints-ospf-te X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 19:49:50 -0000 No, I am not aware of any IPR that applies to this draft. Young -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Thursday, July 18, 2013 2:05 PM To: Fatai Zhang; Leeyoung; Hanjianrui; gregb@grotto-networking.com; xuyunbi= n@mail.ritt.com.cn; zhangguoying@mail.ritt.com.cn; Lidan (Dan); Chenming (N= WResearch); Yeyabin (Yabin) Cc: ccamp@ietf.org Subject: Regarding IPR on draft-ietf-ccamp-gmpls-general-constraints-ospf-t= e Authors, Contributors, (CCAMP) As part of the preparation for WG Last Call: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the abo= ve by responding to this email regardless of whether or not you are aware o= f any relevant IPR. This document will not advance to the next stage until= a response has been received from each author and listed contributor. NOT= E: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or co= ntributor, we remind you of your obligations under the IETF IPR rules which= encourages you to notify the IETF if you are aware of IPR of others on an = IETF contribution, or to refrain from participating in any contribution or = discussion related to your undisclosed IPR. For more information, please s= ee the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wik= i/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your respons= e. From leeyoung@huawei.com Thu Jul 18 12:50:06 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 059AA11E81FD for ; Thu, 18 Jul 2013 12:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lozRS4owglEY for ; Thu, 18 Jul 2013 12:50:01 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AEE0221E8189 for ; Thu, 18 Jul 2013 12:49:59 -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 ATO58315; Thu, 18 Jul 2013 19:49:56 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 18 Jul 2013 20:48:57 +0100 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 18 Jul 2013 20:49:54 +0100 Received: from dfweml511-mbs.china.huawei.com ([169.254.15.12]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.007; Thu, 18 Jul 2013 12:49:46 -0700 From: Leeyoung To: Lou Berger , "diego.caviglia@ericsson.com" , "anders.gavler@acreo.se" , "jonas.martensson@acreo.se" , "i-nishioka@cb.jp.nec.com" , "pierre.peloso@alcatel-lucent.com" , "cyril.margaria@nsn.com" , "giomarti@cisco.com" , "ggalimbe@cisco.com" , "lyong@ciena.com" , "daniele.ceccarelli@ericsson.com" , "gregb@grotto-networking.com" , "Lidan (Dan)" , "imajuku.wataru@lab.ntt.co.jp" , Hanjianrui Thread-Topic: Regarding IPR on draft-ietf-ccamp-rwa-wson-encode Thread-Index: AQHOg+my5RYk+c7YY06uxmuGFBoptZlq2A1A Date: Thu, 18 Jul 2013 19:49:45 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172916268B@dfweml511-mbs.china.huawei.com> References: <51E83C4F.8090502@labn.net> In-Reply-To: <51E83C4F.8090502@labn.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.135.235] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-rwa-wson-encode X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 19:50:06 -0000 No, I am not aware of any IPR that applies to this draft. Young -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Thursday, July 18, 2013 2:05 PM To: diego.caviglia@ericsson.com; anders.gavler@acreo.se; jonas.martensson@a= creo.se; i-nishioka@cb.jp.nec.com; pierre.peloso@alcatel-lucent.com; cyril.= margaria@nsn.com; giomarti@cisco.com; ggalimbe@cisco.com; lyong@ciena.com; = daniele.ceccarelli@ericsson.com; gregb@grotto-networking.com; Leeyoung; Lid= an (Dan); imajuku.wataru@lab.ntt.co.jp; Hanjianrui Cc: ccamp@ietf.org Subject: Regarding IPR on draft-ietf-ccamp-rwa-wson-encode Authors, Contributors, (CCAMP) As part of the preparation for WG Last Call: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the abo= ve by responding to this email regardless of whether or not you are aware o= f any relevant IPR. This document will not advance to the next stage until= a response has been received from each author and listed contributor. NOT= E: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or co= ntributor, we remind you of your obligations under the IETF IPR rules which= encourages you to notify the IETF if you are aware of IPR of others on an = IETF contribution, or to refrain from participating in any contribution or = discussion related to your undisclosed IPR. For more information, please s= ee the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wik= i/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your respons= e. From leeyoung@huawei.com Thu Jul 18 12:54:21 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046BF11E8199 for ; Thu, 18 Jul 2013 12:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKodlh82Wd96 for ; Thu, 18 Jul 2013 12:54:16 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2B49311E81FA for ; Thu, 18 Jul 2013 12:53:58 -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 AVE37150; Thu, 18 Jul 2013 19:53:55 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 18 Jul 2013 20:53:13 +0100 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 18 Jul 2013 20:53:54 +0100 Received: from dfweml511-mbs.china.huawei.com ([169.254.15.12]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.007; Thu, 18 Jul 2013 12:53:44 -0700 From: Leeyoung To: Lou Berger , "diego.caviglia@ericsson.com" , "anders.gavler@acreo.se" , "jonas.martensson@acreo.se" , "i-nishioka@cb.jp.nec.com" , "rrao@infinera.com" , "giomarti@cisco.com" , "remi.theillaud@marben-products.com" , "gregb@grotto-networking.com" , "Lidan (Dan)" , "imajuku.wataru@lab.ntt.co.jp" , Hanjianrui Thread-Topic: Regarding IPR on draft-ietf-ccamp-general-constraint-encode Thread-Index: AQHOg+mhkT85fgwhdEOMqPwJJU22q5lq2Seg Date: Thu, 18 Jul 2013 19:53:43 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E172916269E@dfweml511-mbs.china.huawei.com> References: <51E83C33.7010802@labn.net> In-Reply-To: <51E83C33.7010802@labn.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.135.235] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-general-constraint-encode X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 19:54:21 -0000 No, I am not aware of any IPR that applies to this draft. Young -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Thursday, July 18, 2013 2:04 PM To: diego.caviglia@ericsson.com; anders.gavler@acreo.se; jonas.martensson@a= creo.se; i-nishioka@cb.jp.nec.com; rrao@infinera.com; giomarti@cisco.com; r= emi.theillaud@marben-products.com; gregb@grotto-networking.com; Leeyoung; L= idan (Dan); imajuku.wataru@lab.ntt.co.jp; Hanjianrui Cc: ccamp@ietf.org Subject: Regarding IPR on draft-ietf-ccamp-general-constraint-encode Authors, Contributors, (CCAMP) As part of the preparation for WG Last Call: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the abo= ve by responding to this email regardless of whether or not you are aware o= f any relevant IPR. This document will not advance to the next stage until= a response has been received from each author and listed contributor. NOT= E: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or co= ntributor, we remind you of your obligations under the IETF IPR rules which= encourages you to notify the IETF if you are aware of IPR of others on an = IETF contribution, or to refrain from participating in any contribution or = discussion related to your undisclosed IPR. For more information, please s= ee the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wik= i/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your respons= e. From leeyoung@huawei.com Thu Jul 18 12:56:50 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7557021E8158 for ; Thu, 18 Jul 2013 12:56:50 -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 po-9Od+1TAz4 for ; Thu, 18 Jul 2013 12:56:46 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AA92C11E8199 for ; Thu, 18 Jul 2013 12:56:45 -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 AVE37277; Thu, 18 Jul 2013 19:56:44 +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; Thu, 18 Jul 2013 20:56:03 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 18 Jul 2013 20:56:44 +0100 Received: from dfweml511-mbs.china.huawei.com ([169.254.15.12]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.007; Thu, 18 Jul 2013 12:56:31 -0700 From: Leeyoung To: Leeyoung , Lou Berger , Fatai Zhang , Hanjianrui , "gregb@grotto-networking.com" , "xuyunbin@mail.ritt.com.cn" , "zhangguoying@mail.ritt.com.cn" , "Lidan (Dan)" , "Chenming (NWResearch)" , "Yeyabin (Yabin)" Thread-Topic: Regarding IPR on draft-ietf-ccamp-gmpls-general-constraints-ospf-te Thread-Index: AQHOg+m42dgnSTSvY0iwm25rPko3Y5lq2AAAgAABdbA= Date: Thu, 18 Jul 2013 19:56:31 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E17291626AD@dfweml511-mbs.china.huawei.com> References: <51E83C58.6010602@labn.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.135.235] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-gmpls-general-constraints-ospf-te X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 19:56:50 -0000 Sorry about my confusion on this email. Let me correct.=20 Yes, I'm aware of IPR that applies to this draft and the IPR has been discl= osed in compliance with IETF IPR rules as follows:=20 https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&document_= search=3Ddraft-ietf-ccamp-gmpls-general-constraints-ospf-te Thanks. Young -----Original Message----- From: Leeyoung=20 Sent: Thursday, July 18, 2013 2:50 PM To: 'Lou Berger'; Fatai Zhang; Hanjianrui; gregb@grotto-networking.com; xuy= unbin@mail.ritt.com.cn; zhangguoying@mail.ritt.com.cn; Lidan (Dan); Chenmin= g (NWResearch); Yeyabin (Yabin) Cc: ccamp@ietf.org Subject: RE: Regarding IPR on draft-ietf-ccamp-gmpls-general-constraints-os= pf-te No, I am not aware of any IPR that applies to this draft. Young -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Thursday, July 18, 2013 2:05 PM To: Fatai Zhang; Leeyoung; Hanjianrui; gregb@grotto-networking.com; xuyunbi= n@mail.ritt.com.cn; zhangguoying@mail.ritt.com.cn; Lidan (Dan); Chenming (N= WResearch); Yeyabin (Yabin) Cc: ccamp@ietf.org Subject: Regarding IPR on draft-ietf-ccamp-gmpls-general-constraints-ospf-t= e Authors, Contributors, (CCAMP) As part of the preparation for WG Last Call: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the abo= ve by responding to this email regardless of whether or not you are aware o= f any relevant IPR. This document will not advance to the next stage until= a response has been received from each author and listed contributor. NOT= E: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or co= ntributor, we remind you of your obligations under the IETF IPR rules which= encourages you to notify the IETF if you are aware of IPR of others on an = IETF contribution, or to refrain from participating in any contribution or = discussion related to your undisclosed IPR. For more information, please s= ee the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wik= i/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your respons= e. From leeyoung@huawei.com Thu Jul 18 12:59:51 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC1021E8187 for ; Thu, 18 Jul 2013 12:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u3NM9lZ8bNYV for ; Thu, 18 Jul 2013 12:59:47 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 831B221E8181 for ; Thu, 18 Jul 2013 12:59:46 -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 AVE37401; Thu, 18 Jul 2013 19:59:45 +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, 18 Jul 2013 20:59:02 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 18 Jul 2013 20:59:28 +0100 Received: from dfweml511-mbs.china.huawei.com ([169.254.15.12]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.007; Thu, 18 Jul 2013 12:59:17 -0700 From: Leeyoung To: Leeyoung , Lou Berger , "gregb@grotto-networking.com" Thread-Topic: Regarding IPR on draft-ietf-ccamp-wson-signal-compatibility-ospf Thread-Index: AQHOg+m5MPA6QqWKqkaSHsnc02D1eZlq1WywgAAE1rA= Date: Thu, 18 Jul 2013 19:59:17 +0000 Message-ID: <7AEB3D6833318045B4AE71C2C87E8E17291626BC@dfweml511-mbs.china.huawei.com> References: <51E83C5F.9020304@labn.net> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.135.235] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-wson-signal-compatibility-ospf X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 19:59:51 -0000 Hi, Sorry for the confusion. The following is the right link for IETF IPR discl= osure for this draft. The previous link was wrong.=20 https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&document_= search=3Ddraft-ietf-ccamp-wson-signal-compatibility-ospf=20 Thanks. Young -----Original Message----- From: Leeyoung=20 Sent: Thursday, July 18, 2013 2:43 PM To: 'Lou Berger'; gregb@grotto-networking.com Cc: ccamp@ietf.org Subject: RE: Regarding IPR on draft-ietf-ccamp-wson-signal-compatibility-os= pf Hi, Yes, I'm aware of IPR that applies to this draft & the IPR has been disclos= ed in compliance with IETF IPR rules as follows: http://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&id_documen= t_tag=3Ddraft-ietf-ccamp-gmpls-general-constraints-ospf-te Thanks. Young -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Thursday, July 18, 2013 2:05 PM To: Leeyoung; gregb@grotto-networking.com Cc: ccamp@ietf.org Subject: Regarding IPR on draft-ietf-ccamp-wson-signal-compatibility-ospf Authors, Contributors, (CCAMP) As part of the preparation for WG Last Call: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the abo= ve by responding to this email regardless of whether or not you are aware o= f any relevant IPR. This document will not advance to the next stage until= a response has been received from each author and listed contributor. NOT= E: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or co= ntributor, we remind you of your obligations under the IETF IPR rules which= encourages you to notify the IETF if you are aware of IPR of others on an = IETF contribution, or to refrain from participating in any contribution or = discussion related to your undisclosed IPR. For more information, please s= ee the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wik= i/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your respons= e. From zhangfatai@huawei.com Thu Jul 18 17:30:47 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA28421E8187 for ; Thu, 18 Jul 2013 17:30:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.395 X-Spam-Level: X-Spam-Status: No, score=-3.395 tagged_above=-999 required=5 tests=[AWL=3.204, 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 wPOlMGW2fBh0 for ; Thu, 18 Jul 2013 17:30:43 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EFA9A21E819A for ; Thu, 18 Jul 2013 17:30:42 -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 AVE47782; Fri, 19 Jul 2013 00:30:41 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 01:29:59 +0100 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 01:30:41 +0100 Received: from SZXEML552-MBS.china.huawei.com ([169.254.2.110]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.007; Fri, 19 Jul 2013 08:30:29 +0800 From: Fatai Zhang To: Lou Berger , Leeyoung , Hanjianrui , "gregb@grotto-networking.com" , "xuyunbin@mail.ritt.com.cn" , "zhangguoying@mail.ritt.com.cn" , "Lidan (Dan)" , "Chenming (NWResearch)" , "Yeyabin (Yabin)" Thread-Topic: Regarding IPR on draft-ietf-ccamp-gmpls-general-constraints-ospf-te Thread-Index: AQHOg+m2ejBsiO/RwU6YitRZ8S1/U5lrJmhg Date: Fri, 19 Jul 2013 00:30:29 +0000 Message-ID: References: <51E83C58.6010602@labn.net> In-Reply-To: <51E83C58.6010602@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.72.159] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-gmpls-general-constraints-ospf-te X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 00:30:47 -0000 Yes, I'm aware of IPR that applies to this draft and the IPR has been discl= osed in compliance with IETF IPR rules as follows:=20 https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&document_= search=3Ddraft-ietf-ccamp-gmpls-general-constraints-ospf-te Best Regards Fatai -----Original Message----- From: Lou Berger [mailto:lberger@labn.net]=20 Sent: Friday, July 19, 2013 3:05 AM To: Fatai Zhang; Leeyoung; Hanjianrui; gregb@grotto-networking.com; xuyunbi= n@mail.ritt.com.cn; zhangguoying@mail.ritt.com.cn; Lidan (Dan); Chenming (N= WResearch); Yeyabin (Yabin) Cc: ccamp@ietf.org Subject: Regarding IPR on draft-ietf-ccamp-gmpls-general-constraints-ospf-t= e Authors, Contributors, (CCAMP) As part of the preparation for WG Last Call: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. From huawei.danli@huawei.com Thu Jul 18 17:39:40 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F9B111E8247 for ; Thu, 18 Jul 2013 17:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.788 X-Spam-Level: ** X-Spam-Status: No, score=2.788 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cezCm7E0eTZM for ; Thu, 18 Jul 2013 17:39:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0923C11E8246 for ; Thu, 18 Jul 2013 17:39:30 -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 AVE48165; Fri, 19 Jul 2013 00:39:30 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 01:38:47 +0100 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 01:39:29 +0100 Received: from szxeml555-mbx.china.huawei.com ([169.254.1.249]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.007; Fri, 19 Jul 2013 08:39:17 +0800 From: "Lidan (Dan)" To: Lou Berger , Fatai Zhang , Leeyoung , Hanjianrui , "gregb@grotto-networking.com" , "xuyunbin@mail.ritt.com.cn" , "zhangguoying@mail.ritt.com.cn" , "Chenming (NWResearch)" , "Yeyabin (Yabin)" Thread-Topic: Regarding IPR on draft-ietf-ccamp-gmpls-general-constraints-ospf-te Thread-Index: AQHOg+m2rJv23C9LSkymEALi4uXVPJlrKDwQ Date: Fri, 19 Jul 2013 00:39:16 +0000 Message-ID: <92A1F6CF27D54D4DA5364E59D892A02A56392336@szxeml555-mbx.china.huawei.com> References: <51E83C58.6010602@labn.net> In-Reply-To: <51E83C58.6010602@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.73.151] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ccamp@ietf.org" Subject: [CCAMP] =?gb2312?b?tPC4tDogUmVnYXJkaW5nIElQUiBvbiBkcmFmdC1pZXRm?= =?gb2312?b?LWNjYW1wLWdtcGxzLWdlbmVyYWwtY29uc3RyYWludHMtb3NwZi10ZQ==?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 00:39:40 -0000 WWVzLCBJJ20gYXdhcmUgb2YgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0IGFuZCB0aGUg SVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMg YXMgZm9sbG93czogDQoNCmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByL3NlYXJjaC8/ b3B0aW9uPWRvY3VtZW50X3NlYXJjaCZkb2N1bWVudF9zZWFyY2g9ZHJhZnQtaWV0Zi1jY2FtcC1n bXBscy1nZW5lcmFsLWNvbnN0cmFpbnRzLW9zcGYtdGUNCg0KRGFuDQoNCg0KLS0tLS3Tyrz+1K28 /i0tLS0tDQq3orz+yMs6IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XSANCrei y83KsbzkOiAyMDEzxOo31MIxOcjVIDM6MDUNCsrVvP7IyzogRmF0YWkgWmhhbmc7IExlZXlvdW5n OyBIYW5qaWFucnVpOyBncmVnYkBncm90dG8tbmV0d29ya2luZy5jb207IHh1eXVuYmluQG1haWwu cml0dC5jb20uY247IHpoYW5nZ3VveWluZ0BtYWlsLnJpdHQuY29tLmNuOyBMaWRhbiAoRGFuKTsg Q2hlbm1pbmcgKE5XUmVzZWFyY2gpOyBZZXlhYmluIChZYWJpbikNCrOty806IGNjYW1wQGlldGYu b3JnDQrW98ziOiBSZWdhcmRpbmcgSVBSIG9uIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJh bC1jb25zdHJhaW50cy1vc3BmLXRlDQoNCkF1dGhvcnMsIENvbnRyaWJ1dG9ycywgKENDQU1QKQ0K DQpBcyBwYXJ0IG9mIHRoZSBwcmVwYXJhdGlvbiBmb3IgV0cgTGFzdCBDYWxsOg0KDQpBcmUgeW91 IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0IGlkZW50aWZpZWQgYWJvdmU/ DQoNCiAgUGxlYXNlIHN0YXRlIGVpdGhlcjoNCg0KICAiTm8sIEknbSBub3QgYXdhcmUgb2YgYW55 IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCINCiAgb3INCiAgIlllcywgSSdtIGF3YXJl IG9mIElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCINCg0KSWYgc28sIGhhcyB0aGlzIElQ UiBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMNCihzZWUg UkZDcyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpPw0KDQogICBJ ZiB5ZXMgdG8gdGhlIGFib3ZlLCBwbGVhc2Ugc3RhdGUgZWl0aGVyOg0KDQogICJZZXMsIHRoZSBJ UFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyIN CiAgb3INCiAgIk5vLCB0aGUgSVBSIGhhcyBub3QgYmVlbiBkaXNjbG9zZWQiDQoNCiAgSWYgeW91 IGFuc3dlciBubywgcGxlYXNlIHByb3ZpZGUgYW55IGFkZGl0aW9uYWwgZGV0YWlscyB5b3UgdGhp bmsNCiAgYXBwcm9wcmlhdGUuDQoNCklmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0 aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSBhbnN3ZXIgdGhlDQphYm92ZSBieSByZXNwb25kaW5n IHRvIHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlDQphd2Fy ZSBvZiBhbnkgcmVsZXZhbnQgSVBSLiAgVGhpcyBkb2N1bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRv IHRoZSBuZXh0DQpzdGFnZSB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkIGZyb20g ZWFjaCBhdXRob3IgYW5kIGxpc3RlZA0KY29udHJpYnV0b3IuICBOT1RFOiBUSElTIEFQUExJRVMg VE8gQUxMIE9GIFlPVSBMSVNURUQgSU4gVEhJUw0KTUVTU0FHRSdTIFRPIExJTkVTLg0KDQpJZiB5 b3UgYXJlIG9uIHRoZSBDQ0FNUCBXRyBlbWFpbCBsaXN0IGJ1dCBhcmUgbm90IGxpc3RlZCBhcyBh biBhdXRob3Igb3INCmNvbnRyaWJ1dG9yLCB3ZSByZW1pbmQgeW91IG9mIHlvdXIgb2JsaWdhdGlv bnMgdW5kZXIgdGhlIElFVEYgSVBSIHJ1bGVzDQp3aGljaCBlbmNvdXJhZ2VzIHlvdSB0byBub3Rp ZnkgdGhlIElFVEYgaWYgeW91IGFyZSBhd2FyZSBvZiBJUFIgb2YNCm90aGVycyBvbiBhbiBJRVRG IGNvbnRyaWJ1dGlvbiwgb3IgdG8gcmVmcmFpbiBmcm9tIHBhcnRpY2lwYXRpbmcgaW4gYW55DQpj b250cmlidXRpb24gb3IgZGlzY3Vzc2lvbiByZWxhdGVkIHRvIHlvdXIgdW5kaXNjbG9zZWQgSVBS LiAgRm9yIG1vcmUNCmluZm9ybWF0aW9uLCBwbGVhc2Ugc2VlIHRoZSBSRkNzIGxpc3RlZCBhYm92 ZSBhbmQNCmh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2dyb3VwL2llc2cvdHJhYy93aWtpL0lu dGVsbGVjdHVhbFByb3BlcnR5Lg0KDQpUaGFuayB5b3UsDQpDQ0FNUCBXRyBDaGFpcnMNCg0KUFMg UGxlYXNlIGluY2x1ZGUgYWxsIGxpc3RlZCBpbiB0aGUgaGVhZGVycyBvZiB0aGlzIG1lc3NhZ2Ug aW4geW91cg0KcmVzcG9uc2UuDQo= From huawei.danli@huawei.com Thu Jul 18 17:43:17 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1DE21F9E1E for ; Thu, 18 Jul 2013 17:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.788 X-Spam-Level: ** X-Spam-Status: No, score=2.788 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cC9LROXl3KlR for ; Thu, 18 Jul 2013 17:43:13 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 55C6521F9E12 for ; Thu, 18 Jul 2013 17:43:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATO69584; Fri, 19 Jul 2013 00:43:07 +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; Fri, 19 Jul 2013 01:42:08 +0100 Received: from szxeml459-hub.china.huawei.com (10.82.67.202) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 01:43:05 +0100 Received: from szxeml555-mbx.china.huawei.com ([169.254.1.249]) by szxeml459-hub.china.huawei.com ([10.82.67.202]) with mapi id 14.01.0323.007; Fri, 19 Jul 2013 08:42:53 +0800 From: "Lidan (Dan)" To: Lou Berger , "diego.caviglia@ericsson.com" , "anders.gavler@acreo.se" , "jonas.martensson@acreo.se" , "i-nishioka@cb.jp.nec.com" , "rrao@infinera.com" , "giomarti@cisco.com" , "remi.theillaud@marben-products.com" , "gregb@grotto-networking.com" , Leeyoung , "imajuku.wataru@lab.ntt.co.jp" , Hanjianrui Thread-Topic: Regarding IPR on draft-ietf-ccamp-general-constraint-encode Thread-Index: AQHOg+meAWSAfIB3/0mq/ZDEqFPwMZlrKZVA Date: Fri, 19 Jul 2013 00:42:53 +0000 Message-ID: <92A1F6CF27D54D4DA5364E59D892A02A56392342@szxeml555-mbx.china.huawei.com> References: <51E83C33.7010802@labn.net> In-Reply-To: <51E83C33.7010802@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.73.151] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ccamp@ietf.org" Subject: [CCAMP] =?gb2312?b?tPC4tDogUmVnYXJkaW5nIElQUiBvbiBkcmFmdC1pZXRm?= =?gb2312?b?LWNjYW1wLWdlbmVyYWwtY29uc3RyYWludC1lbmNvZGU=?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 00:43:17 -0000 Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdC4N Cg0KVGhhbmtzLA0KDQpEYW4NCg0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogTG91IEJl cmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdIA0Kt6LLzcqxvOQ6IDIwMTPE6jfUwjE5yNUg MzowNA0KytW8/sjLOiBkaWVnby5jYXZpZ2xpYUBlcmljc3Nvbi5jb207IGFuZGVycy5nYXZsZXJA YWNyZW8uc2U7IGpvbmFzLm1hcnRlbnNzb25AYWNyZW8uc2U7IGktbmlzaGlva2FAY2IuanAubmVj LmNvbTsgcnJhb0BpbmZpbmVyYS5jb207IGdpb21hcnRpQGNpc2NvLmNvbTsgcmVtaS50aGVpbGxh dWRAbWFyYmVuLXByb2R1Y3RzLmNvbTsgZ3JlZ2JAZ3JvdHRvLW5ldHdvcmtpbmcuY29tOyBMZWV5 b3VuZzsgTGlkYW4gKERhbik7IGltYWp1a3Uud2F0YXJ1QGxhYi5udHQuY28uanA7IEhhbmppYW5y dWkNCrOty806IGNjYW1wQGlldGYub3JnDQrW98ziOiBSZWdhcmRpbmcgSVBSIG9uIGRyYWZ0LWll dGYtY2NhbXAtZ2VuZXJhbC1jb25zdHJhaW50LWVuY29kZQ0KDQpBdXRob3JzLCBDb250cmlidXRv cnMsIChDQ0FNUCkNCg0KQXMgcGFydCBvZiB0aGUgcHJlcGFyYXRpb24gZm9yIFdHIExhc3QgQ2Fs bDoNCg0KQXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byBkcmFmdCBpZGVu dGlmaWVkIGFib3ZlPw0KDQogIFBsZWFzZSBzdGF0ZSBlaXRoZXI6DQoNCiAgIk5vLCBJJ20gbm90 IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQiDQogIG9yDQogICJZ ZXMsIEknbSBhd2FyZSBvZiBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQiDQoNCklmIHNv LCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBS IHJ1bGVzDQooc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRh aWxzKT8NCg0KICAgSWYgeWVzIHRvIHRoZSBhYm92ZSwgcGxlYXNlIHN0YXRlIGVpdGhlcjoNCg0K ICAiWWVzLCB0aGUgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVU RiBJUFIgcnVsZXMiDQogIG9yDQogICJObywgdGhlIElQUiBoYXMgbm90IGJlZW4gZGlzY2xvc2Vk Ig0KDQogIElmIHlvdSBhbnN3ZXIgbm8sIHBsZWFzZSBwcm92aWRlIGFueSBhZGRpdGlvbmFsIGRl dGFpbHMgeW91IHRoaW5rDQogIGFwcHJvcHJpYXRlLg0KDQpJZiB5b3UgYXJlIGxpc3RlZCBhcyBh IGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgYW5zd2VyIHRoZQ0KYWJvdmUg YnkgcmVzcG9uZGluZyB0byB0aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3Qg eW91IGFyZQ0KYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4gIFRoaXMgZG9jdW1lbnQgd2lsbCBu b3QgYWR2YW5jZSB0byB0aGUgbmV4dA0Kc3RhZ2UgdW50aWwgYSByZXNwb25zZSBoYXMgYmVlbiBy ZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBsaXN0ZWQNCmNvbnRyaWJ1dG9yLiAgTk9URTog VEhJUyBBUFBMSUVTIFRPIEFMTCBPRiBZT1UgTElTVEVEIElOIFRISVMNCk1FU1NBR0UnUyBUTyBM SU5FUy4NCg0KSWYgeW91IGFyZSBvbiB0aGUgQ0NBTVAgV0cgZW1haWwgbGlzdCBidXQgYXJlIG5v dCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yDQpjb250cmlidXRvciwgd2UgcmVtaW5kIHlvdSBvZiB5 b3VyIG9ibGlnYXRpb25zIHVuZGVyIHRoZSBJRVRGIElQUiBydWxlcw0Kd2hpY2ggZW5jb3VyYWdl cyB5b3UgdG8gbm90aWZ5IHRoZSBJRVRGIGlmIHlvdSBhcmUgYXdhcmUgb2YgSVBSIG9mDQpvdGhl cnMgb24gYW4gSUVURiBjb250cmlidXRpb24sIG9yIHRvIHJlZnJhaW4gZnJvbSBwYXJ0aWNpcGF0 aW5nIGluIGFueQ0KY29udHJpYnV0aW9uIG9yIGRpc2N1c3Npb24gcmVsYXRlZCB0byB5b3VyIHVu ZGlzY2xvc2VkIElQUi4gIEZvciBtb3JlDQppbmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgUkZD cyBsaXN0ZWQgYWJvdmUgYW5kDQpodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9ncm91cC9pZXNn L3RyYWMvd2lraS9JbnRlbGxlY3R1YWxQcm9wZXJ0eS4NCg0KVGhhbmsgeW91LA0KQ0NBTVAgV0cg Q2hhaXJzDQoNClBTIFBsZWFzZSBpbmNsdWRlIGFsbCBsaXN0ZWQgaW4gdGhlIGhlYWRlcnMgb2Yg dGhpcyBtZXNzYWdlIGluIHlvdXINCnJlc3BvbnNlLg0K From huawei.danli@huawei.com Thu Jul 18 17:44:22 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4D711E824B for ; Thu, 18 Jul 2013 17:44:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.788 X-Spam-Level: ** X-Spam-Status: No, score=2.788 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lo1nvx0jGlIz for ; Thu, 18 Jul 2013 17:44:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8B57611E8165 for ; Thu, 18 Jul 2013 17:44:17 -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 ATO69635; Fri, 19 Jul 2013 00:44:14 +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; Fri, 19 Jul 2013 01:43:16 +0100 Received: from SZXEML417-HUB.china.huawei.com (10.82.67.156) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 01:44:14 +0100 Received: from szxeml555-mbx.china.huawei.com ([169.254.1.249]) by szxeml417-hub.china.huawei.com ([10.82.67.156]) with mapi id 14.01.0323.007; Fri, 19 Jul 2013 08:44:03 +0800 From: "Lidan (Dan)" To: Lou Berger , "diego.caviglia@ericsson.com" , "anders.gavler@acreo.se" , "jonas.martensson@acreo.se" , "i-nishioka@cb.jp.nec.com" , "pierre.peloso@alcatel-lucent.com" , "cyril.margaria@nsn.com" , "giomarti@cisco.com" , "ggalimbe@cisco.com" , "lyong@ciena.com" , "daniele.ceccarelli@ericsson.com" , "gregb@grotto-networking.com" , Leeyoung , "imajuku.wataru@lab.ntt.co.jp" , Hanjianrui Thread-Topic: Regarding IPR on draft-ietf-ccamp-rwa-wson-encode Thread-Index: AQHOg+mx/xCjoeF44ESH7L8wUt2x0ZlrKjqw Date: Fri, 19 Jul 2013 00:44:02 +0000 Message-ID: <92A1F6CF27D54D4DA5364E59D892A02A5639234D@szxeml555-mbx.china.huawei.com> References: <51E83C4F.8090502@labn.net> In-Reply-To: <51E83C4F.8090502@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.73.151] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ccamp@ietf.org" Subject: [CCAMP] =?gb2312?b?tPC4tDogUmVnYXJkaW5nIElQUiBvbiBkcmFmdC1pZXRm?= =?gb2312?b?LWNjYW1wLXJ3YS13c29uLWVuY29kZQ==?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 00:44:22 -0000 Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdC4N Cg0KVGhhbmtzLA0KDQpEYW4NCg0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogTG91IEJl cmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdIA0Kt6LLzcqxvOQ6IDIwMTPE6jfUwjE5yNUg MzowNQ0KytW8/sjLOiBkaWVnby5jYXZpZ2xpYUBlcmljc3Nvbi5jb207IGFuZGVycy5nYXZsZXJA YWNyZW8uc2U7IGpvbmFzLm1hcnRlbnNzb25AYWNyZW8uc2U7IGktbmlzaGlva2FAY2IuanAubmVj LmNvbTsgcGllcnJlLnBlbG9zb0BhbGNhdGVsLWx1Y2VudC5jb207IGN5cmlsLm1hcmdhcmlhQG5z bi5jb207IGdpb21hcnRpQGNpc2NvLmNvbTsgZ2dhbGltYmVAY2lzY28uY29tOyBseW9uZ0BjaWVu YS5jb207IGRhbmllbGUuY2VjY2FyZWxsaUBlcmljc3Nvbi5jb207IGdyZWdiQGdyb3R0by1uZXR3 b3JraW5nLmNvbTsgTGVleW91bmc7IExpZGFuIChEYW4pOyBpbWFqdWt1LndhdGFydUBsYWIubnR0 LmNvLmpwOyBIYW5qaWFucnVpDQqzrcvNOiBjY2FtcEBpZXRmLm9yZw0K1vfM4jogUmVnYXJkaW5n IElQUiBvbiBkcmFmdC1pZXRmLWNjYW1wLXJ3YS13c29uLWVuY29kZQ0KDQpBdXRob3JzLCBDb250 cmlidXRvcnMsIChDQ0FNUCkNCg0KQXMgcGFydCBvZiB0aGUgcHJlcGFyYXRpb24gZm9yIFdHIExh c3QgQ2FsbDoNCg0KQXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byBkcmFm dCBpZGVudGlmaWVkIGFib3ZlPw0KDQogIFBsZWFzZSBzdGF0ZSBlaXRoZXI6DQoNCiAgIk5vLCBJ J20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQiDQogIG9y DQogICJZZXMsIEknbSBhd2FyZSBvZiBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQiDQoN CklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElF VEYgSVBSIHJ1bGVzDQooc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9y ZSBkZXRhaWxzKT8NCg0KICAgSWYgeWVzIHRvIHRoZSBhYm92ZSwgcGxlYXNlIHN0YXRlIGVpdGhl cjoNCg0KICAiWWVzLCB0aGUgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdp dGggSUVURiBJUFIgcnVsZXMiDQogIG9yDQogICJObywgdGhlIElQUiBoYXMgbm90IGJlZW4gZGlz Y2xvc2VkIg0KDQogIElmIHlvdSBhbnN3ZXIgbm8sIHBsZWFzZSBwcm92aWRlIGFueSBhZGRpdGlv bmFsIGRldGFpbHMgeW91IHRoaW5rDQogIGFwcHJvcHJpYXRlLg0KDQpJZiB5b3UgYXJlIGxpc3Rl ZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgYW5zd2VyIHRoZQ0K YWJvdmUgYnkgcmVzcG9uZGluZyB0byB0aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBv ciBub3QgeW91IGFyZQ0KYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4gIFRoaXMgZG9jdW1lbnQg d2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dA0Kc3RhZ2UgdW50aWwgYSByZXNwb25zZSBoYXMg YmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBsaXN0ZWQNCmNvbnRyaWJ1dG9yLiAg Tk9URTogVEhJUyBBUFBMSUVTIFRPIEFMTCBPRiBZT1UgTElTVEVEIElOIFRISVMNCk1FU1NBR0Un UyBUTyBMSU5FUy4NCg0KSWYgeW91IGFyZSBvbiB0aGUgQ0NBTVAgV0cgZW1haWwgbGlzdCBidXQg YXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yDQpjb250cmlidXRvciwgd2UgcmVtaW5kIHlv dSBvZiB5b3VyIG9ibGlnYXRpb25zIHVuZGVyIHRoZSBJRVRGIElQUiBydWxlcw0Kd2hpY2ggZW5j b3VyYWdlcyB5b3UgdG8gbm90aWZ5IHRoZSBJRVRGIGlmIHlvdSBhcmUgYXdhcmUgb2YgSVBSIG9m DQpvdGhlcnMgb24gYW4gSUVURiBjb250cmlidXRpb24sIG9yIHRvIHJlZnJhaW4gZnJvbSBwYXJ0 aWNpcGF0aW5nIGluIGFueQ0KY29udHJpYnV0aW9uIG9yIGRpc2N1c3Npb24gcmVsYXRlZCB0byB5 b3VyIHVuZGlzY2xvc2VkIElQUi4gIEZvciBtb3JlDQppbmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0 aGUgUkZDcyBsaXN0ZWQgYWJvdmUgYW5kDQpodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9ncm91 cC9pZXNnL3RyYWMvd2lraS9JbnRlbGxlY3R1YWxQcm9wZXJ0eS4NCg0KVGhhbmsgeW91LA0KQ0NB TVAgV0cgQ2hhaXJzDQoNClBTIFBsZWFzZSBpbmNsdWRlIGFsbCBsaXN0ZWQgaW4gdGhlIGhlYWRl cnMgb2YgdGhpcyBtZXNzYWdlIGluIHlvdXINCnJlc3BvbnNlLg0K From huawei.danli@huawei.com Thu Jul 18 17:46:11 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 708DC21E8104 for ; Thu, 18 Jul 2013 17:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.788 X-Spam-Level: ** X-Spam-Status: No, score=2.788 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNqxjyhZ4rYQ for ; Thu, 18 Jul 2013 17:46:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id EA69121E80E8 for ; Thu, 18 Jul 2013 17:46:06 -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 ATO69707; Fri, 19 Jul 2013 00:46:02 +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; Fri, 19 Jul 2013 01:45:03 +0100 Received: from SZXEML458-HUB.china.huawei.com (10.82.67.201) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 19 Jul 2013 01:46:01 +0100 Received: from szxeml555-mbx.china.huawei.com ([169.254.1.249]) by SZXEML458-HUB.china.huawei.com ([10.82.67.201]) with mapi id 14.01.0323.007; Fri, 19 Jul 2013 08:45:49 +0800 From: "Lidan (Dan)" To: Lou Berger , "diego.caviglia@ericsson.com" , "anders.gavler@acreo.se" , "jonas.martensson@acreo.se" , "i-nishioka@cb.jp.nec.com" , "lyong@ciena.com" , "cyril.margaria@nsn.com" , "gregb@grotto-networking.com" , Leeyoung , "imajuku.wataru@lab.ntt.co.jp" Thread-Topic: Regarding IPR on draft-ietf-ccamp-rwa-info Thread-Index: AQHOg+mcqmeazfBiKkKc3QYPhCWrVZlrKmuw Date: Fri, 19 Jul 2013 00:45:48 +0000 Message-ID: <92A1F6CF27D54D4DA5364E59D892A02A5639235D@szxeml555-mbx.china.huawei.com> References: <51E83C26.2090302@labn.net> In-Reply-To: <51E83C26.2090302@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.73.151] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ccamp@ietf.org" Subject: [CCAMP] =?gb2312?b?tPC4tDogUmVnYXJkaW5nIElQUiBvbiBkcmFmdC1pZXRm?= =?gb2312?b?LWNjYW1wLXJ3YS1pbmZv?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 00:46:11 -0000 WWVzLCBJJ20gYXdhcmUgb2YgSVBScyB0aGF0IGFwcGx5IHRvIHRoaXMgZHJhZnQgJiB0aGUgSVBS cyBoYXZlIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyBh cyBmb2xsb3dzOg0KDQpodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvaXByL3NlYXJjaC8/b3B0 aW9uPWRvY3VtZW50X3NlYXJjaCZpZF9kb2N1bWVudF90YWc9ZHJhZnQtaWV0Zi1jY2FtcC1yd2Et aW5mbw0KDQpUaGFua3MsDQoNCkRhbg0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogTG91 IEJlcmdlciBbbWFpbHRvOmxiZXJnZXJAbGFibi5uZXRdIA0Kt6LLzcqxvOQ6IDIwMTPE6jfUwjE5 yNUgMzowNA0KytW8/sjLOiBkaWVnby5jYXZpZ2xpYUBlcmljc3Nvbi5jb207IGFuZGVycy5nYXZs ZXJAYWNyZW8uc2U7IGpvbmFzLm1hcnRlbnNzb25AYWNyZW8uc2U7IGktbmlzaGlva2FAY2IuanAu bmVjLmNvbTsgbHlvbmdAY2llbmEuY29tOyBjeXJpbC5tYXJnYXJpYUBuc24uY29tOyBncmVnYkBn cm90dG8tbmV0d29ya2luZy5jb207IExlZXlvdW5nOyBMaWRhbiAoRGFuKTsgaW1hanVrdS53YXRh cnVAbGFiLm50dC5jby5qcA0Ks63LzTogY2NhbXBAaWV0Zi5vcmcNCtb3zOI6IFJlZ2FyZGluZyBJ UFIgb24gZHJhZnQtaWV0Zi1jY2FtcC1yd2EtaW5mbw0KDQpBdXRob3JzLCBDb250cmlidXRvcnMs IChDQ0FNUCkNCg0KQXMgcGFydCBvZiB0aGUgcHJlcGFyYXRpb24gZm9yIFdHIExhc3QgQ2FsbDoN Cg0KQXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byBkcmFmdCBpZGVudGlm aWVkIGFib3ZlPw0KDQogIFBsZWFzZSBzdGF0ZSBlaXRoZXI6DQoNCiAgIk5vLCBJJ20gbm90IGF3 YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQiDQogIG9yDQogICJZZXMs IEknbSBhd2FyZSBvZiBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQiDQoNCklmIHNvLCBo YXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1 bGVzDQooc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxz KT8NCg0KICAgSWYgeWVzIHRvIHRoZSBhYm92ZSwgcGxlYXNlIHN0YXRlIGVpdGhlcjoNCg0KICAi WWVzLCB0aGUgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJ UFIgcnVsZXMiDQogIG9yDQogICJObywgdGhlIElQUiBoYXMgbm90IGJlZW4gZGlzY2xvc2VkIg0K DQogIElmIHlvdSBhbnN3ZXIgbm8sIHBsZWFzZSBwcm92aWRlIGFueSBhZGRpdGlvbmFsIGRldGFp bHMgeW91IHRoaW5rDQogIGFwcHJvcHJpYXRlLg0KDQpJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRv Y3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgYW5zd2VyIHRoZQ0KYWJvdmUgYnkg cmVzcG9uZGluZyB0byB0aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91 IGFyZQ0KYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4gIFRoaXMgZG9jdW1lbnQgd2lsbCBub3Qg YWR2YW5jZSB0byB0aGUgbmV4dA0Kc3RhZ2UgdW50aWwgYSByZXNwb25zZSBoYXMgYmVlbiByZWNl aXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBsaXN0ZWQNCmNvbnRyaWJ1dG9yLiAgTk9URTogVEhJ UyBBUFBMSUVTIFRPIEFMTCBPRiBZT1UgTElTVEVEIElOIFRISVMNCk1FU1NBR0UnUyBUTyBMSU5F Uy4NCg0KSWYgeW91IGFyZSBvbiB0aGUgQ0NBTVAgV0cgZW1haWwgbGlzdCBidXQgYXJlIG5vdCBs aXN0ZWQgYXMgYW4gYXV0aG9yIG9yDQpjb250cmlidXRvciwgd2UgcmVtaW5kIHlvdSBvZiB5b3Vy IG9ibGlnYXRpb25zIHVuZGVyIHRoZSBJRVRGIElQUiBydWxlcw0Kd2hpY2ggZW5jb3VyYWdlcyB5 b3UgdG8gbm90aWZ5IHRoZSBJRVRGIGlmIHlvdSBhcmUgYXdhcmUgb2YgSVBSIG9mDQpvdGhlcnMg b24gYW4gSUVURiBjb250cmlidXRpb24sIG9yIHRvIHJlZnJhaW4gZnJvbSBwYXJ0aWNpcGF0aW5n IGluIGFueQ0KY29udHJpYnV0aW9uIG9yIGRpc2N1c3Npb24gcmVsYXRlZCB0byB5b3VyIHVuZGlz Y2xvc2VkIElQUi4gIEZvciBtb3JlDQppbmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgUkZDcyBs aXN0ZWQgYWJvdmUgYW5kDQpodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9ncm91cC9pZXNnL3Ry YWMvd2lraS9JbnRlbGxlY3R1YWxQcm9wZXJ0eS4NCg0KVGhhbmsgeW91LA0KQ0NBTVAgV0cgQ2hh aXJzDQoNClBTIFBsZWFzZSBpbmNsdWRlIGFsbCBsaXN0ZWQgaW4gdGhlIGhlYWRlcnMgb2YgdGhp cyBtZXNzYWdlIGluIHlvdXINCnJlc3BvbnNlLg0K From harai@nict.go.jp Thu Jul 18 23:27:37 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9901C11E80E6 for ; Thu, 18 Jul 2013 23:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.355 X-Spam-Level: X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kNceqbEf6o5m for ; Thu, 18 Jul 2013 23:27:32 -0700 (PDT) Received: from ns2.nict.go.jp (ns2.nict.go.jp [IPv6:2001:df0:232:300::2]) by ietfa.amsl.com (Postfix) with ESMTP id B89C511E8178 for ; Thu, 18 Jul 2013 23:27:23 -0700 (PDT) Received: from gw2.nict.go.jp (gw2 [133.243.18.251]) by ns2.nict.go.jp with ESMTP id r6J6R0lX017029; Fri, 19 Jul 2013 15:27:00 +0900 (JST) Received: from gw2.nict.go.jp (localhost [127.0.0.1]) by gw2.nict.go.jp with ESMTP id r6J6R0iQ012356; Fri, 19 Jul 2013 15:27:00 +0900 (JST) Received: from mail2.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw2.nict.go.jp with ESMTP id r6J6R0FO012353; Fri, 19 Jul 2013 15:27:00 +0900 (JST) Received: from mail2.nict.go.jp (localhost [127.0.0.1]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 2D6262C33E; Fri, 19 Jul 2013 15:27:00 +0900 (JST) Received: from localhost (skigoggle.nict.go.jp [133.243.146.51]) by mail2.nict.go.jp (NICT Mail) with ESMTP id 23CC32C2DE; Fri, 19 Jul 2013 15:27:00 +0900 (JST) Date: Fri, 19 Jul 2013 15:27:00 +0900 (JST) Message-Id: <20130719.152700.653026525707352072.harai@nict.go.jp> To: lberger@labn.net From: Hiroaki Harai In-Reply-To: <51E83C64.2040105@labn.net> References: <51E83C64.2040105@labn.net> X-Mailer: Mew version 6.3 on Emacs 23.2 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: guolintom@gmail.com, a.giorgetti@sssup.it, ccamp@ietf.org, nick@sssup.it, jyf@bupt.edu.cn Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-wson-signaling X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 06:27:37 -0000 No, I'm not aware of any IPR that applies to this draft. Hiroaki Harai From: Lou Berger Subject: Regarding IPR on draft-ietf-ccamp-wson-signaling Date: Thu, 18 Jul 2013 15:05:08 -0400 Message-ID: <51E83C64.2040105@labn.net> > Authors, Contributors, (CCAMP) > > As part of the preparation for WG Last Call: > > Are you aware of any IPR that applies to draft identified above? > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? > > If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS > MESSAGE'S TO LINES. > > If you are on the CCAMP WG email list but are not listed as an author or > contributor, we remind you of your obligations under the IETF IPR rules > which encourages you to notify the IETF if you are aware of IPR of > others on an IETF contribution, or to refrain from participating in any > contribution or discussion related to your undisclosed IPR. For more > information, please see the RFCs listed above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > CCAMP WG Chairs > > PS Please include all listed in the headers of this message in your > response. From daniel@olddog.co.uk Fri Jul 19 00:42:35 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B7421F9970 for ; Fri, 19 Jul 2013 00:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GFFHuaaaTC0 for ; Fri, 19 Jul 2013 00:42:30 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id E343521F99C1 for ; Fri, 19 Jul 2013 00:42:29 -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 r6J7ar0K011674; Fri, 19 Jul 2013 08:36:54 +0100 Received: from Mal (host86-133-205-106.range86-133.btcentralplus.com [86.133.205.106]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6J7aqhl011651; Fri, 19 Jul 2013 08:36:52 +0100 From: "Daniel King" To: "'Lou Berger'" , , , , , , , , , , References: <51E83C64.2040105@labn.net> In-Reply-To: <51E83C64.2040105@labn.net> Date: Fri, 19 Jul 2013 08:37:00 +0100 Message-ID: <00f201ce8452$c1da7fb0$458f7f10$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQJhoMejF5TFQbVG4TyeEV+Ofjtw2phFY+CQ Content-Language: en-gb Cc: ccamp@ietf.org Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-wson-signaling X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 07:42:35 -0000 Hi Lou, All. No, I'm not aware of any IPR that applies to this draft. Br, Dan. -----Original Message----- From: Lou Berger [mailto:lberger@labn.net] Sent: 18 July 2013 20:05 To: gregb@grotto-networking.com; nick@sssup.it; a.giorgetti@sssup.it; guolintom@gmail.com; harai@nict.go.jp; jyf@bupt.edu.cn; daniel@olddog.co.uk; leeyoung@huawei.com; xsg@nict.go.jp; giomarti@cisco.com Cc: ccamp@ietf.org Subject: Regarding IPR on draft-ietf-ccamp-wson-signaling Authors, Contributors, (CCAMP) As part of the preparation for WG Last Call: Are you aware of any IPR that applies to draft identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the CCAMP WG email list but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, CCAMP WG Chairs PS Please include all listed in the headers of this message in your response. From daniele.ceccarelli@ericsson.com Fri Jul 19 01:06:36 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD42D11E81FF for ; Fri, 19 Jul 2013 01:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.512 X-Spam-Level: X-Spam-Status: No, score=-3.512 tagged_above=-999 required=5 tests=[AWL=-0.913, 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 eCtBW5VFcj6f for ; Fri, 19 Jul 2013 01:06:31 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 1C49011E81F7 for ; Fri, 19 Jul 2013 01:06:30 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-59-51e8f38524fc Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 74.DE.11907.583F8E15; Fri, 19 Jul 2013 10:06:29 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.30]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.02.0328.009; Fri, 19 Jul 2013 10:06:29 +0200 From: Daniele Ceccarelli To: Lou Berger , Diego Caviglia , "anders.gavler@acreo.se" , "jonas.martensson@acreo.se" , "i-nishioka@cb.jp.nec.com" , "pierre.peloso@alcatel-lucent.com" , "cyril.margaria@nsn.com" , "giomarti@cisco.com" , "ggalimbe@cisco.com" , "lyong@ciena.com" , "gregb@grotto-networking.com" , "leeyoung@huawei.com" , "danli@huawei.com" , "imajuku.wataru@lab.ntt.co.jp" , "hanjianrui@huawei.com" Thread-Topic: Regarding IPR on draft-ietf-ccamp-rwa-wson-encode Thread-Index: AQHOg+munRK//QDBMkuv0neXhvOYj5lrpahQ Date: Fri, 19 Jul 2013 08:06:29 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE481088A9@ESESSMB301.ericsson.se> References: <51E83C4F.8090502@labn.net> In-Reply-To: <51E83C4F.8090502@labn.net> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKIsWRmVeSWpSXmKPExsUyM+JvrW7r5xeBBrMnWFkcOS9p8WTODRaL id/Xslu8ej6B0eLRo4+sFiuamhktOl40Mlv83N/LbLF08VImi8NLbCwWX5C26Gh+y2IxbZ6r xbYVL1gszrw5xejA7/Hh+Ek2j9Zne1k9Zq/cwORx9uY/Fo8pvzeyesx6fZDVo+XIW1aPJUt+ Mnk0v3jO4vFhUzObx8/1V9kDuKO4bFJSczLLUov07RK4Mv7t3Mda8FOo4vy678wNjPP4uxg5 OSQETCRW3epjgrDFJC7cW8/WxcjFISRwlFHixJ89rCAJIYHFjBKzbxt0MXJwsAlYSTw55ANS IyLQwCbRu38PM0gNs4CqRNv1U2D1wgJ2EhPu/mUEqRcRsJd4MbsGJCwiYCTx9cwVRhCbBah8 0qe5YOW8At4Svx59ZYdYpS5xd18rG4jNKaAh0fj2Odh4RgFZiQm7FzFCrBKXuPVkPtTNAhJL 9pxnhrBFJV4+/scKslZCQFFieb8cRLmexI2pU9ggbG2JZQtfM0OsFZQ4OfMJywRGsVlIps5C 0jILScssJC0LGFlWMXIUpxYn5aYbGWxiBEb9wS2/LXYwXv5rc4hRmoNFSZx3i96ZQCGB9MSS 1OzU1ILUovii0pzU4kOMTBycUg2MYb/lWdabLVshXr+Ei+/EhnQejaDgz66lK2fn1itwPGav 8rZgcL6x+HKs7JXtK79bJz7em3Vsx/cfSz5MvS/lE3pDqjm0we5t5fkJu863a7HxLXEWfu0j y/2+RMTz9Nle5/CczzeCDs6Vuyliv2g1j/0rVvMHm369rGIRPrean9H9xPdq+2oFJZbijERD Leai4kQAoloJY8gCAAA= Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-rwa-wson-encode X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 08:06:36 -0000 No, I'm not aware of any IPR that applies to this draft BR Daniele > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: gioved=EC 18 luglio 2013 21:05 > To: Diego Caviglia; anders.gavler@acreo.se; jonas.martensson@acreo.se; i- > nishioka@cb.jp.nec.com; pierre.peloso@alcatel-lucent.com; > cyril.margaria@nsn.com; giomarti@cisco.com; ggalimbe@cisco.com; > lyong@ciena.com; Daniele Ceccarelli; gregb@grotto-networking.com; > leeyoung@huawei.com; danli@huawei.com; imajuku.wataru@lab.ntt.co.jp; > hanjianrui@huawei.com > Cc: ccamp@ietf.org > Subject: Regarding IPR on draft-ietf-ccamp-rwa-wson-encode >=20 > Authors, Contributors, (CCAMP) >=20 > As part of the preparation for WG Last Call: >=20 > Are you aware of any IPR that applies to draft identified above? >=20 > Please state either: >=20 > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules (see= RFCs > 3979, 4879, 3669 and 5378 for more details)? >=20 > If yes to the above, please state either: >=20 > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" >=20 > If you answer no, please provide any additional details you think > appropriate. >=20 > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next st= age > until a response has been received from each author and listed contributo= r. > NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. >=20 > If you are on the CCAMP WG email list but are not listed as an author or > contributor, we remind you of your obligations under the IETF IPR rules > which encourages you to notify the IETF if you are aware of IPR of others= on > an IETF contribution, or to refrain from participating in any contributio= n or > discussion related to your undisclosed IPR. For more information, please= see > the RFCs listed above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >=20 > Thank you, > CCAMP WG Chairs >=20 > PS Please include all listed in the headers of this message in your respo= nse. From cyril.margaria@coriant.com Fri Jul 19 01:09:05 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC6A211E81D5 for ; Fri, 19 Jul 2013 01:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.348 X-Spam-Level: X-Spam-Status: No, score=-4.348 tagged_above=-999 required=5 tests=[AWL=-1.749, 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 Q8RkYDGWsxG0 for ; Fri, 19 Jul 2013 01:08:59 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0251.outbound.messaging.microsoft.com [213.199.154.251]) by ietfa.amsl.com (Postfix) with ESMTP id 2D63D21F9684 for ; Fri, 19 Jul 2013 01:08:59 -0700 (PDT) Received: from mail156-db9-R.bigfish.com (10.174.16.232) by DB9EHSOBE033.bigfish.com (10.174.14.96) with Microsoft SMTP Server id 14.1.225.22; Fri, 19 Jul 2013 08:08:58 +0000 Received: from mail156-db9 (localhost [127.0.0.1]) by mail156-db9-R.bigfish.com (Postfix) with ESMTP id 1A0BA160223; Fri, 19 Jul 2013 08:08:58 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.53; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0411HT002.eurprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -2 X-BigFish: PS-2(zzc89bh1432I31c5Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzzz2fh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail156-db9: domain of coriant.com designates 157.56.253.53 as permitted sender) client-ip=157.56.253.53; envelope-from=cyril.margaria@coriant.com; helo=DB3PRD0411HT002.eurprd04.prod.outlook.com ; .outlook.com ; Received: from mail156-db9 (localhost.localdomain [127.0.0.1]) by mail156-db9 (MessageSwitch) id 1374221335899803_23446; Fri, 19 Jul 2013 08:08:55 +0000 (UTC) Received: from DB9EHSMHS011.bigfish.com (unknown [10.174.16.251]) by mail156-db9.bigfish.com (Postfix) with ESMTP id CC23812008E; Fri, 19 Jul 2013 08:08:55 +0000 (UTC) Received: from DB3PRD0411HT002.eurprd04.prod.outlook.com (157.56.253.53) by DB9EHSMHS011.bigfish.com (10.174.14.21) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 19 Jul 2013 08:08:55 +0000 Received: from DB3PRD0411MB427.eurprd04.prod.outlook.com ([169.254.6.251]) by DB3PRD0411HT002.eurprd04.prod.outlook.com ([10.255.73.37]) with mapi id 14.16.0329.000; Fri, 19 Jul 2013 08:08:55 +0000 From: "Margaria, Cyril (Coriant - DE/Munich)" To: ext Leeyoung , "Giovanni Martinelli (giomarti)" , "Margaria, Cyril (NSN - DE/Munich)" Thread-Topic: [CCAMP] Comments on draft-ietf-ccamp-wson-signaling-05 Thread-Index: Ac4f9fHWZRxXufGDRkGdO9Y5p2fdaAAeYW8AAAdWyjAY8n5cMA== Date: Fri, 19 Jul 2013 08:08:53 +0000 Message-ID: <523C37072C291347B9730C9291CCA07D0C658B@DB3PRD0411MB427.eurprd04.prod.outlook.com> References: <8DC6547C806B644F998A0566E79E15920F7DFFCC@DEMUMBX006.nsn-intra.net> <0D7F95913F470A4B83AB5F5833A4390D293158@xmb-rcd-x14.cisco.com> <7AEB3D6833318045B4AE71C2C87E8E17291183C3@dfweml511-mbs.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E17291183C3@dfweml511-mbs.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [62.159.77.167] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: coriant.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: CCAMP , "draft-ietf-ccamp-wson-signaling@tools.ietf.org" Subject: Re: [CCAMP] Comments on draft-ietf-ccamp-wson-signaling-05 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 08:09:06 -0000 Dear Authors,=20 I checked the revision -06 for the updates, I think you forgot one, and I h= ave minors comments > > I have the following comments on draft-ietf-ccamp-wson-signaling-05: > > > > Comment 1: > > The document considers bidirection RB set and limit 2 RBInformation > per hop. However per RFC3473 section 8.1.1 and RFC3471, using > different interface id for the upstream and downstream direction. The > current definition does not support that. > > The following change would allow it. > > Section 4.2 > > > > OLD: > > "If more than two objects are encountered, two > > MUST be processed and the rest SHOULD be ignored." > > > > NEW: > > "If more than two objects per direction are encountered, two > > MUST be processed and the rest SHOULD be ignored." > > >=20 > GM> ok >=20 [[Margaria.C]]=20 This was partially updated it seems: Section 4.3 "If more than two objects are encountered, two MUST be processed and the rest SHOULD be ignored." --> this is in the section of the RB information sub tlv, does this refers = to the WSON_signaling object or RBInformation? --> from the text below and to address my comment, I would say=20 --> WSON_signaling, it would be more clear to state it explicitly > > Section 4 > > > > OLD: > > "The usage of object for the bidirectional case is > > the same as per unidirectional. When an intermediate node uses > > information from this object to instruct a node about wavelength > > regeneration, the same information applies to both downstream and > > upstream directions." > > > > NEW: > > "The usage of object for the bidirectional case is > > the same as per unidirectional. When an intermediate node uses > > information from this object to instruct a node about wavelength > > regeneration, the same regeneration information should applies to > both downstream and > > upstream directions." >=20 > GM> I assume you meant section 5. Ok. Just wondering if worth spending > GM> some words on usage of I|E flags vs directions >=20 > YOUNG>> Simple grammar check with your suggested text: >=20 > OLD: "...should applies to both downstream and upstream directions." > NEW: "...should apply to both downstream and upstream directions." >=20 [[Margaria.C]] OK > > > > Comment-2: Section 4.2 : > > I think the restriction on the RB Set identifier processing is maybe > too strong. > > I would like to suggest the following modification: > > > > remove > > "RB Set Field MAY contain more than one RB Indetifier. Only the first > > one MUST be processed, the others SHOULD be ignored. > > " > > In all case, consider the Typo >=20 > GM> fine with me no problem in relaxing constrain (btw thx for catching > GM> the typo) >=20 [[Margaria.C]] the typo (and restriction) are still present=20 > > Comment-3 : > > The restriction on the OIC and other parameters are also too strong, > only considering one does not allows signaling to pick the one RB among > several. > > Please consider the following change > > Remove > > " The Optical Interface Class List, Input Bit Range List and > > Processing Capability List MAY contain more than one element. Only > > the first MUST be processed, the others SHOULD be ignored. > > " > > >=20 > GM> same as comment above [[Margaria.C]] OK Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria From giomarti@cisco.com Fri Jul 19 01:37:30 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94C6921E810A for ; Fri, 19 Jul 2013 01:37:29 -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 GnRJvQv63YaU for ; Fri, 19 Jul 2013 01:37:24 -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 4126E21E80E9 for ; Fri, 19 Jul 2013 01:37:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1883; q=dns/txt; s=iport; t=1374223044; x=1375432644; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=e7N8aBiD3JEVPbYgsH//wQuWR9Ix3KqhiTttSCa5bKI=; b=CL6Xnl+XSg1LWFAlFYtg4mfd/7VV/arASZpLq6l9Jk8bZHMqIRUMOF1n jykUonHsf2p57oEVvQirQ7ayp9JPG1fpM2pyigahHzlgCvz8AzNgfB+Yy Z/1LFL+TNByxhf5MG6e7Ocs1cjc+p3na3Ec3aXLeh06+rX57mAH9xBXff Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAEf66FGtJV2b/2dsb2JhbABagwY1UMBFgQ8WdIIkAQEBAwF0BQULAgEIDhQkMiUCBA4FCIgCBgy2KI5NgRExB4MObgOIcJAWkCSDEoFxOQ X-IronPort-AV: E=Sophos;i="4.89,700,1367971200"; d="scan'208";a="236837758" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 19 Jul 2013 08:37:23 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6J8bNX5015145 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Jul 2013 08:37:23 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.194]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.02.0318.004; Fri, 19 Jul 2013 03:37:22 -0500 From: "Giovanni Martinelli (giomarti)" To: Lou Berger Thread-Topic: Regarding IPR on draft-ietf-ccamp-wson-signaling Thread-Index: AQHOg+m6pf05eNMfwUOo4ZenxUHza5lsAl0A Date: Fri, 19 Jul 2013 08:37:22 +0000 Message-ID: <0D7F95913F470A4B83AB5F5833A4390D0E1080A3@xmb-rcd-x14.cisco.com> References: <51E83C64.2040105@labn.net> In-Reply-To: <51E83C64.2040105@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.172.78] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" , "" , "" , "" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-wson-signaling X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 08:37:30 -0000 No, I'm not aware of any IPR that applies to this draft ~G On Jul 18, 2013, at 21:05 , Lou Berger wrote: > Authors, Contributors, (CCAMP) >=20 > As part of the preparation for WG Last Call: >=20 > Are you aware of any IPR that applies to draft identified above? >=20 > Please state either: >=20 > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? >=20 > If yes to the above, please state either: >=20 > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" >=20 > If you answer no, please provide any additional details you think > appropriate. >=20 > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS > MESSAGE'S TO LINES. >=20 > If you are on the CCAMP WG email list but are not listed as an author or > contributor, we remind you of your obligations under the IETF IPR rules > which encourages you to notify the IETF if you are aware of IPR of > others on an IETF contribution, or to refrain from participating in any > contribution or discussion related to your undisclosed IPR. For more > information, please see the RFCs listed above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >=20 > Thank you, > CCAMP WG Chairs >=20 > PS Please include all listed in the headers of this message in your > response. From giomarti@cisco.com Fri Jul 19 01:42:19 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF2D11E8249 for ; Fri, 19 Jul 2013 01:42:19 -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 GOuHsI6x7alX for ; Fri, 19 Jul 2013 01:42:14 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 19DD011E81F3 for ; Fri, 19 Jul 2013 01:42:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1883; q=dns/txt; s=iport; t=1374223334; x=1375432934; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ZpBpTwULFbi0tPa1mr/ljroehFteubGVV7QoHE4O5GM=; b=RNEYaJNXO3sYvrGIANaFo1JzaX56sVVujkHNMztl5oQjtLzMVKP1sQ2+ vhToDeWkl7Icam163etWKqm6N34dLaFaa1NskstiAiMZcW++wgAeiOTuu U9RbLlSQuhkxPACLfmdlpecQp8xgXOo9tR0SuS90MtN6Li8yJy/6H7h63 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAH366FGtJXG//2dsb2JhbABagwY1UMBFgQ8WdIIkAQEBAwF0BQULAgEIDhQkMiUCBA4FCIgCBgy2KI5NgRExB4MObgOIcJAWkCSDEoFxOQ X-IronPort-AV: E=Sophos;i="4.89,700,1367971200"; d="scan'208";a="236813839" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 19 Jul 2013 08:42:12 +0000 Received: from xhc-rcd-x11.cisco.com (xhc-rcd-x11.cisco.com [173.37.183.85]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6J8gCue024381 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Jul 2013 08:42:12 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.194]) by xhc-rcd-x11.cisco.com ([173.37.183.85]) with mapi id 14.02.0318.004; Fri, 19 Jul 2013 03:42:11 -0500 From: "Giovanni Martinelli (giomarti)" To: Lou Berger Thread-Topic: Regarding IPR on draft-ietf-ccamp-rwa-wson-encode Thread-Index: AQHOg+mtjYM5KIzLWkGvuJjUIP1LR5lsA7aA Date: Fri, 19 Jul 2013 08:42:11 +0000 Message-ID: <0D7F95913F470A4B83AB5F5833A4390D0E1080BD@xmb-rcd-x14.cisco.com> References: <51E83C4F.8090502@labn.net> In-Reply-To: <51E83C4F.8090502@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.172.78] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <68F4201EAC40C347949A39F5DBA31875@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" , "" , "" , "" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-rwa-wson-encode X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 08:42:19 -0000 No, I'm not aware of any IPR that applies to this draft ~G On Jul 18, 2013, at 21:04 , Lou Berger wrote: > Authors, Contributors, (CCAMP) >=20 > As part of the preparation for WG Last Call: >=20 > Are you aware of any IPR that applies to draft identified above? >=20 > Please state either: >=20 > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? >=20 > If yes to the above, please state either: >=20 > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" >=20 > If you answer no, please provide any additional details you think > appropriate. >=20 > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS > MESSAGE'S TO LINES. >=20 > If you are on the CCAMP WG email list but are not listed as an author or > contributor, we remind you of your obligations under the IETF IPR rules > which encourages you to notify the IETF if you are aware of IPR of > others on an IETF contribution, or to refrain from participating in any > contribution or discussion related to your undisclosed IPR. For more > information, please see the RFCs listed above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >=20 > Thank you, > CCAMP WG Chairs >=20 > PS Please include all listed in the headers of this message in your > response. From giomarti@cisco.com Fri Jul 19 01:44:04 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 940BB11E8249 for ; Fri, 19 Jul 2013 01:44:04 -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 WngHhjs8RTea for ; Fri, 19 Jul 2013 01:43:48 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 069F711E81F3 for ; Fri, 19 Jul 2013 01:43:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2028; q=dns/txt; s=iport; t=1374223428; x=1375433028; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zTk/OqmvUT4dL5036dYosafXEUnq3ZHz+eER8hUr45U=; b=QIM4Apc8leOSJC/gQV8n7yQzNE8vMdEkWRk3sfrM8f2JYB5f/UaTIC0c YmkJJ4myS+QnHBM4TUFyjr/lorwiNZXRZA+mxltw3LwpG/OEIzdWOAfjw QepV8ss+fZIK/J9hnAiVoo5NoYGFYrbSKN7hqwQ2ZadLrVgUeY2EARRU7 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAOv76FGtJV2d/2dsb2JhbABagwY1UMBFgQ8WdIIkAQEBAwF0BQULAgEIDhQkMiUCBA4FCIgCBgy2KY5NgQ8CMQeDDm4DiHCQFpAkgxKBcTk X-IronPort-AV: E=Sophos;i="4.89,700,1367971200"; d="scan'208";a="236825116" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 19 Jul 2013 08:43:45 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6J8hj1Z001884 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Jul 2013 08:43:45 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.194]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Fri, 19 Jul 2013 03:43:45 -0500 From: "Giovanni Martinelli (giomarti)" To: Lou Berger Thread-Topic: Regarding IPR on draft-ietf-ccamp-general-constraint-encode Thread-Index: AQHOg+mfh4pH5uMu00a56/JyOYzo9JlsBCSA Date: Fri, 19 Jul 2013 08:43:44 +0000 Message-ID: <0D7F95913F470A4B83AB5F5833A4390D0E1080D7@xmb-rcd-x14.cisco.com> References: <51E83C33.7010802@labn.net> In-Reply-To: <51E83C33.7010802@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.172.78] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3A1A71F6A8D5454C8402CBE0ABB86832@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" , "" , "" , "" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-general-constraint-encode X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 08:44:04 -0000 Yes, the IPR has been disclosed in compliance with IETF IPR rules https://datatracker.ietf.org/ipr/search/?option=3Ddocument_search&document_= search=3Ddraft-ietf-ccamp-general-constraint-encode ~G On Jul 18, 2013, at 21:04 , Lou Berger wrote: > Authors, Contributors, (CCAMP) >=20 > As part of the preparation for WG Last Call: >=20 > Are you aware of any IPR that applies to draft identified above? >=20 > Please state either: >=20 > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? >=20 > If yes to the above, please state either: >=20 > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" >=20 > If you answer no, please provide any additional details you think > appropriate. >=20 > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS > MESSAGE'S TO LINES. >=20 > If you are on the CCAMP WG email list but are not listed as an author or > contributor, we remind you of your obligations under the IETF IPR rules > which encourages you to notify the IETF if you are aware of IPR of > others on an IETF contribution, or to refrain from participating in any > contribution or discussion related to your undisclosed IPR. For more > information, please see the RFCs listed above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >=20 > Thank you, > CCAMP WG Chairs >=20 > PS Please include all listed in the headers of this message in your > response. From diego.caviglia@ericsson.com Fri Jul 19 02:25:51 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902E111E80FE for ; Fri, 19 Jul 2013 02:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHTawp79H0hj for ; Fri, 19 Jul 2013 02:25:46 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 79F0211E80F0 for ; Fri, 19 Jul 2013 02:25:45 -0700 (PDT) X-AuditID: c1b4fb2d-b7f586d000001a55-51-51e90617709f Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 39.DA.06741.71609E15; Fri, 19 Jul 2013 11:25:44 +0200 (CEST) Received: from ESESSMB103.ericsson.se ([169.254.3.218]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Fri, 19 Jul 2013 11:25:43 +0200 From: Diego Caviglia To: Lou Berger , "anders.gavler@acreo.se" , "jonas.martensson@acreo.se" , "i-nishioka@cb.jp.nec.com" , "pierre.peloso@alcatel-lucent.com" , "cyril.margaria@nsn.com" , "giomarti@cisco.com" , "ggalimbe@cisco.com" , "lyong@ciena.com" , Daniele Ceccarelli , "gregb@grotto-networking.com" , "leeyoung@huawei.com" , "danli@huawei.com" , "imajuku.wataru@lab.ntt.co.jp" , "hanjianrui@huawei.com" Thread-Topic: Regarding IPR on draft-ietf-ccamp-rwa-wson-encode Thread-Index: AQHOg+mtRN7rOjL8fEC5W/5a11yc0ZlrvAgg Date: Fri, 19 Jul 2013 09:25:42 +0000 Message-ID: <4E9BAD336C18BD49A429157A855607F11C3B7299@ESESSMB103.ericsson.se> References: <51E83C4F.8090502@labn.net> In-Reply-To: <51E83C4F.8090502@labn.net> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKIsWRmVeSWpSXmKPExsUyM+Jvra4E28tAg+alnBZHzktaPJlzg8Vi 4ve17Bavnk9gtHj06COrxYqmZkaLjheNzBY/9/cyWyxdvJTJ4vASG4vFF6QtOprfslhMm+dq sW3FCxaLM29OMTrwe3w4fpLNo/XZXlaP2Ss3MHmcvfmPxWPK742sHrNeH2T1aDnyltVjyZKf TB7NL56zeHzY1Mzm8XP9VfYA7igum5TUnMyy1CJ9uwSujANLjjMWvBGqWHostYFxOn8XIyeH hICJRNuyacwQtpjEhXvr2boYuTiEBA4zSjyfch/KWcIo8eHzY0aQKjYBI4ldHTNZQBIiAh1s Ei1/ZrODJJgFVCXarp9iBbGFBewkJtz9C9TAAVRkL/Fidg1IWASod+WTx2BhFqDy7tY8kDCv gK/ErIUXwKYICahL3N3XygZicwpoSDS+fQ52HKOArMSE3YsYITaJS9x6Mp8J4mgBiSV7zkM9 ICrx8vE/VghbUWLn2XZmiHo9iRtTp7BB2NoSyxa+ZobYKyhxcuYTlgmMYrOQjJ2FpGUWkpZZ SFoWMLKsYmTPTczMSS833MQIjPqDW37r7mA8dU7kEKM0B4uSOO8mvTOBQgLpiSWp2ampBalF 8UWlOanFhxiZODilGhgTIlf80DyZeFYrQVAn6POBUnGVMBfzQj57a6uEMsHd9dN/F7lc1hO/ P+VjV2tUT2Pi7RlHjk1Z81xMx/mpcPqv7WoTHzWdfq0zm4FzyYNjUX+2TNOs5HHhb1p6/OGV oishMeHGCet4V2lKuwXHHn2uuoVdoPXaJn1Xy9e9P+IWrdHW2ybP06rEUpyRaKjFXFScCAAS HzPUyAIAAA== Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-rwa-wson-encode X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 09:25:51 -0000 "No, I'm not aware of any IPR that applies to this draft" > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: gioved=EC 18 luglio 2013 21:05 > To: Diego Caviglia; anders.gavler@acreo.se; jonas.martensson@acreo.se; i- > nishioka@cb.jp.nec.com; pierre.peloso@alcatel-lucent.com; > cyril.margaria@nsn.com; giomarti@cisco.com; ggalimbe@cisco.com; > lyong@ciena.com; Daniele Ceccarelli; gregb@grotto-networking.com; > leeyoung@huawei.com; danli@huawei.com; imajuku.wataru@lab.ntt.co.jp; > hanjianrui@huawei.com > Cc: ccamp@ietf.org > Subject: Regarding IPR on draft-ietf-ccamp-rwa-wson-encode >=20 > Authors, Contributors, (CCAMP) >=20 > As part of the preparation for WG Last Call: >=20 > Are you aware of any IPR that applies to draft identified above? >=20 > Please state either: >=20 > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules (see= RFCs > 3979, 4879, 3669 and 5378 for more details)? >=20 > If yes to the above, please state either: >=20 > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" >=20 > If you answer no, please provide any additional details you think > appropriate. >=20 > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next st= age > until a response has been received from each author and listed contributo= r. > NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. >=20 > If you are on the CCAMP WG email list but are not listed as an author or > contributor, we remind you of your obligations under the IETF IPR rules > which encourages you to notify the IETF if you are aware of IPR of others= on > an IETF contribution, or to refrain from participating in any contributio= n or > discussion related to your undisclosed IPR. For more information, please= see > the RFCs listed above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >=20 > Thank you, > CCAMP WG Chairs >=20 > PS Please include all listed in the headers of this message in your respo= nse. From diego.caviglia@ericsson.com Fri Jul 19 02:26:14 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50CB221E813F for ; Fri, 19 Jul 2013 02:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.424 X-Spam-Level: X-Spam-Status: No, score=-4.424 tagged_above=-999 required=5 tests=[AWL=-1.825, 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 YpAfKt8Yb7m2 for ; Fri, 19 Jul 2013 02:26:09 -0700 (PDT) Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5C8BA21E80F2 for ; Fri, 19 Jul 2013 02:25:58 -0700 (PDT) X-AuditID: c1b4fb38-b7f456d000002e83-7c-51e90625f7c6 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id A0.58.11907.52609E15; Fri, 19 Jul 2013 11:25:57 +0200 (CEST) Received: from ESESSMB103.ericsson.se ([169.254.3.218]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.02.0328.009; Fri, 19 Jul 2013 11:25:56 +0200 From: Diego Caviglia To: Lou Berger , "anders.gavler@acreo.se" , "jonas.martensson@acreo.se" , "i-nishioka@cb.jp.nec.com" , "rrao@infinera.com" , "giomarti@cisco.com" , "remi.theillaud@marben-products.com" , "gregb@grotto-networking.com" , "ylee@huawei.com" , "danli@huawei.com" , "imajuku.wataru@lab.ntt.co.jp" , "hanjianrui@huawei.com" Thread-Topic: Regarding IPR on draft-ietf-ccamp-general-constraint-encode Thread-Index: AQHOg+mdrhDGPqx580S1XxvHolZJmplrvBkg Date: Fri, 19 Jul 2013 09:25:55 +0000 Message-ID: <4E9BAD336C18BD49A429157A855607F11C3B72A3@ESESSMB103.ericsson.se> References: <51E83C33.7010802@labn.net> In-Reply-To: <51E83C33.7010802@labn.net> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFIsWRmVeSWpSXmKPExsUyM+Jvra4q28tAg1un+SyOnJe0eDLnBovF q+cTGC1WNDUzWnS8aGS2+Lm/l9li6eKlTBaHl9hYLL4gbdHR/JbF4sHHyYwWz6+9Y7Lo/rqa 3YHX48Pxk2wes1duYPKY8nsjq8es1wdZPVqOvGX1WLLkJ5PHpReH2DyaXzxn8fiwqZnNY2rn aaYArigum5TUnMyy1CJ9uwSujFudT5gLNgtVXLz4iKWB8QlfFyMnh4SAiUTX3u3MELaYxIV7 69lAbCGBo4wS15pZuxi5gOwljBL3L1xjAkmwCRhJ7OqYyQKSEBF4xyLRsaaDFSTBLKAq0Xb9 FJgtLOAhMWvmCbBJIgKeEu0L26FsI4ltn/YzgtgsQPXdTf1gNq+Ar8TR/4/YITarS5ybuwVs GaeAhsTXNxvBbEYBWYkJuxcxQuwSl7j1ZD4TxNUCEkv2nIf6QFTi5eN/rBC2osTOs+3MEPV6 EjemTmGDsLUlli18zQyxV1Di5MwnLBMYxWYhGTsLScssJC2zkLQsYGRZxchRnFqclJtuZLCJ ERjfB7f8ttjBePmvzSFGaQ4WJXHeLXpnAoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwqrU9 9X3iaLznvmDhlmkMcyRsxZha/qkfURGT7vx5suqT0dKK/n1HNafqBdlvuW3jG/zxMWND11WO Xn5DRemJH7qsyncdWvx3bdu0bVaxWcvC1VZ+3/K7s7PkTPJfsY9TTY77fcm+W1hpcM9jgnXz xHtKn28wPAk0D/xWdOzVX9Y2sU6jZuUPSizFGYmGWsxFxYkAQI0qfr0CAAA= Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-general-constraint-encode X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 09:26:14 -0000 "No, I'm not aware of any IPR that applies to this draft" > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: gioved=EC 18 luglio 2013 21:04 > To: Diego Caviglia; anders.gavler@acreo.se; jonas.martensson@acreo.se; i- > nishioka@cb.jp.nec.com; rrao@infinera.com; giomarti@cisco.com; > remi.theillaud@marben-products.com; gregb@grotto-networking.com; > ylee@huawei.com; danli@huawei.com; imajuku.wataru@lab.ntt.co.jp; > hanjianrui@huawei.com > Cc: ccamp@ietf.org > Subject: Regarding IPR on draft-ietf-ccamp-general-constraint-encode >=20 > Authors, Contributors, (CCAMP) >=20 > As part of the preparation for WG Last Call: >=20 > Are you aware of any IPR that applies to draft identified above? >=20 > Please state either: >=20 > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules (see= RFCs > 3979, 4879, 3669 and 5378 for more details)? >=20 > If yes to the above, please state either: >=20 > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" >=20 > If you answer no, please provide any additional details you think > appropriate. >=20 > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next st= age > until a response has been received from each author and listed contributo= r. > NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. >=20 > If you are on the CCAMP WG email list but are not listed as an author or > contributor, we remind you of your obligations under the IETF IPR rules > which encourages you to notify the IETF if you are aware of IPR of others= on > an IETF contribution, or to refrain from participating in any contributio= n or > discussion related to your undisclosed IPR. For more information, please= see > the RFCs listed above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >=20 > Thank you, > CCAMP WG Chairs >=20 > PS Please include all listed in the headers of this message in your respo= nse. From diego.caviglia@ericsson.com Fri Jul 19 02:26:25 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48AD421E813A for ; Fri, 19 Jul 2013 02:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.337 X-Spam-Level: X-Spam-Status: No, score=-5.337 tagged_above=-999 required=5 tests=[AWL=0.912, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-wJ2gAmRbEw for ; Fri, 19 Jul 2013 02:26:20 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8644021E811F for ; Fri, 19 Jul 2013 02:26:09 -0700 (PDT) X-AuditID: c1b4fb2d-b7f586d000001a55-8a-51e9062be22e Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D1.EA.06741.B2609E15; Fri, 19 Jul 2013 11:26:03 +0200 (CEST) Received: from ESESSMB103.ericsson.se ([169.254.3.218]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0328.009; Fri, 19 Jul 2013 11:26:03 +0200 From: Diego Caviglia To: Lou Berger , "anders.gavler@acreo.se" , "jonas.martensson@acreo.se" , "i-nishioka@cb.jp.nec.com" , "lyong@ciena.com" , "cyril.margaria@nsn.com" , "gregb@grotto-networking.com" , "leeyoung@huawei.com" , "danli@huawei.com" , "imajuku.wataru@lab.ntt.co.jp" Thread-Topic: Regarding IPR on draft-ietf-ccamp-rwa-info Thread-Index: AQHOg+mYQHN3xKgrbUuUKFv+Uce7aZlrvCJw Date: Fri, 19 Jul 2013 09:26:02 +0000 Message-ID: <4E9BAD336C18BD49A429157A855607F11C3B72B3@ESESSMB103.ericsson.se> References: <51E83C26.2090302@labn.net> In-Reply-To: <51E83C26.2090302@labn.net> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJIsWRmVeSWpSXmKPExsUyM+Jvra4228tAg+MbRSyOnJe0eDLnBovF xO9r2S1ePZ/AaNHxopHZYunipUwWh5fYWCy+IG3R0fyWxWLaPFeLbStesDhwe3w4fpLNY/bK DUweZ2/+Y/GY9fogq0fLkbesHkuW/GTyaH7xnMXjw6ZmNo+f66+yB3BGcdmkpOZklqUW6dsl cGXcnnSCueCVYEXXvr2MDYzz+boYOTkkBEwkvuzqYoWwxSQu3FvP1sXIxSEkcJhRYv/uqcwg CSGBJYwSk8+Jg9hsAkYSuzpmsoAUiQj8YZZYtOE+G0iCWUBVou36KbBJwgLmEnP/rwSzRQQs JN4+PAtlG0nMP7qdEcRmAao/NncK2AJeAV+JllUX2SGWqUvc7VgBFucU0JB4/nMFWJxRQFZi wu5FjBC7xCVuPZnPBHG1gMSSPeeZIWxRiZeP/0F9oyix82w7M0S9nsSNqVOg7tSWWLbwNdRe QYmTM5+wTGAUm4Vk7CwkLbOQtMxC0rKAkWUVI3tuYmZOernhJkZg9B7c8lt3B+OpcyKHGKU5 WJTEeTfpnQkUEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwGjK5mTS+SHih2ZYfnbB5dk9x0tq Em9774nk2zdfkq3lc0XQskt7boRbGh7a4OzhUPPcd5rjjbrWmlWr16bde/2uYrL69olZId9m Zq1Z+df6tNbhS5Pcmn99Cblxo/v2j6CtvKedt+z5Y74ywPPXdp67EsmMjVx2BydnHLt9SkHC oLBMcs/ePZJKLMUZiYZazEXFiQDpWLEcrAIAAA== Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-rwa-info X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 09:26:25 -0000 "No, I'm not aware of any IPR that applies to this draft" > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: gioved=EC 18 luglio 2013 21:04 > To: Diego Caviglia; anders.gavler@acreo.se; jonas.martensson@acreo.se; i- > nishioka@cb.jp.nec.com; lyong@ciena.com; cyril.margaria@nsn.com; > gregb@grotto-networking.com; leeyoung@huawei.com; > danli@huawei.com; imajuku.wataru@lab.ntt.co.jp > Cc: ccamp@ietf.org > Subject: Regarding IPR on draft-ietf-ccamp-rwa-info >=20 > Authors, Contributors, (CCAMP) >=20 > As part of the preparation for WG Last Call: >=20 > Are you aware of any IPR that applies to draft identified above? >=20 > Please state either: >=20 > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules (see= RFCs > 3979, 4879, 3669 and 5378 for more details)? >=20 > If yes to the above, please state either: >=20 > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" >=20 > If you answer no, please provide any additional details you think > appropriate. >=20 > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next st= age > until a response has been received from each author and listed contributo= r. > NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. >=20 > If you are on the CCAMP WG email list but are not listed as an author or > contributor, we remind you of your obligations under the IETF IPR rules > which encourages you to notify the IETF if you are aware of IPR of others= on > an IETF contribution, or to refrain from participating in any contributio= n or > discussion related to your undisclosed IPR. For more information, please= see > the RFCs listed above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >=20 > Thank you, > CCAMP WG Chairs >=20 > PS Please include all listed in the headers of this message in your respo= nse. From agiorgetti@sssup.it Fri Jul 19 03:00:28 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC7A21E80AE for ; Fri, 19 Jul 2013 03:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xb8icnM8MFrx for ; Fri, 19 Jul 2013 03:00:24 -0700 (PDT) Received: from sssup.it (ms01.sssup.it [193.205.80.99]) by ietfa.amsl.com (Postfix) with ESMTP id 7358B21E8095 for ; Fri, 19 Jul 2013 03:00:23 -0700 (PDT) Received: from [10.30.2.168] (account a.giorgetti@sssup.it [10.30.2.168] verified) by sssup.it (CommuniGate Pro SMTP 5.3.15) with ESMTPSA id 83629567; Fri, 19 Jul 2013 12:00:22 +0200 Message-ID: <51E90E56.9000001@sssup.it> Date: Fri, 19 Jul 2013 12:00:54 +0200 From: Alessio Giorgetti User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Lou Berger References: <51E83C64.2040105@labn.net> In-Reply-To: <51E83C64.2040105@labn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: guolintom@gmail.com, a.giorgetti@sssup.it, ccamp@ietf.org, nick@sssup.it, jyf@bupt.edu.cn Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-wson-signaling X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: alessio.giorgetti@sssup.it List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 10:00:28 -0000 Hello all, I'm not aware of any IPR that applies to this draft. Best regards, Alessio Giorgetti Il 18/07/2013 21.05, Lou Berger ha scritto: > Authors, Contributors, (CCAMP) > > As part of the preparation for WG Last Call: > > Are you aware of any IPR that applies to draft identified above? > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? > > If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS > MESSAGE'S TO LINES. > > If you are on the CCAMP WG email list but are not listed as an author or > contributor, we remind you of your obligations under the IETF IPR rules > which encourages you to notify the IETF if you are aware of IPR of > others on an IETF contribution, or to refrain from participating in any > contribution or discussion related to your undisclosed IPR. For more > information, please see the RFCs listed above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > CCAMP WG Chairs > > PS Please include all listed in the headers of this message in your > response. > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > -- Alessio Giorgetti, Ph.D. email: a.giorgetti@sssup.it phone: +39-050-5492168 From nick@sssup.it Fri Jul 19 02:49:08 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1A921F8467 for ; Fri, 19 Jul 2013 02:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oNFaUATS3g4g for ; Fri, 19 Jul 2013 02:49:04 -0700 (PDT) Received: from sssup.it (ms01.sssup.it [193.205.80.99]) by ietfa.amsl.com (Postfix) with ESMTP id 0984521F9E4D for ; Fri, 19 Jul 2013 02:49:03 -0700 (PDT) Received: from [10.30.2.237] (account n.andriolli@sssup.it [10.30.2.237] verified) by sssup.it (CommuniGate Pro SMTP 5.3.15) with ESMTPSA id 83629184; Fri, 19 Jul 2013 11:49:01 +0200 Message-ID: <51E90B8C.4030107@sssup.it> Date: Fri, 19 Jul 2013 11:49:00 +0200 From: Nicola Andriolli User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Lou Berger References: <51E83C64.2040105@labn.net> In-Reply-To: <51E83C64.2040105@labn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 19 Jul 2013 03:27:31 -0700 Cc: guolintom@gmail.com, a.giorgetti@sssup.it, ccamp@ietf.org, jyf@bupt.edu.cn Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-wson-signaling X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 09:50:02 -0000 Hi Lou, all, I'm not aware of any IPR that applies to this draft. Best regards, Nicola Il 18/07/2013 21:05, Lou Berger ha scritto: > Authors, Contributors, (CCAMP) > > As part of the preparation for WG Last Call: > > Are you aware of any IPR that applies to draft identified above? > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? > > If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS > MESSAGE'S TO LINES. > > If you are on the CCAMP WG email list but are not listed as an author or > contributor, we remind you of your obligations under the IETF IPR rules > which encourages you to notify the IETF if you are aware of IPR of > others on an IETF contribution, or to refrain from participating in any > contribution or discussion related to your undisclosed IPR. For more > information, please see the RFCs listed above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > CCAMP WG Chairs > > PS Please include all listed in the headers of this message in your > response. From Itaru.Nishioka@necam.com Fri Jul 19 17:51:01 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE1321E80B4 for ; Fri, 19 Jul 2013 17:51:01 -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 ELihy+smaKob for ; Fri, 19 Jul 2013 17:50:56 -0700 (PDT) Received: from mx11.nec.com (mx11.nec.com [143.101.113.2]) by ietfa.amsl.com (Postfix) with ESMTP id 51E3521E804C for ; Fri, 19 Jul 2013 17:50:54 -0700 (PDT) Received: from unknown (HELO exchbh101.necam.prv) ([172.24.172.62]) by mx11.nec.com with ESMTP; 19 Jul 2013 19:50:42 -0500 Received: from irvmail1.necam.prv ([172.24.28.180]) by exchbh101.necam.prv with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Jul 2013 19:50:42 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Jul 2013 19:50:40 -0500 Message-ID: <4D9364CAAC76F64682C75DC2B8E9F557040E9188@irvmail1.necam.prv> In-Reply-To: <51E83C26.2090302@labn.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Regarding IPR on draft-ietf-ccamp-rwa-info Thread-Index: Ac6D6Zv83cU2P3PIT6CSVdaYXHvmCAA+XorQ References: <51E83C26.2090302@labn.net> From: "Nishioka, Itaru" To: "Lou Berger" , , , , , , , , , , X-OriginalArrivalTime: 20 Jul 2013 00:50:42.0550 (UTC) FILETIME=[294A4960:01CE84E3] X-Mailman-Approved-At: Fri, 19 Jul 2013 17:53:33 -0700 Cc: ccamp@ietf.org Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-rwa-info X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 00:51:01 -0000 X-List-Received-Date: Sat, 20 Jul 2013 00:51:01 -0000 Hi, "No, I'm not aware of any IPR that applies to this draft" Itaru. -------- Itaru Nishioka, NEC Corporation of America Mobile: +1-857-998-1062 Office: +1-617-873-8148 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, July 18, 2013 3:04 PM > To: diego.caviglia@ericsson.com; anders.gavler@acreo.se; > jonas.martensson@acreo.se; i-nishioka@cb.jp.nec.com; lyong@ciena.com; > cyril.margaria@nsn.com; gregb@grotto-networking.com; > leeyoung@huawei.com; danli@huawei.com; imajuku.wataru@lab.ntt.co.jp > Cc: ccamp@ietf.org > Subject: Regarding IPR on draft-ietf-ccamp-rwa-info >=20 > Authors, Contributors, (CCAMP) >=20 > As part of the preparation for WG Last Call: >=20 > Are you aware of any IPR that applies to draft identified above? >=20 > Please state either: >=20 > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules (see > RFCs 3979, 4879, 3669 and 5378 for more details)? >=20 > If yes to the above, please state either: >=20 > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" >=20 > If you answer no, please provide any additional details you think > appropriate. >=20 > If you are listed as a document author or contributor please answer the above > by responding to this email regardless of whether or not you are aware of > any relevant IPR. This document will not advance to the next stage until > a response has been received from each author and listed contributor. NOTE: > THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. >=20 > If you are on the CCAMP WG email list but are not listed as an author or > contributor, we remind you of your obligations under the IETF IPR rules which > encourages you to notify the IETF if you are aware of IPR of others on an > IETF contribution, or to refrain from participating in any contribution or > discussion related to your undisclosed IPR. For more information, please > see the RFCs listed above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >=20 > Thank you, > CCAMP WG Chairs >=20 > PS Please include all listed in the headers of this message in your response. From Itaru.Nishioka@necam.com Fri Jul 19 17:51:15 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8033D11E8160 for ; Fri, 19 Jul 2013 17:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhD7l7qlsdCE for ; Fri, 19 Jul 2013 17:51:11 -0700 (PDT) Received: from mx11.nec.com (mx11.nec.com [143.101.113.2]) by ietfa.amsl.com (Postfix) with ESMTP id A886321E804C for ; Fri, 19 Jul 2013 17:51:04 -0700 (PDT) Received: from unknown (HELO exchbh101.necam.prv) ([172.24.172.62]) by mx11.nec.com with ESMTP; 19 Jul 2013 19:51:04 -0500 Received: from irvmail1.necam.prv ([172.24.28.180]) by exchbh101.necam.prv with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Jul 2013 19:51:04 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Jul 2013 19:51:03 -0500 Message-ID: <4D9364CAAC76F64682C75DC2B8E9F557040E9189@irvmail1.necam.prv> In-Reply-To: <51E83C33.7010802@labn.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Regarding IPR on draft-ietf-ccamp-general-constraint-encode Thread-Index: Ac6D6aGlVs1N5tmWR5CftE8pDAeTTQA+YrCw References: <51E83C33.7010802@labn.net> From: "Nishioka, Itaru" To: "Lou Berger" , , , , , , , , , , , , X-OriginalArrivalTime: 20 Jul 2013 00:51:04.0644 (UTC) FILETIME=[36759040:01CE84E3] X-Mailman-Approved-At: Fri, 19 Jul 2013 17:53:35 -0700 Cc: ccamp@ietf.org Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-general-constraint-encode X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 00:51:15 -0000 Hi, "No, I'm not aware of any IPR that applies to this draft" Itaru -------- Itaru Nishioka, NEC Corporation of America Mobile: +1-857-998-1062 Office: +1-617-873-8148 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, July 18, 2013 3:04 PM > To: diego.caviglia@ericsson.com; anders.gavler@acreo.se; > jonas.martensson@acreo.se; i-nishioka@cb.jp.nec.com; rrao@infinera.com; > giomarti@cisco.com; remi.theillaud@marben-products.com; > gregb@grotto-networking.com; ylee@huawei.com; danli@huawei.com; > imajuku.wataru@lab.ntt.co.jp; hanjianrui@huawei.com > Cc: ccamp@ietf.org > Subject: Regarding IPR on draft-ietf-ccamp-general-constraint-encode >=20 > Authors, Contributors, (CCAMP) >=20 > As part of the preparation for WG Last Call: >=20 > Are you aware of any IPR that applies to draft identified above? >=20 > Please state either: >=20 > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules (see > RFCs 3979, 4879, 3669 and 5378 for more details)? >=20 > If yes to the above, please state either: >=20 > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" >=20 > If you answer no, please provide any additional details you think > appropriate. >=20 > If you are listed as a document author or contributor please answer the above > by responding to this email regardless of whether or not you are aware of > any relevant IPR. This document will not advance to the next stage until > a response has been received from each author and listed contributor. NOTE: > THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. >=20 > If you are on the CCAMP WG email list but are not listed as an author or > contributor, we remind you of your obligations under the IETF IPR rules which > encourages you to notify the IETF if you are aware of IPR of others on an > IETF contribution, or to refrain from participating in any contribution or > discussion related to your undisclosed IPR. For more information, please > see the RFCs listed above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >=20 > Thank you, > CCAMP WG Chairs >=20 > PS Please include all listed in the headers of this message in your response. From Itaru.Nishioka@necam.com Fri Jul 19 17:51:20 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B25311E8160 for ; Fri, 19 Jul 2013 17:51:20 -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 wNInaSsN+dgX for ; Fri, 19 Jul 2013 17:51:15 -0700 (PDT) Received: from mx11.nec.com (mx11.nec.com [143.101.113.2]) by ietfa.amsl.com (Postfix) with ESMTP id 535C511E81D2 for ; Fri, 19 Jul 2013 17:51:14 -0700 (PDT) Received: from unknown (HELO exchbh101.necam.prv) ([172.24.172.62]) by mx11.nec.com with ESMTP; 19 Jul 2013 19:51:14 -0500 Received: from irvmail1.necam.prv ([172.24.28.180]) by exchbh101.necam.prv with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Jul 2013 19:51:14 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Jul 2013 19:51:12 -0500 Message-ID: <4D9364CAAC76F64682C75DC2B8E9F557040E918A@irvmail1.necam.prv> In-Reply-To: <51E83C4F.8090502@labn.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Regarding IPR on draft-ietf-ccamp-rwa-wson-encode Thread-Index: Ac6D6a+St3VZPoDySqiyMD37m0VwXwA+Yd7Q References: <51E83C4F.8090502@labn.net> From: "Nishioka, Itaru" To: "Lou Berger" , , , , , , , , , , , , , , , X-OriginalArrivalTime: 20 Jul 2013 00:51:14.0270 (UTC) FILETIME=[3C325FE0:01CE84E3] X-Mailman-Approved-At: Fri, 19 Jul 2013 17:53:36 -0700 Cc: ccamp@ietf.org Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-rwa-wson-encode X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jul 2013 00:51:20 -0000 "No, I'm not aware of any IPR that applies to this draft" Itaru. -------- Itaru Nishioka, NEC Corporation of America Mobile: +1-857-998-1062 Office: +1-617-873-8148 > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, July 18, 2013 3:05 PM > To: diego.caviglia@ericsson.com; anders.gavler@acreo.se; > jonas.martensson@acreo.se; i-nishioka@cb.jp.nec.com; > pierre.peloso@alcatel-lucent.com; cyril.margaria@nsn.com; > giomarti@cisco.com; ggalimbe@cisco.com; lyong@ciena.com; > daniele.ceccarelli@ericsson.com; gregb@grotto-networking.com; > leeyoung@huawei.com; danli@huawei.com; imajuku.wataru@lab.ntt.co.jp; > hanjianrui@huawei.com > Cc: ccamp@ietf.org > Subject: Regarding IPR on draft-ietf-ccamp-rwa-wson-encode >=20 > Authors, Contributors, (CCAMP) >=20 > As part of the preparation for WG Last Call: >=20 > Are you aware of any IPR that applies to draft identified above? >=20 > Please state either: >=20 > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules (see > RFCs 3979, 4879, 3669 and 5378 for more details)? >=20 > If yes to the above, please state either: >=20 > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" >=20 > If you answer no, please provide any additional details you think > appropriate. >=20 > If you are listed as a document author or contributor please answer the above > by responding to this email regardless of whether or not you are aware of > any relevant IPR. This document will not advance to the next stage until > a response has been received from each author and listed contributor. NOTE: > THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. >=20 > If you are on the CCAMP WG email list but are not listed as an author or > contributor, we remind you of your obligations under the IETF IPR rules which > encourages you to notify the IETF if you are aware of IPR of others on an > IETF contribution, or to refrain from participating in any contribution or > discussion related to your undisclosed IPR. For more information, please > see the RFCs listed above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >=20 > Thank you, > CCAMP WG Chairs >=20 > PS Please include all listed in the headers of this message in your response. From daniele.ceccarelli@ericsson.com Tue Jul 23 01:05:58 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02A2D11E8103 for ; Tue, 23 Jul 2013 01:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.248 X-Spam-Level: X-Spam-Status: No, score=-6.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 s1GUTJF9zHBj for ; Tue, 23 Jul 2013 01:05:36 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 0448321F9D09 for ; Tue, 23 Jul 2013 01:05:35 -0700 (PDT) X-AuditID: c1b4fb25-b7f826d000001766-fc-51ee394e0e21 Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 49.A1.05990.E493EE15; Tue, 23 Jul 2013 10:05:34 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.144]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Tue, 23 Jul 2013 10:05:34 +0200 From: Daniele Ceccarelli To: "CCAMP (ccamp@ietf.org)" Thread-Topic: CCAMP slides and notes for presenters Thread-Index: Ac6HeuAK1Ht9OQm0TsyY7rsgXdhz7A== Date: Tue, 23 Jul 2013 08:05:33 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE4811A173@ESESSMB301.ericsson.se> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: multipart/alternative; boundary="_000_4A1562797D64E44993C5CBF38CF1BE4811A173ESESSMB301ericsso_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+Jvra6f5btAg6bzqhZP5txgsWh6u5fF 4nJXN7tFR/NbFgcWj5f9cxg9liz5yeTxYVMzm8eKzSsZA1iiuGxSUnMyy1KL9O0SuDLOP9nA XrDKuqJneUADY5dxFyMnh4SAicTt2XeYIWwxiQv31rOB2EIChxklTjyX7WLkArKXMEq8+vqE qYuRg4NNwEriySEfkBoRAV2JvRuvg/UyC2xllHj2jwPEFhbQk7jXcJkRosZY4lHLQTYIW0/i 8d1rrCA2i4CqxP5Tj9lBbF4Bb4ktTRdYQGxGAVmJCbsXMULMFJe49WQ+E8RtAhJL9pyHulNU 4uXjf6wQtqJE+9MGqPp8id9LTzBCzBSUODnzCcsERuFZSEbNQlI2C0kZRFxHYsHuT2wQtrbE soWvmWHsMwceMyGLL2BkX8XInpuYmZNebrSJERhHB7f8Vt3BeOecyCFGaQ4WJXHezXpnAoUE 0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwGj7VbOZ8XXac1SopZGWnbni83umOK6Y9BTfnir1j aWRLc85awfYl9WGhamj5CYb1heXOK3ZrV74/nRRoNONU2SrDLbn7F776apfmE3Rxc8/t+ow4 YaVmgQ9u27/P2WLn8Uem3auJS13z3RP3KYXbfI7+LzL9fNtvge8JjlXSxxSn7E1cceuEEktx RqKhFnNRcSIAvLDlVHECAAA= Subject: [CCAMP] CCAMP slides and notes for presenters X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 08:05:58 -0000 --_000_4A1562797D64E44993C5CBF38CF1BE4811A173ESESSMB301ericsso_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear CCAMPers, The hopefully final agenda for the upcoming meeting has been published (http://tools.ietf.org/wg/ccamp/agenda) Presenters: 1. Please verify that you are scheduled. (At this point, all requests have been honored). Note that agenda time is *very* tight and that the scheduled time includes your discussion time. 2. Slides should be submitted to both the chairs *and* the secretaries by the end of Sunday, July 28th. (Earlier would be appreciated.) 3. As a reminder, the goal of the presentation is to resolve issues/discussions in order to move the document forward. Presentations should focus on unresolved issues and questions for the WG and *not* provide a tutorial on the draft. For new drafts this means: - Identify issue to be addressed / questions for the WG - Identify why issue belongs in ccamp - State how draft addresses issue For other drafts this means: Cover recent changes, open issues, planned next steps, and questions for the WG Remember to leave time for discussion! As always, please don't hesitate to begin the discussion on the list before the meeting. A reminder to authors of active working group documents who are *not* presenting: Please send a message summarizing status (briefly, including recent changes= ), open issues/discussion topics and planned next steps to the ccamp list *= this* week. CCAMP chairs and secretaries --_000_4A1562797D64E44993C5CBF38CF1BE4811A173ESESSMB301ericsso_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear CCAMPers,

 

The hopefully final agenda for the upcoming meeti= ng has been published

(http://tools.ietf.org/wg/ccamp/agenda)

 

Presenters:

1. Please verify that you are scheduled. (At this= point, all requests

   have been honored). Note that agenda= time is *very* tight and that

   the scheduled time includes your dis= cussion time.

 

2. Slides should be submitted to both the chairs = *and* the

    secretaries by the end of Sund= ay, July 28th.

    (Earlier would be appreci= ated.)

 

3. As a reminder, the goal of the presentation is= to resolve

    issues/discussions in order to= move the document forward.

    Presentations should focus on = unresolved issues and questions

    for the WG and *not* provide a= tutorial on the draft.

 

    For new drafts this means:

     - Identify issue to be a= ddressed / questions for the WG

     - Identify why issue bel= ongs in ccamp

     - State how draft addres= ses issue

 

    For other drafts this means:

      Cover recent chang= es, open issues, planned next steps,

        &= nbsp;       and questions for the WG

 

    Remember to leave time for dis= cussion!

 

    As always, please don't hesita= te to begin the discussion on the list

    before the meeting.=

 

A reminder to authors of active working group doc= uments who are *not*

presenting:

 

Please send a message summarizing status (briefly= , including recent changes), open issues/discussion topics and planned next= steps to the ccamp list *this* week.

 

CCAMP chairs and secretaries

 

--_000_4A1562797D64E44993C5CBF38CF1BE4811A173ESESSMB301ericsso_-- From xsg@nict.go.jp Tue Jul 23 05:46:03 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD1D11E80F7 for ; Tue, 23 Jul 2013 05:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.355 X-Spam-Level: X-Spam-Status: No, score=-1.355 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Ib0efLp+aOn for ; Tue, 23 Jul 2013 05:45:58 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id B30DD11E8165 for ; Tue, 23 Jul 2013 05:45:57 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id r6NCjQlb022772; Tue, 23 Jul 2013 21:45:26 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id r6NCjQvb013578; Tue, 23 Jul 2013 21:45:26 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id r6NCjPhr013575; Tue, 23 Jul 2013 21:45:25 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NICT Mail) with ESMTP id B685A2CA67; Tue, 23 Jul 2013 21:45:25 +0900 (JST) Received: from [IPv6:::1] (ssh2.nict.go.jp [133.243.3.50]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 5B78A2CA64; Tue, 23 Jul 2013 21:45:24 +0900 (JST) Message-ID: <51EE7AE3.3050203@nict.go.jp> Date: Tue, 23 Jul 2013 21:45:23 +0900 From: Sugang XU User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Lou Berger References: <51E83C64.2040105@labn.net> In-Reply-To: <51E83C64.2040105@labn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: guolintom@gmail.com, a.giorgetti@sssup.it, ccamp@ietf.org, nick@sssup.it, jyf@bupt.edu.cn Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-wson-signaling X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 12:46:03 -0000 Hi Luo, and all: No, I'm not aware of any IPR that applies to this draft. Best Regards, Sugang (2013/07/19 4:05), Lou Berger wrote: > Authors, Contributors, (CCAMP) > > As part of the preparation for WG Last Call: > > Are you aware of any IPR that applies to draft identified above? > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? > > If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS > MESSAGE'S TO LINES. > > If you are on the CCAMP WG email list but are not listed as an author or > contributor, we remind you of your obligations under the IETF IPR rules > which encourages you to notify the IETF if you are aware of IPR of > others on an IETF contribution, or to refrain from participating in any > contribution or discussion related to your undisclosed IPR. For more > information, please see the RFCs listed above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > CCAMP WG Chairs > > PS Please include all listed in the headers of this message in your > response. > From cyril.margaria@coriant.com Wed Jul 24 01:47:54 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 918F411E810F for ; Wed, 24 Jul 2013 01:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYzw-blrU6ne for ; Wed, 24 Jul 2013 01:47:49 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0250.outbound.messaging.microsoft.com [213.199.154.250]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF1711E83AE for ; Wed, 24 Jul 2013 01:47:45 -0700 (PDT) Received: from mail190-db9-R.bigfish.com (10.174.16.251) by DB9EHSOBE001.bigfish.com (10.174.14.64) with Microsoft SMTP Server id 14.1.225.22; Wed, 24 Jul 2013 08:47:44 +0000 Received: from mail190-db9 (localhost [127.0.0.1]) by mail190-db9-R.bigfish.com (Postfix) with ESMTP id CCA30540193; Wed, 24 Jul 2013 08:47:44 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.53; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0411HT005.eurprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zz9371Ic89bh542I1432I31c5Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hz70kz1de098h1033IL17326ah8275dh1de097h1de096hz2fh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail190-db9: domain of coriant.com designates 157.56.253.53 as permitted sender) client-ip=157.56.253.53; envelope-from=cyril.margaria@coriant.com; helo=DB3PRD0411HT005.eurprd04.prod.outlook.com ; .outlook.com ; Received: from mail190-db9 (localhost.localdomain [127.0.0.1]) by mail190-db9 (MessageSwitch) id 137465566276938_28055; Wed, 24 Jul 2013 08:47:42 +0000 (UTC) Received: from DB9EHSMHS014.bigfish.com (unknown [10.174.16.232]) by mail190-db9.bigfish.com (Postfix) with ESMTP id 0301140063; Wed, 24 Jul 2013 08:47:42 +0000 (UTC) Received: from DB3PRD0411HT005.eurprd04.prod.outlook.com (157.56.253.53) by DB9EHSMHS014.bigfish.com (10.174.14.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 24 Jul 2013 08:47:41 +0000 Received: from DB3PRD0411MB427.eurprd04.prod.outlook.com ([169.254.6.251]) by DB3PRD0411HT005.eurprd04.prod.outlook.com ([10.255.73.40]) with mapi id 14.16.0329.000; Wed, 24 Jul 2013 08:47:41 +0000 From: "Margaria, Cyril (Coriant - DE/Munich)" To: ext Lou Berger , "diego.caviglia@ericsson.com" , "anders.gavler@acreo.se" , "jonas.martensson@acreo.se" , "i-nishioka@cb.jp.nec.com" , "lyong@ciena.com" , "cyril.margaria@nsn.com" , "gregb@grotto-networking.com" , "leeyoung@huawei.com" , "danli@huawei.com" , "imajuku.wataru@lab.ntt.co.jp" Thread-Topic: Regarding IPR on draft-ietf-ccamp-rwa-info Thread-Index: AQHOg+mg9PSoAcCHDEidsWxwNN1ycJlzi9Rw Date: Wed, 24 Jul 2013 08:47:41 +0000 Message-ID: <523C37072C291347B9730C9291CCA07D0CAB14@DB3PRD0411MB427.eurprd04.prod.outlook.com> References: <51E83C26.2090302@labn.net> In-Reply-To: <51E83C26.2090302@labn.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [62.159.77.165] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: coriant.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-rwa-info X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 08:47:54 -0000 Dear CCAMP, Chairs No, I'm not aware of any IPR that applies to this draft Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria > -----Original Message----- > From: ext Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, July 18, 2013 9:04 PM > To: diego.caviglia@ericsson.com; anders.gavler@acreo.se; > jonas.martensson@acreo.se; i-nishioka@cb.jp.nec.com; lyong@ciena.com; > cyril.margaria@nsn.com; gregb@grotto-networking.com; > leeyoung@huawei.com; danli@huawei.com; imajuku.wataru@lab.ntt.co.jp > Cc: ccamp@ietf.org > Subject: Regarding IPR on draft-ietf-ccamp-rwa-info >=20 > Authors, Contributors, (CCAMP) >=20 > As part of the preparation for WG Last Call: >=20 > Are you aware of any IPR that applies to draft identified above? >=20 > Please state either: >=20 > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? >=20 > If yes to the above, please state either: >=20 > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" >=20 > If you answer no, please provide any additional details you think > appropriate. >=20 > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S > TO LINES. >=20 > If you are on the CCAMP WG email list but are not listed as an author > or contributor, we remind you of your obligations under the IETF IPR > rules which encourages you to notify the IETF if you are aware of IPR > of others on an IETF contribution, or to refrain from participating in > any contribution or discussion related to your undisclosed IPR. For > more information, please see the RFCs listed above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >=20 > Thank you, > CCAMP WG Chairs >=20 > PS Please include all listed in the headers of this message in your > response. From cyril.margaria@coriant.com Wed Jul 24 01:48:58 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59C9711E83CB for ; Wed, 24 Jul 2013 01:48:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.533 X-Spam-Level: X-Spam-Status: No, score=-1.533 tagged_above=-999 required=5 tests=[AWL=-1.066, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 VZKQdN+1ygbe for ; Wed, 24 Jul 2013 01:48:53 -0700 (PDT) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id 39AF111E810F for ; Wed, 24 Jul 2013 01:48:52 -0700 (PDT) Received: from mail2-co1-R.bigfish.com (10.243.78.228) by CO1EHSOBE002.bigfish.com (10.243.66.65) with Microsoft SMTP Server id 14.1.225.22; Wed, 24 Jul 2013 08:48:52 +0000 Received: from mail2-co1 (localhost [127.0.0.1]) by mail2-co1-R.bigfish.com (Postfix) with ESMTP id 0C2F078012C; Wed, 24 Jul 2013 08:48:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.53; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0411HT003.eurprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: PS-21(zz9371Ic89bh542I1432I31c5Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hz70kz1de098h1033IL17326ah8275dh1de097h1de096h8275bhz2fh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail2-co1: domain of coriant.com designates 157.56.253.53 as permitted sender) client-ip=157.56.253.53; envelope-from=cyril.margaria@coriant.com; helo=DB3PRD0411HT003.eurprd04.prod.outlook.com ; .outlook.com ; Received: from mail2-co1 (localhost.localdomain [127.0.0.1]) by mail2-co1 (MessageSwitch) id 1374655730220231_19595; Wed, 24 Jul 2013 08:48:50 +0000 (UTC) Received: from CO1EHSMHS005.bigfish.com (unknown [10.243.78.225]) by mail2-co1.bigfish.com (Postfix) with ESMTP id 2F5FC560047; Wed, 24 Jul 2013 08:48:50 +0000 (UTC) Received: from DB3PRD0411HT003.eurprd04.prod.outlook.com (157.56.253.53) by CO1EHSMHS005.bigfish.com (10.243.66.15) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 24 Jul 2013 08:48:50 +0000 Received: from DB3PRD0411MB427.eurprd04.prod.outlook.com ([169.254.6.251]) by DB3PRD0411HT003.eurprd04.prod.outlook.com ([10.255.73.38]) with mapi id 14.16.0329.000; Wed, 24 Jul 2013 08:48:44 +0000 From: "Margaria, Cyril (Coriant - DE/Munich)" To: ext Lou Berger , "diego.caviglia@ericsson.com" , "anders.gavler@acreo.se" , "jonas.martensson@acreo.se" , "i-nishioka@cb.jp.nec.com" , "pierre.peloso@alcatel-lucent.com" , "cyril.margaria@nsn.com" , "giomarti@cisco.com" , "ggalimbe@cisco.com" , "lyong@ciena.com" , "daniele.ceccarelli@ericsson.com" , "gregb@grotto-networking.com" , "leeyoung@huawei.com" , "danli@huawei.com" , "imajuku.wataru@lab.ntt.co.jp" , "hanjianrui@huawei.com" Thread-Topic: Regarding IPR on draft-ietf-ccamp-rwa-wson-encode Thread-Index: AQHOg+myl31G4XmAukSstR0csyPj5plzjSzA Date: Wed, 24 Jul 2013 08:48:44 +0000 Message-ID: <523C37072C291347B9730C9291CCA07D0CAB26@DB3PRD0411MB427.eurprd04.prod.outlook.com> References: <51E83C4F.8090502@labn.net> In-Reply-To: <51E83C4F.8090502@labn.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [62.159.77.165] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: coriant.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%ALCATEL-LUCENT.COM$RO%1$TLS%0$FQDN%$TlsDn% Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-rwa-wson-encode X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 08:48:58 -0000 Dear CCAMP , Chairs,=20 No, I'm not aware of any IPR that applies to this draft Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria > -----Original Message----- > From: ext Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, July 18, 2013 9:05 PM > To: diego.caviglia@ericsson.com; anders.gavler@acreo.se; > jonas.martensson@acreo.se; i-nishioka@cb.jp.nec.com; > pierre.peloso@alcatel-lucent.com; cyril.margaria@nsn.com; > giomarti@cisco.com; ggalimbe@cisco.com; lyong@ciena.com; > daniele.ceccarelli@ericsson.com; gregb@grotto-networking.com; > leeyoung@huawei.com; danli@huawei.com; imajuku.wataru@lab.ntt.co.jp; > hanjianrui@huawei.com > Cc: ccamp@ietf.org > Subject: Regarding IPR on draft-ietf-ccamp-rwa-wson-encode >=20 > Authors, Contributors, (CCAMP) >=20 > As part of the preparation for WG Last Call: >=20 > Are you aware of any IPR that applies to draft identified above? >=20 > Please state either: >=20 > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details)? >=20 > If yes to the above, please state either: >=20 > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" >=20 > If you answer no, please provide any additional details you think > appropriate. >=20 > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S > TO LINES. >=20 > If you are on the CCAMP WG email list but are not listed as an author > or contributor, we remind you of your obligations under the IETF IPR > rules which encourages you to notify the IETF if you are aware of IPR > of others on an IETF contribution, or to refrain from participating in > any contribution or discussion related to your undisclosed IPR. For > more information, please see the RFCs listed above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >=20 > Thank you, > CCAMP WG Chairs >=20 > PS Please include all listed in the headers of this message in your > response. From prvs=4917cd9667=lyong@ciena.com Wed Jul 24 01:51:55 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 596CF11E83DF for ; Wed, 24 Jul 2013 01:51:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.265 X-Spam-Level: X-Spam-Status: No, score=-103.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-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 Oswnxtq0zbZ5 for ; Wed, 24 Jul 2013 01:51:50 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by ietfa.amsl.com (Postfix) with ESMTP id BDF8C11E83D9 for ; Wed, 24 Jul 2013 01:51:48 -0700 (PDT) Received: from pps.filterd (m0000419 [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.5/8.14.5) with SMTP id r6O8neUK003097; Wed, 24 Jul 2013 04:51:22 -0400 Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0a-00103a01.pphosted.com with ESMTP id 1dtb6rg3bm-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 24 Jul 2013 04:51:22 -0400 Received: from ONWVEXCHHT01.ciena.com (10.128.6.16) by MDWEXGHT02.ciena.com (10.4.140.213) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 24 Jul 2013 04:51:21 -0400 Received: from ONWVEXCHMB05.ciena.com ([::1]) by ONWVEXCHHT01.ciena.com ([::1]) with mapi; Wed, 24 Jul 2013 04:51:20 -0400 From: "Ong, Lyndon" To: "Margaria, Cyril (Coriant - DE/Munich)" , ext Lou Berger , "diego.caviglia@ericsson.com" , "anders.gavler@acreo.se" , "jonas.martensson@acreo.se" , "i-nishioka@cb.jp.nec.com" , "pierre.peloso@alcatel-lucent.com" , "cyril.margaria@nsn.com" , "giomarti@cisco.com" , "ggalimbe@cisco.com" , "daniele.ceccarelli@ericsson.com" , "gregb@grotto-networking.com" , "leeyoung@huawei.com" , "danli@huawei.com" , "imajuku.wataru@lab.ntt.co.jp" , "hanjianrui@huawei.com" Date: Wed, 24 Jul 2013 04:51:16 -0400 Thread-Topic: Regarding IPR on draft-ietf-ccamp-rwa-wson-encode Thread-Index: AQHOg+myl31G4XmAukSstR0csyPj5plzjSzAgAAAt4A= Message-ID: <9B8F4BBDF8AAA54693083BC8753AE3A71ED17B3B@ONWVEXCHMB05.ciena.com> References: <51E83C4F.8090502@labn.net> <523C37072C291347B9730C9291CCA07D0CAB26@DB3PRD0411MB427.eurprd04.prod.outlook.com> In-Reply-To: <523C37072C291347B9730C9291CCA07D0CAB26@DB3PRD0411MB427.eurprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-20034.005 X-TM-AS-Result: No--26.252000-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-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-24_01:2013-07-22, 2013-07-24, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1305240000 definitions=main-1307240022 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-rwa-wson-encode X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 08:51:55 -0000 Hi All, I am not aware of any IPR related to the draft either. Cheers, Lyndon -----Original Message----- From: Margaria, Cyril (Coriant - DE/Munich) [mailto:cyril.margaria@coriant.= com]=20 Sent: Wednesday, July 24, 2013 1:49 AM To: ext Lou Berger; diego.caviglia@ericsson.com; anders.gavler@acreo.se; jo= nas.martensson@acreo.se; i-nishioka@cb.jp.nec.com; pierre.peloso@alcatel-lu= cent.com; cyril.margaria@nsn.com; giomarti@cisco.com; ggalimbe@cisco.com; O= ng, Lyndon; daniele.ceccarelli@ericsson.com; gregb@grotto-networking.com; l= eeyoung@huawei.com; danli@huawei.com; imajuku.wataru@lab.ntt.co.jp; hanjian= rui@huawei.com Cc: ccamp@ietf.org Subject: RE: Regarding IPR on draft-ietf-ccamp-rwa-wson-encode Dear CCAMP , Chairs,=20 No, I'm not aware of any IPR that applies to this draft Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria > -----Original Message----- > From: ext Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, July 18, 2013 9:05 PM > To: diego.caviglia@ericsson.com; anders.gavler@acreo.se;=20 > jonas.martensson@acreo.se; i-nishioka@cb.jp.nec.com;=20 > pierre.peloso@alcatel-lucent.com; cyril.margaria@nsn.com;=20 > giomarti@cisco.com; ggalimbe@cisco.com; lyong@ciena.com;=20 > daniele.ceccarelli@ericsson.com; gregb@grotto-networking.com;=20 > leeyoung@huawei.com; danli@huawei.com; imajuku.wataru@lab.ntt.co.jp;=20 > hanjianrui@huawei.com > Cc: ccamp@ietf.org > Subject: Regarding IPR on draft-ietf-ccamp-rwa-wson-encode >=20 > Authors, Contributors, (CCAMP) >=20 > As part of the preparation for WG Last Call: >=20 > Are you aware of any IPR that applies to draft identified above? >=20 > Please state either: >=20 > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules=20 > (see RFCs 3979, 4879, 3669 and 5378 for more details)? >=20 > If yes to the above, please state either: >=20 > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" >=20 > If you answer no, please provide any additional details you think > appropriate. >=20 > If you are listed as a document author or contributor please answer=20 > the above by responding to this email regardless of whether or not you=20 > are aware of any relevant IPR. This document will not advance to the=20 > next stage until a response has been received from each author and=20 > listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS=20 > MESSAGE'S TO LINES. >=20 > If you are on the CCAMP WG email list but are not listed as an author=20 > or contributor, we remind you of your obligations under the IETF IPR=20 > rules which encourages you to notify the IETF if you are aware of IPR=20 > of others on an IETF contribution, or to refrain from participating in=20 > any contribution or discussion related to your undisclosed IPR. For=20 > more information, please see the RFCs listed above and=20 > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >=20 > Thank you, > CCAMP WG Chairs >=20 > PS Please include all listed in the headers of this message in your=20 > response. From prvs=4917cd9667=lyong@ciena.com Wed Jul 24 01:52:21 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96A7B11E83E3 for ; Wed, 24 Jul 2013 01:52:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.265 X-Spam-Level: X-Spam-Status: No, score=-103.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-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 uFF4SMNr9VBK for ; Wed, 24 Jul 2013 01:52:15 -0700 (PDT) Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by ietfa.amsl.com (Postfix) with ESMTP id BBD4A11E83D9 for ; Wed, 24 Jul 2013 01:52:12 -0700 (PDT) Received: from pps.filterd (m0000419 [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.5/8.14.5) with SMTP id r6O8oDi3004515; Wed, 24 Jul 2013 04:51:56 -0400 Received: from mdwvexchht01.ciena.com (LIN1-118-36-28.ciena.com [63.118.36.28]) by mx0a-00103a01.pphosted.com with ESMTP id 1dtb6rg3d4-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 24 Jul 2013 04:51:56 -0400 Received: from MDWEXCHCGSIHT01.ciena.com (10.4.140.106) by MDWVEXCHHT01.ciena.com (10.4.156.175) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 24 Jul 2013 04:51:54 -0400 Received: from ONWVEXCHHT01.ciena.com (10.128.6.16) by MDWEXCHCGSIHT01.ciena.com (10.4.140.106) with Microsoft SMTP Server (TLS) id 8.3.298.1; Wed, 24 Jul 2013 04:51:54 -0400 Received: from ONWVEXCHMB05.ciena.com ([::1]) by ONWVEXCHHT01.ciena.com ([::1]) with mapi; Wed, 24 Jul 2013 04:51:54 -0400 From: "Ong, Lyndon" To: "Margaria, Cyril (Coriant - DE/Munich)" , ext Lou Berger , "diego.caviglia@ericsson.com" , "anders.gavler@acreo.se" , "jonas.martensson@acreo.se" , "i-nishioka@cb.jp.nec.com" , "cyril.margaria@nsn.com" , "gregb@grotto-networking.com" , "leeyoung@huawei.com" , "danli@huawei.com" , "imajuku.wataru@lab.ntt.co.jp" Date: Wed, 24 Jul 2013 04:51:52 -0400 Thread-Topic: Regarding IPR on draft-ietf-ccamp-rwa-info Thread-Index: AQHOg+mg9PSoAcCHDEidsWxwNN1ycJlzi9RwgAACVzA= Message-ID: <9B8F4BBDF8AAA54693083BC8753AE3A71ED17B3C@ONWVEXCHMB05.ciena.com> References: <51E83C26.2090302@labn.net> <523C37072C291347B9730C9291CCA07D0CAB14@DB3PRD0411MB427.eurprd04.prod.outlook.com> In-Reply-To: <523C37072C291347B9730C9291CCA07D0CAB14@DB3PRD0411MB427.eurprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-TM-AS-Product-Ver: SMEX-10.0.0.1412-7.000.1014-20034.005 X-TM-AS-Result: No--20.938500-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-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-07-24_01:2013-07-22, 2013-07-24, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=0 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=6.0.2-1305240000 definitions=main-1307240022 Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] Regarding IPR on draft-ietf-ccamp-rwa-info X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 08:52:21 -0000 Hi All, Same here, not aware of any IPR on our part. Cheers, Lyndon -----Original Message----- From: Margaria, Cyril (Coriant - DE/Munich) [mailto:cyril.margaria@coriant.= com]=20 Sent: Wednesday, July 24, 2013 1:48 AM To: ext Lou Berger; diego.caviglia@ericsson.com; anders.gavler@acreo.se; jo= nas.martensson@acreo.se; i-nishioka@cb.jp.nec.com; Ong, Lyndon; cyril.marga= ria@nsn.com; gregb@grotto-networking.com; leeyoung@huawei.com; danli@huawei= .com; imajuku.wataru@lab.ntt.co.jp Cc: ccamp@ietf.org Subject: RE: Regarding IPR on draft-ietf-ccamp-rwa-info Dear CCAMP, Chairs No, I'm not aware of any IPR that applies to this draft Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria > -----Original Message----- > From: ext Lou Berger [mailto:lberger@labn.net] > Sent: Thursday, July 18, 2013 9:04 PM > To: diego.caviglia@ericsson.com; anders.gavler@acreo.se;=20 > jonas.martensson@acreo.se; i-nishioka@cb.jp.nec.com; lyong@ciena.com;=20 > cyril.margaria@nsn.com; gregb@grotto-networking.com;=20 > leeyoung@huawei.com; danli@huawei.com; imajuku.wataru@lab.ntt.co.jp > Cc: ccamp@ietf.org > Subject: Regarding IPR on draft-ietf-ccamp-rwa-info >=20 > Authors, Contributors, (CCAMP) >=20 > As part of the preparation for WG Last Call: >=20 > Are you aware of any IPR that applies to draft identified above? >=20 > Please state either: >=20 > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules=20 > (see RFCs 3979, 4879, 3669 and 5378 for more details)? >=20 > If yes to the above, please state either: >=20 > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" >=20 > If you answer no, please provide any additional details you think > appropriate. >=20 > If you are listed as a document author or contributor please answer=20 > the above by responding to this email regardless of whether or not you=20 > are aware of any relevant IPR. This document will not advance to the=20 > next stage until a response has been received from each author and=20 > listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS=20 > MESSAGE'S TO LINES. >=20 > If you are on the CCAMP WG email list but are not listed as an author=20 > or contributor, we remind you of your obligations under the IETF IPR=20 > rules which encourages you to notify the IETF if you are aware of IPR=20 > of others on an IETF contribution, or to refrain from participating in=20 > any contribution or discussion related to your undisclosed IPR. For=20 > more information, please see the RFCs listed above and=20 > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >=20 > Thank you, > CCAMP WG Chairs >=20 > PS Please include all listed in the headers of this message in your=20 > response. From adrian@olddog.co.uk Wed Jul 24 10:12:52 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C2D121F9DD0 for ; Wed, 24 Jul 2013 10:12:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.038, 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 m4XNnnvz9uHS for ; Wed, 24 Jul 2013 10:12:46 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 04F6721F9AFE for ; Wed, 24 Jul 2013 10:12:45 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6OHCiS4030731; Wed, 24 Jul 2013 18:12:44 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6OHChDY030711 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Jul 2013 18:12:43 +0100 From: "Adrian Farrel" To: Date: Wed, 24 Jul 2013 18:12:41 +0100 Message-ID: <03c801ce8891$02322800$06967800$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6IkPjHAf7FJy/FS5u7e31pZmaAPg== Content-Language: en-gb Cc: ccamp@ietf.org Subject: [CCAMP] AD review of draft-ietf-ccamp-gmpls-g709-framework X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 17:12:52 -0000 Thanks for this document. It is really well-written and a good read. I am sure a lot of effort went into it, so many thanks for the attention you have given to getting it right. I have two requests for small additions to the document and a couple of nits. Obviously, these comments are up for debate, but until then I have placed the document in "Revised I-D Needed" state. Once we resolve these issues or you post a new revision I will issue IETF last call. Thanks, Adrian === Please add a new section to provide a discussion of network management and OAM. A way to approach this is to look at Appendix A of RFC 5706 and use that to guide to what you should write. Alternatively, you could use RFC 6123 to give you guidance and structure. This information is more important in the framework document than in the protocol documents because it will set the scene correctly. A lot of this can probably be done by reference to existing documentation, and a total of only a few paragraphs will probably suffice. I suggest this goes in as Section 5.7 "Implications for Management of GMPLS Networks" --- "OTN" needs to be expanded on first use in the Introduction. --- The phrase "OTN network" seems to be redundant. --- Section 7 should talk about whether the DCN is likely to be in the overhead and therefore in-fiber. This approach, together with access lists at the network edges, provides a significant security feature. From SBardalai@infinera.com Wed Jul 24 14:58:20 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E982211E80E1 for ; Wed, 24 Jul 2013 14:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbI5JxBQpJ9x for ; Wed, 24 Jul 2013 14:58:15 -0700 (PDT) Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id AA47121F9BC3 for ; Wed, 24 Jul 2013 14:58:15 -0700 (PDT) Received: from SV-EXDB-PROD2.infinera.com ([fe80::1d05:1822:aaea:ff52]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.03.0123.003; Wed, 24 Jul 2013 14:58:14 -0700 From: Snigdho Bardalai To: "draft-ceccadedios-ccamp-overlay-use-cases@tools.ietf.org" Thread-Topic: Comment on draft-ceccadedios-ccamp-overlay-use-cases Thread-Index: Ac6Im4o3RLNWsCBKQUmukdLV6s8k8A== Date: Wed, 24 Jul 2013 21:58:14 +0000 Message-ID: <6386D6323049044BA592CB99AB04BACB3FA19151@SV-EXDB-PROD2.infinera.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.96.93] Content-Type: multipart/alternative; boundary="_000_6386D6323049044BA592CB99AB04BACB3FA19151SVEXDBPROD2infi_" MIME-Version: 1.0 Cc: "CCAMP \(ccamp@ietf.org\)" Subject: [CCAMP] Comment on draft-ceccadedios-ccamp-overlay-use-cases X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 21:58:21 -0000 --_000_6386D6323049044BA592CB99AB04BACB3FA19151SVEXDBPROD2infi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Went through this document and there seems to be a large amount of overlap = in terms of context with our ID - draft-bardalai-ccamp-overlay-path-comp. The concept of using PCEP for overlay networks was widely discussed on the = mailing list during the IETF-86 timeframe and based on that we published th= e ID with the main ideas clearly described. So please explain what is conce= ptually different from our draft as far as the PCE approach goes? Regards, Snigdho Bardalai Khuzema Pithewan Rajan Rao --_000_6386D6323049044BA592CB99AB04BACB3FA19151SVEXDBPROD2infi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Went through this document and there seems to be a large amount of over= lap in terms of context with our ID - draft-bardalai-ccamp-overlay-path-com= p.

 

The concept of using PCEP for overlay networks was widely discussed on = the mailing list during the IETF-86 timeframe and based on that we published the ID with the main ideas clearly described. So plea= se explain what is conceptually different from our draft as far as the PCE = approach goes?

 

Regards,

Snigdho Bardalai

Khuzema Pithewan

Rajan Rao

 

 

 

--_000_6386D6323049044BA592CB99AB04BACB3FA19151SVEXDBPROD2infi_-- From lberger@labn.net Fri Jul 26 09:25:45 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB08121F99ED for ; Fri, 26 Jul 2013 09:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.74 X-Spam-Level: X-Spam-Status: No, score=-100.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, 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 boWMiqP5zLAW for ; Fri, 26 Jul 2013 09:25:35 -0700 (PDT) Received: from oproxy12-pub.bluehost.com (oproxy12-pub.bluehost.com [50.87.16.10]) by ietfa.amsl.com (Postfix) with SMTP id A4E1B21F99FA for ; Fri, 26 Jul 2013 09:25:10 -0700 (PDT) Received: (qmail 26462 invoked by uid 0); 26 Jul 2013 16:24:46 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy12.bluehost.com with SMTP; 26 Jul 2013 16:24:46 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=uVGjsxxMZpd6d3i0Bp3l3PETRtTJUyCbEa9o8XwWIsY=; b=F0IvdXs46ax71cLUpIlAuASb1rd2naekZA/XuuDS4DH/S5Xy7yT4wmGU0G27+o/42OiHNCUd095lMvwqNl6IfRTv7mB6CWJRjzMM6/67Kl/dh23vIHIrkVB3ABaCwhvr; Received: from box313.bluehost.com ([69.89.31.113]:46702 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V2kow-0007lg-Ls for ccamp@ietf.org; Fri, 26 Jul 2013 10:24:46 -0600 Message-ID: <51F2A2D1.4040506@labn.net> Date: Fri, 26 Jul 2013 12:24:49 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: CCAMP X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [CCAMP] new drafts X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 16:25:45 -0000 Just a reminder to those presenting a draft that hasn't been previously presented: Please follow Daniele's message from last week and make sure you (paraphrased): - Identify issue(s) identified/addressed by the draft - Identify why issue belongs in ccamp - If relevant, state how draft addresses issue It would be good to also mention how your draft differs from other WG or individual drafts. It would best to send a summary of the above to the WG list too. Feel free to do so even before the meeting. Much thanks Deborah and Lou From adrian@olddog.co.uk Sun Jul 28 01:30:04 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D7121F9D38 for ; Sun, 28 Jul 2013 01:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.595 X-Spam-Level: X-Spam-Status: No, score=-1.595 tagged_above=-999 required=5 tests=[AWL=-0.484, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozFJMDMpzflW for ; Sun, 28 Jul 2013 01:29:56 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 42E6821F9D1E for ; Sun, 28 Jul 2013 01:29:54 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6S8TqLM028970 for ; Sun, 28 Jul 2013 09:29:52 +0100 Received: from 950129200 (dhcp-45d9.meeting.ietf.org [130.129.69.217]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6S8Tpqb028961 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 28 Jul 2013 09:29:52 +0100 From: "Adrian Farrel" To: Date: Sun, 28 Jul 2013 09:29:51 +0100 Message-ID: <02bd01ce8b6c$a1791940$e46b4bc0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6LbJKTtUoIsLR6QaO8Pr1TfB/LBQ== Content-Language: en-gb Subject: [CCAMP] Question about draft-ietf-ccamp-otn-g709-info-model-09.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 08:30:05 -0000 Hi CCAMP, I am currently reviewing draft-ietf-ccamp-otn-g709-info-model-09.txt (cunningly deceptive file name ;-) I have a question... The document makes reference to RFC 4202 and RFC 4203, but not to RFC 5307 (obsoleted RFC 4205). Can I ask why CCAMP no longer considers IS-IS to be a potential routing protocol for GMPLS systems? Thanks, Adrian From adrian@olddog.co.uk Sun Jul 28 04:40:43 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C8121F9D7D for ; Sun, 28 Jul 2013 04:40:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.343 X-Spam-Level: X-Spam-Status: No, score=-2.343 tagged_above=-999 required=5 tests=[AWL=0.256, 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 oyncADoXkV-I for ; Sun, 28 Jul 2013 04:40:37 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id BE6B821F9D5A for ; Sun, 28 Jul 2013 04:40:36 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6SBeZ7P029900; Sun, 28 Jul 2013 12:40:35 +0100 Received: from 950129200 (dhcp-45d9.meeting.ietf.org [130.129.69.217]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6SBeYAr029884 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 28 Jul 2013 12:40:34 +0100 From: "Adrian Farrel" To: Date: Sun, 28 Jul 2013 12:40:32 +0100 Message-ID: <031c01ce8b87$45b79cb0$d126d610$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6LhtnSfQOotGSxTSGTJyWDc179HQ== Content-Language: en-gb Cc: ccamp@ietf.org Subject: [CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jul 2013 11:40:43 -0000 Hi, I have done my normal AD review of your document after receiving the Publication Request. As usual, the purpose of the review is to catch issues and nits as early as possible so that they don't get in the way during IETF last call and IESG evaluation. The review below includes a few nits and raises a couple of questions. All of the issues are open for discussion, and I am quite prepared to hear back that the WG considered things and reached consensus. For the moment, I have marked the I-D as "Revised I-D Needed". Thanks for the work, Adrian === As I asked in my email to the CCAMP list, I find it odd that this document makes no reference to RFC 5307 and the use of IS-IS as a routing protocol in GMPLS control of OTN. --- Section 1 says: Specific routing and signaling extensions are defined in [OTN-OSPF] and [OTN-RSVP]. I think you might extend this text to note that those two documents and the extensions they define, specifically address the gaps identified in this document. --- I found it hard to see the clear gap analysis in section 9. I think what it says is generic and not specific to OTN - i.e., there is a need to distinguish switching capabilities from adaptation/termination capabilities. Am I missing something? Why does OTN have this issue? Should this be handled as a technology-independent issue? --- Section 10 has The IETF foresees that up to eight priorities must be supported and that all of them have to be advertised independently on the number of priorities supported by the implementation. Considering that the advertisement of all the different supported signal types will originate large LSAs, it is advised to advertise only the information related to the really supported priorities. The language here is a bit odd to me. ... *foresees* that *up*to* eight priorities *must* be supported ... ? How about... [RFC4202] defines 8 priorities for resource availability and usage. --- Section 11 Modifications to ISCD/IACD, if needed, have to be addressed in the related encoding documents. I think this document needs to state whether those modifications are needed. --- Section 12 The ODUk label format defined in [RFC4328] could be updated to support new signal types defined in [G.709-2012] but would hardly be further enhanced to support possible new signal types. What does "hardly" mean in this text? So you mean "it would be difficult"? If so.... The ODUk label format defined in [RFC4328] could be updated to support new signal types defined in [G.709-2012] but it would be difficult to further enhanced it to support possible new signal types. --- Section 12 Furthermore such label format may have scalability issues due to the high number of labels needed when signaling large LSPs. For example, when an ODU3 is mapped into an ODU4 with 1.25Gbps tributary slots, it would require the utilization of thirty-one labels (31*4*8=992 bits) to be allocated while an ODUflex into an ODU4 may need up to eighty labels (80*4*8=2560 bits). The maths is flawless. Does the WG believe that this scenario is likely? Or is it just a theoretical possibility? I ask because I am cautious about us engineering for fringe cases. --- I think a number of your Informative references are actually used as Normative. I would list [RFC3471], [RFC3473], [RFC4202], [RFC4203], [RFC4328], and [RFC5339]. From wyaacov@gmail.com Mon Jul 29 03:11:16 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD6121E8094; Mon, 29 Jul 2013 03:11:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.39 X-Spam-Level: X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QdWIJaRVDFTY; Mon, 29 Jul 2013 03:11:15 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) by ietfa.amsl.com (Postfix) with ESMTP id 9900411E80D3; Mon, 29 Jul 2013 03:11:14 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id f12so4020403wgh.3 for ; Mon, 29 Jul 2013 03:11:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kpRMZW/ockb7qFuJ8RVM4YEVUksMyBgDVPmGw9EwRJ0=; b=nocRnGJmjDpZyMz4fXSs84AcnVwdQIEDr/Wa/9V0KsIuJS1/oorsjyKM2nqOZPGzhi pq8UEmYpsF1CT8t8+KNBBIwZR8RdSYrVgemNPI22WGnrKA2wEOVJj4CBlq/aRIF9sdvK bokPtWiDL3Hg6j8vp/PKJ3/e4eOKhdYGW6d/vsxzzgbGQls5O2QrH96eB7+iqy2XpPhb qEqcFKseXj0VWC4qzzBuaxez18yIIoOBxfWTawgIVI1tADyk3gdsPhdKUZKGyUX/LdnP uJChGkZGjFMQLdJkLaNj+ehJs7f56Hyf/FhGZvPytY/8blVIMbHxdA8A+ha4z5UXJVxV 9wqg== MIME-Version: 1.0 X-Received: by 10.194.19.130 with SMTP id f2mr41881574wje.22.1375092673713; Mon, 29 Jul 2013 03:11:13 -0700 (PDT) Received: by 10.194.164.200 with HTTP; Mon, 29 Jul 2013 03:11:13 -0700 (PDT) In-Reply-To: <51F62737.3020505@gmail.com> References: <51DFBCAE.1090904@gmail.com> <51F62737.3020505@gmail.com> Date: Mon, 29 Jul 2013 13:11:13 +0300 Message-ID: From: Yaacov Weingarten To: huubatwork@gmail.com, ccamp@ietf.org Content-Type: multipart/alternative; boundary=047d7b5d4dae599c0e04e2a3b64d X-Mailman-Approved-At: Mon, 29 Jul 2013 04:44:12 -0700 Cc: "mpls@ietf.org" Subject: Re: [CCAMP] [mpls] Fwd: Fwd: I-D Action: draft-helvoort-ccamp-fs-priority-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 10:11:16 -0000 --047d7b5d4dae599c0e04e2a3b64d Content-Type: text/plain; charset=ISO-8859-1 Hi, While I understand (and to a certain extent support) the purpose of this document, I am not sure that the note that you are proposing in Section 2 of the document really clarifies the definitions of what are the priorities. Based on the Rosetta Stone document - a "Communication Channel" is any logical connection between NEs that may be used for management or control plane applications. In theory this includes (to my understanding) any use of the GACH as defined for MPLS-TP (e.g. any OAM functionality). Your note states: "For 1+1 protection schemes (which do not use a communication channel)" - - what are these? Is there a protection scheme for MPLS-TP that do not use a communication channel - for example for CC or CV messages? If you meant to say that they are not dependent upon a coordination protocol (similar to the statement in the ITU documentation that refers to APS) then I suggest that you clearly state this. - However, are you adding a blanket statement that 1+1 protection schemes do not use a coordination protocol? This is news to me, since to the best of my recollection both ITU Ethernet Linear Protection and RFC6378 define support for 1+1 protection, don't they? Might I suggest that you adhere more closely to the language of the ITU definition and state that if a coordination protocol is being used then SF-P priority is higher than FS. Hope this helps, yaacov weingarten On Mon, Jul 29, 2013 at 11:26 AM, Huub van Helvoort wrote: > Hello MPLS, > > I noticed that I did not send this notification to the MPLS > list at the same time as I sent it to CCAMP. > > This concerns/addresses priorities in linear protection. > > Best regards, Huub. > > -------- Original Message -------- > Subject: Fwd: I-D Action: draft-helvoort-ccamp-fs-**priority-00.txt > Date: Fri, 12 Jul 2013 10:22:06 +0200 > From: Huub van Helvoort > Reply-To: huubatwork@gmail.com > To: CCAMP > > Hello CCAMP, > > Based on the messages on the MPLS list: > http://www.ietf.org/mail-**archive/web/mpls/current/**msg09913.html > http://www.ietf.org/mail-**archive/web/mpls/current/**msg09916.html > > I have created and uploaded the draft below. > Comments are appreciated. > > Best regards, Huub. > > -------- Original Message -------- > Subject: I-D Action: draft-helvoort-ccamp-fs-**priority-00.txt > Date: Fri, 12 Jul 2013 01:01:39 -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 : Update Forced Switch Priority > Author(s) : Huub van Helvoort > Filename : draft-helvoort-ccamp-fs-**priority-00.txt > Pages : 4 > Date : 2013-07-12 > > Abstract: > This document clarifies the definitions related to Manual Switch and > Forced Switch. This document updates RFC 4427. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/**doc/draft-helvoort-ccamp-fs-**priority > > There's also a htmlized version available at: > http://tools.ietf.org/html/**draft-helvoort-ccamp-fs-**priority-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-**drafts/ > > ______________________________**_________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/**listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.**html > or ftp://ftp.ietf.org/ietf/**1shadow-sites.txt > > > > > ______________________________**_________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/**listinfo/mpls > -- Thanx and BR, yaacov *Still looking for new opportunity* --047d7b5d4dae599c0e04e2a3b64d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
=A0
While I understand (and t= o a certain extent support) the purpose of this document, I am not sure tha= t the note that you are proposing in Section 2 of the document really clari= fies the definitions of what are the priorities.
=A0
Based on the Rosetta Stone document - a "Communicat= ion Channel" is any logical connection between NEs that may be used fo= r management or control plane applications. In theory this includes (to my = understanding) any use of the GACH as defined for MPLS-TP (e.g. any OAM fun= ctionality).
=A0
Your note states: "For 1+1 protection schemes (whic= h do not use a communication channel)" -
  • what are these?= Is there a protection scheme for MPLS-TP that do not use a communication c= hannel - for example for CC or CV messages? If you meant to say that they a= re not dependent upon a coordination protocol (similar to the statement in = the ITU documentation that refers to APS) then I suggest that you clearly s= tate this.
  • However, are you adding a blanket statement that 1+1 protection schemes= do not use a coordination protocol? This is news to me, since to the best = of my recollection both ITU Ethernet Linear Protection and RFC6378 define s= upport for 1+1 protection, don't they?
Might I suggest that you adhere more closely to the language of t= he ITU definition and state that if a coordination protocol is being used t= hen SF-P priority is higher than FS.
=A0
Hope this hel= ps,
yaacov weingarten


On Mon, Jul 29, 2013 at 11:26 AM, Huub van Helvoort <h= uubatwork@gmail.com> wrote:
Hello MPLS,

I noticed that I did not send this notification to the MPLS
list at the same time as I sent it to CCAMP.

This concerns/addresses priorities in linear protection.

Best regards, Huub.

-------- Original Message --------
Subject: Fwd: I-D Action: draft-helvoort-ccamp-fs-priority-00.txt Date: Fri, 12 Jul 2013 10:22:06 +0200
From: Huub van Helvoort <huubatwork@gmail.com>
Reply-To: huubatw= ork@gmail.com
To: CCAMP <ccamp@iet= f.org>

Hello CCAMP,

Based on the messages on the MPLS list:
http://www.ietf.org/mail-archive/web/mpls/current= /msg09913.html
http://www.ietf.org/mail-archive/web/mpls/current= /msg09916.html

I have created and uploaded the draft below.
Comments are appreciated.

Best regards, Huub.

-------- Original Message --------
Subject: I-D Action: draft-helvoort-ccamp-fs-priority-00.txt
Date: Fri, 12 Jul 2013 01:01:39 -0700
From: interne= t-drafts@ietf.org
Reply-To: int= ernet-drafts@ietf.org
To: i-d-announce= @ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts
directories.


=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Update Forced Switch Priority =A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Huub van Helvoort
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-helvoort-ccamp-fs-pr= iority-00.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 4
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-07-12

Abstract:
=A0 =A0This document clarifies the definitions related to Manual Switch and=
=A0 =A0Forced Switch. This document updates RFC 4427.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-helvoort= -ccamp-fs-priority

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-helvoort-ccamp-fs= -priority-00


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

_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.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




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



--
Thanx = and BR,
yaacov

Still looking for new opport= unity
--047d7b5d4dae599c0e04e2a3b64d-- From lsmt@ietf.org Mon Jul 29 06:47:19 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2293511E80EA; Mon, 29 Jul 2013 06:47:19 -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 G6wNS7j8l1Cg; Mon, 29 Jul 2013 06:47:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C33211E80D9; Mon, 29 Jul 2013 06:47:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: Liaison Statement Management Tool To: Lou Berger , Deborah Brungard X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130729134709.7143.92504.idtracker@ietfa.amsl.com> Date: Mon, 29 Jul 2013 06:47:09 -0700 Cc: Common Control and Measurement Plane Discussion List Subject: [CCAMP] New Liaison Statement, "Liaison Statement on WSON (reply to CCAMP-LS11)" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 13:47:19 -0000 Title: Liaison Statement on WSON (reply to CCAMP-LS11) Submission Date: 2013-07-23 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1268/ From: ITU-T SG 15 (Peter Stassar ) To: Common Control and Measurement Plane (Lou Berger , De= borah Brungard ) Cc: Stewart Bryant ,Adrian Farrel = ,Common Control and Measurement Plane Discussion List ,John= Drake ,Scott Mansfield Reponse Contact: = Technical Contact: = Purpose: For information Body: = Attachments: = https://datatracker.ietf.org/documents/LIAISON/liaison-2013-07-23-itu-t= -sg-15-ccamp-liaison-statement-on-wson-reply-to-ccamp-ls11-attachment-1.pdf From lsmt@ietf.org Mon Jul 29 07:14:52 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2CEA21F8E3D; Mon, 29 Jul 2013 07:14:51 -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 CCXeM5z4t6IX; Mon, 29 Jul 2013 07:14:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D34221F9F31; Mon, 29 Jul 2013 07:14:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: Liaison Statement Management Tool To: Lou Berger , Deborah Brungard X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130729141445.11949.33653.idtracker@ietfa.amsl.com> Date: Mon, 29 Jul 2013 07:14:45 -0700 Cc: Common Control and Measurement Plane Discussion List Subject: [CCAMP] New Liaison Statement, "Liaison Statement on initiating approval of OTN NE Management Recommendations" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 14:14:52 -0000 Title: Liaison Statement on initiating approval of OTN NE Management Recomm= endations Submission Date: 2013-07-23 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1269/ From: ITU-T SG 15 (Hing-Kam Lam ) To: Common Control and Measurement Plane (Lou Berger , De= borah Brungard ) Cc: Stewart Bryant ,Adrian Farrel = ,Common Control and Measurement Plane Discussion List ,John= Drake ,Scott Mansfield Reponse Contact: = Technical Contact: = Purpose: For information Body: = Attachments: Liaison Statement on initiating approval of OTN NE Management Recommend= ations https://datatracker.ietf.org/documents/LIAISON/liaison-2013-07-23-itu-t= -sg-15-ccamp-liaison-statement-on-initiating-approval-of-otn-ne-management-= recommendations-attachment-1.pdf From huubatwork@gmail.com Mon Jul 29 07:33:57 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C560221F9A38; Mon, 29 Jul 2013 07:33:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.953 X-Spam-Level: X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, MISSING_HEADERS=1.292] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Jdaj-pqJezc; Mon, 29 Jul 2013 07:33:45 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 2FB5221F9E43; Mon, 29 Jul 2013 07:33:35 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id r11so1243813pdi.13 for ; Mon, 29 Jul 2013 07:33:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=ri+oHjodlGMBptY2BfPNGAull3zPz9OVIFTUNFV2m1M=; b=FWh5P/MKOpobMreqHvSZ5vLMqrTtj7Zx5g6IDsAxriZSJeYrbqwn2WWaYTwgi4DGeV Y89TXLYo2WkLYtukUydG+uP6pPSFGezLxlRg3SNr+/BJmwr7UbwQ/ipKP1KcVEAYYa2g VJG2EJo3a8bpkKyRo3v2+9+mJOaUPkhSxuzV2FRI+fcabeueEGlABZW8Yz+yjzT/W0Ga 1zJO2ZTq8LhQY/n48HD1PfwTv0H5Ogd4/vVTQ8EnyqkonaOGAolZASLPUJZBpRu+Y+E1 2mLXdWmw4zxd0KJlH28HrEKld7Q9BRuYjBv9IY/XCy46n7MqQ8H43PSab+s8UIJHeP7J CshQ== X-Received: by 10.68.12.97 with SMTP id x1mr844471pbb.150.1375108414069; Mon, 29 Jul 2013 07:33:34 -0700 (PDT) Received: from dhcp-175c.meeting.ietf.org (dhcp-175c.meeting.ietf.org. [130.129.23.92]) by mx.google.com with ESMTPSA id vi8sm77284815pbc.31.2013.07.29.07.33.31 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 07:33:33 -0700 (PDT) Message-ID: <51F67D39.1000907@gmail.com> Date: Mon, 29 Jul 2013 16:33:29 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 References: <51DFBCAE.1090904@gmail.com> <51F62737.3020505@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: "mpls@ietf.org" , ccamp@ietf.org Subject: Re: [CCAMP] [mpls] Fwd: Fwd: I-D Action: draft-helvoort-ccamp-fs-priority-00.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 14:33:59 -0000 Yaacov, hi, You wrote: > While I understand (and to a certain extent support) the purpose of this > document, I am not sure that the note that you are proposing in Section > 2 of the document really clarifies the definitions of what are the > priorities. OK, I hope you mean that more clarification is needed for when the priority FS over SF-P or SF-P over FS are used. > Based on the Rosetta Stone document - a "Communication Channel" is any > logical connection between NEs that may be used for management or > control plane applications. In theory this includes (to my > understanding) any use of the GACH as defined for MPLS-TP (e.g. any OAM > functionality). I think I understand the confusion. I wanted to make a difference between protection switching applications that rely on a control plane, and protection switching applications that rely on an in-band protocol which fate shares with the protection path. > Your note states: "For 1+1 protection schemes (which do not use a > communication channel)" - > > * what are these? Is there a protection scheme for MPLS-TP that do not > use a communication channel - for example for CC or CV messages? If > you meant to say that they are not dependent upon a coordination > protocol (similar to the statement in the ITU documentation that > refers to APS) then I suggest that you clearly state this. As I explained above I wanted to differentiate between a coordination protocol that uses a control plane, and one that fate shares with the protection path. > * However, are you adding a blanket statement that 1+1 protection > schemes do not use a coordination protocol? This is news to me, > since to the best of my recollection both ITU Ethernet Linear > Protection and RFC6378 define support for 1+1 protection, don't they? This was not my intention. > Might I suggest that you adhere more closely to the language of the ITU > definition and state that if a coordination protocol is being used then > SF-P priority is higher than FS. I will try to captuture this more clearly. > Hope this helps, It did, thanks, Huub. ======= > On Mon, Jul 29, 2013 at 11:26 AM, Huub van Helvoort > > wrote: > > Hello MPLS, > > I noticed that I did not send this notification to the MPLS > list at the same time as I sent it to CCAMP. > > This concerns/addresses priorities in linear protection. > > Best regards, Huub. > > -------- Original Message -------- > Subject: Fwd: I-D Action: draft-helvoort-ccamp-fs-__priority-00.txt > Date: Fri, 12 Jul 2013 10:22:06 +0200 > From: Huub van Helvoort > > Reply-To: huubatwork@gmail.com > To: CCAMP > > > Hello CCAMP, > > Based on the messages on the MPLS list: > http://www.ietf.org/mail-__archive/web/mpls/current/__msg09913.html > > http://www.ietf.org/mail-__archive/web/mpls/current/__msg09916.html > > > I have created and uploaded the draft below. > Comments are appreciated. > > Best regards, Huub. > > -------- Original Message -------- > Subject: I-D Action: draft-helvoort-ccamp-fs-__priority-00.txt > Date: Fri, 12 Jul 2013 01:01:39 -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 : Update Forced Switch Priority > Author(s) : Huub van Helvoort > Filename : draft-helvoort-ccamp-fs-__priority-00.txt > Pages : 4 > Date : 2013-07-12 > > Abstract: > This document clarifies the definitions related to Manual Switch and > Forced Switch. This document updates RFC 4427. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/__doc/draft-helvoort-ccamp-fs-__priority > > There's also a htmlized version available at: > http://tools.ietf.org/html/__draft-helvoort-ccamp-fs-__priority-00 > > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-__drafts/ > > > _________________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/__listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.__html > > or ftp://ftp.ietf.org/ietf/__1shadow-sites.txt > > > > > > _________________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/__listinfo/mpls > > > > > > -- > Thanx and BR, > yaacov > > /Still looking for new opportunity/ -- ***************************************************************** 请记住，你是独一无二的，就像其他每一个人一样 From lsmt@ietf.org Mon Jul 29 07:49:45 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CD8821F9D09; Mon, 29 Jul 2013 07:49: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 AF6ZRpu01yUW; Mon, 29 Jul 2013 07:49:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FCA721F997B; Mon, 29 Jul 2013 07:49:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: Liaison Statement Management Tool To: Lou Berger , Deborah Brungard X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130729144943.25577.47185.idtracker@ietfa.amsl.com> Date: Mon, 29 Jul 2013 07:49:43 -0700 Cc: Common Control and Measurement Plane Discussion List Subject: [CCAMP] New Liaison Statement, "Liaison Statement on Corrigendum of OTN terminology Recommendation" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 14:49:45 -0000 Title: Liaison Statement on Corrigendum of OTN terminology Recommendation Submission Date: 2013-07-23 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1270/ From: ITU-T SG 15 (Yoshinori Koike ) To: Common Control and Measurement Plane (Lou Berger , De= borah Brungard ) Cc: Stewart Bryant ,Adrian Farrel = ,Common Control and Measurement Plane Discussion List ,John= Drake ,Scott Mansfield Reponse Contact: = Technical Contact: = Purpose: For information Body: = Attachments: Liaison Statement on Corrigendum of OTN terminology Recommendation https://datatracker.ietf.org/documents/LIAISON/liaison-2013-07-23-itu-t= -sg-15-ccamp-liaison-statement-on-corrigendum-of-otn-terminology-recommenda= tion-attachment-1.pdf Draft Corrigendum 1 to Recommendation ITU-T G.870/Y.1352 (2012) (for Co= nsent, July 2013) https://datatracker.ietf.org/documents/LIAISON/liaison-2013-07-23-itu-t= -sg-15-ccamp-liaison-statement-on-corrigendum-of-otn-terminology-recommenda= tion-attachment-2.pdf From lsmt@ietf.org Mon Jul 29 08:17:34 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F8C21F9C72; Mon, 29 Jul 2013 08:17:33 -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 rFi07Fh7Nszx; Mon, 29 Jul 2013 08:17:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F9611E80FB; Mon, 29 Jul 2013 08:17:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: Liaison Statement Management Tool To: Lou Berger , Deborah Brungard X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130729151731.25593.84695.idtracker@ietfa.amsl.com> Date: Mon, 29 Jul 2013 08:17:31 -0700 Cc: Common Control and Measurement Plane Discussion List Subject: [CCAMP] New Liaison Statement, "Liaison Statement on additional optical link management capabilities" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 15:17:34 -0000 Title: Liaison Statement on additional optical link management capabilities Submission Date: 2013-07-23 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1271/ From: ITU-T SG 15 (Mark Jones ) To: Common Control and Measurement Plane (Lou Berger , De= borah Brungard ) Cc: Stewart Bryant ,Adrian Farrel = ,Common Control and Measurement Plane Discussion List ,John= Drake ,Scott Mansfield Reponse Contact: = Technical Contact: = Purpose: For information Body: = Attachments: Liaison Statement on additional optical link management capabilities https://datatracker.ietf.org/documents/LIAISON/liaison-2013-07-23-itu-t= -sg-15-ccamp-liaison-statement-on-additional-optical-link-management-capabi= lities-attachment-1.pdf From lsmt@ietf.org Tue Jul 30 03:21:46 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96B9121E80C8; Tue, 30 Jul 2013 03:21:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.201 X-Spam-Level: X-Spam-Status: No, score=-102.201 tagged_above=-999 required=5 tests=[AWL=-0.399, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_SUB_RAND_LETTRS4=0.799, 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 niF35WMC8hVB; Tue, 30 Jul 2013 03:21:46 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 870FB21E80C4; Tue, 30 Jul 2013 03:21:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: Liaison Statement Management Tool To: Lou Berger , Deborah Brungard X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130730102144.12496.24208.idtracker@ietfa.amsl.com> Date: Tue, 30 Jul 2013 03:21:44 -0700 Cc: Common Control and Measurement Plane Discussion List Subject: [CCAMP] New Liaison Statement, "Liaison Statement on the SG15 OTNT Standardization Work Plan - ccamp" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 10:21:46 -0000 Title: Liaison Statement on the SG15 OTNT Standardization Work Plan - ccamp Submission Date: 2013-07-23 URL of the IETF Web page: http://datatracker.ietf.org/liaison/1276/ Please reply by 2014-03-07 From: ITU-T SG 15 (Yoshinori Koike ) To: Common Control and Measurement Plane (Lou Berger , De= borah Brungard ) Cc: Stewart Bryant ,Adrian Farrel = ,Common Control and Measurement Plane Discussion List ,John= Drake ,Scott Mansfield Reponse Contact: = Technical Contact: = Purpose: For comment Body: = Attachments: Liaison Statement on the SG15 OTNT Standardization Work Plan https://datatracker.ietf.org/documents/LIAISON/liaison-2013-07-23-itu-t= -sg-15-ccamp-liaison-statement-on-the-sg15-otnt-standardization-work-plan-c= camp-attachment-1.pdf Draft Revised Optical Transport Networks & Technologies Standardization= Work Plan, Issue 17 https://datatracker.ietf.org/documents/LIAISON/liaison-2013-07-23-itu-t= -sg-15-ccamp-liaison-statement-on-the-sg15-otnt-standardization-work-plan-c= camp-attachment-2.pdf From lberger@labn.net Tue Jul 30 04:32:37 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161B211E80F7 for ; Tue, 30 Jul 2013 04:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.502 X-Spam-Level: X-Spam-Status: No, score=-101.502 tagged_above=-999 required=5 tests=[AWL=0.763, 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 9E5mfRzUARE2 for ; Tue, 30 Jul 2013 04:32:32 -0700 (PDT) Received: from oproxy7-pub.bluehost.com (oproxy7-pub.bluehost.com [67.222.55.9]) by ietfa.amsl.com (Postfix) with SMTP id 1AEB821F9E3F for ; Tue, 30 Jul 2013 04:32:31 -0700 (PDT) Received: (qmail 25516 invoked by uid 0); 30 Jul 2013 11:32:01 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 30 Jul 2013 11:32:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:Content-Transfer-Encoding:Date:MIME-Version:Message-ID:Cc:To:Subject:From; bh=/kCKrR9tBKOm4Bw2/0pRjbePXIQnSFBFtNQ7lY5lODs=; b=acur8u3xvX0HHzHHLFo7OnIgr7okGXK9W9wPQk4zYgYMfkcqyalXrOEWxkFKYURVMbfp8Hys00R/c1F2EjDBI9UB/KqNaY0L78nf4wsCjDM8YsX7GJWPQ6YgxLCHM9op; Received: from [69.89.31.113] (port=34696 helo=localhost) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V489p-0006FV-3L; Tue, 30 Jul 2013 05:32:01 -0600 From: Lou Berger To: Message-ID: <6700accc.1375182901959@mail.labn.net> MIME-Version: 1.0 Date: Tue, 30 Jul 2013 13:31:09 +0200 (CEST) User-Agent: ProfiMailGo/4.10.00 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ccamp@ietf.org Subject: Re: [CCAMP] Question about draft-ietf-ccamp-otn-g709-info-model-09.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 11:32:37 -0000 Hi Adrian, So IS-IS is certainly still a viable GMPLS routing protocol and it should be mentioned in the draft as a possibility. Good catch. The more general issue with GMPLS IS-IS, from my perspective, is that there hasn't been much interest in working on related drafts in the WG. GMPLS IS-IS remains in scope, but drafts aren't being written. I take this as the market "speaking". Lou On 10:29am, July 28, 2013, Adrian Farrel wrote: > Hi CCAMP, > > I am currently reviewing draft-ietf-ccamp-otn-g709-info-model-09.txt (cunningly > deceptive file name ;-) > > I have a question... > > The document makes reference to RFC 4202 and RFC 4203, but not to RFC 5307 > (obsoleted RFC 4205). Can I ask why CCAMP no longer considers IS-IS to be a > potential routing protocol for GMPLS systems? > > Thanks, > > Adrian > > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From kpithewan@infinera.com Tue Jul 30 07:26:01 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3143911E81F7 for ; Tue, 30 Jul 2013 07:26: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, 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 snzJB+wON24M for ; Tue, 30 Jul 2013 07:25:53 -0700 (PDT) Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2D94621F9CFB for ; Tue, 30 Jul 2013 07:25:21 -0700 (PDT) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.03.0123.003; Tue, 30 Jul 2013 07:25:20 -0700 From: Khuzema Pithewan To: "CCAMP (ccamp@ietf.org)" Thread-Topic: draft-ali-ccamp-lsp-inquiry-00 Thread-Index: Ac6NL9ROMXULLvcwR2aMbEKex7ZPbA== Date: Tue, 30 Jul 2013 14:25:19 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.156.118] Content-Type: multipart/alternative; boundary="_000_D8D01B39D6B38C45AA37C06ECC1D65D53FDD05A8SVEXDBPROD1infi_" MIME-Version: 1.0 Subject: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 14:26:02 -0000 --_000_D8D01B39D6B38C45AA37C06ECC1D65D53FDD05A8SVEXDBPROD1infi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors, The draft relies on ability to setup GMPLS lsp without committing resources= in dataplane. Only reference I found to setup pre-planned GMPLS is in RFC 6001. The green highlighted part says it is not possible to support 0 bandwidth l= sp for TDM/LSC network. While red part alludes that it can be done. Also I couldn' locate the text in any RFC that describes the NULL label beh= avior in GMPLS context. RFC6001 5.2.2 says ................snip................... However, mechanisms for provisioning (pre-planned or not) a TDM or LSC LSP with 0 bandwidth is currently not possible because the exchanged label value is tightly coupled with resource allocation during LSP signaling (e.g., see [RFC4606] for a SONET/SDH LSP). For TDM and LSC LSP, a NULL Label value is used to prevent resource allocation at the data plane level. In these cases, upon LSP resource commitment, actual label value exchange is performed to commit allocation of timeslots/ wavelengths. .......................snip.................... Khuzema --_000_D8D01B39D6B38C45AA37C06ECC1D65D53FDD05A8SVEXDBPROD1infi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Authors,

 

The draft relies on ability to setup GMPLS lsp witho= ut committing resources in dataplane.

 

Only reference I found to setup pre-planned GMPLS is= in RFC 6001.

 

The green highlighted part says it is not possible t= o support 0 bandwidth lsp for TDM/LSC network. While red part alludes that = it can be done.

 

Also I couldn’ locate the text in any RFC that= describes the NULL label behavior in GMPLS context.

 

 

RFC6001 5.2.2 says

 

…………….snip…̷= 0;………….

 

H= owever, mechanisms for provisioning (pre-planned or not) a TDM or

&= nbsp;  LSC LSP with 0 bandwidth is currently not possible because the<= o:p>

&= nbsp;  exchanged label value is tightly coupled with resource allocati= on

&= nbsp;  during LSP signaling (e.g., see [RFC4606] for a SONET/SDH LSP).=   For

&nb= sp;  TDM and LSC LSP, a NULL Label value is used to prevent resource

&nb= sp;  allocation at the data plane level.  In these cases, = upon LSP

   resource commitment, actual label value= exchange is performed to

   commit allocation of timeslots/ wavelen= gths.

 

…………………..s= nip………………..

 

 

Khuzema

--_000_D8D01B39D6B38C45AA37C06ECC1D65D53FDD05A8SVEXDBPROD1infi_-- From kpithewan@infinera.com Tue Jul 30 07:43:59 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 407E311E8214 for ; Tue, 30 Jul 2013 07:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADbcMTFUT0mc for ; Tue, 30 Jul 2013 07:43:53 -0700 (PDT) Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3DC2F11E8205 for ; Tue, 30 Jul 2013 07:43:49 -0700 (PDT) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.03.0123.003; Tue, 30 Jul 2013 07:43:48 -0700 From: Khuzema Pithewan To: "CCAMP (ccamp@ietf.org)" Thread-Topic: draft-ali-ccamp-rsvp-te-include-route-04 Thread-Index: Ac6NMx+p2RAMz7T3QPeg+VDERTEEPA== Date: Tue, 30 Jul 2013 14:43:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.156.118] Content-Type: multipart/alternative; boundary="_000_D8D01B39D6B38C45AA37C06ECC1D65D53FDD05ECSVEXDBPROD1infi_" MIME-Version: 1.0 Subject: [CCAMP] draft-ali-ccamp-rsvp-te-include-route-04 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 14:43:59 -0000 --_000_D8D01B39D6B38C45AA37C06ECC1D65D53FDD05ECSVEXDBPROD1infi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Authors, For LSP sub-objects, there needs to be validations that ensures that the 2 = loose abstract nodes hops (or 1 loose abstract node followed by with 1 stri= ct hop) before and after the LSP sub-object has to exactly match with that = of LSP being referenced by the sub-object, otherwise, the section of the pa= th from the reference LSP may not be valid for the LSP being setup. Regards Khuzema --_000_D8D01B39D6B38C45AA37C06ECC1D65D53FDD05ECSVEXDBPROD1infi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Authors,

 

For LSP sub-objects, there needs to be validations t= hat ensures that the 2 loose abstract nodes hops (or 1 loose abstract node = followed by with 1 strict hop) before and after the LSP sub-object has to e= xactly match with that of LSP being referenced by the sub-object, otherwise, the section of the path from the = reference LSP may not be valid for the LSP being setup.

 

Regards

Khuzema

--_000_D8D01B39D6B38C45AA37C06ECC1D65D53FDD05ECSVEXDBPROD1infi_-- From adrian@olddog.co.uk Tue Jul 30 08:47:41 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3758021F9C46 for ; Tue, 30 Jul 2013 08:47:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 dvEXrJxrhbY6 for ; Tue, 30 Jul 2013 08:47:35 -0700 (PDT) Received: from asmtp2.iomartmail.com (asmtp2.iomartmail.com [62.128.201.249]) by ietfa.amsl.com (Postfix) with ESMTP id 227A521F9931 for ; Tue, 30 Jul 2013 08:47:34 -0700 (PDT) Received: from asmtp2.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6UFlX78019495 for ; Tue, 30 Jul 2013 16:47:33 +0100 Received: from 950129200 (dhcp-13f0.meeting.ietf.org [130.129.19.240]) (authenticated bits=0) by asmtp2.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6UFlW0q019468 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 30 Jul 2013 16:47:33 +0100 From: "Adrian Farrel" To: Date: Tue, 30 Jul 2013 16:47:31 +0100 Message-ID: <029601ce8d3c$1a76cab0$4f646010$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6NO/KVe3imLWGiRZmFI8XWdhHCOQ== Content-Language: en-gb Subject: [CCAMP] The thing I forgot about draft-ali-ccamp-rsvp-te-include-route X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 15:47:41 -0000 Hi, Sorry about my senility just now. The point I made was please rename the new ERO subobject to avoid confusion about using the referenced LSP as a tunnel or a stitching segment. The point I forgot was to wonder whether there is a category of "best effort" that follows most of the referenced LSP but not all hops? Following that, what if there are specific hops in the referenced LSP that MUST be followed and others that only SHOULD be followed? Cheers, Adrian From daniel@olddog.co.uk Tue Jul 30 10:02:20 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62BB411E80FD for ; Tue, 30 Jul 2013 10:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s+zRZNedVJTi for ; Tue, 30 Jul 2013 10:02:05 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id CED5811E8222 for ; Tue, 30 Jul 2013 10:00:56 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6UH0oT6014640; Tue, 30 Jul 2013 18:00:50 +0100 Received: from Mal ([31.6.35.205]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6UH0m8v014608; Tue, 30 Jul 2013 18:00:49 +0100 From: "Daniel King" To: Date: Tue, 30 Jul 2013 19:00:53 +0200 Message-ID: <024301ce8d46$5aa08720$0fe19560$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0244_01CE8D57.1E29F360" X-Mailer: Microsoft Outlook 15.0 Thread-Index: Ac6NRj2MbBqoNdVcSuOMZ8Fp3xZaDw== Content-Language: en-gb Subject: [CCAMP] IETF87 CCAMP Session 1 Minutes - Questions/Responses X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 17:02:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0244_01CE8D57.1E29F360 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi All, If you were a presenter, or asked a question, during IETF87 CCAMP session 1 would you please review the minutes: http://tools.ietf.org/wg/ccamp/minutes Directly modifying the etherpad minutes to clarify your (actual) question or response would be very much appreciated! Br, Danielle and Dan. ------=_NextPart_000_0244_01CE8D57.1E29F360 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi All,

 

If you were = a presenter, or asked a question, during IETF87 CCAMP session 1 would = you please review the minutes:

 

http://tools.ietf.org/wg/= ccamp/minutes

 

Directly = modifying the etherpad minutes to clarify your (actual) question or = response would be very much appreciated!

 

Br, Danielle = and Dan.

------=_NextPart_000_0244_01CE8D57.1E29F360-- From lberger@labn.net Tue Jul 30 10:31:56 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 226E811E81E8 for ; Tue, 30 Jul 2013 10:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.904 X-Spam-Level: X-Spam-Status: No, score=-100.904 tagged_above=-999 required=5 tests=[AWL=-0.599, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 BEdUrj5wjNr4 for ; Tue, 30 Jul 2013 10:31:45 -0700 (PDT) Received: from oproxy5.bluehost.com (oproxy5-pub.bluehost.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id E66C111E81D4 for ; Tue, 30 Jul 2013 10:31:43 -0700 (PDT) Received: (qmail 5499 invoked by uid 0); 30 Jul 2013 17:31:17 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy5.bluehost.com with SMTP; 30 Jul 2013 17:31:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=r8+QWvkCtwX4aLrWOG3o3QO/qafdVrB1Zx4M8x4YXjY=; b=pHjgOO612OJvPB9tZhB2E6RLF6vM4DP3OiE3s5Dg/vGs7xQi9/Mrk+ETWuD0r4kaTG/MS5DN5exx/N+dbfQXffWtdrVwU2eoDYcOiAmRO+zuH/GSj8OFebs5CEVaCrkT; Received: from box313.bluehost.com ([69.89.31.113]:41410 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V4DlU-0001hq-Ne; Tue, 30 Jul 2013 11:31:16 -0600 Message-ID: <51F7F863.2080702@labn.net> Date: Tue, 30 Jul 2013 19:31:15 +0200 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: CCAMP X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: draft-ietf-ccamp-te-metric-recording@tools.ietf.org, draft-ietf-ccamp-rsvp-te-srlg-collect@tools.ietf.org Subject: [CCAMP] on consistent representation of upstream/downstream information in ROs X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 17:31:56 -0000 Authors/WG, I notice that the above drafts don't quite follow how upstream/downstream label ROs are identified in RFC3473, i.e. separate objects with direction identified using the U-bit. Is there any objection to using this same identification approach in both drafts? (Certainly there's a tradeoff of consistency vs optimal bidirection/unidirectional representation, but I think consistency wins with so little difference in this case.) Thanks, Lou From kpithewan@infinera.com Tue Jul 30 10:40:55 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 269D311E821D for ; Tue, 30 Jul 2013 10:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsxpo7YkbMI8 for ; Tue, 30 Jul 2013 10:40:49 -0700 (PDT) Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id BFD7F11E81F7 for ; Tue, 30 Jul 2013 10:40:49 -0700 (PDT) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.03.0123.003; Tue, 30 Jul 2013 10:40:47 -0700 From: Khuzema Pithewan To: Khuzema Pithewan , "CCAMP (ccamp@ietf.org)" Thread-Topic: draft-ali-ccamp-lsp-inquiry-00 Thread-Index: Ac6NL9ROMXULLvcwR2aMbEKex7ZPbAAG5uQw Date: Tue, 30 Jul 2013 17:40:47 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.156.108] Content-Type: multipart/alternative; boundary="_000_D8D01B39D6B38C45AA37C06ECC1D65D53FDD183BSVEXDBPROD1infi_" MIME-Version: 1.0 Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 17:40:55 -0000 --_000_D8D01B39D6B38C45AA37C06ECC1D65D53FDD183BSVEXDBPROD1infi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Another point I spoke about in the meeting .. Why can't we extend Admin Status object to signal resource locking, checkin= g for re-optimization. Since this operation is typically done in maintenanc= e window by Admin, it may make sense to use Admin Status Object. Moreover, = we have lots of bits available/undefined in Admin Status object. This will save network element to manage life of additional LSP and control= plane failure related issues attached to the additional LSP. Khuzema From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of K= huzema Pithewan Sent: Tuesday, July 30, 2013 4:25 PM To: CCAMP (ccamp@ietf.org) Subject: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Authors, The draft relies on ability to setup GMPLS lsp without committing resources= in dataplane. Only reference I found to setup pre-planned GMPLS is in RFC 6001. The green highlighted part says it is not possible to support 0 bandwidth l= sp for TDM/LSC network. While red part alludes that it can be done. Also I couldn' locate the text in any RFC that describes the NULL label beh= avior in GMPLS context. RFC6001 5.2.2 says ................snip................... However, mechanisms for provisioning (pre-planned or not) a TDM or LSC LSP with 0 bandwidth is currently not possible because the exchanged label value is tightly coupled with resource allocation during LSP signaling (e.g., see [RFC4606] for a SONET/SDH LSP). For TDM and LSC LSP, a NULL Label value is used to prevent resource allocation at the data plane level. In these cases, upon LSP resource commitment, actual label value exchange is performed to commit allocation of timeslots/ wavelengths. .......................snip.................... Khuzema --_000_D8D01B39D6B38C45AA37C06ECC1D65D53FDD183BSVEXDBPROD1infi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Another point I spoke = about in the meeting ..

 

Why can’t we ext= end Admin Status object to signal resource locking, checking for re-optimiz= ation. Since this operation is typically done in maintenance window by Admi= n, it may make sense to use Admin Status Object. Moreover, we have lots of bits available/undefined in Admin Status object.=

 

This will save network= element to manage life of additional LSP and control plane failure related= issues attached to the additional LSP.

 

Khuzema

 

From: ccamp-bo= unces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Khuzema Pithewan
Sent: Tuesday, July 30, 2013 4:25 PM
To: CCAMP (ccamp@ietf.org)
Subject: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Authors,

 

The draft relies on ability to setup GMPLS lsp witho= ut committing resources in dataplane.

 

Only reference I found to setup pre-planned GMPLS is= in RFC 6001.

 

The green highlighted part says it is not possible t= o support 0 bandwidth lsp for TDM/LSC network. While red part alludes that = it can be done.

 

Also I couldn’ locate the text in any RFC that= describes the NULL label behavior in GMPLS context.

 

 

RFC6001 5.2.2 says

 

…………….snip…̷= 0;………….

 

H= owever, mechanisms for provisioning (pre-planned or not) a TDM or

&= nbsp;  LSC LSP with 0 bandwidth is currently not possible because the<= o:p>

&= nbsp;  exchanged label value is tightly coupled with resource allocati= on

&= nbsp;  during LSP signaling (e.g., see [RFC4606] for a SONET/SDH LSP).=   For

&nb= sp;  TDM and LSC LSP, a NULL Label value is used to prevent resource

&nb= sp;  allocation at the data plane level.  In these cases, = upon LSP

   resource commitment, actual label value= exchange is performed to

   commit allocation of timeslots/ wavelen= gths.

 

…………………..s= nip………………..

 

 

Khuzema

--_000_D8D01B39D6B38C45AA37C06ECC1D65D53FDD183BSVEXDBPROD1infi_-- From zali@cisco.com Tue Jul 30 13:08:05 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F3121E80E8 for ; Tue, 30 Jul 2013 13:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FD-Eg7Zmn3Wm for ; Tue, 30 Jul 2013 13:08:00 -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 2701921E80A1 for ; Tue, 30 Jul 2013 13:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6140; q=dns/txt; s=iport; t=1375214880; x=1376424480; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=a0gLx0G7HSLpBJOnEVmcqcCDrZFbqJZzAfh4/HF+7Tk=; b=jR7ExzCD3bj9VZTxXbJamJovr9RU85UNxjXExxHxVz7UUJDpHXYQFGUo gkeNwQuP1CuCGwdYnHkUXB9By3FNWYhs1oYm0maAgbhosZS4Tiq1yAkND 0B93DNfCJZryVU+u986lnaPe7ZnaKdFNzniLHYDpkeEULxQmgW0WVe3SG 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai0FAAIc+FGtJXHA/2dsb2JhbABbgkJENVC+GYEfFnSCJAEBAQQtXgEIDgMDAQILHTkUCQgBAQQBEggRh3e4XY9NIBiDGHEDqSuDFIIq X-IronPort-AV: E=Sophos;i="4.89,780,1367971200"; d="scan'208,217";a="241485041" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 30 Jul 2013 20:07:59 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6UK7xDT026367 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Jul 2013 20:07:59 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.02.0318.004; Tue, 30 Jul 2013 15:07:59 -0500 From: "Zafar Ali (zali)" To: Khuzema Pithewan , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Thread-Index: Ac6NL9ROMXULLvcwR2aMbEKex7ZPbAAG5uQwAAdbOAA= Date: Tue, 30 Jul 2013 20:07:58 +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.2.3.120616 x-originating-ip: [10.82.239.252] Content-Type: multipart/alternative; boundary="_000_B6585D85A128FD47857D0FD58D8120D30E9F39E6xmbrcdx14ciscoc_" MIME-Version: 1.0 Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 20:08:06 -0000 --_000_B6585D85A128FD47857D0FD58D8120D30E9F39E6xmbrcdx14ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Khuzema: The point is to reuse what already exists. The Pre-Planned LSP flag in the = Attribute Flags TLV of LSP_ATTRIBUTES object is already defined in [RFC5420= ] and is a glove fit. Thanks Regards =85 Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 1:40 PM To: Khuzema Pithewan = >, "ccamp@ietf.org" > Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Another point I spoke about in the meeting .. Why can=92t we extend Admin Status object to signal resource locking, check= ing for re-optimization. Since this operation is typically done in maintena= nce window by Admin, it may make sense to use Admin Status Object. Moreover= , we have lots of bits available/undefined in Admin Status object. This will save network element to manage life of additional LSP and control= plane failure related issues attached to the additional LSP. Khuzema --_000_B6585D85A128FD47857D0FD58D8120D30E9F39E6xmbrcdx14ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Khuzema:

The point is to reuse what already exists. The Pre-Planned LSP fl= ag in the Attribute Flags TLV of LSP_ATTRIBUTES object is already defined i= n [RFC5420] and is a glove fit. 

Thanks

Regards =85 Zafar

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Tuesday, July 30, 2013 1:40 P= M
To: Khuzema Pithewan <kpithewan@infinera.com>, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] draft-ali-ccam= p-lsp-inquiry-00

Another point I spoke = about in the meeting ..

 

Why can=92t we extend = Admin Status object to signal resource locking, checking for re-optimizatio= n. Since this operation is typically done in maintenance window by Admin, i= t may make sense to use Admin Status Object. Moreover, we have lots of bits available/undefined in Admin Status object.=

 

This will save network= element to manage life of additional LSP and control plane failure related= issues attached to the additional LSP.

 

Khuzema

 

 --_000_B6585D85A128FD47857D0FD58D8120D30E9F39E6xmbrcdx14ciscoc_-- From kpithewan@infinera.com Tue Jul 30 14:45:59 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35DDD11E814B for ; Tue, 30 Jul 2013 14:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBxqe9sQZZuX for ; Tue, 30 Jul 2013 14:45:53 -0700 (PDT) Received: from sv-casht-prod1.infinera.com (sv-casht-prod1.infinera.com [8.4.225.24]) by ietfa.amsl.com (Postfix) with ESMTP id B7FD411E8141 for ; Tue, 30 Jul 2013 14:45:53 -0700 (PDT) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod1.infinera.com ([10.100.97.218]) with mapi id 14.03.0123.003; Tue, 30 Jul 2013 14:45:53 -0700 From: Khuzema Pithewan To: "Zafar Ali (zali)" , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Thread-Index: Ac6NL9ROMXULLvcwR2aMbEKex7ZPbAAG5uQwAAdbOAAAAUWKEA== Date: Tue, 30 Jul 2013 21:45:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.156.108] Content-Type: multipart/alternative; boundary="_000_D8D01B39D6B38C45AA37C06ECC1D65D53FDD1A47SVEXDBPROD1infi_" MIME-Version: 1.0 Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 21:45:59 -0000 --_000_D8D01B39D6B38C45AA37C06ECC1D65D53FDD1A47SVEXDBPROD1infi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Well.. not really. You are defining new bits for LSP_ATTRIBUTES for resource locking... aren't= you? Instead of doing that, you can define bits in ADMIN_STATUS and save new LSP= life cycle management, which would be quite cumbersome. Regards Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Tuesday, July 30, 2013 10:08 PM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Khuzema: The point is to reuse what already exists. The Pre-Planned LSP flag in the = Attribute Flags TLV of LSP_ATTRIBUTES object is already defined in [RFC5420= ] and is a glove fit. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 1:40 PM To: Khuzema Pithewan = >, "ccamp@ietf.org" > Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Another point I spoke about in the meeting .. Why can't we extend Admin Status object to signal resource locking, checkin= g for re-optimization. Since this operation is typically done in maintenanc= e window by Admin, it may make sense to use Admin Status Object. Moreover, = we have lots of bits available/undefined in Admin Status object. This will save network element to manage life of additional LSP and control= plane failure related issues attached to the additional LSP. Khuzema --_000_D8D01B39D6B38C45AA37C06ECC1D65D53FDD1A47SVEXDBPROD1infi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Well.. not really.

 

You are defining new b= its for LSP_ATTRIBUTES for resource locking… aren’t you?

 

Instead of doing that,= you can define bits in ADMIN_STATUS and save new LSP life cycle management= , which would be quite cumbersome.

 

Regards

Khuzema

 

From: Zafar Al= i (zali) [mailto:zali@cisco.com]
Sent: Tuesday, July 30, 2013 10:08 PM
To: Khuzema Pithewan; CCAMP (ccamp@ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Khuzema= :

&n= bsp;

The poi= nt is to reuse what already exists. The Pre-Planned LSP flag in the At= tribute Flags TLV of LSP_ATTRIBUTES object is already defined in [RFC5420] = and is a glove fit. 

&n= bsp;

Thanks<= o:p>

&n= bsp;

Regards= … Zafar

&n= bsp;

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Tuesday, July 30, 2013 1:40 PM
To: Khuzema Pithewan <k= pithewan@infinera.com>, "ccam= p@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

&n= bsp;

Another point I spoke = about in the meeting ..

 

Why can’t we ext= end Admin Status object to signal resource locking, checking for re-optimiz= ation. Since this operation is typically done in maintenance window by Admi= n, it may make sense to use Admin Status Object. Moreover, we have lots of bits available/undefined in Admin Status object.=

 

This will save network= element to manage life of additional LSP and control plane failure related= issues attached to the additional LSP.<= o:p>

 

Khuzema

 

--_000_D8D01B39D6B38C45AA37C06ECC1D65D53FDD1A47SVEXDBPROD1infi_-- From lberger@labn.net Tue Jul 30 15:17:01 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7E9911E81ED for ; Tue, 30 Jul 2013 15:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.384 X-Spam-Level: X-Spam-Status: No, score=-101.384 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_44=0.6, 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 cpsYBiEHC7k8 for ; Tue, 30 Jul 2013 15:16:57 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id 3E51011E8125 for ; Tue, 30 Jul 2013 15:16:56 -0700 (PDT) Received: (qmail 6034 invoked by uid 0); 30 Jul 2013 22:16:33 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 30 Jul 2013 22:16:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=fx+ntnImSmsCJUjkQD96//y77ch9GH4Y47505cbD218=; b=e+yC8bevtX07YNneInU7EuOsja6uM4vaXU5FtK00XSKzgRHlAxe8Yo0Yc1Kgt0WETjErwb+a04PRCEtb2RZkNWlt5XwD1nBQ+nh1Kd3h/PikC46rJ39qPPZwVSwQWvJt; Received: from box313.bluehost.com ([69.89.31.113]:35912 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V4IDZ-0005Eo-3h; Tue, 30 Jul 2013 16:16:33 -0600 Message-ID: <51F83B40.8000906@labn.net> Date: Tue, 30 Jul 2013 18:16:32 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: ccamp@ietf.org References: <024301ce8d46$5aa08720$0fe19560$@olddog.co.uk> In-Reply-To: <024301ce8d46$5aa08720$0fe19560$@olddog.co.uk> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: Re: [CCAMP] IETF87 CCAMP Session 1 Minutes - Questions/Responses X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 22:17:01 -0000 I've enclosed the raw notes from etherpad below for those who might be interested. It would be best to enter corrections directly into etherpad. Discussions/additions not said int he meeting should take place on list. Thanks, On 07/30/2013 01:00 PM, Daniel King wrote: > Hi All, > > If you were a presenter, or asked a question, during IETF87 CCAMP > session 1 would you please review the minutes: > http://tools.ietf.org/wg/ccamp/minutes > Directly modifying the etherpad minutes to clarify your (actual) > question or response would be very much appreciated! > Br, Danielle and Dan. > > CCAMP Agenda For IETF 87 > CCAMP Agenda For IETF 87 > Version: Jul 22, 2013 > > First Session > TUESDAY, July 30, 2013 > 1700-1830 Afternoon Session III > Room: Potsdam 3 > Presentation Start Time Duration Information > 0 17:00 10 Title: Administrivia & WG Status > Draft: > Presenter: Chairs Fatai Zhang: After this meeting we plan to update [draft-ietf-ccamp-otn-g709-info-model] and [draft-ietf-ccamp-gmpls-g709-framework] based on AD (Adrian Farrel) review. Comments requeested on non presented WG drafts status: ‒ draft-ietf-ccamp-rsvp-te-srlg-collect Oscar: The document is stable. There is one functionality (knowing if a RRO suboject is incomplete or has been edited) that needs to be made generic (there was a comment from Lou during IETF 86th). A mail was sent on 4th of July with several options to make the functionality generic. A new mail to the CCAMP list will be sent this with the options. Feedback is requested from the CCAMP list. ‒ draft-ietf-ccamp-rsvp-te-li-lb: Daniele: No changes from last meeting > 1 17:10 8 Title: LSP Attribute in ERO > Draft: http://tools.ietf.org/html/draft-ietf-ccamp-lsp-attribute-ro-02 > Presenter: Cyril Margaria Lou Berger: I suspect that you addressed Adrian's [Farrel) comment. I suggest you check with him via the list to confirm. > 2 17:18 8 Title: RSVP-TE Extensions for Associated Bidirectional LSPs > Draft: http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-06 > Presenter: Matt Hartley Lou Berger: I think we can move rapidly towards Last Call. Matt Hartley: Splendid. > 3 17:26 8 Title: RSVP-TE extension for recording TE Metric of a LSP > Draft: http://tools.ietf.org/html/draft-ietf-ccamp-te-metric-recording-02 > Presenter: George Swallow Oscar: Regarding IANA requestsCollision with IANA assignment. We need to align on temporary assignments to avoid collisions. George: Daniele: How about we merge the drafts to minmised the number of drafts to read? George: We intially had this plan, but we wanted to avoid holding up the other draft. Lou: Regarding IANA assinments, are you having similar issues in MPLS? (re collision of temporary assignments values). We used to have the wiki which has not been touched for a long time. George: I fully support it. Dan: We used to do that but our AD suggested to stop. Lou: It's not temporary assignment it is just a way to ensure that documents do no collide and avoid implementation issues. We will discuss this with Adrian Farrel. Do we have someone who will take resposnbility for the CCAMP page? Oscar: I volunteer. Lou Berger: We think it would be a good idea to resurrect the wiki Adrian: Different times wrt RFC4020. People wanted to implement and start interop. Now that we support early allcoation which gives a codepoint for 2 years i don't think we need allocations outside IANA. WHat happens if we screw up that registry? George Swallow: We will caveat the request. Adrian Farrel: Why not go that extra bit further and requst an early allocation. We should talk in more details chairs and ADs. Loa Andersson: Suggestion: ask the WG chairs if the draft is stable enough to start developemen, then request an early allocation. Adrian Farrel: I suggest that if I am uneasy with this the IESG may also have issues. We can take take this discussion offline (with CCAMP and MPLS chairs). > 4 17:34 8 Title: RSVP-TE LSP Route Diversity using Exclude Routes > Draft: http://tools.ietf.org/html/draft-ietf-ccamp-lsp-diversity-02 > Presenter: George Swallow Fatai: I understand the motivation, but I have an issue with the comp0lext solution. Why not use existing solution like path-key? George: The oeprator may not be using PCE. We did discuss the solution early on before this document became a WG document. Deborah: Make sure you read the document and trigger discussion on the list, not wait for the meeting. > 5 17:42 6 Title: Include Routes - Extension to RSVP-TE > Draft: http://tools.ietf.org/html/draft-ali-ccamp-rsvp-te-include-route-04 > Presenter: George Swallow Khuzema: There are elements (constraints) influencing a section or complete path of an LSP, these need to be managed. George: If you cannot meet all the existing contraints, as well ameet diverse objective, then an error will be issued. This is described in the document. Lou: another XRO might be present and you need to consider it. Adrian: Suggest that you rename subobject. As there might be confusion. george: An easy change, do you have an suggestion? Lou: "Inclusion"? George: "Follow the breadcrumb"? Ok, we (authors) will discuss. > 6 17:48 5 Title: RSVP-TE Extension for Label Switched Path (LSP) Inquiry > Draft: http://tools.ietf.org/html/draft-ali-ccamp-lsp-inquiry-00 > Presenter: George Swallow Lou Berger: Off course reusing exisitng mechnisms is good, if you manage to reuse also existing terminology it's better. George: Yes. Khuzema: This will affect existing services. Geoirge: This is signaled from the IP plane, so we assume that you are in a maintenance window. Dieter: There are technologies out there that allow soft set up of resources. Are you envisaging to cover also those technologies? George: We see this being used for shared mesh protection in optical enviroments. Dieter: I'm talking about technologies that in tens of ms are able to tear down an LSP and setup the protecting one. Xian: I don't follow the motivation for the secon type of inquiry. What is its usage? Have you considered using calls? George: I'm not familiar with that particular mechanism. Lou: Not sure how it would help. > 7 17:53 5 Title: RSVP-TE Extension for Signaling Objective Function and Metric Bound > Draft: http://tools.ietf.org/html/draft-ali-ccamp-rc-objective-function-metric-bound-03 > Presenter: George Swallow Lou: how many people think it's a useful function (good number) How many read? (slightly less) How many think this is a gpood foundation? (slightly less) Cyril: Oscar: Not only in this draft but in others you add path computation constraints like include/exclude things. When path computation is done in the middle of the network one may want to pass all the path computation constraints in RSVP-TE. However, in the proposal, you are duplicating PCEP objects. Lou; we followed the approach that we can distribute path computatoin. OScar: Not what I meant. I mean that if there is already a complete syntax to express path compuations constraints, inclusions/exclusions, etc, why dont't reuse it? Lou: Can you make this suggestion on the list? Fatai: not sure about the value of this draft. > 8 17:58 5 Title: RSVP-TE Signaling Extension for Bandwidth availability > Draft: http://tools.ietf.org/html/draft-long-ccamp-rsvp-te-bandwidth-availability-01 > Presenter: Min Ye Lou: See the TSV WG [Tunnel Congestion I-D?], there could be overlap with your draft. Khuzema: you might end up multiple lenghts to satisfy a bandwdith request. > 9 18:03 5 Title: OSPF Routing Extension for links with variable discrete bandwidth > Draft: http://tools.ietf.org/html/draft-long-ccamp-ospf-availability-extension-00 > Presenter: Min Ye Matt: Should this be an OSPF WG draft? Lou: in the past we agreed with the OSPF chairs that it is possible to make OSPF changes in CCAMP. > 10 18:08 7 Title: Domain Subobjects for Resource ReserVation Protocol – Traffic Engineering (RSVP-TE) > Draft: http://tools.ietf.org/html/draft-dhody-ccamp-rsvp-te-domain-subobjects-02 > Presenter: Dhruv Dhody Deborah: [Poll] How many think it's useful? [good number], How many have read [good number] Take to the list > 11 18:15 5 Title: A SNMP MIB to manage GMPLS with General Constraints Support > Draft: http://tools.ietf.org/html/draft-gmggm-ccamp-gencons-snmp-mib-02 > Presenter: Giovanni Martinelli Lou: I think this document is timed perfectly in relation to the WSON work. Fatai: General comment. When do we need MIB drafts? Do we need it in this case? Some MIB drafts are on the CCAMP page and are not updated for years. Deborah: Some people use SNMP as management interface, some others use different management protocols Adrian: You are not required to write MIB modules. You are required to discuss how your network may be managed. > 12 18:20 5 Title: Information Model for WSONs with Impairments Validation > Draft: http://tools.ietf.org/html/draft-martinelli-ccamp-wson-iv-info-02 > Presenter: Giovanni Martinelli Dieter: Considering we do not have data plane interop, and a computation capability to compute end-to-end, find this work a little early? Giovanni: What do you mean that there is no data plane compatibility? The answer from ITU-T folks was that there could be some multivendor case. Dieter From the discussoin in Orlando interop is not currrently capable, so is development of an information model too soon? Giovanni: THe compatibility will come, we cannot make any public statement now. THere are some parameters that no one cares how are computed. Dieter: We are supposed to develop standard that provide interoperability Giovanni: Yes. At the control plane. Deborah: I suggest to talk with Q6 guys. Interim meerting, to hlpe define. > 13 18:25 5 Title: Information Encoding for WSON with Impairments Validation > Draft: http://tools.ietf.org/html/draft-martinelli-ccamp-wson-iv-encode-02 > Presenter: Giovanni Martinelli No comments. > Adjourn 18:30 From zali@cisco.com Tue Jul 30 17:16:47 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B35911E8139 for ; Tue, 30 Jul 2013 17:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPbT0NFRgEfr for ; Tue, 30 Jul 2013 17:16:41 -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 F146C21E80AE for ; Tue, 30 Jul 2013 17:16:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=52976; q=dns/txt; s=iport; t=1375229798; x=1376439398; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=eqQxlesIFloZ0dwX3L5Qxr8MJWN8zIwqoTLqjt07fhU=; b=NrTsUX94/wQ8V8uzLf5wrQK+GkQfz2ffR3CvhjXgmEr8mHlzCZPRbTta 0KVtTTCtHvuynN0MY82G63JJyZpK10BlqzopelKLT9a6H7qYKEHBpBxAA GuTz7/Dd+bTlRoP5bcsW5xS3tt0t1EoPlQXELWYqU0WwV15z8RXhZQjUt w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAA5X+FGtJXG8/2dsb2JhbABbgkJENVC+GIEfFnSCJAEBAQQtXgEIDgMDAQEBCxYBBjkUCQgBAQQBEggRh3e4bo9NIBcBgxhxA6krgxSCKg X-IronPort-AV: E=Sophos;i="4.89,782,1367971200"; d="scan'208,217";a="241356209" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-1.cisco.com with ESMTP; 31 Jul 2013 00:16:37 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6V0Gbib030650 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Jul 2013 00:16:37 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Tue, 30 Jul 2013 19:16:37 -0500 From: "Zafar Ali (zali)" To: Khuzema Pithewan , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Thread-Index: Ac6NL9ROMXULLvcwR2aMbEKex7ZPbAAG5uQwAAdbOAAAAUWKEAAHaZGA Date: Wed, 31 Jul 2013 00:16:36 +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.2.3.120616 x-originating-ip: [10.82.254.44] Content-Type: multipart/alternative; boundary="_000_B6585D85A128FD47857D0FD58D8120D30E9F3BDCxmbrcdx14ciscoc_" MIME-Version: 1.0 Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 00:16:47 -0000 --_000_B6585D85A128FD47857D0FD58D8120D30E9F3BDCxmbrcdx14ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Khuzema: For signaling inquiry LSP with resource locking, we are using the Pre-Plann= ed LSP flag as-is as defined in RFC6001. Given this, we are defining a new = flag when inquiry LSP needs to be signal without resource locking. Thanks Regards =85 Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 5:45 PM To: zali >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Well.. not really. You are defining new bits for LSP_ATTRIBUTES for resource locking=85 aren= =92t you? Instead of doing that, you can define bits in ADMIN_STATUS and save new LSP= life cycle management, which would be quite cumbersome. Regards Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Tuesday, July 30, 2013 10:08 PM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Khuzema: The point is to reuse what already exists. The Pre-Planned LSP flag in the = Attribute Flags TLV of LSP_ATTRIBUTES object is already defined in [RFC5420= ] and is a glove fit. Thanks Regards =85 Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 1:40 PM To: Khuzema Pithewan = >, "ccamp@ietf.org" > Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Another point I spoke about in the meeting .. Why can=92t we extend Admin Status object to signal resource locking, check= ing for re-optimization. Since this operation is typically done in maintena= nce window by Admin, it may make sense to use Admin Status Object. Moreover= , we have lots of bits available/undefined in Admin Status object. This will save network element to manage life of additional LSP and control= plane failure related issues attached to the additional LSP. Khuzema --_000_B6585D85A128FD47857D0FD58D8120D30E9F3BDCxmbrcdx14ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <443367EEA389A14BB2A0619D3851AAE8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Khuzema:

For signaling inquiry LSP with resource locking, we are using the Pre-Planned LSP flag as-is as defined in RFC6001. Given th= is, we are defining a new flag when inquiry LSP needs to be signal without resource locking.  

Thanks

Regards =85 Zafar

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Tuesday, July 30, 2013 5:45 P= M
To: zali <zali@cisco.com>, "ccamp@ietf.org" <ccamp@ietf.= org>
Subject: RE: [CCAMP] draft-ali-ccam= p-lsp-inquiry-00

Well.. not really.

 

You are defining new b= its for LSP_ATTRIBUTES for resource locking=85 aren=92t you?

 

Instead of doing that,= you can define bits in ADMIN_STATUS and save new LSP life cycle management= , which would be quite cumbersome.

 

Regards

Khuzema

 

From: Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Tuesday, July 30, 2013 10:08 PM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Khuzema= :

&n= bsp;

The poi= nt is to reuse what already exists. The Pre-Planned LSP flag in the At= tribute Flags TLV of LSP_ATTRIBUTES object is already defined in [RFC5420] = and is a glove fit. 

&n= bsp;

Thanks<= o:p>

&n= bsp;

Regards= =85 Zafar

&n= bsp;

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Tuesday, July 30, 2013 1:40 PM
To: Khuzema Pithewan <k= pithewan@infinera.com>, "ccam= p@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

&n= bsp;

Another point I spoke = about in the meeting ..

 

Why can=92t we extend = Admin Status object to signal resource locking, checking for re-optimizatio= n. Since this operation is typically done in maintenance window by Admin, i= t may make sense to use Admin Status Object. Moreover, we have lots of bits available/undefined in Admin Status object.=

 

This will save network= element to manage life of additional LSP and control plane failure related= issues attached to the additional LSP.<= o:p>

 

Khuzema

 

--_000_B6585D85A128FD47857D0FD58D8120D30E9F3BDCxmbrcdx14ciscoc_-- From zali@cisco.com Tue Jul 30 20:11:15 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4196311E8167 for ; Tue, 30 Jul 2013 20:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hvgmDe6mEcv for ; Tue, 30 Jul 2013 20:11:09 -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 7DFBD11E815B for ; Tue, 30 Jul 2013 20:10:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13144; q=dns/txt; s=iport; t=1375240258; x=1376449858; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=RzqgpdSq9zZl4MFxl5EN17wrzDKHje/9pNV+GNohH3k=; b=QmbKHTOZE7prnTteAbQD6Kqsh8f7p0btVD19V5WiGcffvBKRJVtXE0mw PD9HIX54uo09cCmfqcF6xMHtlQLjR8vUE0u11a4xCmocGdH0zfYpag9qP Ekgg5NUf69BZIBDZY75+OjNy6ZHM8XXs58IFyH8NQ6s1NEWDpM4PufpX3 I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAJd/+FGtJXG9/2dsb2JhbABbgkJENVC1XIg/gRoWdIIkAQEBBC1eAQYCDgMDAQILHTkUCQgBAQQBEgiICAyLUa0Vj00gGIMYcQOZCJAjgxSCKg X-IronPort-AV: E=Sophos;i="4.89,783,1367971200"; d="scan'208,217";a="241600743" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 31 Jul 2013 03:10:57 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r6V3AvxT019913 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Jul 2013 03:10:57 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Tue, 30 Jul 2013 22:10:57 -0500 From: "Zafar Ali (zali)" To: Khuzema Pithewan , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Thread-Index: Ac6NL9ROMXULLvcwR2aMbEKex7ZPbAAdB7oA Date: Wed, 31 Jul 2013 03:10:56 +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.2.3.120616 x-originating-ip: [10.82.218.68] Content-Type: multipart/alternative; boundary="_000_B6585D85A128FD47857D0FD58D8120D30E9F3CB7xmbrcdx14ciscoc_" MIME-Version: 1.0 Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 03:11:15 -0000 --_000_B6585D85A128FD47857D0FD58D8120D30E9F3CB7xmbrcdx14ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Khuzema- Please see in-line. Thanks Regards =85 Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 10:25 AM To: "ccamp@ietf.org" > Subject: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Authors, The draft relies on ability to setup GMPLS lsp without committing resources= in dataplane. Only reference I found to setup pre-planned GMPLS is in RFC 6001. The green highlighted part says it is not possible to support 0 bandwidth l= sp for TDM/LSC network. While red part alludes that it can be done. Also I couldn=92 locate the text in any RFC that describes the NULL label b= ehavior in GMPLS context. RFC6001 5.2.2 says =85=85=85=85=85.snip=85=85=85=85=85=85. The snippet in the following is from section that talks about Path Provisio= ned LSPs (not pre pre-planned LSPs). The difference is stated as follows: "There is a difference between an LSP that is established with 0 bandwidth (path provisioning) and an LSP that is established with a certain bandwidth value not committed at the data plane level (i.e., pre-planned LSP)." Having said that the following snippet talks about Path provision LSP. However, mechanisms for provisioning (pre-planned or not) a TDM or LSC LSP with 0 bandwidth is currently not possible because the exchanged label value is tightly coupled with resource allocation during LSP signaling (e.g., see [RFC4606] for a SONET/SDH LSP). For TDM and LSC LSP, a NULL Label value is used to prevent resource allocation at the data plane level. In these cases, upon LSP resource commitment, actual label value exchange is performed to commit allocation of timeslots/ wavelengths. Earlier text in the RFC6001 talks about how Null service can be signaled. "o The second technique consists in making use of path-provisioned LSPs only. In this case, there is no associated resource demand during the LSP establishment. This can be considered as the RSVP- TE equivalent of the Null service type specified in [RFC2997]. " However, in the context of inquiry we are not interested in Null service bu= t signaling LSP with the actual TSPEC. Hence we did not used Null service c= onstruct. =85=85=85=85=85=85=85..snip=85=85=85=85=85=85.. Khuzema --_000_B6585D85A128FD47857D0FD58D8120D30E9F3CB7xmbrcdx14ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <4C6870EC40FDDD4BA619E63865888AFB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Khuzema- 

Please see in-line. 

Thanks

Regards =85 Zafar

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Tuesday, July 30, 2013 10:25 = AM
To: "ccamp@ietf.org" <cca= mp@ietf.org>
Subject: [CCAMP] draft-ali-ccamp-ls= p-inquiry-00

Authors,

 

The draft relies on ability to setup GMPLS lsp witho= ut committing resources in dataplane.

 

Only reference I found to setup pre-planned GMPLS is= in RFC 6001.

 

The green highlighted part says it is not possible t= o support 0 bandwidth lsp for TDM/LSC network. While red part alludes that = it can be done.

 

Also I couldn=92 locate the text in any RFC that des= cribes the NULL label behavior in GMPLS context.

 

 

RFC6001 5.2.2 says

 

=85=85=85=85=85.snip=85=85=85=85=85=85.

 


The snippet in the following is from section that talks about Path Provisioned LSPs (not = pre pre-planned LSPs). The difference is= stated as follows: 

"There i=
s a difference between an LSP that is established with 0
   bandwidth (path provisioning) and an LSP that is established with a
   certain bandwidth value not committed at the data plane level (i.e.,
   pre-planned LSP)."



Having said t=
hat the following snippet talks about Path provision LSP. 

H= owever, mechanisms for provisioning (pre-planned or not) a TDM or

&= nbsp;  LSC LSP with 0 bandwidth is currently not possible because the<= o:p>

&= nbsp;  exchanged label value is tightly coupled with resource allocati= on

&= nbsp;  during LSP signaling (e.g., see [RFC4606] for a SONET/SDH LSP).=   For

&nb= sp;  TDM and LSC LSP, a NULL Label value is used to prevent resource

&nb= sp;  allocation at the data plane level.  In these cases, = upon LSP

   resource commitment, actual label value= exchange is performed to

   commit allocation of timeslots/ wavelen= gths.

 

 

Earlier text =
in the RFC6001 talks about how Null service can be signaled. 




   "o Th=
e second technique consists in making use of path-provisioned
     LSPs only.  In this case, there is no associated resource demand
     during the LSP establishment.  This can be considered as the RSVP-


  TE equivale=
nt of the Null service type specified in [RFC2997 "

However, in the context of inquiry we are not interested in Null servi= ce but signaling LSP with the actual TSPEC. Hence we did not used Null serv= ice construct. 


=85=85=85=85=85=85=85..snip=85=85=85=85=85=85..=

 

 

Khuzema

 --_000_B6585D85A128FD47857D0FD58D8120D30E9F3CB7xmbrcdx14ciscoc_-- From mhartley@cisco.com Wed Jul 31 00:08:36 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02C0921E804C for ; Wed, 31 Jul 2013 00:08:36 -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 DnBJ8Ry2nGkl for ; Wed, 31 Jul 2013 00:08:30 -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 643E521F9DCA for ; Wed, 31 Jul 2013 00:08:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1073; q=dns/txt; s=iport; t=1375254510; x=1376464110; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=QT0Xk0rUEFy+grZ+VXc8dE2p8aSFpZCAWT4VePPwG/Y=; b=EYSaveiN/224EmPIKrUce/O84MG0sOfb9qB6/zHglviWi1tb5VAd+ijr friLx/Qlpgs6ealb+WdlncuPR208U37DnoWL6F4qEBW3Pjg3O7QU/S/v3 3jRdHdeXuwMVmnuI4A4MVc+5h8qALepWANowXBcMiAs6l4FKlkGVxSZ1y o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAKa3+FGtJXG8/2dsb2JhbABRCoMGgQW+HIEYFnSCJgEEOg0wAhIBKhRCJgEEDg0Th3WrJo1JjjyBETGDH3EDlAiVI4MUgio X-IronPort-AV: E=Sophos;i="4.89,785,1367971200"; d="scan'208";a="241726036" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-4.cisco.com with ESMTP; 31 Jul 2013 07:08:22 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6V78MFH032252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 31 Jul 2013 07:08:22 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.202]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Wed, 31 Jul 2013 02:08:21 -0500 From: "Matt Hartley (mhartley)" To: "ccamp@ietf.org" Thread-Topic: Summary of draft-ali-ccamp-gmpls-uni-error-notification-00 Thread-Index: Ac6NvI7j5UPAfkA0Tpqtzz1lvicRYQ== Date: Wed, 31 Jul 2013 07:08:21 +0000 Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC105856F3@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.61.216.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CCAMP] Summary of draft-ali-ccamp-gmpls-uni-error-notification-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 07:08:36 -0000 Problem statements =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This draft addresses two issues with GMPLS-UNI. 1. When a Path-Error message is generated, a node can add an IP address to = identify the source of the error. If this happens within a core network, th= is may be a problem if the core's policy is to avoid allowing any informati= on about the core topology to propagate outside the core. 2. if a failure for an established GMPLS-UNI LSP occurs within the core and= is repaired, there's no way for the UNI-C control plane to know that the r= epair has occurred. CCAMP relevance =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D This is a simple extension to GMPLS-UNI, and therefore falls within CCAMP's= charter. Solutions =3D=3D=3D=3D=3D=3D=3D=3D=3D 1. Allow a node to change the IP address in a Path-Error message to an addr= ess that it owns, in order to conceal the core topology/address from the up= stream node(s). 2. Define a new Path-Error Notify subcode so that a notification of LSP rep= air can be sent. From kpithewan@infinera.com Wed Jul 31 00:45:23 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9B5C21F9BC4 for ; Wed, 31 Jul 2013 00:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mXm6S3WtYs-3 for ; Wed, 31 Jul 2013 00:45:18 -0700 (PDT) Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id EB37E21E80B3 for ; Wed, 31 Jul 2013 00:45:13 -0700 (PDT) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.03.0123.003; Wed, 31 Jul 2013 00:45:13 -0700 From: Khuzema Pithewan To: "Zafar Ali (zali)" , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Thread-Index: Ac6NL9ROMXULLvcwR2aMbEKex7ZPbAAG5uQwAAdbOAAAAUWKEAAHaZGAAA2DHKA= Date: Wed, 31 Jul 2013 07:45:12 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.156.118] Content-Type: multipart/alternative; boundary="_000_D8D01B39D6B38C45AA37C06ECC1D65D53FDD1FFCSVEXDBPROD1infi_" MIME-Version: 1.0 Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 07:45:23 -0000 --_000_D8D01B39D6B38C45AA37C06ECC1D65D53FDD1FFCSVEXDBPROD1infi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Zafar, The point I am making here is.. the 2 approaches.. Admin Status and LSP_Att= ributes, are exactly same in terms of object re-use and both of them define= s new bits for enhanced functionality. The LSP_Attribute approach has addit= ional overhead of managing a separate control LSP, which is not desirable. Thanks Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Wednesday, July 31, 2013 2:17 AM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Khuzema: For signaling inquiry LSP with resource locking, we are using the Pre-Plann= ed LSP flag as-is as defined in RFC6001. Given this, we are defining a new = flag when inquiry LSP needs to be signal without resource locking. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 5:45 PM To: zali >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Well.. not really. You are defining new bits for LSP_ATTRIBUTES for resource locking... aren't= you? Instead of doing that, you can define bits in ADMIN_STATUS and save new LSP= life cycle management, which would be quite cumbersome. Regards Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Tuesday, July 30, 2013 10:08 PM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Khuzema: The point is to reuse what already exists. The Pre-Planned LSP flag in the = Attribute Flags TLV of LSP_ATTRIBUTES object is already defined in [RFC5420= ] and is a glove fit. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 1:40 PM To: Khuzema Pithewan = >, "ccamp@ietf.org" > Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Another point I spoke about in the meeting .. Why can't we extend Admin Status object to signal resource locking, checkin= g for re-optimization. Since this operation is typically done in maintenanc= e window by Admin, it may make sense to use Admin Status Object. Moreover, = we have lots of bits available/undefined in Admin Status object. This will save network element to manage life of additional LSP and control= plane failure related issues attached to the additional LSP. Khuzema --_000_D8D01B39D6B38C45AA37C06ECC1D65D53FDD1FFCSVEXDBPROD1infi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Zafar,

 

The point I am making = here is.. the 2 approaches.. Admin Status and LSP_Attributes, are exactly s= ame in terms of object re-use and both of them defines new bits for enhance= d functionality. The LSP_Attribute approach has additional overhead of managing a separate control LSP, which is not d= esirable.

 

Thanks

Khuzema

 

From: Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Wednesday, July 31, 2013 2:17 AM
To: Khuzema Pithewan; CCAMP (ccamp@ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Khuz= ema:

 <= /o:p>

For signalin= g inquiry LSP with resource locking, we are using the Pre-Planned LSP flag&= nbsp;as-is as defined in RFC6001. Given this, we are defining a new flag when inquiry LSP needs to be signal without resource locking. &nb= sp;

 <= /o:p>

Thanks<= /o:p>

 <= /o:p>

Regards R= 30; Zafar

 

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Tuesday, July 30, 2013 5:45 PM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Well.. not really.

 

You are defining new b= its for LSP_ATTRIBUTES for resource locking… aren’t you?=

 

Instead of doing that,= you can define bits in ADMIN_STATUS and save new LSP life cycle management= , which would be quite cumbersome.<= /o:p>

 

Regards

Khuzema

 

From: Zafar Ali (zali) [mailto:= zali@cisco.com]
Sent: Tuesday, July 30, 2013 10:08 PM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 =

Khuzema= :

 <= /span>

The poi= nt is to reuse what already exists. The Pre-Planned LSP flag in the At= tribute Flags TLV of LSP_ATTRIBUTES object is already defined in [RFC5420] = and is a glove fit. 

 <= /span>

Thanks<= /span>

 <= /span>

Regards= … Zafar

 <= /span>

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Tuesday, July 30, 2013 1:40 PM
To: Khuzema Pithewan <k= pithewan@infinera.com>, "ccam= p@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 <= /span>

Another point I spoke = about in the meeting ..

 

Why can’t we ext= end Admin Status object to signal resource locking, checking for re-optimiz= ation. Since this operation is typically done in maintenance window by Admi= n, it may make sense to use Admin Status Object. Moreover, we have lots of bits available/undefined in Admin Status object.=

 

This will save network= element to manage life of additional LSP and control plane failure related= issues attached to the additional LSP.<= o:p>

 

Khuzema

 

--_000_D8D01B39D6B38C45AA37C06ECC1D65D53FDD1FFCSVEXDBPROD1infi_-- From kpithewan@infinera.com Wed Jul 31 00:47:13 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EB0621E812E for ; Wed, 31 Jul 2013 00:47:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hBSJYSW38Qj for ; Wed, 31 Jul 2013 00:47:09 -0700 (PDT) Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC4821E8111 for ; Wed, 31 Jul 2013 00:47:09 -0700 (PDT) Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.03.0123.003; Wed, 31 Jul 2013 00:47:09 -0700 From: Khuzema Pithewan To: "Zafar Ali (zali)" , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Thread-Index: Ac6NL9ROMXULLvcwR2aMbEKex7ZPbAAdB7oAAAeE/GA= Date: Wed, 31 Jul 2013 07:47:09 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.100.156.118] Content-Type: multipart/alternative; boundary="_000_D8D01B39D6B38C45AA37C06ECC1D65D53FDD2013SVEXDBPROD1infi_" MIME-Version: 1.0 Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 07:47:13 -0000 --_000_D8D01B39D6B38C45AA37C06ECC1D65D53FDD2013SVEXDBPROD1infi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable How do you deal with NULL label in GMPLS context. I couldn't find where it = is detailed. Thanks Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Wednesday, July 31, 2013 5:11 AM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Khuzema- Please see in-line. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 10:25 AM To: "ccamp@ietf.org" > Subject: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Authors, The draft relies on ability to setup GMPLS lsp without committing resources= in dataplane. Only reference I found to setup pre-planned GMPLS is in RFC 6001. The green highlighted part says it is not possible to support 0 bandwidth l= sp for TDM/LSC network. While red part alludes that it can be done. Also I couldn' locate the text in any RFC that describes the NULL label beh= avior in GMPLS context. RFC6001 5.2.2 says ................snip................... The snippet in the following is from section that talks about Path Provisio= ned LSPs (not pre pre-planned LSPs). The difference is stated as follows: "There is a difference between an LSP that is established with 0 bandwidth (path provisioning) and an LSP that is established with a certain bandwidth value not committed at the data plane level (i.e., pre-planned LSP)." Having said that the following snippet talks about Path provision LSP. However, mechanisms for provisioning (pre-planned or not) a TDM or LSC LSP with 0 bandwidth is currently not possible because the exchanged label value is tightly coupled with resource allocation during LSP signaling (e.g., see [RFC4606] for a SONET/SDH LSP). For TDM and LSC LSP, a NULL Label value is used to prevent resource allocation at the data plane level. In these cases, upon LSP resource commitment, actual label value exchange is performed to commit allocation of timeslots/ wavelengths. Earlier text in the RFC6001 talks about how Null service can be signaled. "o The second technique consists in making use of path-provisioned LSPs only. In this case, there is no associated resource demand during the LSP establishment. This can be considered as the RSVP- TE equivalent of the Null service type specified in [RFC2997]. " However, in the context of inquiry we are not interested in Null service bu= t signaling LSP with the actual TSPEC. Hence we did not used Null service c= onstruct. .......................snip.................... Khuzema --_000_D8D01B39D6B38C45AA37C06ECC1D65D53FDD2013SVEXDBPROD1infi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

How do you deal with N= ULL label in GMPLS context. I couldn’t find where it is detailed.

 

Thanks

Khuzema

 

From: Zafar Al= i (zali) [mailto:zali@cisco.com]
Sent: Wednesday, July 31, 2013 5:11 AM
To: Khuzema Pithewan; CCAMP (ccamp@ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Khuz= ema- 

&n= bsp;

Please = see in-line. 

&n= bsp;

Thanks<= o:p>

&n= bsp;

Regards= … Zafar

&n= bsp;

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Tuesday, July 30, 2013 10:25 AM
To: "ccamp@ietf.org"= <ccamp@ietf.org>
Subject: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

&n= bsp;

Authors,

 =

The draft relies on abil= ity to setup GMPLS lsp without committing resources in dataplane.

 =

Only reference I found t= o setup pre-planned GMPLS is in RFC 6001.

 =

The green highlighted pa= rt says it is not possible to support 0 bandwidth lsp for TDM/LSC network. = While red part alludes that it can be done.

 =

Also I couldn’ loc= ate the text in any RFC that describes the NULL label behavior in GMPLS con= text.

 =

 =

RFC6001 5.2.2 says<= /o:p>

 =

………= 230;….snip……………….

 =

&n= bsp;

The snippet in the follo= wing is from section that talks about Path Provisioned LSPs (not pre p= re-planned LSPs). The difference is stated as follows: 

 = 

"Ther=
e is a difference between an LSP that is established with 0
 &nbs=
p; bandwidth (path provisioning) and an LSP that is established with a=

 &nbs=
p; certain bandwidth value not committed at the data plane level (i.e.,
 &nbs=
p; pre-planned LSP)."

 
Having sai=
d that the following snippet talks about Path provision LSP. 

However, mechanisms for provisioning (pre-planned or not) a TDM = or

   LSC LSP with 0 bandwidth is currently not possible = because the

   exchanged label value is tightly coupled with resou= rce allocation

   during LSP signaling (e.g., see [RFC4606] for a SON= ET/SDH LSP).  For

   TDM and LSC LSP, a NULL Label value is used to preven= t resource

   allocation at the data plane level.  In these cases, upon LSP

   resource co= mmitment, actual label value exchange is performed to

   commit allo= cation of timeslots/ wavelengths.

 =

 = 

Earlier te=
xt in the RFC6001 talks about how Null service can be signaled. 

 &nbs=
p; "o The second technique consists in making use of path-provisi=
oned
 &nbs=
p;   LSPs only.  In this case, there is no associated resour=
ce demand
 &nbs=
p;   during the LSP establishment.  This can be considered a=
s the RSVP-<=
/span>
  TE =
equivalent of the Null service type specified in [RFC2997]. "

 =

However, in the context = of inquiry we are not interested in Null service but signaling LSP with the= actual TSPEC. Hence we did not used Null service construct. 

 =

 =

………= 230;………..snip………………..=

 =

 =

Khuzema

--_000_D8D01B39D6B38C45AA37C06ECC1D65D53FDD2013SVEXDBPROD1infi_-- From zali@cisco.com Wed Jul 31 02:09:57 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96C7421F9DAB for ; Wed, 31 Jul 2013 02:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sj97PE9QavPR for ; Wed, 31 Jul 2013 02:09:44 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id C7AE221F93C4 for ; Wed, 31 Jul 2013 02:01:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19062; q=dns/txt; s=iport; t=1375261295; x=1376470895; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=CL4JOrs7ziveuOlqMLpCHNZCHU32oHxmNF2gNsIiBUI=; b=L6GEfksGVPKv8PLkfNztvNZqq1dZYgZuhemcThbgSiJ4e3kB5qU9k74O hJ/N0t+JRBJLoAzVoUfZeGxlQvP+iWp1lBU2p+ZQ5AKiAPJo2lmBi6jQK tHRRs1mDzJALOVUNPFCMoRDpJ0nqUa3ySyPQTS4/oO3d7efw/JbhiNgG0 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFALXQ+FGtJV2b/2dsb2JhbABbgkJENVC+HIEXFnSCJAEBAQQtXgEIDgMDAQEBCx05FAkIAgQBEggRh3e4W49NIBcBgxhxA6krgxSCKg X-IronPort-AV: E=Sophos;i="4.89,785,1367971200"; d="scan'208,217";a="241659681" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 31 Jul 2013 08:59:39 +0000 Received: from xhc-aln-x04.cisco.com (xhc-aln-x04.cisco.com [173.36.12.78]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6V8xdZk016022 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Jul 2013 08:59:39 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-aln-x04.cisco.com ([173.36.12.78]) with mapi id 14.02.0318.004; Wed, 31 Jul 2013 03:59:38 -0500 From: "Zafar Ali (zali)" To: Khuzema Pithewan , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Thread-Index: Ac6NL9ROMXULLvcwR2aMbEKex7ZPbAAG5uQwAAdbOAAAAUWKEAAHaZGAAA2DHKAABMFSAA== Date: Wed, 31 Jul 2013 08:59:38 +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.2.3.120616 x-originating-ip: [10.82.212.118] Content-Type: multipart/alternative; boundary="_000_B6585D85A128FD47857D0FD58D8120D30E9F3F71xmbrcdx14ciscoc_" MIME-Version: 1.0 Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 09:09:57 -0000 --_000_B6585D85A128FD47857D0FD58D8120D30E9F3F71xmbrcdx14ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Khuzema: Please see in-line. Thanks Regards =85 Zafar From: Khuzema Pithewan > Date: Wednesday, July 31, 2013 3:45 AM To: zali >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Zafar, The point I am making here is.. the 2 approaches.. Admin Status and LSP_Att= ributes, are exactly same in terms of object re-use and both of them define= s new bits for enhanced functionality. The LSP_Attribute approach has addit= ional overhead of managing a separate control LSP, which is not desirable. The inquire/ potential reopt LSP is likely not to follow path of the curren= tly active LSP. Hence this cannot be implemented by just adding some Admin = Status bit on the current LSP. One need to signal a separate LSP. Thanks Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Wednesday, July 31, 2013 2:17 AM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Khuzema: For signaling inquiry LSP with resource locking, we are using the Pre-Plann= ed LSP flag as-is as defined in RFC6001. Given this, we are defining a new = flag when inquiry LSP needs to be signal without resource locking. Thanks Regards =85 Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 5:45 PM To: zali >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Well.. not really. You are defining new bits for LSP_ATTRIBUTES for resource locking=85 aren= =92t you? Instead of doing that, you can define bits in ADMIN_STATUS and save new LSP= life cycle management, which would be quite cumbersome. Regards Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Tuesday, July 30, 2013 10:08 PM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Khuzema: The point is to reuse what already exists. The Pre-Planned LSP flag in the = Attribute Flags TLV of LSP_ATTRIBUTES object is already defined in [RFC5420= ] and is a glove fit. Thanks Regards =85 Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 1:40 PM To: Khuzema Pithewan = >, "ccamp@ietf.org" > Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Another point I spoke about in the meeting .. Why can=92t we extend Admin Status object to signal resource locking, check= ing for re-optimization. Since this operation is typically done in maintena= nce window by Admin, it may make sense to use Admin Status Object. Moreover= , we have lots of bits available/undefined in Admin Status object. This will save network element to manage life of additional LSP and control= plane failure related issues attached to the additional LSP. Khuzema --_000_B6585D85A128FD47857D0FD58D8120D30E9F3F71xmbrcdx14ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <94ED4A3AAF456841B04606A0B0F3A074@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Khuzema: 

Please see in-line. 

Thanks

Regards =85 Zafar

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Wednesday, July 31, 2013 3:45= AM
To: zali <zali@cisco.com>, "ccamp@ietf.org" <ccamp@ietf.= org>
Subject: RE: [CCAMP] draft-ali-ccam= p-lsp-inquiry-00

Hi Zafar,

 

The point I am making = here is.. the 2 approaches.. Admin Status and LSP_Attributes, are exactly s= ame in terms of object re-use and both of them defines new bits for enhance= d functionality. The LSP_Attribute approach has additional overhead of managing a separate control LSP, which is not d= esirable.

 

The inquire/ potential reopt LSP is likely not to follow path of the c= urrently active LSP. Hence this cannot be implemented by just adding some A= dmin Status bit on the current LSP. One need to signal a separate LSP. = ;

Thanks

Khuzema

 

From: Zafar Ali (zali) [= mailto:zali@cisco.com]
Sent: Wednesday, July 31, 2013 2:17 AM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Khuzema:<= /span>

 

For signaling inquiry LSP wi= th resource locking, we are using the Pre-Planned LSP flag as-is as de= fined in RFC6001. Given this, we are defining a new flag when inquiry LSP needs to be signal without resource locking. &= nbsp;

 

Thanks

 

Regards =85 Zafar=

 

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Tuesday, July 30, 2013 5:45 PM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Well.. not really.

 

You are defining new b= its for LSP_ATTRIBUTES for resource locking=85 aren=92t you?

 

Instead of doing that,= you can define bits in ADMIN_STATUS and save new LSP life cycle management= , which would be quite cumbersome.<= /o:p>

 

Regards

Khuzema

 

From: Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Tuesday, July 30, 2013 10:08 PM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 =

Khuzema= :

 <= /span>

The poi= nt is to reuse what already exists. The Pre-Planned LSP flag in the At= tribute Flags TLV of LSP_ATTRIBUTES object is already defined in [RFC5420] = and is a glove fit. 

 <= /span>

Thanks<= /span>

 <= /span>

Regards= =85 Zafar

 <= /span>

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Tuesday, July 30, 2013 1:40 PM
To: Khuzema Pithewan <k= pithewan@infinera.com>, "ccam= p@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 <= /span>

Another point I spoke = about in the meeting ..

 

Why can=92t we extend = Admin Status object to signal resource locking, checking for re-optimizatio= n. Since this operation is typically done in maintenance window by Admin, i= t may make sense to use Admin Status Object. Moreover, we have lots of bits available/undefined in Admin Status object.=

 

This will save network= element to manage life of additional LSP and control plane failure related= issues attached to the additional LSP.<= o:p>

 

Khuzema

 

 --_000_B6585D85A128FD47857D0FD58D8120D30E9F3F71xmbrcdx14ciscoc_-- From adrian@olddog.co.uk Wed Jul 31 02:11:19 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E6A21F9B8F for ; Wed, 31 Jul 2013 02:11:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.463 X-Spam-Level: X-Spam-Status: No, score=-2.463 tagged_above=-999 required=5 tests=[AWL=0.136, 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 O4EQslKV794i for ; Wed, 31 Jul 2013 02:11:10 -0700 (PDT) Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) by ietfa.amsl.com (Postfix) with ESMTP id 30CAE21F8793 for ; Wed, 31 Jul 2013 02:04:07 -0700 (PDT) Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6V93niN030565; Wed, 31 Jul 2013 10:03:49 +0100 Received: from 950129200 (dhcp-13f0.meeting.ietf.org [130.129.19.240]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6V93m58030538 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 31 Jul 2013 10:03:49 +0100 From: "Adrian Farrel" To: "'Lou Berger'" References: <6700accc.1375182901959@mail.labn.net> In-Reply-To: <6700accc.1375182901959@mail.labn.net> Date: Wed, 31 Jul 2013 10:03:47 +0100 Message-ID: <03eb01ce8dcc$de384ec0$9aa8ec40$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQEOi7AdD1YSYntSKjlyOgFI9+f6jJr+gN3w Content-Language: en-gb Cc: ccamp@ietf.org Subject: Re: [CCAMP] Question about draft-ietf-ccamp-otn-g709-info-model-09.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 09:11:20 -0000 Lou, I think that is fine. This draft should give some weight to IS-IS (at least mention it :-) along with OSPF. I am not requiring the WG to produce IS-IS solution drafts. The only requirement there is to facilitate IS-IS solutions drafts if people want to write them and intend to implement in code. A > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: 30 July 2013 12:31 > To: adrian@olddog.co.uk > Cc: ccamp@ietf.org > Subject: Re: [CCAMP] Question about draft-ietf-ccamp-otn-g709-info-model- > 09.txt > > Hi Adrian, > > So IS-IS is certainly still a viable GMPLS routing protocol and it should be > mentioned in the draft as a possibility. Good catch. > > The more general issue with GMPLS IS-IS, from my perspective, is that there > hasn't been much interest in working on related drafts in the WG. GMPLS IS-IS > remains in scope, but drafts aren't being written. I take this as the market > "speaking". > > Lou > > On 10:29am, July 28, 2013, Adrian Farrel wrote: > > Hi CCAMP, > > > > I am currently reviewing draft-ietf-ccamp-otn-g709-info-model-09.txt > (cunningly > > deceptive file name ;-) > > > > I have a question... > > > > The document makes reference to RFC 4202 and RFC 4203, but not to RFC 5307 > > (obsoleted RFC 4205). Can I ask why CCAMP no longer considers IS-IS to be a > > potential routing protocol for GMPLS systems? > > > > Thanks, > > > > Adrian > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp > > From adrian@olddog.co.uk Wed Jul 31 02:11:33 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3A621F9D4F for ; Wed, 31 Jul 2013 02:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.130, 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 wkbzx4o1R4nY for ; Wed, 31 Jul 2013 02:11:26 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id D77F621F9EC6 for ; Wed, 31 Jul 2013 02:04:42 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6V94bLW014542; Wed, 31 Jul 2013 10:04:37 +0100 Received: from 950129200 (dhcp-13f0.meeting.ietf.org [130.129.19.240]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6V94a8r014499 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 31 Jul 2013 10:04:37 +0100 From: "Adrian Farrel" To: "'Khuzema Pithewan'" , "'CCAMP'" References: In-Reply-To: Date: Wed, 31 Jul 2013 10:04:35 +0100 Message-ID: <03f301ce8dcc$faeca2a0$f0c5e7e0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03F4_01CE8DD5.5CB35490" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGu+7aOT387C3jmH4N3pUr4Jl2uR5m9oYZA Content-Language: en-gb Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 09:11:33 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03F4_01CE8DD5.5CB35490 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Right, Khuzema, you caught the right piece of text. The point here is that the LSP is *not* set up in the data plane if it has a different label. All that is happening is that the LSP-ID and state is being set up in the control plane. I may have said it before but it is massively helpful for people to pay close attention to whether they mean "control plane LSP" or "data plane LSP" when they say "LSP". A From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Khuzema Pithewan Sent: 30 July 2013 15:25 To: CCAMP (ccamp@ietf.org) Subject: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Authors, The draft relies on ability to setup GMPLS lsp without committing resources in dataplane. Only reference I found to setup pre-planned GMPLS is in RFC 6001. The green highlighted part says it is not possible to support 0 bandwidth lsp for TDM/LSC network. While red part alludes that it can be done. Also I couldn' locate the text in any RFC that describes the NULL label behavior in GMPLS context. RFC6001 5.2.2 says ......snip....... However, mechanisms for provisioning (pre-planned or not) a TDM or LSC LSP with 0 bandwidth is currently not possible because the exchanged label value is tightly coupled with resource allocation during LSP signaling (e.g., see [RFC4606] for a SONET/SDH LSP). For TDM and LSC LSP, a NULL Label value is used to prevent resource allocation at the data plane level. In these cases, upon LSP resource commitment, actual label value exchange is performed to commit allocation of timeslots/ wavelengths. .........snip........ Khuzema ------=_NextPart_000_03F4_01CE8DD5.5CB35490 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Right, Khuzema, you = caught the right piece of text.

 

The point here is that = the LSP is *not* set up in the data plane if it has a different label. = All that is happening is that the LSP-ID and state is being set up in = the control plane.

 

I may have said it = before <snarkle> but it is massively helpful for people to pay = close attention to whether they mean "control plane LSP" or = "data plane LSP" when they say = "LSP".

 

A

 

From: = ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of = Khuzema Pithewan
Sent: 30 July 2013 15:25
To: = CCAMP (ccamp@ietf.org)
Subject: [CCAMP] = draft-ali-ccamp-lsp-inquiry-00

 

Authors,

 

The draft relies on ability to setup = GMPLS lsp without committing resources in = dataplane.

 

Only reference I found to setup = pre-planned GMPLS is in RFC 6001.

 

The green highlighted part says it is = not possible to support 0 bandwidth lsp for TDM/LSC network. While red = part alludes that it can be done.

 

Also I couldn’ locate the text = in any RFC that describes the NULL label behavior in GMPLS = context.

 

 

RFC6001 5.2.2 = says

 

…………….sni= p……………….

 

Howe= ver, mechanisms for provisioning (pre-planned or not) a TDM = or

&nbs= p;  LSC LSP with 0 bandwidth is currently not possible because = the

&nbs= p;  exchanged label value is tightly coupled with resource = allocation

&nbs= p;  during LSP signaling (e.g., see [RFC4606] for a SONET/SDH = LSP).  = For

 =   TDM and LSC LSP, a NULL Label value is used to prevent = resource

 =   allocation at the data plane level.  In these cases, upon = LSP

   resource commitment, = actual label value exchange is performed to

   commit allocation of = timeslots/ wavelengths.

 

……………R= 30;…..snip………………..

 

 

Khuzema

------=_NextPart_000_03F4_01CE8DD5.5CB35490-- From zali@cisco.com Wed Jul 31 02:27:19 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BFA421F9FF2 for ; Wed, 31 Jul 2013 02:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ZyHgmEHtD8S for ; Wed, 31 Jul 2013 02:27:00 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id D566721F8F67 for ; Wed, 31 Jul 2013 02:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34387; q=dns/txt; s=iport; t=1375262807; x=1376472407; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=fOj/dhYxC5UIM8FmeormapoJU3LdlDjE5VgvZ4yoqIg=; b=KD2OhVdZCUmFcp/UgdKnd8oVKUkgnwjwtHxY3zM2munFdVZdAYrDJ9V/ eT/frN7UIg9WPNDYtauDCwkSEd/ZVQ9SXotOUvZw45IbG5yW2kzhkvzTH RfCJ3210YihR8Wfx0CPuKpdGMIyf4MrmRhz7AGp56gJNnDnfrihHVsirS M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFAMTX+FGtJV2c/2dsb2JhbABbgkJENVC+HIEXFnSCJAEBAQQtXgEGAhEDAQEBCxYBBi0MFAkIAQEEAREBCIgIi0WtF49NIBcBgxhxA6krgxSCKg X-IronPort-AV: E=Sophos;i="4.89,786,1367971200"; d="scan'208,217";a="241668988" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 31 Jul 2013 09:26:46 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6V9QjCV009009 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Jul 2013 09:26:45 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.02.0318.004; Wed, 31 Jul 2013 04:26:45 -0500 From: "Zafar Ali (zali)" To: "adrian@olddog.co.uk" , "'Khuzema Pithewan'" , "'CCAMP'" Thread-Topic: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Thread-Index: Ac6NL9ROMXULLvcwR2aMbEKex7ZPbAAxw6uA///DJAA= Date: Wed, 31 Jul 2013 09:26:45 +0000 Message-ID: In-Reply-To: <03f301ce8dcc$faeca2a0$f0c5e7e0$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.212.118] Content-Type: multipart/alternative; boundary="_000_B6585D85A128FD47857D0FD58D8120D30E9F40A5xmbrcdx14ciscoc_" MIME-Version: 1.0 Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 09:27:21 -0000 --_000_B6585D85A128FD47857D0FD58D8120D30E9F40A5xmbrcdx14ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Adrian/ Khuzema: Inquiry LSP is a "control plane LSP" which is setup using tunnel Tspec and = non-null (actual) labels in Path/ Resv. Resource availability is examined b= ut the resources are NOT committed in the data plane (e.g., no XC). Thanks Regards =85 Zafar From: "adrian@olddog.co.uk" > Reply-To: "adrian@olddog.co.uk" > Date: Wednesday, July 31, 2013 5:04 AM To: 'Khuzema Pithewan' >, "ccamp@ietf.org" > Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Right, Khuzema, you caught the right piece of text. The point here is that the LSP is *not* set up in the data plane if it has = a different label. All that is happening is that the LSP-ID and state is be= ing set up in the control plane. I may have said it before but it is massively helpful for people = to pay close attention to whether they mean "control plane LSP" or "data pl= ane LSP" when they say "LSP". A From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Khuzema Pithewan Sent: 30 July 2013 15:25 To: CCAMP (ccamp@ietf.org) Subject: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Authors, The draft relies on ability to setup GMPLS lsp without committing resources= in dataplane. Only reference I found to setup pre-planned GMPLS is in RFC 6001. The green highlighted part says it is not possible to support 0 bandwidth l= sp for TDM/LSC network. While red part alludes that it can be done. Also I couldn=92 locate the text in any RFC that describes the NULL label b= ehavior in GMPLS context. RFC6001 5.2.2 says =85=85=85=85=85.snip=85=85=85=85=85=85. However, mechanisms for provisioning (pre-planned or not) a TDM or LSC LSP with 0 bandwidth is currently not possible because the exchanged label value is tightly coupled with resource allocation during LSP signaling (e.g., see [RFC4606] for a SONET/SDH LSP). For TDM and LSC LSP, a NULL Label value is used to prevent resource allocation at the data plane level. In these cases, upon LSP resource commitment, actual label value exchange is performed to commit allocation of timeslots/ wavelengths. =85=85=85=85=85=85=85..snip=85=85=85=85=85=85.. Khuzema --_000_B6585D85A128FD47857D0FD58D8120D30E9F40A5xmbrcdx14ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Adrian/ Khuzema: 

Inquiry LSP is a "control plane LSP" which is setup using tu= nnel Tspec and non-null (actual) labels in Path/ Resv. Resource availabilit= y is examined but the resources are NOT committed in the data plane (e.g., = no XC). 

Thanks

Regards =85 Zafar

From: "adrian@olddog.co.uk" <adrian@olddog.co.uk>
Reply-To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>
Date: Wednesday, July 31, 2013 5:04= AM
To: 'Khuzema Pithewan' <kpithewan@infinera.com>, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] draft-ali-ccam= p-lsp-inquiry-00

Right, Khuzema, you caught the right piece of text.<= /span>

 

The point here is that the LSP is *not* set up in the data plan= e if it has a different label. All that is happening is that the LSP-ID and state is being set up in the control plane.

 

I may have said it before <snarkle> but it is massively h= elpful for people to pay close attention to whether they mean "control plane LSP" or "data plane LSP" when= they say "LSP".

 

A

 

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Khuzema Pithewan
Sent: 30 July 2013 15:25
To: CCAMP (ccamp@ietf.org)
Subject: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Authors,

 

The draft relies on ability to setup GMPLS lsp without committing resour= ces in dataplane.

 

Only reference I found to setup pre-planned GMPLS is in RFC 6001.

 

The green highlighted part says it is not possible to support 0 bandwidt= h lsp for TDM/LSC network. While red part alludes that it can be done.=

 

Also I couldn=92 locate the text in any RFC that describes the NULL labe= l behavior in GMPLS context.

 

 

RFC6001 5.2.2 says

 

=85=85=85=85=85.snip=85=85=85=85=85=85.

 

However, mechanisms for provisioning = (pre-planned or not) a TDM or

   LSC LSP with 0 bandwidth= is currently not possible because the

   exchanged label value is= tightly coupled with resource allocation

   during LSP signaling (e.= g., see [RFC4606] for a SONET/SDH LSP).  For

   TDM and LSC LSP, a NULL La= bel value is used to prevent resource

   allocation at the data pla= ne level.&nbs= p; In these cases, upon LSP

   resource commitment, actual label value exchange is perform= ed to

   commit allocation of timeslots/ wavelengths.

 

=85=85=85=85=85=85=85..snip=85=85=85=85=85=85..

 

 

Khuzema

--_000_B6585D85A128FD47857D0FD58D8120D30E9F40A5xmbrcdx14ciscoc_-- From zhangfatai@huawei.com Wed Jul 31 02:34:46 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B78D21F9F70 for ; Wed, 31 Jul 2013 02:33:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=-4.298, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vflnIc23KGrm for ; Wed, 31 Jul 2013 02:33:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8E721F9298 for ; Wed, 31 Jul 2013 02:33:26 -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 ATY66267; Wed, 31 Jul 2013 09:33:11 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 31 Jul 2013 10:32:59 +0100 Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 31 Jul 2013 10:33:08 +0100 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.72]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0323.007; Wed, 31 Jul 2013 17:32:52 +0800 From: Fatai Zhang To: "Zafar Ali (zali)" , Khuzema Pithewan , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Thread-Index: Ac6NL9ROMXULLvcwR2aMbEKex7ZPbAAG5uQwAAdbOAAAAUWKEAAHaZGAAA2DHKAABMFSAAABID8g Date: Wed, 31 Jul 2013 09:32:52 +0000 Message-ID: References: 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.47.131.51] Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF84EE43E6FSZXEML552MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [CCAMP] =?gb2312?b?tPC4tDogIGRyYWZ0LWFsaS1jY2FtcC1sc3AtaW5xdWly?= =?gb2312?b?eS0wMA==?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 09:34:49 -0000 --_000_F82A4B6D50F9464B8EBA55651F541CF84EE43E6FSZXEML552MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgWmFmYXIsDQoNClBsZWFzZSBoYXZlIGEgIGxvb2sgYXQgZHJhZnQtemhhbmctY2NhbXAtZ21w bHMtdW5pLWFwcDxodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtemhhbmctY2NhbXAtZ21w bHMtdW5pLWFwcC0wNC50eHQ+LCB3aGljaCBoYXMgYSB2ZXJ5IGdvb2Qgc29sdXRpb24gdG8gYWRk cmVzcyB0aGUgcmVxdWlyZW1lbnRzIGluIHlvdXIgdGhpcyAgZHJhZnQgKGFuZCBzb21lIG90aGVy IHJlcXVpcmVtZW50cyBpbiB5b3VyIG90aGVyIGRyYWZ0cykuDQoNCkkgZG9uoa90IHRoaW5rIGl0 IGlzIGEgZ29vZCBpZGVhIHRvIG92ZXJsb2FkIFJTVlAtVEUgYnkgaW50cm9kdWNpbmcgcGF0aCBj b21wdXRhdGlvbiBmdW5jdGlvbnMgKG9yIFBDRVAgb2JqZWN0cyBsaWtlIE9GIHlvdSBkZXNjcmli ZWQgaW4gYW5vdGhlciBkcmFmdCkuDQoNClRoYW5rcw0KDQpGYXRhaQ0KDQoNCg0Kt6K8/sjLOiBj Y2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gtPqx 7SBaYWZhciBBbGkgKHphbGkpDQq3osvNyrG85DogMjAxM8TqN9TCMzHI1SAxNzowMA0KytW8/sjL OiBLaHV6ZW1hIFBpdGhld2FuOyBDQ0FNUCAoY2NhbXBAaWV0Zi5vcmcpDQrW98ziOiBSZTogW0ND QU1QXSBkcmFmdC1hbGktY2NhbXAtbHNwLWlucXVpcnktMDANCg0KSGkgS2h1emVtYToNCg0KUGxl YXNlIHNlZSBpbi1saW5lLg0KDQpUaGFua3MNCg0KUmVnYXJkcyChrSBaYWZhcg0KDQpGcm9tOiBL aHV6ZW1hIFBpdGhld2FuIDxrcGl0aGV3YW5AaW5maW5lcmEuY29tPG1haWx0bzprcGl0aGV3YW5A aW5maW5lcmEuY29tPj4NCkRhdGU6IFdlZG5lc2RheSwgSnVseSAzMSwgMjAxMyAzOjQ1IEFNDQpU bzogemFsaSA8emFsaUBjaXNjby5jb208bWFpbHRvOnphbGlAY2lzY28uY29tPj4sICJjY2FtcEBp ZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+IiA8Y2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNj YW1wQGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBbQ0NBTVBdIGRyYWZ0LWFsaS1jY2FtcC1sc3At aW5xdWlyeS0wMA0KDQpIaSBaYWZhciwNCg0KVGhlIHBvaW50IEkgYW0gbWFraW5nIGhlcmUgaXMu LiB0aGUgMiBhcHByb2FjaGVzLi4gQWRtaW4gU3RhdHVzIGFuZCBMU1BfQXR0cmlidXRlcywgYXJl IGV4YWN0bHkgc2FtZSBpbiB0ZXJtcyBvZiBvYmplY3QgcmUtdXNlIGFuZCBib3RoIG9mIHRoZW0g ZGVmaW5lcyBuZXcgYml0cyBmb3IgZW5oYW5jZWQgZnVuY3Rpb25hbGl0eS4gVGhlIExTUF9BdHRy aWJ1dGUgYXBwcm9hY2ggaGFzIGFkZGl0aW9uYWwgb3ZlcmhlYWQgb2YgbWFuYWdpbmcgYSBzZXBh cmF0ZSBjb250cm9sIExTUCwgd2hpY2ggaXMgbm90IGRlc2lyYWJsZS4NCg0KDQpUaGUgaW5xdWly ZS8gcG90ZW50aWFsIHJlb3B0IExTUCBpcyBsaWtlbHkgbm90IHRvIGZvbGxvdyBwYXRoIG9mIHRo ZSBjdXJyZW50bHkgYWN0aXZlIExTUC4gSGVuY2UgdGhpcyBjYW5ub3QgYmUgaW1wbGVtZW50ZWQg YnkganVzdCBhZGRpbmcgc29tZSBBZG1pbiBTdGF0dXMgYml0IG9uIHRoZSBjdXJyZW50IExTUC4g T25lIG5lZWQgdG8gc2lnbmFsIGEgc2VwYXJhdGUgTFNQLg0KDQpUaGFua3MNCktodXplbWENCg0K RnJvbTogWmFmYXIgQWxpICh6YWxpKSBbbWFpbHRvOnphbGlAY2lzY28uY29tXQ0KU2VudDogV2Vk bmVzZGF5LCBKdWx5IDMxLCAyMDEzIDI6MTcgQU0NClRvOiBLaHV6ZW1hIFBpdGhld2FuOyBDQ0FN UCAoY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPikNClN1YmplY3Q6IFJlOiBb Q0NBTVBdIGRyYWZ0LWFsaS1jY2FtcC1sc3AtaW5xdWlyeS0wMA0KDQpIaSBLaHV6ZW1hOg0KDQpG b3Igc2lnbmFsaW5nIGlucXVpcnkgTFNQIHdpdGggcmVzb3VyY2UgbG9ja2luZywgd2UgYXJlIHVz aW5nIHRoZSBQcmUtUGxhbm5lZCBMU1AgZmxhZyBhcy1pcyBhcyBkZWZpbmVkIGluIFJGQzYwMDEu IEdpdmVuIHRoaXMsIHdlIGFyZSBkZWZpbmluZyBhIG5ldyBmbGFnIHdoZW4gaW5xdWlyeSBMU1Ag bmVlZHMgdG8gYmUgc2lnbmFsIHdpdGhvdXQgcmVzb3VyY2UgbG9ja2luZy4NCg0KVGhhbmtzDQoN ClJlZ2FyZHMgoa0gWmFmYXINCg0KRnJvbTogS2h1emVtYSBQaXRoZXdhbiA8a3BpdGhld2FuQGlu ZmluZXJhLmNvbTxtYWlsdG86a3BpdGhld2FuQGluZmluZXJhLmNvbT4+DQpEYXRlOiBUdWVzZGF5 LCBKdWx5IDMwLCAyMDEzIDU6NDUgUE0NClRvOiB6YWxpIDx6YWxpQGNpc2NvLmNvbTxtYWlsdG86 emFsaUBjaXNjby5jb20+PiwgImNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4i IDxjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUkU6IFtD Q0FNUF0gZHJhZnQtYWxpLWNjYW1wLWxzcC1pbnF1aXJ5LTAwDQoNCldlbGwuLiBub3QgcmVhbGx5 Lg0KDQpZb3UgYXJlIGRlZmluaW5nIG5ldyBiaXRzIGZvciBMU1BfQVRUUklCVVRFUyBmb3IgcmVz b3VyY2UgbG9ja2luZ6GtIGFyZW6hr3QgeW91Pw0KDQpJbnN0ZWFkIG9mIGRvaW5nIHRoYXQsIHlv dSBjYW4gZGVmaW5lIGJpdHMgaW4gQURNSU5fU1RBVFVTIGFuZCBzYXZlIG5ldyBMU1AgbGlmZSBj eWNsZSBtYW5hZ2VtZW50LCB3aGljaCB3b3VsZCBiZSBxdWl0ZSBjdW1iZXJzb21lLg0KDQpSZWdh cmRzDQpLaHV6ZW1hDQoNCkZyb206IFphZmFyIEFsaSAoemFsaSkgW21haWx0bzp6YWxpQGNpc2Nv LmNvbV0NClNlbnQ6IFR1ZXNkYXksIEp1bHkgMzAsIDIwMTMgMTA6MDggUE0NClRvOiBLaHV6ZW1h IFBpdGhld2FuOyBDQ0FNUCAoY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPikN ClN1YmplY3Q6IFJlOiBbQ0NBTVBdIGRyYWZ0LWFsaS1jY2FtcC1sc3AtaW5xdWlyeS0wMA0KDQpL aHV6ZW1hOg0KDQpUaGUgcG9pbnQgaXMgdG8gcmV1c2Ugd2hhdCBhbHJlYWR5IGV4aXN0cy4gVGhl IFByZS1QbGFubmVkIExTUCBmbGFnIGluIHRoZSBBdHRyaWJ1dGUgRmxhZ3MgVExWIG9mIExTUF9B VFRSSUJVVEVTIG9iamVjdCBpcyBhbHJlYWR5IGRlZmluZWQgaW4gW1JGQzU0MjBdIGFuZCBpcyBh IGdsb3ZlIGZpdC4NCg0KVGhhbmtzDQoNClJlZ2FyZHMgoa0gWmFmYXINCg0KRnJvbTogS2h1emVt YSBQaXRoZXdhbiA8a3BpdGhld2FuQGluZmluZXJhLmNvbTxtYWlsdG86a3BpdGhld2FuQGluZmlu ZXJhLmNvbT4+DQpEYXRlOiBUdWVzZGF5LCBKdWx5IDMwLCAyMDEzIDE6NDAgUE0NClRvOiBLaHV6 ZW1hIFBpdGhld2FuIDxrcGl0aGV3YW5AaW5maW5lcmEuY29tPG1haWx0bzprcGl0aGV3YW5AaW5m aW5lcmEuY29tPj4sICJjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+IiA8Y2Nh bXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbQ0NBTVBd IGRyYWZ0LWFsaS1jY2FtcC1sc3AtaW5xdWlyeS0wMA0KDQpBbm90aGVyIHBvaW50IEkgc3Bva2Ug YWJvdXQgaW4gdGhlIG1lZXRpbmcgLi4NCg0KV2h5IGNhbqGvdCB3ZSBleHRlbmQgQWRtaW4gU3Rh dHVzIG9iamVjdCB0byBzaWduYWwgcmVzb3VyY2UgbG9ja2luZywgY2hlY2tpbmcgZm9yIHJlLW9w dGltaXphdGlvbi4gU2luY2UgdGhpcyBvcGVyYXRpb24gaXMgdHlwaWNhbGx5IGRvbmUgaW4gbWFp bnRlbmFuY2Ugd2luZG93IGJ5IEFkbWluLCBpdCBtYXkgbWFrZSBzZW5zZSB0byB1c2UgQWRtaW4g U3RhdHVzIE9iamVjdC4gTW9yZW92ZXIsIHdlIGhhdmUgbG90cyBvZiBiaXRzIGF2YWlsYWJsZS91 bmRlZmluZWQgaW4gQWRtaW4gU3RhdHVzIG9iamVjdC4NCg0KVGhpcyB3aWxsIHNhdmUgbmV0d29y ayBlbGVtZW50IHRvIG1hbmFnZSBsaWZlIG9mIGFkZGl0aW9uYWwgTFNQIGFuZCBjb250cm9sIHBs YW5lIGZhaWx1cmUgcmVsYXRlZCBpc3N1ZXMgYXR0YWNoZWQgdG8gdGhlIGFkZGl0aW9uYWwgTFNQ Lg0KDQpLaHV6ZW1hDQoNCg== --_000_F82A4B6D50F9464B8EBA55651F541CF84EE43E6FSZXEML552MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Zafar,

 

Please have a  look at draft-zhang-ccamp-gmpls-uni-app, which has a very= good solution to address the requirements in your this  draft (and some other requirements in your other drafts).

 

I don=A1=AFt think it is a good idea to overload RSVP-TE by intro= ducing path computation functions (or PCEP objects like OF you described in= another draft).

 

Thanks

 

Fatai

 

 

 

=B7=A2=BC=FE=C8=CB: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] =B4=FA=B1=ED = Zafar Ali (zali)
=B7=A2=CB=CD= =CA=B1=BC=E4: 2013=C4=EA7=D4=C2<= span lang=3D"EN-US">31=C8=D5 17:00
=CA=D5=BC=FE=C8=CB: Khuzema Pithewan; CCAMP (ccamp@ietf.org)
=D6=F7=CC=E2: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Khuzema: 

 

Please see in-line. 

 

Thanks

 

Regards =A1=AD Zafar

 

From: = Khuzema Pithewan <= kpithewan@infinera.com> Date: Wednesday, July 31, 2013 3:45 AM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Zafa= r,

 <= /span>

The poi= nt I am making here is.. the 2 approaches.. Admin Status and LSP_Attributes= , are exactly same in terms of object re-use and both of them defines new b= its for enhanced functionality. The LSP_Attribute approach has additional overhead of managing a separate control LSP, which= is not desirable.

 <= /span>

 

The inquire/ potential reopt LSP is li= kely not to follow path of the currently active LSP. Hence this cannot be i= mplemented by just adding some Admin Status bit on the current LSP. One need to signal a separate LSP. 

 

Thanks<= /span>

Khuzema=

 <= /span>

From: = Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Wednesday, July 31, 2013 2:17 AM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Khuzema:<= /o:p>

 

For signaling inquiry LSP with resource locking, we are using the Pre-Pl= anned LSP flag as-is as defined in RFC6001. Given this, we are defining a new flag when inquiry LSP needs to be signal without resource l= ocking.  =

 

Thanks

 

Regards =A1=AD Zafar

 

From: Khuzema Pithewan <= kpithewan@infinera.com> Date: Tuesday, July 30, 2013 5:45 PM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Well.. = not really.

 <= /span>

You are= defining new bits for LSP_ATTRIBUTES for resource locking=A1=AD aren=A1=AF= t you?<= /p>

 <= /span>

Instead= of doing that, you can define bits in ADMIN_STATUS and save new LSP life c= ycle management, which would be quite cumbersome.

 <= /span>

Regards=

Khuzema=

 <= /span>

From: Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Tuesday, July 30, 2013 10:08 PM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Khuzema:

 =

The point is to reuse what already exists. The Pre-Planned LSP= flag in the Attribute Flags TLV of LSP_ATTRIBUTES object is already define= d in [RFC5420] and is a glove fit. 

 =

Thanks=

 =

Regards =A1=AD Zafar

 =

From: = Khuzema Pithewan <= kpithewan@infinera.com> Date: Tuesday, July 30, 2013 1:40 PM
To: Khuzema Pithewan <k= pithewan@infinera.com>, "ccam= p@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 =

Another= point I spoke about in the meeting ..

 <= /span>

Why can= =A1=AFt we extend Admin Status object to signal resource locking, checking = for re-optimization. Since this operation is typically done in maintenance = window by Admin, it may make sense to use Admin Status Object. Moreover, we have lots of bits available/undefined in Admin= Status object.

 <= /span>

This wi= ll save network element to manage life of additional LSP and control plane = failure related issues attached to the additional LSP.

 <= /span>

Khuzema=

 <= /span>

--_000_F82A4B6D50F9464B8EBA55651F541CF84EE43E6FSZXEML552MBXchi_-- From lberger@labn.net Wed Jul 31 02:48:11 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4564921F9263 for ; Wed, 31 Jul 2013 02:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.774 X-Spam-Level: X-Spam-Status: No, score=-100.774 tagged_above=-999 required=5 tests=[AWL=-0.469, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_BL_SPAMCOP_NET=1.96, 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 UxVapeveQYod for ; Wed, 31 Jul 2013 02:48:06 -0700 (PDT) Received: from oproxy5.bluehost.com (oproxy5-pub.bluehost.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 6CBDB21F860A for ; Wed, 31 Jul 2013 02:47:57 -0700 (PDT) Received: (qmail 29575 invoked by uid 0); 31 Jul 2013 09:47:35 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy5.bluehost.com with SMTP; 31 Jul 2013 09:47:35 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:Content-Transfer-Encoding:Date:MIME-Version:Message-ID:References:Cc:To:Subject:From; bh=KH4KscYtNRSlUo3WoavSDUr9Mm70ha/QUTjo0rblDxc=; b=CEepYpEXl1rttuhbT/zLSBf1uQTzBg8vuIl/YoGzs4purwmqpkEhP3ZlvfK3v0Z9ZA218SAAo+FbFEUwQsckVX+FqXqUh2bAbBcuwM52/boCRuA+/h06nHxvUko2U3m4; Received: from [69.89.31.113] (port=35493 helo=localhost) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V4T0J-0001RE-3B; Wed, 31 Jul 2013 03:47:35 -0600 From: Lou Berger To: References: <6700accc.1375182901959@mail.labn.net> Message-ID: MIME-Version: 1.0 Date: Wed, 31 Jul 2013 11:46:28 +0200 (CEST) User-Agent: ProfiMailGo/4.10.00 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: ccamp@ietf.org Subject: Re: [CCAMP] Question about draft-ietf-ccamp-otn-g709-info-model-09.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 09:48:12 -0000 Adrian, I think we're all in agreement on this.=20 The 709 document should be fixed as part of addressing your review comment= s. Thanks, Lou On 11:03am, July 31, 2013, Adrian Farrel wrote: > Lou, >=20 > I think that is fine.=20 >=20 > This draft should give some weight to IS-IS (at least mention it :-) alon= g with > OSPF. >=20 > I am not requiring the WG to produce IS-IS solution drafts. The only requ= irement > there is to facilitate IS-IS solutions drafts if people want to write the= m and > intend to implement in code. >=20 > A >=20 > > -----Original Message----- > > From: Lou Berger [mailto:lberger@labn.net] > > Sent: 30 July 2013 12:31 > > To: adrian@olddog.co.uk > > Cc: ccamp@ietf.org > > Subject: Re: [CCAMP] Question about draft-ietf-ccamp-otn-g709-info-mode= l- > > 09.txt > >=20 > > Hi Adrian, > >=20 > > So IS-IS is certainly still a viable GMPLS routing protocol and it shou= ld be > > mentioned in the draft as a possibility. Good catch. > >=20 > > The more general issue with GMPLS IS-IS, from my perspective, is that t= here > > hasn't been much interest in working on related drafts in the WG. GMPLS= IS-IS > > remains in scope, but drafts aren't being written.=C2=A0 I take this as= the market > > "speaking". > >=20 > > Lou > >=20 > > On 10:29am, July 28, 2013, Adrian Farrel wrote: > > > Hi CCAMP, > > >=20 > > > I am currently reviewing draft-ietf-ccamp-otn-g709-info-model-09.txt > > (cunningly > > > deceptive file name ;-) > > >=20 > > > I have a question... > > >=20 > > > The document makes reference to RFC 4202 and RFC 4203, but not to RFC= 5307 > > > (obsoleted RFC 4205). Can I ask why CCAMP no longer considers IS-IS t= o be a > > > potential routing protocol for GMPLS systems? > > >=20 > > > Thanks, > > >=20 > > > Adrian > > >=20 > > > _______________________________________________ > > > CCAMP mailing list > > > CCAMP@ietf.org > > > https://www.ietf.org/mailman/listinfo/ccamp > > >=20 >=20 >=20 From zali@cisco.com Wed Jul 31 02:53:57 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62B411E810F for ; Wed, 31 Jul 2013 02:53:55 -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 C6XgO9EnA-bu for ; Wed, 31 Jul 2013 02:53:39 -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 896BE11E80EE for ; Wed, 31 Jul 2013 02:53:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11566; q=dns/txt; s=iport; t=1375264410; x=1376474010; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=uWAq2B5uqNy8m+RA4mtJTGVqmDJ9P14QmNc3d6xK3sE=; b=lLhn4KPetqyasNV8VZvgXSIMB1MXme+1FnGKzFlSxPE1xsYItPnyJqTR 4gkpmTeQ0BHwAIpFw0XXCwkpFhQpJDfdFRPKtYJZWaHQE1e76hOw24Z7D jJ03vr3iI6WE81nbMQEzfuCfB02H0oYiDl0EA0IeFLdTEevBNRORtkPSB 4=; X-Files: default.xml, default[1].xml : 3222, 3222 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAFjd+FGtJV2Y/2dsb2JhbABbgwY1UL4bgRgWdIIkAQEBBAEBAWsXBgEIEQMBAgsmJQsUCQgCBAESCAaIAgy4UwSPTRYKGAaDEnEDkBKBLZdsgxSCKg X-IronPort-AV: E=Sophos;i="4.89,786,1367971200"; d="rels'?xml'?scan'72,48,208";a="241688333" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 31 Jul 2013 09:53:28 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6V9rR0x008452 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Jul 2013 09:53:27 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Wed, 31 Jul 2013 04:53:27 -0500 From: "Zafar Ali (zali)" To: "adrian@olddog.co.uk" , "ccamp@ietf.org" Thread-Topic: [CCAMP] The thing I forgot about draft-ali-ccamp-rsvp-te-include-route Thread-Index: AQHOjdPNEjuCqoHP5EOGrOPiXXa7DA== Date: Wed, 31 Jul 2013 09:53:26 +0000 Message-ID: In-Reply-To: <029601ce8d3c$1a76cab0$4f646010$@olddog.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.212.118] Content-Type: multipart/mixed; boundary="_003_B6585D85A128FD47857D0FD58D8120D30E9F40E5xmbrcdx14ciscoc_" MIME-Version: 1.0 Subject: Re: [CCAMP] The thing I forgot about draft-ali-ccamp-rsvp-te-include-route X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 09:53:58 -0000 --_003_B6585D85A128FD47857D0FD58D8120D30E9F40E5xmbrcdx14ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable Hi Adrian-=20 Thanks for your feedback. Please see in-line. Thanks Regards =8A Zafar -----Original Message----- From: "adrian@olddog.co.uk" Reply-To: "adrian@olddog.co.uk" Date: Tuesday, July 30, 2013 11:47 AM To: "ccamp@ietf.org" Subject: [CCAMP] The thing I forgot about draft-ali-ccamp-rsvp-te-include-route >Hi, > >Sorry about my senility just now. > >The point I made was please rename the new ERO subobject to avoid >confusion >about using the referenced LSP as a tunnel or a stitching segment. Yes, we can change the name of subobject. I read the minutes and guessed George assumed an AI on this :) > >The point I forgot was to wonder whether there is a category of "best >effort" >that follows most of the referenced LSP but not all hops? Yes, current definition of inclusion (copying from draft) is: 0x02 =3D Best-effort inclusion This flag is used to indicate that the route of the LSP being signaled SHOULD follow the path specified by the LSP subobject. >Following that, what if there are specific hops in the referenced LSP >that MUST >be followed and others that only SHOULD be followed? In this case the Ingress can divide the loose hop into two loose hops: one with "lsp/ inclusion" subobject with mandatory inclusion and another one with "lsp/ inclusion" subobject with best-effort inclusion. > >Cheers, >Adrian > >_______________________________________________ >CCAMP mailing list >CCAMP@ietf.org >https://www.ietf.org/mailman/listinfo/ccamp --_003_B6585D85A128FD47857D0FD58D8120D30E9F40E5xmbrcdx14ciscoc_ Content-Type: application/xml; name="default.xml" Content-Description: default.xml Content-Disposition: attachment; filename="default.xml"; size=3222; creation-date="Wed, 31 Jul 2013 09:53:26 GMT"; modification-date="Wed, 31 Jul 2013 09:53:26 GMT" Content-ID: <48F15A95C6ACDE4C8697490AAB1000C0@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 --_003_B6585D85A128FD47857D0FD58D8120D30E9F40E5xmbrcdx14ciscoc_ Content-Type: application/xml; name="default[1].xml" Content-Description: default[1].xml Content-Disposition: attachment; filename="default[1].xml"; size=3222; creation-date="Wed, 31 Jul 2013 09:53:26 GMT"; modification-date="Wed, 31 Jul 2013 09:53:26 GMT" Content-ID: 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 --_003_B6585D85A128FD47857D0FD58D8120D30E9F40E5xmbrcdx14ciscoc_-- From zali@cisco.com Wed Jul 31 03:18:42 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9687821E8055 for ; Wed, 31 Jul 2013 03:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.074 X-Spam-Level: X-Spam-Status: No, score=-6.074 tagged_above=-999 required=5 tests=[AWL=-4.524, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vh-E2dmRs92E for ; Wed, 31 Jul 2013 03:18:37 -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 9FCB421E805F for ; Wed, 31 Jul 2013 03:18:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30775; q=dns/txt; s=iport; t=1375265914; x=1376475514; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=lu5SAd2LwbJPQFGtgLLEvc9g25c6Sb1zyUcczGegp0g=; b=ScyopBnz3PE0BAEjYkbis6ucX+OodEGN2y9GS9lRQAxbXKJN/WaAuxEN H4uOjgyhsRgRsmjqxkDPTntLIk4etWBhc0EUGW1LHtFF/lZACd5Yuptd8 HySbwayKkTlUY8CJLHBPenPX/FaePhc6vmpC055kGcHMjI1ilJbEwkgQ8 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoFAHTj+FGtJXHA/2dsb2JhbABbgkJENVCDELJMiD8XgQEWdIIkAQEBBC1eAQYCEQMBAQELFgEGBQQwFAYDCAIEARIIEQKHdQyLS5s/CJFRj00WChcBgmE3cQOZCJAjgxSCKg X-IronPort-AV: E=Sophos;i="4.89,786,1367971200"; d="scan'208,217";a="238695607" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 31 Jul 2013 10:18:33 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r6VAIWcI026467 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Jul 2013 10:18:32 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Wed, 31 Jul 2013 05:18:32 -0500 From: "Zafar Ali (zali)" To: Fatai Zhang , Khuzema Pithewan , "CCAMP (ccamp@ietf.org)" Thread-Topic: =?gb2312?B?tPC4tDogW0NDQU1QXSBkcmFmdC1hbGktY2NhbXAtbHNwLWlucXVpcnktMDA=?= Thread-Index: Ac6NL9ROMXULLvcwR2aMbEKex7ZPbAAG5uQwAAdbOAAAAUWKEAAHaZGAAA2DHKAABMFSAAABID8gAAGheQA= Date: Wed, 31 Jul 2013 10:18:32 +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.2.3.120616 x-originating-ip: [10.82.212.118] Content-Type: multipart/alternative; boundary="_000_B6585D85A128FD47857D0FD58D8120D30E9F4125xmbrcdx14ciscoc_" MIME-Version: 1.0 Subject: Re: [CCAMP] =?gb2312?b?tPC4tDogIGRyYWZ0LWFsaS1jY2FtcC1sc3AtaW5xdWly?= =?gb2312?b?eS0wMA==?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 10:18:42 -0000 --_000_B6585D85A128FD47857D0FD58D8120D30E9F4125xmbrcdx14ciscoc_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RmF0YWk6DQoNClNlcnZpY2UgcHJvdmlkZXIgbWF5IE5PVCB1c2UgUENFIGluIGFsbCBkZXBsb3lt ZW50cywgZS5nLiwgYXMgaXQgaXMgdGhlIGNhc2Ugb2YgbW9zdCwgaWYgbm90IGFsbCwgb2YgdGhl IGN1cnJlbnQgZGVwbG95bWVudHMuIEkgd291bGQgYWxzbyBhcmd1ZSB0aGF0IFBDRSBpcyBub3Qg YmUgYmVzdCBwbGFjZSBmb3IgdGhlIGlucXVpcnkgdHlwZSBwcm9jZWR1cmUgYXMgc2NvcGUgb2Yg UENFIGlzIHBhdGggY29tcHV0YXRpb24uIFBhdGggaW5xdWlyeSBpcyBub3QgYWJvdXQgcGF0aCBj b21wdXRhdGlvbiBidXQgYWJvdXQgcHJvYmluZyBmZWFzaWJpbGl0eSBvZiBhIHBhdGguDQoNClRo YW5rcw0KDQpSZWdhcmRzIKGtIFphZmFyDQoNCkZyb206IEZhdGFpIFpoYW5nIDx6aGFuZ2ZhdGFp QGh1YXdlaS5jb208bWFpbHRvOnpoYW5nZmF0YWlAaHVhd2VpLmNvbT4+DQpEYXRlOiBXZWRuZXNk YXksIEp1bHkgMzEsIDIwMTMgNTozMiBBTQ0KVG86IHphbGkgPHphbGlAY2lzY28uY29tPG1haWx0 bzp6YWxpQGNpc2NvLmNvbT4+LCBLaHV6ZW1hIFBpdGhld2FuIDxrcGl0aGV3YW5AaW5maW5lcmEu Y29tPG1haWx0bzprcGl0aGV3YW5AaW5maW5lcmEuY29tPj4sICJjY2FtcEBpZXRmLm9yZzxtYWls dG86Y2NhbXBAaWV0Zi5vcmc+IiA8Y2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3Jn Pj4NClN1YmplY3Q6ILTwuLQ6IFtDQ0FNUF0gZHJhZnQtYWxpLWNjYW1wLWxzcC1pbnF1aXJ5LTAw DQoNCkhpIFphZmFyLA0KDQpQbGVhc2UgaGF2ZSBhICBsb29rIGF0IGRyYWZ0LXpoYW5nLWNjYW1w LWdtcGxzLXVuaS1hcHA8aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXpoYW5nLWNjYW1w LWdtcGxzLXVuaS1hcHAtMDQudHh0Piwgd2hpY2ggaGFzIGEgdmVyeSBnb29kIHNvbHV0aW9uIHRv IGFkZHJlc3MgdGhlIHJlcXVpcmVtZW50cyBpbiB5b3VyIHRoaXMgIGRyYWZ0IChhbmQgc29tZSBv dGhlciByZXF1aXJlbWVudHMgaW4geW91ciBvdGhlciBkcmFmdHMpLg0KDQpJIGRvbqGvdCB0aGlu ayBpdCBpcyBhIGdvb2QgaWRlYSB0byBvdmVybG9hZCBSU1ZQLVRFIGJ5IGludHJvZHVjaW5nIHBh dGggY29tcHV0YXRpb24gZnVuY3Rpb25zIChvciBQQ0VQIG9iamVjdHMgbGlrZSBPRiB5b3UgZGVz Y3JpYmVkIGluIGFub3RoZXIgZHJhZnQpLg0KDQpUaGFua3MNCg0KRmF0YWkNCg0KDQoNCreivP7I yzogY2NhbXAtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZz4g W21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSC0+rHtIFphZmFyIEFsaSAoemFsaSkNCrei y83KsbzkOiAyMDEzxOo31MIzMcjVIDE3OjAwDQrK1bz+yMs6IEtodXplbWEgUGl0aGV3YW47IEND QU1QIChjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+KQ0K1vfM4jogUmU6IFtD Q0FNUF0gZHJhZnQtYWxpLWNjYW1wLWxzcC1pbnF1aXJ5LTAwDQoNCkhpIEtodXplbWE6DQoNClBs ZWFzZSBzZWUgaW4tbGluZS4NCg0KVGhhbmtzDQoNClJlZ2FyZHMgoa0gWmFmYXINCg0KRnJvbTog S2h1emVtYSBQaXRoZXdhbiA8a3BpdGhld2FuQGluZmluZXJhLmNvbTxtYWlsdG86a3BpdGhld2Fu QGluZmluZXJhLmNvbT4+DQpEYXRlOiBXZWRuZXNkYXksIEp1bHkgMzEsIDIwMTMgMzo0NSBBTQ0K VG86IHphbGkgPHphbGlAY2lzY28uY29tPG1haWx0bzp6YWxpQGNpc2NvLmNvbT4+LCAiY2NhbXBA aWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPiIgPGNjYW1wQGlldGYub3JnPG1haWx0bzpj Y2FtcEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogW0NDQU1QXSBkcmFmdC1hbGktY2NhbXAtbHNw LWlucXVpcnktMDANCg0KSGkgWmFmYXIsDQoNClRoZSBwb2ludCBJIGFtIG1ha2luZyBoZXJlIGlz Li4gdGhlIDIgYXBwcm9hY2hlcy4uIEFkbWluIFN0YXR1cyBhbmQgTFNQX0F0dHJpYnV0ZXMsIGFy ZSBleGFjdGx5IHNhbWUgaW4gdGVybXMgb2Ygb2JqZWN0IHJlLXVzZSBhbmQgYm90aCBvZiB0aGVt IGRlZmluZXMgbmV3IGJpdHMgZm9yIGVuaGFuY2VkIGZ1bmN0aW9uYWxpdHkuIFRoZSBMU1BfQXR0 cmlidXRlIGFwcHJvYWNoIGhhcyBhZGRpdGlvbmFsIG92ZXJoZWFkIG9mIG1hbmFnaW5nIGEgc2Vw YXJhdGUgY29udHJvbCBMU1AsIHdoaWNoIGlzIG5vdCBkZXNpcmFibGUuDQoNCg0KVGhlIGlucXVp cmUvIHBvdGVudGlhbCByZW9wdCBMU1AgaXMgbGlrZWx5IG5vdCB0byBmb2xsb3cgcGF0aCBvZiB0 aGUgY3VycmVudGx5IGFjdGl2ZSBMU1AuIEhlbmNlIHRoaXMgY2Fubm90IGJlIGltcGxlbWVudGVk IGJ5IGp1c3QgYWRkaW5nIHNvbWUgQWRtaW4gU3RhdHVzIGJpdCBvbiB0aGUgY3VycmVudCBMU1Au IE9uZSBuZWVkIHRvIHNpZ25hbCBhIHNlcGFyYXRlIExTUC4NCg0KVGhhbmtzDQpLaHV6ZW1hDQoN CkZyb206IFphZmFyIEFsaSAoemFsaSkgW21haWx0bzp6YWxpQGNpc2NvLmNvbV0NClNlbnQ6IFdl ZG5lc2RheSwgSnVseSAzMSwgMjAxMyAyOjE3IEFNDQpUbzogS2h1emVtYSBQaXRoZXdhbjsgQ0NB TVAgKGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4pDQpTdWJqZWN0OiBSZTog W0NDQU1QXSBkcmFmdC1hbGktY2NhbXAtbHNwLWlucXVpcnktMDANCg0KSGkgS2h1emVtYToNCg0K Rm9yIHNpZ25hbGluZyBpbnF1aXJ5IExTUCB3aXRoIHJlc291cmNlIGxvY2tpbmcsIHdlIGFyZSB1 c2luZyB0aGUgUHJlLVBsYW5uZWQgTFNQIGZsYWcgYXMtaXMgYXMgZGVmaW5lZCBpbiBSRkM2MDAx LiBHaXZlbiB0aGlzLCB3ZSBhcmUgZGVmaW5pbmcgYSBuZXcgZmxhZyB3aGVuIGlucXVpcnkgTFNQ IG5lZWRzIHRvIGJlIHNpZ25hbCB3aXRob3V0IHJlc291cmNlIGxvY2tpbmcuDQoNClRoYW5rcw0K DQpSZWdhcmRzIKGtIFphZmFyDQoNCkZyb206IEtodXplbWEgUGl0aGV3YW4gPGtwaXRoZXdhbkBp bmZpbmVyYS5jb208bWFpbHRvOmtwaXRoZXdhbkBpbmZpbmVyYS5jb20+Pg0KRGF0ZTogVHVlc2Rh eSwgSnVseSAzMCwgMjAxMyA1OjQ1IFBNDQpUbzogemFsaSA8emFsaUBjaXNjby5jb208bWFpbHRv OnphbGlAY2lzY28uY29tPj4sICJjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+ IiA8Y2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBb Q0NBTVBdIGRyYWZ0LWFsaS1jY2FtcC1sc3AtaW5xdWlyeS0wMA0KDQpXZWxsLi4gbm90IHJlYWxs eS4NCg0KWW91IGFyZSBkZWZpbmluZyBuZXcgYml0cyBmb3IgTFNQX0FUVFJJQlVURVMgZm9yIHJl c291cmNlIGxvY2tpbmehrSBhcmVuoa90IHlvdT8NCg0KSW5zdGVhZCBvZiBkb2luZyB0aGF0LCB5 b3UgY2FuIGRlZmluZSBiaXRzIGluIEFETUlOX1NUQVRVUyBhbmQgc2F2ZSBuZXcgTFNQIGxpZmUg Y3ljbGUgbWFuYWdlbWVudCwgd2hpY2ggd291bGQgYmUgcXVpdGUgY3VtYmVyc29tZS4NCg0KUmVn YXJkcw0KS2h1emVtYQ0KDQpGcm9tOiBaYWZhciBBbGkgKHphbGkpIFttYWlsdG86emFsaUBjaXNj by5jb21dDQpTZW50OiBUdWVzZGF5LCBKdWx5IDMwLCAyMDEzIDEwOjA4IFBNDQpUbzogS2h1emVt YSBQaXRoZXdhbjsgQ0NBTVAgKGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4p DQpTdWJqZWN0OiBSZTogW0NDQU1QXSBkcmFmdC1hbGktY2NhbXAtbHNwLWlucXVpcnktMDANCg0K S2h1emVtYToNCg0KVGhlIHBvaW50IGlzIHRvIHJldXNlIHdoYXQgYWxyZWFkeSBleGlzdHMuIFRo ZSBQcmUtUGxhbm5lZCBMU1AgZmxhZyBpbiB0aGUgQXR0cmlidXRlIEZsYWdzIFRMViBvZiBMU1Bf QVRUUklCVVRFUyBvYmplY3QgaXMgYWxyZWFkeSBkZWZpbmVkIGluIFtSRkM1NDIwXSBhbmQgaXMg YSBnbG92ZSBmaXQuDQoNClRoYW5rcw0KDQpSZWdhcmRzIKGtIFphZmFyDQoNCkZyb206IEtodXpl bWEgUGl0aGV3YW4gPGtwaXRoZXdhbkBpbmZpbmVyYS5jb208bWFpbHRvOmtwaXRoZXdhbkBpbmZp bmVyYS5jb20+Pg0KRGF0ZTogVHVlc2RheSwgSnVseSAzMCwgMjAxMyAxOjQwIFBNDQpUbzogS2h1 emVtYSBQaXRoZXdhbiA8a3BpdGhld2FuQGluZmluZXJhLmNvbTxtYWlsdG86a3BpdGhld2FuQGlu ZmluZXJhLmNvbT4+LCAiY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPiIgPGNj YW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW0NDQU1Q XSBkcmFmdC1hbGktY2NhbXAtbHNwLWlucXVpcnktMDANCg0KQW5vdGhlciBwb2ludCBJIHNwb2tl IGFib3V0IGluIHRoZSBtZWV0aW5nIC4uDQoNCldoeSBjYW6hr3Qgd2UgZXh0ZW5kIEFkbWluIFN0 YXR1cyBvYmplY3QgdG8gc2lnbmFsIHJlc291cmNlIGxvY2tpbmcsIGNoZWNraW5nIGZvciByZS1v cHRpbWl6YXRpb24uIFNpbmNlIHRoaXMgb3BlcmF0aW9uIGlzIHR5cGljYWxseSBkb25lIGluIG1h aW50ZW5hbmNlIHdpbmRvdyBieSBBZG1pbiwgaXQgbWF5IG1ha2Ugc2Vuc2UgdG8gdXNlIEFkbWlu IFN0YXR1cyBPYmplY3QuIE1vcmVvdmVyLCB3ZSBoYXZlIGxvdHMgb2YgYml0cyBhdmFpbGFibGUv dW5kZWZpbmVkIGluIEFkbWluIFN0YXR1cyBvYmplY3QuDQoNClRoaXMgd2lsbCBzYXZlIG5ldHdv cmsgZWxlbWVudCB0byBtYW5hZ2UgbGlmZSBvZiBhZGRpdGlvbmFsIExTUCBhbmQgY29udHJvbCBw bGFuZSBmYWlsdXJlIHJlbGF0ZWQgaXNzdWVzIGF0dGFjaGVkIHRvIHRoZSBhZGRpdGlvbmFsIExT UC4NCg0KS2h1emVtYQ0KDQo= --_000_B6585D85A128FD47857D0FD58D8120D30E9F4125xmbrcdx14ciscoc_ Content-Type: text/html; charset="gb2312" Content-ID: <62B5936CA308AC4E9813FAC020C2B62C@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Fatai: 

Service provider may NOT use PCE in all deployments, e.g., as it is th= e case of most, if not all, of the current deployments. I would also argue = that PCE is not be best place for the inquiry type procedure as scope of PC= E is path computation. Path inquiry is not about path computation but about probing feasibility of a path.&nbs= p;

Thanks

Regards =A1=AD Zafar

From: Fatai Zhang <zhangfatai@huawei.com>
Date: Wednesday, July 31, 2013 5:32= AM
To: zali <zali@cisco.com>, Khuzema Pithewan <kpithewan@infinera.com>, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: =B4=F0=B8=B4: [CCAMP] draf= t-ali-ccamp-lsp-inquiry-00

Hi Zafar,

 

Please have a  look at draft-zhang-ccamp-gmpls-uni-app, which has a very good solution to = address the requirements in your this  draft (and some other requirements in your other drafts).=

 

I don=A1=AFt think it is a good idea to overload RSVP-TE by intro= ducing path computation functions (or PCEP objects like OF you described in= another draft).

 

Thanks

 

Fatai

 

 

 

=B7=A2=BC=FE=C8=CB: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] =B4=FA=B1=ED = Zafar Ali (zali)
=B7=A2=CB=CD= =CA=B1=BC=E4: 2013=C4=EA7=D4=C2<= span lang=3D"EN-US">31=C8=D5 17:00
=CA=D5=BC=FE=C8=CB: Khuzema Pithewan; CCAMP (ccamp@ie= tf.org)
=D6=F7=CC=E2: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Khuzema: 

 

Please see in-line. 

 

Thanks

 

Regards =A1=AD Zafar

 

From: = Khuzema Pithewan <= kpithewan@infinera.com> Date: Wednesday, July 31, 2013 3:45 AM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Zafa= r,

 <= /span>

The poi= nt I am making here is.. the 2 approaches.. Admin Status and LSP_Attributes= , are exactly same in terms of object re-use and both of them defines new b= its for enhanced functionality. The LSP_Attribute approach has additional overhead of managing a separate control LSP, which= is not desirable.

 <= /span>

 

The inquire/ potential reopt LSP is li= kely not to follow path of the currently active LSP. Hence this cannot be i= mplemented by just adding some Admin Status bit on the current LSP. One need to signal a separate LSP. 

 

Thanks<= /span>

Khuzema=

 <= /span>

From: Zafar Ali (zali) [mailto:zali@cisco.com] <= br> Sent: Wednesday, July 31, 2013 2:17 AM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Khuze= ma:

 =

For signaling= inquiry LSP with resource locking, we are using the Pre-Planned LSP flag&n= bsp;as-is as defined in RFC6001. Given this, we are defining a new flag when inquiry LSP needs to be signal without res= ource locking.  

 =

Thanks=

 =

Regards =A1= =AD Zafar

 

From: Khuzema Pithewan <= kpithewan@infinera.com> Date: Tuesday, July 30, 2013 5:45 PM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Well.. = not really.

 <= /span>

You are= defining new bits for LSP_ATTRIBUTES for resource locking=A1=AD aren=A1=AF= t you?<= /p>

 <= /span>

Instead= of doing that, you can define bits in ADMIN_STATUS and save new LSP life c= ycle management, which would be quite cumbersome.

 <= /span>

Regards=

Khuzema=

 <= /span>

From: Zafar Ali (zali) [mailto:zali= @cisco.com]
Sent: Tuesday, July 30, 2013 10:08 PM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Khuzema:

 =

The point is to reuse what already exists. The Pre-Planned LSP= flag in the Attribute Flags TLV of LSP_ATTRIBUTES object is already define= d in [RFC5420] and is a glove fit. 

 =

Thanks=

 =

Regards =A1=AD Zafar

 =

From: = Khuzema Pithewan <= kpithewan@infinera.com> Date: Tuesday, July 30, 2013 1:40 PM
To: Khuzema Pithewan <k= pithewan@infinera.com>, "ccam= p@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 =

Another= point I spoke about in the meeting ..

 <= /span>

Why can= =A1=AFt we extend Admin Status object to signal resource locking, checking = for re-optimization. Since this operation is typically done in maintenance = window by Admin, it may make sense to use Admin Status Object. Moreover, we have lots of bits available/undefined in Admin= Status object.

 <= /span>

This wi= ll save network element to manage life of additional LSP and control plane = failure related issues attached to the additional LSP.

 <= /span>

Khuzema=

 <= /span>

--_000_B6585D85A128FD47857D0FD58D8120D30E9F4125xmbrcdx14ciscoc_-- From internet-drafts@ietf.org Wed Jul 31 03:25:21 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14AB911E8151; Wed, 31 Jul 2013 03:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.551 X-Spam-Level: X-Spam-Status: No, score=-102.551 tagged_above=-999 required=5 tests=[AWL=0.049, 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 bWn4EdKPucOq; Wed, 31 Jul 2013 03:25:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7137E11E80C5; Wed, 31 Jul 2013 03:25:20 -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.60p1 Message-ID: <20130731102520.16585.93118.idtracker@ietfa.amsl.com> Date: Wed, 31 Jul 2013 03:25:20 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-otn-g709-info-model-10.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 10:25:21 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane Work= ing Group of the IETF. Title : Evaluation of existing GMPLS encoding against G.709v3 Op= tical Transport Networks (OTN) Author(s) : Sergio Belotti Pietro Vittorio Grandi Daniele Ceccarelli Diego Caviglia Fatai Zhang Dan Li Filename : draft-ietf-ccamp-otn-g709-info-model-10.txt Pages : 22 Date : 2013-07-31 Abstract: ITU-T recommendation G.709 [G.709-2012] has introduced new fixed and flexible Optical Data Unit (ODU) containers in Optical Transport Networks (OTNs). This document provides an evaluation of existing Generalized Multiprotocol Label Switching (GMPLS) routing and signaling protocols against the G.709 [G.709-2012] OTN networks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ccamp-otn-g709-info-model There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-ccamp-otn-g709-info-model-10 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ccamp-otn-g709-info-model-10 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From daniele.ceccarelli@ericsson.com Wed Jul 31 03:29:08 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 710F211E80C5 for ; Wed, 31 Jul 2013 03:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OULpx4lebpJ6 for ; Wed, 31 Jul 2013 03:29:03 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 60FD711E80E4 for ; Wed, 31 Jul 2013 03:28:58 -0700 (PDT) X-AuditID: c1b4fb30-b7ef76d000004bbc-7e-51f8e6e8f06f Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 02.66.19388.8E6E8F15; Wed, 31 Jul 2013 12:28:57 +0200 (CEST) Received: from ESESSMB301.ericsson.se ([169.254.1.144]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Wed, 31 Jul 2013 12:28:56 +0200 From: Daniele Ceccarelli To: "adrian@olddog.co.uk" , "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" Thread-Topic: [CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model Thread-Index: Ac6LhtnSfQOotGSxTSGTJyWDc179HQCSrD6A Date: Wed, 31 Jul 2013 10:28:56 +0000 Message-ID: <4A1562797D64E44993C5CBF38CF1BE48126BF3@ESESSMB301.ericsson.se> References: <031c01ce8b87$45b79cb0$d126d610$@olddog.co.uk> In-Reply-To: <031c01ce8b87$45b79cb0$d126d610$@olddog.co.uk> Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvre7LZz8CDZZ957b40XOD2eLJnBss FlNmf2dxYPZYsuQnk8eKzSsZPb5c/swWwBzFZZOSmpNZllqkb5fAlXG97wR7wQvdip/9U1kb GH8pdzFyckgImEhs+neRHcIWk7hwbz1bFyMXh5DAYUaJySfms0M4Sxglrv6Yx9rFyMHBJmAl 8eSQD0hcRGABo8T8H5/BupkFVCXarp9iBbGFBdwkfm2fxwxiiwi4SyzrOsoEYRtJ7D39EyzO AlR/7MZxsHpeAW+JrnfHWEDmCwHNP7TcGSTMKWAtcfPkf7ASRgFZiQm7FzFCrBKXuPVkPhPE 0QISS/acZ4awRSVePv7HCmErSTQuecIKUa8jsWD3JzYIW1ti2cLXzBBrBSVOznzCMoFRbBaS sbOQtMxC0jILScsCRpZVjOy5iZk56eXmmxiBcXNwy2+DHYyb7osdYpTmYFES592sdyZQSCA9 sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2PYF6GW2/JR3JU9TdecC3/f/P9romLdluXh/wMdOdc/ KI0JYJrSHXDr5vnpzb992eTco/ddOBQp57P/sq57dePtB9kP77m9K+56rDU1dk3qh03b5ms1 3Pm5wUI9/1L45QPWc15runz+yp035dUKscz3oY1yTxy/5hyd5tWooPTvm5fqDQ5BhlIlluKM REMt5qLiRABUkH0aaQIAAA== Cc: "ccamp@ietf.org" Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 10:29:08 -0000 Adrian, Thanks for your review and suggestions. The document has been updated and inline below you can find comments on the= modifications made. Thanks The authors > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > Of Adrian Farrel > Sent: domenica 28 luglio 2013 13:41 > To: draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org > Cc: ccamp@ietf.org > Subject: [CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model >=20 > Hi, >=20 > I have done my normal AD review of your document after receiving the > Publication Request. As usual, the purpose of the review is to catch iss= ues > and nits as early as possible so that they don't get in the way during IE= TF last > call and IESG evaluation. >=20 > The review below includes a few nits and raises a couple of questions. > All of the issues are open for discussion, and I am quite prepared to hea= r back > that the WG considered things and reached consensus. >=20 > For the moment, I have marked the I-D as "Revised I-D Needed". >=20 > Thanks for the work, >=20 > Adrian >=20 > =3D=3D=3D >=20 > As I asked in my email to the CCAMP list, I find it odd that this documen= t makes > no reference to RFC 5307 and the use of IS-IS as a routing protocol in GM= PLS > control of OTN. >=20 =20 At the end of the intro we added the following sentence: " As far as it concerns routing, analogous considerations apply to IS-IS [RFC5307] but in the following only a gap analysis with respect to OSPF-T= E is provided." > --- >=20 > Section 1 says: >=20 > Specific routing and signaling extensions are defined in [OTN-OSPF] > and [OTN-RSVP]. >=20 > I think you might extend this text to note that those two documents and t= he > extensions they define, specifically address the gaps identified in this > document. >=20 =20 OK. The following text has been added: "Specific routing and signaling extensions defined in [OTN-OSPF] and [OTN-RSVP] specifically address the gaps identified in this document." > --- >=20 > I found it hard to see the clear gap analysis in section 9. I think what= it says is > generic and not specific to OTN - i.e., there is a need to distinguish sw= itching > capabilities from adaptation/termination capabilities. >=20 > Am I missing something? Why does OTN have this issue? Should this be > handled as a technology-independent issue? > Added the following text at the end of section 9:=20 "The issue shown above is analyzed in an OTN context but it is a general te= chnology independent GMPLS limitation." > --- >=20 > Section 10 has >=20 > The IETF foresees that up to eight priorities must be supported and > that all of them have to be advertised independently on the number of > priorities supported by the implementation. Considering that the > advertisement of all the different supported signal types will > originate large LSAs, it is advised to advertise only the information > related to the really supported priorities. >=20 > The language here is a bit odd to me. > ... *foresees* that *up*to* eight priorities *must* be supported ... ? >=20 > How about... >=20 > [RFC4202] defines 8 priorities for resource availability and usage. >=20 [RFC4202] defines 8 priorities for resource availability and usage. =20 All of them have to be advertised independently on the number of prioritie= s=20 supported by the implementation. Considering that the advertisement of=20 all the different supported signal types will originate large LSAs, it is advised to advertise only the information related to the really supported = priorities. =20 > --- >=20 > Section 11 >=20 > Modifications to ISCD/IACD, if needed, have to be addressed in the > related encoding documents. >=20 > I think this document needs to state whether those modifications are need= ed. >=20 =20 Sentence dropped and added this one at the end of the section: "What said above implies augmenting both the ISCD and the IACD." > --- >=20 > Section 12 >=20 > The ODUk label format defined in [RFC4328] could be updated to > support new signal types defined in [G.709-2012] but would hardly be > further enhanced to support possible new signal types. >=20 > What does "hardly" mean in this text? So you mean "it would be difficult= "? If > so.... >=20 > The ODUk label format defined in [RFC4328] could be updated to > support new signal types defined in [G.709-2012] but it would be > difficult to further enhanced it to support possible new signal > types. >=20 ok > --- >=20 > Section 12 >=20 > Furthermore such label format may have scalability issues due to the > high number of labels needed when signaling large LSPs. For example, > when an ODU3 is mapped into an ODU4 with 1.25Gbps tributary slots, it > would require the utilization of thirty-one labels (31*4*8=3D992 bits) > to be allocated while an ODUflex into an ODU4 may need up to eighty > labels (80*4*8=3D2560 bits). >=20 > The maths is flawless. Does the WG believe that this scenario is likely?= Or is it > just a theoretical possibility? >=20 > I ask because I am cautious about us engineering for fringe cases. Multiplexing an ODU3 or an ODUflex into an ODU4 is a pretty common scenario= . 100Gbps lambdas are being widely deployed and OTN is used to groom traffi= c.=20 >=20 > --- >=20 > I think a number of your Informative references are actually used as > Normative. I would list >=20 > [RFC3471], [RFC3473], [RFC4202], [RFC4203], [RFC4328], and [RFC5339]. OK >=20 > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From cyril.margaria@coriant.com Wed Jul 31 03:47:03 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AED1B11E80EC for ; Wed, 31 Jul 2013 03:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.806 X-Spam-Level: X-Spam-Status: No, score=-0.806 tagged_above=-999 required=5 tests=[AWL=-1.340, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 gnt3YTF7Pgec for ; Wed, 31 Jul 2013 03:46:56 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0187.outbound.messaging.microsoft.com [213.199.154.187]) by ietfa.amsl.com (Postfix) with ESMTP id 8BEBC11E80D1 for ; Wed, 31 Jul 2013 03:46:55 -0700 (PDT) Received: from mail216-db8-R.bigfish.com (10.174.8.254) by DB8EHSOBE037.bigfish.com (10.174.4.100) with Microsoft SMTP Server id 14.1.225.22; Wed, 31 Jul 2013 10:46:54 +0000 Received: from mail216-db8 (localhost [127.0.0.1]) by mail216-db8-R.bigfish.com (Postfix) with ESMTP id 2067DE00DF; Wed, 31 Jul 2013 10:46:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.53; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0411HT003.eurprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: PS-22(zz9371Ic89bhc85dh31c5Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah18c673h1c8fb4h1de096h8275bh8275dh1de097hz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail216-db8: domain of coriant.com designates 157.56.253.53 as permitted sender) client-ip=157.56.253.53; envelope-from=cyril.margaria@coriant.com; helo=DB3PRD0411HT003.eurprd04.prod.outlook.com ; .outlook.com ; Received: from mail216-db8 (localhost.localdomain [127.0.0.1]) by mail216-db8 (MessageSwitch) id 1375267612606569_16380; Wed, 31 Jul 2013 10:46:52 +0000 (UTC) Received: from DB8EHSMHS005.bigfish.com (unknown [10.174.8.229]) by mail216-db8.bigfish.com (Postfix) with ESMTP id 8ED02220046; Wed, 31 Jul 2013 10:46:52 +0000 (UTC) Received: from DB3PRD0411HT003.eurprd04.prod.outlook.com (157.56.253.53) by DB8EHSMHS005.bigfish.com (10.174.4.15) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 31 Jul 2013 10:46:52 +0000 Received: from DB3PRD0411MB427.eurprd04.prod.outlook.com ([169.254.6.251]) by DB3PRD0411HT003.eurprd04.prod.outlook.com ([10.255.73.38]) with mapi id 14.16.0341.000; Wed, 31 Jul 2013 10:46:51 +0000 From: "Margaria, Cyril (Coriant - DE/Munich)" To: "Zafar Ali (zali)" , Khuzema Pithewan , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Thread-Index: Ac6NL9ROMXULLvcwR2aMbEKex7ZPbAAG5uQwAAdbOAAAAUWKEAAHaZGAAA2DHKAABMFSAAABVtHg Date: Wed, 31 Jul 2013 10:46:50 +0000 Message-ID: <523C37072C291347B9730C9291CCA07D0D0F1B@DB3PRD0411MB427.eurprd04.prod.outlook.com> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.21.250] Content-Type: multipart/alternative; boundary="_000_523C37072C291347B9730C9291CCA07D0D0F1BDB3PRD0411MB427eu_" MIME-Version: 1.0 X-FOPE-CRA-Verdict: 157.56.253.53$infinera.com%0%1%coriant.com%False%False%0$ X-OriginatorOrg: coriant.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%INFINERA.COM$RO%1$TLS%0$FQDN%$TlsDn% Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 10:47:03 -0000 --_000_523C37072C291347B9730C9291CCA07D0D0F1BDB3PRD0411MB427eu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, For the resource reservation aspect, this seems related to priorities, LSP = inquiry without reservation could be defined as LSP with setup, holding pri= ority 8 (or 255). This would in addition allow for reporting when the resou= rce are gone (preempted) Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Z= afar Ali (zali) Sent: Wednesday, July 31, 2013 11:00 AM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Khuzema: Please see in-line. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Wednesday, July 31, 2013 3:45 AM To: zali >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Zafar, The point I am making here is.. the 2 approaches.. Admin Status and LSP_Att= ributes, are exactly same in terms of object re-use and both of them define= s new bits for enhanced functionality. The LSP_Attribute approach has addit= ional overhead of managing a separate control LSP, which is not desirable. The inquire/ potential reopt LSP is likely not to follow path of the curren= tly active LSP. Hence this cannot be implemented by just adding some Admin = Status bit on the current LSP. One need to signal a separate LSP. Thanks Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Wednesday, July 31, 2013 2:17 AM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Khuzema: For signaling inquiry LSP with resource locking, we are using the Pre-Plann= ed LSP flag as-is as defined in RFC6001. Given this, we are defining a new = flag when inquiry LSP needs to be signal without resource locking. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 5:45 PM To: zali >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Well.. not really. You are defining new bits for LSP_ATTRIBUTES for resource locking... aren't= you? Instead of doing that, you can define bits in ADMIN_STATUS and save new LSP= life cycle management, which would be quite cumbersome. Regards Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Tuesday, July 30, 2013 10:08 PM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Khuzema: The point is to reuse what already exists. The Pre-Planned LSP flag in the = Attribute Flags TLV of LSP_ATTRIBUTES object is already defined in [RFC5420= ] and is a glove fit. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 1:40 PM To: Khuzema Pithewan = >, "ccamp@ietf.org" > Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Another point I spoke about in the meeting .. Why can't we extend Admin Status object to signal resource locking, checkin= g for re-optimization. Since this operation is typically done in maintenanc= e window by Admin, it may make sense to use Admin Status Object. Moreover, = we have lots of bits available/undefined in Admin Status object. This will save network element to manage life of additional LSP and control= plane failure related issues attached to the additional LSP. Khuzema --_000_523C37072C291347B9730C9291CCA07D0D0F1BDB3PRD0411MB427eu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi, =

 

For the resource reser= vation aspect, this seems related to priorities, LSP inquiry without reserv= ation could be defined as LSP with setup, holding priority 8 (or 255). This= would in addition allow for reporting when the resource are gone (preempted)

 

Mit freundlic= hen Gr=FC=DFen / Best Regards
Cyril Margaria

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: Wednesday, July 31, 2013 11:00 AM
To: Khuzema Pithewan; CCAMP (ccamp@ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Khuz= ema: 

&n= bsp;

Please = see in-line. 

&n= bsp;

Thanks<= o:p>

&n= bsp;

Regards= … Zafar

&n= bsp;

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Wednesday, July 31, 2013 3:45 AM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

&n= bsp;

Hi Zafar,

 

The point I am making = here is.. the 2 approaches.. Admin Status and LSP_Attributes, are exactly s= ame in terms of object re-use and both of them defines new bits for enhance= d functionality. The LSP_Attribute approach has additional overhead of managing a separate control LSP, which is not d= esirable.

 

 

The inquire/ potential reopt LSP is likely not to fol= low path of the currently active LSP. Hence this cannot be implemented by j= ust adding some Admin Status bit on the current LSP. One need to signal a separate LSP. 

 

Thanks

Khuzema

 

From: Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Wednesday, July 31, 2013 2:17 AM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 =

Hi Khuz= ema:

 

For signalin= g inquiry LSP with resource locking, we are using the Pre-Planned LSP flag&= nbsp;as-is as defined in RFC6001. Given this, we are defining a new flag when inquiry LSP needs to be signal without resource locking. &nb= sp;

 

Thanks

 

Regards R= 30; Zafar

 <= /span>

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Tuesday, July 30, 2013 5:45 PM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 <= /span>

Well.. not really.

 

You are defining new b= its for LSP_ATTRIBUTES for resource locking… aren’t you?=

 

Instead of doing that,= you can define bits in ADMIN_STATUS and save new LSP life cycle management= , which would be quite cumbersome.<= /o:p>

 

Regards

Khuzema

 

From: Zafar Ali (zali) [mailto:= zali@cisco.com]
Sent: Tuesday, July 30, 2013 10:08 PM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 =

Khuzema= :

 <= /span>

The poi= nt is to reuse what already exists. The Pre-Planned LSP flag in the At= tribute Flags TLV of LSP_ATTRIBUTES object is already defined in [RFC5420] = and is a glove fit. 

 <= /span>

Thanks<= /span>

 <= /span>

Regards= … Zafar

 <= /span>

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Tuesday, July 30, 2013 1:40 PM
To: Khuzema Pithewan <k= pithewan@infinera.com>, "ccam= p@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 <= /span>

Another point I spoke = about in the meeting ..

 

Why can’t we ext= end Admin Status object to signal resource locking, checking for re-optimiz= ation. Since this operation is typically done in maintenance window by Admi= n, it may make sense to use Admin Status Object. Moreover, we have lots of bits available/undefined in Admin Status object.=

 

This will save network= element to manage life of additional LSP and control plane failure related= issues attached to the additional LSP.<= o:p>

 

Khuzema

 

--_000_523C37072C291347B9730C9291CCA07D0D0F1BDB3PRD0411MB427eu_-- From zali@cisco.com Wed Jul 31 03:54:33 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6644611E8175 for ; Wed, 31 Jul 2013 03:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.844 X-Spam-Level: X-Spam-Status: No, score=-9.844 tagged_above=-999 required=5 tests=[AWL=0.754, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juWICZjkpL1n for ; Wed, 31 Jul 2013 03:54:27 -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 748AD11E8176 for ; Wed, 31 Jul 2013 03:54:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26300; q=dns/txt; s=iport; t=1375268067; x=1376477667; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=lAmvZW+hNkMsXwnVa7tSNZuULzj7DIgYweDhSIbHmYU=; b=HA1IXhVt7LKkUEZAY9q8fSjdtNjm9uhed8gKhfQh1ohG7jREVq1eB6vp RzMLPIlHKZdFT3i2ydPLHEefMrpOjhoJ9LhslNTbuYpofe3ZeXK8lD6av EgWBzXDN7Z5uUbqzjvFZGiMZ9DviO6ZV69na4qDXnxHrFcT5bWExbc1He M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAFrs+FGtJV2Y/2dsb2JhbABbgkJENVC+HIEYFnSCJAEBAQQtXgEIEQMBAQELFgc5FAkIAgQBEggRh3e4co9WDRMXAYMYcwOpLIMUgio X-IronPort-AV: E=Sophos;i="4.89,786,1367971200"; d="scan'208,217";a="241790014" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 31 Jul 2013 10:54:26 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r6VAsQN4001959 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Jul 2013 10:54:26 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Wed, 31 Jul 2013 05:54:26 -0500 From: "Zafar Ali (zali)" To: "Margaria, Cyril (Coriant - DE/Munich)" , Khuzema Pithewan , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Thread-Index: Ac6NL9ROMXULLvcwR2aMbEKex7ZPbAAG5uQwAAdbOAAAAUWKEAAHaZGAAA2DHKAABMFSAAABVtHgAAKruoA= Date: Wed, 31 Jul 2013 10:54:25 +0000 Message-ID: In-Reply-To: <523C37072C291347B9730C9291CCA07D0D0F1B@DB3PRD0411MB427.eurprd04.prod.outlook.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.82.212.118] Content-Type: multipart/alternative; boundary="_000_B6585D85A128FD47857D0FD58D8120D30E9F417Bxmbrcdx14ciscoc_" MIME-Version: 1.0 Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 10:54:33 -0000 --_000_B6585D85A128FD47857D0FD58D8120D30E9F417Bxmbrcdx14ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Margaria- Resource reservation (in control plane) are always associated with a given = priority. The inquiry LSP should be signaled using the same setup and hold = priority as the currently active LSP. Changing priority of inquiry LSP to 7= (lowest) will cause incorrect blocking for the inquiry LSP (as resource ma= y be available at the priority of the LSP but may not be available at the 7= (lowest) priority. Thanks Regards =85 Zafar From: , "Cyril (Coriant - DE/Munich)" > Date: Wednesday, July 31, 2013 6:46 AM To: zali >, Khuzema Pithewan >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi, For the resource reservation aspect, this seems related to priorities, LSP = inquiry without reservation could be defined as LSP with setup, holding pri= ority 8 (or 255). This would in addition allow for reporting when the resou= rce are gone (preempted) Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Zafar Ali (zali) Sent: Wednesday, July 31, 2013 11:00 AM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Khuzema: Please see in-line. Thanks Regards =85 Zafar From: Khuzema Pithewan > Date: Wednesday, July 31, 2013 3:45 AM To: zali >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Zafar, The point I am making here is.. the 2 approaches.. Admin Status and LSP_Att= ributes, are exactly same in terms of object re-use and both of them define= s new bits for enhanced functionality. The LSP_Attribute approach has addit= ional overhead of managing a separate control LSP, which is not desirable. The inquire/ potential reopt LSP is likely not to follow path of the curren= tly active LSP. Hence this cannot be implemented by just adding some Admin = Status bit on the current LSP. One need to signal a separate LSP. Thanks Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Wednesday, July 31, 2013 2:17 AM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Khuzema: For signaling inquiry LSP with resource locking, we are using the Pre-Plann= ed LSP flag as-is as defined in RFC6001. Given this, we are defining a new = flag when inquiry LSP needs to be signal without resource locking. Thanks Regards =85 Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 5:45 PM To: zali >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Well.. not really. You are defining new bits for LSP_ATTRIBUTES for resource locking=85 aren= =92t you? Instead of doing that, you can define bits in ADMIN_STATUS and save new LSP= life cycle management, which would be quite cumbersome. Regards Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Tuesday, July 30, 2013 10:08 PM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Khuzema: The point is to reuse what already exists. The Pre-Planned LSP flag in the = Attribute Flags TLV of LSP_ATTRIBUTES object is already defined in [RFC5420= ] and is a glove fit. Thanks Regards =85 Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 1:40 PM To: Khuzema Pithewan = >, "ccamp@ietf.org" > Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Another point I spoke about in the meeting .. Why can=92t we extend Admin Status object to signal resource locking, check= ing for re-optimization. Since this operation is typically done in maintena= nce window by Admin, it may make sense to use Admin Status Object. Moreover= , we have lots of bits available/undefined in Admin Status object. This will save network element to manage life of additional LSP and control= plane failure related issues attached to the additional LSP. Khuzema --_000_B6585D85A128FD47857D0FD58D8120D30E9F417Bxmbrcdx14ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: <48D56E988A54C24CA6CDA8DFF3D6DE0A@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hi Margaria- 

Resource reservation (in control plane) are always associated with a g= iven priority. The inquiry LSP should be signaled using the same setup and = hold priority as the currently active LSP. Changing priority of inquiry LSP= to 7 (lowest) will cause incorrect blocking for the inquiry LSP (as resource may be available at the priority= of the LSP but may not be available at the 7 (lowest) priority. 

Thanks

Regards =85 Zafar

From: <Margaria>, "Cyril= (Coriant - DE/Munich)" <cyril.margaria@coriant.com>
Date: Wednesday, July 31, 2013 6:46= AM
To: zali <zali@cisco.com>, Khuzema Pithewan <kpithewan@infinera.com>, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccam= p-lsp-inquiry-00

Hi, =

 

For the resource reser= vation aspect, this seems related to priorities, LSP inquiry without reserv= ation could be defined as LSP with setup, holding priority 8 (or 255). This= would in addition allow for reporting when the resource are gone (preempted)

 

Mit freundlichen Gr= =FC=DFen / Best Regards
Cyril Margaria<= /o:p>

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: Wednesday, July 31, 2013 11:00 AM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Khuz= ema: 

&n= bsp;

Please = see in-line. 

&n= bsp;

Thanks<= o:p>

&n= bsp;

Regards= =85 Zafar

&n= bsp;

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Wednesday, July 31, 2013 3:45 AM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

&n= bsp;

Hi Zafar,

 

The point I am making = here is.. the 2 approaches.. Admin Status and LSP_Attributes, are exactly s= ame in terms of object re-use and both of them defines new bits for enhance= d functionality. The LSP_Attribute approach has additional overhead of managing a separate control LSP, which is not d= esirable.

 

 

The inquire/ potential reopt LSP is likely not to fol= low path of the currently active LSP. Hence this cannot be implemented by j= ust adding some Admin Status bit on the current LSP. One need to signal a separate LSP. 

 

Thanks

Khuzema

 

From: Zafar Ali (zali) [mailto:zali@ci= sco.com]
Sent: Wednesday, July 31, 2013 2:17 AM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 =

Hi Khuzema:

 

For signaling inquiry LSP wi= th resource locking, we are using the Pre-Planned LSP flag as-is as de= fined in RFC6001. Given this, we are defining a new flag when inquiry LSP needs to be signal without resource locking. &= nbsp;

 

Thanks

 

Regards =85 Zafar

 <= /span>

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Tuesday, July 30, 2013 5:45 PM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 <= /span>

Well.. not really.

 

You are defining new b= its for LSP_ATTRIBUTES for resource locking=85 aren=92t you?

 

Instead of doing that,= you can define bits in ADMIN_STATUS and save new LSP life cycle management= , which would be quite cumbersome.<= /o:p>

 

Regards

Khuzema

 

From: Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Tuesday, July 30, 2013 10:08 PM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 =

Khuzema= :

 <= /span>

The poi= nt is to reuse what already exists. The Pre-Planned LSP flag in the At= tribute Flags TLV of LSP_ATTRIBUTES object is already defined in [RFC5420] = and is a glove fit. 

 <= /span>

Thanks<= /span>

 <= /span>

Regards= =85 Zafar

 <= /span>

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Tuesday, July 30, 2013 1:40 PM
To: Khuzema Pithewan <k= pithewan@infinera.com>, "ccam= p@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 <= /span>

Another point I spoke = about in the meeting ..

 

Why can=92t we extend = Admin Status object to signal resource locking, checking for re-optimizatio= n. Since this operation is typically done in maintenance window by Admin, i= t may make sense to use Admin Status Object. Moreover, we have lots of bits available/undefined in Admin Status object.=

 

This will save network= element to manage life of additional LSP and control plane failure related= issues attached to the additional LSP.<= o:p>

 

Khuzema

 

--_000_B6585D85A128FD47857D0FD58D8120D30E9F417Bxmbrcdx14ciscoc_-- From zali@cisco.com Wed Jul 31 03:58:10 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99CE011E8172 for ; Wed, 31 Jul 2013 03:58:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A7dBRSxoXuoj for ; Wed, 31 Jul 2013 03:57:52 -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 09F3D21F967C for ; Wed, 31 Jul 2013 03:57:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6273; q=dns/txt; s=iport; t=1375268271; x=1376477871; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=8zs+oO14UdQ7H9qM8T+CwkGicQIYc7VMq8vVGiYLIVw=; b=iKMVhu67oZ/skGwSNecRvMsqkibn/S73Vh/MR66LKoJminP/LRY12wh6 v1yZnGzZDMJFc90bkSZiEXvnwR8Rln+Z3j2Op+EKklt1Pe183x2tnhTse p2p6JvV6aqYVDKUCUrrKME6yygPNmnlgVdaQLT/WiqKgOJujWR3NmFf8N g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAFrs+FGtJXG+/2dsb2JhbABbgkJENVC+HIEYFnSCJAEBAQQtXgEIDgMDAQILHTkUCQgBAQQBEgiICLhyj1YgGIMYcwOpLIMUgWokHA X-IronPort-AV: E=Sophos;i="4.89,786,1367971200"; d="scan'208,217";a="241790818" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-4.cisco.com with ESMTP; 31 Jul 2013 10:57:50 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r6VAvoe0012694 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Jul 2013 10:57:50 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.213]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Wed, 31 Jul 2013 05:57:50 -0500 From: "Zafar Ali (zali)" To: Khuzema Pithewan , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-rsvp-te-include-route-04 Thread-Index: Ac6NMx+p2RAMz7T3QPeg+VDERTEEPAAsg+UA Date: Wed, 31 Jul 2013 10:57:49 +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.2.3.120616 x-originating-ip: [10.82.212.118] Content-Type: multipart/alternative; boundary="_000_B6585D85A128FD47857D0FD58D8120D30E9F41ACxmbrcdx14ciscoc_" MIME-Version: 1.0 Subject: Re: [CCAMP] draft-ali-ccamp-rsvp-te-include-route-04 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 10:58:10 -0000 --_000_B6585D85A128FD47857D0FD58D8120D30E9F41ACxmbrcdx14ciscoc_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Khuzema- Please see in-line. Thanks Regards =85 Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 10:43 AM To: "ccamp@ietf.org" > Subject: [CCAMP] draft-ali-ccamp-rsvp-te-include-route-04 Authors, For LSP sub-objects, there needs to be validations that ensures that the 2 = loose abstract nodes hops (or 1 loose abstract node followed by with 1 stri= ct hop) before and after the LSP sub-object has to exactly match with that = of LSP being referenced by the sub-object, otherwise, the section of the pa= th from the reference LSP may not be valid for the LSP being setup. Please note that the use case for the include route is to allow two LSPs to= follow the same route. Hence, the loose hop expansion code and destination= of the loose hop for LSP being signaled needs be along the route of the re= ference LSP. Having said that, best-effort flag allow for some diversion on= the two paths (if ALL inclusion in not feasible). Regards Khuzema --_000_B6585D85A128FD47857D0FD58D8120D30E9F41ACxmbrcdx14ciscoc_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Khuzema- 

Please see in-line. 

Thanks

Regards =85 Zafar

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Tuesday, July 30, 2013 10:43 = AM
To: "ccamp@ietf.org" <cca= mp@ietf.org>
Subject: [CCAMP] draft-ali-ccamp-rs= vp-te-include-route-04

Authors,

 

For LSP sub-objects, there needs to be validations t= hat ensures that the 2 loose abstract nodes hops (or 1 loose abstract node = followed by with 1 strict hop) before and after the LSP sub-object has to e= xactly match with that of LSP being referenced by the sub-object, otherwise, the section of the path from the = reference LSP may not be valid for the LSP being setup.

 


Please note that the use case for the include route is to allow two LS= Ps to follow the same route. Hence, the loose hop expansion code and destin= ation of the loose hop for LSP being signaled needs be along the route of t= he reference LSP. Having said that, best-effort flag allow for some diversion on the two paths (if ALL inclusi= on in not feasible). 

Regards

Khuzema

 --_000_B6585D85A128FD47857D0FD58D8120D30E9F41ACxmbrcdx14ciscoc_-- From cyril.margaria@coriant.com Wed Jul 31 04:24:16 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5742D11E8170 for ; Wed, 31 Jul 2013 04:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.136 X-Spam-Level: X-Spam-Status: No, score=-0.136 tagged_above=-999 required=5 tests=[AWL=-0.670, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 VUta7APBwMOt for ; Wed, 31 Jul 2013 04:24:04 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0253.outbound.messaging.microsoft.com [213.199.154.253]) by ietfa.amsl.com (Postfix) with ESMTP id 256CF11E8176 for ; Wed, 31 Jul 2013 04:24:02 -0700 (PDT) Received: from mail101-db9-R.bigfish.com (10.174.16.247) by DB9EHSOBE029.bigfish.com (10.174.14.92) with Microsoft SMTP Server id 14.1.225.22; Wed, 31 Jul 2013 11:24:01 +0000 Received: from mail101-db9 (localhost [127.0.0.1]) by mail101-db9-R.bigfish.com (Postfix) with ESMTP id 819D92A01BC; Wed, 31 Jul 2013 11:24:01 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.53; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0411HT002.eurprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: PS-22(zz9371Ic89bhc85dh31c5Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1d7338h1de098h1033IL17326ah18c673h1c8fb4h1de096h8275bh8275dh1de097hz2fh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail101-db9: domain of coriant.com designates 157.56.253.53 as permitted sender) client-ip=157.56.253.53; envelope-from=cyril.margaria@coriant.com; helo=DB3PRD0411HT002.eurprd04.prod.outlook.com ; .outlook.com ; Received: from mail101-db9 (localhost.localdomain [127.0.0.1]) by mail101-db9 (MessageSwitch) id 1375269839652062_22297; Wed, 31 Jul 2013 11:23:59 +0000 (UTC) Received: from DB9EHSMHS016.bigfish.com (unknown [10.174.16.240]) by mail101-db9.bigfish.com (Postfix) with ESMTP id 857B734004A; Wed, 31 Jul 2013 11:23:59 +0000 (UTC) Received: from DB3PRD0411HT002.eurprd04.prod.outlook.com (157.56.253.53) by DB9EHSMHS016.bigfish.com (10.174.14.26) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 31 Jul 2013 11:23:58 +0000 Received: from DB3PRD0411MB427.eurprd04.prod.outlook.com ([169.254.6.251]) by DB3PRD0411HT002.eurprd04.prod.outlook.com ([10.255.73.37]) with mapi id 14.16.0341.000; Wed, 31 Jul 2013 11:23:58 +0000 From: "Margaria, Cyril (Coriant - DE/Munich)" To: "Zafar Ali (zali)" , Khuzema Pithewan , "CCAMP (ccamp@ietf.org)" Thread-Topic: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Thread-Index: Ac6NL9ROMXULLvcwR2aMbEKex7ZPbAAG5uQwAAdbOAAAAUWKEAAHaZGAAA2DHKAABMFSAAABVtHgAAKruoAAAb6xQA== Date: Wed, 31 Jul 2013 11:23:57 +0000 Message-ID: <523C37072C291347B9730C9291CCA07D0D0FDC@DB3PRD0411MB427.eurprd04.prod.outlook.com> References: <523C37072C291347B9730C9291CCA07D0D0F1B@DB3PRD0411MB427.eurprd04.prod.outlook.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.21.250] Content-Type: multipart/alternative; boundary="_000_523C37072C291347B9730C9291CCA07D0D0FDCDB3PRD0411MB427eu_" MIME-Version: 1.0 X-FOPE-CRA-Verdict: 157.56.253.53$infinera.com%0%1%coriant.com%False%False%0$ X-OriginatorOrg: coriant.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%0$Dn%INFINERA.COM$RO%1$TLS%0$FQDN%$TlsDn% Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 11:24:16 -0000 --_000_523C37072C291347B9730C9291CCA07D0D0FDCDB3PRD0411MB427eu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, The LSP inquiry without resource locking (at a given priority then) mechani= sm is present not reserve the resource for other LSPs (of same or higher pr= iority) or preempt lower priority. Could this be achieved by setting the LSP with a lower holding priority, si= gnal is as pre-planned AND indicate that this should not preempt other LSPs= . When this is instantiated a new LSP (or the same ) can be signaled with SE = and explicit ERO with the changed flag. Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Wednesday, July 31, 2013 12:54 PM To: Margaria, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP (ccamp@i= etf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Margaria- Resource reservation (in control plane) are always associated with a given = priority. The inquiry LSP should be signaled using the same setup and hold = priority as the currently active LSP. Changing priority of inquiry LSP to 7= (lowest) will cause incorrect blocking for the inquiry LSP (as resource ma= y be available at the priority of the LSP but may not be available at the 7= (lowest) priority. Thanks Regards ... Zafar From: , "Cyril (Coriant - DE/Munich)" > Date: Wednesday, July 31, 2013 6:46 AM To: zali >, Khuzema Pithewan >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi, For the resource reservation aspect, this seems related to priorities, LSP = inquiry without reservation could be defined as LSP with setup, holding pri= ority 8 (or 255). This would in addition allow for reporting when the resou= rce are gone (preempted) Mit freundlichen Gr=FC=DFen / Best Regards Cyril Margaria From: ccamp-bounces@ietf.org [mailto:ccamp-b= ounces@ietf.org] On Behalf Of Zafar Ali (zali) Sent: Wednesday, July 31, 2013 11:00 AM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Khuzema: Please see in-line. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Wednesday, July 31, 2013 3:45 AM To: zali >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Zafar, The point I am making here is.. the 2 approaches.. Admin Status and LSP_Att= ributes, are exactly same in terms of object re-use and both of them define= s new bits for enhanced functionality. The LSP_Attribute approach has addit= ional overhead of managing a separate control LSP, which is not desirable. The inquire/ potential reopt LSP is likely not to follow path of the curren= tly active LSP. Hence this cannot be implemented by just adding some Admin = Status bit on the current LSP. One need to signal a separate LSP. Thanks Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Wednesday, July 31, 2013 2:17 AM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Hi Khuzema: For signaling inquiry LSP with resource locking, we are using the Pre-Plann= ed LSP flag as-is as defined in RFC6001. Given this, we are defining a new = flag when inquiry LSP needs to be signal without resource locking. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 5:45 PM To: zali >, "ccamp@ietf.org" > Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Well.. not really. You are defining new bits for LSP_ATTRIBUTES for resource locking... aren't= you? Instead of doing that, you can define bits in ADMIN_STATUS and save new LSP= life cycle management, which would be quite cumbersome. Regards Khuzema From: Zafar Ali (zali) [mailto:zali@cisco.com] Sent: Tuesday, July 30, 2013 10:08 PM To: Khuzema Pithewan; CCAMP (ccamp@ietf.org) Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Khuzema: The point is to reuse what already exists. The Pre-Planned LSP flag in the = Attribute Flags TLV of LSP_ATTRIBUTES object is already defined in [RFC5420= ] and is a glove fit. Thanks Regards ... Zafar From: Khuzema Pithewan > Date: Tuesday, July 30, 2013 1:40 PM To: Khuzema Pithewan = >, "ccamp@ietf.org" > Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00 Another point I spoke about in the meeting .. Why can't we extend Admin Status object to signal resource locking, checkin= g for re-optimization. Since this operation is typically done in maintenanc= e window by Admin, it may make sense to use Admin Status Object. Moreover, = we have lots of bits available/undefined in Admin Status object. This will save network element to manage life of additional LSP and control= plane failure related issues attached to the additional LSP. Khuzema --_000_523C37072C291347B9730C9291CCA07D0D0FDCDB3PRD0411MB427eu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi, =

 

 

The LSP inquiry withou= t resource locking (at a given priority then) mechanism is present not rese= rve the resource for other LSPs (of same or higher priority) or preempt low= er priority.

 

Could this be achieved= by setting the LSP with a lower holding priority, signal is as pre-planned= AND indicate that this should not preempt other LSPs.

When this is instantia= ted a new LSP (or the same ) can be signaled with SE and explicit ERO with = the changed flag.

 

 

Mit freundlic= hen Gr=FC=DFen / Best Regards
Cyril Margaria

From: Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Wednesday, July 31, 2013 12:54 PM
To: Margaria, Cyril (Coriant - DE/Munich); Khuzema Pithewan; CCAMP (= ccamp@ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Marg= aria- 

&n= bsp;

Resourc= e reservation (in control plane) are always associated with a given priorit= y. The inquiry LSP should be signaled using the same setup and hold priorit= y as the currently active LSP. Changing priority of inquiry LSP to 7 (lowest) will cause incorrect blocking for th= e inquiry LSP (as resource may be available at the priority of the LSP but = may not be available at the 7 (lowest) priority. 

&n= bsp;

Thanks<= o:p>

&n= bsp;

Regards= … Zafar

&n= bsp;

From: <Margaria>, "Cyril (Coriant - DE/Munich)= " <cyril.margaria@cor= iant.com>
Date: Wednesday, July 31, 2013 6:46 AM
To: zali <zali@cisco.com>= ;, Khuzema Pithewan <kpithewan= @infinera.com>, "ccamp@ietf.o= rg" <ccamp@ietf.org> Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

&n= bsp;

Hi,

 

For the resource reser= vation aspect, this seems related to priorities, LSP inquiry without reserv= ation could be defined as LSP with setup, holding priority 8 (or 255). This= would in addition allow for reporting when the resource are gone (preempted) =

 

Mit freundlic= hen Gr=FC=DFen / Best Regards
Cyril Margaria

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Zafar Ali (zali)
Sent: Wednesday, July 31, 2013 11:00 AM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 =

Hi Khuz= ema: 

 <= /span>

Please = see in-line. 

 <= /span>

Thanks<= /span>

 <= /span>

Regards= … Zafar

 <= /span>

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Wednesday, July 31, 2013 3:45 AM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 <= /span>

Hi Zafar,

 

The point I am making = here is.. the 2 approaches.. Admin Status and LSP_Attributes, are exactly s= ame in terms of object re-use and both of them defines new bits for enhance= d functionality. The LSP_Attribute approach has additional overhead of managing a separate control LSP, which is not d= esirable.

 

 <= /span>

The inquire/ potential reopt LSP is likely not to fol= low path of the currently active LSP. Hence this cannot be implemented by j= ust adding some Admin Status bit on the current LSP. One need to signal a separate LSP. 

 <= /span>

Thanks

Khuzema

 

From: Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Wednesday, July 31, 2013 2:17 AM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 =

Hi Khuz= ema:

 

For signalin= g inquiry LSP with resource locking, we are using the Pre-Planned LSP flag&= nbsp;as-is as defined in RFC6001. Given this, we are defining a new flag when inquiry LSP needs to be signal without resource locking. &nb= sp;

 

Thanks

 

Regards R= 30; Zafar

 <= /span>

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Tuesday, July 30, 2013 5:45 PM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 <= /span>

Well.. not really.

 

You are defining new b= its for LSP_ATTRIBUTES for resource locking… aren’t you?=

 

Instead of doing that,= you can define bits in ADMIN_STATUS and save new LSP life cycle management= , which would be quite cumbersome.<= /o:p>

 

Regards

Khuzema

 

From: Zafar Ali (zali) [mailto:= zali@cisco.com]
Sent: Tuesday, July 30, 2013 10:08 PM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 =

Khuzema= :

 <= /span>

The poi= nt is to reuse what already exists. The Pre-Planned LSP flag in the At= tribute Flags TLV of LSP_ATTRIBUTES object is already defined in [RFC5420] = and is a glove fit. 

 <= /span>

Thanks<= /span>

 <= /span>

Regards= … Zafar

 <= /span>

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Tuesday, July 30, 2013 1:40 PM
To: Khuzema Pithewan <k= pithewan@infinera.com>, "ccam= p@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 <= /span>

Another point I spoke = about in the meeting ..

 

Why can’t we ext= end Admin Status object to signal resource locking, checking for re-optimiz= ation. Since this operation is typically done in maintenance window by Admi= n, it may make sense to use Admin Status Object. Moreover, we have lots of bits available/undefined in Admin Status object.=

 

This will save network= element to manage life of additional LSP and control plane failure related= issues attached to the additional LSP.<= o:p>

 

Khuzema

 

--_000_523C37072C291347B9730C9291CCA07D0D0FDCDB3PRD0411MB427eu_-- From zhangfatai@huawei.com Wed Jul 31 04:29:37 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE7E121E80E2 for ; Wed, 31 Jul 2013 04:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[AWL=-2.149, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RidEmLdSSInB for ; Wed, 31 Jul 2013 04:29:31 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CC7E021F9ED1 for ; Wed, 31 Jul 2013 04:29:29 -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 AVP29538; Wed, 31 Jul 2013 11:29:27 +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, 31 Jul 2013 12:29:16 +0100 Received: from SZXEML421-HUB.china.huawei.com (10.82.67.160) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 31 Jul 2013 12:29:26 +0100 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.72]) by szxeml421-hub.china.huawei.com ([10.82.67.160]) with mapi id 14.01.0323.007; Wed, 31 Jul 2013 19:29:18 +0800 From: Fatai Zhang To: "Zafar Ali (zali)" , Khuzema Pithewan , "CCAMP (ccamp@ietf.org)" Thread-Topic: =?gb2312?B?tPC4tDogW0NDQU1QXSBkcmFmdC1hbGktY2NhbXAtbHNwLWlucXVpcnktMDA=?= Thread-Index: Ac6NL9ROMXULLvcwR2aMbEKex7ZPbAAG5uQwAAdbOAAAAUWKEAAHaZGAAA2DHKAABMFSAAABID8gAAGheQAAABx6MA== Date: Wed, 31 Jul 2013 11:29:17 +0000 Message-ID: References: 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.47.156.188] Content-Type: multipart/alternative; boundary="_000_F82A4B6D50F9464B8EBA55651F541CF84EE43F1DSZXEML552MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [CCAMP] =?gb2312?b?tPC4tDogtPC4tDogIGRyYWZ0LWFsaS1jY2FtcC1sc3At?= =?gb2312?b?aW5xdWlyeS0wMA==?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 11:29:37 -0000 --_000_F82A4B6D50F9464B8EBA55651F541CF84EE43F1DSZXEML552MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgWmFmYXIsDQoNCkkgd291bGQgbGlrZSB0byBzZWUgbXVjaCAgY2xlYXJlciByZXF1aXJlbWVu dHMgb2YgeW91ciBkcmFmdHMsIGUuZywgaWYgeW91IHdhbnQgdGhlIFVOQy1DIHRvIHByb2JlIHRo ZSBmZWFzaWJpbGl0eSBvZiBhIHBhdGggKGUuZywgZm9yIG9wdGltaXphdGlvbiBwdXJwb3NlKSwg SSB3b3VsZCBzYXkgdGhpcyBpcyBub3QgdGhlIGJ1c2luZXNzIG9mIHRoZSBVTkktQywgdGhpcyB3 aWxsIGJlIGRvbmUgZS5nLCBiYXNlZCBvbiB0aGUgcG9saWN5IG9mIHRoZSBvcGVyYXRvciBmcm9t IHRoZSBVTkktTiBkb21haW5zIChhbmQgdGhlbiB0aGVyZSBhcmUgbG90cyBvZiBleGlzdGluZyBt ZWFzdXJlbWVudHMgdG8gYWNoaWV2ZSB0aGUgb2JqZWN0aXZlcykuDQoNCg0KVGhhbmtzDQoNCkZh dGFpDQoNCg0Kt6K8/sjLOiBaYWZhciBBbGkgKHphbGkpIFttYWlsdG86emFsaUBjaXNjby5jb21d DQq3osvNyrG85DogMjAxM8TqN9TCMzHI1SAxODoxOQ0KytW8/sjLOiBGYXRhaSBaaGFuZzsgS2h1 emVtYSBQaXRoZXdhbjsgQ0NBTVAgKGNjYW1wQGlldGYub3JnKQ0K1vfM4jogUmU6ILTwuLQ6IFtD Q0FNUF0gZHJhZnQtYWxpLWNjYW1wLWxzcC1pbnF1aXJ5LTAwDQoNCkZhdGFpOg0KDQpTZXJ2aWNl IHByb3ZpZGVyIG1heSBOT1QgdXNlIFBDRSBpbiBhbGwgZGVwbG95bWVudHMsIGUuZy4sIGFzIGl0 IGlzIHRoZSBjYXNlIG9mIG1vc3QsIGlmIG5vdCBhbGwsIG9mIHRoZSBjdXJyZW50IGRlcGxveW1l bnRzLiBJIHdvdWxkIGFsc28gYXJndWUgdGhhdCBQQ0UgaXMgbm90IGJlIGJlc3QgcGxhY2UgZm9y IHRoZSBpbnF1aXJ5IHR5cGUgcHJvY2VkdXJlIGFzIHNjb3BlIG9mIFBDRSBpcyBwYXRoIGNvbXB1 dGF0aW9uLiBQYXRoIGlucXVpcnkgaXMgbm90IGFib3V0IHBhdGggY29tcHV0YXRpb24gYnV0IGFi b3V0IHByb2JpbmcgZmVhc2liaWxpdHkgb2YgYSBwYXRoLg0KDQpUaGFua3MNCg0KUmVnYXJkcyCh rSBaYWZhcg0KDQpGcm9tOiBGYXRhaSBaaGFuZyA8emhhbmdmYXRhaUBodWF3ZWkuY29tPG1haWx0 bzp6aGFuZ2ZhdGFpQGh1YXdlaS5jb20+Pg0KRGF0ZTogV2VkbmVzZGF5LCBKdWx5IDMxLCAyMDEz IDU6MzIgQU0NClRvOiB6YWxpIDx6YWxpQGNpc2NvLmNvbTxtYWlsdG86emFsaUBjaXNjby5jb20+ PiwgS2h1emVtYSBQaXRoZXdhbiA8a3BpdGhld2FuQGluZmluZXJhLmNvbTxtYWlsdG86a3BpdGhl d2FuQGluZmluZXJhLmNvbT4+LCAiY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3Jn PiIgPGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4+DQpTdWJqZWN0OiC08Li0 OiBbQ0NBTVBdIGRyYWZ0LWFsaS1jY2FtcC1sc3AtaW5xdWlyeS0wMA0KDQpIaSBaYWZhciwNCg0K UGxlYXNlIGhhdmUgYSAgbG9vayBhdCBkcmFmdC16aGFuZy1jY2FtcC1nbXBscy11bmktYXBwPGh0 dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC16aGFuZy1jY2FtcC1nbXBscy11bmktYXBwLTA0 LnR4dD4sIHdoaWNoIGhhcyBhIHZlcnkgZ29vZCBzb2x1dGlvbiB0byBhZGRyZXNzIHRoZSByZXF1 aXJlbWVudHMgaW4geW91ciB0aGlzICBkcmFmdCAoYW5kIHNvbWUgb3RoZXIgcmVxdWlyZW1lbnRz IGluIHlvdXIgb3RoZXIgZHJhZnRzKS4NCg0KSSBkb26hr3QgdGhpbmsgaXQgaXMgYSBnb29kIGlk ZWEgdG8gb3ZlcmxvYWQgUlNWUC1URSBieSBpbnRyb2R1Y2luZyBwYXRoIGNvbXB1dGF0aW9uIGZ1 bmN0aW9ucyAob3IgUENFUCBvYmplY3RzIGxpa2UgT0YgeW91IGRlc2NyaWJlZCBpbiBhbm90aGVy IGRyYWZ0KS4NCg0KVGhhbmtzDQoNCkZhdGFpDQoNCg0KDQq3orz+yMs6IGNjYW1wLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86Y2NhbXAtYm91 bmNlc0BpZXRmLm9yZ10gtPqx7SBaYWZhciBBbGkgKHphbGkpDQq3osvNyrG85DogMjAxM8TqN9TC MzHI1SAxNzowMA0KytW8/sjLOiBLaHV6ZW1hIFBpdGhld2FuOyBDQ0FNUCAoY2NhbXBAaWV0Zi5v cmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPikNCtb3zOI6IFJlOiBbQ0NBTVBdIGRyYWZ0LWFsaS1j Y2FtcC1sc3AtaW5xdWlyeS0wMA0KDQpIaSBLaHV6ZW1hOg0KDQpQbGVhc2Ugc2VlIGluLWxpbmUu DQoNClRoYW5rcw0KDQpSZWdhcmRzIKGtIFphZmFyDQoNCkZyb206IEtodXplbWEgUGl0aGV3YW4g PGtwaXRoZXdhbkBpbmZpbmVyYS5jb208bWFpbHRvOmtwaXRoZXdhbkBpbmZpbmVyYS5jb20+Pg0K RGF0ZTogV2VkbmVzZGF5LCBKdWx5IDMxLCAyMDEzIDM6NDUgQU0NClRvOiB6YWxpIDx6YWxpQGNp c2NvLmNvbTxtYWlsdG86emFsaUBjaXNjby5jb20+PiwgImNjYW1wQGlldGYub3JnPG1haWx0bzpj Y2FtcEBpZXRmLm9yZz4iIDxjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+Pg0K U3ViamVjdDogUkU6IFtDQ0FNUF0gZHJhZnQtYWxpLWNjYW1wLWxzcC1pbnF1aXJ5LTAwDQoNCkhp IFphZmFyLA0KDQpUaGUgcG9pbnQgSSBhbSBtYWtpbmcgaGVyZSBpcy4uIHRoZSAyIGFwcHJvYWNo ZXMuLiBBZG1pbiBTdGF0dXMgYW5kIExTUF9BdHRyaWJ1dGVzLCBhcmUgZXhhY3RseSBzYW1lIGlu IHRlcm1zIG9mIG9iamVjdCByZS11c2UgYW5kIGJvdGggb2YgdGhlbSBkZWZpbmVzIG5ldyBiaXRz IGZvciBlbmhhbmNlZCBmdW5jdGlvbmFsaXR5LiBUaGUgTFNQX0F0dHJpYnV0ZSBhcHByb2FjaCBo YXMgYWRkaXRpb25hbCBvdmVyaGVhZCBvZiBtYW5hZ2luZyBhIHNlcGFyYXRlIGNvbnRyb2wgTFNQ LCB3aGljaCBpcyBub3QgZGVzaXJhYmxlLg0KDQoNClRoZSBpbnF1aXJlLyBwb3RlbnRpYWwgcmVv cHQgTFNQIGlzIGxpa2VseSBub3QgdG8gZm9sbG93IHBhdGggb2YgdGhlIGN1cnJlbnRseSBhY3Rp dmUgTFNQLiBIZW5jZSB0aGlzIGNhbm5vdCBiZSBpbXBsZW1lbnRlZCBieSBqdXN0IGFkZGluZyBz b21lIEFkbWluIFN0YXR1cyBiaXQgb24gdGhlIGN1cnJlbnQgTFNQLiBPbmUgbmVlZCB0byBzaWdu YWwgYSBzZXBhcmF0ZSBMU1AuDQoNClRoYW5rcw0KS2h1emVtYQ0KDQpGcm9tOiBaYWZhciBBbGkg KHphbGkpIFttYWlsdG86emFsaUBjaXNjby5jb21dDQpTZW50OiBXZWRuZXNkYXksIEp1bHkgMzEs IDIwMTMgMjoxNyBBTQ0KVG86IEtodXplbWEgUGl0aGV3YW47IENDQU1QIChjY2FtcEBpZXRmLm9y ZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+KQ0KU3ViamVjdDogUmU6IFtDQ0FNUF0gZHJhZnQtYWxp LWNjYW1wLWxzcC1pbnF1aXJ5LTAwDQoNCkhpIEtodXplbWE6DQoNCkZvciBzaWduYWxpbmcgaW5x dWlyeSBMU1Agd2l0aCByZXNvdXJjZSBsb2NraW5nLCB3ZSBhcmUgdXNpbmcgdGhlIFByZS1QbGFu bmVkIExTUCBmbGFnIGFzLWlzIGFzIGRlZmluZWQgaW4gUkZDNjAwMS4gR2l2ZW4gdGhpcywgd2Ug YXJlIGRlZmluaW5nIGEgbmV3IGZsYWcgd2hlbiBpbnF1aXJ5IExTUCBuZWVkcyB0byBiZSBzaWdu YWwgd2l0aG91dCByZXNvdXJjZSBsb2NraW5nLg0KDQpUaGFua3MNCg0KUmVnYXJkcyChrSBaYWZh cg0KDQpGcm9tOiBLaHV6ZW1hIFBpdGhld2FuIDxrcGl0aGV3YW5AaW5maW5lcmEuY29tPG1haWx0 bzprcGl0aGV3YW5AaW5maW5lcmEuY29tPj4NCkRhdGU6IFR1ZXNkYXksIEp1bHkgMzAsIDIwMTMg NTo0NSBQTQ0KVG86IHphbGkgPHphbGlAY2lzY28uY29tPG1haWx0bzp6YWxpQGNpc2NvLmNvbT4+ LCAiY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPiIgPGNjYW1wQGlldGYub3Jn PG1haWx0bzpjY2FtcEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogW0NDQU1QXSBkcmFmdC1hbGkt Y2NhbXAtbHNwLWlucXVpcnktMDANCg0KV2VsbC4uIG5vdCByZWFsbHkuDQoNCllvdSBhcmUgZGVm aW5pbmcgbmV3IGJpdHMgZm9yIExTUF9BVFRSSUJVVEVTIGZvciByZXNvdXJjZSBsb2NraW5noa0g YXJlbqGvdCB5b3U/DQoNCkluc3RlYWQgb2YgZG9pbmcgdGhhdCwgeW91IGNhbiBkZWZpbmUgYml0 cyBpbiBBRE1JTl9TVEFUVVMgYW5kIHNhdmUgbmV3IExTUCBsaWZlIGN5Y2xlIG1hbmFnZW1lbnQs IHdoaWNoIHdvdWxkIGJlIHF1aXRlIGN1bWJlcnNvbWUuDQoNClJlZ2FyZHMNCktodXplbWENCg0K RnJvbTogWmFmYXIgQWxpICh6YWxpKSBbbWFpbHRvOnphbGlAY2lzY28uY29tXQ0KU2VudDogVHVl c2RheSwgSnVseSAzMCwgMjAxMyAxMDowOCBQTQ0KVG86IEtodXplbWEgUGl0aGV3YW47IENDQU1Q IChjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+KQ0KU3ViamVjdDogUmU6IFtD Q0FNUF0gZHJhZnQtYWxpLWNjYW1wLWxzcC1pbnF1aXJ5LTAwDQoNCktodXplbWE6DQoNClRoZSBw b2ludCBpcyB0byByZXVzZSB3aGF0IGFscmVhZHkgZXhpc3RzLiBUaGUgUHJlLVBsYW5uZWQgTFNQ IGZsYWcgaW4gdGhlIEF0dHJpYnV0ZSBGbGFncyBUTFYgb2YgTFNQX0FUVFJJQlVURVMgb2JqZWN0 IGlzIGFscmVhZHkgZGVmaW5lZCBpbiBbUkZDNTQyMF0gYW5kIGlzIGEgZ2xvdmUgZml0Lg0KDQpU aGFua3MNCg0KUmVnYXJkcyChrSBaYWZhcg0KDQpGcm9tOiBLaHV6ZW1hIFBpdGhld2FuIDxrcGl0 aGV3YW5AaW5maW5lcmEuY29tPG1haWx0bzprcGl0aGV3YW5AaW5maW5lcmEuY29tPj4NCkRhdGU6 IFR1ZXNkYXksIEp1bHkgMzAsIDIwMTMgMTo0MCBQTQ0KVG86IEtodXplbWEgUGl0aGV3YW4gPGtw aXRoZXdhbkBpbmZpbmVyYS5jb208bWFpbHRvOmtwaXRoZXdhbkBpbmZpbmVyYS5jb20+PiwgImNj YW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4iIDxjY2FtcEBpZXRmLm9yZzxtYWls dG86Y2NhbXBAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtDQ0FNUF0gZHJhZnQtYWxpLWNjYW1w LWxzcC1pbnF1aXJ5LTAwDQoNCkFub3RoZXIgcG9pbnQgSSBzcG9rZSBhYm91dCBpbiB0aGUgbWVl dGluZyAuLg0KDQpXaHkgY2Fuoa90IHdlIGV4dGVuZCBBZG1pbiBTdGF0dXMgb2JqZWN0IHRvIHNp Z25hbCByZXNvdXJjZSBsb2NraW5nLCBjaGVja2luZyBmb3IgcmUtb3B0aW1pemF0aW9uLiBTaW5j ZSB0aGlzIG9wZXJhdGlvbiBpcyB0eXBpY2FsbHkgZG9uZSBpbiBtYWludGVuYW5jZSB3aW5kb3cg YnkgQWRtaW4sIGl0IG1heSBtYWtlIHNlbnNlIHRvIHVzZSBBZG1pbiBTdGF0dXMgT2JqZWN0LiBN b3Jlb3Zlciwgd2UgaGF2ZSBsb3RzIG9mIGJpdHMgYXZhaWxhYmxlL3VuZGVmaW5lZCBpbiBBZG1p biBTdGF0dXMgb2JqZWN0Lg0KDQpUaGlzIHdpbGwgc2F2ZSBuZXR3b3JrIGVsZW1lbnQgdG8gbWFu YWdlIGxpZmUgb2YgYWRkaXRpb25hbCBMU1AgYW5kIGNvbnRyb2wgcGxhbmUgZmFpbHVyZSByZWxh dGVkIGlzc3VlcyBhdHRhY2hlZCB0byB0aGUgYWRkaXRpb25hbCBMU1AuDQoNCktodXplbWENCg0K --_000_F82A4B6D50F9464B8EBA55651F541CF84EE43F1DSZXEML552MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Zafar,

 

I would like to see much  clearer requirements of your draft= s, e.g, if you want the UNC-C to probe the feasibility of a path (e.g, for = optimization purpose), I would say this is not the business of the UNI-C, this will be done e.g, based on the policy = of the operator from the UNI-N domains (and then there are lots of existing= measurements to achieve the objectives).

 

 

Thanks

 

Fatai

 

 

=B7=A2=BC=FE=C8=CB: Zafar Ali (zali) [mailto:zali@cisco.com]
=B7=A2= =CB=CD=CA=B1=BC=E4: 2013=C4=EA7=D4=C231=C8=D5 18:19
=CA=D5=BC=FE=C8=CB: Fatai Zhang; Khuzema Pithewan; CCAMP (ccamp@ietf.org)
=D6=F7=CC=E2: Re: =B4=F0=B8=B4: [CCAMP] draft-ali-ccamp-lsp= -inquiry-00

 

Fatai: 

 

Service provider may NOT use PCE in all deployments, e.g., as it is= the case of most, if not all, of the current deployments. I would also arg= ue that PCE is not be best place for the inquiry type procedure as scope of PCE is path computation. Path inquiry i= s not about path computation but about probing feasibility of a path. =

 

Thanks

 

Regards =A1=AD Zafar

 

From: = Fatai Zhang <zhangfatai@huawei.com>
Date: Wednesday, July 31, 2013 5:32 AM
To: zali <zali@cisco.com>= ;, Khuzema Pithewan <kpithewan= @infinera.com>, "ccamp@ietf.o= rg" <ccamp@ietf.org> Subject: =B4=F0=B8=B4: [CCAMP] dr= aft-ali-ccamp-lsp-inquiry-00

 

Hi Zafar,<= /o:p>

 

Please have a  look at draft-zhang-ccamp-gmpls-uni-app, whic= h has a very good solution to address the requirements in your this  draft (and some other requirements in your other drafts).<= /span>

 

I don=A1=AFt think it is a good idea to overload RSVP-TE by intro= ducing path computation functions (or PCEP objects like OF you described in= another draft).

 

Thanks

 

Fatai

 

 

 

=B7=A2=BC=FE=C8=CB: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] =B4=FA=B1=ED Zafar Ali (zali)
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA7=D4=C231= =C8=D5 17:00
=CA=D5=BC=FE=C8=CB: Khuzema Pithewan; CCAMP (ccamp@ie= tf.org)
=D6=F7=CC=E2: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Khuzema: =

 =

Please see in-line. 

 =

Thanks=

 =

Regards =A1=AD Zafar

 =

From: = Khuzema Pithewan <= kpithewan@infinera.com> Date: Wednesday, July 31, 2013 3:45 AM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 =

Hi Zafa= r,

 <= /span>

The poi= nt I am making here is.. the 2 approaches.. Admin Status and LSP_Attributes= , are exactly same in terms of object re-use and both of them defines new b= its for enhanced functionality. The LSP_Attribute approach has additional overhead of managing a separate control LSP, which= is not desirable.

 <= /span>

 

The inquire/ potential reopt LSP is li= kely not to follow path of the currently active LSP. Hence this cannot be i= mplemented by just adding some Admin Status bit on the current LSP. One need to signal a separate LSP. 

 

Thanks<= /span>

Khuzema=

 <= /span>

From: = Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Wednesday, July 31, 2013 2:17 AM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Hi Khuzema:<= /o:p>

 

For signaling inquiry LSP with resource locking, we are using the Pre-Pl= anned LSP flag as-is as defined in RFC6001. Given this, we are defining a new flag when inquiry LSP needs to be signal without resource l= ocking.  =

 

Thanks

 

Regards =A1=AD Zafar

 

From: Khuzema Pithewan <= kpithewan@infinera.com> Date: Tuesday, July 30, 2013 5:45 PM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Well.. = not really.

 <= /span>

You are= defining new bits for LSP_ATTRIBUTES for resource locking=A1=AD aren=A1=AF= t you?<= /p>

 <= /span>

Instead= of doing that, you can define bits in ADMIN_STATUS and save new LSP life c= ycle management, which would be quite cumbersome.

 <= /span>

Regards=

Khuzema=

 <= /span>

From: Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Tuesday, July 30, 2013 10:08 PM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Khuzema:

 =

The point is to reuse what already exists. The Pre-Planned LSP= flag in the Attribute Flags TLV of LSP_ATTRIBUTES object is already define= d in [RFC5420] and is a glove fit. 

 =

Thanks=

 =

Regards =A1=AD Zafar

 =

From: = Khuzema Pithewan <= kpithewan@infinera.com> Date: Tuesday, July 30, 2013 1:40 PM
To: Khuzema Pithewan <k= pithewan@infinera.com>, "ccam= p@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 =

Another= point I spoke about in the meeting ..

 <= /span>

Why can= =A1=AFt we extend Admin Status object to signal resource locking, checking = for re-optimization. Since this operation is typically done in maintenance = window by Admin, it may make sense to use Admin Status Object. Moreover, we have lots of bits available/undefined in Admin= Status object.

 <= /span>

This wi= ll save network element to manage life of additional LSP and control plane = failure related issues attached to the additional LSP.

 <= /span>

Khuzema=

 <= /span>

--_000_F82A4B6D50F9464B8EBA55651F541CF84EE43F1DSZXEML552MBXchi_-- From adrian@olddog.co.uk Wed Jul 31 05:06:39 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A37B011E8178 for ; Wed, 31 Jul 2013 05:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 Sa4r8dm1NEFc for ; Wed, 31 Jul 2013 05:06:26 -0700 (PDT) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) by ietfa.amsl.com (Postfix) with ESMTP id 6294A21F9CA8 for ; Wed, 31 Jul 2013 05:06:26 -0700 (PDT) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6VC6Jt4032268 for ; Wed, 31 Jul 2013 13:06:19 +0100 Received: from 950129200 (dhcp-13f0.meeting.ietf.org [130.129.19.240]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6VC6IDI032257 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 31 Jul 2013 13:06:18 +0100 From: "Adrian Farrel" To: "'CCAMP'" Date: Wed, 31 Jul 2013 13:06:16 +0100 Message-ID: <04b201ce8de6$5cf3f750$16dbe5f0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6N5kLyDCZhe/nvSXe0BNULW06lNA== Content-Language: en-gb Subject: [CCAMP] The draft I mentioned on TE in interconnected domains X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 12:06:39 -0000 Hi, Here is the document I mentioned at the mic just now. All comments are welcome. I am not sure it is a CCAMP I-D per se, and I don't think it is complete! draft-farrel-interconnected-te-info-exchange Cheers, Adrian From cyril.margaria@coriant.com Wed Jul 31 05:09:47 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6217C11E818D for ; Wed, 31 Jul 2013 05:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.479 X-Spam-Level: X-Spam-Status: No, score=-1.479 tagged_above=-999 required=5 tests=[AWL=1.120, 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 ulsP+-7V+FZU for ; Wed, 31 Jul 2013 05:09:41 -0700 (PDT) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0189.outbound.messaging.microsoft.com [213.199.154.189]) by ietfa.amsl.com (Postfix) with ESMTP id AD0B811E8187 for ; Wed, 31 Jul 2013 05:09:22 -0700 (PDT) Received: from mail36-db8-R.bigfish.com (10.174.8.232) by DB8EHSOBE032.bigfish.com (10.174.4.95) with Microsoft SMTP Server id 14.1.225.22; Wed, 31 Jul 2013 12:09:21 +0000 Received: from mail36-db8 (localhost [127.0.0.1]) by mail36-db8-R.bigfish.com (Postfix) with ESMTP id 966FE140146; Wed, 31 Jul 2013 12:09:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.53; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0411HT005.eurprd04.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: PS-1(zzc89bh31c5Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h17326ah1de096h1954cbh8275bh1de097hz2fh2a8h668h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d07h1d0ch1d2eh1d3fh1dc1h1de9h1dfeh1dffh1e1dh1155h) Received-SPF: pass (mail36-db8: domain of coriant.com designates 157.56.253.53 as permitted sender) client-ip=157.56.253.53; envelope-from=cyril.margaria@coriant.com; helo=DB3PRD0411HT005.eurprd04.prod.outlook.com ; .outlook.com ; Received: from mail36-db8 (localhost.localdomain [127.0.0.1]) by mail36-db8 (MessageSwitch) id 1375272558847943_5553; Wed, 31 Jul 2013 12:09:18 +0000 (UTC) Received: from DB8EHSMHS008.bigfish.com (unknown [10.174.8.239]) by mail36-db8.bigfish.com (Postfix) with ESMTP id C09A2100047; Wed, 31 Jul 2013 12:09:18 +0000 (UTC) Received: from DB3PRD0411HT005.eurprd04.prod.outlook.com (157.56.253.53) by DB8EHSMHS008.bigfish.com (10.174.4.18) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 31 Jul 2013 12:09:15 +0000 Received: from DB3PRD0411MB427.eurprd04.prod.outlook.com ([169.254.6.251]) by DB3PRD0411HT005.eurprd04.prod.outlook.com ([10.255.73.40]) with mapi id 14.16.0341.000; Wed, 31 Jul 2013 12:09:15 +0000 From: "Margaria, Cyril (Coriant - DE/Munich)" To: "CCAMP (ccamp@ietf.org)" , "draft-zhang-ccamp-flexible-grid-ospf-ext@tools.ietf.org" Thread-Topic: Comments on draft-zhang-ccamp-flexible-grid-ospf-ext-02 Thread-Index: Ac6N5sMy5IwJulNTQ8y2wU7nkrfHnA== Date: Wed, 31 Jul 2013 12:09:14 +0000 Message-ID: <523C37072C291347B9730C9291CCA07D0D10DC@DB3PRD0411MB427.eurprd04.prod.outlook.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.129.21.250] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: coriant.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [CCAMP] Comments on draft-zhang-ccamp-flexible-grid-ospf-ext-02 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 12:09:47 -0000 Hi,=20 I have the following comments for draft-zhang-ccamp-flexible-grid-ospf-ext= -02: 1) section 3.1: last paragraph : the section to reference is 5.8 I believe 2) section 3.1: The requirement to flood non-overlapping available frequenc= y ranges do not appear in the framework, and in my opinion is an unnecessar= y requirement limiting the information advertized, especially considering b= undling. 3) section 4.1 : draft-ietf-ccamp-wson-signal-compatibility-ospf-11 defines= the LV for WSON, from the framework this is another ISCD, so the mapping s= hould be defined and the number of TLVs to be present should also be define= d and recommendation presented 4) section 4.1.3 : the relation with the m of the base label is missing. 5) section 4.2: min width and max width could be flooded as 2 available lab= el TLVs, can't those attributes be deduced from the available labels? This = would allow nodes not to support the connectivity matrix, only the label pa= rt. 6) a new OSPF switching capability should be defined, similar to section 6 = of draft-ietf-ccamp-wson-signal-compatibility-ospf-11 7) There is no consideration on bundling in the document, I think this is m= issing. 8) The document is considering only the flexible grid granularity, for Flex= igrid-compatible old nodes (with fixed grid), this seems not addressed. The= re is a comparison to fixed grid description, but they are not considered i= n the context of Flexigrid switching. Adding the grid type would be useful= , and may allow to consider n,m in step of 0.5 (for now) and maybe allow ot= her grid (yet keeping the different switching introduced by Flexigrid). Overall the Flexigrid specific aspects could be covered better, especially = considering the fixed grid. Best Regards/ Mit freundlichen Gr=FC=DFen Cyril Margaria SW Architect ON RD SW Net2 2 DE St.-Martin-Str. 76 81541 M=FCnchen Tel: +49 89 5159 16934 Mob: +49 176 24036175 Fax: +49 89 5159 44 16934 cyril.margaria@coriant.com http://www.coriant.com Coriant R&D GmbH Gesch=E4ftsleitung / Board of Directors: Robert Richter, Rolf Nauerz=20 Sitz der Gesellschaft: M=FCnchen / Registered office: Munich Registergericht: M=FCnchen / Commercial registry: Munich, HRB 197143 From adrian@olddog.co.uk Wed Jul 31 05:22:08 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0818821F9E5E for ; Wed, 31 Jul 2013 05:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.482 X-Spam-Level: X-Spam-Status: No, score=-2.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7f9SJkJONAWc for ; Wed, 31 Jul 2013 05:21:52 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 788E821F9C60 for ; Wed, 31 Jul 2013 05:21:51 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6VCLnwj016707 for ; Wed, 31 Jul 2013 13:21:50 +0100 Received: from 950129200 (dhcp-13f0.meeting.ietf.org [130.129.19.240]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6VCLmTX016695 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 31 Jul 2013 13:21:49 +0100 From: "Adrian Farrel" To: "'CCAMP'" Date: Wed, 31 Jul 2013 13:21:48 +0100 Message-ID: <04be01ce8de8$87b888f0$97299ad0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac6N6Es5HncY8RoHR62GeZsKgN6ppQ== Content-Language: en-gb Subject: [CCAMP] draft-ali-ccamp-gmpls-uni-error-notification X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 12:22:11 -0000 Sorry for my continued senior moments. My question wrt this draft was "Doesn't RFC 4783 give you everything you need?" Adrian From adrian@olddog.co.uk Wed Jul 31 05:39:13 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40B3511E817E for ; Wed, 31 Jul 2013 05:39:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.49 X-Spam-Level: X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[AWL=0.109, 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 Coke5D46SH52 for ; Wed, 31 Jul 2013 05:39:08 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id ADC9C21F9D4C for ; Wed, 31 Jul 2013 05:37:14 -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 r6VCbBpK005207; Wed, 31 Jul 2013 13:37:12 +0100 Received: from 950129200 (dhcp-13f0.meeting.ietf.org [130.129.19.240]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id r6VCbAGU005180 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 31 Jul 2013 13:37:11 +0100 From: "Adrian Farrel" To: "'Daniele Ceccarelli'" , References: <031c01ce8b87$45b79cb0$d126d610$@olddog.co.uk> <4A1562797D64E44993C5CBF38CF1BE48126BF3@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48126BF3@ESESSMB301.ericsson.se> Date: Wed, 31 Jul 2013 13:37:09 +0100 Message-ID: <04d201ce8dea$ad29bb20$077d3160$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIXx93VA/UdhQko2wImjUTLAiqMbQK/MUvxmNZLDeA= Content-Language: en-gb Cc: ccamp@ietf.org Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 12:39:13 -0000 Thanks, I'll try to get to this in short order. I think this document should be batched with the framework (so it will be held until I can advance both together). I think that the signaling and routing I-Ds are gated on this document and the framework. Cheers, Adrian > -----Original Message----- > From: Daniele Ceccarelli [mailto:daniele.ceccarelli@ericsson.com] > Sent: 31 July 2013 11:29 > To: adrian@olddog.co.uk; draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org > Cc: ccamp@ietf.org > Subject: RE: [CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model > > Adrian, > > Thanks for your review and suggestions. > The document has been updated and inline below you can find comments on the > modifications made. > > Thanks > The authors > > > -----Original Message----- > > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf > > Of Adrian Farrel > > Sent: domenica 28 luglio 2013 13:41 > > To: draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org > > Cc: ccamp@ietf.org > > Subject: [CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model > > > > Hi, > > > > I have done my normal AD review of your document after receiving the > > Publication Request. As usual, the purpose of the review is to catch issues > > and nits as early as possible so that they don't get in the way during IETF last > > call and IESG evaluation. > > > > The review below includes a few nits and raises a couple of questions. > > All of the issues are open for discussion, and I am quite prepared to hear back > > that the WG considered things and reached consensus. > > > > For the moment, I have marked the I-D as "Revised I-D Needed". > > > > Thanks for the work, > > > > Adrian > > > > === > > > > As I asked in my email to the CCAMP list, I find it odd that this document makes > > no reference to RFC 5307 and the use of IS-IS as a routing protocol in GMPLS > > control of OTN. > > > > At the end of the intro we added the following sentence: > " As far as it concerns routing, analogous considerations apply to IS-IS > [RFC5307] but in the following only a gap analysis with respect to OSPF-TE is > provided." > > > --- > > > > Section 1 says: > > > > Specific routing and signaling extensions are defined in [OTN-OSPF] > > and [OTN-RSVP]. > > > > I think you might extend this text to note that those two documents and the > > extensions they define, specifically address the gaps identified in this > > document. > > > > OK. The following text has been added: > "Specific routing and > signaling extensions defined in [OTN-OSPF] and [OTN-RSVP] specifically > address the gaps identified in this document." > > > --- > > > > I found it hard to see the clear gap analysis in section 9. I think what it says is > > generic and not specific to OTN - i.e., there is a need to distinguish switching > > capabilities from adaptation/termination capabilities. > > > > Am I missing something? Why does OTN have this issue? Should this be > > handled as a technology-independent issue? > > > Added the following text at the end of section 9: > > "The issue shown above is analyzed in an OTN context but it is a general > technology independent GMPLS limitation." > > > --- > > > > Section 10 has > > > > The IETF foresees that up to eight priorities must be supported and > > that all of them have to be advertised independently on the number of > > priorities supported by the implementation. Considering that the > > advertisement of all the different supported signal types will > > originate large LSAs, it is advised to advertise only the information > > related to the really supported priorities. > > > > The language here is a bit odd to me. > > ... *foresees* that *up*to* eight priorities *must* be supported ... ? > > > > How about... > > > > [RFC4202] defines 8 priorities for resource availability and usage. > > > > [RFC4202] defines 8 priorities for resource availability and usage. > All of them have to be advertised independently on the number of > priorities > supported by the implementation. Considering that the advertisement of > all the different supported signal types will originate large LSAs, it is > advised to advertise only the information related to the really supported > priorities. > > > > > --- > > > > Section 11 > > > > Modifications to ISCD/IACD, if needed, have to be addressed in the > > related encoding documents. > > > > I think this document needs to state whether those modifications are needed. > > > > Sentence dropped and added this one at the end of the section: > "What said above implies augmenting both the ISCD and the IACD." > > > --- > > > > Section 12 > > > > The ODUk label format defined in [RFC4328] could be updated to > > support new signal types defined in [G.709-2012] but would hardly be > > further enhanced to support possible new signal types. > > > > What does "hardly" mean in this text? So you mean "it would be difficult"? If > > so.... > > > > The ODUk label format defined in [RFC4328] could be updated to > > support new signal types defined in [G.709-2012] but it would be > > difficult to further enhanced it to support possible new signal > > types. > > > > ok > > > --- > > > > Section 12 > > > > Furthermore such label format may have scalability issues due to the > > high number of labels needed when signaling large LSPs. For example, > > when an ODU3 is mapped into an ODU4 with 1.25Gbps tributary slots, it > > would require the utilization of thirty-one labels (31*4*8=992 bits) > > to be allocated while an ODUflex into an ODU4 may need up to eighty > > labels (80*4*8=2560 bits). > > > > The maths is flawless. Does the WG believe that this scenario is likely? Or is it > > just a theoretical possibility? > > > > I ask because I am cautious about us engineering for fringe cases. > > Multiplexing an ODU3 or an ODUflex into an ODU4 is a pretty common scenario. > 100Gbps lambdas are being widely deployed and OTN is used to groom traffic. > > > > > > --- > > > > I think a number of your Informative references are actually used as > > Normative. I would list > > > > [RFC3471], [RFC3473], [RFC4202], [RFC4203], [RFC4328], and [RFC5339]. > > OK > > > > > _______________________________________________ > > CCAMP mailing list > > CCAMP@ietf.org > > https://www.ietf.org/mailman/listinfo/ccamp From zhangfatai@huawei.com Wed Jul 31 06:51:59 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6D821F9CCA for ; Wed, 31 Jul 2013 06:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.186 X-Spam-Level: * X-Spam-Status: No, score=1.186 tagged_above=-999 required=5 tests=[AWL=-1.602, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snxmrDxTH0KJ for ; Wed, 31 Jul 2013 06:51:55 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 90D0321F9EA7 for ; Wed, 31 Jul 2013 06:51:54 -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 AVP41337; Wed, 31 Jul 2013 13:51:48 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 31 Jul 2013 14:51:24 +0100 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 31 Jul 2013 14:51:35 +0100 Received: from SZXEML552-MBX.china.huawei.com ([169.254.1.72]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.007; Wed, 31 Jul 2013 21:50:52 +0800 From: Fatai Zhang To: "adrian@olddog.co.uk" , "'Daniele Ceccarelli'" , "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" Thread-Topic: [CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model Thread-Index: Ac6LhtnSfQOotGSxTSGTJyWDc179HQCSrD6A//+sJoD//2aK8A== Date: Wed, 31 Jul 2013 13:50:52 +0000 Message-ID: References: <031c01ce8b87$45b79cb0$d126d610$@olddog.co.uk> <4A1562797D64E44993C5CBF38CF1BE48126BF3@ESESSMB301.ericsson.se> <04d201ce8dea$ad29bb20$077d3160$@olddog.co.uk> In-Reply-To: <04d201ce8dea$ad29bb20$077d3160$@olddog.co.uk> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.128.105] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "ccamp@ietf.org" Subject: [CCAMP] =?gb2312?b?tPC4tDogIEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWNj?= =?gb2312?b?YW1wLW90bi1nNzA5LWluZm8tbW9kZWw=?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 13:51:59 -0000 SGkgQWRyaWFuLA0KDQpJIHdpbGwgdXBkYXRlIEZXSyBkcmFmdCBhZnRlciBJRVRGIG1lZXRpbmcu DQoNCkhvcGUgeW91IGJlIHBhdGllbnQgZm9yIGEgd2hpbGUsIDotKQ0KDQpUaGFua3MNCg0KRmF0 YWkNCg0KDQoNCi0tLS0t08q8/tStvP4tLS0tLQ0Kt6K8/sjLOiBBZHJpYW4gRmFycmVsIFttYWls dG86YWRyaWFuQG9sZGRvZy5jby51a10gDQq3osvNyrG85DogMjAxM8TqN9TCMzHI1SAyMDozNw0K ytW8/sjLOiAnRGFuaWVsZSBDZWNjYXJlbGxpJzsgZHJhZnQtaWV0Zi1jY2FtcC1vdG4tZzcwOS1p bmZvLW1vZGVsQHRvb2xzLmlldGYub3JnDQqzrcvNOiBjY2FtcEBpZXRmLm9yZw0K1vfM4jogUkU6 IFtDQ0FNUF0gQUQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtY2NhbXAtb3RuLWc3MDktaW5mby1tb2Rl bA0KDQpUaGFua3MsDQoNCkknbGwgdHJ5IHRvIGdldCB0byB0aGlzIGluIHNob3J0IG9yZGVyLiAN CkkgdGhpbmsgdGhpcyBkb2N1bWVudCBzaG91bGQgYmUgYmF0Y2hlZCB3aXRoIHRoZSBmcmFtZXdv cmsgKHNvIGl0IHdpbGwgYmUgaGVsZCB1bnRpbCBJIGNhbiBhZHZhbmNlIGJvdGggdG9nZXRoZXIp Lg0KDQpJIHRoaW5rIHRoYXQgdGhlIHNpZ25hbGluZyBhbmQgcm91dGluZyBJLURzIGFyZSBnYXRl ZCBvbiB0aGlzIGRvY3VtZW50IGFuZCB0aGUgZnJhbWV3b3JrLg0KDQpDaGVlcnMsDQpBZHJpYW4N Cg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEYW5pZWxlIENlY2NhcmVs bGkgW21haWx0bzpkYW5pZWxlLmNlY2NhcmVsbGlAZXJpY3Nzb24uY29tXQ0KPiBTZW50OiAzMSBK dWx5IDIwMTMgMTE6MjkNCj4gVG86IGFkcmlhbkBvbGRkb2cuY28udWs7IA0KPiBkcmFmdC1pZXRm LWNjYW1wLW90bi1nNzA5LWluZm8tbW9kZWxAdG9vbHMuaWV0Zi5vcmcNCj4gQ2M6IGNjYW1wQGll dGYub3JnDQo+IFN1YmplY3Q6IFJFOiBbQ0NBTVBdIEFEIHJldmlldyBvZiBkcmFmdC1pZXRmLWNj YW1wLW90bi1nNzA5LWluZm8tbW9kZWwNCj4gDQo+IEFkcmlhbiwNCj4gDQo+IFRoYW5rcyBmb3Ig eW91ciByZXZpZXcgYW5kIHN1Z2dlc3Rpb25zLg0KPiBUaGUgZG9jdW1lbnQgaGFzIGJlZW4gdXBk YXRlZCBhbmQgaW5saW5lIGJlbG93IHlvdSBjYW4gZmluZCBjb21tZW50cyANCj4gb24gdGhlIG1v ZGlmaWNhdGlvbnMgbWFkZS4NCj4gDQo+IFRoYW5rcw0KPiBUaGUgYXV0aG9ycw0KPiANCj4gPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IGNjYW1wLWJvdW5jZXNAaWV0Zi5v cmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbiANCj4gPiBCZWhhbGYgT2YgQWRy aWFuIEZhcnJlbA0KPiA+IFNlbnQ6IGRvbWVuaWNhIDI4IGx1Z2xpbyAyMDEzIDEzOjQxDQo+ID4g VG86IGRyYWZ0LWlldGYtY2NhbXAtb3RuLWc3MDktaW5mby1tb2RlbEB0b29scy5pZXRmLm9yZw0K PiA+IENjOiBjY2FtcEBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFtDQ0FNUF0gQUQgcmV2aWV3IG9m IGRyYWZ0LWlldGYtY2NhbXAtb3RuLWc3MDktaW5mby1tb2RlbA0KPiA+DQo+ID4gSGksDQo+ID4N Cj4gPiBJIGhhdmUgZG9uZSBteSBub3JtYWwgQUQgcmV2aWV3IG9mIHlvdXIgZG9jdW1lbnQgYWZ0 ZXIgcmVjZWl2aW5nIHRoZSANCj4gPiBQdWJsaWNhdGlvbiBSZXF1ZXN0LiAgQXMgdXN1YWwsIHRo ZSBwdXJwb3NlIG9mIHRoZSByZXZpZXcgaXMgdG8gDQo+ID4gY2F0Y2ggaXNzdWVzIGFuZCBuaXRz IGFzIGVhcmx5IGFzIHBvc3NpYmxlIHNvIHRoYXQgdGhleSBkb24ndCBnZXQgaW4gDQo+ID4gdGhl IHdheSBkdXJpbmcgSUVURg0KbGFzdA0KPiA+IGNhbGwgYW5kIElFU0cgZXZhbHVhdGlvbi4NCj4g Pg0KPiA+IFRoZSByZXZpZXcgYmVsb3cgaW5jbHVkZXMgYSBmZXcgbml0cyBhbmQgcmFpc2VzIGEg Y291cGxlIG9mIHF1ZXN0aW9ucy4NCj4gPiBBbGwgb2YgdGhlIGlzc3VlcyBhcmUgb3BlbiBmb3Ig ZGlzY3Vzc2lvbiwgYW5kIEkgYW0gcXVpdGUgcHJlcGFyZWQgDQo+ID4gdG8gaGVhcg0KYmFjaw0K PiA+IHRoYXQgdGhlIFdHIGNvbnNpZGVyZWQgdGhpbmdzIGFuZCByZWFjaGVkIGNvbnNlbnN1cy4N Cj4gPg0KPiA+IEZvciB0aGUgbW9tZW50LCBJIGhhdmUgbWFya2VkIHRoZSBJLUQgYXMgIlJldmlz ZWQgSS1EIE5lZWRlZCIuDQo+ID4NCj4gPiBUaGFua3MgZm9yIHRoZSB3b3JrLA0KPiA+DQo+ID4g QWRyaWFuDQo+ID4NCj4gPiA9PT0NCj4gPg0KPiA+IEFzIEkgYXNrZWQgaW4gbXkgZW1haWwgdG8g dGhlIENDQU1QIGxpc3QsIEkgZmluZCBpdCBvZGQgdGhhdCB0aGlzIA0KPiA+IGRvY3VtZW50DQpt YWtlcw0KPiA+IG5vIHJlZmVyZW5jZSB0byBSRkMgNTMwNyBhbmQgdGhlIHVzZSBvZiBJUy1JUyBh cyBhIHJvdXRpbmcgcHJvdG9jb2wgDQo+ID4gaW4gR01QTFMgY29udHJvbCBvZiBPVE4uDQo+ID4N Cj4gDQo+IEF0IHRoZSBlbmQgb2YgdGhlIGludHJvIHdlIGFkZGVkIHRoZSBmb2xsb3dpbmcgc2Vu dGVuY2U6DQo+ICIgIEFzIGZhciBhcyBpdCBjb25jZXJucyByb3V0aW5nLCBhbmFsb2dvdXMgY29u c2lkZXJhdGlvbnMgYXBwbHkgdG8gSVMtSVMNCj4gICBbUkZDNTMwN10gYnV0IGluIHRoZSBmb2xs b3dpbmcgb25seSBhIGdhcCBhbmFseXNpcyB3aXRoIHJlc3BlY3QgdG8gDQo+IE9TUEYtVEUNCmlz DQo+IHByb3ZpZGVkLiINCj4gDQo+ID4gLS0tDQo+ID4NCj4gPiBTZWN0aW9uIDEgc2F5czoNCj4g Pg0KPiA+ICAgIFNwZWNpZmljIHJvdXRpbmcgYW5kIHNpZ25hbGluZyBleHRlbnNpb25zIGFyZSBk ZWZpbmVkIGluIFtPVE4tT1NQRl0NCj4gPiAgICBhbmQgW09UTi1SU1ZQXS4NCj4gPg0KPiA+IEkg dGhpbmsgeW91IG1pZ2h0IGV4dGVuZCB0aGlzIHRleHQgdG8gbm90ZSB0aGF0IHRob3NlIHR3byBk b2N1bWVudHMgDQo+ID4gYW5kIHRoZSBleHRlbnNpb25zIHRoZXkgZGVmaW5lLCBzcGVjaWZpY2Fs bHkgYWRkcmVzcyB0aGUgZ2FwcyANCj4gPiBpZGVudGlmaWVkIGluIHRoaXMgZG9jdW1lbnQuDQo+ ID4NCj4gDQo+IE9LLiBUaGUgZm9sbG93aW5nIHRleHQgaGFzIGJlZW4gYWRkZWQ6DQo+ICJTcGVj aWZpYyByb3V0aW5nIGFuZA0KPiAgIHNpZ25hbGluZyBleHRlbnNpb25zIGRlZmluZWQgaW4gW09U Ti1PU1BGXSBhbmQgW09UTi1SU1ZQXSBzcGVjaWZpY2FsbHkNCj4gICBhZGRyZXNzIHRoZSBnYXBz IGlkZW50aWZpZWQgaW4gdGhpcyBkb2N1bWVudC4iDQo+IA0KPiA+IC0tLQ0KPiA+DQo+ID4gSSBm b3VuZCBpdCBoYXJkIHRvIHNlZSB0aGUgY2xlYXIgZ2FwIGFuYWx5c2lzIGluIHNlY3Rpb24gOS4g IEkgdGhpbmsgDQo+ID4gd2hhdCBpdA0Kc2F5cyBpcw0KPiA+IGdlbmVyaWMgYW5kIG5vdCBzcGVj aWZpYyB0byBPVE4gLSBpLmUuLCB0aGVyZSBpcyBhIG5lZWQgdG8gDQo+ID4gZGlzdGluZ3Vpc2gN CnN3aXRjaGluZw0KPiA+IGNhcGFiaWxpdGllcyBmcm9tIGFkYXB0YXRpb24vdGVybWluYXRpb24g Y2FwYWJpbGl0aWVzLg0KPiA+DQo+ID4gQW0gSSBtaXNzaW5nIHNvbWV0aGluZz8gIFdoeSBkb2Vz IE9UTiBoYXZlIHRoaXMgaXNzdWU/ICBTaG91bGQgdGhpcyANCj4gPiBiZSBoYW5kbGVkIGFzIGEg dGVjaG5vbG9neS1pbmRlcGVuZGVudCBpc3N1ZT8NCj4gPg0KPiBBZGRlZCB0aGUgZm9sbG93aW5n IHRleHQgYXQgdGhlIGVuZCBvZiBzZWN0aW9uIDk6DQo+IA0KPiAiVGhlIGlzc3VlIHNob3duIGFi b3ZlIGlzIGFuYWx5emVkIGluIGFuIE9UTiBjb250ZXh0IGJ1dCBpdCBpcyBhIA0KPiBnZW5lcmFs IHRlY2hub2xvZ3kgaW5kZXBlbmRlbnQgR01QTFMgbGltaXRhdGlvbi4iDQo+IA0KPiA+IC0tLQ0K PiA+DQo+ID4gU2VjdGlvbiAxMCBoYXMNCj4gPg0KPiA+ICAgIFRoZSBJRVRGIGZvcmVzZWVzIHRo YXQgdXAgdG8gZWlnaHQgcHJpb3JpdGllcyBtdXN0IGJlIHN1cHBvcnRlZCBhbmQNCj4gPiAgICB0 aGF0IGFsbCBvZiB0aGVtIGhhdmUgdG8gYmUgYWR2ZXJ0aXNlZCBpbmRlcGVuZGVudGx5IG9uIHRo ZSBudW1iZXIgb2YNCj4gPiAgICBwcmlvcml0aWVzIHN1cHBvcnRlZCBieSB0aGUgaW1wbGVtZW50 YXRpb24uICBDb25zaWRlcmluZyB0aGF0IHRoZQ0KPiA+ICAgIGFkdmVydGlzZW1lbnQgb2YgYWxs IHRoZSBkaWZmZXJlbnQgc3VwcG9ydGVkIHNpZ25hbCB0eXBlcyB3aWxsDQo+ID4gICAgb3JpZ2lu YXRlIGxhcmdlIExTQXMsIGl0IGlzIGFkdmlzZWQgdG8gYWR2ZXJ0aXNlIG9ubHkgdGhlIGluZm9y bWF0aW9uDQo+ID4gICAgcmVsYXRlZCB0byB0aGUgcmVhbGx5IHN1cHBvcnRlZCBwcmlvcml0aWVz Lg0KPiA+DQo+ID4gVGhlIGxhbmd1YWdlIGhlcmUgaXMgYSBiaXQgb2RkIHRvIG1lLg0KPiA+IC4u LiAqZm9yZXNlZXMqIHRoYXQgKnVwKnRvKiBlaWdodCBwcmlvcml0aWVzICptdXN0KiBiZSBzdXBw b3J0ZWQgLi4uICA/DQo+ID4NCj4gPiBIb3cgYWJvdXQuLi4NCj4gPg0KPiA+IFtSRkM0MjAyXSBk ZWZpbmVzIDggcHJpb3JpdGllcyBmb3IgcmVzb3VyY2UgYXZhaWxhYmlsaXR5IGFuZCB1c2FnZS4N Cj4gPg0KPiANCj4gW1JGQzQyMDJdIGRlZmluZXMgOCBwcmlvcml0aWVzIGZvciByZXNvdXJjZSBh dmFpbGFiaWxpdHkgYW5kIHVzYWdlLg0KPiAJQWxsIG9mIHRoZW0gaGF2ZSB0byBiZSBhZHZlcnRp c2VkIGluZGVwZW5kZW50bHkgb24gdGhlIG51bWJlciBvZiANCj4gcHJpb3JpdGllcw0KPiAJc3Vw cG9ydGVkIGJ5IHRoZSBpbXBsZW1lbnRhdGlvbi4gQ29uc2lkZXJpbmcgdGhhdCB0aGUgYWR2ZXJ0 aXNlbWVudCBvZg0KPiAJYWxsIHRoZSBkaWZmZXJlbnQgc3VwcG9ydGVkIHNpZ25hbCB0eXBlcyB3 aWxsIG9yaWdpbmF0ZSBsYXJnZSBMU0FzLCANCj4gaXQNCmlzDQo+IAlhZHZpc2VkIHRvIGFkdmVy dGlzZSBvbmx5IHRoZSBpbmZvcm1hdGlvbiByZWxhdGVkIHRvIHRoZSByZWFsbHkNCnN1cHBvcnRl ZA0KPiBwcmlvcml0aWVzLg0KPiANCj4gDQo+IA0KPiA+IC0tLQ0KPiA+DQo+ID4gU2VjdGlvbiAx MQ0KPiA+DQo+ID4gICAgTW9kaWZpY2F0aW9ucyB0byBJU0NEL0lBQ0QsIGlmIG5lZWRlZCwgaGF2 ZSB0byBiZSBhZGRyZXNzZWQgaW4gdGhlDQo+ID4gICAgcmVsYXRlZCBlbmNvZGluZyBkb2N1bWVu dHMuDQo+ID4NCj4gPiBJIHRoaW5rIHRoaXMgZG9jdW1lbnQgbmVlZHMgdG8gc3RhdGUgd2hldGhl ciB0aG9zZSBtb2RpZmljYXRpb25zIGFyZSBuZWVkZWQuDQo+ID4NCj4gDQo+IFNlbnRlbmNlIGRy b3BwZWQgYW5kIGFkZGVkIHRoaXMgb25lIGF0IHRoZSBlbmQgb2YgdGhlIHNlY3Rpb246DQo+ICJX aGF0IHNhaWQgYWJvdmUgaW1wbGllcyBhdWdtZW50aW5nIGJvdGggdGhlIElTQ0QgYW5kIHRoZSBJ QUNELiINCj4gDQo+ID4gLS0tDQo+ID4NCj4gPiBTZWN0aW9uIDEyDQo+ID4NCj4gPiAgICBUaGUg T0RVayBsYWJlbCBmb3JtYXQgZGVmaW5lZCBpbiBbUkZDNDMyOF0gY291bGQgYmUgdXBkYXRlZCB0 bw0KPiA+ICAgIHN1cHBvcnQgbmV3IHNpZ25hbCB0eXBlcyBkZWZpbmVkIGluIFtHLjcwOS0yMDEy XSBidXQgd291bGQgaGFyZGx5IGJlDQo+ID4gICAgZnVydGhlciBlbmhhbmNlZCB0byBzdXBwb3J0 IHBvc3NpYmxlIG5ldyBzaWduYWwgdHlwZXMuDQo+ID4NCj4gPiBXaGF0IGRvZXMgImhhcmRseSIg bWVhbiBpbiB0aGlzIHRleHQ/ICBTbyB5b3UgbWVhbiAiaXQgd291bGQgYmUgZGlmZmljdWx0Ij8N CklmDQo+ID4gc28uLi4uDQo+ID4NCj4gPiAgICBUaGUgT0RVayBsYWJlbCBmb3JtYXQgZGVmaW5l ZCBpbiBbUkZDNDMyOF0gY291bGQgYmUgdXBkYXRlZCB0bw0KPiA+ICAgIHN1cHBvcnQgbmV3IHNp Z25hbCB0eXBlcyBkZWZpbmVkIGluIFtHLjcwOS0yMDEyXSBidXQgaXQgd291bGQgYmUNCj4gPiAg ICBkaWZmaWN1bHQgdG8gZnVydGhlciBlbmhhbmNlZCBpdCB0byBzdXBwb3J0IHBvc3NpYmxlIG5l dyBzaWduYWwNCj4gPiAgICB0eXBlcy4NCj4gPg0KPiANCj4gb2sNCj4gDQo+ID4gLS0tDQo+ID4N Cj4gPiBTZWN0aW9uIDEyDQo+ID4NCj4gPiAgICBGdXJ0aGVybW9yZSBzdWNoIGxhYmVsIGZvcm1h dCBtYXkgaGF2ZSBzY2FsYWJpbGl0eSBpc3N1ZXMgZHVlIHRvIHRoZQ0KPiA+ICAgIGhpZ2ggbnVt YmVyIG9mIGxhYmVscyBuZWVkZWQgd2hlbiBzaWduYWxpbmcgbGFyZ2UgTFNQcy4gIEZvciBleGFt cGxlLA0KPiA+ICAgIHdoZW4gYW4gT0RVMyBpcyBtYXBwZWQgaW50byBhbiBPRFU0IHdpdGggMS4y NUdicHMgdHJpYnV0YXJ5IHNsb3RzLCBpdA0KPiA+ICAgIHdvdWxkIHJlcXVpcmUgdGhlIHV0aWxp emF0aW9uIG9mIHRoaXJ0eS1vbmUgbGFiZWxzICgzMSo0Kjg9OTkyIGJpdHMpDQo+ID4gICAgdG8g YmUgYWxsb2NhdGVkIHdoaWxlIGFuIE9EVWZsZXggaW50byBhbiBPRFU0IG1heSBuZWVkIHVwIHRv IGVpZ2h0eQ0KPiA+ICAgIGxhYmVscyAoODAqNCo4PTI1NjAgYml0cykuDQo+ID4NCj4gPiBUaGUg bWF0aHMgaXMgZmxhd2xlc3MuICBEb2VzIHRoZSBXRyBiZWxpZXZlIHRoYXQgdGhpcyBzY2VuYXJp byBpcyBsaWtlbHk/DQpPciBpcyBpdA0KPiA+IGp1c3QgYSB0aGVvcmV0aWNhbCBwb3NzaWJpbGl0 eT8NCj4gPg0KPiA+IEkgYXNrIGJlY2F1c2UgSSBhbSBjYXV0aW91cyBhYm91dCB1cyBlbmdpbmVl cmluZyBmb3IgZnJpbmdlIGNhc2VzLg0KPiANCj4gTXVsdGlwbGV4aW5nIGFuIE9EVTMgb3IgYW4g T0RVZmxleCBpbnRvIGFuIE9EVTQgaXMgYSBwcmV0dHkgY29tbW9uIHNjZW5hcmlvLg0KPiAxMDBH YnBzIGxhbWJkYXMgYXJlIGJlaW5nIHdpZGVseSBkZXBsb3llZCBhbmQgT1ROIGlzIHVzZWQgdG8g Z3Jvb20gdHJhZmZpYy4NCj4gDQo+IA0KPiA+DQo+ID4gLS0tDQo+ID4NCj4gPiBJIHRoaW5rIGEg bnVtYmVyIG9mIHlvdXIgSW5mb3JtYXRpdmUgcmVmZXJlbmNlcyBhcmUgYWN0dWFsbHkgdXNlZCBh cyANCj4gPiBOb3JtYXRpdmUuICBJIHdvdWxkIGxpc3QNCj4gPg0KPiA+ICAgIFtSRkMzNDcxXSwg W1JGQzM0NzNdLCBbUkZDNDIwMl0sIFtSRkM0MjAzXSwgW1JGQzQzMjhdLCBhbmQgW1JGQzUzMzld Lg0KPiANCj4gT0sNCj4gDQo+ID4NCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+IENDQU1QIG1haWxpbmcgbGlzdA0KPiA+IENDQU1QQGlldGYu b3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KDQo= From huubatwork@gmail.com Wed Jul 31 08:07:44 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E03C21F9F6F; Wed, 31 Jul 2013 08:07:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.384 X-Spam-Level: X-Spam-Status: No, score=-2.384 tagged_above=-999 required=5 tests=[AWL=0.215, 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 YUvUgSYrXMWN; Wed, 31 Jul 2013 08:07:44 -0700 (PDT) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE3E21F9F13; Wed, 31 Jul 2013 08:07:43 -0700 (PDT) Received: by mail-pb0-f45.google.com with SMTP id mc8so880575pbc.32 for ; Wed, 31 Jul 2013 08:07:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:subject:content-type :content-transfer-encoding; bh=D9d5NFdatKiIbv/MtW7gpZqZDAL0qgmDp9rYmjwrHl0=; b=JXX+pSOlzoVsSlrJPjfOBsm9bQauALUvWUuZblADOmGWu6LHhB3C9BNkYXnjhGbd0x qbWq1ijC9vtgTK6f7QkPd9RsMWYEUBp65vzzKaDMeHJYLdHeU0vFS9ZfJbTCY3/kQKja wIlnFUgukzgSMdSldc0RqRjfZexQEf0ZQOPbEofvA+6zivdA9I5m1/m1J9Cyt7ZQNz9I m6jUh1bMi7+cm+4+5PTt+w5XfRFS0jKs15RLgrQeDdprAJoNv5UUXHvL5sQL6sbRQxok RcTE3lx/DA4WECpDAbq4K+nB/hnoQe3o1wROmskFvu0qTP3On3rSDHpIOfL3nq2rZCqG BAGw== X-Received: by 10.66.142.42 with SMTP id rt10mr62624584pab.1.1375283263194; Wed, 31 Jul 2013 08:07:43 -0700 (PDT) Received: from dhcp-175c.meeting.ietf.org (dhcp-175c.meeting.ietf.org. [130.129.23.92]) by mx.google.com with ESMTPSA id eq5sm2692762pbc.15.2013.07.31.08.07.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 31 Jul 2013 08:07:42 -0700 (PDT) Message-ID: <51F9283C.6020204@gmail.com> Date: Wed, 31 Jul 2013 17:07:40 +0200 From: Huub van Helvoort User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: CCAMP , "mpls@ietf.org" Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: [CCAMP] follow-up draft-helvoort.ccamp-fs-priority X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: huubatwork@gmail.com List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 15:07:44 -0000 All, Following up on the discussion in the ccamp WG after the presentation of draft-helvoort.ccamp-fs-priority where Lou pointed out that RFC4427 does not define the actual order of the priorities: I discussed this with the interested parties and we reached the conclusion that updates to PSC (draft-rhd-mpls-tp-psc-priority) can be made without updating RFC4427. Best regards, Huub. -- ***************************************************************** 请记住，你是独一无二的，就像其他每一个人一样 From lberger@labn.net Wed Jul 31 09:51:10 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A48F911E819A for ; Wed, 31 Jul 2013 09:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.161 X-Spam-Level: X-Spam-Status: No, score=-101.161 tagged_above=-999 required=5 tests=[AWL=-0.096, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_13=0.6, J_CHICKENPOX_44=0.6, 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 zIYv9I0zkcPV for ; Wed, 31 Jul 2013 09:51:06 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id AC2B811E819F for ; Wed, 31 Jul 2013 09:50:55 -0700 (PDT) Received: (qmail 26113 invoked by uid 0); 31 Jul 2013 16:50:34 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy9.bluehost.com with SMTP; 31 Jul 2013 16:50:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=KO06uA/EQG+nBsFaF6e2RS/t+IFPWi3+L1nqHD2rjyQ=; b=vWmIXtujj1YGwydbn2H1BT1soPcXgDEpU7v+5V7RpXa7C40S+3F2BJag5lf/MNYNKTRn95FuHL5HKm5nFfoSMBj+msnYC4I/fCksj/vjJW5KNYg7kZ4YNavopnXM8od/; Received: from box313.bluehost.com ([69.89.31.113]:51569 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V4Zbd-0002tW-Kl for ccamp@ietf.org; Wed, 31 Jul 2013 10:50:34 -0600 Message-ID: <51F9405B.5040008@labn.net> Date: Wed, 31 Jul 2013 18:50:35 +0200 From: Lou Berger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: CCAMP X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Subject: [CCAMP] rough minutes for Berlin CCAMP meetings X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 16:51:10 -0000 As before, it would be best to enter corrections on http://tools.ietf.org/wg/ccamp/minutes (send mail to list if you can't). Discussion should take place on the list and *not* in etherpad. Much thanks to our secretaries and all who contributed to the notes. Lou > CCAMP Agenda For IETF 87 > CCAMP Agenda For IETF 87 > Version: Jul 22, 2013 > > First Session > TUESDAY, July 30, 2013 > 1700-1830 Afternoon Session III > Room: Potsdam 3 > Presentation Start Time Duration Information > 0 17:00 10 Title: Administrivia & WG Status > Draft: > Presenter: Chairs Fatai Zhang: After this meeting we plan to update [draft-ietf-ccamp-otn-g709-info-model] and [draft-ietf-ccamp-gmpls-g709-framework] based on AD (Adrian Farrel) review. Comments requested on non presented WG drafts status: ‒ draft-ietf-ccamp-rsvp-te-srlg-collect Oscar Gonzalez de Dios: The document is stable. There is one functionality (knowing if a RRO suboject is incomplete or has been edited) that needs to be made generic (there was a comment from Lou during IETF 86th). A mail was sent on 4th of July with several options to make the functionality generic. A new mail to the CCAMP list will be sent this with the options. Feedback is requested from the CCAMP list. ‒ draft-ietf-ccamp-rsvp-te-li-lb: Daniele Ceccarelli: No changes from last meeting > 1 17:10 8 Title: LSP Attribute in ERO > Draft: http://tools.ietf.org/html/draft-ietf-ccamp-lsp-attribute-ro-02 > Presenter: Cyril Margaria Lou Berger: I suspect that you addressed Adrian's [Farrel) comment. I suggest you check with him via the list to confirm. > 2 17:18 8 Title: RSVP-TE Extensions for Associated Bidirectional LSPs > Draft: http://tools.ietf.org/html/draft-ietf-ccamp-mpls-tp-rsvpte-ext-associated-lsp-06 > Presenter: Matt Hartley Lou Berger: I think we can move rapidly towards Last Call. Matt Hartley: Splendid. > 3 17:26 8 Title: RSVP-TE extension for recording TE Metric of a LSP > Draft: http://tools.ietf.org/html/draft-ietf-ccamp-te-metric-recording-02 > Presenter: George Swallow Oscar Gonzalez de Dios: Regarding IANA requests Collision with IANA assignment. We need to align on temporary assignments to avoid collisions. George Swallow: Daniele Ceccarelli: How about we merge the drafts to minimized the number of drafts to read? George Swallow: We initially had this plan, but we wanted to avoid holding up the other draft. Lou Berger: Regarding IANA assignments, are you having similar issues in MPLS? (re collision of temporary assignments values). We used to have the wiki which has not been touched for a long time. George Swallow: I fully support it. Dan: We used to do that but our AD suggested to stop. Lou Berger: It's not temporary assignment it is just a way to ensure that documents do no collide and avoid implementation issues. We will discuss this with Adrian Farrel. Do we have someone who will take responsibility for the CCAMP page? Oscar Gonzalez de Dios: I volunteer. Lou Berger: We think it would be a good idea to resurrect the wiki Adrian: Different times wrt RFC4020. People wanted to implement and start interop. Now that we support early allocation which gives a codepoint for 2 years i don't think we need allocations outside IANA. What happens if we screw up that registry? George Swallow: We will caveat the request. Adrian Farrel: Why not go that extra bit further and request an early allocation. We should talk in more details chairs and ADs. Loa Andersson: Suggestion: ask the WG chairs if the draft is stable enough to start development, then request an early allocation. Adrian Farrel: I suggest that if I am uneasy with this the IESG may also have issues. We can take this discussion offline (with CCAMP and MPLS chairs). > 4 17:34 8 Title: RSVP-TE LSP Route Diversity using Exclude Routes > Draft: http://tools.ietf.org/html/draft-ietf-ccamp-lsp-diversity-02 > Presenter: George Swallow Fatai Zhang: I understand the motivation, but I have an issue with the comp0lext solution. Why not use existing solution like path-key? George Swallow: The operator may not be using PCE. We did discuss the solution early on before this document became a WG document. Deborah Brungard: Make sure you read the document and trigger discussion on the list, not wait for the meeting. > 5 17:42 6 Title: Include Routes - Extension to RSVP-TE > Draft: http://tools.ietf.org/html/draft-ali-ccamp-rsvp-te-include-route-04 > Presenter: George Swallow Khuzema Pithewan: There are elements (constraints) influencing a section or complete path of an LSP, these need to be managed. George Swallow: If you cannot meet all the existing constraints, as well as meet diverse objective, then an error will be issued. This is described in the document. Lou Berger: another XRO might be present and you need to consider it. Adrian: Suggest that you rename subobject. As there might be confusion. George Swallow: An easy change, do you have an suggestion? Lou Berger: "Inclusion"? George Swallow: "Follow the breadcrumb"? Ok, we (authors) will discuss. > 6 17:48 5 Title: RSVP-TE Extension for Label Switched Path (LSP) Inquiry > Draft: http://tools.ietf.org/html/draft-ali-ccamp-lsp-inquiry-00 > Presenter: George Swallow Lou Berger: Off course reusing existing mechanisms is good, if you manage to reuse also existing terminology its better. George Swallow: Yes. Khuzema Pithewan: This will affect existing services. George Swallow: This is signaled from the IP plane, so we assume that you are in a maintenance window. Dieter Beller: There are technologies out there that allow soft set up of resources. Are you envisaging to cover also those technologies? George Swallow: We see this being used for shared mesh protection in optical environments. Dieter Beller: I'm talking about technologies that in tens of ms are able to tear down an LSP and setup the protecting one. Xian: I don't follow the motivation for the second type of inquiry. What is its usage? Have you considered using calls? George Swallow: I'm not familiar with that particular mechanism. Lou Berger: Not sure how it would help. > 7 17:53 5 Title: RSVP-TE Extension for Signaling Objective Function and Metric Bound > Draft: http://tools.ietf.org/html/draft-ali-ccamp-rc-objective-function-metric-bound-03 > Presenter: George Swallow Lou Berger: how many people think it's a useful function (good number) How many read? (slightly less) How many think this is a good foundation? (slightly less) Cyril Margaria: Mechanisms defined in draft-ietf-ccamp-lsp-attribute-ro are meant for this kind of information Oscar Gonzalez de Dios: Not only in this draft but in others you add path computation constraints like include/exclude things. When path computation is done in the middle of the network one may want to pass all the path computation constraints in RSVP-TE. However, in the proposal, you are duplicating PCEP objects. Lou; we followed the approach that we can distribute path computation. Oscar Gonzalez de Dios: Not what I meant. I mean that if there is already a complete syntax to express path computation constraints, inclusions/exclusions, etc, why not reuse it? Lou Berger: Can you make this suggestion on the list? Fatai Zhang: not sure about the value of this draft. > 8 17:58 5 Title: RSVP-TE Signaling Extension for Bandwidth availability > Draft: http://tools.ietf.org/html/draft-long-ccamp-rsvp-te-bandwidth-availability-01 > Presenter: Min Ye Lou Berger: See the TSV WG [Tunnel Congestion I-D?], there could be overlap with your draft. Khuzema Pithewan: you might end up multiple lengths to satisfy a bandwidth request. > 9 18:03 5 Title: OSPF Routing Extension for links with variable discrete bandwidth > Draft: http://tools.ietf.org/html/draft-long-ccamp-ospf-availability-extension-00 > Presenter: Min Ye Matt Hartley: Should this be an OSPF WG draft? Lou Berger: in the past we agreed with the OSPF chairs that it is possible to make OSPF changes in CCAMP. > 10 18:08 7 Title: Domain Subobjects for Resource ReserVation Protocol – Traffic Engineering (RSVP-TE) > Draft: http://tools.ietf.org/html/draft-dhody-ccamp-rsvp-te-domain-subobjects-02 > Presenter: Dhruv Dhody Deborah Brungard: [Poll] How many think it's useful? [good number], How many have read [good number] Take to the list > 11 18:15 5 Title: A SNMP MIB to manage GMPLS with General Constraints Support > Draft: http://tools.ietf.org/html/draft-gmggm-ccamp-gencons-snmp-mib-02 > Presenter: Giovanni Martinelli Lou Berger: I think this document is timed perfectly in relation to the WSON work. Fatai Zhang: General comment. When do we need MIB drafts? Do we need it in this case? Some MIB drafts are on the CCAMP page and are not updated for years. Deborah Brungard: Some people use SNMP as management interface, some others use different management protocols Adrian: You are not required to write MIB modules. You are required to discuss how your network may be managed. > 12 18:20 5 Title: Information Model for WSONs with Impairments Validation > Draft: http://tools.ietf.org/html/draft-martinelli-ccamp-wson-iv-info-02 > Presenter: Giovanni Martinelli Dieter Beller: Considering we do not have data plane interop, and a computation capability to compute end-to-end, find this work a little early? Giovanni: What do you mean that there is no data plane compatibility? The answer from ITU-T folks was that there could be some multivendor case. Dieter From the discussion in Orlando interop is not currently capable, so is development of an information model too soon? Giovanni: The compatibility will come, we cannot make any public statement now. There are some parameters that no one cares how are computed. Dieter Beller: We are supposed to develop standard that provide interoperability Giovanni: Yes. At the control plane. Deborah Brungard: I suggest to talk with Q6 guys. Interim meeting, to help define. > 13 18:25 5 Title: Information Encoding for WSON with Impairments Validation > Draft: http://tools.ietf.org/html/draft-martinelli-ccamp-wson-iv-encode-02 > Presenter: Giovanni Martinelli No comments. > Adjourn 18:30 > > Second Session > WEDNESDAY, July 31, 2013 > 1300-1500 > Room: Potsdam 1 > Presentation Start Time Duration Information > 0 13:00 5 Title: Administrivia > Draft: > Presenter: Chairs > 14 13:05 8 Title: Framework and Requirements for GMPLS based control of Flexi-grid DWDM networks > Draft: http://tools.ietf.org/html/draft-ogrcetal-ccamp-flexi-grid-fwk-03 > Presenter: Oscar Gonzalez de Dios Deborah Brungard: we have a lot of liaisons from ITU-T. G.872 was consented? Malcolm: G.872 has been consented. Deborah Brungard: has it been sent to the CCAMP? Malcolm: I think it is worth sending a specific Liaison to Q6. Lou Berger: polling on usefulness, reading and support as foundation of WG work. Good support. Confirm on the list. > 15 13:13 8 Title: RSVP-TE Signaling Extensions in support of Flexible Grid > Draft: http://tools.ietf.org/html/draft-zhang-ccamp-flexible-grid-rsvp-te-ext-02 > Presenter: Xian Zhang Giovanni: what happens if the LSP needs to be resized? Xian: Lou Berger: The document is in an early stage of development. [Poll] How many have read? How many support? Pretty good number but less than FWK. We may poll before the next meeting, assuming adoption of the framework document. Iftekar: It seems that this document isn't as well developed. Does it make sense to adopt. Lou Berger: We can adopt early if it makes sense. remember that adoption is the start of the WG's technical work, not a statement that a documented solution is completely correct. if you feel the document is not ready or heading in the wrong direction, then you should bring any comments to the list. Iftekar: [?] Giovanni: WG can judge if the document is suitable, but it maybe early. Lou Berger: So you feel adopting the document is premature? Giovanni: Yes. > 16 13:21 8 Title: GMPLS OSPF-TE Extensions in support of Flexible Grid DWDM Networks > Draft: http://tools.ietf.org/html/draft-zhang-ccamp-flexible-grid-ospf-ext-02 > Presenter: Ramon Casellas Cyril Margaria: A bit too early to make it a wg document Lou Berger: Specific technical issues? Cyril Margaria: no Lou Berger: Okay, then please review and send specific comments to the list. Lou Berger: General comment. Please take advantage of the list to raise comments and objections, lack of discussion may be misconstrued as concurrence or disinterest. Fatai Zhang: We could adopt the framework and label drafts and then speak about signaling and routing Lou Berger: Can you make this suggestion on the list once the result of the framework adoption poll is known? > 17 13:29 7 Title: An SNMP MIB extension to RFC3591 to manage optical interface parameters of DWDM applications > Draft: http://tools.ietf.org/html/draft-galikunze-ccamp-g-698-2-snmp-mib-03 > Presenter: Gabriele Galimberti > 18 13:36 7 Title: An SNMP MIB extension to RFC3591 to manage optical interface parameters of DWDM applications > Draft: http://tools.ietf.org/html/draft-galikunze-ccamp-opt-imp-snmp-mib-00 > Presenter: Gabriele Galimberti Gert Grammel: These two drafts are covering the same content of the one we discussed in Orlando? Gabriele Galimberti: one is covering what is in the ITU-T recommendation and the other one what is not there. They are complimentary. Deborah Brungard: [Poll] How many have read the document? [Not too many] Hopefully we will see a Liaison to help us progress these documents. > 19 13:43 8 Title: Extension to the LMP for DWDM Optical Line Systems to manage optical parameters of DWDM applications > Draft: http://tools.ietf.org/html/draft-dharinigert-ccamp-g-698-2-lmp-03 > http://tools.ietf.org/html/draft-dharinigert-ccamp-opt-imp-lmp-00 > Presenter: Gert Grammel Deborah Brungard: If you not use the application codes, the set of parameters you are defining is enough to provide interoperability? Gert Grammel: If it is a standard application code then it is interoperable. If it is not a standards application code, then... Deborah Brungard: it would be good to take it to Q6 [Poll] Is draft-dharinigert-ccamp-opt-imp-lmp-00 useful, [a reasonable number]. Poll for 698.2 lmp same number. Poll for opt imp lmp same number -1 > 20 13:51 7 Title: Use cases for operating networks in the overlay model context > Draft: http://tools.ietf.org/html/draft-ceccadedios-ccamp-overlay-use-cases-01 > Presenter: Daniele Ceccarelli (single presentation for next) > 21 13:58 8 Title: Applicability of Generalized Multiprotocol Label Switching (GMPLS) User-Network Interface (UNI) > Draft: http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-uni-app-04 > Presenter: Daniele Ceccarelli Adrian Farrel: AD hat off - My name appears on applicability I-D, but not on the use cases. This is not an accident, if we go for option 1 fine, if we go for option 2 I would not support. I do not think the approach is good or even possible. This is not how we should build networks. Lou Berger: Do you believe that sharing network information between domains is not acceptable? Adrian Farrel: No, in fact I am working on a document that facilitates this. My issue is the mechanisms used to exchange information. Lou Berger: At the overlay provider, what used to be called L1VPN enhanced mode would this be acceptable? Adrian Farrel: architecture or protocol? We did discuss solutions, three options including an inter-domain routing protocol. Lou Berger: In theory you support this, but you have an issue with one of the solutions. Adrian Farrel: Lou Berger: Layer you communicate at Vs. ... Adrian Farrel: My view as a WG participant is that we need to step back and discuss the architecture, then solution work. Oscar; When I began this work I wanted to discuss the use cases and describe the architecture, rather than develop solutions. Lou Berger: so maybe we should step back and review the architecture. Actually we have other documents that discuss the work. Julien Meuric: [slide UNI/ONI Use case] this feels like transport recovery mechanisms being pushed into the packet layer. Daniele Ceccarelli: The intention was to demonstrate how it is possible mix the advantages of the two layers Deborah Brungard: I suggest we break up the examples and post to the list and request feedback. Lou Berger: Happy to hear the authors are looking at taking a step back and revisiting their drafts. When doing this please look at other individual drafts that may have related text and work with those other authors. Also consider the differences between UNI and ENNI, which operate in a single layer, and the concepts of L1VPN basic and enhanced mode which can be leveraged for cross client/server layers -- which is perhaps what's intended by ONI. > 22 14:06 5 Title: Extensions to RSVP-TE for Error Notication in GMPLS User-Network Interface (UNI) > Draft: http://tools.ietf.org/html/draft-ali-ccamp-gmpls-uni-error-notification-00 > Presenter: Matt Hartley Igor Bryskin: What happens if the notification is not received? The edge node will not find out. Igor Bryskin: most of that solutions don't work. What you need is some reliable mechanism to do it. Matt Hartley: It'll work the way RSVP-TE always works. Igor Bryskin: you should think about a reliable notify delivery Lou Berger: This is a general issue with RSVP and beyond the scope of this single document Matt Hartley: Cyril Margaria: This mechanisms seems to apply to UNI, we need a general mechanism. Lou Berger: This leads to a question that I had, why is the general address mapping/hiding mechanism defined RFC4208 insufficient? Matt Hartley: will have to look at that Adrian: The question I sent on the mailing list is that what you want to define is already there in RFC4783 Matt Hartley: If you can send this comment to the list I can review and comment. Deborah Brungard: Are you looking at segment protection in the core? Lou Berger: what you are looking for is a single error value? (Matt Hartley: Yes) It seems it's going to be a short draft. > 23 14:11 8 Title: UNI Extensions for Diversity and Latency Support > Draft: http://tools.ietf.org/html/draft-fedyk-ccamp-uni-extensions-02 > Presenter: Dieter Beller Lou Berger: [slide - relationships with prior work] Do you think that your document is related to Daniele's [draft-ceccadedios-ccamp-overlay-use-cases and ] presentation? Dieter Beller: Yes. Lou Berger: I suggest you take advantage of the time this week and see how these documents fit together. And then update the documents/WG accordingly. > 24 14:19 8 Title: Mutually Exclusive Link Group (MELG) > Draft: http://tools.ietf.org/html/draft-beeram-ccamp-melg-01 > Presenter: Vishnu Pavan Beeram Lou Berger: [slide - 4] A clarification question, is this a virtual TE link, or an actual TE link? Vishnu Pavan Beeram: a virtual TE link Lou Berger: Based on existing work (RFCs), there is no distinction between virtual TE link and an actual TE link in the client topology. This is a significant change. Vishnu Pavan Beeram: We can make a note of this in the document. George Swallow: At what point would you advertise mutual exclusivity, do you wait until it is setup? If this is the direction, how many do you advertise, why not include this in the draft. Igor Bryskin: we did consider this and we think to expand the concept of SRLG. [Will poke Igor to provide his comments.] Deborah Brungard: [poll] how many think this is interesting? not to many, try to raise interest. > 25 14:27 8 Title: OSPF-TE extensions for MLNMRN based on OTN > Draft: http://tools.ietf.org/html/draft-rao-ccamp-mlnmrn-otn-ospfte-ext-02 > Presenter: Khuzema Pithewan Lou Berger: Do you require anything from signaling? Khuzema Pithewan: yes, maybe yes. Fatai Zhang: > 26 14:35 8 Title: GMPLS-based Hierarchy LSP Creation in Multi-Region and Multi-Layer Networks > Draft: http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-h-lsp-mln-05 > Presenter: Xian Zhang Lou Berger: Do you need anything from routing to make the signaling work? Cyril Margaria: You don't know where you originate Lou Berger: I do not understand, can you discuss with the previous authors and see if anything needs to be aligned. Cyril Margaria: no we don't need igp extensions. Khuzema Pithewan: If you are in a single domain you definitely need routing extensions Lou Berger: Please review RFC6107 as some of these mechanisms may already be described. > 27 14:43 5 Title: RSVP-TE Extensions For Signaling GMPLS Restoration LSP > Draft: http://tools.ietf.org/html/draft-gandhi-ccamp-gmpls-restoration-lsp-01 > Presenter: Gabriele Galimberti Igor Bryskin: why are you requesting feedbacks if 2 years ago we presented a similar draft and there was no interest? Lou Berger: Cyril are you willing to work on a BCP with the authors, I think we agree that mechanisms exist but we need to document how they might be used. We do not have time to discuss, so let’s take this offline. > 28 14:48 7 Title: Update Forced Switch Priority > Draft: http://tools.ietf.org/html/draft-helvoort-ccamp-fs-priority-00 > Presenter: Huub van Helvoort Lou Berger: You mentioned on the list that this draft was in response to a message that I sent. The message stated that a combined change was needed to 4427 and 6372, but this draft only covers 4427. Also I was mistaken in my statement WRT 4427, as it doesn't state relative priorities. That is stated only in 6372. There are other discussions on this topic going on, and this draft should be taken forward in a manner consistent with those discussions. > 29 14:55 5 Title: RSVP-TE Extensions for Bit Error Rate (BER) Measurement > Draft: http://tools.ietf.org/html/draft-zhang-ccamp-rsvpte-ber-measure-00 > Presenter: Zhenbin Li > Adjourn 15:00 From mhartley@cisco.com Wed Jul 31 10:05:40 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45A7A11E8167 for ; Wed, 31 Jul 2013 10:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_GB2312=1.345] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kZuy-r5sckJ0 for ; Wed, 31 Jul 2013 10:05:34 -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 C149721F9F8F for ; Wed, 31 Jul 2013 10:05:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37133; q=dns/txt; s=iport; t=1375290334; x=1376499934; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=wI3oCNLhqz0YQBG2Dg3/i5ChXjIGXEBUXXF1+iEWrSU=; b=W2Vw2DuRhENlT4+LaLWzW+hvExbJxvlP9lodZEwXHJIrUs7RQnXIUo4U YotJ6ssWTTMk6z16bJWY8+ewTTbdWSasO62M3PWyPO1Ux6ARasVtAuJSf BQSMBdSykQAiAmPfTJptUw1b0qv+l3MhzWZUdOhd6glrmuywBf3CRRkGO E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai8FAIVD+VGtJV2d/2dsb2JhbABbgkJENVCDELJSiD8XgQIWdIIkAQEBBC1MEAIBBgIRAwEBAQsWAQYFAgIwFAYDCAIEAQ0FCBECh3UMjAibQAiRS49WFgoRBgGCYTdzA5kIkCSDFIIq X-IronPort-AV: E=Sophos;i="4.89,788,1367971200"; d="scan'208,217";a="241864436" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 31 Jul 2013 17:05:33 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r6VH5XaE007532 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 31 Jul 2013 17:05:33 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.202]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Wed, 31 Jul 2013 12:05:32 -0500 From: "Matt Hartley (mhartley)" To: Fatai Zhang , "Zafar Ali (zali)" , Khuzema Pithewan , "CCAMP (ccamp@ietf.org)" Thread-Topic: =?gb2312?B?W0NDQU1QXSC08Li0OiC08Li0OiAgZHJhZnQtYWxpLWNjYW1wLWxzcC1pbnF1?= =?gb2312?Q?iry-00?= Thread-Index: AQHOjeFCpw0OE+evg0GwwUbNPtHgBpl/AzEg Date: Wed, 31 Jul 2013 17:05:31 +0000 Message-ID: <9D50FCE7413E3D4EA5E42331115FB5BC105872C8@xmb-rcd-x03.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.216.107] Content-Type: multipart/alternative; boundary="_000_9D50FCE7413E3D4EA5E42331115FB5BC105872C8xmbrcdx03ciscoc_" MIME-Version: 1.0 Subject: Re: [CCAMP] =?gb2312?b?tPC4tDogtPC4tDogIGRyYWZ0LWFsaS1jY2FtcC1sc3At?= =?gb2312?b?aW5xdWlyeS0wMA==?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 17:05:40 -0000 --_000_9D50FCE7413E3D4EA5E42331115FB5BC105872C8xmbrcdx03ciscoc_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 RmF0YWksDQoNClRoZSBjb3JlIG5ldHdvcmsgY2FuIG9ubHkgcmUtZXZhbHVhdGUgdGhlIHBhdGgg YmFzZWQgb24gdGhlIHByb3BlcnRpZXMgb2YgdGhlIGN1cnJlbnRseS1lc3RhYmxpc2hlZCBMU1As IGJ1dCB0aGUgVU5JLUMgbWF5IHdpc2ggdG8gY2hhbmdlIHRoaW5ncyBsaWtlIGNvbnN0cmFpbnRz IGluIGJldHdlZW4gYXR0ZW1wdHMgaW4gdGhlIGludGVyZXN0cyBvZiBmaW5kaW5nIHRoZSBiZXN0 IGNvbXByb21pc2UgYmV0d2VlbiBkZXNpcmVkIGNvbnN0cmFpbnRzIGFuZCBhY3R1YWxseSBmaW5k aW5nIGEgcGF0aCB0aGF0oa9zIGF2YWlsYWJsZS4NCg0KQnV0IHllcywgd2UgY2FuIGNlcnRhaW5s eSBjbGFyaWZ5IHRoZSByZXF1aXJlbWVudHMgaW4gdGhlIG5leHQgcmV2aXNpb24uDQoNCkNoZWVy cw0KDQpNYXR0DQoNCg0KSGkgWmFmYXIsDQoNCkkgd291bGQgbGlrZSB0byBzZWUgbXVjaCAgY2xl YXJlciByZXF1aXJlbWVudHMgb2YgeW91ciBkcmFmdHMsIGUuZywgaWYgeW91IHdhbnQgdGhlIFVO Qy1DIHRvIHByb2JlIHRoZSBmZWFzaWJpbGl0eSBvZiBhIHBhdGggKGUuZywgZm9yIG9wdGltaXph dGlvbiBwdXJwb3NlKSwgSSB3b3VsZCBzYXkgdGhpcyBpcyBub3QgdGhlIGJ1c2luZXNzIG9mIHRo ZSBVTkktQywgdGhpcyB3aWxsIGJlIGRvbmUgZS5nLCBiYXNlZCBvbiB0aGUgcG9saWN5IG9mIHRo ZSBvcGVyYXRvciBmcm9tIHRoZSBVTkktTiBkb21haW5zIChhbmQgdGhlbiB0aGVyZSBhcmUgbG90 cyBvZiBleGlzdGluZyBtZWFzdXJlbWVudHMgdG8gYWNoaWV2ZSB0aGUgb2JqZWN0aXZlcykuDQoN Cg0KVGhhbmtzDQoNCkZhdGFpDQoNCg0Kt6K8/sjLOiBaYWZhciBBbGkgKHphbGkpIFttYWlsdG86 emFsaUBjaXNjby5jb21dDQq3osvNyrG85DogMjAxM8TqN9TCMzHI1SAxODoxOQ0KytW8/sjLOiBG YXRhaSBaaGFuZzsgS2h1emVtYSBQaXRoZXdhbjsgQ0NBTVAgKGNjYW1wQGlldGYub3JnPG1haWx0 bzpjY2FtcEBpZXRmLm9yZz4pDQrW98ziOiBSZTogtPC4tDogW0NDQU1QXSBkcmFmdC1hbGktY2Nh bXAtbHNwLWlucXVpcnktMDANCg0KRmF0YWk6DQoNClNlcnZpY2UgcHJvdmlkZXIgbWF5IE5PVCB1 c2UgUENFIGluIGFsbCBkZXBsb3ltZW50cywgZS5nLiwgYXMgaXQgaXMgdGhlIGNhc2Ugb2YgbW9z dCwgaWYgbm90IGFsbCwgb2YgdGhlIGN1cnJlbnQgZGVwbG95bWVudHMuIEkgd291bGQgYWxzbyBh cmd1ZSB0aGF0IFBDRSBpcyBub3QgYmUgYmVzdCBwbGFjZSBmb3IgdGhlIGlucXVpcnkgdHlwZSBw cm9jZWR1cmUgYXMgc2NvcGUgb2YgUENFIGlzIHBhdGggY29tcHV0YXRpb24uIFBhdGggaW5xdWly eSBpcyBub3QgYWJvdXQgcGF0aCBjb21wdXRhdGlvbiBidXQgYWJvdXQgcHJvYmluZyBmZWFzaWJp bGl0eSBvZiBhIHBhdGguDQoNClRoYW5rcw0KDQpSZWdhcmRzIKGtIFphZmFyDQoNCkZyb206IEZh dGFpIFpoYW5nIDx6aGFuZ2ZhdGFpQGh1YXdlaS5jb208bWFpbHRvOnpoYW5nZmF0YWlAaHVhd2Vp LmNvbT4+DQpEYXRlOiBXZWRuZXNkYXksIEp1bHkgMzEsIDIwMTMgNTozMiBBTQ0KVG86IHphbGkg PHphbGlAY2lzY28uY29tPG1haWx0bzp6YWxpQGNpc2NvLmNvbT4+LCBLaHV6ZW1hIFBpdGhld2Fu IDxrcGl0aGV3YW5AaW5maW5lcmEuY29tPG1haWx0bzprcGl0aGV3YW5AaW5maW5lcmEuY29tPj4s ICJjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0Zi5vcmc+IiA8Y2NhbXBAaWV0Zi5vcmc8 bWFpbHRvOmNjYW1wQGlldGYub3JnPj4NClN1YmplY3Q6ILTwuLQ6IFtDQ0FNUF0gZHJhZnQtYWxp LWNjYW1wLWxzcC1pbnF1aXJ5LTAwDQoNCkhpIFphZmFyLA0KDQpQbGVhc2UgaGF2ZSBhICBsb29r IGF0IGRyYWZ0LXpoYW5nLWNjYW1wLWdtcGxzLXVuaS1hcHA8aHR0cDovL3Rvb2xzLmlldGYub3Jn L2lkL2RyYWZ0LXpoYW5nLWNjYW1wLWdtcGxzLXVuaS1hcHAtMDQudHh0Piwgd2hpY2ggaGFzIGEg dmVyeSBnb29kIHNvbHV0aW9uIHRvIGFkZHJlc3MgdGhlIHJlcXVpcmVtZW50cyBpbiB5b3VyIHRo aXMgIGRyYWZ0IChhbmQgc29tZSBvdGhlciByZXF1aXJlbWVudHMgaW4geW91ciBvdGhlciBkcmFm dHMpLg0KDQpJIGRvbqGvdCB0aGluayBpdCBpcyBhIGdvb2QgaWRlYSB0byBvdmVybG9hZCBSU1ZQ LVRFIGJ5IGludHJvZHVjaW5nIHBhdGggY29tcHV0YXRpb24gZnVuY3Rpb25zIChvciBQQ0VQIG9i amVjdHMgbGlrZSBPRiB5b3UgZGVzY3JpYmVkIGluIGFub3RoZXIgZHJhZnQpLg0KDQpUaGFua3MN Cg0KRmF0YWkNCg0KDQoNCreivP7IyzogY2NhbXAtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86Y2Nh bXAtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSC0+rHt IFphZmFyIEFsaSAoemFsaSkNCreiy83KsbzkOiAyMDEzxOo31MIzMcjVIDE3OjAwDQrK1bz+yMs6 IEtodXplbWEgUGl0aGV3YW47IENDQU1QIChjY2FtcEBpZXRmLm9yZzxtYWlsdG86Y2NhbXBAaWV0 Zi5vcmc+KQ0K1vfM4jogUmU6IFtDQ0FNUF0gZHJhZnQtYWxpLWNjYW1wLWxzcC1pbnF1aXJ5LTAw DQoNCkhpIEtodXplbWE6DQoNClBsZWFzZSBzZWUgaW4tbGluZS4NCg0KVGhhbmtzDQoNClJlZ2Fy ZHMgoa0gWmFmYXINCg0KRnJvbTogS2h1emVtYSBQaXRoZXdhbiA8a3BpdGhld2FuQGluZmluZXJh LmNvbTxtYWlsdG86a3BpdGhld2FuQGluZmluZXJhLmNvbT4+DQpEYXRlOiBXZWRuZXNkYXksIEp1 bHkgMzEsIDIwMTMgMzo0NSBBTQ0KVG86IHphbGkgPHphbGlAY2lzY28uY29tPG1haWx0bzp6YWxp QGNpc2NvLmNvbT4+LCAiY2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYub3JnPiIgPGNj YW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogW0NDQU1Q XSBkcmFmdC1hbGktY2NhbXAtbHNwLWlucXVpcnktMDANCg0KSGkgWmFmYXIsDQoNClRoZSBwb2lu dCBJIGFtIG1ha2luZyBoZXJlIGlzLi4gdGhlIDIgYXBwcm9hY2hlcy4uIEFkbWluIFN0YXR1cyBh bmQgTFNQX0F0dHJpYnV0ZXMsIGFyZSBleGFjdGx5IHNhbWUgaW4gdGVybXMgb2Ygb2JqZWN0IHJl LXVzZSBhbmQgYm90aCBvZiB0aGVtIGRlZmluZXMgbmV3IGJpdHMgZm9yIGVuaGFuY2VkIGZ1bmN0 aW9uYWxpdHkuIFRoZSBMU1BfQXR0cmlidXRlIGFwcHJvYWNoIGhhcyBhZGRpdGlvbmFsIG92ZXJo ZWFkIG9mIG1hbmFnaW5nIGEgc2VwYXJhdGUgY29udHJvbCBMU1AsIHdoaWNoIGlzIG5vdCBkZXNp cmFibGUuDQoNCg0KVGhlIGlucXVpcmUvIHBvdGVudGlhbCByZW9wdCBMU1AgaXMgbGlrZWx5IG5v dCB0byBmb2xsb3cgcGF0aCBvZiB0aGUgY3VycmVudGx5IGFjdGl2ZSBMU1AuIEhlbmNlIHRoaXMg Y2Fubm90IGJlIGltcGxlbWVudGVkIGJ5IGp1c3QgYWRkaW5nIHNvbWUgQWRtaW4gU3RhdHVzIGJp dCBvbiB0aGUgY3VycmVudCBMU1AuIE9uZSBuZWVkIHRvIHNpZ25hbCBhIHNlcGFyYXRlIExTUC4N Cg0KVGhhbmtzDQpLaHV6ZW1hDQoNCkZyb206IFphZmFyIEFsaSAoemFsaSkgW21haWx0bzp6YWxp QGNpc2NvLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgSnVseSAzMSwgMjAxMyAyOjE3IEFNDQpUbzog S2h1emVtYSBQaXRoZXdhbjsgQ0NBTVAgKGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRm Lm9yZz4pDQpTdWJqZWN0OiBSZTogW0NDQU1QXSBkcmFmdC1hbGktY2NhbXAtbHNwLWlucXVpcnkt MDANCg0KSGkgS2h1emVtYToNCg0KRm9yIHNpZ25hbGluZyBpbnF1aXJ5IExTUCB3aXRoIHJlc291 cmNlIGxvY2tpbmcsIHdlIGFyZSB1c2luZyB0aGUgUHJlLVBsYW5uZWQgTFNQIGZsYWcgYXMtaXMg YXMgZGVmaW5lZCBpbiBSRkM2MDAxLiBHaXZlbiB0aGlzLCB3ZSBhcmUgZGVmaW5pbmcgYSBuZXcg ZmxhZyB3aGVuIGlucXVpcnkgTFNQIG5lZWRzIHRvIGJlIHNpZ25hbCB3aXRob3V0IHJlc291cmNl IGxvY2tpbmcuDQoNClRoYW5rcw0KDQpSZWdhcmRzIKGtIFphZmFyDQoNCkZyb206IEtodXplbWEg UGl0aGV3YW4gPGtwaXRoZXdhbkBpbmZpbmVyYS5jb208bWFpbHRvOmtwaXRoZXdhbkBpbmZpbmVy YS5jb20+Pg0KRGF0ZTogVHVlc2RheSwgSnVseSAzMCwgMjAxMyA1OjQ1IFBNDQpUbzogemFsaSA8 emFsaUBjaXNjby5jb208bWFpbHRvOnphbGlAY2lzY28uY29tPj4sICJjY2FtcEBpZXRmLm9yZzxt YWlsdG86Y2NhbXBAaWV0Zi5vcmc+IiA8Y2NhbXBAaWV0Zi5vcmc8bWFpbHRvOmNjYW1wQGlldGYu b3JnPj4NClN1YmplY3Q6IFJFOiBbQ0NBTVBdIGRyYWZ0LWFsaS1jY2FtcC1sc3AtaW5xdWlyeS0w MA0KDQpXZWxsLi4gbm90IHJlYWxseS4NCg0KWW91IGFyZSBkZWZpbmluZyBuZXcgYml0cyBmb3Ig TFNQX0FUVFJJQlVURVMgZm9yIHJlc291cmNlIGxvY2tpbmehrSBhcmVuoa90IHlvdT8NCg0KSW5z dGVhZCBvZiBkb2luZyB0aGF0LCB5b3UgY2FuIGRlZmluZSBiaXRzIGluIEFETUlOX1NUQVRVUyBh bmQgc2F2ZSBuZXcgTFNQIGxpZmUgY3ljbGUgbWFuYWdlbWVudCwgd2hpY2ggd291bGQgYmUgcXVp dGUgY3VtYmVyc29tZS4NCg0KUmVnYXJkcw0KS2h1emVtYQ0KDQpGcm9tOiBaYWZhciBBbGkgKHph bGkpIFttYWlsdG86emFsaUBjaXNjby5jb21dDQpTZW50OiBUdWVzZGF5LCBKdWx5IDMwLCAyMDEz IDEwOjA4IFBNDQpUbzogS2h1emVtYSBQaXRoZXdhbjsgQ0NBTVAgKGNjYW1wQGlldGYub3JnPG1h aWx0bzpjY2FtcEBpZXRmLm9yZz4pDQpTdWJqZWN0OiBSZTogW0NDQU1QXSBkcmFmdC1hbGktY2Nh bXAtbHNwLWlucXVpcnktMDANCg0KS2h1emVtYToNCg0KVGhlIHBvaW50IGlzIHRvIHJldXNlIHdo YXQgYWxyZWFkeSBleGlzdHMuIFRoZSBQcmUtUGxhbm5lZCBMU1AgZmxhZyBpbiB0aGUgQXR0cmli dXRlIEZsYWdzIFRMViBvZiBMU1BfQVRUUklCVVRFUyBvYmplY3QgaXMgYWxyZWFkeSBkZWZpbmVk IGluIFtSRkM1NDIwXSBhbmQgaXMgYSBnbG92ZSBmaXQuDQoNClRoYW5rcw0KDQpSZWdhcmRzIKGt IFphZmFyDQoNCkZyb206IEtodXplbWEgUGl0aGV3YW4gPGtwaXRoZXdhbkBpbmZpbmVyYS5jb208 bWFpbHRvOmtwaXRoZXdhbkBpbmZpbmVyYS5jb20+Pg0KRGF0ZTogVHVlc2RheSwgSnVseSAzMCwg MjAxMyAxOjQwIFBNDQpUbzogS2h1emVtYSBQaXRoZXdhbiA8a3BpdGhld2FuQGluZmluZXJhLmNv bTxtYWlsdG86a3BpdGhld2FuQGluZmluZXJhLmNvbT4+LCAiY2NhbXBAaWV0Zi5vcmc8bWFpbHRv OmNjYW1wQGlldGYub3JnPiIgPGNjYW1wQGlldGYub3JnPG1haWx0bzpjY2FtcEBpZXRmLm9yZz4+ DQpTdWJqZWN0OiBSZTogW0NDQU1QXSBkcmFmdC1hbGktY2NhbXAtbHNwLWlucXVpcnktMDANCg0K QW5vdGhlciBwb2ludCBJIHNwb2tlIGFib3V0IGluIHRoZSBtZWV0aW5nIC4uDQoNCldoeSBjYW6h r3Qgd2UgZXh0ZW5kIEFkbWluIFN0YXR1cyBvYmplY3QgdG8gc2lnbmFsIHJlc291cmNlIGxvY2tp bmcsIGNoZWNraW5nIGZvciByZS1vcHRpbWl6YXRpb24uIFNpbmNlIHRoaXMgb3BlcmF0aW9uIGlz IHR5cGljYWxseSBkb25lIGluIG1haW50ZW5hbmNlIHdpbmRvdyBieSBBZG1pbiwgaXQgbWF5IG1h a2Ugc2Vuc2UgdG8gdXNlIEFkbWluIFN0YXR1cyBPYmplY3QuIE1vcmVvdmVyLCB3ZSBoYXZlIGxv dHMgb2YgYml0cyBhdmFpbGFibGUvdW5kZWZpbmVkIGluIEFkbWluIFN0YXR1cyBvYmplY3QuDQoN ClRoaXMgd2lsbCBzYXZlIG5ldHdvcmsgZWxlbWVudCB0byBtYW5hZ2UgbGlmZSBvZiBhZGRpdGlv bmFsIExTUCBhbmQgY29udHJvbCBwbGFuZSBmYWlsdXJlIHJlbGF0ZWQgaXNzdWVzIGF0dGFjaGVk IHRvIHRoZSBhZGRpdGlvbmFsIExTUC4NCg0KS2h1emVtYQ0KDQo= --_000_9D50FCE7413E3D4EA5E42331115FB5BC105872C8xmbrcdx03ciscoc_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Fatai,

 

The core network can = only re-evaluate the path based on the properties of the currently-establis= hed LSP, but the UNI-C may wish to change things like constraints in between attempts in the interests of finding the best compromise betwee= n desired constraints and actually finding a path that=A1=AFs available.

 

But yes, we can certa= inly clarify the requirements in the next revision.

 

Cheers

 

Matt

 

 

Hi Za= far,

=  

I wou= ld like to see much  clearer requirements of your drafts, e.g, if you = want the UNC-C to probe the feasibility of a path (e.g, for optimization pu= rpose), I would say this is not the business of the UNI-C, this will be done e.g, based on the policy of the operator f= rom the UNI-N domains (and then there are lots of existing measurements to = achieve the objectives).

=  

=  

Thank= s

=  

Fatai=

=  

=  

=B7=A2=BC=FE=C8=CB: Zafar Ali (zali) [mailto:zali@cisco.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA7=D4=C231=C8=D5 18:19
=CA=D5=BC=FE=C8=CB: Fatai Zhang; Khuzema= Pithewan; CCAMP (ccamp@ietf.org)
=D6=F7=CC=E2: Re: = =B4=F0=B8=B4: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 

Fatai:&= nbsp;

&n= bsp;

Service= provider may NOT use PCE in all deployments, e.g., as it is the case of mo= st, if not all, of the current deployments. I would also argue that PCE is = not be best place for the inquiry type procedure as scope of PCE is path computation. Path inquiry is not about p= ath computation but about probing feasibility of a path. 

&n= bsp;

Thanks<= o:p>

&n= bsp;

Regards= =A1=AD Zafar

&n= bsp;

From: Fatai Zhang <zhangfatai@huawei.com>
Date: Wednesday, July 31, 2013 5:32 AM
To: zali <zali@cisco.com>= ;, Khuzema Pithewan <kpithewan= @infinera.com>, "ccamp@ietf.o= rg" <ccamp@ietf.org> Subject: =B4=F0=B8=B4: [CCAMP] draft-al= i-ccamp-lsp-inquiry-00

&n= bsp;

Hi Za= far,

 = ;

Pleas= e have a  look at draft-zhang-ccamp-gmpls-uni-app, which has a very go= od solution to address the requirements in your this  draft (and some other requirements in your other drafts).

 =

I don= =A1=AFt think it is a good idea to overload RSVP-TE by introducing path com= putation functions (or PCEP objects like OF you described in another draft)= .

 = ;

Thank= s

 = ;

Fatai=

 = ;

 = ;

 = ;

=B7=A2=BC=FE=C8= =CB: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] =B4=FA=B1=ED Zafar Ali (zali)
=B7=A2=CB=CD=CA=B1=BC=E4: 2013=C4=EA7=D4=C231=C8=D5 17:00
=CA=D5=BC=FE=C8=CB: Khuzema Pithewan; CC= AMP (ccamp@ietf.org)
=D6=F7=CC=E2: Re: [CCAMP] draft-ali-ccam= p-lsp-inquiry-00

 =

Hi Khuz= ema: 

 <= /span>

Please = see in-line. 

 <= /span>

Thanks<= /span>

 <= /span>

Regards= =A1=AD Zafar

 <= /span>

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Wednesday, July 31, 2013 3:45 AM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 <= /span>

Hi Zafar,

 

The point I am making = here is.. the 2 approaches.. Admin Status and LSP_Attributes, are exactly s= ame in terms of object re-use and both of them defines new bits for enhance= d functionality. The LSP_Attribute approach has additional overhead of managing a separate control LSP, which is not d= esirable.

 

 <= /span>

The inquire/ potential reopt LSP is likely not to fol= low path of the currently active LSP. Hence this cannot be implemented by j= ust adding some Admin Status bit on the current LSP. One need to signal a separate LSP. 

 <= /span>

Thanks

Khuzema

 

From: Zafar Ali (zali) [mailto:zali@cisco.com]
Sent: Wednesday, July 31, 2013 2:17 AM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 =

Hi Khuz= ema:

 

For signalin= g inquiry LSP with resource locking, we are using the Pre-Planned LSP flag&= nbsp;as-is as defined in RFC6001. Given this, we are defining a new flag when inquiry LSP needs to be signal without resource locking. &nb= sp;

 

Thanks

 

Regards =A1= =AD Zafar

 <= /span>

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Tuesday, July 30, 2013 5:45 PM
To: zali <zali@cisco.com>= ;, "ccamp@ietf.org" <ccamp@ietf.org>
Subject: RE: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 <= /span>

Well.. not really.

 

You are defining new b= its for LSP_ATTRIBUTES for resource locking=A1=AD aren=A1=AFt you?

 

Instead of doing that,= you can define bits in ADMIN_STATUS and save new LSP life cycle management= , which would be quite cumbersome.<= /o:p>

 

Regards

Khuzema

 

From: Zafar Ali (zali) [mailto:= zali@cisco.com]
Sent: Tuesday, July 30, 2013 10:08 PM
To: Khuzema Pithewan; CCAMP (ccamp= @ietf.org)
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 =

Khuzema= :

 <= /span>

The poi= nt is to reuse what already exists. The Pre-Planned LSP flag in the At= tribute Flags TLV of LSP_ATTRIBUTES object is already defined in [RFC5420] = and is a glove fit. 

 <= /span>

Thanks<= /span>

 <= /span>

Regards= =A1=AD Zafar

 <= /span>

From: Khuzema Pithewan <kpithewan@infinera.com>
Date: Tuesday, July 30, 2013 1:40 PM
To: Khuzema Pithewan <k= pithewan@infinera.com>, "ccam= p@ietf.org" <ccamp@ietf.org>
Subject: Re: [CCAMP] draft-ali-ccamp-lsp-inquiry-00

 <= /span>

Another point I spoke = about in the meeting ..

 

Why can=A1=AFt we exte= nd Admin Status object to signal resource locking, checking for re-optimiza= tion. Since this operation is typically done in maintenance window by Admin= , it may make sense to use Admin Status Object. Moreover, we have lots of bits available/undefined in Admin Status object.=

 

This will save network= element to manage life of additional LSP and control plane failure related= issues attached to the additional LSP.<= o:p>

 

Khuzema

 

--_000_9D50FCE7413E3D4EA5E42331115FB5BC105872C8xmbrcdx03ciscoc_-- From lberger@labn.net Wed Jul 31 10:09:32 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8211F21E80FD for ; Wed, 31 Jul 2013 10:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.915 X-Spam-Level: X-Spam-Status: No, score=-101.915 tagged_above=-999 required=5 tests=[AWL=0.685, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szqJy-vbWDTh for ; Wed, 31 Jul 2013 10:09:26 -0700 (PDT) Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by ietfa.amsl.com (Postfix) with SMTP id B833121E80DD for ; Wed, 31 Jul 2013 10:09:02 -0700 (PDT) Received: (qmail 13461 invoked by uid 0); 31 Jul 2013 17:08:40 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy1.bluehost.com with SMTP; 31 Jul 2013 17:08:40 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=m58VrqfQeoLGlQQ+8sU6Juh9H9Xrv1Jz8xFbMc3tM3w=; b=QEQ3VHheKezvUGtzY3ym64XQJ9gUXvk24vyr5FDW+Jrzf7/uaIWWE3LKDt6qW5XRR/7ZLiY0WDpIVF6Zs9uwFRHG0qSgsFgxmZnNfzXXSbLnsdCOr8fw+G0MNWZ7PLlc; Received: from box313.bluehost.com ([69.89.31.113]:54749 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.80) (envelope-from ) id 1V4ZtA-00028s-G4; Wed, 31 Jul 2013 11:08:40 -0600 Message-ID: <51F94497.8010402@labn.net> Date: Wed, 31 Jul 2013 13:08:39 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: Daniele Ceccarelli References: <031c01ce8b87$45b79cb0$d126d610$@olddog.co.uk> <4A1562797D64E44993C5CBF38CF1BE48126BF3@ESESSMB301.ericsson.se> In-Reply-To: <4A1562797D64E44993C5CBF38CF1BE48126BF3@ESESSMB301.ericsson.se> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Cc: "draft-ietf-ccamp-otn-g709-info-model@tools.ietf.org" , "ccamp@ietf.org" Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-otn-g709-info-model X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 17:09:33 -0000 Daniele, See comments below. On 07/31/2013 06:28 AM, Daniele Ceccarelli wrote: ... >> -----Original Message----- ... >> As I asked in my email to the CCAMP list, I find it odd that this document makes >> no reference to RFC 5307 and the use of IS-IS as a routing protocol in GMPLS >> control of OTN. >> > > At the end of the intro we added the following sentence: > " As far as it concerns routing, analogous considerations apply to IS-IS > [RFC5307] but in the following only a gap analysis with respect to OSPF-TE is provided." > Given that the analysis for 5307 is pretty similar to 4203, I think you should take a pass at including it as well. I'm happy to review/contribute as needed. Thanks, Lou (chair & doc shepherd) From zhang.xian@huawei.com Wed Jul 31 14:49:41 2013 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABBBF11E8117 for ; Wed, 31 Jul 2013 14:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.498 X-Spam-Level: X-Spam-Status: No, score=-4.498 tagged_above=-999 required=5 tests=[AWL=2.102, 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 wWkEq277sOJq for ; Wed, 31 Jul 2013 14:49:36 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id ADA7511E80E6 for ; Wed, 31 Jul 2013 14:49:35 -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 AVP66317; Wed, 31 Jul 2013 21:49:33 +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, 31 Jul 2013 22:49:20 +0100 Received: from SZXEML416-HUB.china.huawei.com (10.82.67.155) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 31 Jul 2013 22:49:31 +0100 Received: from SZXEML510-MBX.china.huawei.com ([169.254.3.4]) by szxeml416-hub.china.huawei.com ([10.82.67.155]) with mapi id 14.01.0323.007; Thu, 1 Aug 2013 05:49:18 +0800 From: "Zhangxian (Xian)" To: "ccamp@ietf.org" Thread-Topic: follow-up on draft-zhang-ccamp-gmpls-h-lsp-mln-05 Thread-Index: Ac6ONGnO1v/vaEAqR+y66p48VraVAw== Date: Wed, 31 Jul 2013 21:49:18 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.216.75] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [CCAMP] follow-up on draft-zhang-ccamp-gmpls-h-lsp-mln-05 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 21:49:41 -0000 Hi, CCAMPers,=20 At end of the presentation, a question was raised by Lou that check whet= her RFC6107 can solve the problem we are trying to address. After discussio= n offline with co-authors as well as check that RFC, we think that that RFC= does not cover what this draft intend to do. The reason is: RFC6107 provid= e extensions to support to indicate the type of FA-LSP, or to which IGP the= FA-LSP is advertised to etc. . In our draft, we trying to address the pro= blem how a LSP (not necessarily a FA-LSP) can explicitly specify the region= change in a MLN/MRN context.=20 As for the question wehther it needs routing extensions, I may not make = myself clear enough during the presentation. So i would like to clarify: ye= s, we need it. Of course, we primarily have in mind using PCE to provide su= ch needed information. But IMHO current scope of "draft-rao-ccamp-mlnmrn-ot= n-ospfte-ext-02" is generic enough. Would be great to see a generic draft a= nd we are interested to get aligned.=20 Please review our draft and send your comments. Much appreciated. =20 Regards, Xian =