From loa@pi.nu Tue Jun 1 00:46:11 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D880A3A68E7; Tue, 1 Jun 2010 00:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxDJjoth3Tqm; Tue, 1 Jun 2010 00:46:10 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 99C583A68BD; Tue, 1 Jun 2010 00:46:10 -0700 (PDT) Received: from [156.106.219.23] (unknown [156.106.219.23]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id CEF37D404F; Tue, 1 Jun 2010 09:45:54 +0200 (CEST) Message-ID: <4C04B508.1080706@pi.nu> Date: Tue, 01 Jun 2010 09:21:44 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: CCAMP , mpls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [CCAMP] joint ccamp and mpls working group last call on draft-ietf-mpls-explicit-resource-control-bundle+07 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 01 Jun 2010 07:46:12 -0000 All, in mid-February the draft-ietf-mpls-explicit-resource-control-bundle was retruned to the MPLS Working Group from the responsible AD stating that: - it had been a long time since the working group last call - the version that were working group last called was much earlier than the one we requested publication for, i.e. the document has changed many times since the wg last call - this document is also of interest for the CCAMP working group, and the working group last call should have been jointly between MPLS and CCAMP - there is a need to poll both working group to see if there is an interest in this draft. However it also needs to pointed out that there are at least two deployed implementations and we need to amke the reservation of the code points in the IANA section. This is to start a joint CCAMP and MPLS working group last call on draft-ietf-mpls-explicit-resource-control-bundle-07. Please send your comments to the mpls and ccamp working group list. The joint working group last call ends eob June 16. /Loa -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From lberger@labn.net Tue Jun 1 04:46:01 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD5D028C110 for ; Tue, 1 Jun 2010 04:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.288 X-Spam-Level: X-Spam-Status: No, score=0.288 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72Zicact7gSR for ; Tue, 1 Jun 2010 04:45:59 -0700 (PDT) Received: from outbound-mail-313.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id A67623A69D8 for ; Tue, 1 Jun 2010 04:45:49 -0700 (PDT) Received: (qmail 28585 invoked by uid 0); 1 Jun 2010 11:45:37 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 1 Jun 2010 11:45:37 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=yjrNelhl7OY8e9n/hFe6wo431ZmJ78Q0D17VTm+6uxFx2z2ObzaLlUubf4F4zKOXxW2/4vtW1FNs+/XVekfVpZ3CqElUXXKHE4iwfeOXbYArx/nE8EoTUZbadpIm3YIz; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OJPua-0005IM-Uk for ccamp@ietf.org; Tue, 01 Jun 2010 05:45:37 -0600 Message-ID: <4C04F2E0.2000307@labn.net> Date: Tue, 01 Jun 2010 07:45:36 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100301 Eudora/3.0.1 MIME-Version: 1.0 To: CCAMP Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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] poll on draft-shiomoto-ccamp-switch-programming-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 01 Jun 2010 11:46:02 -0000 This mail begins a 2 week poll on making draft-shiomoto-ccamp-switch-programming-01 a working group document. The intended publication status for this document is Informational. Please indicate your support or objections to the WG taking on this document. If you object, please indicate your rationale. The documents being polled is: http://tools.ietf.org/html/draft-shiomoto-ccamp-switch-programming-01 The poll ends Tuesday June 15. Much thanks, Lou From sunwq@mit.edu Tue Jun 1 06:44:54 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90E223A6A0F for ; Tue, 1 Jun 2010 06:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.882 X-Spam-Level: * X-Spam-Status: No, score=1.882 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 40Fmc6m1saR7 for ; Tue, 1 Jun 2010 06:44:53 -0700 (PDT) Received: from dmz-mailsec-scanner-3.mit.edu (DMZ-MAILSEC-SCANNER-3.MIT.EDU [18.9.25.14]) by core3.amsl.com (Postfix) with ESMTP id C56C13A69FA for ; Tue, 1 Jun 2010 06:44:49 -0700 (PDT) X-AuditID: 1209190e-b7b82ae000005260-70-4c050ec50ded Received: from mailhub-2.mit.edu (MAILHUB-2.MIT.EDU [18.7.62.30]) by dmz-mailsec-scanner-3.mit.edu (Symantec Brightmail Gateway) with SMTP id E6.C2.21088.5CE050C4; Tue, 1 Jun 2010 09:44:37 -0400 (EDT) Received: from outgoing-legacy.mit.edu (OUTGOING-LEGACY.MIT.EDU [18.7.22.104]) by mailhub-2.mit.edu (8.13.8/8.9.2) with ESMTP id o51DibAX025882; Tue, 1 Jun 2010 09:44:37 -0400 Received: from webmail-5.mit.edu (WEBMAIL-5.MIT.EDU [18.9.23.15]) ) by outgoing-legacy.mit.edu (8.13.6/8.12.4) with ESMTP id o51DiUGi017752; Tue, 1 Jun 2010 09:44:31 -0400 (EDT) Received: from webmail-5.mit.edu (webmail-5.mit.edu [127.0.0.1]) by webmail-5.mit.edu (8.13.8) with ESMTP id o51DiZw2003476; Tue, 1 Jun 2010 09:44:35 -0400 Received: (from nobody@localhost) by webmail-5.mit.edu (8.13.8/8.13.8/Submit) id o51DiYM6003473; Tue, 1 Jun 2010 09:44:34 -0400 X-Authentication-Warning: webmail-5.mit.edu: nobody set sender to sunwq@mit.edu using -f Received: from 182.149.38.58.broad.xw.sh.dynamic.163data.com.cn (182.149.38.58.broad.xw.sh.dynamic.163data.com.cn [58.38.149.182]) (User authenticated as sunwq@ATHENA.MIT.EDU) by webmail.mit.edu (Horde MIME library) with HTTP; Tue, 01 Jun 2010 09:44:34 -0400 Message-ID: <20100601094434.8stonbpwsgcw4k48@webmail.mit.edu> Date: Tue, 01 Jun 2010 09:44:34 -0400 From: Weiqiang Sun To: Lou Berger References: <4C04F2E0.2000307@labn.net> In-Reply-To: <4C04F2E0.2000307@labn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) X-Brightmail-Tracker: AAAAARRkZUY= Cc: CCAMP Subject: Re: [CCAMP] poll on draft-shiomoto-ccamp-switch-programming-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 01 Jun 2010 13:44:55 -0000 Yes, support. Weiqiang Quoting Lou Berger : > This mail begins a 2 week poll on making > draft-shiomoto-ccamp-switch-programming-01 a working group document. > The intended publication status for this document is Informational. > Please indicate your support or objections to the WG taking on this > document. If you object, please indicate your rationale. > > The documents being polled is: > > http://tools.ietf.org/html/draft-shiomoto-ccamp-switch-programming-01 > > The poll ends Tuesday June 15. > > Much thanks, > Lou > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From gregb@grotto-networking.com Tue Jun 1 08:13:57 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9A353A68A4 for ; Tue, 1 Jun 2010 08:13:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DvnkVwuRol-u for ; Tue, 1 Jun 2010 08:13:54 -0700 (PDT) Received: from mail32c40.carrierzone.com (mail32c40.carrierzone.com [209.235.156.172]) by core3.amsl.com (Postfix) with ESMTP id 21F423A68F2 for ; Tue, 1 Jun 2010 08:13:53 -0700 (PDT) X-Authenticated-User: gregb.grotto-networking.com Received: from [192.168.0.131] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133]) (authenticated bits=0) by mail32c40.carrierzone.com (8.13.6/8.13.1) with ESMTP id o51FDcsq026046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 1 Jun 2010 11:13:40 -0400 Message-ID: <4C0523A3.2070402@grotto-networking.com> Date: Tue, 01 Jun 2010 08:13:39 -0700 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: ccamp@ietf.org References: <4C04F2E0.2000307@labn.net> In-Reply-To: <4C04F2E0.2000307@labn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [CCAMP] poll on draft-shiomoto-ccamp-switch-programming-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 01 Jun 2010 15:13:57 -0000 Support Greg On 6/1/2010 4:45 AM, Lou Berger wrote: > This mail begins a 2 week poll on making > draft-shiomoto-ccamp-switch-programming-01 a working group document. > The intended publication status for this document is Informational. > Please indicate your support or objections to the WG taking on this > document. If you object, please indicate your rationale. > > The documents being polled is: > > http://tools.ietf.org/html/draft-shiomoto-ccamp-switch-programming-01 > > The poll ends Tuesday June 15. > > Much thanks, > Lou > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > > -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 From zhang.fei3@zte.com.cn Tue Jun 1 17:37:56 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00BE63A6801; Tue, 1 Jun 2010 17:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.79 X-Spam-Level: X-Spam-Status: No, score=-92.79 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_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpvxFKsS34wz; Tue, 1 Jun 2010 17:37:55 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 7226A3A68F9; Tue, 1 Jun 2010 17:37:53 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 368871461793122; Wed, 2 Jun 2010 08:30:35 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 6793.1973556129; Wed, 2 Jun 2010 08:37:40 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o520bVhH011323; Wed, 2 Jun 2010 08:37:31 +0800 (CST) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <4C04F2E0.2000307@labn.net> To: Lou Berger MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: zhang.fei3@zte.com.cn Date: Wed, 2 Jun 2010 08:37:30 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-06-02 08:37:31, Serialize complete at 2010-06-02 08:37:31 Content-Type: multipart/alternative; boundary="=_alternative 0003955648257736_=" X-MAIL: mse2.zte.com.cn o520bVhH011323 Cc: CCAMP , ccamp-bounces@ietf.org Subject: [CCAMP] =?gb2312?b?tPC4tDogIHBvbGwgb24gZHJhZnQtc2hpb21vdG8tY2Nh?= =?gb2312?b?bXAtc3dpdGNoLXByb2dyYW1taW5nLTAx?= X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 02 Jun 2010 00:37:56 -0000 This is a multipart message in MIME format. --=_alternative 0003955648257736_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 eWVhaC9zdXBwb3J0IQ0KDQpGZWkNCg0KDQoNCkxvdSBCZXJnZXIgPGxiZXJnZXJAbGFibi5uZXQ+ IA0Kt6K8/sjLOiAgY2NhbXAtYm91bmNlc0BpZXRmLm9yZw0KMjAxMC0wNi0wMSAxOTo0NQ0KDQrK 1bz+yMsNCkNDQU1QIDxjY2FtcEBpZXRmLm9yZz4NCrOty80NCg0K1vfM4g0KW0NDQU1QXSBwb2xs IG9uIGRyYWZ0LXNoaW9tb3RvLWNjYW1wLXN3aXRjaC1wcm9ncmFtbWluZy0wMQ0KDQoNCg0KDQoN Cg0KVGhpcyBtYWlsIGJlZ2lucyBhIDIgd2VlayBwb2xsIG9uIG1ha2luZyANCmRyYWZ0LXNoaW9t b3RvLWNjYW1wLXN3aXRjaC1wcm9ncmFtbWluZy0wMSBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQu IA0KVGhlIGludGVuZGVkIHB1YmxpY2F0aW9uIHN0YXR1cyBmb3IgdGhpcyBkb2N1bWVudCBpcyBJ bmZvcm1hdGlvbmFsLiANClBsZWFzZSBpbmRpY2F0ZSB5b3VyIHN1cHBvcnQgb3Igb2JqZWN0aW9u cyB0byB0aGUgV0cgdGFraW5nIG9uIHRoaXMgDQpkb2N1bWVudC4gIElmIHlvdSBvYmplY3QsIHBs ZWFzZSBpbmRpY2F0ZSB5b3VyIHJhdGlvbmFsZS4NCg0KVGhlIGRvY3VtZW50cyBiZWluZyBwb2xs ZWQgaXM6DQoNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNoaW9tb3RvLWNjYW1w LXN3aXRjaC1wcm9ncmFtbWluZy0wMQ0KDQpUaGUgcG9sbCBlbmRzIFR1ZXNkYXkgSnVuZSAxNS4N Cg0KTXVjaCB0aGFua3MsDQpMb3UNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpDQ0FNUCBtYWlsaW5nIGxpc3QNCkNDQU1QQGlldGYub3JnDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQoNCg0KDQo= --=_alternative 0003955648257736_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnllYWgvc3VwcG9ydCE8L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkZlaTwvZm9udD4NCjxi cj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQg d2lkdGg9MzQlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5Mb3UgQmVyZ2VyICZs dDtsYmVyZ2VyQGxhYm4ubmV0Jmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtjY2FtcC1ib3VuY2VzQGlldGYub3JnPC9mb250 Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTAtMDYtMDEgMTk6NDU8L2Zv bnQ+DQo8dGQgd2lkdGg9NjUlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrV vP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Q0NB TVAgJmx0O2NjYW1wQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0K PGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9u dD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W0NDQU1QXSBwb2xsIG9uIGRyYWZ0LXNoaW9tb3Rv LWNjYW1wLXN3aXRjaC1wcm9ncmFtbWluZy0wMTwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxl Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJy Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+VGhpcyBtYWlsIGJlZ2lucyBhIDIgd2VlayBw b2xsIG9uIG1ha2luZyA8YnI+DQpkcmFmdC1zaGlvbW90by1jY2FtcC1zd2l0Y2gtcHJvZ3JhbW1p bmctMDEgYSB3b3JraW5nIGdyb3VwIGRvY3VtZW50LiA8YnI+DQpUaGUgaW50ZW5kZWQgcHVibGlj YXRpb24gc3RhdHVzIGZvciB0aGlzIGRvY3VtZW50IGlzIEluZm9ybWF0aW9uYWwuIDxicj4NClBs ZWFzZSBpbmRpY2F0ZSB5b3VyIHN1cHBvcnQgb3Igb2JqZWN0aW9ucyB0byB0aGUgV0cgdGFraW5n IG9uIHRoaXMgPGJyPg0KZG9jdW1lbnQuICZuYnNwO0lmIHlvdSBvYmplY3QsIHBsZWFzZSBpbmRp Y2F0ZSB5b3VyIHJhdGlvbmFsZS48YnI+DQo8YnI+DQpUaGUgZG9jdW1lbnRzIGJlaW5nIHBvbGxl ZCBpczo8YnI+DQo8YnI+DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zaGlvbW90 by1jY2FtcC1zd2l0Y2gtcHJvZ3JhbW1pbmctMDE8YnI+DQo8YnI+DQpUaGUgcG9sbCBlbmRzIFR1 ZXNkYXkgSnVuZSAxNS48YnI+DQo8YnI+DQpNdWNoIHRoYW5rcyw8YnI+DQpMb3U8YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkNDQU1QIG1h aWxpbmcgbGlzdDxicj4NCkNDQU1QQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9jY2FtcDxicj4NCjxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPg0K --=_alternative 0003955648257736_=-- From srivatsan.raghavan@aricent.com Tue Jun 1 21:55:27 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AE6F3A68F8 for ; Tue, 1 Jun 2010 21:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbA0PSgL29fR for ; Tue, 1 Jun 2010 21:55:26 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by core3.amsl.com (Postfix) with ESMTP id 7E9F83A6853 for ; Tue, 1 Jun 2010 21:55:25 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id B05CA36B5F for ; Wed, 2 Jun 2010 10:25:11 +0530 (IST) Received: from GUREXHT02.ASIAN.AD.ARICENT.COM (gurexht02.asian.ad.aricent.com [10.203.171.138]) by jaguar.aricent.com (Postfix) with ESMTP id 9AEB236B57 for ; Wed, 2 Jun 2010 10:25:11 +0530 (IST) Received: from GUREXMB01.asian.ad.aricent.com ([10.203.171.130]) by GUREXHT02.ASIAN.AD.ARICENT.COM ([10.203.171.138]) with mapi; Wed, 2 Jun 2010 10:25:10 +0530 From: Srivatsan Raghavan To: "ccamp@ietf.org" Date: Wed, 2 Jun 2010 10:25:10 +0530 Thread-Topic: Clarification reqd: RFC 4802/03 XCIndex for Bidirectional LSP Thread-Index: AQHLAg/HCubSyyIl5U2Lrue3gqo67A== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CCAMP] Clarification reqd: RFC 4802/03 XCIndex for Bidirectional LSP X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 02 Jun 2010 04:55:27 -0000 Hi all I require a clarification on the examples in RFC 4802 and 4803 with respective to Bidirectional LSPs. RFC 4803 shows an example where the two cross connect entries are created, containing references to insegment and outsegment in each direction respectively. Since this is actually one Bidirectional LSP , each of the Cross Connect Entries contain pointers to the same mplsXCLspId as illustrated in = the example However, if we assume the LspID as equivalent to the Tunnel Instance in the tunnel Table Mib, each row in the tunnel table contains a single mplsTunnelXCPointer which could reference one of the two cross connect entries mentioned above. So how is the other XC index referenced from the Tunnel Table entry ? In order to achieve this, if we were to create a separate Tunnel Table row with a new Tunnel Instance field containing a separate XC pointer, then this degenerates to the case of two unidirectional LSPs in opposite d= irection defeating the purpose of the gmplsTunnelDirection field in the Tunnel Table= . Could the authors or anyone in the mailing list throw light on this tunnel = table -> XCIndex Linkage for bidirectional LSPs ? Thanks Srivatsan "DISCLAIMER: This message is proprietary to Aricent and is intended solely = for the use of the individual to whom it is addressed. It may contain privi= leged or confidential information and should not be circulated or used for = any purpose other than for what it is intended. If you have received this m= essage in error, please notify the originator immediately. If you are not t= he intended recipient, you are notified that you are strictly prohibited fr= om using, copying, altering, or disclosing the contents of this message. Ar= icent accepts no responsibility for loss or damage arising from the use of = the information transmitted by this email including damage from virus." From ylee@huawei.com Tue Jun 1 22:18:15 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1456C3A698C for ; Tue, 1 Jun 2010 22:18:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7NC58q99orT for ; Tue, 1 Jun 2010 22:18:09 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 868CD3A6955 for ; Tue, 1 Jun 2010 22:18:08 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3D00CRVG1V5R@usaga01-in.huawei.com> for ccamp@ietf.org; Tue, 01 Jun 2010 22:17:56 -0700 (PDT) Received: from L73682 ([210.21.213.197]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L3D006F8G1T44@usaga01-in.huawei.com> for ccamp@ietf.org; Tue, 01 Jun 2010 22:17:55 -0700 (PDT) Date: Wed, 02 Jun 2010 00:17:49 -0500 From: Young Lee In-reply-to: <4C04F2E0.2000307@labn.net> To: 'Lou Berger' , 'CCAMP' Message-id: <002a01cb0212$f3364c80$6b08a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcsBgAdLPWqluidNSqCIBXy5L2ALSgAkuTfg References: <4C04F2E0.2000307@labn.net> Subject: Re: [CCAMP] poll on draft-shiomoto-ccamp-switch-programming-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 02 Jun 2010 05:18:15 -0000 Yes/support. Young -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger Sent: Tuesday, June 01, 2010 6:46 AM To: CCAMP Subject: [CCAMP] poll on draft-shiomoto-ccamp-switch-programming-01 This mail begins a 2 week poll on making draft-shiomoto-ccamp-switch-programming-01 a working group document. The intended publication status for this document is Informational. Please indicate your support or objections to the WG taking on this document. If you object, please indicate your rationale. The documents being polled is: http://tools.ietf.org/html/draft-shiomoto-ccamp-switch-programming-01 The poll ends Tuesday June 15. Much thanks, Lou _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From gyzhang@sina.com Tue Jun 1 22:22:05 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 726253A69E6 for ; Tue, 1 Jun 2010 22:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.944 X-Spam-Level: *** X-Spam-Status: No, score=3.944 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DATE_IN_FUTURE_12_24=2.189, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nceTFKNsFkMz for ; Tue, 1 Jun 2010 22:21:58 -0700 (PDT) Received: from smtp.sina.com.cn (mail3-167.sinamail.sina.com.cn [202.108.3.167]) by core3.amsl.com (Postfix) with ESMTP id 4D88C3A6955 for ; Tue, 1 Jun 2010 22:21:45 -0700 (PDT) Received: from irxd5-201.sinamail.sina.com.cn (unknown [10.55.5.201]) by smtp.sina.com.cn (SINAMAIL) with ESMTP id A4629108950 for ; Wed, 2 Jun 2010 13:21:32 +0800 (CST) X-Originating-IP: [124.64.127.243] Received: from unknown (HELO gyzhang) ([124.64.127.243]) by irxd5-201.sinamail.sina.com.cn with ESMTP; 02 Jun 2010 13:21:30 +0800 Date: Wed, 2 Jun 2010 13:22:58 -0700 From: "gyzhang" To: "Lou Berger" , "CCAMP" References: <4C04F2E0.2000307@labn.net> Message-ID: <201006021322571710711@sina.com> X-mailer: Foxmail 6, 15, 201, 22 [cn] Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====003_Dragon166343777484_=====" Subject: Re: [CCAMP] poll on draft-shiomoto-ccamp-switch-programming-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 02 Jun 2010 05:22:05 -0000 This is a multi-part message in MIME format. --=====003_Dragon166343777484_===== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 7bit Yes/Support. Guoying Zhang 2010-06-02 gyzhang Lou Berger 2010-06-01 03:45:36 CCAMP [CCAMP] poll on draft-shiomoto-ccamp-switch-programming-01 This mail begins a 2 week poll on making draft-shiomoto-ccamp-switch-programming-01 a working group document. The intended publication status for this document is Informational. Please indicate your support or objections to the WG taking on this document. If you object, please indicate your rationale. The documents being polled is: http://tools.ietf.org/html/draft-shiomoto-ccamp-switch-programming-01 The poll ends Tuesday June 15. Much thanks, Lou _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp --=====003_Dragon166343777484_===== Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC42MDAwLjE3MDIzIiBuYW1lPUdFTkVSQVRPUj4NCjxTVFlMRT5AZm9udC1mYWNlIHsNCglmb250 LWZhbWlseTogy87M5TsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBWZXJkYW5hOw0K fQ0KQGZvbnQtZmFjZSB7DQoJZm9udC1mYW1pbHk6IEDLzszlOw0KfQ0KQHBhZ2UgU2VjdGlvbjEg e3NpemU6IDU5NS4zcHQgODQxLjlwdDsgbWFyZ2luOiA3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4w cHQ7IGxheW91dC1ncmlkOiAxNS42cHQ7IH0NClAuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6 IGludGVyLWlkZW9ncmFwaDsgRk9OVC1TSVpFOiAxMC41cHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7 IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJvbWFuIjsgVEVYVC1BTElHTjoganVzdGlmeQ0KfQ0K TEkuTXNvTm9ybWFsIHsNCglURVhULUpVU1RJRlk6IGludGVyLWlkZW9ncmFwaDsgRk9OVC1TSVpF OiAxMC41cHQ7IE1BUkdJTjogMGNtIDBjbSAwcHQ7IEZPTlQtRkFNSUxZOiAiVGltZXMgTmV3IFJv bWFuIjsgVEVYVC1BTElHTjoganVzdGlmeQ0KfQ0KRElWLk1zb05vcm1hbCB7DQoJVEVYVC1KVVNU SUZZOiBpbnRlci1pZGVvZ3JhcGg7IEZPTlQtU0laRTogMTAuNXB0OyBNQVJHSU46IDBjbSAwY20g MHB0OyBGT05ULUZBTUlMWTogIlRpbWVzIE5ldyBSb21hbiI7IFRFWFQtQUxJR046IGp1c3RpZnkN Cn0NCkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9 DQpTUEFOLk1zb0h5cGVybGluayB7DQoJQ09MT1I6IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5k ZXJsaW5lDQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9SOiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjog dW5kZXJsaW5lDQp9DQpTUEFOLk1zb0h5cGVybGlua0ZvbGxvd2VkIHsNCglDT0xPUjogcHVycGxl OyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0KfQ0KU1BBTi5FbWFpbFN0eWxlMTcgew0KCUZP TlQtV0VJR0hUOiBub3JtYWw7IENPTE9SOiB3aW5kb3d0ZXh0OyBGT05ULVNUWUxFOiBub3JtYWw7 IEZPTlQtRkFNSUxZOiBWZXJkYW5hOyBURVhULURFQ09SQVRJT046IG5vbmU7IG1zby1zdHlsZS10 eXBlOiBwZXJzb25hbC1jb21wb3NlDQp9DQpESVYuU2VjdGlvbjEgew0KCXBhZ2U6IFNlY3Rpb24x DQp9DQpVTktOT1dOIHsNCglGT05ULVNJWkU6IDEwcHQNCn0NCkJMT0NLUVVPVEUgew0KCU1BUkdJ Ti1UT1A6IDBweDsgTUFSR0lOLUJPVFRPTTogMHB4OyBNQVJHSU4tTEVGVDogMmVtDQp9DQpPTCB7 DQoJTUFSR0lOLVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NClVMIHsNCglNQVJHSU4t VE9QOiAwcHg7IE1BUkdJTi1CT1RUT006IDBweA0KfQ0KPC9TVFlMRT4NCjwvSEVBRD4NCjxCT0RZ IHN0eWxlPSJGT05ULVNJWkU6IDEwcHQ7IEZPTlQtRkFNSUxZOiB2ZXJkYW5hIj4NCjxESVY+PEZP TlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwODAgc2l6ZT0yPlllcy9TdXBwb3J0LjwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwODAgc2l6ZT0yPjwvRk9O VD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIGNvbG9yPSMwMDAwODAgc2l6 ZT0yPkd1b3lpbmcgWmhhbmc8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBj b2xvcj0jYzBjMGMwIHNpemU9Mj4yMDEwLTA2LTAyIDwvRk9OVD48L0RJVj48Rk9OVCANCmZhY2U9 VmVyZGFuYSBjb2xvcj0jMDAwMDgwIHNpemU9Mj4NCjxIUiBzdHlsZT0iV0lEVEg6IDEyMnB4OyBI RUlHSFQ6IDJweCIgYWxpZ249bGVmdCBTSVpFPTI+DQo8L0ZPTlQ+DQo8RElWPjxGT05UIGZhY2U9 VmVyZGFuYSBjb2xvcj0jYzBjMGMwIHNpemU9Mj48U1BBTj5neXpoYW5nPC9TUEFOPiANCjwvRk9O VD48L0RJVj48Rk9OVCBmYWNlPVZlcmRhbmEgY29sb3I9IzAwMDA4MCBzaXplPTI+DQo8SFI+DQo8 L0ZPTlQ+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+TG91IEJlcmdlciA8L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+MjAxMC0wNi0wMSZuYnNwOyAw Mzo0NTozNiA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+Q0NB TVAgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPiZuYnNwOzwv Rk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1WZXJkYW5hIHNpemU9Mj5bQ0NBTVBdIHBvbGwg b24gDQpkcmFmdC1zaGlvbW90by1jY2FtcC1zd2l0Y2gtcHJvZ3JhbW1pbmctMDEgPC9GT05UPjwv RElWPg0KPERJVj48Rk9OVCBmYWNlPVZlcmRhbmEgc2l6ZT0yPjwvRk9OVD4gPC9ESVY+DQo8RElW PjxGT05UIGZhY2U9VmVyZGFuYSBzaXplPTI+DQo8RElWPlRoaXMmbmJzcDttYWlsJm5ic3A7YmVn aW5zJm5ic3A7YSZuYnNwOzImbmJzcDt3ZWVrJm5ic3A7cG9sbCZuYnNwO29uJm5ic3A7bWFraW5n Jm5ic3A7PC9ESVY+DQo8RElWPmRyYWZ0LXNoaW9tb3RvLWNjYW1wLXN3aXRjaC1wcm9ncmFtbWlu Zy0wMSZuYnNwO2EmbmJzcDt3b3JraW5nJm5ic3A7Z3JvdXAmbmJzcDtkb2N1bWVudC4mbmJzcDs8 L0RJVj4NCjxESVY+VGhlJm5ic3A7aW50ZW5kZWQmbmJzcDtwdWJsaWNhdGlvbiZuYnNwO3N0YXR1 cyZuYnNwO2ZvciZuYnNwO3RoaXMmbmJzcDtkb2N1bWVudCZuYnNwO2lzJm5ic3A7SW5mb3JtYXRp b25hbC4mbmJzcDs8L0RJVj4NCjxESVY+UGxlYXNlJm5ic3A7aW5kaWNhdGUmbmJzcDt5b3VyJm5i c3A7c3VwcG9ydCZuYnNwO29yJm5ic3A7b2JqZWN0aW9ucyZuYnNwO3RvJm5ic3A7dGhlJm5ic3A7 V0cmbmJzcDt0YWtpbmcmbmJzcDtvbiZuYnNwO3RoaXMmbmJzcDs8L0RJVj4NCjxESVY+ZG9jdW1l bnQuJm5ic3A7Jm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtvYmplY3QsJm5ic3A7cGxlYXNlJm5ic3A7 aW5kaWNhdGUmbmJzcDt5b3VyJm5ic3A7cmF0aW9uYWxlLjwvRElWPg0KPERJVj48L0RJVj4NCjxE SVY+VGhlJm5ic3A7ZG9jdW1lbnRzJm5ic3A7YmVpbmcmbmJzcDtwb2xsZWQmbmJzcDtpczo8L0RJ Vj4NCjxESVY+PC9ESVY+DQo8RElWPmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXNo aW9tb3RvLWNjYW1wLXN3aXRjaC1wcm9ncmFtbWluZy0wMTwvRElWPg0KPERJVj48L0RJVj4NCjxE SVY+VGhlJm5ic3A7cG9sbCZuYnNwO2VuZHMmbmJzcDtUdWVzZGF5Jm5ic3A7SnVuZSZuYnNwOzE1 LjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+TXVjaCZuYnNwO3RoYW5rcyw8L0RJVj4NCjxESVY+ TG91PC9ESVY+DQo8RElWPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPC9ESVY+DQo8RElWPkNDQU1QJm5ic3A7bWFpbGluZyZuYnNwO2xpc3Q8L0RJVj4NCjxE SVY+Q0NBTVBAaWV0Zi5vcmc8L0RJVj4NCjxESVY+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9jY2FtcDwvRElWPg0KPERJVj48L0RJVj48L0ZPTlQ+PC9ESVY+PC9CT0RZPjwv SFRNTD4NCg== --=====003_Dragon166343777484_=====-- From Attila.Takacs@ericsson.com Tue Jun 1 23:41:36 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B25823A6964 for ; Tue, 1 Jun 2010 23:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnWWnxQCJrKo for ; Tue, 1 Jun 2010 23:41:25 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 900863A6928 for ; Tue, 1 Jun 2010 23:41:15 -0700 (PDT) X-AuditID: c1b4fb39-b7b80ae000001aa1-ab-4c05fcfd28fa Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 7B.60.06817.DFCF50C4; Wed, 2 Jun 2010 08:41:01 +0200 (CEST) Received: from esessmw0191.eemea.ericsson.se (153.88.115.84) by esessmw0247.eemea.ericsson.se (153.88.115.93) with Microsoft SMTP Server (TLS) id 8.2.234.1; Wed, 2 Jun 2010 08:41:01 +0200 Received: from ESESSCMS0355.eemea.ericsson.se ([169.254.2.123]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 2 Jun 2010 08:41:00 +0200 From: Attila Takacs To: Lou Berger , CCAMP Date: Wed, 2 Jun 2010 08:41:00 +0200 Thread-Topic: [CCAMP] poll on draft-shiomoto-ccamp-switch-programming-01 Thread-Index: AcsBf/9O2CBRj3wuQumcw5ofc1+mZgAnipkw Message-ID: <79F41BA1E9BF3C489375521EF8DDE23C1FED302433@ESESSCMS0355.eemea.ericsson.se> References: <4C04F2E0.2000307@labn.net> In-Reply-To: <4C04F2E0.2000307@labn.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [CCAMP] poll on draft-shiomoto-ccamp-switch-programming-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 02 Jun 2010 06:41:36 -0000 Support. Attila=20 (BTW, I would remove "Advise on" from the title.) > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]=20 > On Behalf Of Lou Berger > Sent: Tuesday, June 01, 2010 1:46 PM > To: CCAMP > Subject: [CCAMP] poll on draft-shiomoto-ccamp-switch-programming-01 >=20 > This mail begins a 2 week poll on making > draft-shiomoto-ccamp-switch-programming-01 a working group document.=20 > The intended publication status for this document is Informational.=20 > Please indicate your support or objections to the WG taking=20 > on this document. If you object, please indicate your rationale. >=20 > The documents being polled is: >=20 > http://tools.ietf.org/html/draft-shiomoto-ccamp-switch-programming-01 >=20 > The poll ends Tuesday June 15. >=20 > Much thanks, > Lou > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > = From danli@huawei.com Wed Jun 2 00:05:29 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 40E723A69CB for ; Wed, 2 Jun 2010 00:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.518 X-Spam-Level: * X-Spam-Status: No, score=1.518 tagged_above=-999 required=5 tests=[AWL=1.667, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogMA+HepDNOL for ; Wed, 2 Jun 2010 00:05:25 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 7F91F3A67D3 for ; Wed, 2 Jun 2010 00:05:25 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3D00C5JL0O5R@usaga01-in.huawei.com> for ccamp@ietf.org; Wed, 02 Jun 2010 00:05:13 -0700 (PDT) Received: from rdun014012.na.infineon.com ([156.106.204.80]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPSA id <0L3D009V0L0NPT@usaga01-in.huawei.com> for ccamp@ietf.org; Wed, 02 Jun 2010 00:05:12 -0700 (PDT) Date: Wed, 02 Jun 2010 09:05:10 +0200 From: Dan Li In-reply-to: <4C04F2E0.2000307@labn.net> To: Lou Berger Message-id: <7CD736FA-95B0-4BBA-B54B-FF5B6CE2ABBA@huawei.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.936) Content-type: text/plain; charset=GB2312; format=flowed; delsp=yes Content-transfer-encoding: quoted-printable References: <4C04F2E0.2000307@labn.net> Cc: CCAMP Subject: Re: [CCAMP] poll on draft-shiomoto-ccamp-switch-programming-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 02 Jun 2010 07:05:29 -0000 Hi, Yes/Support! I think this document clarifies the procedure of how the LSP be =20 established, and also provide the good support information for the LSP =20= establishment performance drafts. Dan =D4=DA 2010-6-1=A3=AC=CF=C2=CE=E71:45=A3=AC Lou Berger =D0=B4=B5=C0=A3=BA > This mail begins a 2 week poll on making draft-shiomoto-ccamp-switch-=20= > programming-01 a working group document. The intended publication =20 > status for this document is Informational. Please indicate your =20 > support or objections to the WG taking on this document. If you =20 > object, please indicate your rationale. > > The documents being polled is: > > http://tools.ietf.org/html/draft-shiomoto-ccamp-switch-programming-01 > > The poll ends Tuesday June 15. > > Much thanks, > Lou > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From julien.meuric@orange-ftgroup.com Wed Jun 2 02:21:49 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 069AE3A6988 for ; Wed, 2 Jun 2010 02:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.76 X-Spam-Level: X-Spam-Status: No, score=-0.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPWEQRpDTk2F for ; Wed, 2 Jun 2010 02:21:45 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id 5DB803A6933 for ; Wed, 2 Jun 2010 02:21:44 -0700 (PDT) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 1991FFC4003 for ; Wed, 2 Jun 2010 11:21:31 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 116A0FC4008 for ; Wed, 2 Jun 2010 11:21:31 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Jun 2010 11:21:24 +0200 Received: from [10.193.71.77] ([10.193.71.77]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Wed, 2 Jun 2010 11:21:23 +0200 Message-ID: <4C062293.9050402@orange-ftgroup.com> Date: Wed, 02 Jun 2010 11:21:23 +0200 From: Julien Meuric Organization: France Telecom User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100423 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: ccamp@ietf.org References: <4C04F2E0.2000307@labn.net> In-Reply-To: <4C04F2E0.2000307@labn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 02 Jun 2010 09:21:24.0018 (UTC) FILETIME=[F8754120:01CB0234] Subject: Re: [CCAMP] poll on draft-shiomoto-ccamp-switch-programming-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 02 Jun 2010 09:21:49 -0000 Hi all. This document contains useful information which it makes sense to gather in a single place: I support. Julien Le 01/06/2010 13:45, Lou Berger a écrit : > This mail begins a 2 week poll on making > draft-shiomoto-ccamp-switch-programming-01 a working group document. > The intended publication status for this document is Informational. > Please indicate your support or objections to the WG taking on this > document. If you object, please indicate your rationale. > > The documents being polled is: > > http://tools.ietf.org/html/draft-shiomoto-ccamp-switch-programming-01 > > The poll ends Tuesday June 15. > > Much thanks, > Lou > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From i-nishioka@cb.jp.nec.com Wed Jun 2 06:08:50 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C3493A68F8 for ; Wed, 2 Jun 2010 06:08:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.51 X-Spam-Level: ** X-Spam-Status: No, score=2.51 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHgLy9GB7L-M for ; Wed, 2 Jun 2010 06:08:49 -0700 (PDT) Received: from tyo201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.193]) by core3.amsl.com (Postfix) with ESMTP id 7BF4D3A68BC for ; Wed, 2 Jun 2010 06:08:47 -0700 (PDT) Received: from mailgate4.nec.co.jp ([10.7.69.184]) by tyo201.gate.nec.co.jp (8.13.8/8.13.4) with ESMTP id o52D8X9N029887 for ; Wed, 2 Jun 2010 22:08:33 +0900 (JST) Received: (from root@localhost) by mailgate4.nec.co.jp (8.11.7/3.7W-MAILGATE-NEC) id o52D8XQ24914 for ccamp@ietf.org; Wed, 2 Jun 2010 22:08:33 +0900 (JST) Received: from mail02.kamome.nec.co.jp (mail02.kamome.nec.co.jp [10.25.43.5]) by mailsv.nec.co.jp (8.13.8/8.13.4) with ESMTP id o52D8XVn004527 for ; Wed, 2 Jun 2010 22:08:33 +0900 (JST) Received: from saigo.jp.nec.com ([10.26.220.6] [10.26.220.6]) by mail02.kamome.nec.co.jp with ESMTP id BT-MMP-3260315; Wed, 2 Jun 2010 22:08:21 +0900 Received: from C08AUG00201 ([10.56.131.165] [10.56.131.165]) by mail.jp.nec.com with ESMTP; Wed, 2 Jun 2010 22:08:21 +0900 From: "Itaru Nishioka" To: "'CCAMP'" References: <4C04F2E0.2000307@labn.net> In-Reply-To: <4C04F2E0.2000307@labn.net> Date: Wed, 2 Jun 2010 22:08:21 +0900 Organization: NEC Message-ID: <5AE285211B5747D5B8DB226EC2C60B0B@nsl.ad.nec.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6001.18416 Thread-Index: AcsBf/5aqozBDhsxR+6q3OwCUIUn7gA1IAfQ Subject: Re: [CCAMP] poll on draft-shiomoto-ccamp-switch-programming-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: i-nishioka@cb.jp.nec.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, 02 Jun 2010 13:08:50 -0000 Hi, Yes, support. Itaru > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] > On Behalf Of Lou Berger > Sent: Tuesday, June 01, 2010 8:46 PM > To: CCAMP > Subject: [CCAMP] poll on draft-shiomoto-ccamp-switch-programming-01 > > This mail begins a 2 week poll on making > draft-shiomoto-ccamp-switch-programming-01 a working group document. > The intended publication status for this document is Informational. > Please indicate your support or objections to the WG taking > on this document. If you object, please indicate your rationale. > > The documents being polled is: > > http://tools.ietf.org/html/draft-shiomoto-ccamp-switch-programming-01 > > The poll ends Tuesday June 15. > > Much thanks, > Lou > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From ldunbar@huawei.com Wed Jun 2 07:38:20 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C464B3A694A for ; Wed, 2 Jun 2010 07:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id em1WeVN5wrt6 for ; Wed, 2 Jun 2010 07:38:18 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id E8FBB3A6883 for ; Wed, 2 Jun 2010 07:38:17 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3E00F415ZHJ8@usaga01-in.huawei.com> for ccamp@ietf.org; Wed, 02 Jun 2010 07:38:05 -0700 (PDT) Received: from L735042 (250.91.88.117.broad.nj.js.dynamic.163data.com.cn [117.88.91.250]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L3E009JO5ZEZF@usaga01-in.huawei.com> for ccamp@ietf.org; Wed, 02 Jun 2010 07:38:05 -0700 (PDT) Date: Wed, 02 Jun 2010 09:38:08 -0500 From: Linda Dunbar In-reply-to: <002a01cb0212$f3364c80$6b08a8c0@china.huawei.com> To: 'Young Lee' , 'Lou Berger' , 'CCAMP' Message-id: <00de01cb0261$39be7ee0$9b96a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcsBgAdLPWqluidNSqCIBXy5L2ALSgAkuTfgABOPMdA= References: <4C04F2E0.2000307@labn.net> <002a01cb0212$f3364c80$6b08a8c0@china.huawei.com> Subject: Re: [CCAMP] poll on draft-shiomoto-ccamp-switch-programming-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 02 Jun 2010 14:38:20 -0000 Yes/support. Linda Dunbar -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger Sent: Tuesday, June 01, 2010 6:46 AM To: CCAMP Subject: [CCAMP] poll on draft-shiomoto-ccamp-switch-programming-01 This mail begins a 2 week poll on making draft-shiomoto-ccamp-switch-programming-01 a working group document. The intended publication status for this document is Informational. Please indicate your support or objections to the WG taking on this document. If you object, please indicate your rationale. The documents being polled is: http://tools.ietf.org/html/draft-shiomoto-ccamp-switch-programming-01 The poll ends Tuesday June 15. Much thanks, 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 adrian@olddog.co.uk Wed Jun 2 08:05:10 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D21A53A698F for ; Wed, 2 Jun 2010 08:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 50HLryOkSb4Y for ; Wed, 2 Jun 2010 08:05:05 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id BE1AD3A69E7 for ; Wed, 2 Jun 2010 08:05:03 -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 o52F4TfW019797; Wed, 2 Jun 2010 16:04:35 +0100 Received: from your029b8cecfe ([156.106.219.63]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id o52F4Tsv019789; Wed, 2 Jun 2010 16:04:29 +0100 Message-ID: <5E57B06015494C56BD0BC7EDDE94D6AF@your029b8cecfe> From: "Adrian Farrel" To: "Srivatsan Raghavan" , References: Date: Wed, 2 Jun 2010 16:04:20 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 Subject: Re: [CCAMP] Clarification reqd: RFC 4802/03 XCIndex for BidirectionalLSP X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jun 2010 15:05:10 -0000 Hi, I owe you a response on this but am currently very tied up in meetings. Please ping me if you have not heard back in two weeks. Adrian ----- Original Message ----- From: "Srivatsan Raghavan" To: Sent: Wednesday, June 02, 2010 5:55 AM Subject: [CCAMP] Clarification reqd: RFC 4802/03 XCIndex for BidirectionalLSP > Hi all > > I require a clarification on the examples in RFC 4802 and 4803 > with respective to Bidirectional LSPs. > > RFC 4803 shows an example where the two cross connect entries > are created, containing references to insegment and outsegment > in each direction respectively. > Since this is actually one Bidirectional LSP , each of the Cross > Connect Entries contain pointers to the same mplsXCLspId as illustrated in > the > example > > > However, if we assume the LspID as equivalent to the Tunnel Instance > in the tunnel Table Mib, each row in the tunnel table contains a > single mplsTunnelXCPointer which could reference one of the two > cross connect entries mentioned above. > So how is the other XC index referenced from the Tunnel Table entry ? > > In order to achieve this, if we were to create a separate Tunnel Table > row with a new Tunnel Instance field containing a separate XC pointer, > then this degenerates to the case of two unidirectional LSPs in opposite > direction > defeating the purpose of the gmplsTunnelDirection field in the Tunnel > Table. > > Could the authors or anyone in the mailing list throw light on this tunnel > table > -> XCIndex Linkage for bidirectional LSPs ? > > Thanks > Srivatsan > > > > > > "DISCLAIMER: This message is proprietary to Aricent and is intended solely > for the use of the individual to whom it is addressed. It may contain > privileged or confidential information and should not be circulated or > used for any purpose other than for what it is intended. If you have > received this message in error, please notify the originator immediately. > If you are not the intended recipient, you are notified that you are > strictly prohibited from using, copying, altering, or disclosing the > contents of this message. Aricent accepts no responsibility for loss or > damage arising from the use of the information transmitted by this email > including damage from virus." > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From Lyong@Ciena.com Wed Jun 2 08:12:45 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBB2928C122 for ; Wed, 2 Jun 2010 08:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aANDSR28NNt for ; Wed, 2 Jun 2010 08:12:43 -0700 (PDT) Received: from hicks.ciena.com (hicks.ciena.com [63.118.34.22]) by core3.amsl.com (Postfix) with ESMTP id 6F4F63A69E0 for ; Wed, 2 Jun 2010 08:12:38 -0700 (PDT) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4657 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Wed, 2 Jun 2010 11:11:58 -0400 Message-ID: <0AFD1B67B949784DA087CDA9F0DD4AD901A2EF1D@mdmxm03.ciena.com> In-Reply-To: <00de01cb0261$39be7ee0$9b96a8c0@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] poll on draft-shiomoto-ccamp-switch-programming-01 Thread-Index: AcsBgAdLPWqluidNSqCIBXy5L2ALSgAkuTfgABOPMdAAASwNsA== References: <4C04F2E0.2000307@labn.net><002a01cb0212$f3364c80$6b08a8c0@china.huawei.com> <00de01cb0261$39be7ee0$9b96a8c0@china.huawei.com> Importance: normal Priority: normal From: "Ong, Lyndon" To: "Lou Berger" , "CCAMP" Subject: Re: [CCAMP] poll on draft-shiomoto-ccamp-switch-programming-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 02 Jun 2010 15:12:46 -0000 Sure, support. Lyndon -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger Sent: Tuesday, June 01, 2010 6:46 AM To: CCAMP Subject: [CCAMP] poll on draft-shiomoto-ccamp-switch-programming-01 This mail begins a 2 week poll on making=20 draft-shiomoto-ccamp-switch-programming-01 a working group document.=20 The intended publication status for this document is Informational.=20 Please indicate your support or objections to the WG taking on this=20 document. If you object, please indicate your rationale. The documents being polled is: http://tools.ietf.org/html/draft-shiomoto-ccamp-switch-programming-01 The poll ends Tuesday June 15. Much thanks, 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 _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From zhangfatai@huawei.com Wed Jun 2 08:36:42 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC1173A693F for ; Wed, 2 Jun 2010 08:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.11 X-Spam-Level: X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zpz577Q4FIz for ; Wed, 2 Jun 2010 08:36:42 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 0BD2B3A69FB for ; Wed, 2 Jun 2010 08:36:42 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3E002368OPZU@usaga03-in.huawei.com> for ccamp@ietf.org; Wed, 02 Jun 2010 10:36:26 -0500 (CDT) Received: from zhang ([156.106.216.165]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L3E00CPS8OOPD@usaga03-in.huawei.com> for ccamp@ietf.org; Wed, 02 Jun 2010 10:36:25 -0500 (CDT) Date: Wed, 02 Jun 2010 23:36:18 +0800 From: Fatai Zhang To: Lou Berger Message-id: <01dc01cb0269$59206cf0$a5d86a9c@zhang> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4C04F2E0.2000307@labn.net> Cc: CCAMP Subject: Re: [CCAMP] poll on draft-shiomoto-ccamp-switch-programming-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 02 Jun 2010 15:36:42 -0000 Yes/Support. I think this draft is really useful for people (especially for the programmers) to understand when it is ready to start sending data traffic. ----- Original Message ----- From: "Lou Berger" To: "CCAMP" Sent: Tuesday, June 01, 2010 7:45 PM Subject: [CCAMP] poll on draft-shiomoto-ccamp-switch-programming-01 > This mail begins a 2 week poll on making > draft-shiomoto-ccamp-switch-programming-01 a working group document. > The intended publication status for this document is Informational. > Please indicate your support or objections to the WG taking on this > document. If you object, please indicate your rationale. > > The documents being polled is: > > http://tools.ietf.org/html/draft-shiomoto-ccamp-switch-programming-01 > > The poll ends Tuesday June 15. > > Much thanks, > Lou > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp From gregimirsky@gmail.com Wed Jun 2 10:19:14 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D22B28B797 for ; Wed, 2 Jun 2010 10:19:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 718xMleGdaIu for ; Wed, 2 Jun 2010 10:19:04 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 4CD8A3A6837 for ; Wed, 2 Jun 2010 10:19:04 -0700 (PDT) Received: by vws11 with SMTP id 11so2901709vws.31 for ; Wed, 02 Jun 2010 10:18:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=81ah16ru/dq3QT+qhsgbQ0mliu0yWSPm35kQv8DsoBU=; b=dnZP2oId4tixcodKXyz/b7DVwFGBTVpAjFf43QFL29egoLuTF9+5wKoS92Vb0g4/Vr ieWDfJYL+PS/68H+Iztg2AjiRRT0KSF+nu8ICs7k7RdDAKV8HOSE7trOCGfD774d8XuQ iLXWrT9l/4GaSe7WEQWJKpL29cxuzqen+leTs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=oJ0ahw04V1rTdGgJ5JXgw/YzA/oveVkBtLHIcpBNzgbd76chPQAU1c9vKtpw7p8+En goFllLm9gRkgBwJCV+duilGyxe8nKpeAN5gtwwG45EwTv9ETlRDY1jq52eijK0vDVheS 2oon1aVP4dTDoQV+0VlOPKwAWz5RZt9iKO9+g= MIME-Version: 1.0 Received: by 10.220.108.73 with SMTP id e9mr5843998vcp.268.1275499128826; Wed, 02 Jun 2010 10:18:48 -0700 (PDT) Received: by 10.220.171.147 with HTTP; Wed, 2 Jun 2010 10:18:48 -0700 (PDT) In-Reply-To: <01dc01cb0269$59206cf0$a5d86a9c@zhang> References: <4C04F2E0.2000307@labn.net> <01dc01cb0269$59206cf0$a5d86a9c@zhang> Date: Wed, 2 Jun 2010 10:18:48 -0700 Message-ID: From: Greg Mirsky To: CCAMP Content-Type: multipart/alternative; boundary=001485ece4707c2e3b04880f4857 Subject: Re: [CCAMP] poll on draft-shiomoto-ccamp-switch-programming-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 02 Jun 2010 17:19:14 -0000 --001485ece4707c2e3b04880f4857 Content-Type: text/plain; charset=ISO-8859-1 yes/support Regards, Greg ----- Original Message ----- > From: "Lou Berger" > To: "CCAMP" > Sent: Tuesday, June 01, 2010 7:45 PM > Subject: [CCAMP] poll on draft-shiomoto-ccamp-switch-programming-01 > > > > This mail begins a 2 week poll on making > > draft-shiomoto-ccamp-switch-programming-01 a working group document. > > The intended publication status for this document is Informational. > > Please indicate your support or objections to the WG taking on this > > document. If you object, please indicate your rationale. > > > > The documents being polled is: > > > > http://tools.ietf.org/html/draft-shiomoto-ccamp-switch-programming-01 > > > > The poll ends Tuesday June 15. > > > > Much thanks, > > 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 > --001485ece4707c2e3b04880f4857 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable yes/support

Regards,
Greg

----- Original Message -----
From: "Lou Berger" <lberge= r@labn.net>
To: "CCAMP" <ccamp@ietf.org<= /a>>
Sent: Tuesday, June 01, 2010 7:45 PM
Subject: [CCAMP] poll on draft-shiomoto-ccamp-switch-programming-01


> This mail begins a 2 week poll on making
> draft-shiomoto-ccamp-switch-programming-01 a working group document. > The intended publication status for this document is Informational. > Please indicate your support or objections to the WG taking on this > document. =A0If you object, please indicate your rationale.
>
> The documents being polled is:
>
> http://tools.ietf.org/html/draft-shiomoto-cca= mp-switch-programming-01
>
> The poll ends Tuesday June 15.
>
> Much thanks,
> Lou
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ccamp

--001485ece4707c2e3b04880f4857-- From Feng.f.Huang@alcatel-sbell.com.cn Wed Jun 2 11:49:38 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C46453A6A31 for ; Wed, 2 Jun 2010 11:49:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2WVYk49TIJE for ; Wed, 2 Jun 2010 11:49:24 -0700 (PDT) Received: from cnshjsmin03.alcatel-sbell.com.cn (cnshjsmin03.alcatel-sbell.com.cn [211.144.215.47]) by core3.amsl.com (Postfix) with ESMTP id 274F328C17E for ; Wed, 2 Jun 2010 11:49:14 -0700 (PDT) X-AuditID: ac189297-b7b94ae0000019ad-f6-4c06a782c6f4 Received: from cnshgsbhs01.ad4.ad.alcatel.com (smtp.cn.alcatel-lucent.com [172.24.146.145]) by cnshjsmin03.alcatel-sbell.com.cn (Symantec Brightmail Gateway) with SMTP id 34.1E.06573.287A60C4; Thu, 3 Jun 2010 02:48:34 +0800 (HKT) Received: from CNSHGSMBS01.ad4.ad.alcatel.com ([172.24.146.171]) by cnshgsbhs01.ad4.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Jun 2010 02:49:01 +0800 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: Thu, 3 Jun 2010 02:48:57 +0800 Message-ID: In-Reply-To: <01dc01cb0269$59206cf0$a5d86a9c@zhang> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [CCAMP] poll on draft-shiomoto-ccamp-switch-programming-01 Thread-Index: AcsCaWKd+OBzolKrTkW+o4c2DoeQjQAGslSQ References: <4C04F2E0.2000307@labn.net> <01dc01cb0269$59206cf0$a5d86a9c@zhang> From: "HUANG Feng F" To: "CCAMP" X-OriginalArrivalTime: 02 Jun 2010 18:49:01.0043 (UTC) FILETIME=[4406DC30:01CB0284] X-CFilter-Loop: Reflected X-Brightmail-Tracker: AAAAAQAAAZE= Subject: Re: [CCAMP] poll on draft-shiomoto-ccamp-switch-programming-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 02 Jun 2010 18:49:39 -0000 Yes/Support ----- Original Message ----- From: "Lou Berger" To: "CCAMP" Sent: Tuesday, June 01, 2010 7:45 PM Subject: [CCAMP] poll on draft-shiomoto-ccamp-switch-programming-01 > This mail begins a 2 week poll on making > draft-shiomoto-ccamp-switch-programming-01 a working group document.=20 > The intended publication status for this document is Informational.=20 > Please indicate your support or objections to the WG taking on this=20 > document. If you object, please indicate your rationale. >=20 > The documents being polled is: >=20 > http://tools.ietf.org/html/draft-shiomoto-ccamp-switch-programming-01 >=20 > The poll ends Tuesday June 15. >=20 > Much thanks, > 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 xsg@nict.go.jp Wed Jun 2 19:11:11 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 775243A6943 for ; Wed, 2 Jun 2010 19:11:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.059 X-Spam-Level: * X-Spam-Status: No, score=1.059 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_JP=1.244] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbE8aSL-0L+c for ; Wed, 2 Jun 2010 19:11:10 -0700 (PDT) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:2f8:29:300::1]) by core3.amsl.com (Postfix) with ESMTP id C965D3A68FC for ; Wed, 2 Jun 2010 19:11:09 -0700 (PDT) Received: from gw1.nict.go.jp (gw1 [133.243.18.250]) by ns1.nict.go.jp with ESMTP id o532Ar5V001918 for ; Thu, 3 Jun 2010 11:10:53 +0900 (JST) Received: from gw1.nict.go.jp (localhost [127.0.0.1]) by gw1.nict.go.jp with ESMTP id o532ArqW023796 for ; Thu, 3 Jun 2010 11:10:53 +0900 (JST) Received: from mail1.nict.go.jp (mail.nict.go.jp [133.243.18.3]) by gw1.nict.go.jp with ESMTP id o532ArUh023793 for ; Thu, 3 Jun 2010 11:10:53 +0900 (JST) Received: from mail1.nict.go.jp (localhost [127.0.0.1]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 1BD1016584 for ; Thu, 3 Jun 2010 11:10:53 +0900 (JST) Received: from [127.0.0.1] (ssh2.nict.go.jp [133.243.3.50]) by mail1.nict.go.jp (NICT Mail) with ESMTP id 15B5E16552 for ; Thu, 3 Jun 2010 11:10:53 +0900 (JST) Message-ID: <4C070F11.6020400@nict.go.jp> Date: Thu, 03 Jun 2010 11:10:25 +0900 From: Sugang XU User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: CCAMP References: <4C04F2E0.2000307@labn.net> In-Reply-To: <4C04F2E0.2000307@labn.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [CCAMP] poll on draft-shiomoto-ccamp-switch-programming-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 03 Jun 2010 02:11:11 -0000 Yes/Support Best Regards, Sugang > This mail begins a 2 week poll on making > draft-shiomoto-ccamp-switch-programming-01 a working group document. The > intended publication status for this document is Informational. Please > indicate your support or objections to the WG taking on this document. > If you object, please indicate your rationale. > > The documents being polled is: > > http://tools.ietf.org/html/draft-shiomoto-ccamp-switch-programming-01 > > The poll ends Tuesday June 15. > > Much thanks, > Lou > _______________________________________________ > CCAMP mailing list > CCAMP@ietf.org > https://www.ietf.org/mailman/listinfo/ccamp > From gregimirsky@gmail.com Thu Jun 3 10:47:37 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2773728C162; Thu, 3 Jun 2010 10:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.858 X-Spam-Level: X-Spam-Status: No, score=-0.858 tagged_above=-999 required=5 tests=[AWL=-0.860, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQuhr0aIjS0S; Thu, 3 Jun 2010 10:47:21 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 1B03F28C0D7; Thu, 3 Jun 2010 10:47:18 -0700 (PDT) Received: by vws11 with SMTP id 11so409549vws.31 for ; Thu, 03 Jun 2010 10:47:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=9Rh6aMdS/I7OLtizfkeAKYCjgAVbnrrItjBGusI9ywM=; b=AtCyAxKzNIxtVxslesVHeFSclpcSndvWCMjUc0YlyeO3fEkoLUidd3wUW50xvvJ8Ab lk6SkRKTL64j+98j4nHWuSiGFDgn0bZin0qkqaid1Kk5T1HZMi6ufblbnj0+zA+chpQx PQ9PUsvgjYxuIt5AcuiBprcoriOwB/dsZ0/VE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=EMvf+UB2iqXknEfhTxvRAyOdnP+8+sOTlBjF/iKkGC1qQUyIO3KcSiajQuoMavf7AN Qn76UOEQKQfJAkKaLkkMbWQuuB+7d7tIoSC+FALHpZocrR6K7QtkBlPIw8wg0zeuLydJ BMZjfu1J52dQc6ociUgg+shVYYzlaW4WLQmAY= MIME-Version: 1.0 Received: by 10.220.107.158 with SMTP id b30mr7050423vcp.105.1275587220137; Thu, 03 Jun 2010 10:47:00 -0700 (PDT) Received: by 10.220.171.147 with HTTP; Thu, 3 Jun 2010 10:47:00 -0700 (PDT) In-Reply-To: <2303DFD3C2884F2DB7C194CA0C60367D@m55527c> References: <2303DFD3C2884F2DB7C194CA0C60367D@m55527c> Date: Thu, 3 Jun 2010 10:47:00 -0700 Message-ID: From: Greg Mirsky To: Mach Chen Content-Type: multipart/alternative; boundary=00c09f8e5c5122e919048823cbce Cc: Mukund Mani , rtg-bfd@ietf.org, ccamp@ietf.org, mpls-tp@ietf.org Subject: Re: [CCAMP] [mpls-tp] Query on draft-chen-mpls-bfd-enhancement-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 03 Jun 2010 17:47:37 -0000 --00c09f8e5c5122e919048823cbce Content-Type: text/plain; charset=ISO-8859-1 Dear Mach, I very much agree with your view that "It depends on how you want each direction of a bidirectional LSP to be operated [GIM>> perhaps "protected" is closer] (independent or coordinated). If you want each direction of the bidirectional LSP to be protected and switched independently, there should be separate BFD session for each direction, or only one BFD session is needed." But I'd differ that associated and co-routed bidirectional LSP should be viewed as the same construct. They certainly may be viewed this way but I wouldn't see that as "should". If, for example, associated bidirectional LSP has assymetric BW for each direction, it would might be reasonable to have two independent BFD sessions and protect each direction independently. At the same time, bidirectional linear LSP will always be co-routed and using independent BFD session for each direction and independent protection doesn't seem practical. And I agree that BFD control mechanism is needed. I think it can be part of overall OAM control mechanism that is being worked on by CCAMP WG (I've added the CCAMP to the discussion). Best regards, Greg On Thu, Jun 3, 2010 at 2:49 AM, Mach Chen wrote: > Hi Mukund, > > Please see inline... > > > -------------------------------------------------- > From: "Mukund Mani" > Sent: Thursday, June 03, 2010 3:40 PM > To: ; > Subject: Re: Query on draft-chen-mpls-bfd-enhancement-01 > > > Hi Mach >> >> Maybe "BFD session set-up in progress" ?? >> > > Sounds better! > > > >> Also you mention: "The case you described *maybe* occur" >> As for me this will *always* occur if I configure both the ends in Active >> mode, because enabling BFD would initiate the LSP Ping for BFD bootstrap. >> Am I correct on this? >> > > A node (with smart implementation) with lower IP address should not > initiate the LSP Ping for BFD bootstrap for the LSP(s) if it has already > received an LSP Ping. So it depends on which end will firstly initiate the > LSP Ping. > > > >> On the whole I have had another question for quite some time which I have >> been asking in the MPLS-TP group also. >> My question was w.r.t the draft-asm-mpls-tp-bfd-cc-cv-04 which defines >> CC/CV >> and RDI mechanism using BFD and relates the number of sessions to >> protection >> switching architectures. But I would like to co-relate the details here to >> have a clear understanding on the BFD operation itself... >> > I totally agree with you on this. Although protection switching is normally > based on BFD detection results, but, IMHO, the number of BFD sessions should > not closely coupled with the protection switching types(e.g., 1:1,1+1...). > > > >> For co-routed bi-directional LSP the forward and reverse path will be >> associated at the LER's. Also the same relationship exists for forward and >> reverse path of associated bi-directional LSP's in the LER's and the >> common >> LSR's. >> > My understanding of co-routed bi-directional LSP is that it "associated" at > all nodes(including LERs and LSRs) along the LSP. > > > >> So why cant I use this inherent relationship to decide whether to have a >> single or two BFD sessions for a bidirectional LSP? >> > I am not sure what's your meaning about the inherent relationship. Do you > suggest: one BFD session for co-routed bi-dir LSP and two BFD sessions for > associated bi-dir LSP, or just one BFD session for bi-dir LSP (no matter > what co-routed or associated)? > > For co-routed and associated bidirectional LSP, IMHO, they should be > treated as the same construct. From the view of their clients, there is no > difference between the co-routed and associated bidirection LSP. Why there > requires associated bidirectional LSP, that is becase there is no co-routed > bidirectional LSP(e.g., the devices do support yet) and bidirectional LSPs > are desired. Now that we have associated two unidirectional LSPs into one > associated bidirectional LSP, it is logically to treat it as a real > bidirectional LSP. That means, there should be no difference in protection > switching between co-routed and associated bidrectional LSP. > > > Basically trying to figure out the need for the explicit mechanism >> using Return Path TLV and Session Control TLV mentioned in the draft >> "draft-chen-mpls-bfd-enhancement-01". >> I agree that for a pair of Uni-directional LSP's, using Return Path and >> Session Control TLV might be useful but why do we need this for associated >> and co-routed LSP? >> > > It depends on how you want each direction of a bidirectional LSP to be > operated (independent or coordinated). If you want each direction of the > bidirectional LSP to be protected and switched independently, there should > be separate BFD session for each direction, or only one BFD session is > needed. > > In our draft, if the LSP is bidirectional(co-routed or associated), there > is no need to carry the Return Path TLV, only Session Control TLV is > required, which is used to control how many BFD sessions should be setup > over the LSP. IMHO, if we want the LSP could be operated either as > independent or coodinated, a BFD session control mechanism(using Session > Control TLV or other means(e.g., in MPLS-TP scenario, using a bit of GACh > flag field)) is needed. > > Best regards, > Mach > > > >> With Regards >> Mukund >> >> On Tue, Jun 1, 2010 at 3:03 PM, Mach Chen wrote: >> >> Hi Mukund, >>> >>> Sorry for the delay response! >>> >>> The case you described maybe occur, and strictly speaking, it is not very >>> accurate to mention that the "Backward direction BFD session exists" as >>> return code, how about "BFD session collision"? or do you have any other >>> suggestions? >>> >>> Best regards, >>> Mach >>> -------------------------------------------------- >>> From: "Mukund Mani" >>> Sent: Monday, May 31, 2010 3:04 AM >>> To: >>> Subject: Query on draft-chen-mpls-bfd-enhancement-01 >>> >>> >>> Hi >>> >>>> >>>> Have a query w.r.t "draft-chen-mpls-bfd-enhancement-01". Could the draft >>>> authors kindly clarify the same: >>>> >>>> Section 4 on session establishment mentions the following: >>>> >>>> If node with the larger IP receives LSP ping >>>> message signaling BFD session with Session Control TLV, LSP ping >>>> reply must be transmitted with "Backward direction BFD session >>>> exists" to the ingress LSR. >>>> >>>> >>>> >>>> In the case of BFD session provisioned on both nodes in the Active >>>> mode, the LSP Ping for the backward direction BFD session could be >>>> received even when the forward direction session is not yet >>>> established. In that case is it correct to mention that the "Backward >>>> direction BFD session exists" as return code? >>>> >>>> >>>> Kindly let me know if I am missing something here... >>>> >>>> >>>> With Regards >>>> >>>> Mukund >>>> >>>> >>>> >> _______________________________________________ > mpls-tp mailing list > mpls-tp@ietf.org > https://www.ietf.org/mailman/listinfo/mpls-tp > --00c09f8e5c5122e919048823cbce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Mach,
I very much agree with your view that "It depends on how= you want each direction of a bidirectional LSP to be=20 operated [GIM>> perhaps "= protected" is closer] (independent or coordinated). If you want= each direction of the bidirectional LSP to be protected and switched independently, there=20 should be separate BFD session for each direction, or only one BFD=20 session is needed."
But I'd differ that associated and co-route= d bidirectional LSP should be viewed as the same construct. They certainly = may be viewed this way but I wouldn't see that as "should". I= f, for example, associated bidirectional LSP has assymetric BW for each dir= ection, it would might be reasonable to have two independent BFD sessions a= nd protect each direction independently. At the same time, bidirectional li= near LSP will always be co-routed and using independent BFD session for eac= h direction and independent protection doesn't seem practical.
And I agree that BFD control mechanism is needed. I think it can be part of= overall OAM control mechanism that is being worked on by CCAMP WG (I'v= e added the CCAMP to the discussion).

Best regards,
Greg

On Thu, Jun 3, 2010 at 2:49 AM, Mach Chen <mach@huawei.com&= gt; wrote:
Hi Mukund,

Please see inline...


--------------------------------------------------
From: "Mukund Mani" <mukund.mani@gmail.com>
Sent: Thursday, June 03, 2010 3:40 PM
To: <mach@huawei.co= m>; <rtg-bf= d@ietf.org>
Subject: Re: Query on draft-chen-mpls-bfd-enhancement-01
<= br>
Hi Mach

Maybe "BFD session set-up in progress" ??

Sounds better!



Also you mention: =A0"The case you described *maybe* occur"
As for me this will *always* occur if I configure both the ends in Active mode, because enabling BFD would initiate the LSP Ping for BFD bootstrap. Am I correct on this?

A node (with smart implementation) with lower IP address should not initiat= e the LSP Ping for BFD bootstrap for the LSP(s) if it has already received = an LSP Ping. So it depends on which end will firstly initiate the LSP Ping.=



On the whole I have had another question for quite some time which I have been asking in the MPLS-TP group also.
My question was w.r.t the draft-asm-mpls-tp-bfd-cc-cv-04 which defines CC/C= V
and RDI mechanism using BFD and relates the number of sessions to protectio= n
switching architectures. But I would like to co-relate the details here to<= br> have a clear understanding on the BFD operation itself...
I totally agree with you on this. Although protection switching is normally= based on BFD detection results, but, IMHO, the number of BFD sessions shou= ld not closely coupled with the protection switching types(e.g., 1:1,1+1...= ).



For co-routed bi-directional LSP the forward and reverse path will be
associated at the LER's. Also the same relationship exists for forward = and
reverse path of associated bi-directional LSP's in the LER's and th= e common
LSR's.
My understanding of co-routed bi-directional LSP is that it "associate= d" at all nodes(including LERs and LSRs) along the LSP.



So why cant I use this inherent relationship to decide whether to have a single or two BFD sessions for a bidirectional LSP?
I am not sure what's your meaning about the inherent relationship. Do y= ou suggest: one BFD session for co-routed bi-dir LSP and two BFD sessions f= or associated bi-dir LSP, or just one BFD session for bi-dir LSP (no matter= what co-routed or associated)?

For co-routed and associated bidirectional LSP, IMHO, they should be treate= d as the same construct. From the view of their clients, there is no differ= ence between the co-routed and associated bidirection LSP. Why there requir= es associated bidirectional LSP, that is becase there is no co-routed bidir= ectional LSP(e.g., the devices do support yet) and bidirectional LSPs are d= esired. Now that we have associated two unidirectional LSPs into one associ= ated bidirectional LSP, it is logically to treat it as a real bidirectional= LSP. That means, there should be no difference in protection switching bet= ween co-routed and associated bidrectional LSP.


Basically trying to figure out the need for the explicit mechanism
using Return Path TLV and Session Control TLV mentioned in the draft
"draft-chen-mpls-bfd-enhancement-01".
I agree that for a pair of Uni-directional LSP's, using Return Path and=
Session Control TLV might be useful but why do we need this for associated<= br> and co-routed LSP?

It depends on how you want each direction of a bidirectional LSP to be oper= ated (independent or coordinated). If you want each direction of the bidire= ctional LSP to be protected and switched independently, there should be sep= arate BFD session for each direction, or only one BFD session is needed.
In our draft, if the LSP is bidirectional(co-routed or associated), there i= s no need to carry the Return Path TLV, only Session Control TLV is require= d, which is used to control how many BFD sessions should be setup over the = LSP. IMHO, if we want the LSP could be operated either as independent or co= odinated, a BFD session control mechanism(using Session Control TLV or othe= r means(e.g., in MPLS-TP scenario, using a bit of GACh flag field)) is need= ed.

Best regards,
Mach



With Regards
Mukund

On Tue, Jun 1, 2010 at 3:03 PM, Mach Chen <mach@huawei.com> wrote:

Hi Mukund,

Sorry for the delay response!

The case you described maybe occur, and strictly speaking, it is not very accurate to mention that the "Backward direction BFD session exists&qu= ot; as
return code, how about "BFD session collision"? or do you have an= y other
suggestions?

Best regards,
Mach
--------------------------------------------------
From: "Mukund Mani" <mukund.mani@gmail.com>
Sent: Monday, May 31, 2010 3:04 AM
To: <rtg-bfd@ietf.= org>
Subject: Query on draft-chen-mpls-bfd-enhancement-01


Hi

Have a query w.r.t "draft-chen-mpls-bfd-enhancement-01". Could th= e draft
authors kindly clarify the same:

Section 4 on session establishment mentions the following:

If node with the larger IP receives LSP ping
message signaling BFD session with Session Control TLV, LSP ping
reply must be transmitted with "Backward direction BFD session
exists" to the ingress LSR.



In the case of BFD session provisioned on both nodes in the Active
mode, the LSP Ping for the backward direction BFD session could be
received even when the forward direction session is not yet
established. In that case is it correct to mention that the "Backward<= br> direction BFD session exists" as return code?


Kindly let me know if I am missing something here...


With Regards

Mukund



_______________________________________________
mpls-tp mailing list
mpls-tp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/mpls-tp

--00c09f8e5c5122e919048823cbce-- From mach@huawei.com Fri Jun 4 03:50:30 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2EBB83A6A63; Fri, 4 Jun 2010 03:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.565 X-Spam-Level: X-Spam-Status: No, score=-0.565 tagged_above=-999 required=5 tests=[AWL=-1.167, BAYES_50=0.001, J_CHICKENPOX_32=0.6, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOpSXs7ZNere; Fri, 4 Jun 2010 03:50:28 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 8CE403A698B; Fri, 4 Jun 2010 03:50:27 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3H00307KRO6F@szxga03-in.huawei.com>; Fri, 04 Jun 2010 18:50:12 +0800 (CST) Received: from m55527c ([10.110.98.169]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L3H00667KRNJ6@szxga03-in.huawei.com>; Fri, 04 Jun 2010 18:50:12 +0800 (CST) Date: Fri, 04 Jun 2010 18:50:11 +0800 From: Mach Chen In-reply-to: To: Greg Mirsky Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=original Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: <2303DFD3C2884F2DB7C194CA0C60367D@m55527c> Cc: Mukund Mani , rtg-bfd@ietf.org, ccamp@ietf.org, mpls-tp@ietf.org Subject: Re: [CCAMP] [mpls-tp] Query on draft-chen-mpls-bfd-enhancement-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Jun 2010 10:50:30 -0000 Dear Greg, Thanks for your response! Although co-routed bidirectional LSP may also has assymetric BW for each direction and be protected and swithed for each direction in theory, I basically agree with your analysis about co-routed bidirectional LSP, it does not seem practical, one direction of a co-routed bi-dir LSP broken, usually means the other direction of the LSP is broken too, and of cause the whole LSP is actually broken even if one direction may be OK. So requiring a co-routed bidirectional to be operated as a single entity is reasonable. What I mean they should be treated as the same construt is from the view of protection switching, now that it is called and used as a bidirectioanl LSP, it is resonalbe to be protected and switched as single LSP. But since an associated bi-dir LSP is combined with two different LSPs and each LSP has its own fate, when one LSP is broken, usually the other LSP is OK, and from the view of the whole associated bi-dir LSP, it is non-workable now and should be switched to another protection associated bi-dir LSP(if not, why we need to combine the two unidirectional LSP into a bidirectional LSP?). >From the view of fault localizaion and associated bi-dir LSP re-construction, we should better know which component LSP is broken, hence independent BFD session for each component LSP is necessary. Best regards, Mach -------------------------------------------------- From: "Greg Mirsky" Sent: Friday, June 04, 2010 1:47 AM To: "Mach Chen" Cc: "Mukund Mani" ; ; ; Subject: Re: [mpls-tp] Query on draft-chen-mpls-bfd-enhancement-01 > Dear Mach, > I very much agree with your view that "It depends on how you want each > direction of a bidirectional LSP to be operated [GIM>> perhaps "protected" > is closer] (independent or coordinated). If you want each direction of the > bidirectional LSP to be protected and switched independently, there should > be separate BFD session for each direction, or only one BFD session is > needed." > But I'd differ that associated and co-routed bidirectional LSP should be > viewed as the same construct. They certainly may be viewed this way but I > wouldn't see that as "should". If, for example, associated bidirectional > LSP > has assymetric BW for each direction, it would might be reasonable to have > two independent BFD sessions and protect each direction independently. At > the same time, bidirectional linear LSP will always be co-routed and using > independent BFD session for each direction and independent protection > doesn't seem practical. > And I agree that BFD control mechanism is needed. I think it can be part > of > overall OAM control mechanism that is being worked on by CCAMP WG (I've > added the CCAMP to the discussion). > > Best regards, > Greg > > On Thu, Jun 3, 2010 at 2:49 AM, Mach Chen wrote: > >> Hi Mukund, >> >> Please see inline... >> >> >> -------------------------------------------------- >> From: "Mukund Mani" >> Sent: Thursday, June 03, 2010 3:40 PM >> To: ; >> Subject: Re: Query on draft-chen-mpls-bfd-enhancement-01 >> >> >> Hi Mach >>> >>> Maybe "BFD session set-up in progress" ?? >>> >> >> Sounds better! >> >> >> >>> Also you mention: "The case you described *maybe* occur" >>> As for me this will *always* occur if I configure both the ends in >>> Active >>> mode, because enabling BFD would initiate the LSP Ping for BFD >>> bootstrap. >>> Am I correct on this? >>> >> >> A node (with smart implementation) with lower IP address should not >> initiate the LSP Ping for BFD bootstrap for the LSP(s) if it has already >> received an LSP Ping. So it depends on which end will firstly initiate >> the >> LSP Ping. >> >> >> >>> On the whole I have had another question for quite some time which I >>> have >>> been asking in the MPLS-TP group also. >>> My question was w.r.t the draft-asm-mpls-tp-bfd-cc-cv-04 which defines >>> CC/CV >>> and RDI mechanism using BFD and relates the number of sessions to >>> protection >>> switching architectures. But I would like to co-relate the details here >>> to >>> have a clear understanding on the BFD operation itself... >>> >> I totally agree with you on this. Although protection switching is >> normally >> based on BFD detection results, but, IMHO, the number of BFD sessions >> should >> not closely coupled with the protection switching types(e.g., >> 1:1,1+1...). >> >> >> >>> For co-routed bi-directional LSP the forward and reverse path will be >>> associated at the LER's. Also the same relationship exists for forward >>> and >>> reverse path of associated bi-directional LSP's in the LER's and the >>> common >>> LSR's. >>> >> My understanding of co-routed bi-directional LSP is that it "associated" >> at >> all nodes(including LERs and LSRs) along the LSP. >> >> >> >>> So why cant I use this inherent relationship to decide whether to have a >>> single or two BFD sessions for a bidirectional LSP? >>> >> I am not sure what's your meaning about the inherent relationship. Do you >> suggest: one BFD session for co-routed bi-dir LSP and two BFD sessions >> for >> associated bi-dir LSP, or just one BFD session for bi-dir LSP (no matter >> what co-routed or associated)? >> >> For co-routed and associated bidirectional LSP, IMHO, they should be >> treated as the same construct. From the view of their clients, there is >> no >> difference between the co-routed and associated bidirection LSP. Why >> there >> requires associated bidirectional LSP, that is becase there is no >> co-routed >> bidirectional LSP(e.g., the devices do support yet) and bidirectional >> LSPs >> are desired. Now that we have associated two unidirectional LSPs into one >> associated bidirectional LSP, it is logically to treat it as a real >> bidirectional LSP. That means, there should be no difference in >> protection >> switching between co-routed and associated bidrectional LSP. >> >> >> Basically trying to figure out the need for the explicit mechanism >>> using Return Path TLV and Session Control TLV mentioned in the draft >>> "draft-chen-mpls-bfd-enhancement-01". >>> I agree that for a pair of Uni-directional LSP's, using Return Path and >>> Session Control TLV might be useful but why do we need this for >>> associated >>> and co-routed LSP? >>> >> >> It depends on how you want each direction of a bidirectional LSP to be >> operated (independent or coordinated). If you want each direction of the >> bidirectional LSP to be protected and switched independently, there >> should >> be separate BFD session for each direction, or only one BFD session is >> needed. >> >> In our draft, if the LSP is bidirectional(co-routed or associated), there >> is no need to carry the Return Path TLV, only Session Control TLV is >> required, which is used to control how many BFD sessions should be setup >> over the LSP. IMHO, if we want the LSP could be operated either as >> independent or coodinated, a BFD session control mechanism(using Session >> Control TLV or other means(e.g., in MPLS-TP scenario, using a bit of GACh >> flag field)) is needed. >> >> Best regards, >> Mach >> >> >> >>> With Regards >>> Mukund >>> >>> On Tue, Jun 1, 2010 at 3:03 PM, Mach Chen wrote: >>> >>> Hi Mukund, >>>> >>>> Sorry for the delay response! >>>> >>>> The case you described maybe occur, and strictly speaking, it is not >>>> very >>>> accurate to mention that the "Backward direction BFD session exists" as >>>> return code, how about "BFD session collision"? or do you have any >>>> other >>>> suggestions? >>>> >>>> Best regards, >>>> Mach >>>> -------------------------------------------------- >>>> From: "Mukund Mani" >>>> Sent: Monday, May 31, 2010 3:04 AM >>>> To: >>>> Subject: Query on draft-chen-mpls-bfd-enhancement-01 >>>> >>>> >>>> Hi >>>> >>>>> >>>>> Have a query w.r.t "draft-chen-mpls-bfd-enhancement-01". Could the >>>>> draft >>>>> authors kindly clarify the same: >>>>> >>>>> Section 4 on session establishment mentions the following: >>>>> >>>>> If node with the larger IP receives LSP ping >>>>> message signaling BFD session with Session Control TLV, LSP ping >>>>> reply must be transmitted with "Backward direction BFD session >>>>> exists" to the ingress LSR. >>>>> >>>>> >>>>> >>>>> In the case of BFD session provisioned on both nodes in the Active >>>>> mode, the LSP Ping for the backward direction BFD session could be >>>>> received even when the forward direction session is not yet >>>>> established. In that case is it correct to mention that the "Backward >>>>> direction BFD session exists" as return code? >>>>> >>>>> >>>>> Kindly let me know if I am missing something here... >>>>> >>>>> >>>>> With Regards >>>>> >>>>> Mukund >>>>> >>>>> >>>>> >>> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >> > From mach@huawei.com Fri Jun 4 03:50:34 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 479143A6A63; Fri, 4 Jun 2010 03:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.479 X-Spam-Level: X-Spam-Status: No, score=0.479 tagged_above=-999 required=5 tests=[AWL=-1.627, BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8qjTkGWVTH7; Fri, 4 Jun 2010 03:50:31 -0700 (PDT) Received: from szxga05-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id A86D43A6A65; Fri, 4 Jun 2010 03:50:30 -0700 (PDT) Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3H00F0IKRT8Q@szxga05-in.huawei.com>; Fri, 04 Jun 2010 18:50:17 +0800 (CST) Received: from m55527c ([10.110.98.169]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L3H00EDZKRR1U@szxga05-in.huawei.com>; Fri, 04 Jun 2010 18:50:17 +0800 (CST) Date: Fri, 04 Jun 2010 18:50:15 +0800 From: Mach Chen In-reply-to: To: Mukund Mani , Greg Mirsky Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V14.0.8064.206 X-Mailer: Microsoft Windows Live Mail 14.0.8064.206 Content-type: text/plain; format=flowed; charset=ISO-8859-1; reply-type=original Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 X-MSMail-priority: Normal References: <2303DFD3C2884F2DB7C194CA0C60367D@m55527c> Cc: rtg-bfd@ietf.org, ccamp@ietf.org, mpls-tp@ietf.org Subject: Re: [CCAMP] [mpls-tp] Query on draft-chen-mpls-bfd-enhancement-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Jun 2010 10:50:34 -0000 Hi Mukund, Please see inline... -------------------------------------------------- From: "Mukund Mani" Sent: Friday, June 04, 2010 3:05 AM To: "Greg Mirsky" ; Cc: ; ; Subject: Re: [mpls-tp] Query on draft-chen-mpls-bfd-enhancement-01 > Hi Mach > > Thanks for the response.. So in that case the BFD session initiator shall > include the Session Control TLV in the Echo Request only when the > bidirectional LSP is to be protected in a co-ordinated fashion. Yes. > > You also mention in the draft that > > "If there is no Session Control TLV carried in the echo request, it's up > to > the egress LSR to decide whether to initiate another BFD session for the > backward direction LSP" > > Does this imply that when a Session Control TLV is not included by the > peer, > it can still end up in one BFD session?? (based on the egress LSR's > decision) There is one more sentence you did not quote: "..this is the same as the definition in [BFD-MPLS]." So, if there is no session Control TLV included, the procedure is same as current BFD for MPLS specification. The BFD session is only trigered by the configuration/policy at the egress, it does not relate to whether it received a LSP Ping bootstrap message. Best regards, Mach > > > > With Regards > Mukund > > On Thu, Jun 3, 2010 at 11:17 PM, Greg Mirsky > wrote: > >> Dear Mach, >> I very much agree with your view that "It depends on how you want each >> direction of a bidirectional LSP to be operated [GIM>> perhaps >> "protected" >> is closer] (independent or coordinated). If you want each direction of >> the >> bidirectional LSP to be protected and switched independently, there >> should >> be separate BFD session for each direction, or only one BFD session is >> needed." >> But I'd differ that associated and co-routed bidirectional LSP should be >> viewed as the same construct. They certainly may be viewed this way but I >> wouldn't see that as "should". If, for example, associated bidirectional >> LSP >> has assymetric BW for each direction, it would might be reasonable to >> have >> two independent BFD sessions and protect each direction independently. At >> the same time, bidirectional linear LSP will always be co-routed and >> using >> independent BFD session for each direction and independent protection >> doesn't seem practical. >> And I agree that BFD control mechanism is needed. I think it can be part >> of >> overall OAM control mechanism that is being worked on by CCAMP WG (I've >> added the CCAMP to the discussion). >> >> Best regards, >> Greg >> >> On Thu, Jun 3, 2010 at 2:49 AM, Mach Chen wrote: >> >>> Hi Mukund, >>> >>> Please see inline... >>> >>> >>> -------------------------------------------------- >>> From: "Mukund Mani" >>> Sent: Thursday, June 03, 2010 3:40 PM >>> To: ; >>> Subject: Re: Query on draft-chen-mpls-bfd-enhancement-01 >>> >>> >>> Hi Mach >>>> >>>> Maybe "BFD session set-up in progress" ?? >>>> >>> >>> Sounds better! >>> >>> >>> >>>> Also you mention: "The case you described *maybe* occur" >>>> As for me this will *always* occur if I configure both the ends in >>>> Active >>>> mode, because enabling BFD would initiate the LSP Ping for BFD >>>> bootstrap. >>>> Am I correct on this? >>>> >>> >>> A node (with smart implementation) with lower IP address should not >>> initiate the LSP Ping for BFD bootstrap for the LSP(s) if it has already >>> received an LSP Ping. So it depends on which end will firstly initiate >>> the >>> LSP Ping. >>> >>> >>> >>>> On the whole I have had another question for quite some time which I >>>> have >>>> been asking in the MPLS-TP group also. >>>> My question was w.r.t the draft-asm-mpls-tp-bfd-cc-cv-04 which defines >>>> CC/CV >>>> and RDI mechanism using BFD and relates the number of sessions to >>>> protection >>>> switching architectures. But I would like to co-relate the details here >>>> to >>>> have a clear understanding on the BFD operation itself... >>>> >>> I totally agree with you on this. Although protection switching is >>> normally based on BFD detection results, but, IMHO, the number of BFD >>> sessions should not closely coupled with the protection switching >>> types(e.g., 1:1,1+1...). >>> >>> >>> >>>> For co-routed bi-directional LSP the forward and reverse path will be >>>> associated at the LER's. Also the same relationship exists for forward >>>> and >>>> reverse path of associated bi-directional LSP's in the LER's and the >>>> common >>>> LSR's. >>>> >>> My understanding of co-routed bi-directional LSP is that it "associated" >>> at all nodes(including LERs and LSRs) along the LSP. >>> >>> >>> >>>> So why cant I use this inherent relationship to decide whether to have >>>> a >>>> single or two BFD sessions for a bidirectional LSP? >>>> >>> I am not sure what's your meaning about the inherent relationship. Do >>> you >>> suggest: one BFD session for co-routed bi-dir LSP and two BFD sessions >>> for >>> associated bi-dir LSP, or just one BFD session for bi-dir LSP (no matter >>> what co-routed or associated)? >>> >>> For co-routed and associated bidirectional LSP, IMHO, they should be >>> treated as the same construct. From the view of their clients, there is >>> no >>> difference between the co-routed and associated bidirection LSP. Why >>> there >>> requires associated bidirectional LSP, that is becase there is no >>> co-routed >>> bidirectional LSP(e.g., the devices do support yet) and bidirectional >>> LSPs >>> are desired. Now that we have associated two unidirectional LSPs into >>> one >>> associated bidirectional LSP, it is logically to treat it as a real >>> bidirectional LSP. That means, there should be no difference in >>> protection >>> switching between co-routed and associated bidrectional LSP. >>> >>> >>> Basically trying to figure out the need for the explicit mechanism >>>> using Return Path TLV and Session Control TLV mentioned in the draft >>>> "draft-chen-mpls-bfd-enhancement-01". >>>> I agree that for a pair of Uni-directional LSP's, using Return Path and >>>> Session Control TLV might be useful but why do we need this for >>>> associated >>>> and co-routed LSP? >>>> >>> >>> It depends on how you want each direction of a bidirectional LSP to be >>> operated (independent or coordinated). If you want each direction of the >>> bidirectional LSP to be protected and switched independently, there >>> should >>> be separate BFD session for each direction, or only one BFD session is >>> needed. >>> >>> In our draft, if the LSP is bidirectional(co-routed or associated), >>> there >>> is no need to carry the Return Path TLV, only Session Control TLV is >>> required, which is used to control how many BFD sessions should be setup >>> over the LSP. IMHO, if we want the LSP could be operated either as >>> independent or coodinated, a BFD session control mechanism(using Session >>> Control TLV or other means(e.g., in MPLS-TP scenario, using a bit of >>> GACh >>> flag field)) is needed. >>> >>> Best regards, >>> Mach >>> >>> >>> >>>> With Regards >>>> Mukund >>>> >>>> On Tue, Jun 1, 2010 at 3:03 PM, Mach Chen wrote: >>>> >>>> Hi Mukund, >>>>> >>>>> Sorry for the delay response! >>>>> >>>>> The case you described maybe occur, and strictly speaking, it is not >>>>> very >>>>> accurate to mention that the "Backward direction BFD session exists" >>>>> as >>>>> return code, how about "BFD session collision"? or do you have any >>>>> other >>>>> suggestions? >>>>> >>>>> Best regards, >>>>> Mach >>>>> -------------------------------------------------- >>>>> From: "Mukund Mani" >>>>> Sent: Monday, May 31, 2010 3:04 AM >>>>> To: >>>>> Subject: Query on draft-chen-mpls-bfd-enhancement-01 >>>>> >>>>> >>>>> Hi >>>>> >>>>>> >>>>>> Have a query w.r.t "draft-chen-mpls-bfd-enhancement-01". Could the >>>>>> draft >>>>>> authors kindly clarify the same: >>>>>> >>>>>> Section 4 on session establishment mentions the following: >>>>>> >>>>>> If node with the larger IP receives LSP ping >>>>>> message signaling BFD session with Session Control TLV, LSP ping >>>>>> reply must be transmitted with "Backward direction BFD session >>>>>> exists" to the ingress LSR. >>>>>> >>>>>> >>>>>> >>>>>> In the case of BFD session provisioned on both nodes in the Active >>>>>> mode, the LSP Ping for the backward direction BFD session could be >>>>>> received even when the forward direction session is not yet >>>>>> established. In that case is it correct to mention that the "Backward >>>>>> direction BFD session exists" as return code? >>>>>> >>>>>> >>>>>> Kindly let me know if I am missing something here... >>>>>> >>>>>> >>>>>> With Regards >>>>>> >>>>>> Mukund >>>>>> >>>>>> >>>>>> >>>> _______________________________________________ >>> mpls-tp mailing list >>> mpls-tp@ietf.org >>> https://www.ietf.org/mailman/listinfo/mpls-tp >>> >> >> > From mukund.mani@gmail.com Thu Jun 3 12:06:17 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBE6F3A6890; Thu, 3 Jun 2010 12:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LNJ3VPINSRCF; Thu, 3 Jun 2010 12:06:16 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 91F773A6359; Thu, 3 Jun 2010 12:06:15 -0700 (PDT) Received: by gyh4 with SMTP id 4so355143gyh.31 for ; Thu, 03 Jun 2010 12:05:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=1i0Ag8WpKmGhmzYeTjdwx3+/1/kPFeT3hRbc8R4a7uE=; b=IWeLYvfDkC3tFYsOUfZhOmIrXx+20+GkHTHV8qmaJ/aplVREH703TDHOMXjRmNP4bN 88feeLhCoMy18bObVPUtPNm5IVbExaxwx8qbqfN4pW89o3A3NVLLxr34Kkw6eLJqxYvh G6FV6YfUoTewrFgU30m5Y0sxk7NCIzLdjYvm0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=jKnOOdzsNM/FQLCAP8kfNfYYRH/MuZJEwm0AQS/8PgS0fOkkcVmBGFz9Z/8j7AMerx otPoi0Q+aEmAeFa6iaeGWIyrKnn8IS59i56QRo9T2wWuJgWFgLM3v3fSWD/KkAqBezQz OoWzRrhsjJnj6+vgmLQemZOAPORyE1L90x44c= MIME-Version: 1.0 Received: by 10.224.87.75 with SMTP id v11mr5098677qal.397.1275591957376; Thu, 03 Jun 2010 12:05:57 -0700 (PDT) Received: by 10.229.73.206 with HTTP; Thu, 3 Jun 2010 12:05:57 -0700 (PDT) In-Reply-To: References: <2303DFD3C2884F2DB7C194CA0C60367D@m55527c> Date: Fri, 4 Jun 2010 00:35:57 +0530 Message-ID: From: Mukund Mani To: Greg Mirsky , mach@huawei.com Content-Type: multipart/alternative; boundary=00c09f89980e8196f5048824e5a4 X-Mailman-Approved-At: Fri, 04 Jun 2010 04:53:37 -0700 Cc: rtg-bfd@ietf.org, ccamp@ietf.org, mpls-tp@ietf.org Subject: Re: [CCAMP] [mpls-tp] Query on draft-chen-mpls-bfd-enhancement-01 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 03 Jun 2010 19:06:18 -0000 --00c09f89980e8196f5048824e5a4 Content-Type: text/plain; charset=ISO-8859-1 Hi Mach Thanks for the response.. So in that case the BFD session initiator shall include the Session Control TLV in the Echo Request only when the bidirectional LSP is to be protected in a co-ordinated fashion. You also mention in the draft that "If there is no Session Control TLV carried in the echo request, it's up to the egress LSR to decide whether to initiate another BFD session for the backward direction LSP" Does this imply that when a Session Control TLV is not included by the peer, it can still end up in one BFD session?? (based on the egress LSR's decision) With Regards Mukund On Thu, Jun 3, 2010 at 11:17 PM, Greg Mirsky wrote: > Dear Mach, > I very much agree with your view that "It depends on how you want each > direction of a bidirectional LSP to be operated [GIM>> perhaps "protected" > is closer] (independent or coordinated). If you want each direction of the > bidirectional LSP to be protected and switched independently, there should > be separate BFD session for each direction, or only one BFD session is > needed." > But I'd differ that associated and co-routed bidirectional LSP should be > viewed as the same construct. They certainly may be viewed this way but I > wouldn't see that as "should". If, for example, associated bidirectional LSP > has assymetric BW for each direction, it would might be reasonable to have > two independent BFD sessions and protect each direction independently. At > the same time, bidirectional linear LSP will always be co-routed and using > independent BFD session for each direction and independent protection > doesn't seem practical. > And I agree that BFD control mechanism is needed. I think it can be part of > overall OAM control mechanism that is being worked on by CCAMP WG (I've > added the CCAMP to the discussion). > > Best regards, > Greg > > On Thu, Jun 3, 2010 at 2:49 AM, Mach Chen wrote: > >> Hi Mukund, >> >> Please see inline... >> >> >> -------------------------------------------------- >> From: "Mukund Mani" >> Sent: Thursday, June 03, 2010 3:40 PM >> To: ; >> Subject: Re: Query on draft-chen-mpls-bfd-enhancement-01 >> >> >> Hi Mach >>> >>> Maybe "BFD session set-up in progress" ?? >>> >> >> Sounds better! >> >> >> >>> Also you mention: "The case you described *maybe* occur" >>> As for me this will *always* occur if I configure both the ends in Active >>> mode, because enabling BFD would initiate the LSP Ping for BFD bootstrap. >>> Am I correct on this? >>> >> >> A node (with smart implementation) with lower IP address should not >> initiate the LSP Ping for BFD bootstrap for the LSP(s) if it has already >> received an LSP Ping. So it depends on which end will firstly initiate the >> LSP Ping. >> >> >> >>> On the whole I have had another question for quite some time which I have >>> been asking in the MPLS-TP group also. >>> My question was w.r.t the draft-asm-mpls-tp-bfd-cc-cv-04 which defines >>> CC/CV >>> and RDI mechanism using BFD and relates the number of sessions to >>> protection >>> switching architectures. But I would like to co-relate the details here >>> to >>> have a clear understanding on the BFD operation itself... >>> >> I totally agree with you on this. Although protection switching is >> normally based on BFD detection results, but, IMHO, the number of BFD >> sessions should not closely coupled with the protection switching >> types(e.g., 1:1,1+1...). >> >> >> >>> For co-routed bi-directional LSP the forward and reverse path will be >>> associated at the LER's. Also the same relationship exists for forward >>> and >>> reverse path of associated bi-directional LSP's in the LER's and the >>> common >>> LSR's. >>> >> My understanding of co-routed bi-directional LSP is that it "associated" >> at all nodes(including LERs and LSRs) along the LSP. >> >> >> >>> So why cant I use this inherent relationship to decide whether to have a >>> single or two BFD sessions for a bidirectional LSP? >>> >> I am not sure what's your meaning about the inherent relationship. Do you >> suggest: one BFD session for co-routed bi-dir LSP and two BFD sessions for >> associated bi-dir LSP, or just one BFD session for bi-dir LSP (no matter >> what co-routed or associated)? >> >> For co-routed and associated bidirectional LSP, IMHO, they should be >> treated as the same construct. From the view of their clients, there is no >> difference between the co-routed and associated bidirection LSP. Why there >> requires associated bidirectional LSP, that is becase there is no co-routed >> bidirectional LSP(e.g., the devices do support yet) and bidirectional LSPs >> are desired. Now that we have associated two unidirectional LSPs into one >> associated bidirectional LSP, it is logically to treat it as a real >> bidirectional LSP. That means, there should be no difference in protection >> switching between co-routed and associated bidrectional LSP. >> >> >> Basically trying to figure out the need for the explicit mechanism >>> using Return Path TLV and Session Control TLV mentioned in the draft >>> "draft-chen-mpls-bfd-enhancement-01". >>> I agree that for a pair of Uni-directional LSP's, using Return Path and >>> Session Control TLV might be useful but why do we need this for >>> associated >>> and co-routed LSP? >>> >> >> It depends on how you want each direction of a bidirectional LSP to be >> operated (independent or coordinated). If you want each direction of the >> bidirectional LSP to be protected and switched independently, there should >> be separate BFD session for each direction, or only one BFD session is >> needed. >> >> In our draft, if the LSP is bidirectional(co-routed or associated), there >> is no need to carry the Return Path TLV, only Session Control TLV is >> required, which is used to control how many BFD sessions should be setup >> over the LSP. IMHO, if we want the LSP could be operated either as >> independent or coodinated, a BFD session control mechanism(using Session >> Control TLV or other means(e.g., in MPLS-TP scenario, using a bit of GACh >> flag field)) is needed. >> >> Best regards, >> Mach >> >> >> >>> With Regards >>> Mukund >>> >>> On Tue, Jun 1, 2010 at 3:03 PM, Mach Chen wrote: >>> >>> Hi Mukund, >>>> >>>> Sorry for the delay response! >>>> >>>> The case you described maybe occur, and strictly speaking, it is not >>>> very >>>> accurate to mention that the "Backward direction BFD session exists" as >>>> return code, how about "BFD session collision"? or do you have any other >>>> suggestions? >>>> >>>> Best regards, >>>> Mach >>>> -------------------------------------------------- >>>> From: "Mukund Mani" >>>> Sent: Monday, May 31, 2010 3:04 AM >>>> To: >>>> Subject: Query on draft-chen-mpls-bfd-enhancement-01 >>>> >>>> >>>> Hi >>>> >>>>> >>>>> Have a query w.r.t "draft-chen-mpls-bfd-enhancement-01". Could the >>>>> draft >>>>> authors kindly clarify the same: >>>>> >>>>> Section 4 on session establishment mentions the following: >>>>> >>>>> If node with the larger IP receives LSP ping >>>>> message signaling BFD session with Session Control TLV, LSP ping >>>>> reply must be transmitted with "Backward direction BFD session >>>>> exists" to the ingress LSR. >>>>> >>>>> >>>>> >>>>> In the case of BFD session provisioned on both nodes in the Active >>>>> mode, the LSP Ping for the backward direction BFD session could be >>>>> received even when the forward direction session is not yet >>>>> established. In that case is it correct to mention that the "Backward >>>>> direction BFD session exists" as return code? >>>>> >>>>> >>>>> Kindly let me know if I am missing something here... >>>>> >>>>> >>>>> With Regards >>>>> >>>>> Mukund >>>>> >>>>> >>>>> >>> _______________________________________________ >> mpls-tp mailing list >> mpls-tp@ietf.org >> https://www.ietf.org/mailman/listinfo/mpls-tp >> > > --00c09f89980e8196f5048824e5a4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Mach

Thanks for the response.. So in that case t= he BFD session initiator shall include the Session Control TLV in the Echo = Request only when the bidirectional LSP is to be protected in a co-ordinate= d fashion.=A0

You also mention in the draft that=A0

&quo= t;If there is no Session Control TLV car= ried in the echo request, it's up to the egress LSR to decide whether to initiate another BFD session for the b= ackward direction LSP"

=
Does this imply that when a Session Control TLV is= not included by the peer, it can still end up in one BFD session?? (based = on the egress LSR's decision)



With Regards
Mukund

On Thu, Jun 3, 2010 at 11:17 PM, Greg Mirsky <gregimirsky@gmail.com>= ; wrote:
Dear Mach,
I very much agree with your v= iew that "It depends on how you want each direction of a bidirectional= LSP to be=20 operated [GIM>> perhaps "pr= otected" is closer] (independent or coordinated). If you want e= ach direction of the bidirectional LSP to be protected and switched independently, there=20 should be separate BFD session for each direction, or only one BFD=20 session is needed."
But I'd differ that associated and co-route= d bidirectional LSP should be viewed as the same construct. They certainly = may be viewed this way but I wouldn't see that as "should". I= f, for example, associated bidirectional LSP has assymetric BW for each dir= ection, it would might be reasonable to have two independent BFD sessions a= nd protect each direction independently. At the same time, bidirectional li= near LSP will always be co-routed and using independent BFD session for eac= h direction and independent protection doesn't seem practical.
And I agree that BFD control mechanism is needed. I think it can be part of= overall OAM control mechanism that is being worked on by CCAMP WG (I'v= e added the CCAMP to the discussion).

Best regards,
Greg

On Thu, Ju= n 3, 2010 at 2:49 AM, Mach Chen <mach@huawei.com> wrote:
Hi Mukund,

Please see inline...


--------------------------------------------------
From: "Mukund Mani" <mukund.mani@gmail.com>
Sent: Thursday, June 03, 2010 3:40 PM
To: <mach@huawei.co= m>; <rtg-bf= d@ietf.org>
Subject: Re: Query on draft-chen-mpls-bfd-enhancement-01


Hi Mach

Maybe "BFD session set-up in progress" ??

Sounds better!



Also you mention: =A0"The case you described *maybe* occur"
As for me this will *always* occur if I configure both the ends in Active mode, because enabling BFD would initiate the LSP Ping for BFD bootstrap. Am I correct on this?

A node (with smart implementation) with lower IP address should not initiat= e the LSP Ping for BFD bootstrap for the LSP(s) if it has already received = an LSP Ping. So it depends on which end will firstly initiate the LSP Ping.=



On the whole I have had another question for quite some time which I have been asking in the MPLS-TP group also.
My question was w.r.t the draft-asm-mpls-tp-bfd-cc-cv-04 which defines CC/C= V
and RDI mechanism using BFD and relates the number of sessions to protectio= n
switching architectures. But I would like to co-relate the details here to<= br> have a clear understanding on the BFD operation itself...
I totally agree with you on this. Although protection switching is normally= based on BFD detection results, but, IMHO, the number of BFD sessions shou= ld not closely coupled with the protection switching types(e.g., 1:1,1+1...= ).



For co-routed bi-directional LSP the forward and reverse path will be
associated at the LER's. Also the same relationship exists for forward = and
reverse path of associated bi-directional LSP's in the LER's and th= e common
LSR's.
My understanding of co-routed bi-directional LSP is that it "associate= d" at all nodes(including LERs and LSRs) along the LSP.



So why cant I use this inherent relationship to decide whether to have a single or two BFD sessions for a bidirectional LSP?
I am not sure what's your meaning about the inherent relationship. Do y= ou suggest: one BFD session for co-routed bi-dir LSP and two BFD sessions f= or associated bi-dir LSP, or just one BFD session for bi-dir LSP (no matter= what co-routed or associated)?

For co-routed and associated bidirectional LSP, IMHO, they should be treate= d as the same construct. From the view of their clients, there is no differ= ence between the co-routed and associated bidirection LSP. Why there requir= es associated bidirectional LSP, that is becase there is no co-routed bidir= ectional LSP(e.g., the devices do support yet) and bidirectional LSPs are d= esired. Now that we have associated two unidirectional LSPs into one associ= ated bidirectional LSP, it is logically to treat it as a real bidirectional= LSP. That means, there should be no difference in protection switching bet= ween co-routed and associated bidrectional LSP.


Basically trying to figure out the need for the explicit mechanism
using Return Path TLV and Session Control TLV mentioned in the draft
"draft-chen-mpls-bfd-enhancement-01".
I agree that for a pair of Uni-directional LSP's, using Return Path and=
Session Control TLV might be useful but why do we need this for associated<= br> and co-routed LSP?

It depends on how you want each direction of a bidirectional LSP to be oper= ated (independent or coordinated). If you want each direction of the bidire= ctional LSP to be protected and switched independently, there should be sep= arate BFD session for each direction, or only one BFD session is needed.
In our draft, if the LSP is bidirectional(co-routed or associated), there i= s no need to carry the Return Path TLV, only Session Control TLV is require= d, which is used to control how many BFD sessions should be setup over the = LSP. IMHO, if we want the LSP could be operated either as independent or co= odinated, a BFD session control mechanism(using Session Control TLV or othe= r means(e.g., in MPLS-TP scenario, using a bit of GACh flag field)) is need= ed.

Best regards,
Mach



With Regards
Mukund

On Tue, Jun 1, 2010 at 3:03 PM, Mach Chen <mach@huawei.com> wrote:

Hi Mukund,

Sorry for the delay response!

The case you described maybe occur, and strictly speaking, it is not very accurate to mention that the "Backward direction BFD session exists&qu= ot; as
return code, how about "BFD session collision"? or do you have an= y other
suggestions?

Best regards,
Mach
--------------------------------------------------
From: "Mukund Mani" <mukund.mani@gmail.com>
Sent: Monday, May 31, 2010 3:04 AM
To: <rtg-bfd@ietf.= org>
Subject: Query on draft-chen-mpls-bfd-enhancement-01


Hi

Have a query w.r.t "draft-chen-mpls-bfd-enhancement-01". Could th= e draft
authors kindly clarify the same:

Section 4 on session establishment mentions the following:

If node with the larger IP receives LSP ping
message signaling BFD session with Session Control TLV, LSP ping
reply must be transmitted with "Backward direction BFD session
exists" to the ingress LSR.



In the case of BFD session provisioned on both nodes in the Active
mode, the LSP Ping for the backward direction BFD session could be
received even when the forward direction session is not yet
established. In that case is it correct to mention that the "Backward<= br> direction BFD session exists" as return code?


Kindly let me know if I am missing something here...


With Regards

Mukund



_______________________________________________
mpls-tp mailing list
mpls-tp@ietf.org<= br> https://www.ietf.org/mailman/listinfo/mpls-tp


--00c09f89980e8196f5048824e5a4-- From lberger@labn.net Fri Jun 4 04:54:17 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE3B13A6979 for ; Fri, 4 Jun 2010 04:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.696 X-Spam-Level: X-Spam-Status: No, score=-1.696 tagged_above=-999 required=5 tests=[AWL=1.969, BAYES_50=0.001, GB_I_INVITATION=-2, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id acB2vKEuVEjj for ; Fri, 4 Jun 2010 04:54:16 -0700 (PDT) Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id 8F7F53A691F for ; Fri, 4 Jun 2010 04:54:16 -0700 (PDT) Received: (qmail 20341 invoked by uid 0); 4 Jun 2010 11:54:03 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 4 Jun 2010 11:54:03 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=aVTPDYmDU5qNNkvq7eWDVJmiIw7V8rNzWzO73kHu2kolWIbHIbbzkLy0ywnGHowl8uWhLOPMEQV5olmzT16BR9vjCKu60tKftDtwxKuJpKuiv7Q56qcE+NDuqghDWBQ9; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OKVTO-0002g0-S3 for ccamp@ietf.org; Fri, 04 Jun 2010 05:54:03 -0600 Message-ID: <4C08E95E.3090809@labn.net> Date: Fri, 04 Jun 2010 07:54:06 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100301 Eudora/3.0.1 MIME-Version: 1.0 To: CCAMP Content-Type: text/plain; charset=utf-8; format=flowed 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] Fwd: IETF 78 - Meeting and Sponsorship Information X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 04 Jun 2010 11:54:17 -0000 -------- Original Message -------- Subject: IETF 78 - Meeting and Sponsorship Information Date: Thu, 3 Jun 2010 12:51:40 -0700 (PDT) From: IETF Secretariat To: Working Group Chairs Working Group Chairs, Can you please forward this message to your individual working group emails lists. We want to ensure that as many people as possible are aware of the sponsorship opportunities available at IETF meetings. Thank you. ========================================== 78th IETF Meeting Maastricht, Netherlands July 25-30, 2010 1. Sponsorship Opportunities 2. Registration Types 3. Visas and Letters of Invitation 4. Accommodations & Breakfast Information 5. IETF 79 (Beijing) Visa Information 1) Sponsorship Opportunities There are still sponsorship opportunities and benefits for high profile company/organizational exposure at the upcoming IETF meeting in Maastricht, Netherlands from July 25-30, 2010. All sponsorship fees go directly to fund the operations of the IETF. See the options at: http://www.ietf.org/meeting/78/index.html “Sponsorship Opportunities” under “General”. Each of the sponsorship options provide extended and repeat exposure at this weeklong meeting. Please contact Drew Dvorshak, dvorshak@isoc.org, with any questions and/or to reserve your organization’s spot. Thanks in advance for supporting the critical work of the IETF! 2) Register online at: http://www.ietf.org/meetings/78/ 3) Letters of Invitation and Visas Letters of Invitation After you complete the meeting registration process, you will be given the option to request a letter of invitation. You can request the Letter of Invitation as soon as you finish registration, or at a later time by following the link provided in the confirmation email. Visas Please check the Netherlands Ministry of Foreign Affairs site (http://www.minbuza.nl/en/Services/Consular_Services/Visa) for list of countries with visa exemptions. We recommend you give yourself at least one month to complete the visa process. 4) Accommodations & Breakfast Information http://www.ietf.org/meeting/78/hotel.html 5) If you want to start planning for your trip to IETF 79 in Beijing, we have visa information online here: http://www.ietf.org/meeting/79/visa.html Only 52 days until IETF 78! From wwwrun@core3.amsl.com Tue Jun 8 07:39:44 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 6363628C1C0; Tue, 8 Jun 2010 07:39:44 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100608143944.6363628C1C0@core3.amsl.com> Date: Tue, 8 Jun 2010 07:39:44 -0700 (PDT) Cc: ccamp mailing list , Internet Architecture Board , ccamp chair , RFC Editor Subject: [CCAMP] Protocol Action: 'Ethernet Traffic Parameters' to Proposed Standard X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 08 Jun 2010 14:39:44 -0000 The IESG has approved the following document: - 'Ethernet Traffic Parameters ' as a Proposed Standard This document is the product of the Common Control and Measurement Plane Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet-traffic-parameters-10.txt Technical Summary This document describes the support of Metro Ethernet Forum (MEF) Ethernet Traffic Parameters as described in MEF10.1 when using Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling. Working Group Summary Nothing to report. Document Quality There are no known implementations, but it is expected that several vendors plan to implement. Personnel Deborah Brungard (db3546@att.com) is the Document Shepherd. Adrian Farrel (adrian.farrel@huawei.com) is the Responsible AD RFC Editor Note RFC Editor - we suggest that you treat this I-D as part of a cluster including the following five documents. draft-ietf-ccamp-ethernet-traffic-parameters draft-ietf-ccamp-gmpls-dcsc-channel-ext draft-ietf-ccamp-gmpls-ether-svcs draft-ietf-ccamp-gmpls-mef-uni draft-ietf-ccamp-gmpls-mln-extensions --- Section 4 - Switching Granularity OLD Values 0 through 239, and 255 are assigned by IANA via IETF Standards Action. Value 255 is reserved by the present document. NEW Values 0 to 2 are specified by the present document. Values 3 through 239 are to be assigned by IANA via Standards Action [RFC5226]. Value 255 is reserved by the present document (its Length is to be determined by the RFC that will specify it). --- Section 4 - TLV (Type-Length-Value) OLD Type: 16 bits Defined values are: Type Length Format Description ------------------------------------------------------ 0 TBD Reserved Reserved value 1 TBD Reserved Reserved value 2 24 see Section 3.1 Ethernet Bandwidth Profile [MEF10.1] 3 8 [GMPLS-ESVCS] Layer 2 Control Processing (L2CP) 255 TBD Reserved Reserved value Values 0 through 239, and 255 are assigned by IANA via IETF Standards Action. Values 0 and 255 are reserved by the present document. NEW Type: 16 bits Defined values are: Type Length Format Description ------------------------------------------------------ 0 - Reserved Reserved value 1 - Reserved Reserved value 2 24 see Section 3.1 Ethernet Bandwidth Profile [MEF10.1] 3 8 [GMPLS-ESVCS] Layer 2 Control Processing (L2CP) 255 - Reserved Reserved value Values 0, 1, and 255 are reserved by the present document. Values 2, and 3 are specified by the present document. Values 4 through 239 are to be assigned by IANA via Standards Action [RFC5226]. --- Section 4.1 OLD The Flag 2 (CM) indicates whether the color-aware or color- blind property is employed by the bandwidth profile. When Flag 2 is set to value 0 (1), the bandwidth profile algorithm is said to be in color blind (color aware) mode. NEW The Flag 2 (CM) indicates whether the color-aware or color- blind property [MEF10.2] is employed by the bandwidth profile. When Flag 2 is set to value 0 (1), the bandwidth profile algorithm is said to be in color blind (color aware) mode. --- Section 8 OLD This document introduces no new security considerations to either [RFC3473]. NEW This document introduces no new security considerations to [RFC3473]. --- Sections 11.1 and 11.2 Move from 11.2 to 11.1 (i.e. become a normative reference) [MEF10.1] The MEF Technical Specification, "Ethernet Services Attributes Phase 2", MEF 10.1, November 2006. --- Section 11.2 ADD [MEF10.2] The MEF Technical Specification, "Ethernet Services Attributes Phase 2", MEF 10.2, October 2009. From gregb@grotto-networking.com Wed Jun 9 11:54:52 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B5C13A6783 for ; Wed, 9 Jun 2010 11:54:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oajqXf6pQ0N for ; Wed, 9 Jun 2010 11:54:50 -0700 (PDT) Received: from mail32c40.carrierzone.com (mail32c40.carrierzone.com [209.235.156.172]) by core3.amsl.com (Postfix) with ESMTP id 902563A676A for ; Wed, 9 Jun 2010 11:54:50 -0700 (PDT) X-Authenticated-User: gregb.grotto-networking.com Received: from [192.168.0.131] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133]) (authenticated bits=0) by mail32c40.carrierzone.com (8.13.6/8.13.1) with ESMTP id o59Ismvl020542 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 9 Jun 2010 14:54:51 -0400 Message-ID: <4C0FE37A.1000106@grotto-networking.com> Date: Wed, 09 Jun 2010 11:54:50 -0700 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: CCAMP Content-Type: multipart/alternative; boundary="------------050605090906070500030305" Subject: [CCAMP] WSON document status and next steps... X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 09 Jun 2010 18:54:52 -0000 This is a multi-part message in MIME format. --------------050605090906070500030305 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi CCAMPers interested in WSON, it's been about three years since the WSON enhancements to GMPLS got started. The non-impairment related WSON drafts have been fairly stable for some time. Here is the status and recommended next steps to the best of the authors knowledge: *Document Title * *File Link* *Last Update* *Next Steps* Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) draft-ietf-ccamp-rwa-wson-framework-06 2010-04-07 Last call finished, CCAMP chairs processing Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks draft-ietf-ccamp-rwa-info-07 2010-02-18 *Ready for last call.* General Network Element Constraint Encoding for GMPLS Controlled Networks draft-ietf-ccamp-general-constraint-encode-01 2010-03-02 *Ready for last call.* Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks draft-ietf-ccamp-rwa-wson-encode-04 2010-02-18 *Ready for last call.* As you can see /there are three drafts that the authors consider ready for last call and would like to proceed/. Please send comments, questions, or concerns about the above drafts (excluding Framework) to the list so we can discuss prior to IETF-78 in Maastrich. Per working group agreement the documents flow from general/abstract to more specific any issues should be addressed at the highest level of abstraction possible rather than the lowest, i.e., info model first, then encoding drafts, then protocol specific drafts. The most specific being the following two OSPF protocol related drafts: Document Title File Link Last Update Next Steps OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks draft-ietf-ccamp-wson-signal-compatibility-ospf-01 2010-03-05 Will be ready for last call after the RWA WSON encode OSPF Extensions in Support of Routing and Wavelength Assignment (RWA) in Wavelength Switched Optical Networks (WSONs) draft-zhang-ccamp-rwa-wson-routing-ospf-03 2010-03-04 Individual draft aligned with General Constraint Encoding. *Ready to be a WG draft* It should be noted that draft-ietf-ccamp-rwa-wson-encode-04 provides a robust and efficient modeling of regeneration (OEO) and other processing pools within an optical switch or ROADM. More extensive examples of the modeling power are available in the document http://www.grotto-networking.com/sites/default/files/ModelingSwitchesConvertersRegensV02f.pdf which provides better graphics than available via ASCII and extended discussion not usually part of an IETF document. Please review the WG draft and bring any issues to the CCAMP list if you feel you've found a situation that cannot be adequately modeled with these existing mechanisms. From the minutes of the IETF-77 Anaheim meeting there was an issue on "directionless ROADMs". This turns out to be a terminology issue. Directionless ROADMs are those whose add/drop ports are not bound to a particular line side ingress/egress port. These are also known as "add per node" ROADMs to be distinguished from "add per port" ROADMs. Though the terminology is not standardized these ROADMs are well (and easily) modeled via the techniques in the framework and an example is illustrated in Figure 2 of the WSON framework document. Best Regards Greg B. and WSON co-authors -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------050605090906070500030305 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi CCAMPers interested in WSON, it's been about three years since the WSON enhancements to GMPLS got started. The non-impairment related WSON drafts have been fairly stable for some time. Here is the status and recommended next steps to the best of the authors knowledge:

Document Title
 File Link
 Last Update
 Next Steps
Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON)
 draft-ietf-ccamp-rwa-wson-framework-06 2010-04-07
 Last call finished, CCAMP chairs processing
Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks
 draft-ietf-ccamp-rwa-info-07 2010-02-18
 Ready for last call.
General Network Element Constraint Encoding for GMPLS Controlled Networks
 draft-ietf-ccamp-general-constraint-encode-01 2010-03-02
 Ready for last call.
Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks
 draft-ietf-ccamp-rwa-wson-encode-04 2010-02-18
 Ready for last call.

As you can see there are three drafts that the authors consider ready for last call and would like to proceed. Please send comments, questions, or concerns about the above drafts (excluding Framework) to the list so we can discuss prior to IETF-78 in Maastrich. Per working group agreement the documents flow from general/abstract to more specific any issues should be addressed at the highest level of abstraction possible rather than the lowest, i.e., info model first, then encoding drafts, then protocol specific drafts.

The most specific being the following two OSPF protocol related drafts:

Document Title
 File Link
 Last Update
 Next Steps
OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks
 draft-ietf-ccamp-wson-signal-compatibility-ospf-01 2010-03-05
 Will be ready for last call after the RWA WSON encode
OSPF Extensions in Support of Routing and Wavelength Assignment (RWA) in Wavelength Switched Optical Networks (WSONs)
 draft-zhang-ccamp-rwa-wson-routing-ospf-03 2010-03-04
 Individual draft aligned with General Constraint Encoding. Ready to be a WG draft

It should be noted that draft-ietf-ccamp-rwa-wson-encode-04 provides a robust and efficient modeling of regeneration (OEO) and other processing pools within an optical switch or ROADM. More extensive examples of the modeling power are available in the document http://www.grotto-networking.com/sites/default/files/ModelingSwitchesConvertersRegensV02f.pdf which provides better graphics than available via ASCII and extended discussion not usually part of an IETF document. Please review the WG draft and bring any issues to the CCAMP list if you feel you've found a situation that cannot be adequately modeled with these existing mechanisms.

>From the minutes of the IETF-77 Anaheim meeting there was an issue on "directionless ROADMs". This turns out to be a terminology issue. Directionless ROADMs are those whose add/drop ports are not bound to a particular line side ingress/egress port. These are also known as "add per node" ROADMs to be distinguished from "add per port" ROADMs. Though the terminology is not standardized these ROADMs are well (and easily) modeled via the techniques in the framework and an example is illustrated in  Figure 2 of the WSON framework document.

Best Regards

Greg B. and  WSON co-authors
-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------050605090906070500030305-- From lberger@labn.net Wed Jun 9 12:07:27 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 239E63A6768 for ; Wed, 9 Jun 2010 12:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lB7xkS3xW8wo for ; Wed, 9 Jun 2010 12:07:26 -0700 (PDT) Received: from cpoproxy2-pub.bluehost.com (cpoproxy2-pub.bluehost.com [67.222.39.38]) by core3.amsl.com (Postfix) with SMTP id 02B783A6359 for ; Wed, 9 Jun 2010 12:07:25 -0700 (PDT) Received: (qmail 21678 invoked by uid 0); 9 Jun 2010 19:07:27 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy2.bluehost.com with SMTP; 9 Jun 2010 19:07:27 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=kE1piPWP29BKQtAkkPMV8eWx7NLPzBFef1kAyKgM8M9hqi5asvGMBKAZ+IUPOBm/nQqKDy3pQNx0598hx+ha6uyCqS7Bck++rhkGups9+9P5TUKaJ2lrWbFAKZ1m9bkT; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OMQcZ-0003VE-Js; Wed, 09 Jun 2010 13:07:27 -0600 Message-ID: <4C0FE670.1060900@labn.net> Date: Wed, 09 Jun 2010 15:07:28 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100301 Eudora/3.0.1 MIME-Version: 1.0 To: Greg Bernstein References: <4C0FE37A.1000106@grotto-networking.com> In-Reply-To: <4C0FE37A.1000106@grotto-networking.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Re: [CCAMP] WSON document status and next steps... X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 09 Jun 2010 19:07:27 -0000 Greg/Young, Glad to see that you're still focused on getting these documents through the WG. In Anaheim we had an off-line discussion about another revision of the (generic) encoding related documents. Are you you saying that you no longer think this revision is needed? What happened to address the discussed points? Much thanks, Lou On 6/9/2010 2:54 PM, Greg Bernstein wrote: > General Network Element Constraint Encoding for GMPLS Controlled Networks > draft-ietf-ccamp-general-constraint-encode-01 > > 2010-03-02 > *Ready for last call.* > Routing and Wavelength Assignment Information Encoding for Wavelength > Switched Optical Networks > draft-ietf-ccamp-rwa-wson-encode-04 > > 2010-02-18 > *Ready for last call.* > From ylee@huawei.com Wed Jun 9 18:28:27 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89BCC3A69C6 for ; Wed, 9 Jun 2010 18:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F4roaXPA5+Il for ; Wed, 9 Jun 2010 18:28:26 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id B621F3A69C3 for ; Wed, 9 Jun 2010 18:28:26 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3R00HL4YRGI7@usaga03-in.huawei.com> for ccamp@ietf.org; Wed, 09 Jun 2010 20:28:28 -0500 (CDT) Received: from L73682 (p4032-ipngn501marunouchi.tokyo.ocn.ne.jp [114.158.115.32]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L3R00C6JYRDVP@usaga03-in.huawei.com> for ccamp@ietf.org; Wed, 09 Jun 2010 20:28:28 -0500 (CDT) Date: Wed, 09 Jun 2010 20:28:16 -0500 From: Young Lee In-reply-to: <4C0FE670.1060900@labn.net> To: 'Lou Berger' , 'Greg Bernstein' Message-id: <005601cb083c$34e146b0$1201a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcsIBxrxWkAM9B3HS1O4UKXp2UNjAAANJ4eA References: <4C0FE37A.1000106@grotto-networking.com> <4C0FE670.1060900@labn.net> Cc: 'CCAMP' Subject: Re: [CCAMP] WSON document status and next steps... X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 10 Jun 2010 01:28:27 -0000 Hi Lou, We have just updated the generic constraint encoding draft per our discussion in the 77th IETF. We cleaned up all wson specific terminology and added a few texts to generalize the requirements. With this updated version, co-authors of this draft believe it is ready for working group last call. http://www.ietf.org/id/draft-ietf-ccamp-general-constraint-encode-02.txt Thanks. Young -----Original Message----- From: Lou Berger [mailto:lberger@labn.net] Sent: Wednesday, June 09, 2010 2:07 PM To: Greg Bernstein Cc: CCAMP; Young Lee Subject: Re: [CCAMP] WSON document status and next steps... Greg/Young, Glad to see that you're still focused on getting these documents through the WG. In Anaheim we had an off-line discussion about another revision of the (generic) encoding related documents. Are you you saying that you no longer think this revision is needed? What happened to address the discussed points? Much thanks, Lou On 6/9/2010 2:54 PM, Greg Bernstein wrote: > General Network Element Constraint Encoding for GMPLS Controlled Networks > draft-ietf-ccamp-general-constraint-encode-01 > > 2010-03-02 > *Ready for last call.* > Routing and Wavelength Assignment Information Encoding for Wavelength > Switched Optical Networks > draft-ietf-ccamp-rwa-wson-encode-04 > > 2010-02-18 > *Ready for last call.* > From root@core3.amsl.com Wed Jun 9 18:30:02 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 74DF428C11F; Wed, 9 Jun 2010 18:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100610013002.74DF428C11F@core3.amsl.com> Date: Wed, 9 Jun 2010 18:30:01 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-general-constraint-encode-02.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 10 Jun 2010 01:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : General Network Element Constraint Encoding for GMPLS Controlled Networks Author(s) : G. Bernstein, et al. Filename : draft-ietf-ccamp-general-constraint-encode-02.txt Pages : 28 Date : 2010-06-09 Generalized Multiprotocol Label Switching can be used to control a wide variety of technologies. In some of these technologies network elements and links may impose additional routing constraints such as asymmetric switch connectivity, non-local label assignment, and label range limitations on links. This document provides efficient, protocol-agnostic encodings for general information elements representing connectivity and label constraints as well as label availability. It is intended that protocol-specific documents will reference this memo to describe how information is carried for specific uses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-general-constraint-encode-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-general-constraint-encode-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-09182425.I-D@ietf.org> --NextPart-- From ylee@huawei.com Wed Jun 9 19:12:39 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 984393A68EE for ; Wed, 9 Jun 2010 19:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.299, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7zS879P5OFrb for ; Wed, 9 Jun 2010 19:12:31 -0700 (PDT) Received: from usaga01-in.huawei.com (usaga01-in.huawei.com [206.16.17.211]) by core3.amsl.com (Postfix) with ESMTP id 6005B3A6889 for ; Wed, 9 Jun 2010 19:12:31 -0700 (PDT) Received: from huawei.com (usaga01-in [172.18.4.6]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3S00HW00SWTW@usaga01-in.huawei.com> for ccamp@ietf.org; Wed, 09 Jun 2010 19:12:33 -0700 (PDT) Received: from L73682 (p4032-ipngn501marunouchi.tokyo.ocn.ne.jp [114.158.115.32]) by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L3S00FOB0SUGQ@usaga01-in.huawei.com> for ccamp@ietf.org; Wed, 09 Jun 2010 19:12:32 -0700 (PDT) Date: Wed, 09 Jun 2010 21:12:20 -0500 From: Young Lee In-reply-to: <4C0FE37A.1000106@grotto-networking.com> To: 'CCAMP' Message-id: <006001cb0842$5cc095e0$1201a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_Nhtlw/bgLzZoKfDfPbZbbA)" Thread-index: AcsIBWOnLA/M/SWMSnqS1T+qBkFOigAPH5jw References: <4C0FE37A.1000106@grotto-networking.com> Subject: Re: [CCAMP] WSON document status and next steps... X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 10 Jun 2010 02:12:39 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Nhtlw/bgLzZoKfDfPbZbbA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi CCAMPers, We just have updated the following draft, "General Network Element Constraint Encoding for GMPLS controlled Networks." http://www.ietf.org/id/draft-ietf-ccamp-general-constraint-encode-02.txt With this update, the co-authors of the document believe it is ready for working group last call. Thanks. Young _____ From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Greg Bernstein Sent: Wednesday, June 09, 2010 1:55 PM To: CCAMP Subject: [CCAMP] WSON document status and next steps... Hi CCAMPers interested in WSON, it's been about three years since the WSON enhancements to GMPLS got started. The non-impairment related WSON drafts have been fairly stable for some time. Here is the status and recommended next steps to the best of the authors knowledge: Document Title File Link Last Update Next Steps Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) draft-ietf-ccamp-rwa-wson-framework-06 2010-04-07 Last call finished, CCAMP chairs processing Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks draft-ietf-ccamp-rwa-info-07 2010-02-18 Ready for last call. General Network Element Constraint Encoding for GMPLS Controlled Networks draft-ietf-ccamp-general-constraint-encode-01 2010-03-02 Ready for last call. Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks draft-ietf-ccamp-rwa-wson-encode-04 2010-02-18 Ready for last call. As you can see there are three drafts that the authors consider ready for last call and would like to proceed. Please send comments, questions, or concerns about the above drafts (excluding Framework) to the list so we can discuss prior to IETF-78 in Maastrich. Per working group agreement the documents flow from general/abstract to more specific any issues should be addressed at the highest level of abstraction possible rather than the lowest, i.e., info model first, then encoding drafts, then protocol specific drafts. The most specific being the following two OSPF protocol related drafts: Document Title File Link Last Update Next Steps OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks draft-ietf-ccamp-wson-signal-compatibility-ospf-01 2010-03-05 Will be ready for last call after the RWA WSON encode OSPF Extensions in Support of Routing and Wavelength Assignment (RWA) in Wavelength Switched Optical Networks (WSONs) draft-zhang-ccamp-rwa-wson-routing-ospf-03 2010-03-04 Individual draft aligned with General Constraint Encoding. Ready to be a WG draft It should be noted that draft-ietf-ccamp-rwa-wson-encode-04 provides a robust and efficient modeling of regeneration (OEO) and other processing pools within an optical switch or ROADM. More extensive examples of the modeling power are available in the document http://www.grotto-networking.com/sites/default/files/ModelingSwitchesConvert ersRegensV02f.pdf which provides better graphics than available via ASCII and extended discussion not usually part of an IETF document. Please review the WG draft and bring any issues to the CCAMP list if you feel you've found a situation that cannot be adequately modeled with these existing mechanisms. >From the minutes of the IETF-77 Anaheim meeting there was an issue on "directionless ROADMs". This turns out to be a terminology issue. Directionless ROADMs are those whose add/drop ports are not bound to a particular line side ingress/egress port. These are also known as "add per node" ROADMs to be distinguished from "add per port" ROADMs. Though the terminology is not standardized these ROADMs are well (and easily) modeled via the techniques in the framework and an example is illustrated in Figure 2 of the WSON framework document. Best Regards Greg B. and WSON co-authors -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --Boundary_(ID_Nhtlw/bgLzZoKfDfPbZbbA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi = CCAMPers,

 

We just have updated the following = draft, “General Network Element Constraint Encoding for GMPLS controlled = Networks.”

 

http://www.ietf.org/id/draft-ietf-ccamp-general-constraint-encod= e-02.txt

 

With this update, the co-authors of = the document believe it is ready for working group last call. = Thanks.

 

Young

 

From: ccamp-bounces@ietf.org = [mailto:ccamp-bounces@ietf.org] On Behalf Of Greg Bernstein
Sent: Wednesday, June 09, = 2010 1:55 PM
To: CCAMP
Subject: [CCAMP] WSON = document status and next steps...

 

Hi CCAMPers interested in WSON, it's been = about three years since the WSON enhancements to GMPLS got started. The non-impairment related WSON drafts have been fairly stable for some = time. Here is the status and recommended next steps to the best of the authors = knowledge:

Document = Title

File = Link

Last = Update

Next = Steps

Framework for GMPLS and PCE Control of = Wavelength Switched Optical Networks (WSON)

draft-ietf-ccamp-rwa-wson-framework-06<= /p>

2010-04-07

Last call finished, CCAMP chairs = processing

Routing and Wavelength Assignment = Information Model for Wavelength Switched Optical Networks

draft= -ietf-ccamp-rwa-info-07

2010-02-18

Ready for last = call.

General Network Element Constraint Encoding = for GMPLS Controlled Networks

draft-ietf-ccamp-general-constraint-encode-01<= /span>

2010-03-02

Ready for last = call.

Routing and Wavelength Assignment = Information Encoding for Wavelength Switched Optical = Networks

draft-ietf-ccamp-rwa-wson-encode-04

2010-02-18

Ready for last = call.


As you can see there are three = drafts that the authors consider ready for last call and would like to = proceed. Please send comments, questions, or concerns about the above drafts = (excluding Framework) to the list so we can discuss prior to IETF-78 in Maastrich. = Per working group agreement the documents flow from general/abstract to more specific any issues should be addressed at the highest level of = abstraction possible rather than the lowest, i.e., info model first, then encoding = drafts, then protocol specific drafts.

The most specific being the following two OSPF protocol related = drafts:

Document Title

File Link

Last Update

Next Steps

OSPF Enhancement for Signal and Network = Element Compatibility for Wavelength Switched Optical = Networks

draft-ietf-ccamp-wson-signal-compatibility-ospf-01

2010-03-05

Will be ready for last call after the RWA = WSON encode

OSPF Extensions in Support of Routing and = Wavelength Assignment (RWA) in Wavelength Switched Optical Networks = (WSONs)

draft-zhang-ccamp-rwa-wson-routing-ospf-03

2010-03-04

Individual draft aligned with General = Constraint Encoding. Ready to be a WG = draft


It should be noted that draft-ietf-ccamp-rwa-wson-encode-04 provides a robust and efficient modeling of regeneration (OEO) and other processing pools within an optical switch or ROADM. More extensive = examples of the modeling power are available in the document http://www.grotto-networking.com/sites/defa= ult/files/ModelingSwitchesConvertersRegensV02f.pdf which provides better graphics than available via ASCII and extended discussion not usually part of an IETF document. Please review the WG = draft and bring any issues to the CCAMP list if you feel you've found a situation = that cannot be adequately modeled with these existing mechanisms.

>From the minutes of the IETF-77 Anaheim meeting there was an issue on "directionless ROADMs". This turns out to be a terminology = issue. Directionless ROADMs are those whose add/drop ports are not bound to a particular line side ingress/egress port. These are also known as = "add per node" ROADMs to be distinguished from "add per port" = ROADMs. Though the terminology is not standardized these ROADMs are well (and = easily) modeled via the techniques in the framework and an example is = illustrated in  Figure 2 of the WSON framework document.

Best Regards

Greg B. and  WSON co-authors

-- 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Greg Bernstein, Grotto Networking (510) =
573-2237
 
--Boundary_(ID_Nhtlw/bgLzZoKfDfPbZbbA)-- From gregb@grotto-networking.com Thu Jun 10 08:11:37 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DE4D28C0DF for ; Thu, 10 Jun 2010 08:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vRYVgS2ibDC for ; Thu, 10 Jun 2010 08:11:35 -0700 (PDT) Received: from mail30c40.carrierzone.com (mail30c40.carrierzone.com [209.235.156.170]) by core3.amsl.com (Postfix) with ESMTP id D112A28C0DB for ; Thu, 10 Jun 2010 08:11:34 -0700 (PDT) X-Authenticated-User: gregb.grotto-networking.com Received: from [192.168.0.131] (c-71-202-41-133.hsd1.ca.comcast.net [71.202.41.133]) (authenticated bits=0) by mail30c40.carrierzone.com (8.13.6/8.13.1) with ESMTP id o5AFBXPN010673 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 10 Jun 2010 11:11:35 -0400 Message-ID: <4C1100A7.1040301@grotto-networking.com> Date: Thu, 10 Jun 2010 08:11:35 -0700 From: Greg Bernstein User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: ccamp@ietf.org References: <4C0FE37A.1000106@grotto-networking.com> In-Reply-To: <4C0FE37A.1000106@grotto-networking.com> Content-Type: multipart/alternative; boundary="------------050607070004030503040102" Subject: Re: [CCAMP] WSON document status and next steps... X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 10 Jun 2010 15:11:37 -0000 This is a multi-part message in MIME format. --------------050607070004030503040102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Good catch Lou and Young, we had done the update to /general constraints encoding/ over two months ago but somehow it didn't make it from our hard disk to the IETF server :-( . The updated list of documents ready for last call is: *Document Title * *File Link* *Last Update* *Next Steps* Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON) draft-ietf-ccamp-rwa-wson-framework-06 2010-04-07 Last call finished, CCAMP chairs processing Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks draft-ietf-ccamp-rwa-info-07 2010-02-18 *Ready for last call.* General Network Element Constraint Encoding for GMPLS Controlled Networks draft-ietf-ccamp-general-constraint-encode-02 *2010-06-09* *Ready for last call.* Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks draft-ietf-ccamp-rwa-wson-encode-04 2010-02-18 *Ready for last call.* Best Regards Greg B. and WSON co-authors -- =================================================== Dr Greg Bernstein, Grotto Networking (510) 573-2237 --------------050607070004030503040102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Good catch Lou and Young, we had done the update to general constraints encoding over two months ago but  somehow it  didn't make it from our hard disk to the IETF server :-( . The updated list of documents ready for  last call is:

Document Title
 File Link
Last Update
Next Steps
Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks (WSON)
 draft-ietf-ccamp-rwa-wson-framework-06 2010-04-07
 Last call finished, CCAMP chairs processing
Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks
 draft-ietf-ccamp-rwa-info-07 2010-02-18
 Ready for last call.
General Network Element Constraint Encoding for GMPLS Controlled Networks
 draft-ietf-ccamp-general-constraint-encode-02 2010-06-09
 Ready for last call.
Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks
 draft-ietf-ccamp-rwa-wson-encode-04 2010-02-18
 Ready for last call.

Best Regards

Greg B. and  WSON co-authors

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237
--------------050607070004030503040102-- From wwwrun@core3.amsl.com Thu Jun 10 08:55:24 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 3B74F3A69FD; Thu, 10 Jun 2010 08:55:23 -0700 (PDT) To: danli@huawei.com, diego.caviglia@ericsson.com, snigdho.bardalai@us.fujitsu.com, daniele.ceccarelli@ericsson.com From: IETF Secretariat Message-Id: <20100610155524.3B74F3A69FD@core3.amsl.com> Date: Thu, 10 Jun 2010 08:55:24 -0700 (PDT) Cc: ccamp@ietf.org, adrian.farrel@huawei.com, dbrungard@att.com, ipr-announce@ietf.org Subject: [CCAMP] Posting of IPR Disclosure related to HUAWEI TECHNOLOGIES CO., LTD's Statement about IPR related to RFC 5852 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 10 Jun 2010 15:55:24 -0000 Dear Dan Li, Diego Caviglia, Snigdho Bardalai, Daniele Ceccarelli: An IPR disclosure that pertains to your RFC entitled "RSVP-TE Signaling Extension for LSP Handover from the Management Plane to the Control Plane in a GMPLS-Enabled Transport Network." (RFC5852) was submitted to the IETF Secretariat on 2010-06-10 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1327/). The title of the IPR disclosure is "HUAWEI TECHNOLOGIES CO.,LTD's Statement about IPR related to RFC 5852." The IETF Secretariat From benoit.c.tremblay@ericsson.com Thu Jun 10 21:24:22 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39CB228C11F for ; Thu, 10 Jun 2010 21:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, LOCALPART_IN_SUBJECT=2.02, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2ric8HMr4Hf for ; Thu, 10 Jun 2010 21:24:20 -0700 (PDT) Received: from imr1.ericy.com (imr1.ericy.com [198.24.6.9]) by core3.amsl.com (Postfix) with ESMTP id 8A9113A681F for ; Thu, 10 Jun 2010 21:24:20 -0700 (PDT) Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id o5B4VH8W014337; Thu, 10 Jun 2010 23:31:17 -0500 Received: from EUSAACMS0703.eamcs.ericsson.se ([169.254.2.83]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 11 Jun 2010 00:24:21 -0400 From: Benoit C Tremblay To: "draft-ietf-ccamp-lsp-hierarchy-bis@tools.ietf.org" Date: Fri, 11 Jun 2010 00:24:16 -0400 Thread-Topic: draft-ietf-ccamp-lsp-hierarchy-bis Thread-Index: AcsJHfQ4XZtdXkt/SxiXSN9wEx40eA== Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/mixed; boundary="_005_CE39F5249064D946AA3535E63A01461960FCB0C9FCEUSAACMS0703e_" MIME-Version: 1.0 Cc: "ccamp@ietf.org" Subject: [CCAMP] draft-ietf-ccamp-lsp-hierarchy-bis X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 11 Jun 2010 04:24:22 -0000 --_005_CE39F5249064D946AA3535E63A01461960FCB0C9FCEUSAACMS0703e_ Content-Type: multipart/alternative; boundary="_000_CE39F5249064D946AA3535E63A01461960FCB0C9FCEUSAACMS0703e_" --_000_CE39F5249064D946AA3535E63A01461960FCB0C9FCEUSAACMS0703e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Adrian and Shiomoto-san, We evaluated the implementation of the extensions proposed in draft-ietf-c= camp-lsp-hierarchy-bis. The proposed extensions are pretty easy to implement and fulfills the lacks= that were present in the existing HLSP RFC related to how to advertise the= resulting TE-link. However, we believe that a feature is still missing and= would like to share our observation with you. When advertising the (virtual) TE-link corresponding to an HLSP, RFC4206 re= commends to set its TE-metric to max(1, (TE-metric of the FA-LSP path) - 1)= . However, in many cases none of the ingress or egress node knows the resu= lting TE-metric of the signaled HLSP. Here are a few examples of scenarios where the nodes do not know the TE-met= ric of the HLSP: - On the ingress node, the path is only partially computed and the further = path computation is delegated to node down the signaling path. - The Record Route Object (RRO) that collects the path (either from the ing= ress to the egress node or from the egress node to the ingress node) is opt= ional and might not be received by the remote node. - The RRO object may contain node IDs instead of links. If multiple links = with different costs exist between two neighbor nodes, the ingress or egres= s node might not be able to determine which link has been used. - In some cases, the RRO contains path keys to identify segments of the LSP= instead of the node or links. When the end nodes can not accurately determine the TE-metric of the HLSP, = a default or approximate value is used. The default value does not usually= correspond to the actual metric of the HLSP and can introduce distortion i= n further path computations. Have you considered how the metric of the TE-link corresponding to the HLSP= would be computed by the ingress and the egress nodes? Regards, Benoit BENOIT TREMBLAY Researcher Ericsson Canada inc. Broadband and Systems Research 8400 Decarie Montreal H4P 2N2, Canada Phone +1 514 345 7900 x45064 Fax +1 514 345-6105 Mobile +1 514 501-0236 benoit.c.tremblay@ericsson.com www.ericsson.com This Communication is Confidential. We only send and receive email on the b= asis of the terms set out at www.ericsson.com/email_disclaimer --_000_CE39F5249064D946AA3535E63A01461960FCB0C9FCEUSAACMS0703e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Adrian and Shiomoto-san,
 
We evaluated the implementation of  the extensions proposed in dr= aft-ietf-ccamp-lsp-hierarchy-bis.
The proposed extensions are pretty easy to implement and fulfills the = lacks that were present in the existing HLSP RFC related to how to advertis= e the resulting TE-link. However, we believe that a feature is still missin= g and would like to share our observation with you.
 
When advertising the (virtual) TE-link corresponding to an HLSP, RFC42= 06 recommends to set its TE-metric to max(1, (TE-metric of the FA-LSP path)= - 1).  However, in many cases none of the ingress or egress node know= s the resulting TE-metric of the signaled HLSP.
 
Here are a few examples of scenarios where the nodes do not know the T= E-metric of the HLSP:
- On the ingress node, the path is only partially computed and the fur= ther path computation is delegated to node down the signaling path.
- The Record Route Object (RRO) that collects the path (either from th= e ingress to the egress node or from the egress node to the ingress node) i= s optional and might not be received by the remote node. 
- The RRO object may contain node IDs instead of links.  If multi= ple links with different costs exist between two neighbor nodes, the ingres= s or egress node might not be able to determine which link has been used. <= /div>
- In some cases, the RRO contains path keys to identify segments of th= e LSP instead of the node or links. 
 
When the end nodes can not accurately determine the TE-metric of the H= LSP, a default or approximate value is used.  The default value does n= ot usually correspond to the actual metric of the HLSP and can introduce di= stortion in further path computations.
 
Have you considered how the metric of the TE-link corresponding to the= HLSP would be computed by the ingress and the egress nodes?
 
Regards,
Benoit



BENOIT TREMBLAY
Researcher =

Ericsson Canada inc.
Broadband and Systems Research
8400 Decarie
Montreal H4P 2N2, Canada
Phone +1 514 345 7900 x45064
Fax +1 514 345-6105
Mobile +1 514 501-0236
benoit.c.tremblay@ericsson.com
www.ericsson.com





This Communication is Con= fidential. We only send and receive email on the basis of the terms set out= at www.ericsson.com/email_disclaime= r
 
 
 --_000_CE39F5249064D946AA3535E63A01461960FCB0C9FCEUSAACMS0703e_-- --_005_CE39F5249064D946AA3535E63A01461960FCB0C9FCEUSAACMS0703e_ Content-Type: image/jpeg; name="Picture (Device Independent Bitmap) 1.jpg" Content-Description: Picture (Device Independent Bitmap) 1.jpg Content-Disposition: inline; filename="Picture (Device Independent Bitmap) 1.jpg"; creation-date="Fri, 11 Jun 2010 00:24:18 GMT"; modification-date="Fri, 11 Jun 2010 00:24:18 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAADAP8DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0DxiM awTzyg7+1cvJRRXwWN/3yp6sxqFaSqslFFa0Tz6hVkqrJRRXp0jgqFaSqzdaKK9OkefUG0UUV30z EWloortpiCloorupiCloortpgRNUL0UVqbwIHqBqKKR2QIGqB6KKR2QIGqFutFFI7KYoqQUUVjI9 XDkgqQUUVzTPaw5ItSLRRXNI9vDki16n8FEB1XVXyciBB9445Y9unb/OaKK5Zm2Z/wC4VPl+aP/Z --_005_CE39F5249064D946AA3535E63A01461960FCB0C9FCEUSAACMS0703e_ Content-Type: image/jpeg; name="Picture (Device Independent Bitmap) 2.jpg" Content-Description: Picture (Device Independent Bitmap) 2.jpg Content-Disposition: inline; filename="Picture (Device Independent Bitmap) 2.jpg"; creation-date="Fri, 11 Jun 2010 00:24:18 GMT"; modification-date="Fri, 11 Jun 2010 00:24:18 GMT" Content-ID: <46c3889d-5ad8-453e-8c6d-90876ebacaa8> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCAB7AGUDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDyi8/4 /rj/AK6N/OoKmvP+P24/66N/Ooa9s8t7hRRRTEFFFFABRW5ofg/xB4kYf2XpdxPGTgyldsY/4EcC vTtC+AUskYk17VhESP8AU2a7iPq7DH6fjWc6sIbsuNKctkeK0V2HxD8CyeB9XhgW5NzaXKF4JGXD cHBUj1GRz71x9VGSkromUXF2YUUUVQi3ZMRvwxHTocetFJZ/x/hRTR1U/hRHef8AH7cf9dG/nUNT Xn/H7cf9dG/nUNScz3CiiimI9H8E/CHUvFVhFql1dJYafKT5ZKlpJADjIHAA9yfwr1/QPhR4T0HZ ILD7dcLg+deESc+y/dH5VxngP4waHpfhS10zWEnhuLKPykaKPesqjp9DjjmnXfxi13X52s/Bvh2a V+nnSoZGHvtXhfqSa4Knt5Sa2R2Q9lFJ9T2QmG2gySkUMY74VVH9K4jX/i74U0PdGl2dQuBx5dmA 4z7v939TXGx/DPxt4vkS48X6+0EJwfsyt5hH0VcIp9+a7fRPhR4R0VB/xLVvpsYMt7+9z/wE/KPy rHlpR+J39DS85bKx4F488b3XjjWI7uWAW1tAhSCANu2gnJJPcnj8hXK16X8ZvC+k+HdesZNKhS3W 8iZpLdPuoVIGQOwOensa80r0aTi4Jx2OKompPm3CiiitCC1Z/wAf4UUWf8f4UVSOqn8KI7z/AI/b j/ro386hqa8/4/bj/ro386hqDme4UUUUxHvfw3+FOhXHh2x1vWYjfXF0nnJEzERop6DA+8cdc8c9 K9bs7K00+3W3sraG3hUYWOFAij8BXzd4M+KXiXQtMTRLKxj1JFz9nRkdnTJ6DaeRk9P1rqf+Ec+K Hjk7tZ1A6PYv/wAsd2zj/rmvJ+jGvPq05uTc5WR205x5fdR6Pr3xD8L+HN6XuqRPOv8Aywg/ePn0 wOn44rzy8+MPiHX5XtvB/hyZ8cec8ZlYe+1flX8Sa6TQfgt4X0krJerLqk45zcHEefZB/UmvQba1 trK3WC1gighTokSBVH4CsualDZXNLTlu7Hx74ivdav8AWppfED3LaiMLILhdrKOw24GB7AY5rKr1 T456npV/4lsY7CSKa6t4GS5kiII5OVUkdxz+deV16NOXNFO1jhqK0mrhRRRWhBas/wCP8KKLP+P8 KKpHVT+FEd5/x+3H/XRv51DU15/x+3H/AF0b+dQ1BzPcKKKKYj6l+E+n6Va+AdOuNPjiMs8e65lU As0mfmBPt0x7V0Gt+KtC8OxF9V1O3tjjIjLZc/RRyfyr5K0/XdW0mKWLTtTu7SOX76wTMgb8j1ql LLJNK0srtJIxyzMckn3NcbwvNJts6ViLRSSPdNf+PdrFvi0DTHnboLi6O1fqFHJ/EivLte+IHifx JuW/1SUQN/y7wfu4/pgdfxzXM0VvCjCGyMpVZy3YUUUVqZhRRRQBas/4/wAKKLP+P8KKpHVT+FEd 5/x+3H/XRv511nhPwEvibQb/AFifWbbTbWyk2SvOhIAwDnOeOtcnef8AH7cf9dG/nXsXwiuli8C6 /BHLpv2uSceVDqEgETnaPvDqRWFWTjG6MqcVKdmcYPAdlc+I9K0fTfFFhfvfmQNJAhIh2rkZGec8 /lWhe/Clk0/Vp9L8RWGo3GlBjd2yKVdNucjnv8rfka6hXvIPiV4UuNV/4Rq2jV5wDpUgC/c58zPT tj8au3GuWPiPS/Hmj2g0/S79JX2T2zqhvkBb7xP3icEH/frJ1J6W/rU2VOGun9WPN7r4d6hHp/hu e0uEup9dGYYFUqY+ATkk9AD19quav8O9M0SO4gvfGemrqkERdrMRseQudu7PU9gR3rt4vE2maFp/ w2vbm4iaKCCSO42MGaIPEq5IHIwT/OuX8W/Du6utR1XxBp+s6VdaXM0l4szXQDYOWK47nsPw6U1U k37zt/w5LpxSulco/wDCt7PT9K0+68Q+KrHSJ7+Lzbe3kiZ8qcHlgRjqM1Dpnw8gl8NQeINa8Q2u kWF1IY7ZpImkaXkgHAIxnBr0fwkdTm0G1t/GMnh7UPDYswyXE0ytLEu0bVOe4HB7jHU1R8AnWVso 7dJNDvvBclzLshvph51rDvYDg+3IB9e1S6krPX+vItUoO2hweifDt9budVmj1m0i0XTWKy6m4Ox+ /wAq9+Oevp60/V/htNZWum6jp2rW2p6Tf3CW63cKFfLZm2jcufXPfrxxXbwSeHdb0fxf4N0HULW1 867E9juk2xzcIWVT6bkI+hBHFQBrXwZ4E0zwvfX9rNq15qsM8kUMocW6CVGyT2GEH4sewzT9pK/6 eXcn2cbHMeIfhNqPh/WNGsnv4podUuBbLcLGQInJAwRn0OR9DXJeJNEfw54hvdIknWd7VwhkVcBu Aen4174PE+l3/wARtS8P6neQPZq9vfafMZV2xyxhWZQ2cc4z/wB9eteMfEqWKf4ia1LDIkkbTAq6 MGB+VehFVSqTk7S7E1YRjG8e5z9n/H+FFFn/AB/hRXUiqfwojvP+P24/66N/OoamvP8Aj9uP+ujf zqGoOZ7hRRRTEFFFFABRRRQAUUUUAFFFFAFqz/j/AAoos/4/woqkdVP4UR3n/H7cf9dG/nUNTXn/ AB+3H/XRv51DUHM9wooopiCiiigAooooAKKKKACiiigC1Z/x/hRRZ/x/hRVI6qfwojvP+P24/wCu jfzqGprz/j9uP+ujfzqGoOZ7hRRRTEFFFFABRRRQAUUUUAFFFFAFqz/j/Cim2pI349qKpLQ6qS91 H//Z --_005_CE39F5249064D946AA3535E63A01461960FCB0C9FCEUSAACMS0703e_-- From Adrian.Farrel@huawei.com Sat Jun 12 04:18:45 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57B8D3A68C2 for ; Sat, 12 Jun 2010 04:18:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.843 X-Spam-Level: X-Spam-Status: No, score=-0.843 tagged_above=-999 required=5 tests=[AWL=-0.888, BAYES_50=0.001, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znXE5CqHw6fQ for ; Sat, 12 Jun 2010 04:18:44 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id 0EE683A6861 for ; Sat, 12 Jun 2010 04:18:44 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L3W009VGFFAME@usaga03-in.huawei.com> for ccamp@ietf.org; Sat, 12 Jun 2010 06:18:46 -0500 (CDT) Received: from your029b8cecfe (host225.n061-193-185-224.pri.iprevolution.ne.jp [61.193.185.225]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L3W005NTFF7XV@usaga03-in.huawei.com> for ccamp@ietf.org; Sat, 12 Jun 2010 06:18:46 -0500 (CDT) Date: Sat, 12 Jun 2010 08:21:36 +0100 From: Adrian Farrel To: draft-ietf-ccamp-gmpls-ethernet-pbb-te@tools.ietf.org Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Mailer: Microsoft Outlook Express 6.00.2900.5931 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal Cc: ccamp@ietf.org, ccamp-chairs@tools.ietf.org Subject: [CCAMP] AD review of draft-ietf-ccamp-gmpls-ethernet-pbb-te-04 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian Farrel List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jun 2010 11:18:45 -0000 Hi, Don't panic! I have done my AD review of your document. I have quite a large number of fairly minor editorial gripes, and a couple of technical questions that I think you should address before we move the document forward. This will result in a better document and a smoother course through IETF and IESG review. All my issues are open for discussion - nothing is mandatory. I will move the document into "Revised I-D needed" state in the data tracker. Thanks, Adrian --- Please remove citations from the Abstract. It is OK to mention the documents by name (e.g. "RFC 5828") but not to give references. (The Abstract is standalone information.) --- Section 3 GMPLS is being defined here to establish ESPs and TESIs. As it can be seen from the above this requires configuration of both the I and B components of the IB-BEBs connected by the ESPs. Perhaps an overstatement? :-) I think either: This document defines the applicability of GMPLS to establish... or This document defines extensions to GMPLS to establish... --- Figure 2 The word "ports" seems to be aligned wrong --- Section 3.1 s/Path Computation Server/Path Computation Element/ --- Section 3.2 Please capitalise the seciton heading --- Section 3.2 The ESP-VID/ESP-MAC DA can be considered to be a shared forwarding identifier or label consisting of some number of P2P connections distinctly identified by the MAC ESP-VID/ESP-MAC DA/ESP- MAC SA tuple. This is analogous to an LDP label merge but in the shared forwarding case the original ESP header still identifies the complete path. Resources can continue to be allocated per LSP with Shared forwarding. Isn't this a bad choice of the word "path" since this (expecially in association with "complete" tends to imply a route. And "original" in what context? I think you might use... ...case the ESP header contians sufficient information to identify the flow to which a packet belongs. --- Section 3.2 It is a local decision of how this is performed but the best choice is a path that maximizes the shared forwarding. Does "local decision" mean "implementation decision" or is it supposed to be a configurable thing or policy driven? What is meant by "maximize shared forwarding". Actually, isn't the objective to reduce forwarding table entries. So any shared entry is good enough. You seem to be introducing a new requirement to get as much traffic as possible through the same forwarding entry. Can you add some text or modify what you have to clarify these points --- Section 3.2 The concept of bandwidth management still applies equally well with shared forwarding. As an example consider a PBB-TE edge switch that terminates an Ethernet LSP with the following attributes: bandwidth B1, ESP-MAC DA D, ESP-MAC SA S1, ESP-VID V. A request to establish an additional Ethernet LSP with attributes (bandwidth B2, ESP-MAC DA D, ESP-MAC SA S2, ESP-VID V) can be accepted provided there is sufficient link capacity remaining. I find this example quite hard to follow. My suggestion is to either remove the example, or to fill it out with a figure. Why do you use an edge switch in your example? That seems to add to my confusion. --- Section 4.1.1 Where individual paths in a protection group are modified, signaling procedures MAY be combined with Protection Switching (PS) coordination to administratively force PS switching operations such that modification is only ever performed on the protection path. I think you need a reference for PS. --- Section 4.5 I think you are missing a chunk of text. I think I can see how the CALL_ATTRIBUTES are used in accordance with RFC4974, but there really is nothing more than a reference to RFC4974 in step 6) or Seciotn 4.1. I can't find any explanation of the use of LSP_ATTRIBUTES. No reference to RFC5420, and no mention of how the object might be used. How do the authors propose for these objects to be used, and how did the WG assess the protocol extensions? Can one LSP be associated with multiple I-SIDs? What does it mean for a Call to be associated with multiple I-SIDs? The inclusion of a field for flags with none defined might be excusable, if you had some spare bits, but you don't. Why don't you strike this and include an options sub-TLV is necessary in the future? Presumably if Action == range then excatly two I-SIDs must be present in the sub-TLV. This section worries me a fair bit. It feels like the absence of an implementation is a bit telling. I find myself wondering whether the I-D should actually be published as Informational or Experimental "as a basis for future standards track work" I would feel a lot more comfortable if this section was more robust. --- Figures 4 and 5 There seem to be some minor alignment problems with vertical pipes. Someone been using tab stops? --- Section 5.1.1 is a bit woolly! Starting with Seciton 5.1 The network operator administratively selects a set of VLAN Identifiers that can be used to setup ESPs. Consequently, any VID outside the allocated range is invalid and an error MUST be generated where the mismatch is discovered. It is unclear is this is a data plane, management plane, or control plane error. In 5.1.1: which message might give rise to the error? which message is used to carry the error? --- Section 5.1.2 What was wrong with using an existing sub-code such as 9? BTW, 35 is already allocated. --- Section 6 This section is not going to get past the Security Directorate! - It will help to refer to draft-ietf-mpls-mpls-and-gmpls-security-framework - "The commonly known techniques..." will need references - The statement that all devices in the domain are trusted will raise eyebrows especially give the pug and play nature of Ehternet and the relative ease of packet insertion via the data plane. - "Care is required to ensure untrusted access to the trusted domain does not occur" needs at least some guidance on what care might be taken - It seems to me that you are allowing the control plane to set up a different forwarding paradigm from the one we are used to. Since the forwarding plane is more easily (differently) subverted than the management plane, surely you are introducing risks that have never even been thought about. --- Section 8.1 Please include file name (draft-ietf-ccamp-gmpls-mln-extensions) for [MLN-EXT] to remove downref warning. --- Section 8.2 Please fix up the references to [IEEE 802.1ay] should be [IEEE 802.1Qay] [IEEE 802.1ah] should be [IEEE 802.1Qah] Please remove unreferenced items. [IEEE 802.1ag] [Y.1731] --- From loa@pi.nu Mon Jun 14 04:20:13 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 950CE3A67A7; Mon, 14 Jun 2010 04:20:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PDvxi39P5MCN; Mon, 14 Jun 2010 04:20:12 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 702433A68BD; Mon, 14 Jun 2010 04:20:12 -0700 (PDT) Received: from [90.232.5.42] (host-90-232-5-42.mobileonline.telia.com [90.232.5.42]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 8808AD404F; Mon, 14 Jun 2010 13:20:13 +0200 (CEST) Message-ID: <4C1610C7.4000103@pi.nu> Date: Mon, 14 Jun 2010 13:21:43 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: CCAMP , mpls@ietf.org References: <4C04B508.1080706@pi.nu> In-Reply-To: <4C04B508.1080706@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [CCAMP] joint ccamp and mpls working group last call on draft-ietf-mpls-explicit-resource-control-bundle+07 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 14 Jun 2010 11:20:13 -0000 Working groups, we have seen no responses to this last call. The normal interpretation would be that there are no comments and the draft is ready to progress. However, because of the special nature of this working group last call, we won't lightly subscribe to this interpretation. The wg last call is therefore extended one week and people supporting this draft being published as in RFC are encourage to state this on the list. If you have concerns you are of course also encourage to state this on the list. The working group last call will end eob June 25th. /Loa On 2010-06-01 09:21, Loa Andersson wrote: > > > All, > > in mid-February the draft-ietf-mpls-explicit-resource-control-bundle > was retruned to the MPLS Working Group from the responsible AD > stating that: > > - it had been a long time since the working group last call > - the version that were working group last called was much earlier > than the one we requested publication for, i.e. the document has > changed many times since the wg last call > - this document is also of interest for the CCAMP working group, and > the working group last call should have been jointly between MPLS > and CCAMP > - there is a need to poll both working group to see if there is > an interest in this draft. > > However it also needs to pointed out that there are at least two deployed > implementations and we need to amke the reservation of the code points > in the IANA section. > > This is to start a joint CCAMP and MPLS working group last call on > draft-ietf-mpls-explicit-resource-control-bundle-07. > > Please send your comments to the mpls and ccamp working group list. > > > > The joint working group last call ends eob June 16. > > > /Loa -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13 From wwwrun@core3.amsl.com Mon Jun 14 08:56:37 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 85CDE3A69F7; Mon, 14 Jun 2010 08:56:37 -0700 (PDT) To: zhangrenhai@huawei.com,mach@huawei.com From: IETF Secretariat Message-Id: <20100614155637.85CDE3A69F7@core3.amsl.com> Date: Mon, 14 Jun 2010 08:56:37 -0700 (PDT) Cc: ccamp@ietf.org, adrian.farrel@huawei.com, dbrungard@att.com, ipr-announce@ietf.org Subject: [CCAMP] Posting of IPR Disclosure related to HUAWEI TECHNOLOGIES CO., LTD's Statement about IPR related to RFC 5392 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 14 Jun 2010 15:56:37 -0000 Dear Renhai Zhang, Mach Chen: An IPR disclosure that pertains to your RFC entitled "OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering" (RFC5392) was submitted to the IETF Secretariat on 2010-06-13 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1329/). The title of the IPR disclosure is "HUAWEI TECHNOLOGIES CO.,LTD's Statement about IPR related to RFC 5392." The IETF Secretariat From sergio.belotti@alcatel-lucent.com Tue Jun 15 06:49:56 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 003F53A6801 for ; Tue, 15 Jun 2010 06:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.766 X-Spam-Level: X-Spam-Status: No, score=0.766 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rOkQfeBqCd7R for ; Tue, 15 Jun 2010 06:49:52 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 99CBE3A6A6F for ; Tue, 15 Jun 2010 06:49:52 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o5FDnmGq014226 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 15 Jun 2010 15:49:49 +0200 Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.40]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 15 Jun 2010 15:49:48 +0200 From: "BELOTTI, SERGIO (SERGIO)" To: CCAMP WG Date: Tue, 15 Jun 2010 15:49:48 +0200 Thread-Topic: new draft draft-bccg-ccamp-otn-g709-info-model-00 Thread-Index: AcsMkZ6VIsgqjaJyTziNuPqD/a8ApQ== Message-ID: Accept-Language: en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_F050945A8D8E9A44A71039532BA344D80B4EC2BEFRMRSSXCHMBSB1d_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Subject: [CCAMP] new draft draft-bccg-ccamp-otn-g709-info-model-00 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 15 Jun 2010 13:49:56 -0000 --_000_F050945A8D8E9A44A71039532BA344D80B4EC2BEFRMRSSXCHMBSB1d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi CCAMP'rs An new draft entitled "Information model for G.709 Optical Transport Netw= orks (OTN)" is now available: http://tools.ietf.org/id/draft-bccg-ccamp-otn-g709-info-model-00.txt This draft provides a model of information needed by the routing process i= n OTNs to support Generalized Multiprotocol Label Switching in alignment wi= th the content of G.709-v3 (consented Oct 2009). The authors would appreciate your comments and discussions in the mailing l= ist. Thanks. Best Regards, the authors Sergio Belotti System Architecture Optics Division-Terrestrial Optics Unit ALCATEL-LUCENT +39 039 6863033 +39 039 6863590 --_000_F050945A8D8E9A44A71039532BA344D80B4EC2BEFRMRSSXCHMBSB1d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi CCAMP’rs
 
An new draft  entitled “Information model for G.709 Optical Transport Networks (OTN)” = is now available:
 
 
This draft provides a model of information needed by the routing proc= ess in OTNs to support Generalized Multiprotocol Label Switching in alignme= nt with the content of  G.709-v3 (consented Oct 2009).
    
 
The authors would appreciate your comments and discussions in the mail= ing list.
Thanks. 
 
Best Regards,
the authors 
 
 
Sergio Belotti
 
System Architecture
Optics Division-Terrestrial Optics Unit
ALCATEL-LUCENT<= /div>
 
+39 039 6863033
+39 039 6863590
 
 
 
 --_000_F050945A8D8E9A44A71039532BA344D80B4EC2BEFRMRSSXCHMBSB1d_-- From lberger@labn.net Tue Jun 15 11:48:17 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 019F93A69D1 for ; Tue, 15 Jun 2010 11:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.335 X-Spam-Level: X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[BAYES_50=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMY-Q+C6H80j for ; Tue, 15 Jun 2010 11:48:15 -0700 (PDT) Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id 852EC3A69B1 for ; Tue, 15 Jun 2010 11:48:15 -0700 (PDT) Received: (qmail 4971 invoked by uid 0); 15 Jun 2010 18:48:19 -0000 Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 15 Jun 2010 18:48:19 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=labn.net; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=jFI/wR/5/2wwsE1384xy++fbkP15lisRR+2nLXiZPd4gxlxUgmrN4mmcoxD816WUacCCSNY6A3sRQTtBd44BvH6O24xhL9O0GOv01XDeQSW9g7XWeDEqcbo1ATbwQnEE; Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OObBL-00041v-Jm; Tue, 15 Jun 2010 12:48:19 -0600 Message-ID: <4C17CAF2.1080605@labn.net> Date: Tue, 15 Jun 2010 14:48:18 -0400 From: Lou Berger User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.7) Gecko/20100301 Eudora/3.0.1 MIME-Version: 1.0 To: Loa Andersson , draft-ietf-mpls-explicit-resource-control-bundle@tools.ietf.org References: <4C04B508.1080706@pi.nu> <4C1610C7.4000103@pi.nu> In-Reply-To: <4C1610C7.4000103@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: mpls@ietf.org, CCAMP Subject: Re: [CCAMP] joint ccamp and mpls working group last call on draft-ietf-mpls-explicit-resource-control-bundle+07 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 15 Jun 2010 18:48:17 -0000 On 6/14/2010 7:21 AM, Loa Andersson wrote: > Working groups, > > we have seen no responses to this last call. The normal > interpretation would be that there are no comments and the > draft is ready to progress. However, because of the special > nature of this working group last call, we won't lightly > subscribe to this interpretation. > > The wg last call is therefore extended one week and people > supporting this draft being published as in RFC are encourage > to state this on the list. If you have concerns you are of > course also encourage to state this on the list. > > The working group last call will end eob June 25th. > > /Loa > Okay, I've been suitably shamed into doing a full review. I don't have any fundamental objections to this document. I think there are some editorial fixes and technical clarifications that are needed before the document is ready for publication as an RFC. Here are my LC comments: - Section 2, 3rd paragraph: Really should be rewritten. It's not clear what point(s) are being made. -Section 3.1: For consistency with 4201: "component interface identifier" -> "component link identifier" OLD: component link identifier of a (bundled) TE Link. This subobject NEW: component link identifier of a bundled TE Link. This subobject Section 3.2: - Section should use normative, RFC2119 language. - In multiple locations: proposal -> document - Make it clear that processing is occurring at ingress, clarify label SO processing: OLD: In most cases, a node initiates recording for a given LSP by adding the RRO to the Path message. If the node desires Component Link recording and if the outgoing TE link is bundled, then the initial RRO contains the Component Link identifier (numbered or unnumbered) as selected by the sender. As well, the Component Link Recording desired flag is set in the LSP_ATTRIBUTE object. If the node also desires label recording, it sets the Label_Recording flag in the SESSION_ATTRIBUTE object. NEW: When the ingress node sets the "Component Link Recording desired" flag and the outgoing interface is link bundled, then the ingress SHOULD create an RRO containing a subobject indicating the Component Link identifier (numbered or unnumbered) as selected by the sender. When an ingress also desires label recording, it sets the Label_Recording flag as defined in [RFC3209]. Any Label Record subobjects MUST precede the corresponding component link identifier subobject. - Clarify intent: OLD set is received by an intermediate node, if a new Path message is to be sent for a downstream bundled TE link, the node adds a new Component Link subobject to the RECORD_ROUTE object (RRO) and appends the resulting RRO to the Path message before transmission. NEW set is received by an intermediate node, and the outgoing interface is a link bundled, the node SHOULD add - need to add words on label handling too - Not sure the following adds anything, but I expect it's talking about transmission not reception: Note also that, unlike Labels, Component Link identifiers are always known on receipt of the Path message. - the following looks like a bad cut-and-paste from 3209, and needs to be reworded. (BTW what does "needs TE route" mean?) When the destination node of an RSVP session receives a Path message with an RRO and the "Component Link Recording desired" flag set, this indicates that the sender node needs TE route as well as component link recording. The destination node initiates the RRO process by adding an RRO to Resv messages. The processing mirrors that of the Path messages - Clarify that this following applies to all cases: OLD: The Component Interface Record subobject is pushed onto the NEW: In all cases, a Component Interface Record subobject is pushed onto the - need to defined label processing in this context: When component interfaces are recorded for bi-directional LSPs, component interface RRO subobjects for both downstream and upstream interfaces MUST be included. Section 4: - Why must a component SO follow an SO object with L=0. To preclude it accidentally being an incoming interface? - "cleared (0)" -> "clear (0)" - The following has an interesting implication that the ERO always contains the component identifiers of the remote side of a TA link: local translation into the outgoing interface identifier from the received incoming remote interface identifier Is this correct? If so, I think this needs to be explicitly stated in the format section. It also counter to how rfc3473 handles label SOs in EROs. - The interactions and implications on label SO processing needs to be stated - The case of a bidirectional LSP with only a component SO with a Ubit = 0 isn't covered - "Inferred from above" --> "As implied above" Section 5. - first 2 paragraphs use 2119 language for nodes that *don't* support the document, i.e., you can't use normative language here. The 3rd paragraph in the section gets it right. Section 6 seems a bit light. That's it. Lou From wwwrun@core3.amsl.com Thu Jun 17 08:18:56 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 144543A67D6; Thu, 17 Jun 2010 08:18:55 -0700 (PDT) To: zhangrenhai@huawei.com,mach@huawei.com From: IETF Secretariat Message-Id: <20100617151856.144543A67D6@core3.amsl.com> Date: Thu, 17 Jun 2010 08:18:56 -0700 (PDT) Cc: ccamp@ietf.org, adrian.farrel@huawei.com, dbrungard@att.com, ipr-announce@ietf.org Subject: [CCAMP] IPR Disclosure: HUAWEI TECHNOLOGIES CO., LTD's Statement about IPR related to RFC 5316 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 17 Jun 2010 15:18:56 -0000 Dear Renhai Zhang, Mach Chen: An IPR disclosure that pertains to your RFC entitled "ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering " (RFC5316) was submitted to the IETF Secretariat on 2010-06-17 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1332/). The title of the IPR disclosure is "HUAWEI TECHNOLOGIES CO.,LTD's Statement about IPR related to RFC 5316." The IETF Secretariat From root@core3.amsl.com Fri Jun 18 14:15:11 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 57D7C3A699D; Fri, 18 Jun 2010 14:15:05 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100618211508.57D7C3A699D@core3.amsl.com> Date: Fri, 18 Jun 2010 14:15:06 -0700 (PDT) Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action:draft-ietf-ccamp-mpls-tp-cp-framework-02.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 18 Jun 2010 21:15:15 -0000 --NextPart 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 : MPLS-TP Control Plane Framework Author(s) : L. Andersson, et al. Filename : draft-ietf-ccamp-mpls-tp-cp-framework-02.txt Pages : 49 Date : 2010-06-18 The MPLS Transport Profile (MPLS-TP) supports static provisioning of transport paths via a Network Management System (NMS), and dynamic provisioning of transport paths via a control plane. This document provides the framework for MPLS-TP dynamic provisioning, and covers control plane addressing, routing, path computation, signaling, traffic engineering,, and path recovery. MPLS-TP uses GMPLS as the control plane for MPLS-TP LSPs and provides for compatibility with MPLS. MPLS-TP also uses the control plane for Pseudowires (PWs). Management plane functions such as manual configuration and the initiation of LSP setup are out of scope of this document. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-tp-cp-framework-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ccamp-mpls-tp-cp-framework-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-18140902.I-D@ietf.org> --NextPart-- From wwwrun@core3.amsl.com Tue Jun 22 14:54:36 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 5E9C53A6A13; Tue, 22 Jun 2010 14:54:36 -0700 (PDT) From: Greg Jones(ITU-T SG 15) To: lberger@labn.net,dbrungard@att.com Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100622215436.5E9C53A6A13@core3.amsl.com> Date: Tue, 22 Jun 2010 14:54:36 -0700 (PDT) X-Mailman-Approved-At: Tue, 22 Jun 2010 14:59:10 -0700 Cc: hiroshi.ota@itu.int, greg.jones@itu.int, ccamp@ietf.org, yoichi.maeda@ntt-at.co.jp, peter.stassar@ties.itu.int, paf@cisco.com, adrian.farrel@huawei.com, rcallon@juniper.net, tsbsg15@itu.int, francesco.montalti@telecomitalia.it Subject: [CCAMP] New Liaison Statement, "LS194 - Lambda switch capable equipment" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 21:54:36 -0000 Title: LS194 - Lambda switch capable equipment Submission Date: 2010-06-22 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=909 From: Greg Jones(ITU-T SG 15) To: IETF CCAMP WG(lberger@labn.net,dbrungard@att.com) Cc: paf@cisco.com adrian.farrel@huawei.com rcallon@juniper.net ccamp@ietf.org yoichi.maeda@ntt-at.co.jp francesco.montalti@telecomitalia.it Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: peter.stassar@ties.itu.int Purpose: For information Body: Q.6/15 would like to thank IETF�s CCAMP Working Group for their Liaison Statement on Lambda Switch Capable Equipment, dated 27 May 2010, contained in TD 145 (WP2). Q.6/15 would like to inform CCAMP that it was agreed that no change would be required to ITU-T Recommendation G.697 (with respect to the parameter encoding contained in Appendix V) in response to CCAMP�s decisions on the document �Generalized Labels for Lambda-Switching Capable Label Switching Routers�. Q.6/15 is looking forward to continuing the exchange of information with CCAMP on the topics of the revision of ITU-T Recommendation G.680 and CCAMP�s activities. Attachment(s): LS194 - Lambda switch capable equipment - pdf body (https://datatracker.ietf.org/documents/LIAISON/file1042.pdf) From wwwrun@core3.amsl.com Tue Jun 22 15:10:43 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 9C97E3A67B8; Tue, 22 Jun 2010 15:10:43 -0700 (PDT) From: Greg Jones(ITU-T SG 15) To: lberger@labn.net,dbrungard@att.com Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100622221043.9C97E3A67B8@core3.amsl.com> Date: Tue, 22 Jun 2010 15:10:43 -0700 (PDT) Cc: hiroshi.ota@itu.int, greg.jones@itu.int, steve.trowbridge@alcatel-lucent.com, ccamp@ietf.org, yoichi.maeda@ntt-at.co.jp, paf@cisco.com, adrian.farrel@huawei.com, rcallon@juniper.net, tsbsg15@itu.int Subject: [CCAMP] New Liaison Statement, "LS201 - Response on G.709 efforts in IETF" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jun 2010 22:10:43 -0000 Title: LS201 - Response on G.709 efforts in IETF Submission Date: 2010-06-22 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=910 Please reply by 2010-10-04 From: Greg Jones(ITU-T SG 15) To: IETF CCAMP WG(lberger@labn.net,dbrungard@att.com) Cc: paf@cisco.com adrian.farrel@huawei.com rcallon@juniper.net ccamp@ietf.org yoichi.maeda@ntt-at.co.jp steve.trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: malcolm.betts@zte.com.cn Purpose: For action Body: Attachment(s): LS201 - Response on G.709 efforts in IETF - pdf body (https://datatracker.ietf.org/documents/LIAISON/file1043.pdf) LS201 - Response on G.709 efforts in IETF - pdf 247r1 (https://datatracker.ietf.org/documents/LIAISON/file1044.pdf) LS201 - Response on G.709 efforts in IETF - pdf 271r1 (https://datatracker.ietf.org/documents/LIAISON/file1045.pdf) LS201 - Response on G.709 efforts in IETF - pdf 279r1 (https://datatracker.ietf.org/documents/LIAISON/file1046.pdf) From zhang.fei3@zte.com.cn Wed Jun 23 20:45:28 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30F283A6919; Wed, 23 Jun 2010 20:45:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.035 X-Spam-Level: X-Spam-Status: No, score=-95.035 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 83dwFrpsrxIh; Wed, 23 Jun 2010 20:45:27 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 272C13A6A97; Wed, 23 Jun 2010 20:45:24 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 383433264510032; Thu, 24 Jun 2010 11:44:12 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 2748.6368853354; Thu, 24 Jun 2010 11:45:12 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o5O3iwBd081820; Thu, 24 Jun 2010 11:44:58 +0800 (CST) (envelope-from zhang.fei3@zte.com.cn) In-Reply-To: <20100618211508.57D7C3A699D@core3.amsl.com> To: loa.andersson@ericsson.com, lberger@labn.net, lufang@cisco.com, nabil.n.bitar@verizon.com MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: zhang.fei3@zte.com.cn Date: Thu, 24 Jun 2010 11:44:50 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-06-24 11:44:52, Serialize complete at 2010-06-24 11:44:52 Content-Type: multipart/alternative; boundary="=_alternative 0014CD094825774C_=" X-MAIL: mse2.zte.com.cn o5O3iwBd081820 Cc: ccamp@ietf.org, ccamp-bounces@ietf.org, i-d-announce@ietf.org Subject: Re: [CCAMP] I-D Action:draft-ietf-ccamp-mpls-tp-cp-framework-02.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 24 Jun 2010 03:45:28 -0000 This is a multipart message in MIME format. --=_alternative 0014CD094825774C_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgYWxsDQoNCldoZW4gd3JpdGluZyB0aGUgcmVxdWlyZW1lbnRzIG9mIFI4Mi84My84NC84NSwg dGhlIGZvbGxvd2luZyB0YWJsZSBnaXZlIA0KdGhlIHRpcHMgb2YgdGhlIHNvbHV0aW9uOg0KDQog ICAgIDgyLiBUaGUgTVBMUy1UUCBjb250cm9sIHBsYW5lIG11c3QgcGVybWl0IHRoZSB0ZXN0aW5n IGFuZA0KICAgICAgICAgdmFsaWRhdGlvbiBvZiB0aGUgaW50ZWdyaXR5IG9mIHRoZSBwcm90ZWN0 aW9uL3JlY292ZXJ5DQogICAgICAgICB0cmFuc3BvcnQgcGF0aCBbUkZDNTY1NCwgcmVxdWlyZW1l bnQgODQgQV0uDQoNCiAgICAgODMuIFRoZSBNUExTLVRQIGNvbnRyb2wgcGxhbmUgbXVzdCBwZXJt aXQgdGhlIHRlc3RpbmcgYW5kDQogICAgICAgICB2YWxpZGF0aW9uIG9mIHByb3RlY3Rpb24vIHJl c3RvcmF0aW9uIG1lY2hhbmlzbXMgd2l0aG91dA0KICAgICAgICAgdHJpZ2dlcmluZyB0aGUgYWN0 dWFsIHByb3RlY3Rpb24vcmVzdG9yYXRpb24gW1JGQzU2NTQsDQogICAgICAgICByZXF1aXJlbWVu dCA4NCBCXS4NCg0KICAgICA4NC4gVGhlIE1QTFMtVFAgY29udHJvbCBwbGFuZSBtdXN0IHBlcm1p dCB0aGUgdGVzdGluZyBhbmQNCiAgICAgICAgIHZhbGlkYXRpb24gb2YgcHJvdGVjdGlvbi8gcmVz dG9yYXRpb24gbWVjaGFuaXNtcyB3aGlsZSB0aGUNCiAgICAgICAgIHdvcmtpbmcgcGF0aCBpcyBp biBzZXJ2aWNlIFtSRkM1NjU0LCByZXF1aXJlbWVudCA4NCBDXS4NCg0KICAgICA4NS4gVGhlIE1Q TFMtVFAgY29udHJvbCBwbGFuZSBtdXN0IHBlcm1pdCB0aGUgdGVzdGluZyBhbmQNCiAgICAgICAg IHZhbGlkYXRpb24gb2YgcHJvdGVjdGlvbi8gcmVzdG9yYXRpb24gbWVjaGFuaXNtcyB3aGlsZSB0 aGUNCiAgICAgICAgIHdvcmtpbmcgcGF0aCBpcyBvdXQgb2Ygc2VydmljZSBbUkZDNTY1NCwgcmVx dWlyZW1lbnQgODQgRF0uDQoNCiAgIHwgICA4MiAgfCBbUkZDNDg3Ml0sIFtSRkM0ODczXSArIFRl c3RpbmcgY29udHJvbCAoU2VlIFNlYy4gNC40LjUpICAgfA0KICAgfCAgIDgzICB8IFtSRkM0ODcy XSwgW1JGQzQ4NzNdICsgVGVzdGluZyBjb250cm9sIChTZWUgU2VjLiA0LjQuNSkgICB8DQogICB8 ICAgODQgIHwgW1JGQzQ4NzJdLCBbUkZDNDg3M10gKyBUZXN0aW5nIGNvbnRyb2wgKFNlZSBTZWMu IDQuNC41KSAgIHwNCiAgIHwgICA4NSAgfCBbUkZDNDg3Ml0sIFtSRkM0ODczXSArIFRlc3Rpbmcg Y29udHJvbCAoU2VlIFNlYy4gNC40LjUpICAgfA0KDQpIb3dldmVyLCBzZWMuIDQuNC41IGlzIGRl c2NyaWJpbmcgdGhlIGRpYWdub3N0aWMgdGVzdGluZywgaW5jbHVkaW5nIA0KbG9vcGJhY2sgYW5k IHRocm91Z2hwdXQuIFRoZSB0ZXN0aW5nIGFuZCB2YWxpZGF0aW9uIHByb2Nlc3MgZGVzY2lyYmVk IGhlcmUgDQpzaG91bGQgYmUgYSBjb21tYW5kIG9mIHByb3RlY3Rpb24sIGxpa2UgdGhlIGV4ZXJj aXNlIGNvbW1hbmQgb2YgQVBTLiBBTUhPLCANCnRoZSBzb2x1dGlvbiBzaG91bGQgYmUgdGhlIHRl c3RpbmcgYml0IG9mIEFkbWluLXN0YXR1cyBvYmplY3QsIGJ1dCBJIGRpZCANCm5vdCBzZWUgYW55 IHBhdGljdWxhciB1c2FnZSBvZiB0aGUgVCBiaXQuDQoNCkIuUi4NCg0KRmVpDQoNCjopDQoNCnBh cg0KDQpJbnRlcm5ldC1EcmFmdHNAaWV0Zi5vcmcgDQq3orz+yMs6ICBjY2FtcC1ib3VuY2VzQGll dGYub3JnDQoyMDEwLTA2LTE5IDA1OjE1DQoNCsrVvP7Iyw0KaS1kLWFubm91bmNlQGlldGYub3Jn DQqzrcvNDQpjY2FtcEBpZXRmLm9yZw0K1vfM4g0KW0NDQU1QXSBJLUQgQWN0aW9uOmRyYWZ0LWll dGYtY2NhbXAtbXBscy10cC1jcC1mcmFtZXdvcmstMDIudHh0DQoNCg0KDQoNCg0KDQpBIE5ldyBJ bnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFm dHMgDQpkaXJlY3Rvcmllcy4NClRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIENvbW1v biBDb250cm9sIGFuZCBNZWFzdXJlbWVudCBQbGFuZSANCldvcmtpbmcgR3JvdXAgb2YgdGhlIElF VEYuDQoNCg0KICAgICAgICAgICAgICAgICBUaXRsZSAgICAgICAgICAgOiBNUExTLVRQIENvbnRy b2wgUGxhbmUgRnJhbWV3b3JrDQogICAgICAgICAgICAgICAgIEF1dGhvcihzKSAgICAgICA6IEwu IEFuZGVyc3NvbiwgZXQgYWwuDQogICAgICAgICAgICAgICAgIEZpbGVuYW1lICAgICAgICA6IA0K ZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLWNwLWZyYW1ld29yay0wMi50eHQNCiAgICAgICAgICAg ICAgICAgUGFnZXMgICAgICAgICAgIDogNDkNCiAgICAgICAgICAgICAgICAgRGF0ZSAgICAgICAg ICAgIDogMjAxMC0wNi0xOA0KDQpUaGUgTVBMUyBUcmFuc3BvcnQgUHJvZmlsZSAoTVBMUy1UUCkg c3VwcG9ydHMgc3RhdGljIHByb3Zpc2lvbmluZw0Kb2YgdHJhbnNwb3J0IHBhdGhzIHZpYSBhIE5l dHdvcmsgTWFuYWdlbWVudCBTeXN0ZW0gKE5NUyksIGFuZA0KZHluYW1pYyBwcm92aXNpb25pbmcg b2YgdHJhbnNwb3J0IHBhdGhzIHZpYSBhIGNvbnRyb2wgcGxhbmUuIFRoaXMNCmRvY3VtZW50IHBy b3ZpZGVzIHRoZSBmcmFtZXdvcmsgZm9yIE1QTFMtVFAgZHluYW1pYyBwcm92aXNpb25pbmcsDQph bmQgY292ZXJzIGNvbnRyb2wgcGxhbmUgYWRkcmVzc2luZywgcm91dGluZywgcGF0aCBjb21wdXRh dGlvbiwNCnNpZ25hbGluZywgdHJhZmZpYyBlbmdpbmVlcmluZywsIGFuZCBwYXRoIHJlY292ZXJ5 LiAgTVBMUy1UUCB1c2VzDQpHTVBMUyBhcyB0aGUgY29udHJvbCBwbGFuZSBmb3IgTVBMUy1UUCBM U1BzIGFuZCBwcm92aWRlcyBmb3INCmNvbXBhdGliaWxpdHkgd2l0aCBNUExTLiAgTVBMUy1UUCBh bHNvIHVzZXMgdGhlIGNvbnRyb2wgcGxhbmUgZm9yDQpQc2V1ZG93aXJlcyAoUFdzKS4gIE1hbmFn ZW1lbnQgcGxhbmUgZnVuY3Rpb25zIHN1Y2ggYXMgbWFudWFsDQpjb25maWd1cmF0aW9uIGFuZCB0 aGUgaW5pdGlhdGlvbiBvZiBMU1Agc2V0dXAgYXJlIG91dCBvZiBzY29wZSBvZg0KdGhpcyBkb2N1 bWVudC4NCg0KQSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6DQpodHRwOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWNjYW1wLW1wbHMtdHAtY3AtZnJhbWV3 b3JrLTAyLnR4dA0KDQoNCkludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5v bnltb3VzIEZUUCBhdDoNCmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCkJl bG93IGlzIHRoZSBkYXRhIHdoaWNoIHdpbGwgZW5hYmxlIGEgTUlNRSBjb21wbGlhbnQgbWFpbCBy ZWFkZXINCmltcGxlbWVudGF0aW9uIHRvIGF1dG9tYXRpY2FsbHkgcmV0cmlldmUgdGhlIEFTQ0lJ IHZlcnNpb24gb2YgdGhlDQpJbnRlcm5ldC1EcmFmdC4NCmZ0cDovL2Fub255bW91c0BmdHAuaWV0 Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtY2NhbXAtbXBscy10cC1jcC1mcmFtZXdv cmstMDIudHh0DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KQ0NBTVAgbWFpbGluZyBsaXN0DQpDQ0FNUEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KDQoNCg== --=_alternative 0014CD094825774C_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIGFsbDwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+V2hlbiB3cml0aW5nIHRoZSByZXF1 aXJlbWVudHMgb2YgUjgyLzgzLzg0Lzg1LA0KdGhlIGZvbGxvd2luZyB0YWJsZSBnaXZlIHRoZSB0 aXBzIG9mIHRoZSBzb2x1dGlvbjo8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPjx0dD4m bmJzcDsgJm5ic3A7ICZuYnNwOzgyLiBUaGUgTVBMUy1UUCBjb250cm9sIHBsYW5lDQptdXN0IHBl cm1pdCB0aGUgdGVzdGluZyBhbmQ8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHZh bGlkYXRpb24gb2YgdGhlIGludGVncml0eSBvZiB0aGUgcHJvdGVjdGlvbi9yZWNvdmVyeTxicj4N CiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdHJhbnNwb3J0IHBhdGggW1JGQzU2NTQsIHJl cXVpcmVtZW50IDg0IEFdLjxicj4NCjxicj4NCiAmbmJzcDsgJm5ic3A7IDgzLiBUaGUgTVBMUy1U UCBjb250cm9sIHBsYW5lIG11c3QgcGVybWl0IHRoZSB0ZXN0aW5nIGFuZDxicj4NCiAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgdmFsaWRhdGlvbiBvZiBwcm90ZWN0aW9uLyByZXN0b3JhdGlv biBtZWNoYW5pc21zDQp3aXRob3V0PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB0 cmlnZ2VyaW5nIHRoZSBhY3R1YWwgcHJvdGVjdGlvbi9yZXN0b3JhdGlvbg0KW1JGQzU2NTQsPGJy Pg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyByZXF1aXJlbWVudCA4NCBCXS48YnI+DQo8 YnI+DQogJm5ic3A7ICZuYnNwOyA4NC4gVGhlIE1QTFMtVFAgY29udHJvbCBwbGFuZSBtdXN0IHBl cm1pdCB0aGUgdGVzdGluZyBhbmQ8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHZh bGlkYXRpb24gb2YgcHJvdGVjdGlvbi8gcmVzdG9yYXRpb24gbWVjaGFuaXNtcw0Kd2hpbGUgdGhl PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB3b3JraW5nIHBhdGggaXMgaW4gc2Vy dmljZSBbUkZDNTY1NCwgcmVxdWlyZW1lbnQNCjg0IENdLjxicj4NCjxicj4NCiAmbmJzcDsgJm5i c3A7IDg1LiBUaGUgTVBMUy1UUCBjb250cm9sIHBsYW5lIG11c3QgcGVybWl0IHRoZSB0ZXN0aW5n IGFuZDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdmFsaWRhdGlvbiBvZiBwcm90 ZWN0aW9uLyByZXN0b3JhdGlvbiBtZWNoYW5pc21zDQp3aGlsZSB0aGU8YnI+DQogJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IHdvcmtpbmcgcGF0aCBpcyBvdXQgb2Ygc2VydmljZSBbUkZDNTY1 NCwgcmVxdWlyZW1lbnQNCjg0IERdLjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 Mz48dHQ+Jm5ic3A7ICZuYnNwO3wgJm5ic3A7IDgyICZuYnNwO3wgWzwvdHQ+PC9mb250PjxhIGhy ZWY9aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDg3Mj48Zm9udCBzaXplPTMgY29sb3I9 Ymx1ZT48dHQ+PHU+UkZDNDg3MjwvdT48L3R0PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zPjx0dD5d LA0KWzwvdHQ+PC9mb250PjxhIGhyZWY9aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDg3 Mz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dHQ+PHU+UkZDNDg3MzwvdT48L3R0PjwvZm9udD48 L2E+PGZvbnQgc2l6ZT0zPjx0dD5dDQorIFRlc3RpbmcgY29udHJvbCAoU2VlIFNlYy4gNC40LjUp ICZuYnNwOyB8PGJyPg0KICZuYnNwOyB8ICZuYnNwOyA4MyAmbmJzcDt8IFs8L3R0PjwvZm9udD48 YSBocmVmPWh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ4NzI+PGZvbnQgc2l6ZT0zIGNv bG9yPWJsdWU+PHR0Pjx1PlJGQzQ4NzI8L3U+PC90dD48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz48 dHQ+XSwNCls8L3R0PjwvZm9udD48YSBocmVmPWh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzQ4NzM+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHR0Pjx1PlJGQzQ4NzM8L3U+PC90dD48L2Zv bnQ+PC9hPjxmb250IHNpemU9Mz48dHQ+XQ0KKyBUZXN0aW5nIGNvbnRyb2wgKFNlZSBTZWMuIDQu NC41KSAmbmJzcDsgfDxicj4NCiAmbmJzcDsgfCAmbmJzcDsgODQgJm5ic3A7fCBbPC90dD48L2Zv bnQ+PGEgaHJlZj1odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0ODcyPjxmb250IHNpemU9 MyBjb2xvcj1ibHVlPjx0dD48dT5SRkM0ODcyPC91PjwvdHQ+PC9mb250PjwvYT48Zm9udCBzaXpl PTM+PHR0Pl0sDQpbPC90dD48L2ZvbnQ+PGEgaHJlZj1odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9yZmM0ODczPjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx0dD48dT5SRkM0ODczPC91PjwvdHQ+ PC9mb250PjwvYT48Zm9udCBzaXplPTM+PHR0Pl0NCisgVGVzdGluZyBjb250cm9sIChTZWUgU2Vj LiA0LjQuNSkgJm5ic3A7IHw8YnI+DQogJm5ic3A7IHwgJm5ic3A7IDg1ICZuYnNwO3wgWzwvdHQ+ PC9mb250PjxhIGhyZWY9aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDg3Mj48Zm9udCBz aXplPTMgY29sb3I9Ymx1ZT48dHQ+PHU+UkZDNDg3MjwvdT48L3R0PjwvZm9udD48L2E+PGZvbnQg c2l6ZT0zPjx0dD5dLA0KWzwvdHQ+PC9mb250PjxhIGhyZWY9aHR0cDovL3Rvb2xzLmlldGYub3Jn L2h0bWwvcmZjNDg3Mz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZT48dHQ+PHU+UkZDNDg3MzwvdT48 L3R0PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0zPjx0dD5dDQorIFRlc3RpbmcgY29udHJvbCAoU2Vl IFNlYy4gNC40LjUpICZuYnNwOyB8PC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPkhvd2V2ZXIsIHNlYy4gNC40LjUgaXMgZGVzY3JpYmluZyB0aGUN CmRpYWdub3N0aWMgdGVzdGluZywgaW5jbHVkaW5nIGxvb3BiYWNrIGFuZCB0aHJvdWdocHV0LiBU aGUgdGVzdGluZyBhbmQNCnZhbGlkYXRpb24gcHJvY2VzcyBkZXNjaXJiZWQgaGVyZSBzaG91bGQg YmUgYSBjb21tYW5kIG9mIHByb3RlY3Rpb24sIGxpa2UNCnRoZSBleGVyY2lzZSBjb21tYW5kIG9m IEFQUy4gQU1ITywgdGhlIHNvbHV0aW9uIHNob3VsZCBiZSB0aGUgdGVzdGluZyBiaXQNCm9mIEFk bWluLXN0YXR1cyBvYmplY3QsIGJ1dCBJIGRpZCBub3Qgc2VlIGFueSBwYXRpY3VsYXIgdXNhZ2Ug b2YgdGhlIFQNCmJpdC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPjx0dD5CLlIuPC90 dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0zPjx0dD5GZWk8L3R0PjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTM+PHR0PjopPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnBhcjwvZm9udD4NCjxicj4NCjx0YWJsZSB3aWR0aD0x MDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9MzQlPjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj48Yj5JbnRlcm5ldC1EcmFmdHNAaWV0Zi5vcmc8L2I+DQo8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7Y2NhbXAtYm91bmNl c0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEw LTA2LTE5IDA1OjE1PC9mb250Pg0KPHRkIHdpZHRoPTY1JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0K PHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNl PSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPmktZC1hbm5vdW5jZUBpZXRmLm9yZzwvZm9udD4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Y2Nh bXBAaWV0Zi5vcmc8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmln aHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+ PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPltDQ0FNUF0gSS1EIEFjdGlvbjpkcmFmdC1p ZXRmLWNjYW1wLW1wbHMtdHAtY3AtZnJhbWV3b3JrLTAyLnR4dDwvZm9udD48L3RhYmxlPg0KPGJy Pg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3Rh YmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+QSBOZXcgSW50ZXJuZXQtRHJh ZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUNCkludGVybmV0LURyYWZ0cyBkaXJlY3Rv cmllcy48YnI+DQpUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBDb21tb24gQ29udHJv bCBhbmQgTWVhc3VyZW1lbnQgUGxhbmUgV29ya2luZw0KR3JvdXAgb2YgdGhlIElFVEYuPGJyPg0K PGJyPg0KPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsNClRpdGxlICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgOiBN UExTLVRQIENvbnRyb2wgUGxhbmUgRnJhbWV3b3JrPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCkF1dGhvcihzKSAmbmJzcDsgJm5i c3A7ICZuYnNwOyA6IEwuIEFuZGVyc3NvbiwgZXQgYWwuPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCkZpbGVuYW1lICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOzogZHJhZnQtaWV0Zi1jY2FtcC1tcGxzLXRwLWNwLWZyYW1ld29y ay0wMi50eHQ8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KUGFnZXMgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA6 IDQ5PGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsNCkRhdGUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs6 IDIwMTAtMDYtMTg8YnI+DQo8YnI+DQpUaGUgTVBMUyBUcmFuc3BvcnQgUHJvZmlsZSAoTVBMUy1U UCkgc3VwcG9ydHMgc3RhdGljIHByb3Zpc2lvbmluZzxicj4NCm9mIHRyYW5zcG9ydCBwYXRocyB2 aWEgYSBOZXR3b3JrIE1hbmFnZW1lbnQgU3lzdGVtIChOTVMpLCBhbmQ8YnI+DQpkeW5hbWljIHBy b3Zpc2lvbmluZyBvZiB0cmFuc3BvcnQgcGF0aHMgdmlhIGEgY29udHJvbCBwbGFuZS4gVGhpczxi cj4NCmRvY3VtZW50IHByb3ZpZGVzIHRoZSBmcmFtZXdvcmsgZm9yIE1QTFMtVFAgZHluYW1pYyBw cm92aXNpb25pbmcsPGJyPg0KYW5kIGNvdmVycyBjb250cm9sIHBsYW5lIGFkZHJlc3NpbmcsIHJv dXRpbmcsIHBhdGggY29tcHV0YXRpb24sPGJyPg0Kc2lnbmFsaW5nLCB0cmFmZmljIGVuZ2luZWVy aW5nLCwgYW5kIHBhdGggcmVjb3ZlcnkuICZuYnNwO01QTFMtVFAgdXNlczxicj4NCkdNUExTIGFz IHRoZSBjb250cm9sIHBsYW5lIGZvciBNUExTLVRQIExTUHMgYW5kIHByb3ZpZGVzIGZvcjxicj4N CmNvbXBhdGliaWxpdHkgd2l0aCBNUExTLiAmbmJzcDtNUExTLVRQIGFsc28gdXNlcyB0aGUgY29u dHJvbCBwbGFuZSBmb3I8YnI+DQpQc2V1ZG93aXJlcyAoUFdzKS4gJm5ic3A7TWFuYWdlbWVudCBw bGFuZSBmdW5jdGlvbnMgc3VjaCBhcyBtYW51YWw8YnI+DQpjb25maWd1cmF0aW9uIGFuZCB0aGUg aW5pdGlhdGlvbiBvZiBMU1Agc2V0dXAgYXJlIG91dCBvZiBzY29wZSBvZjxicj4NCnRoaXMgZG9j dW1lbnQuPGJyPg0KPGJyPg0KQSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6PGJyPg0K aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1jY2FtcC1tcGxz LXRwLWNwLWZyYW1ld29yay0wMi50eHQ8YnI+DQo8YnI+DQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFs c28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6PGJyPg0KZnRwOi8vZnRwLmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy88YnI+DQo8YnI+DQpCZWxvdyBpcyB0aGUgZGF0YSB3aGljaCB3aWxs IGVuYWJsZSBhIE1JTUUgY29tcGxpYW50IG1haWwgcmVhZGVyPGJyPg0KaW1wbGVtZW50YXRpb24g dG8gYXV0b21hdGljYWxseSByZXRyaWV2ZSB0aGUgQVNDSUkgdmVyc2lvbiBvZiB0aGU8YnI+DQpJ bnRlcm5ldC1EcmFmdC48YnI+DQo8L3R0PjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+ZnRwOi8vYW5vbnltb3VzQGZ0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt aWV0Zi1jY2FtcC1tcGxzLXRwLWNwLWZyYW1ld29yay0wMi50eHQ8L2ZvbnQ+PGZvbnQgc2l6ZT0y Pjx0dD5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CkNDQU1QIG1haWxpbmcgbGlzdDxicj4NCkNDQU1QQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcDxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPg0K --=_alternative 0014CD094825774C_=-- From wwwrun@core3.amsl.com Thu Jun 24 10:16:14 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id EE69D3A6A31; Thu, 24 Jun 2010 10:16:13 -0700 (PDT) To: zhangrenhai@huawei.com,mach@huawei.com From: IETF Secretariat Message-Id: <20100624171613.EE69D3A6A31@core3.amsl.com> Date: Thu, 24 Jun 2010 10:16:13 -0700 (PDT) Cc: ccamp@ietf.org, adrian.farrel@huawei.com, dbrungard@att.com, ipr-announce@ietf.org Subject: [CCAMP] IPR Disclosure: HUAWEI TECHNOLOGIES CO., LTD's Statement about IPR related to RFC 5392 (2) X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 24 Jun 2010 17:16:14 -0000 Dear Renhai Zhang, Mach Chen: An IPR disclosure that pertains to your RFC entitled "OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering" (RFC5392) was submitted to the IETF Secretariat on 2010-06-17 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1330/). The title of the IPR disclosure is "HUAWEI TECHNOLOGIES CO.,LTD's Statement about IPR related to RFC 5392 (2)." The IETF Secretariat From wwwrun@core3.amsl.com Thu Jun 24 14:28:02 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 971F73A68D8; Thu, 24 Jun 2010 14:28:02 -0700 (PDT) From: Greg Jones(ITU-T SG 15) To: lberger@labn.net, dbrungard@att.com, jpv@cisco.com, julien.meuric@orange-ftgroup.com, swallow@cisco.com, loa@pi.nu Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100624212802.971F73A68D8@core3.amsl.com> Date: Thu, 24 Jun 2010 14:28:02 -0700 (PDT) Cc: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, steve.trowbridge@alcatel-lucent.com, ccamp@ietf.org, yoichi.maeda@ntt-at.co.jp, paf@cisco.com, adrian.farrel@huawei.com, tsbsg15@itu.int, rcallon@juniper.net, pce@ietf.org Subject: [CCAMP] New Liaison Statement, "LS204 - SG15 OTNT standardization work plan" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 21:28:03 -0000 Title: LS204 - SG15 OTNT standardization work plan Submission Date: 2010-06-24 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=913 Please reply by 2011-02-01 From: Greg Jones(ITU-T SG 15) To: IETF CCAMP, PCE and MPLS WGs(lberger@labn.net,dbrungard@att.com,jpv@cisco.com,julien.meuric@orange-ftgroup.com,swallow@cisco.com,loa@pi.nu) Cc: paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com rcallon@juniper.net mpls@ietf.org pce@ietf.org ccamp@ietf.org yoichi.maeda@ntt-at.co.jp steve.trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: koike.yoshinori@lab.ntt.co.jp Purpose: For comment Body: Attachment(s): LS204 - SG15 OTNT standardization work plan - pdf body (https://datatracker.ietf.org/documents/LIAISON/file1054.pdf) LS204 - SG15 OTNT standardization work plan - pdf attach (https://datatracker.ietf.org/documents/LIAISON/file1055.pdf) From wwwrun@core3.amsl.com Thu Jun 24 15:48:14 2010 Return-Path: X-Original-To: ccamp@ietf.org Delivered-To: ccamp@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 431283A69A8; Thu, 24 Jun 2010 15:48:13 -0700 (PDT) From: Greg Jones(ITU-T SG 15) To: lberger@labn.net,dbrungard@att.com,swallow@cisco.com,loa@pi.nu Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20100624224814.431283A69A8@core3.amsl.com> Date: Thu, 24 Jun 2010 15:48:14 -0700 (PDT) Cc: mpls@ietf.org, hiroshi.ota@itu.int, greg.jones@itu.int, steve.trowbridge@alcatel-lucent.com, ccamp@ietf.org, yoichi.maeda@ntt-at.co.jp, paf@cisco.com, adrian.farrel@huawei.com, rcallon@juniper.net, tsbsg15@itu.int Subject: [CCAMP] New Liaison Statement, "LS212 - Approval process initiated for G.7714.1 revision" X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: tsbsg15@itu.int List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jun 2010 22:48:14 -0000 Title: LS212 - Approval process initiated for G.7714.1 revision Submission Date: 2010-06-24 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=919 From: Greg Jones(ITU-T SG 15) To: IETF CCAMP and MPLS WGs(lberger@labn.net,dbrungard@att.com,swallow@cisco.com,loa@pi.nu) Cc: paf@cisco.com stbryant@cisco.com adrian.farrel@huawei.com rcallon@juniper.net mpls@ietf.org ccamp@ietf.org yoichi.maeda@ntt-at.co.jp steve.trowbridge@alcatel-lucent.com Reponse Contact: tsbsg15@itu.int greg.jones@itu.int hiroshi.ota@itu.int Technical Contact: Kam.Lam@alcatel-lucent.com Purpose: For information Body: We are pleased to inform the IETF that the revision to Recommendation G.7714.1, Protocol for automatic discovery in SDH and OTN networks, has been put into the approval process from the 31 May � 11 June 2010 Study Group 15 Plenary Meeting in Geneva. This version of G.7714.1 includes the previously agreed study points. Attach: TD230R1/PLEN � The text of G.7714.1 Revision. Attachment(s): LS212 - Approval process initiated for G.7714.1 revision - pdf body (https://datatracker.ietf.org/documents/LIAISON/file1064.pdf) LS212 - Approval process initiated for G.7714.1 revision - pdf 230r1 (https://datatracker.ietf.org/documents/LIAISON/file1065.pdf) From daniel@olddog.co.uk Fri Jun 25 03:21:35 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66F2A3A695F for ; Fri, 25 Jun 2010 03:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.673 X-Spam-Level: X-Spam-Status: No, score=-0.673 tagged_above=-999 required=5 tests=[AWL=1.326, BAYES_00=-2.599, J_CHICKENPOX_52=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fw6TP1xYNgC1 for ; Fri, 25 Jun 2010 03:21:31 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by core3.amsl.com (Postfix) with ESMTP id 456683A6974 for ; Fri, 25 Jun 2010 03:21:28 -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 o5PALRW9005338; Fri, 25 Jun 2010 11:21:27 +0100 Received: from Serenity (88-97-23-122.dsl.zen.co.uk [88.97.23.122]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id o5PALQow005322; Fri, 25 Jun 2010 11:21:26 +0100 From: "Daniel King" To: Date: Fri, 25 Jun 2010 11:21:27 +0100 Message-ID: <002901cb1450$2c36a8f0$84a3fad0$@co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-gb Thread-index: AcsUUCuebxsadpNGQ+KSm58GS8M1cQ== Cc: dbrungard@att.com Subject: [CCAMP] Agenda Requests for IETF 78 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 25 Jun 2010 10:21:35 -0000 Hello CCAMP'rs, Please let us know if you have an agenda request for our CCAMP sessions at IETF 78. Reply to this email (please also CC the co-chairs) with the desired duration, topic/draft title, and presenter for each slot that you request. Please let us have your requests by Monday, July 12th. Key dates are at: http://www.ietf.org/meeting/cutoff-dates-2010.html#IETF78 2010-07-05 (Monday): Internet Draft Cut-off for initial document (-00) submission by 17:00 PDT (24:00 UTC). 2010-07-12 (Monday): Internet Draft final submission cut-off by 17:00 PDT (24:00 UTC). The preliminary agenda has now been posted: https://datatracker.ietf.org/meeting/78/agenda.html Br, Dan. From curtis@occnc.com Wed Jun 30 00:02:12 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51EEA3A683C for ; Wed, 30 Jun 2010 00:02:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.392 X-Spam-Level: X-Spam-Status: No, score=-0.392 tagged_above=-999 required=5 tests=[AWL=0.348, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2R5v7TIU6xa for ; Wed, 30 Jun 2010 00:02:08 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by core3.amsl.com (Postfix) with ESMTP id 1F4D23A6847 for ; Wed, 30 Jun 2010 00:02:08 -0700 (PDT) Received: from harbor.orleans.occnc.com (harbor.orleans.occnc.com [173.9.106.135]) by harbor.orleans.occnc.com (8.13.6/8.13.6) with ESMTP id o5U72GWq003232; Wed, 30 Jun 2010 03:02:17 -0400 (EDT) (envelope-from curtis@harbor.orleans.occnc.com) Message-Id: <201006300702.o5U72GWq003232@harbor.orleans.occnc.com> To: Lou Berger , Deborah Brungard From: Curtis Villamizar Date: Wed, 30 Jun 2010 03:02:16 -0400 Sender: curtis@occnc.com Cc: ccamp@ietf.org Subject: [CCAMP] please consider draft-villamizar-mpls-tp-multipath as WG item X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: curtis@occnc.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, 30 Jun 2010 07:02:12 -0000 CCAMP WG, Please consider adopting draft-villamizar-mpls-tp-multipath-00 as a WG item. Lou, Deb, Even though this is just beyond 24 hours after you asked that time slots be requested, please try to fit in a short time slot at IETF78. Curtis ------- Forwarded Message [multiple blank lines removed] From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Tuesday, June 29, 2010 9:51 PM To: Curtis Villamizar Subject: New Version Notification for draft-villamizar-mpls-tp-multipath-00 A new version of I-D, draft-villamizar-mpls-tp-multipath-00.txt has been successfully submitted by Curtis Villamizar and posted to the IETF repository. Filename: draft-villamizar-mpls-tp-multipath Revision: 00 Title: Use of Multipath with MPLS-TP and MPLS Creation_date: 2010-06-29 WG ID: Independent Submission Number_of_pages: 35 Abstract: Many MPLS implementations have supported multipath techniques and many MPLS deployments have used multipath techniques, particularly in very high bandwidth applications, such as provider IP/MPLS core networks. MPLS-TP has discouraged the use of multipath techniques. Some degradation of MPLS-TP OAM performance cannot be avoided when operating over current high bandwidth multipath implementations. The tradeoffs involved in using multipath techniques with MPLS and MPLS-TP are described. Requirements are discussed which enable full MPLS-TP compliant LSP including full OAM capability to be carried over MPLS LSP which are traversing multipath links. Other means of supporting MPLS-TP coexisting with MPLS and multipath are discussed. The IETF Secretariat. ------- End of Forwarded Message From loa@pi.nu Wed Jun 30 02:52:41 2010 Return-Path: X-Original-To: ccamp@core3.amsl.com Delivered-To: ccamp@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E78B73A6A5A; Wed, 30 Jun 2010 02:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.153 X-Spam-Level: X-Spam-Status: No, score=-2.153 tagged_above=-999 required=5 tests=[AWL=0.446, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nO9RBtEDQ5ji; Wed, 30 Jun 2010 02:52:41 -0700 (PDT) Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by core3.amsl.com (Postfix) with ESMTP id 05C1E3A69AA; Wed, 30 Jun 2010 02:52:40 -0700 (PDT) Received: from [90.232.194.45] (host-90-232-194-45.mobileonline.telia.com [90.232.194.45]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id 09E5CD4058; Wed, 30 Jun 2010 11:52:50 +0200 (CEST) Message-ID: <4C2B1408.7010906@pi.nu> Date: Wed, 30 Jun 2010 11:53:12 +0200 From: Loa Andersson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: CCAMP , mpls@ietf.org References: <4C04B508.1080706@pi.nu> <4C1610C7.4000103@pi.nu> In-Reply-To: <4C1610C7.4000103@pi.nu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [CCAMP] [mpls] joint ccamp and mpls working group last call on draft-ietf-mpls-explicit-resource-control-bundle+07 X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.9 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, 30 Jun 2010 09:52:42 -0000 All, this wg last call has ended. /Loa On 2010-06-14 13:21, Loa Andersson wrote: > Working groups, > > we have seen no responses to this last call. The normal > interpretation would be that there are no comments and the > draft is ready to progress. However, because of the special > nature of this working group last call, we won't lightly > subscribe to this interpretation. > > The wg last call is therefore extended one week and people > supporting this draft being published as in RFC are encourage > to state this on the list. If you have concerns you are of > course also encourage to state this on the list. > > The working group last call will end eob June 25th. > > /Loa > > > > On 2010-06-01 09:21, Loa Andersson wrote: >> >> >> All, >> >> in mid-February the draft-ietf-mpls-explicit-resource-control-bundle >> was retruned to the MPLS Working Group from the responsible AD >> stating that: >> >> - it had been a long time since the working group last call >> - the version that were working group last called was much earlier >> than the one we requested publication for, i.e. the document has >> changed many times since the wg last call >> - this document is also of interest for the CCAMP working group, and >> the working group last call should have been jointly between MPLS >> and CCAMP >> - there is a need to poll both working group to see if there is >> an interest in this draft. >> >> However it also needs to pointed out that there are at least two deployed >> implementations and we need to amke the reservation of the code points >> in the IANA section. >> >> This is to start a joint CCAMP and MPLS working group last call on >> draft-ietf-mpls-explicit-resource-control-bundle-07. >> >> Please send your comments to the mpls and ccamp working group list. >> >> >> >> The joint working group last call ends eob June 16. >> >> >> /Loa > -- Loa Andersson email: loa.andersson@ericsson.com Sr Strategy and Standards Manager loa@pi.nu Ericsson Inc phone: +46 10 717 52 13 +46 767 72 92 13