From zhangfatai@huawei.com Sun Sep 4 19:50:28 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4011321F8880 for ; Sun, 4 Sep 2011 19:50:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.243 X-Spam-Level: X-Spam-Status: No, score=-5.243 tagged_above=-999 required=5 tests=[AWL=1.355, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KM-zWQit3M-d for ; Sun, 4 Sep 2011 19:50:27 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id EF9F721F8876 for ; Sun, 4 Sep 2011 19:50:26 -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 <0LR100IO13YSI5@szxga03-in.huawei.com> for ccamp@ietf.org; Mon, 05 Sep 2011 10:52:04 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LR1008SB3YR15@szxga03-in.huawei.com> for ccamp@ietf.org; Mon, 05 Sep 2011 10:52:04 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADP44045; Mon, 05 Sep 2011 10:51:44 +0800 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 05 Sep 2011 10:51:43 +0800 Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.184]) by szxeml405-hub.china.huawei.com ([169.254.211.222]) with mapi id 14.01.0270.001; Mon, 05 Sep 2011 10:51:41 +0800 Date: Mon, 05 Sep 2011 02:50:57 +0000 From: Zhangfatai X-Originating-IP: [10.70.76.157] To: "swallow@cisco.com" , John E Drake , "hirokazu.ishimatsu@g1m.jp" , "yakov@juniper.net" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_TyipNHw13VJmb5DTB6sU2Q)" Content-language: en-US Accept-Language: zh-CN, en-US Thread-topic: Request comments on draft-zhang-ccamp-gmpls-uni-app Thread-index: Acxrdr0SFBrE1D91SomoO4dOu28dGQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected Cc: CCAMP Subject: [CCAMP] Request comments on draft-zhang-ccamp-gmpls-uni-app X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2011 02:50:28 -0000 --Boundary_(ID_TyipNHw13VJmb5DTB6sU2Q) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Hi Authors of RFC4208 and CCAMpers, I am updating [draft-zhang-ccamp-gmpls-uni-app], do you have any comments on this draft? Any comments or suggestions are appreciated. Thanks Fatai --Boundary_(ID_TyipNHw13VJmb5DTB6sU2Q) Content-type: text/html; charset=us-ascii Content-transfer-encoding: quoted-printable

Hi Authors of RFC4208 and CCA= Mpers,

 

I am updating [draft-zhang-ccamp-gmpls-uni-app], do you have any comments = on this draft?

 

Any comments or suggestions a= re appreciated.

 

 

 

Thanks
 
Fatai

 

--Boundary_(ID_TyipNHw13VJmb5DTB6sU2Q)-- From daniele.ceccarelli@ericsson.com Tue Sep 6 07:29:46 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B600521F8997 for ; Tue, 6 Sep 2011 07:29:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.155 X-Spam-Level: X-Spam-Status: No, score=-4.155 tagged_above=-999 required=5 tests=[AWL=2.443, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnF+l9ZkX6SM for ; Tue, 6 Sep 2011 07:29:46 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6F46721F87D9 for ; Tue, 6 Sep 2011 07:29:45 -0700 (PDT) X-AuditID: c1b4fb39-b7bfdae000005125-93-4e662ec393d5 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E5.75.20773.3CE266E4; Tue, 6 Sep 2011 16:31:31 +0200 (CEST) Received: from ESESSCMS0360.eemea.ericsson.se ([169.254.1.84]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Tue, 6 Sep 2011 16:31:30 +0200 From: Daniele Ceccarelli To: 'CCAMP' Date: Tue, 6 Sep 2011 16:31:29 +0200 Thread-Topic: OTN OSPF draft Thread-Index: AcxsoarC74aS+C5MQhCBtlubPw9cKw== Message-ID: Accept-Language: it-IT, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: it-IT, en-US Content-Type: multipart/mixed; boundary="_005_B5630A95D803744A81C51AD4040A6DAA141A62B8B6ESESSCMS0360e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [CCAMP] OTN OSPF draft X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 14:29:46 -0000 --_005_B5630A95D803744A81C51AD4040A6DAA141A62B8B6ESESSCMS0360e_ Content-Type: multipart/alternative; boundary="_000_B5630A95D803744A81C51AD4040A6DAA141A62B8B6ESESSCMS0360e_" --_000_B5630A95D803744A81C51AD4040A6DAA141A62B8B6ESESSCMS0360e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi CCAMPers, The new version of the OTN OSPF draft has been published and can be found a= t the following link: http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-ospf-g709-07 Main changes address comments/feedback received at the IETF 81 meeting in Q= uebec City and consist on: - Removing the SCSI TLV --> single SCSI per ISCD and consequent unbundling = of component links with dissimilar hierarchies. In other words, what was su= pposed to be split into different SCSI TLV is now split into different ISCD= s - Removing the F flag for the distinction between unres bandwidth and max l= sp bandwidht for flexible container and adding the Bandwdith TLV type 3 (ty= pe 2 is now for unres band and type 3 for max lsp band). - Adding the TSG advertisement - Adding an example of MAX LSP Bandwidth fields in the ISCD common part - Adding some text expalining the T,S bits example - Updating the examples accordingly with the modifications - Zero padding to 32 bit alignment in case of odd supported priorities. ...Nits here and there. Thanks The authors DANIELE CECCARELLI System & Technology - DU IP & Broadband Via L.Calda, 5 Genova, Italy Phone +390106002512 Mobile +393346725750 daniele.ceccarelli@ericsson.com www.ericsson.com This Communication is Confidential. We only send and receive email on the b= asis of the term set out at www.ericsson.com/email_disclaimer --_000_B5630A95D803744A81C51AD4040A6DAA141A62B8B6ESESSCMS0360e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi CCAMPers,
 
The new version of the OTN OSPF draft has been published and can be fo= und at the following link:
 
 
 
Main changes address comments/feedback received at the IETF 81 meeting= in Quebec City and consist on:
 
- Removing the SCSI TL= V --> single SCSI per ISCD and consequent unbundling of component links = with dissimilar hierarchies. In other words, what was supposed to be split = into different SCSI TLV is now split into different ISCDs
- Removing the F flag for the distinction between unres bandwidth and max l= sp bandwidht for flexible container and adding the Bandwdith TLV type 3 (ty= pe 2 is now for unres band and type 3 for max lsp band).
- Adding the TSG advertisement
- Adding an example of MAX LSP Bandwidth fields in the ISCD common p= art
- Adding some text expalining the T,S bits example
- Updating the examples accordingly with the modifications
- Zero padding to 32 bit alignment in case of odd supported prioriti= es.
...Nits here and there= .
Thanks
The authors
 
 



DANIELE CECCARE= LLI
System & Te= chnology - DU IP & Broadband

Via L.Calda, 5
Genova, Italy
Phone +390106002512
Mobile +393346725750
daniele.ceccarelli@ericsson.com
www.ericsson.com

This Communication is Con= fidential. We only send and receive email on the basis of the term set out = at www.ericsson.com/email_disclaime= r
 
 
--_000_B5630A95D803744A81C51AD4040A6DAA141A62B8B6ESESSCMS0360e_-- --_005_B5630A95D803744A81C51AD4040A6DAA141A62B8B6ESESSCMS0360e_ 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="Tue, 06 Sep 2011 14:31:30 GMT"; modification-date="Tue, 06 Sep 2011 14:31:30 GMT" Content-ID: <299a57d1-3e37-4f6d-aa41-e8b3b39ee52e> 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_B5630A95D803744A81C51AD4040A6DAA141A62B8B6ESESSCMS0360e_ 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="Tue, 06 Sep 2011 14:31:30 GMT"; modification-date="Tue, 06 Sep 2011 14:31:30 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABRAfQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwDz6TVN QErj7fdfeP8Ay2b/ABpv9q6h/wA/91/3+b/Gq0v+uf8A3jTK96yPLuy5/amof8/91/3+b/Gj+1NR /wCf+6/7/N/jS6XpV9reoxafp1u091Lnai8cDqSewHrXqehfAu5k2y67qawr1MFoNzfQuePyBrOd SnT+IuEJy2PKv7V1DIH2+6yeAPObn9ac2pamjlHvLxGHVWkYEfga+kbXw74J8CWwuXisrRgP+Pi7 cNI30Lc/lXj/AMVPFWjeKdZtJNHUyLbxsklyU2+YSeAM8kDB596zp1lUlaMdO5c6XJG7epxv9qah /wA/91/3+b/Gj+1NQ/5/7r/v83+NVKK6LIxuz638LMz+EdFZmLMbCAkk5JPlrWtWR4V/5E/RP+vC D/0Wta9eHL4menHZBRRRUjCiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigA ooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACi iigAooooA+NJf9c/+8abTpf9c/8AvGm1755Ru+DdZ1HQfE9reaVafbLo5iFsFJMgbqBjn3z7V7as fxH8TKPMks/DNm3UIPOuCP5CvFfBXiP/AIRXxRb6obU3ShWiaJfvENx8vvXtS+JfHHiRQNB8PJpN qw/4/NVb5seqxjn864sSnzXSXqzqotctrlux+GvhvTZDqGrvLqt0vLXWqTbwPfB4FeU/Fi78NXWu 2v8Awjwti6Rst09qoEZORtHHBI56V6dF8Mv7SlW48W67fa1IOfIL+VAPoq9vyrzD4r6N4d0XW7SD QRFE5iP2m3hfcsZB+U+xPPHtUYdp1NZNv8CqqahtY4Cloor0DjPrbwr/AMifon/XhB/6LWtesjwr /wAifon/AF4Qf+i1rXrwpfEz1I7IKKKKkYUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFAHxpL/rX/AN402rNvatfarDZxsFe4nESs3QFmwM/nXWTfDe6j1y20dNZs ZbyeZoSqxyARlVLEkkYI+XHHrXuOcY6M8xRb2M7wHrth4b8XWup6jA0tsispKruMZIwHA74/rXp2 ufHPT4A0eh6fLdv2muP3afl94/pXnz/Dm/EsAi1Kxngnt57iOdN4BEON6lSAQeeDVa48EzWVpbfb dX0+31K6jSWHTXLGVgxwoJAwpOehrGcaNSXMzWLqRVkJrnxC8T+INyXWpyQwN/ywtf3S/jjk/ia5 eu2f4bXg15NGj1aykvQjSXCeXIvkKoBJ5HzjkD5e9VLfwT5/224Ou2EOl2jpE9/Kkiq0jdECEbsj IznpmtIzpxXukOM29TlaK7Kb4Z65BY6xcs9uzaWRvjQljKpUNuQ9xtOfwNc/r+iz+HtYl024ljll jRHLx52kMoYdfrVRqRk7JkuElqz6k8K/8ifon/XhB/6LWtesjwr/AMifon/XhB/6LWtevFl8TPSj sgoooqRhRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAfHtpdf YdZt7zZv+z3Cy7M43bWzj9K7y6+KMVxr9lqw0/UCba4afyJr/fH8yMuFXbhfvV51L/rn/wB402vc lTjLVnmRm46I7sfEmSZ7W5v7GS5vobS5s2uDMAZElPy5GOq/rVDU/FOk67BBcarosz6vFAkBuoLs okgXozLjg49K5OkpKlBaoftJPc9AuviJaXSabbmy1UQWLvIk51DN0GIwAJMfdA7HOePSk1H4jWmu G+tdX0RptMuWikWOK42yq8YxuL4w24cGuBopexh2H7WR6BJ8VLxrh7iOwWNzfRXCKsmVEKR+X5R4 5yCeffpXMeK9dXxL4judWS2+zLMqKId27aFUDr+FY1FONKMXdITnKSsz628K/wDIn6J/14Qf+i1r XrI8K/8AIn6J/wBeEH/ota168aXxM9GOyCiiipGFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFA BRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAF FFFABRRRQAUUUUAFFFFABRRRQB8aS/65/wDeNNp0v+tf/eNNr3zygooooAKKKKACkpaKAPrbwr/y J+if9eEH/ota16yPCv8AyJ+if9eEH/ota168KXxM9SOyCiiipGFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQB8kyf61/9402iivbPMCiiigAooooAKDRRQB9R+Gf +RU0f/rxh/8AQBWrRRXiy3Z6S2CiiikMKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAo oooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACii igAooooAKKKKACiiigD/2Q== --_005_B5630A95D803744A81C51AD4040A6DAA141A62B8B6ESESSCMS0360e_-- From internet-drafts@ietf.org Thu Sep 8 15:15:33 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699B621F8BC3; Thu, 8 Sep 2011 15:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tb2MYYERPTJz; Thu, 8 Sep 2011 15:15:32 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4B6321F8BBD; Thu, 8 Sep 2011 15:15:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110908221532.29036.90886.idtracker@ietfa.amsl.com> Date: Thu, 08 Sep 2011 15:15:32 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 22:15:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane = Working Group of the IETF. Title : OSPF Enhancement for Signal and Network Element Compatib= ility for Wavelength Switched Optical Networks Author(s) : Young Lee Greg M. Bernstein Filename : draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt Pages : 14 Date : 2011-09-08 This document provides GMPLS OSPF routing enhancements to support signal compatibility constraints associated with WSON network elements. These routing enhancements are required in common optical or hybrid electro-optical networks where not all of the optical signals in the network are compatible with all network elements participating in the network. This compatibility constraint model is applicable to common optical or hybrid electro optical systems such as OEO switches, regenerators, and wavelength converters since such systems can be limited to processing only certain types of WSON signals. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compatibil= ity-ospf-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compatibili= ty-ospf-05.txt From internet-drafts@ietf.org Thu Sep 8 22:55:44 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB2D921F8A97; Thu, 8 Sep 2011 22:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eyr8rcbA1hA; Thu, 8 Sep 2011 22:55:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 483FE21F8B50; Thu, 8 Sep 2011 22:55:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110909055544.22235.97250.idtracker@ietfa.amsl.com> Date: Thu, 08 Sep 2011 22:55:44 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-g709-framework-05.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 05:55:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane = Working Group of the IETF. Title : Framework for GMPLS and PCE Control of G.709 Optical Tra= nsport Networks Author(s) : Fatai Zhang Dan Li Han Li Sergio Belotti Daniele Ceccarelli Filename : draft-ietf-ccamp-gmpls-g709-framework-05.txt Pages : 28 Date : 2011-09-08 This document provides a framework to allow the development of protocol extensions to support Generalized Multi-Protocol Label Switching (GMPLS) and Path Computation Element (PCE) control of Optical Transport Networks (OTN) as specified in ITU-T Recommendation G.709 as consented in October 2009. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g709-framework-0= 5.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-g709-framework-05= .txt From zhangfatai@huawei.com Thu Sep 8 23:21:47 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA8221F8A7A for ; Thu, 8 Sep 2011 23:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.318 X-Spam-Level: X-Spam-Status: No, score=-5.318 tagged_above=-999 required=5 tests=[AWL=1.280, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9IHAAVIRqOEy for ; Thu, 8 Sep 2011 23:21:46 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id AC84021F84BC for ; Thu, 8 Sep 2011 23:21:45 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LR8009MDSFE4C@szxga04-in.huawei.com> for ccamp@ietf.org; Fri, 09 Sep 2011 14:23:38 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LR800AIISFEVJ@szxga04-in.huawei.com> for ccamp@ietf.org; Fri, 09 Sep 2011 14:23:38 +0800 (CST) Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADR09735; Fri, 09 Sep 2011 14:23:38 +0800 Received: from SZXEML406-HUB.china.huawei.com (10.82.67.93) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 09 Sep 2011 14:23:31 +0800 Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.184]) by szxeml406-hub.china.huawei.com ([10.82.67.93]) with mapi id 14.01.0270.001; Fri, 09 Sep 2011 14:23:36 +0800 Date: Fri, 09 Sep 2011 06:23:26 +0000 From: Zhangfatai In-reply-to: <20110909055544.22235.97250.idtracker@ietfa.amsl.com> X-Originating-IP: [10.70.76.157] To: "ccamp@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_agXLJT79R5GF/ZUka+BX4g)" Content-language: en-US Accept-Language: zh-CN, en-US Thread-topic: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-g709-framework-05.txt Thread-index: AQHMbrWY5b/YnUX2iEia+OLZ6WokXZVEjwVQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20110909055544.22235.97250.idtracker@ietfa.amsl.com> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-g709-framework-05.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 06:21:47 -0000 --Boundary_(ID_agXLJT79R5GF/ZUka+BX4g) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: base64 SGkgQ0NBTVBlcnMsDQoNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIE9UTiBmcmFtZXdvcmsgZG9jdW1l bnQgaGFzIGJlZW4gc3VibWl0dGVkIGJlY2F1c2UgaXQgd2lsbCBiZSBleHBpcmVkIHNvb24uDQoN Cg0KDQpUaGUgdXBkYXRlcyBhcmUgYmFzZWQgb24gdGhlIHByb2dyZXNzIG9mIE9UTiBPU1BGIGFu ZCBSU1ZQLVRFIGRyYWZ0cywgbW9yZSBzcGVjaWZpY2FsbHkgYXMgZm9sbG93czoNCg0KDQoNCigx KSBSZWZpbmVkIHNvbWUgdGV4dCByZWxhdGVkIHRvIGEgbmV3IHN3aXRjaGluZyB0eXBlICgxMDEp IGludHJvZHVjZWQgaW4gdGhlIHJvdXRpbmcuDQoNCigyKSBBZGRlZCBhIG5ldyBzaWduYWxpbmcg cmVxdWlyZW1lbnQgdG8gZGVzY3JpYmUgdGhlIG5ldyBTd2l0Y2hpbmcgVHlwZSBpbiB0aGUgc2ln bmFsaW5nIHNob3VsZCBiZSBjb25zaXN0ZW50IHdpdGggcm91dGluZy4NCg0KKDMpIEFkZGVkIGEg bmV3IHJvdXRpbmcgcmVxdWlyZW1lbnQgYWJvdXQgVFNHIGFkdmVydGlzZW1lbnQsIGFuZCBjb25z ZXF1ZW50bHksIHJlZmluZWQgc29tZSB0ZXh0IGFib3V0IFRTRyBpbmZvcm1hdGlvbiBpbiB0aGUg c2lnbmFsaW5nLg0KDQoNCg0KUGxlYXNlIHNoYXJlIHlvdXIgY29tbWVudHMgb3IgY29uY2VybnMu DQoNCg0KDQoNCg0KVGhhbmtzDQoNCg0KDQpGYXRhaQ0KDQoNCg0KDQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAt Ym91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0K U2VudDogMjAxMeW5tDnmnIg55pelIDEzOjU2DQpUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQpD YzogY2NhbXBAaWV0Zi5vcmcNClN1YmplY3Q6IFtDQ0FNUF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0 Zi1jY2FtcC1nbXBscy1nNzA5LWZyYW1ld29yay0wNS50eHQNCg0KDQoNCkEgTmV3IEludGVybmV0 LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJl Y3Rvcmllcy4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQ29tbW9uIENvbnRyb2wg YW5kIE1lYXN1cmVtZW50IFBsYW5lIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQoNCg0KDQog ICAgICAgICBUaXRsZSAgICAgICAgICAgOiBGcmFtZXdvcmsgZm9yIEdNUExTIGFuZCBQQ0UgQ29u dHJvbCBvZiBHLjcwOSBPcHRpY2FsIFRyYW5zcG9ydCBOZXR3b3Jrcw0KDQogICAgICAgICBBdXRo b3IocykgICAgICAgOiBGYXRhaSBaaGFuZw0KDQogICAgICAgICAgICAgICAgICAgICAgICAgIERh biBMaQ0KDQogICAgICAgICAgICAgICAgICAgICAgICAgIEhhbiBMaQ0KDQogICAgICAgICAgICAg ICAgICAgICAgICAgIFNlcmdpbyBCZWxvdHRpDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAg RGFuaWVsZSBDZWNjYXJlbGxpDQoNCiAgICAgICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWll dGYtY2NhbXAtZ21wbHMtZzcwOS1mcmFtZXdvcmstMDUudHh0DQoNCiAgICAgICAgIFBhZ2VzICAg ICAgICAgICA6IDI4DQoNCiAgICAgICAgIERhdGUgICAgICAgICAgICA6IDIwMTEtMDktMDgNCg0K DQoNCiAgIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgYSBmcmFtZXdvcmsgdG8gYWxsb3cgdGhlIGRl dmVsb3BtZW50IG9mDQoNCiAgIHByb3RvY29sIGV4dGVuc2lvbnMgdG8gc3VwcG9ydCBHZW5lcmFs aXplZCBNdWx0aS1Qcm90b2NvbCBMYWJlbA0KDQogICBTd2l0Y2hpbmcgKEdNUExTKSBhbmQgUGF0 aCBDb21wdXRhdGlvbiBFbGVtZW50IChQQ0UpIGNvbnRyb2wgb2YNCg0KICAgT3B0aWNhbCBUcmFu c3BvcnQgTmV0d29ya3MgKE9UTikgYXMgc3BlY2lmaWVkIGluIElUVS1UIFJlY29tbWVuZGF0aW9u DQoNCiAgIEcuNzA5IGFzIGNvbnNlbnRlZCBpbiBPY3RvYmVyIDIwMDkuDQoNCg0KDQoNCg0KQSBV UkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6DQoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS1mcmFtZXdvcmstMDUudHh0 DQoNCg0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBG VFAgYXQ6DQoNCmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCg0KDQpUaGlz IEludGVybmV0LURyYWZ0IGNhbiBiZSByZXRyaWV2ZWQgYXQ6DQoNCmZ0cDovL2Z0cC5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nNzA5LWZyYW1ld29yay0w NS50eHQNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg0KQ0NBTVAgbWFpbGluZyBsaXN0DQoNCkNDQU1QQGlldGYub3JnDQoNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCg== --Boundary_(ID_agXLJT79R5GF/ZUka+BX4g) Content-type: text/html; charset=utf-8 Content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmp1c3RpZnk7DQoJdGV4dC1qdXN0 aWZ5OmludGVyLWlkZW9ncmFwaDsNCglmb250LXNpemU6MTAuNXB0Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQgQ2hhciI7 DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjVw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCnNwYW4uUGxhaW5UZXh0 Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7fQ0KLyogUGFnZSBEZWZpbml0aW9ucyAqLw0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5 MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5bGU9 InRleHQtanVzdGlmeS10cmltOnB1bmN0dWF0aW9uIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPkhpIENDQU1QZXJzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5BIG5ldyB2ZXJz aW9uIG9mIE9UTiBmcmFtZXdvcmsgZG9jdW1lbnQgaGFzIGJlZW4gc3VibWl0dGVkIGJlY2F1c2Ug aXQgd2lsbCBiZSBleHBpcmVkIHNvb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlRoZSB1cGRhdGVzIGFy ZSBiYXNlZCBvbiB0aGUgcHJvZ3Jlc3Mgb2YgT1ROIE9TUEYgYW5kIFJTVlAtVEUgZHJhZnRzLCBt b3JlIHNwZWNpZmljYWxseSBhcyBmb2xsb3dzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4oMSkgUmVmaW5l ZCBzb21lIHRleHQgcmVsYXRlZCB0byBhIG5ldyBzd2l0Y2hpbmcgdHlwZSAoMTAxKSBpbnRyb2R1 Y2VkIGluIHRoZSByb3V0aW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDo2LjBwdDt0ZXh0LWluZGVudDotNi4wcHQiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+KDIpIEFkZGVkIGEgbmV3 IHNpZ25hbGluZyByZXF1aXJlbWVudCB0byBkZXNjcmliZSB0aGUgbmV3IFN3aXRjaGluZyBUeXBl IGluIHRoZSBzaWduYWxpbmcgc2hvdWxkIGJlIGNvbnNpc3RlbnQgd2l0aCByb3V0aW5nLg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4oMykgQWRkZWQgYSBuZXcgcm91dGluZyBy ZXF1aXJlbWVudCBhYm91dCBUU0cgYWR2ZXJ0aXNlbWVudCwgYW5kIGNvbnNlcXVlbnRseSwgcmVm aW5lZCBzb21lIHRleHQgYWJvdXQgVFNHIGluZm9ybWF0aW9uIGluIHRoZSBzaWduYWxpbmcuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMi4wcHQiPlBsZWFzZSBzaGFyZSB5b3VyIGNvbW1lbnRzIG9yIGNvbmNlcm5zLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQi PlRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5G YXRhaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv UGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPi0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv OmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBpbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmc8YnI+DQpTZW50OiAyMDExPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTrlrovk vZMiPuW5tDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+OTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk65a6L5L2TIj7mnIg8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjk8L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OuWui+S9kyI+5pelPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij4gMTM6NTY8YnI+DQpUbzogaS1kLWFubm91bmNlQGlldGYub3JnPGJyPg0KQ2M6IGNjYW1wQGll dGYub3JnPGJyPg0KU3ViamVjdDogW0NDQU1QXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNjYW1w LWdtcGxzLWc3MDktZnJhbWV3b3JrLTA1LnR4dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+QSBO ZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQt RHJhZnRzIGRpcmVjdG9yaWVzLiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBDb21t b24gQ29udHJvbCBhbmQgTWVhc3VyZW1lbnQgUGxhbmUgV29ya2luZyBHcm91cCBvZiB0aGUgSUVU Ri48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBUaXRsZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IEZyYW1ld29yayBmb3IgR01QTFMgYW5kIFBD RSBDb250cm9sIG9mIEcuNzA5IE9wdGljYWwgVHJhbnNwb3J0IE5ldHdvcmtzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBdXRob3Iocykm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiBGYXRhaSBaaGFuZzxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRGFuIExpPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBIYW4gTGk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNlcmdpbyBCZWxvdHRpPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtEYW5pZWxlIENlY2NhcmVsbGk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZp bGVuYW1lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogZHJhZnQt aWV0Zi1jY2FtcC1nbXBscy1nNzA5LWZyYW1ld29yay0wNS50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBhZ2VzJm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogMjg8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERh dGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgOiAyMDExLTA5LTA4PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsm bmJzcDsgVGhpcyBkb2N1bWVudCBwcm92aWRlcyBhIGZyYW1ld29yayB0byBhbGxvdyB0aGUgZGV2 ZWxvcG1lbnQgb2Y8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7Jm5ic3A7IHByb3RvY29sIGV4dGVuc2lvbnMgdG8g c3VwcG9ydCBHZW5lcmFsaXplZCBNdWx0aS1Qcm90b2NvbCBMYWJlbDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsm bmJzcDsgU3dpdGNoaW5nIChHTVBMUykgYW5kIFBhdGggQ29tcHV0YXRpb24gRWxlbWVudCAoUENF KSBjb250cm9sIG9mPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOyZuYnNwOyBPcHRpY2FsIFRyYW5zcG9ydCBOZXR3 b3JrcyAoT1ROKSBhcyBzcGVjaWZpZWQgaW4gSVRVLVQgUmVjb21tZW5kYXRpb248bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+ Jm5ic3A7Jm5ic3A7IEcuNzA5IGFzIGNvbnNlbnRlZCBpbiBPY3RvYmVyIDIwMDkuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+QSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQt RHJhZnQgaXM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWlldGYtY2NhbXAtZ21wbHMtZzcwOS1mcmFtZXdvcmstMDUudHh0PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxzcGFuIGxh bmc9IkVOLVVTIj5JbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91 cyBGVFAgYXQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGlzIEludGVybmV0LURyYWZ0IGNhbiBiZSByZXRyaWV2 ZWQgYXQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNw YW4gbGFuZz0iRU4tVVMiPmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt aWV0Zi1jY2FtcC1nbXBscy1nNzA5LWZyYW1ld29yay0wNS50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48c3BhbiBsYW5nPSJFTi1VUyI+Q0NBTVAgbWFp bGluZyBsaXN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PHNwYW4gbGFuZz0iRU4tVVMiPkNDQU1QQGlldGYub3JnPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PHNwYW4gbGFuZz0iRU4tVVMiPmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --Boundary_(ID_agXLJT79R5GF/ZUka+BX4g)-- From leeyoung@huawei.com Fri Sep 9 12:49:32 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20D221F889A for ; Fri, 9 Sep 2011 12:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.543 X-Spam-Level: X-Spam-Status: No, score=-6.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-4YU4ztk+-m for ; Fri, 9 Sep 2011 12:49:32 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 48E0321F87FC for ; Fri, 9 Sep 2011 12:49:32 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LR900LV1TTRD2@usaga02-in.huawei.com> for ccamp@ietf.org; Fri, 09 Sep 2011 14:51:27 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LR900J2KTTRJS@usaga02-in.huawei.com> for ccamp@ietf.org; Fri, 09 Sep 2011 14:51:27 -0500 (CDT) Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 09 Sep 2011 12:51:30 -0700 Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Fri, 09 Sep 2011 12:51:22 -0700 Date: Fri, 09 Sep 2011 19:51:20 +0000 From: Leeyoung X-Originating-IP: [10.192.11.52] To: "ccamp@ietf.org" Message-id: <7AEB3D6833318045B4AE71C2C87E8E1718166966@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt Thread-index: AQHMbnVXZ5ztk/P48kGlpLOGXqrkmpVFc5Ag X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 19:49:32 -0000 Hi, This update added a new section to discuss OSPF scalability and how to use multiple TE LSA instance technique to keep the LSA under the MTU limit. Please note that the MTU limit is 1500 bytes and the examples given in the encoding draft is far below this limit. In case the LSA size goes above the MTU, this draft discusses how to split the Sub-TLVs' defined under the Optical Node Property TLV under the MTU limit to avoid fragmentation. Take a look at Section 3 and if you have questions, please feel free to discuss in the mailing list. Regards, Young -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Thursday, September 08, 2011 5:16 PM To: i-d-announce@ietf.org Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks Author(s) : Young Lee Greg M. Bernstein Filename : draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt Pages : 14 Date : 2011-09-08 This document provides GMPLS OSPF routing enhancements to support signal compatibility constraints associated with WSON network elements. These routing enhancements are required in common optical or hybrid electro-optical networks where not all of the optical signals in the network are compatible with all network elements participating in the network. This compatibility constraint model is applicable to common optical or hybrid electro optical systems such as OEO switches, regenerators, and wavelength converters since such systems can be limited to processing only certain types of WSON signals. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From internet-drafts@ietf.org Fri Sep 9 14:19:50 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF32121F872A; Fri, 9 Sep 2011 14:19:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RyQ4dnt5Lv5n; Fri, 9 Sep 2011 14:19:49 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73A6F21F86A4; Fri, 9 Sep 2011 14:19:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110909211949.22139.11442.idtracker@ietfa.amsl.com> Date: Fri, 09 Sep 2011 14:19:49 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-info-12.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 21:19:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane = Working Group of the IETF. Title : Routing and Wavelength Assignment Information Model for = Wavelength Switched Optical Networks Author(s) : Young Lee Greg M. Bernstein Dan Li Wataru Imajuku Filename : draft-ietf-ccamp-rwa-info-12.txt Pages : 27 Date : 2011-09-09 This document provides a model of information needed by the routing and wavelength assignment (RWA) process in wavelength switched optical networks (WSONs). The purpose of the information described in this model is to facilitate constrained lightpath computation in WSONs. This model takes into account compatibility constraints between WSON signal attributes and network elements but does not include constraints due to optical impairments. Aspects of this information that may be of use to other technologies utilizing a GMPLS control plane are discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-12.txt From leeyoung@huawei.com Fri Sep 9 14:27:59 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C41A21F8A7E for ; Fri, 9 Sep 2011 14:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.546 X-Spam-Level: X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLwHY54VthlR for ; Fri, 9 Sep 2011 14:27:58 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 95ABA21F8A69 for ; Fri, 9 Sep 2011 14:27:58 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LR9006DOYDT5H@usaga02-in.huawei.com> for ccamp@ietf.org; Fri, 09 Sep 2011 16:29:54 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LR900MXNYDTPC@usaga02-in.huawei.com> for ccamp@ietf.org; Fri, 09 Sep 2011 16:29:53 -0500 (CDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 09 Sep 2011 14:29:57 -0700 Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Fri, 09 Sep 2011 14:29:48 -0700 Date: Fri, 09 Sep 2011 21:29:48 +0000 From: Leeyoung X-Originating-IP: [10.192.11.52] To: "ccamp@ietf.org" Message-id: <7AEB3D6833318045B4AE71C2C87E8E17181669D3@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-info-12.txt Thread-index: AQHMbzaIDI6/KZa+pUuuGsK1nP8d9ZVFjvuQ X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-info-12.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Sep 2011 21:27:59 -0000 Hi, This update (version 12) includes the following: (i) Replaced all instances of "ingress" with "input" and all instances of "egress" with "output". (ii) Added clarifying text on relationship between resource block model and physical entities such as line cards. This draft is now very mature and incorporated all the comments raised in the mailing list and the last meetings. Thanks, Young -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Friday, September 09, 2011 4:20 PM To: i-d-announce@ietf.org Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-info-12.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks Author(s) : Young Lee Greg M. Bernstein Dan Li Wataru Imajuku Filename : draft-ietf-ccamp-rwa-info-12.txt Pages : 27 Date : 2011-09-09 This document provides a model of information needed by the routing and wavelength assignment (RWA) process in wavelength switched optical networks (WSONs). The purpose of the information described in this model is to facilitate constrained lightpath computation in WSONs. This model takes into account compatibility constraints between WSON signal attributes and network elements but does not include constraints due to optical impairments. Aspects of this information that may be of use to other technologies utilizing a GMPLS control plane are discussed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-12.txt _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From acee.lindem@ericsson.com Mon Sep 12 15:57:00 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA04221F8EA7 for ; Mon, 12 Sep 2011 15:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.526 X-Spam-Level: X-Spam-Status: No, score=-6.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQPFLIHYlMaP for ; Mon, 12 Sep 2011 15:56:59 -0700 (PDT) Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id C44CA21F8EA4 for ; Mon, 12 Sep 2011 15:56:59 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p8CMuQEJ026563; Mon, 12 Sep 2011 17:58:57 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.60]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Mon, 12 Sep 2011 18:58:18 -0400 From: Acee Lindem To: Greg Bernstein , Young Lee Date: Mon, 12 Sep 2011 18:58:15 -0400 Thread-Topic: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt Thread-Index: Acxxn3We2bcVajIHTaiMTdzaysu9UA== Message-ID: <63CEF1D1-D774-40C9-90BB-04BD5E85BF1B@ericsson.com> References: <7AEB3D6833318045B4AE71C2C87E8E1718166966@DFWEML501-MBX.china.huawei.com> In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1718166966@DFWEML501-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-158-406163146"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: CCAMP Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Sep 2011 22:57:01 -0000 --Apple-Mail-158-406163146 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Young, Greg,=20 I have the following comments: 1. Specify that the Optical Node Property TLV cardinality and order = rules per LSA.=20 For example (from RFC 3630):=20 "The Link TLV describes a single link. It is constructed of a set = of sub-TLVs. There are no ordering requirements for the sub-TLVs. Only one Link TLV shall be carried in each LSA, allowing for fine =20= granularity changes in topology." However, use the term "advertised" rather than "carried". After = all, these are Link State Advertisements.=20 2. The same comment for all the Sub-TLVs. Here is another example = from=20 RFC 3630: "The Link Type and Link ID sub-TLVs are mandatory, i.e., must = appear exactly once. All other sub-TLVs defined here may occur at most once. These restrictions need not apply to future sub-TLVs. Unrecognized sub-TLVs are ignored." The new Sub-TLVs you are defining need this level of = specification.=20 3. I know I told you not to use the term "multi-instance LSA". I = still don't like the usage of "LSA instance" in the draft. In the base OSPF = specification, RFC 2328,=20 the term LSA instance is used to denote a particular version of = the same LSA - NOT an opaque identifier for multiple LSAs of the same type. Refer to = section 12.1 in=20 RFC 2328.=20 The OSPF Opaque LSA RFC (RFC 2370 and its successor RFC 5250) = correctly=20 identify the last 24 bits of the LSA ID as the Opaque ID. While = RFC 3630 refers to this field as the "Instance", I believe this term should be = avoided given the=20 semantics in the OSPF base specification. Hence, I'd suggest the=20= following changes: 225,226c225,226 < the rest and make use of multiple TE LSA instances per source, per < [RFC3630] multiple instance capability. --- > the rest and be advertised with multiple TE LSAs per OSPF router, = as > described in [RFC3630] and [RFC5250]. 342,344c342,344 < the dynamic information sub-TLVs into separate LSAs within an = Optical < Node Property TLV using multiple TE LSA instances per source, per = the < reference [RFC3630] multiple instance capability. --- > the dynamic information sub-TLVs from the static information = sub-TLVs > and advertise them in OSPF TE LSAs, each with the Optical Node > Property TLV at the top level ([RFC3630 and RFC5250]).=20 392c392 < into smaller sub-TLVs that can be sent in separate LSA instances. --- > into smaller sub-TLVs that can be sent in separate OSPF TE LSAs. 399c399 < sub-TLVs that can be sent in multiple LSA instances. The --- > sub-TLVs that can be sent in multiple OSPF TE LSAs. The 473c473 < into multiple LSA instances each containing a disjoint assembly of --- > into multiple OSPF TE LSAs each containing a disjoint assembly of Additionally, I'd add RFC 5250 as at least a informative reference. =20 =20 4. Finally, I'd suggest changing the title from "OSPF Enhancement..." = to=20 "GMPLS OSPF Enhancement..." since you are not really enhancing = base=20 OSPF itself. Of course, there are other CCAMP RFCs that do not = make=20 this distinction.=20 Thanks, Acee=20 =20 On Sep 9, 2011, at 3:51 PM, Leeyoung wrote: > Hi, >=20 > This update added a new section to discuss OSPF scalability and how to = use multiple TE LSA instance technique to keep the LSA under the MTU = limit. Please note that the MTU limit is 1500 bytes and the examples = given in the encoding draft is far below this limit. In case the LSA = size goes above the MTU, this draft discusses how to split the Sub-TLVs' = defined under the Optical Node Property TLV under the MTU limit to avoid = fragmentation.=20 >=20 > Take a look at Section 3 and if you have questions, please feel free = to discuss in the mailing list.=20 >=20 > Regards, > Young >=20 >=20 >=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of internet-drafts@ietf.org > Sent: Thursday, September 08, 2011 5:16 PM > To: i-d-announce@ietf.org > Cc: ccamp@ietf.org > Subject: [CCAMP] I-D Action: = draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt >=20 > 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. >=20 > Title : OSPF Enhancement for Signal and Network = Element Compatibility for Wavelength Switched Optical Networks > Author(s) : Young Lee > Greg M. Bernstein > Filename : = draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt > Pages : 14 > Date : 2011-09-08 >=20 > This document provides GMPLS OSPF routing enhancements to support > signal compatibility constraints associated with WSON network > elements. These routing enhancements are required in common optical > or hybrid electro-optical networks where not all of the optical > signals in the network are compatible with all network elements > participating in the network. >=20 > This compatibility constraint model is applicable to common optical > or hybrid electro optical systems such as OEO switches, = regenerators, > and wavelength converters since such systems can be limited to > processing only certain types of WSON signals. >=20 >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compatibi= lity-ospf-05.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compatibil= ity-ospf-05.txt > _______________________________________________ > 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 --Apple-Mail-158-406163146 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDkxMjIyNTgxNlowIwYJKoZI hvcNAQkEMRYEFBf9voFVNqXOPuNY6niD4XRkTyM2MFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgHr4RmWFX3EPxyuq37n+vdfG3921nAMSkGSe4iQhZ8TuUNhSK8k5xhTNsfLZsdAR KaVUFJjvRP5M5O1T+PklRxRtZbZlZzFydviatq9MW7VDfOcjPH13rZ5YAm05kA+Li70HFlCDrtHV Om3PCWRDAQNkbapdw7q8ZIfEx+1GL6rtAAAAAAAA --Apple-Mail-158-406163146-- From zhangfatai@huawei.com Mon Sep 12 20:35:45 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA4BA21F8C5B for ; Mon, 12 Sep 2011 20:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.386 X-Spam-Level: X-Spam-Status: No, score=-5.386 tagged_above=-999 required=5 tests=[AWL=1.213, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QEtELKjnR1+e for ; Mon, 12 Sep 2011 20:35:45 -0700 (PDT) Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 9616521F8C59 for ; Mon, 12 Sep 2011 20:35:44 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRF00A53ZF00V@szxga04-in.huawei.com> for ccamp@ietf.org; Tue, 13 Sep 2011 11:37:49 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRF001ORZF06R@szxga04-in.huawei.com> for ccamp@ietf.org; Tue, 13 Sep 2011 11:37:48 +0800 (CST) Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADX84811; Tue, 13 Sep 2011 11:37:46 +0800 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 13 Sep 2011 11:37:44 +0800 Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.184]) by szxeml410-hub.china.huawei.com ([169.254.101.122]) with mapi id 14.01.0270.001; Tue, 13 Sep 2011 11:37:45 +0800 Date: Tue, 13 Sep 2011 03:37:09 +0000 From: Zhangfatai In-reply-to: <63CEF1D1-D774-40C9-90BB-04BD5E85BF1B@ericsson.com> X-Originating-IP: [10.70.76.157] To: Acee Lindem , Greg Bernstein , Leeyoung Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt Thread-index: AQHMcZ+ZHZuJ9fm07UCZMv6mUYXLw5VKqMxw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <7AEB3D6833318045B4AE71C2C87E8E1718166966@DFWEML501-MBX.china.huawei.com> <63CEF1D1-D774-40C9-90BB-04BD5E85BF1B@ericsson.com> Cc: CCAMP Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 03:35:46 -0000 SGkgQWNlZSwNCg0KSSBwZXJzb25hbGx5IGFncmVlIHdpdGggeW91ciBjb21tZW50cyBvbiAibXVs dGktaW5zdGFuY2UgTFNBIi4NCg0KSSB3aWxsIHRha2UgeW91ciBzdWdnZXN0aW9ucyBpbnRvIGFj Y291bnQgd2hlbiBJIHVwZGF0ZSAiZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLWNvbnN0 cmFpbnRzLW9zcGYtdGUtMDUudHh0Ii4NCg0KDQoNCg0KVGhhbmtzDQrCoA0KRmF0YWkNCg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBb bWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBY2VlIExpbmRlbQ0K U2VudDogMjAxMeW5tDnmnIgxM+aXpSA2OjU4DQpUbzogR3JlZyBCZXJuc3RlaW47IExlZXlvdW5n DQpDYzogQ0NBTVANClN1YmplY3Q6IFJlOiBbQ0NBTVBdIEZXOiBJLUQgQWN0aW9uOiBkcmFmdC1p ZXRmLWNjYW1wLXdzb24tc2lnbmFsLWNvbXBhdGliaWxpdHktb3NwZi0wNS50eHQNCg0KSGkgWW91 bmcsIEdyZWcsDQpJIGhhdmUgdGhlIGZvbGxvd2luZyBjb21tZW50czoNCg0KICAgMS4gU3BlY2lm eSB0aGF0IHRoZSBPcHRpY2FsIE5vZGUgUHJvcGVydHkgVExWIGNhcmRpbmFsaXR5IGFuZCBvcmRl ciBydWxlcyBwZXIgTFNBLiANCiAgICAgICBGb3IgZXhhbXBsZSAoZnJvbSBSRkMgMzYzMCk6IA0K DQogICAgICJUaGUgTGluayBUTFYgZGVzY3JpYmVzIGEgc2luZ2xlIGxpbmsuICBJdCBpcyBjb25z dHJ1Y3RlZCBvZiBhIHNldCBvZg0KICAgICAgIHN1Yi1UTFZzLiAgVGhlcmUgYXJlIG5vIG9yZGVy aW5nIHJlcXVpcmVtZW50cyBmb3IgdGhlIHN1Yi1UTFZzLg0KDQogICAgICBPbmx5IG9uZSBMaW5r IFRMViBzaGFsbCBiZSBjYXJyaWVkIGluIGVhY2ggTFNBLCBhbGxvd2luZyBmb3IgZmluZSAgDQog ICAgICBncmFudWxhcml0eSBjaGFuZ2VzIGluIHRvcG9sb2d5LiINCg0KICAgICAgSG93ZXZlciwg dXNlIHRoZSB0ZXJtICJhZHZlcnRpc2VkIiByYXRoZXIgdGhhbiAiY2FycmllZCIuIEFmdGVyIGFs bCwgdGhlc2UgYXJlDQogICAgICBMaW5rIFN0YXRlIEFkdmVydGlzZW1lbnRzLiANCg0KICAgMi4g VGhlIHNhbWUgY29tbWVudCBmb3IgYWxsIHRoZSBTdWItVExWcy4gSGVyZSBpcyBhbm90aGVyIGV4 YW1wbGUgZnJvbSANCiAgICAgICAgUkZDIDM2MzA6DQoNCiAgICAgICJUaGUgTGluayBUeXBlIGFu ZCBMaW5rIElEIHN1Yi1UTFZzIGFyZSBtYW5kYXRvcnksIGkuZS4sIG11c3QgYXBwZWFyDQogICAg ICAgZXhhY3RseSBvbmNlLiAgQWxsIG90aGVyIHN1Yi1UTFZzIGRlZmluZWQgaGVyZSBtYXkgb2Nj dXIgYXQgbW9zdA0KICAgICAgIG9uY2UuICBUaGVzZSByZXN0cmljdGlvbnMgbmVlZCBub3QgYXBw bHkgdG8gZnV0dXJlIHN1Yi1UTFZzLg0KICAgICAgIFVucmVjb2duaXplZCBzdWItVExWcyBhcmUg aWdub3JlZC4iDQoNCiAgICAgICBUaGUgbmV3IFN1Yi1UTFZzIHlvdSBhcmUgZGVmaW5pbmcgbmVl ZCB0aGlzIGxldmVsIG9mIHNwZWNpZmljYXRpb24uIA0KDQogICAzLiBJIGtub3cgSSB0b2xkIHlv dSBub3QgdG8gdXNlIHRoZSB0ZXJtICJtdWx0aS1pbnN0YW5jZSBMU0EiLiBJIHN0aWxsIGRvbid0 IGxpa2UNCiAgICAgICB0aGUgdXNhZ2Ugb2YgIkxTQSBpbnN0YW5jZSIgaW4gdGhlIGRyYWZ0LiBJ biB0aGUgYmFzZSBPU1BGIHNwZWNpZmljYXRpb24sIFJGQyAyMzI4LCANCiAgICAgICB0aGUgdGVy bSBMU0EgaW5zdGFuY2UgaXMgdXNlZCB0byBkZW5vdGUgYSBwYXJ0aWN1bGFyIHZlcnNpb24gb2Yg dGhlIHNhbWUgTFNBIC0gTk9UDQogICAgICAgYW4gb3BhcXVlIGlkZW50aWZpZXIgZm9yIG11bHRp cGxlIExTQXMgb2YgdGhlIHNhbWUgdHlwZS4gUmVmZXIgdG8gc2VjdGlvbiAxMi4xIGluIA0KICAg ICAgIFJGQyAyMzI4LiANCg0KICAgICAgVGhlIE9TUEYgT3BhcXVlIExTQSBSRkMgKFJGQyAyMzcw IGFuZCBpdHMgc3VjY2Vzc29yIFJGQyA1MjUwKSBjb3JyZWN0bHkgDQogICAgICAgaWRlbnRpZnkg dGhlIGxhc3QgMjQgYml0cyBvZiB0aGUgTFNBIElEIGFzIHRoZSBPcGFxdWUgSUQuIFdoaWxlIFJG QyAzNjMwIHJlZmVycw0KICAgICAgIHRvIHRoaXMgZmllbGQgYXMgdGhlICJJbnN0YW5jZSIsIEkg YmVsaWV2ZSB0aGlzIHRlcm0gc2hvdWxkIGJlIGF2b2lkZWQgZ2l2ZW4gdGhlIA0KICAgICAgIHNl bWFudGljcyBpbiB0aGUgT1NQRiBiYXNlIHNwZWNpZmljYXRpb24uIEhlbmNlLCBJJ2Qgc3VnZ2Vz dCB0aGUgDQogICAgICAgZm9sbG93aW5nIGNoYW5nZXM6DQoNCjIyNSwyMjZjMjI1LDIyNg0KPCAg ICB0aGUgcmVzdCBhbmQgbWFrZSB1c2Ugb2YgbXVsdGlwbGUgVEUgTFNBIGluc3RhbmNlcyBwZXIg c291cmNlLCBwZXINCjwgICAgW1JGQzM2MzBdIG11bHRpcGxlIGluc3RhbmNlIGNhcGFiaWxpdHku DQotLS0NCj4gICAgdGhlIHJlc3QgYW5kIGJlIGFkdmVydGlzZWQgd2l0aCBtdWx0aXBsZSBURSBM U0FzIHBlciBPU1BGIHJvdXRlciwgYXMNCj4gICAgZGVzY3JpYmVkIGluIFtSRkMzNjMwXSBhbmQg W1JGQzUyNTBdLg0KMzQyLDM0NGMzNDIsMzQ0DQo8ICAgIHRoZSBkeW5hbWljIGluZm9ybWF0aW9u IHN1Yi1UTFZzIGludG8gc2VwYXJhdGUgTFNBcyB3aXRoaW4gYW4gT3B0aWNhbA0KPCAgICBOb2Rl IFByb3BlcnR5IFRMViB1c2luZyBtdWx0aXBsZSBURSBMU0EgaW5zdGFuY2VzIHBlciBzb3VyY2Us IHBlciB0aGUNCjwgICAgcmVmZXJlbmNlIFtSRkMzNjMwXSBtdWx0aXBsZSBpbnN0YW5jZSBjYXBh YmlsaXR5Lg0KLS0tDQo+ICAgIHRoZSBkeW5hbWljIGluZm9ybWF0aW9uIHN1Yi1UTFZzIGZyb20g dGhlIHN0YXRpYyBpbmZvcm1hdGlvbiBzdWItVExWcw0KPiAgICBhbmQgYWR2ZXJ0aXNlIHRoZW0g aW4gT1NQRiBURSBMU0FzLCBlYWNoIHdpdGggdGhlIE9wdGljYWwgTm9kZQ0KPiAgICBQcm9wZXJ0 eSBUTFYgYXQgdGhlIHRvcCBsZXZlbCAoW1JGQzM2MzAgYW5kIFJGQzUyNTBdKS4gDQozOTJjMzky DQo8ICAgIGludG8gc21hbGxlciBzdWItVExWcyB0aGF0IGNhbiBiZSBzZW50IGluIHNlcGFyYXRl IExTQSBpbnN0YW5jZXMuDQotLS0NCj4gICAgaW50byBzbWFsbGVyIHN1Yi1UTFZzIHRoYXQgY2Fu IGJlIHNlbnQgaW4gc2VwYXJhdGUgT1NQRiBURSBMU0FzLg0KMzk5YzM5OQ0KPCAgICBzdWItVExW cyB0aGF0IGNhbiBiZSBzZW50IGluIG11bHRpcGxlIExTQSBpbnN0YW5jZXMuIFRoZQ0KLS0tDQo+ ICAgIHN1Yi1UTFZzIHRoYXQgY2FuIGJlIHNlbnQgaW4gbXVsdGlwbGUgT1NQRiBURSBMU0FzLiBU aGUNCjQ3M2M0NzMNCjwgICAgaW50byBtdWx0aXBsZSBMU0EgaW5zdGFuY2VzIGVhY2ggY29udGFp bmluZyBhIGRpc2pvaW50IGFzc2VtYmx5IG9mDQotLS0NCj4gICAgaW50byBtdWx0aXBsZSBPU1BG IFRFIExTQXMgZWFjaCBjb250YWluaW5nIGEgZGlzam9pbnQgYXNzZW1ibHkgb2YNCg0KICAgICBB ZGRpdGlvbmFsbHksIEknZCBhZGQgUkZDIDUyNTAgYXMgYXQgbGVhc3QgYSBpbmZvcm1hdGl2ZSBy ZWZlcmVuY2UuDQogICAgDQogICAgDQoNCiAgIDQuIEZpbmFsbHksIEknZCBzdWdnZXN0IGNoYW5n aW5nIHRoZSB0aXRsZSBmcm9tICJPU1BGIEVuaGFuY2VtZW50Li4uIiB0byANCiAgICAgICAiR01Q TFMgT1NQRiBFbmhhbmNlbWVudC4uLiIgc2luY2UgeW91IGFyZSBub3QgcmVhbGx5IGVuaGFuY2lu ZyBiYXNlIA0KICAgICAgIE9TUEYgaXRzZWxmLiAgT2YgY291cnNlLCB0aGVyZSBhcmUgb3RoZXIg Q0NBTVAgUkZDcyB0aGF0IGRvIG5vdCBtYWtlIA0KICAgICAgIHRoaXMgZGlzdGluY3Rpb24uIA0K DQoNClRoYW5rcywNCkFjZWUgDQoNCg0KICANCk9uIFNlcCA5LCAyMDExLCBhdCAzOjUxIFBNLCBM ZWV5b3VuZyB3cm90ZToNCg0KPiBIaSwNCj4gDQo+IFRoaXMgdXBkYXRlIGFkZGVkIGEgbmV3IHNl Y3Rpb24gdG8gZGlzY3VzcyBPU1BGIHNjYWxhYmlsaXR5IGFuZCBob3cgdG8gdXNlIG11bHRpcGxl IFRFIExTQSBpbnN0YW5jZSB0ZWNobmlxdWUgdG8ga2VlcCB0aGUgTFNBIHVuZGVyIHRoZSBNVFUg bGltaXQuIFBsZWFzZSBub3RlIHRoYXQgdGhlIE1UVSBsaW1pdCBpcyAxNTAwIGJ5dGVzIGFuZCB0 aGUgZXhhbXBsZXMgZ2l2ZW4gaW4gdGhlIGVuY29kaW5nIGRyYWZ0IGlzIGZhciBiZWxvdyB0aGlz IGxpbWl0LiBJbiBjYXNlIHRoZSBMU0Egc2l6ZSBnb2VzIGFib3ZlIHRoZSBNVFUsIHRoaXMgZHJh ZnQgZGlzY3Vzc2VzIGhvdyB0byBzcGxpdCB0aGUgU3ViLVRMVnMnIGRlZmluZWQgdW5kZXIgdGhl IE9wdGljYWwgTm9kZSBQcm9wZXJ0eSBUTFYgdW5kZXIgdGhlIE1UVSBsaW1pdCB0byBhdm9pZCBm cmFnbWVudGF0aW9uLiANCj4gDQo+IFRha2UgYSBsb29rIGF0IFNlY3Rpb24gMyBhbmQgaWYgeW91 IGhhdmUgcXVlc3Rpb25zLCBwbGVhc2UgZmVlbCBmcmVlIHRvIGRpc2N1c3MgaW4gdGhlIG1haWxp bmcgbGlzdC4gDQo+IA0KPiBSZWdhcmRzLA0KPiBZb3VuZw0KPiANCj4gDQo+IA0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWls dG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIA0KPiBPZiBpbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmcNCj4gU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAwOCwgMjAxMSA1OjE2IFBN DQo+IFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4gQ2M6IGNjYW1wQGlldGYub3JnDQo+IFN1 YmplY3Q6IFtDQ0FNUF0gSS1EIEFjdGlvbjogDQo+IGRyYWZ0LWlldGYtY2NhbXAtd3Nvbi1zaWdu YWwtY29tcGF0aWJpbGl0eS1vc3BmLTA1LnR4dA0KPiANCj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQg aXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVjdG9yaWVz LiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBDb21tb24gQ29udHJvbCBhbmQgTWVh c3VyZW1lbnQgUGxhbmUgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4NCj4gDQo+IAlUaXRsZSAg ICAgICAgICAgOiBPU1BGIEVuaGFuY2VtZW50IGZvciBTaWduYWwgYW5kIE5ldHdvcmsgRWxlbWVu dCBDb21wYXRpYmlsaXR5IGZvciBXYXZlbGVuZ3RoIFN3aXRjaGVkIE9wdGljYWwgTmV0d29ya3MN Cj4gCUF1dGhvcihzKSAgICAgICA6IFlvdW5nIExlZQ0KPiAgICAgICAgICAgICAgICAgICAgICAg ICAgR3JlZyBNLiBCZXJuc3RlaW4NCj4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtY2Nh bXAtd3Nvbi1zaWduYWwtY29tcGF0aWJpbGl0eS1vc3BmLTA1LnR4dA0KPiAJUGFnZXMgICAgICAg ICAgIDogMTQNCj4gCURhdGUgICAgICAgICAgICA6IDIwMTEtMDktMDgNCj4gDQo+ICAgVGhpcyBk b2N1bWVudCBwcm92aWRlcyBHTVBMUyBPU1BGIHJvdXRpbmcgZW5oYW5jZW1lbnRzIHRvIHN1cHBv cnQNCj4gICBzaWduYWwgY29tcGF0aWJpbGl0eSBjb25zdHJhaW50cyBhc3NvY2lhdGVkIHdpdGgg V1NPTiBuZXR3b3JrDQo+ICAgZWxlbWVudHMuIFRoZXNlIHJvdXRpbmcgZW5oYW5jZW1lbnRzIGFy ZSByZXF1aXJlZCBpbiBjb21tb24gb3B0aWNhbA0KPiAgIG9yIGh5YnJpZCBlbGVjdHJvLW9wdGlj YWwgbmV0d29ya3Mgd2hlcmUgbm90IGFsbCBvZiB0aGUgb3B0aWNhbA0KPiAgIHNpZ25hbHMgaW4g dGhlIG5ldHdvcmsgYXJlIGNvbXBhdGlibGUgd2l0aCBhbGwgbmV0d29yayBlbGVtZW50cw0KPiAg IHBhcnRpY2lwYXRpbmcgaW4gdGhlIG5ldHdvcmsuDQo+IA0KPiAgIFRoaXMgY29tcGF0aWJpbGl0 eSBjb25zdHJhaW50IG1vZGVsIGlzIGFwcGxpY2FibGUgdG8gY29tbW9uIG9wdGljYWwNCj4gICBv ciBoeWJyaWQgZWxlY3RybyBvcHRpY2FsIHN5c3RlbXMgc3VjaCBhcyBPRU8gc3dpdGNoZXMsIHJl Z2VuZXJhdG9ycywNCj4gICBhbmQgd2F2ZWxlbmd0aCBjb252ZXJ0ZXJzIHNpbmNlIHN1Y2ggc3lz dGVtcyBjYW4gYmUgbGltaXRlZCB0bw0KPiAgIHByb2Nlc3Npbmcgb25seSBjZXJ0YWluIHR5cGVz IG9mIFdTT04gc2lnbmFscy4NCj4gDQo+IA0KPiANCj4gQSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQt RHJhZnQgaXM6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWll dGYtY2NhbXAtd3Nvbi1zaWduYWwtY29tcGENCj4gdGliaWxpdHktb3NwZi0wNS50eHQNCj4gDQo+ IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoN Cj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gDQo+IFRoaXMgSW50ZXJu ZXQtRHJhZnQgY2FuIGJlIHJldHJpZXZlZCBhdDoNCj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWNjYW1wLXdzb24tc2lnbmFsLWNvbXBhdA0KPiBpYmlsaXR5 LW9zcGYtMDUudHh0IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IENDQU1QIG1haWxpbmcgbGlzdA0KPiBDQ0FNUEBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IENDQU1QIG1haWxpbmcgbGlzdA0KPiBDQ0FN UEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1w DQoNCg== From zhangfatai@huawei.com Mon Sep 12 20:40:26 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B1F21F8C6B for ; Mon, 12 Sep 2011 20:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[AWL=1.152, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E5FFCSmxig2h for ; Mon, 12 Sep 2011 20:40:25 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id E8F3521F8C6A for ; Mon, 12 Sep 2011 20:40:24 -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 <0LRF00LCAZL45Q@szxga05-in.huawei.com> for ccamp@ietf.org; Tue, 13 Sep 2011 11:41:29 +0800 (CST) Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRF00IUEZL4MF@szxga05-in.huawei.com> for ccamp@ietf.org; Tue, 13 Sep 2011 11:41:28 +0800 (CST) Received: from szxeml201-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADR74529; Tue, 13 Sep 2011 11:41:27 +0800 Received: from SZXEML401-HUB.china.huawei.com (10.82.67.31) by szxeml201-edg.china.huawei.com (172.24.2.39) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 13 Sep 2011 11:41:24 +0800 Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.184]) by szxeml401-hub.china.huawei.com ([10.82.67.31]) with mapi id 14.01.0270.001; Tue, 13 Sep 2011 11:41:25 +0800 Date: Tue, 13 Sep 2011 03:40:49 +0000 From: Zhangfatai X-Originating-IP: [10.70.76.157] To: Zhangfatai , Acee Lindem , Greg Bernstein , Leeyoung Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt Thread-index: AQHMcZ+ZHZuJ9fm07UCZMv6mUYXLw5VKqMxwgAABIbA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <7AEB3D6833318045B4AE71C2C87E8E1718166966@DFWEML501-MBX.china.huawei.com> <63CEF1D1-D774-40C9-90BB-04BD5E85BF1B@ericsson.com> Cc: CCAMP Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 03:40:26 -0000 SGkgQWNlZSwNCg0KU29ycnkgZm9yIGEgbWlzdGFrZSwgOi0pDQoNCkkgc2hvdWxkIHNheSAid2hl biBJIHVwZGF0ZSBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWdlbmVyYWwtY29uc3RyYWludHMtb3Nw Zi10ZS0wMC50eHQiIGluc3RlYWQgb2YgImRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC1j b25zdHJhaW50cy1vc3BmLXRlLTA1LnR4dCIuDQoNCg0KDQoNCg0KDQpUaGFua3MNCsKgDQpGYXRh aQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBaaGFuZ2ZhdGFpIA0KU2Vu dDogMjAxMeW5tDnmnIgxM+aXpSAxMTozOA0KVG86ICdBY2VlIExpbmRlbSc7IEdyZWcgQmVybnN0 ZWluOyBMZWV5b3VuZw0KQ2M6IENDQU1QDQpTdWJqZWN0OiBSRTogW0NDQU1QXSBGVzogSS1EIEFj dGlvbjogZHJhZnQtaWV0Zi1jY2FtcC13c29uLXNpZ25hbC1jb21wYXRpYmlsaXR5LW9zcGYtMDUu dHh0DQoNCkhpIEFjZWUsDQoNCkkgcGVyc29uYWxseSBhZ3JlZSB3aXRoIHlvdXIgY29tbWVudHMg b24gIm11bHRpLWluc3RhbmNlIExTQSIuDQoNCkkgd2lsbCB0YWtlIHlvdXIgc3VnZ2VzdGlvbnMg aW50byBhY2NvdW50IHdoZW4gSSB1cGRhdGUgImRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJh bC1jb25zdHJhaW50cy1vc3BmLXRlLTA1LnR4dCIuDQoNCg0KDQoNClRoYW5rcw0KwqANCkZhdGFp DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGNjYW1wLWJvdW5jZXNAaWV0 Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWNlZSBM aW5kZW0NClNlbnQ6IDIwMTHlubQ55pyIMTPml6UgNjo1OA0KVG86IEdyZWcgQmVybnN0ZWluOyBM ZWV5b3VuZw0KQ2M6IENDQU1QDQpTdWJqZWN0OiBSZTogW0NDQU1QXSBGVzogSS1EIEFjdGlvbjog ZHJhZnQtaWV0Zi1jY2FtcC13c29uLXNpZ25hbC1jb21wYXRpYmlsaXR5LW9zcGYtMDUudHh0DQoN CkhpIFlvdW5nLCBHcmVnLA0KSSBoYXZlIHRoZSBmb2xsb3dpbmcgY29tbWVudHM6DQoNCiAgIDEu IFNwZWNpZnkgdGhhdCB0aGUgT3B0aWNhbCBOb2RlIFByb3BlcnR5IFRMViBjYXJkaW5hbGl0eSBh bmQgb3JkZXIgcnVsZXMgcGVyIExTQS4gDQogICAgICAgRm9yIGV4YW1wbGUgKGZyb20gUkZDIDM2 MzApOiANCg0KICAgICAiVGhlIExpbmsgVExWIGRlc2NyaWJlcyBhIHNpbmdsZSBsaW5rLiAgSXQg aXMgY29uc3RydWN0ZWQgb2YgYSBzZXQgb2YNCiAgICAgICBzdWItVExWcy4gIFRoZXJlIGFyZSBu byBvcmRlcmluZyByZXF1aXJlbWVudHMgZm9yIHRoZSBzdWItVExWcy4NCg0KICAgICAgT25seSBv bmUgTGluayBUTFYgc2hhbGwgYmUgY2FycmllZCBpbiBlYWNoIExTQSwgYWxsb3dpbmcgZm9yIGZp bmUgIA0KICAgICAgZ3JhbnVsYXJpdHkgY2hhbmdlcyBpbiB0b3BvbG9neS4iDQoNCiAgICAgIEhv d2V2ZXIsIHVzZSB0aGUgdGVybSAiYWR2ZXJ0aXNlZCIgcmF0aGVyIHRoYW4gImNhcnJpZWQiLiBB ZnRlciBhbGwsIHRoZXNlIGFyZQ0KICAgICAgTGluayBTdGF0ZSBBZHZlcnRpc2VtZW50cy4gDQoN CiAgIDIuIFRoZSBzYW1lIGNvbW1lbnQgZm9yIGFsbCB0aGUgU3ViLVRMVnMuIEhlcmUgaXMgYW5v dGhlciBleGFtcGxlIGZyb20gDQogICAgICAgIFJGQyAzNjMwOg0KDQogICAgICAiVGhlIExpbmsg VHlwZSBhbmQgTGluayBJRCBzdWItVExWcyBhcmUgbWFuZGF0b3J5LCBpLmUuLCBtdXN0IGFwcGVh cg0KICAgICAgIGV4YWN0bHkgb25jZS4gIEFsbCBvdGhlciBzdWItVExWcyBkZWZpbmVkIGhlcmUg bWF5IG9jY3VyIGF0IG1vc3QNCiAgICAgICBvbmNlLiAgVGhlc2UgcmVzdHJpY3Rpb25zIG5lZWQg bm90IGFwcGx5IHRvIGZ1dHVyZSBzdWItVExWcy4NCiAgICAgICBVbnJlY29nbml6ZWQgc3ViLVRM VnMgYXJlIGlnbm9yZWQuIg0KDQogICAgICAgVGhlIG5ldyBTdWItVExWcyB5b3UgYXJlIGRlZmlu aW5nIG5lZWQgdGhpcyBsZXZlbCBvZiBzcGVjaWZpY2F0aW9uLiANCg0KICAgMy4gSSBrbm93IEkg dG9sZCB5b3Ugbm90IHRvIHVzZSB0aGUgdGVybSAibXVsdGktaW5zdGFuY2UgTFNBIi4gSSBzdGls bCBkb24ndCBsaWtlDQogICAgICAgdGhlIHVzYWdlIG9mICJMU0EgaW5zdGFuY2UiIGluIHRoZSBk cmFmdC4gSW4gdGhlIGJhc2UgT1NQRiBzcGVjaWZpY2F0aW9uLCBSRkMgMjMyOCwgDQogICAgICAg dGhlIHRlcm0gTFNBIGluc3RhbmNlIGlzIHVzZWQgdG8gZGVub3RlIGEgcGFydGljdWxhciB2ZXJz aW9uIG9mIHRoZSBzYW1lIExTQSAtIE5PVA0KICAgICAgIGFuIG9wYXF1ZSBpZGVudGlmaWVyIGZv ciBtdWx0aXBsZSBMU0FzIG9mIHRoZSBzYW1lIHR5cGUuIFJlZmVyIHRvIHNlY3Rpb24gMTIuMSBp biANCiAgICAgICBSRkMgMjMyOC4gDQoNCiAgICAgIFRoZSBPU1BGIE9wYXF1ZSBMU0EgUkZDIChS RkMgMjM3MCBhbmQgaXRzIHN1Y2Nlc3NvciBSRkMgNTI1MCkgY29ycmVjdGx5IA0KICAgICAgIGlk ZW50aWZ5IHRoZSBsYXN0IDI0IGJpdHMgb2YgdGhlIExTQSBJRCBhcyB0aGUgT3BhcXVlIElELiBX aGlsZSBSRkMgMzYzMCByZWZlcnMNCiAgICAgICB0byB0aGlzIGZpZWxkIGFzIHRoZSAiSW5zdGFu Y2UiLCBJIGJlbGlldmUgdGhpcyB0ZXJtIHNob3VsZCBiZSBhdm9pZGVkIGdpdmVuIHRoZSANCiAg ICAgICBzZW1hbnRpY3MgaW4gdGhlIE9TUEYgYmFzZSBzcGVjaWZpY2F0aW9uLiBIZW5jZSwgSSdk IHN1Z2dlc3QgdGhlIA0KICAgICAgIGZvbGxvd2luZyBjaGFuZ2VzOg0KDQoyMjUsMjI2YzIyNSwy MjYNCjwgICAgdGhlIHJlc3QgYW5kIG1ha2UgdXNlIG9mIG11bHRpcGxlIFRFIExTQSBpbnN0YW5j ZXMgcGVyIHNvdXJjZSwgcGVyDQo8ICAgIFtSRkMzNjMwXSBtdWx0aXBsZSBpbnN0YW5jZSBjYXBh YmlsaXR5Lg0KLS0tDQo+ICAgIHRoZSByZXN0IGFuZCBiZSBhZHZlcnRpc2VkIHdpdGggbXVsdGlw bGUgVEUgTFNBcyBwZXIgT1NQRiByb3V0ZXIsIGFzDQo+ICAgIGRlc2NyaWJlZCBpbiBbUkZDMzYz MF0gYW5kIFtSRkM1MjUwXS4NCjM0MiwzNDRjMzQyLDM0NA0KPCAgICB0aGUgZHluYW1pYyBpbmZv cm1hdGlvbiBzdWItVExWcyBpbnRvIHNlcGFyYXRlIExTQXMgd2l0aGluIGFuIE9wdGljYWwNCjwg ICAgTm9kZSBQcm9wZXJ0eSBUTFYgdXNpbmcgbXVsdGlwbGUgVEUgTFNBIGluc3RhbmNlcyBwZXIg c291cmNlLCBwZXIgdGhlDQo8ICAgIHJlZmVyZW5jZSBbUkZDMzYzMF0gbXVsdGlwbGUgaW5zdGFu Y2UgY2FwYWJpbGl0eS4NCi0tLQ0KPiAgICB0aGUgZHluYW1pYyBpbmZvcm1hdGlvbiBzdWItVExW cyBmcm9tIHRoZSBzdGF0aWMgaW5mb3JtYXRpb24gc3ViLVRMVnMNCj4gICAgYW5kIGFkdmVydGlz ZSB0aGVtIGluIE9TUEYgVEUgTFNBcywgZWFjaCB3aXRoIHRoZSBPcHRpY2FsIE5vZGUNCj4gICAg UHJvcGVydHkgVExWIGF0IHRoZSB0b3AgbGV2ZWwgKFtSRkMzNjMwIGFuZCBSRkM1MjUwXSkuIA0K MzkyYzM5Mg0KPCAgICBpbnRvIHNtYWxsZXIgc3ViLVRMVnMgdGhhdCBjYW4gYmUgc2VudCBpbiBz ZXBhcmF0ZSBMU0EgaW5zdGFuY2VzLg0KLS0tDQo+ICAgIGludG8gc21hbGxlciBzdWItVExWcyB0 aGF0IGNhbiBiZSBzZW50IGluIHNlcGFyYXRlIE9TUEYgVEUgTFNBcy4NCjM5OWMzOTkNCjwgICAg c3ViLVRMVnMgdGhhdCBjYW4gYmUgc2VudCBpbiBtdWx0aXBsZSBMU0EgaW5zdGFuY2VzLiBUaGUN Ci0tLQ0KPiAgICBzdWItVExWcyB0aGF0IGNhbiBiZSBzZW50IGluIG11bHRpcGxlIE9TUEYgVEUg TFNBcy4gVGhlDQo0NzNjNDczDQo8ICAgIGludG8gbXVsdGlwbGUgTFNBIGluc3RhbmNlcyBlYWNo IGNvbnRhaW5pbmcgYSBkaXNqb2ludCBhc3NlbWJseSBvZg0KLS0tDQo+ICAgIGludG8gbXVsdGlw bGUgT1NQRiBURSBMU0FzIGVhY2ggY29udGFpbmluZyBhIGRpc2pvaW50IGFzc2VtYmx5IG9mDQoN CiAgICAgQWRkaXRpb25hbGx5LCBJJ2QgYWRkIFJGQyA1MjUwIGFzIGF0IGxlYXN0IGEgaW5mb3Jt YXRpdmUgcmVmZXJlbmNlLg0KICAgIA0KICAgIA0KDQogICA0LiBGaW5hbGx5LCBJJ2Qgc3VnZ2Vz dCBjaGFuZ2luZyB0aGUgdGl0bGUgZnJvbSAiT1NQRiBFbmhhbmNlbWVudC4uLiIgdG8gDQogICAg ICAgIkdNUExTIE9TUEYgRW5oYW5jZW1lbnQuLi4iIHNpbmNlIHlvdSBhcmUgbm90IHJlYWxseSBl bmhhbmNpbmcgYmFzZSANCiAgICAgICBPU1BGIGl0c2VsZi4gIE9mIGNvdXJzZSwgdGhlcmUgYXJl IG90aGVyIENDQU1QIFJGQ3MgdGhhdCBkbyBub3QgbWFrZSANCiAgICAgICB0aGlzIGRpc3RpbmN0 aW9uLiANCg0KDQpUaGFua3MsDQpBY2VlIA0KDQoNCiAgDQpPbiBTZXAgOSwgMjAxMSwgYXQgMzo1 MSBQTSwgTGVleW91bmcgd3JvdGU6DQoNCj4gSGksDQo+IA0KPiBUaGlzIHVwZGF0ZSBhZGRlZCBh IG5ldyBzZWN0aW9uIHRvIGRpc2N1c3MgT1NQRiBzY2FsYWJpbGl0eSBhbmQgaG93IHRvIHVzZSBt dWx0aXBsZSBURSBMU0EgaW5zdGFuY2UgdGVjaG5pcXVlIHRvIGtlZXAgdGhlIExTQSB1bmRlciB0 aGUgTVRVIGxpbWl0LiBQbGVhc2Ugbm90ZSB0aGF0IHRoZSBNVFUgbGltaXQgaXMgMTUwMCBieXRl cyBhbmQgdGhlIGV4YW1wbGVzIGdpdmVuIGluIHRoZSBlbmNvZGluZyBkcmFmdCBpcyBmYXIgYmVs b3cgdGhpcyBsaW1pdC4gSW4gY2FzZSB0aGUgTFNBIHNpemUgZ29lcyBhYm92ZSB0aGUgTVRVLCB0 aGlzIGRyYWZ0IGRpc2N1c3NlcyBob3cgdG8gc3BsaXQgdGhlIFN1Yi1UTFZzJyBkZWZpbmVkIHVu ZGVyIHRoZSBPcHRpY2FsIE5vZGUgUHJvcGVydHkgVExWIHVuZGVyIHRoZSBNVFUgbGltaXQgdG8g YXZvaWQgZnJhZ21lbnRhdGlvbi4gDQo+IA0KPiBUYWtlIGEgbG9vayBhdCBTZWN0aW9uIDMgYW5k IGlmIHlvdSBoYXZlIHF1ZXN0aW9ucywgcGxlYXNlIGZlZWwgZnJlZSB0byBkaXNjdXNzIGluIHRo ZSBtYWlsaW5nIGxpc3QuIA0KPiANCj4gUmVnYXJkcywNCj4gWW91bmcNCj4gDQo+IA0KPiANCj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiANCj4gT2YgaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnDQo+IFNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMDgsIDIwMTEg NToxNiBQTQ0KPiBUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQo+IENjOiBjY2FtcEBpZXRmLm9y Zw0KPiBTdWJqZWN0OiBbQ0NBTVBdIEktRCBBY3Rpb246IA0KPiBkcmFmdC1pZXRmLWNjYW1wLXdz b24tc2lnbmFsLWNvbXBhdGliaWxpdHktb3NwZi0wNS50eHQNCj4gDQo+IEEgTmV3IEludGVybmV0 LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJl Y3Rvcmllcy4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQ29tbW9uIENvbnRyb2wg YW5kIE1lYXN1cmVtZW50IFBsYW5lIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+IA0KPiAJ VGl0bGUgICAgICAgICAgIDogT1NQRiBFbmhhbmNlbWVudCBmb3IgU2lnbmFsIGFuZCBOZXR3b3Jr IEVsZW1lbnQgQ29tcGF0aWJpbGl0eSBmb3IgV2F2ZWxlbmd0aCBTd2l0Y2hlZCBPcHRpY2FsIE5l dHdvcmtzDQo+IAlBdXRob3IocykgICAgICAgOiBZb3VuZyBMZWUNCj4gICAgICAgICAgICAgICAg ICAgICAgICAgIEdyZWcgTS4gQmVybnN0ZWluDQo+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1p ZXRmLWNjYW1wLXdzb24tc2lnbmFsLWNvbXBhdGliaWxpdHktb3NwZi0wNS50eHQNCj4gCVBhZ2Vz ICAgICAgICAgICA6IDE0DQo+IAlEYXRlICAgICAgICAgICAgOiAyMDExLTA5LTA4DQo+IA0KPiAg IFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgR01QTFMgT1NQRiByb3V0aW5nIGVuaGFuY2VtZW50cyB0 byBzdXBwb3J0DQo+ICAgc2lnbmFsIGNvbXBhdGliaWxpdHkgY29uc3RyYWludHMgYXNzb2NpYXRl ZCB3aXRoIFdTT04gbmV0d29yaw0KPiAgIGVsZW1lbnRzLiBUaGVzZSByb3V0aW5nIGVuaGFuY2Vt ZW50cyBhcmUgcmVxdWlyZWQgaW4gY29tbW9uIG9wdGljYWwNCj4gICBvciBoeWJyaWQgZWxlY3Ry by1vcHRpY2FsIG5ldHdvcmtzIHdoZXJlIG5vdCBhbGwgb2YgdGhlIG9wdGljYWwNCj4gICBzaWdu YWxzIGluIHRoZSBuZXR3b3JrIGFyZSBjb21wYXRpYmxlIHdpdGggYWxsIG5ldHdvcmsgZWxlbWVu dHMNCj4gICBwYXJ0aWNpcGF0aW5nIGluIHRoZSBuZXR3b3JrLg0KPiANCj4gICBUaGlzIGNvbXBh dGliaWxpdHkgY29uc3RyYWludCBtb2RlbCBpcyBhcHBsaWNhYmxlIHRvIGNvbW1vbiBvcHRpY2Fs DQo+ICAgb3IgaHlicmlkIGVsZWN0cm8gb3B0aWNhbCBzeXN0ZW1zIHN1Y2ggYXMgT0VPIHN3aXRj aGVzLCByZWdlbmVyYXRvcnMsDQo+ICAgYW5kIHdhdmVsZW5ndGggY29udmVydGVycyBzaW5jZSBz dWNoIHN5c3RlbXMgY2FuIGJlIGxpbWl0ZWQgdG8NCj4gICBwcm9jZXNzaW5nIG9ubHkgY2VydGFp biB0eXBlcyBvZiBXU09OIHNpZ25hbHMuDQo+IA0KPiANCj4gDQo+IEEgVVJMIGZvciB0aGlzIElu dGVybmV0LURyYWZ0IGlzOg0KPiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1pZXRmLWNjYW1wLXdzb24tc2lnbmFsLWNvbXBhDQo+IHRpYmlsaXR5LW9zcGYtMDUudHh0 DQo+IA0KPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBG VFAgYXQ6DQo+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+IA0KPiBUaGlz IEludGVybmV0LURyYWZ0IGNhbiBiZSByZXRyaWV2ZWQgYXQ6DQo+IGZ0cDovL2Z0cC5pZXRmLm9y Zy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1jY2FtcC13c29uLXNpZ25hbC1jb21wYXQNCj4g aWJpbGl0eS1vc3BmLTA1LnR4dCBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KPiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4gQ0NBTVBAaWV0Zi5vcmcNCj4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBDQ0FNUCBtYWlsaW5nIGxpc3QN Cj4gQ0NBTVBAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9jY2FtcA0KDQo= From internet-drafts@ietf.org Tue Sep 13 01:24:17 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5467721F8B74; Tue, 13 Sep 2011 01:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.579 X-Spam-Level: X-Spam-Status: No, score=-102.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lJYFAXuj7N8g; Tue, 13 Sep 2011 01:24:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D99D921F8B7A; Tue, 13 Sep 2011 01:24:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110913082416.24829.90461.idtracker@ietfa.amsl.com> Date: Tue, 13 Sep 2011 01:24:16 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 08:24:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane = Working Group of the IETF. Title : OSPF-TE Extensions for General Network Element Constrain= ts Author(s) : Fatai Zhang Young Lee Jianrui Han Greg Bernstein Yunbin Xu Filename : draft-ietf-ccamp-gmpls-general-constraints-ospf-te-01.txt Pages : 12 Date : 2011-09-13 Generalized Multiprotocol Label Switching can be used to control a wide variety of technologies including packet switching (e.g., MPLS), time-division (e.g., SONET/SDH, OTN), wavelength (lambdas), and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). 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 describes OSPF routing protocol extensions to support these kinds of constraints under the control of Generalized MPLS (GMPLS). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-general-constrai= nts-ospf-te-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-general-constrain= ts-ospf-te-01.txt From zhangfatai@huawei.com Tue Sep 13 01:30:15 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABDC621F8A66 for ; Tue, 13 Sep 2011 01:30:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.502 X-Spam-Level: X-Spam-Status: No, score=-5.502 tagged_above=-999 required=5 tests=[AWL=1.097, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fx7wZ1smcjWH for ; Tue, 13 Sep 2011 01:30:14 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9174521F886F for ; Tue, 13 Sep 2011 01:30:14 -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 <0LRG00M9WD1SMF@szxga03-in.huawei.com> for ccamp@ietf.org; Tue, 13 Sep 2011 16:32:16 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRG00JWGD1S54@szxga03-in.huawei.com> for ccamp@ietf.org; Tue, 13 Sep 2011 16:32:16 +0800 (CST) Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADY07745; Tue, 13 Sep 2011 16:32:16 +0800 Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 13 Sep 2011 16:32:13 +0800 Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.184]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0270.001; Tue, 13 Sep 2011 16:32:13 +0800 Date: Tue, 13 Sep 2011 08:31:36 +0000 From: Zhangfatai In-reply-to: <20110913082416.24829.90461.idtracker@ietfa.amsl.com> X-Originating-IP: [10.70.76.157] To: "ccamp@ietf.org" Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-01.txt Thread-index: AQHMce+i9FFUflUOuUezjcAL6Gkcpw== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <20110913082416.24829.90461.idtracker@ietfa.amsl.com> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 08:30:15 -0000 SGkgYWxsLA0KDQpUaGVyZSBhcmUgbm8gc2lnbmlmaWNhbnQgY2hhbmdlcyBpbiB0aGlzIHZlcnNp b24sIGp1c3Qgc29tZSBkZXNjcmlwdGlvbiBhYm91dCByb3V0aW5nIHByb2NlZHVyZXMgcmVmaW5l ZC4NCg0KDQoNClRoYW5rcw0KwqANCkZhdGFpDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQpTZW50OiAyMDEx 5bm0OeaciDEz5pelIDE2OjI0DQpUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQpDYzogY2NhbXBA aWV0Zi5vcmcNClN1YmplY3Q6IFtDQ0FNUF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jY2FtcC1n bXBscy1nZW5lcmFsLWNvbnN0cmFpbnRzLW9zcGYtdGUtMDEudHh0DQoNCkEgTmV3IEludGVybmV0 LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJl Y3Rvcmllcy4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQ29tbW9uIENvbnRyb2wg YW5kIE1lYXN1cmVtZW50IFBsYW5lIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQoNCglUaXRs ZSAgICAgICAgICAgOiBPU1BGLVRFIEV4dGVuc2lvbnMgZm9yIEdlbmVyYWwgTmV0d29yayBFbGVt ZW50IENvbnN0cmFpbnRzDQoJQXV0aG9yKHMpICAgICAgIDogRmF0YWkgWmhhbmcNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgWW91bmcgTGVlDQogICAgICAgICAgICAgICAgICAgICAgICAgIEpp YW5ydWkgSGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgIEdyZWcgQmVybnN0ZWluDQogICAg ICAgICAgICAgICAgICAgICAgICAgIFl1bmJpbiBYdQ0KCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0 LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC1jb25zdHJhaW50cy1vc3BmLXRlLTAxLnR4dA0KCVBh Z2VzICAgICAgICAgICA6IDEyDQoJRGF0ZSAgICAgICAgICAgIDogMjAxMS0wOS0xMw0KDQogICBH ZW5lcmFsaXplZCBNdWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGluZyBjYW4gYmUgdXNlZCB0byBj b250cm9sIGENCiAgIHdpZGUgdmFyaWV0eSBvZiB0ZWNobm9sb2dpZXMgaW5jbHVkaW5nIHBhY2tl dCBzd2l0Y2hpbmcgKGUuZy4sIE1QTFMpLA0KICAgdGltZS1kaXZpc2lvbiAoZS5nLiwgU09ORVQv U0RILCBPVE4pLCB3YXZlbGVuZ3RoIChsYW1iZGFzKSwgYW5kDQogICBzcGF0aWFsIHN3aXRjaGlu ZyAoZS5nLiwgaW5jb21pbmcgcG9ydCBvciBmaWJlciB0byBvdXRnb2luZyBwb3J0IG9yDQogICBm aWJlcikuIEluIHNvbWUgb2YgdGhlc2UgdGVjaG5vbG9naWVzIG5ldHdvcmsgZWxlbWVudHMgYW5k IGxpbmtzIG1heQ0KICAgaW1wb3NlIGFkZGl0aW9uYWwgcm91dGluZyBjb25zdHJhaW50cyBzdWNo IGFzIGFzeW1tZXRyaWMgc3dpdGNoDQogICBjb25uZWN0aXZpdHksIG5vbi1sb2NhbCBsYWJlbCBh c3NpZ25tZW50LCBhbmQgbGFiZWwgcmFuZ2UgbGltaXRhdGlvbnMNCiAgIG9uIGxpbmtzLiBUaGlz IGRvY3VtZW50IGRlc2NyaWJlcyBPU1BGIHJvdXRpbmcgcHJvdG9jb2wgZXh0ZW5zaW9ucyB0bw0K ICAgc3VwcG9ydCB0aGVzZSBraW5kcyBvZiBjb25zdHJhaW50cyB1bmRlciB0aGUgY29udHJvbCBv ZiBHZW5lcmFsaXplZA0KICAgTVBMUyAoR01QTFMpLg0KDQoNCg0KQSBVUkwgZm9yIHRoaXMgSW50 ZXJuZXQtRHJhZnQgaXM6DQpodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm dC1pZXRmLWNjYW1wLWdtcGxzLWdlbmVyYWwtY29uc3RyYWludHMtb3NwZi10ZS0wMS50eHQNCg0K SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0K ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCg0KVGhpcyBJbnRlcm5ldC1EcmFm dCBjYW4gYmUgcmV0cmlldmVkIGF0Og0KZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWdlbmVyYWwtY29uc3RyYWludHMtb3NwZi10ZS0wMS50 eHQNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpDQ0FN UCBtYWlsaW5nIGxpc3QNCkNDQU1QQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2NjYW1wDQo= From leeyoung@huawei.com Tue Sep 13 12:53:04 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FC8311E80F3 for ; Tue, 13 Sep 2011 12:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.548 X-Spam-Level: X-Spam-Status: No, score=-6.548 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bklLwrw9P882 for ; Tue, 13 Sep 2011 12:53:03 -0700 (PDT) Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id CD87C11E80E2 for ; Tue, 13 Sep 2011 12:53:03 -0700 (PDT) Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRH000V98NY8W@usaga02-in.huawei.com> for ccamp@ietf.org; Tue, 13 Sep 2011 14:55:10 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPS id <0LRH00KQ28NWGM@usaga02-in.huawei.com> for ccamp@ietf.org; Tue, 13 Sep 2011 14:55:09 -0500 (CDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 13 Sep 2011 12:55:10 -0700 Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Tue, 13 Sep 2011 12:55:03 -0700 Date: Tue, 13 Sep 2011 19:55:03 +0000 From: Leeyoung In-reply-to: <63CEF1D1-D774-40C9-90BB-04BD5E85BF1B@ericsson.com> X-Originating-IP: [172.18.9.109] To: Acee Lindem , Greg Bernstein Message-id: <7AEB3D6833318045B4AE71C2C87E8E1718166F36@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt Thread-index: AQHMcZ+UFFQoSK2Grk66bsO2RD5lYJVLuDBo X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <7AEB3D6833318045B4AE71C2C87E8E1718166966@DFWEML501-MBX.china.huawei.com> <63CEF1D1-D774-40C9-90BB-04BD5E85BF1B@ericsson.com> Cc: CCAMP Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 19:53:04 -0000 Hi Acee, Thanks for your thorough review and great comments. We will incorporate all your comments where possible in the revision. See my comment in-line. Best Regards Young ________________________________________ From: Acee Lindem [acee.lindem@ericsson.com] Sent: Monday, September 12, 2011 5:58 PM To: Greg Bernstein; Leeyoung Cc: CCAMP Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt Hi Young, Greg, I have the following comments: 1. Specify that the Optical Node Property TLV cardinality and order rules per LSA. For example (from RFC 3630): "The Link TLV describes a single link. It is constructed of a set of sub-TLVs. There are no ordering requirements for the sub-TLVs. Only one Link TLV shall be carried in each LSA, allowing for fine granularity changes in topology." However, use the term "advertised" rather than "carried". After all, these are Link State Advertisements. YOUNG>> Yes, I agree. 2. The same comment for all the Sub-TLVs. Here is another example from RFC 3630: "The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear exactly once. All other sub-TLVs defined here may occur at most once. These restrictions need not apply to future sub-TLVs. Unrecognized sub-TLVs are ignored." The new Sub-TLVs you are defining need this level of specification. YOUNG>> Yes, this is fine. 3. I know I told you not to use the term "multi-instance LSA". I still don't like the usage of "LSA instance" in the draft. In the base OSPF specification, RFC 2328, the term LSA instance is used to denote a particular version of the same LSA - NOT an opaque identifier for multiple LSAs of the same type. Refer to section 12.1 in RFC 2328. YOUNG>> Sorry for the confusion. Yes mutliple TE-LSAs are what we are talking about here. The OSPF Opaque LSA RFC (RFC 2370 and its successor RFC 5250) correctly identify the last 24 bits of the LSA ID as the Opaque ID. While RFC 3630 refers to this field as the "Instance", I believe this term should be avoided given the semantics in the OSPF base specification. Hence, I'd suggest the following changes: YOUNG>> Will do. Thanks. 225,226c225,226 < the rest and make use of multiple TE LSA instances per source, per < [RFC3630] multiple instance capability. --- > the rest and be advertised with multiple TE LSAs per OSPF router, as > described in [RFC3630] and [RFC5250]. 342,344c342,344 < the dynamic information sub-TLVs into separate LSAs within an Optical < Node Property TLV using multiple TE LSA instances per source, per the < reference [RFC3630] multiple instance capability. --- > the dynamic information sub-TLVs from the static information sub-TLVs > and advertise them in OSPF TE LSAs, each with the Optical Node > Property TLV at the top level ([RFC3630 and RFC5250]). 392c392 < into smaller sub-TLVs that can be sent in separate LSA instances. --- > into smaller sub-TLVs that can be sent in separate OSPF TE LSAs. 399c399 < sub-TLVs that can be sent in multiple LSA instances. The --- > sub-TLVs that can be sent in multiple OSPF TE LSAs. The 473c473 < into multiple LSA instances each containing a disjoint assembly of --- > into multiple OSPF TE LSAs each containing a disjoint assembly of Additionally, I'd add RFC 5250 as at least a informative reference. 4. Finally, I'd suggest changing the title from "OSPF Enhancement..." to "GMPLS OSPF Enhancement..." since you are not really enhancing base OSPF itself. Of course, there are other CCAMP RFCs that do not make this distinction. YOUNG>> If the chairs are OK with this, we will change the title. Thanks, Acee On Sep 9, 2011, at 3:51 PM, Leeyoung wrote: > Hi, > > This update added a new section to discuss OSPF scalability and how to use multiple TE LSA instance technique to keep the LSA under the MTU limit. Please note that the MTU limit is 1500 bytes and the examples given in the encoding draft is far below this limit. In case the LSA size goes above the MTU, this draft discusses how to split the Sub-TLVs' defined under the Optical Node Property TLV under the MTU limit to avoid fragmentation. > > Take a look at Section 3 and if you have questions, please feel free to discuss in the mailing list. > > Regards, > Young > > > > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org > Sent: Thursday, September 08, 2011 5:16 PM > To: i-d-announce@ietf.org > Cc: ccamp@ietf.org > Subject: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. > > Title : OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks > Author(s) : Young Lee > Greg M. Bernstein > Filename : draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt > Pages : 14 > Date : 2011-09-08 > > This document provides GMPLS OSPF routing enhancements to support > signal compatibility constraints associated with WSON network > elements. These routing enhancements are required in common optical > or hybrid electro-optical networks where not all of the optical > signals in the network are compatible with all network elements > participating in the network. > > This compatibility constraint model is applicable to common optical > or hybrid electro optical systems such as OEO switches, regenerators, > and wavelength converters since such systems can be limited to > processing only certain types of WSON signals. > > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt > _______________________________________________ > 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 acee.lindem@ericsson.com Tue Sep 13 14:02:41 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F1CC11E80DB for ; Tue, 13 Sep 2011 14:02:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.529 X-Spam-Level: X-Spam-Status: No, score=-6.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UmV3C97BoibG for ; Tue, 13 Sep 2011 14:02:40 -0700 (PDT) Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by ietfa.amsl.com (Postfix) with ESMTP id 1454421F8C4E for ; Tue, 13 Sep 2011 14:02:40 -0700 (PDT) Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id p8DL4RYN014551 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 13 Sep 2011 16:04:36 -0500 Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.60]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Tue, 13 Sep 2011 17:04:04 -0400 From: Acee Lindem To: Fatai Zhang Date: Tue, 13 Sep 2011 17:04:01 -0400 Thread-Topic: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt Thread-Index: AcxyWKqYFvUb/PaFRxGLKrzaWB2Oyg== Message-ID: <73C7F487-34D7-49E0-81FC-F3B4F1501D66@ericsson.com> References: <7AEB3D6833318045B4AE71C2C87E8E1718166966@DFWEML501-MBX.china.huawei.com> <63CEF1D1-D774-40C9-90BB-04BD5E85BF1B@ericsson.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; boundary="Apple-Mail-6-485708969"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Cc: CCAMP Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 21:02:41 -0000 --Apple-Mail-6-485708969 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Fatai, I only have two comments on this document: 1. Reference RFC 5250 rather than RFC 2370 as the former obsoleted the = latter.=20 2. Possibly this draft should remove the RFC 5786 restriction that = only a single OSPF TE LSA containing a top-level TLV is allowed.=20 Couldn't the connectivity matrix become quite large?=20 Thanks, Acee On Sep 12, 2011, at 11:40 PM, Zhangfatai wrote: > Hi Acee, >=20 > Sorry for a mistake, :-) >=20 > I should say "when I update = draft-ietf-ccamp-gmpls-general-constraints-ospf-te-00.txt" instead of = "draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05.txt". >=20 >=20 >=20 >=20 >=20 >=20 > Thanks > =20 > Fatai >=20 >=20 > -----Original Message----- > From: Zhangfatai=20 > Sent: 2011=E5=B9=B49=E6=9C=8813=E6=97=A5 11:38 > To: 'Acee Lindem'; Greg Bernstein; Leeyoung > Cc: CCAMP > Subject: RE: [CCAMP] FW: I-D Action: = draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt >=20 > Hi Acee, >=20 > I personally agree with your comments on "multi-instance LSA". >=20 > I will take your suggestions into account when I update = "draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05.txt". >=20 >=20 >=20 >=20 > Thanks > =20 > Fatai >=20 >=20 > -----Original Message----- > From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf = Of Acee Lindem > Sent: 2011=E5=B9=B49=E6=9C=8813=E6=97=A5 6:58 > To: Greg Bernstein; Leeyoung > Cc: CCAMP > Subject: Re: [CCAMP] FW: I-D Action: = draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt >=20 > Hi Young, Greg, > I have the following comments: >=20 > 1. Specify that the Optical Node Property TLV cardinality and order = rules per LSA.=20 > For example (from RFC 3630):=20 >=20 > "The Link TLV describes a single link. It is constructed of a set = of > sub-TLVs. There are no ordering requirements for the sub-TLVs. >=20 > Only one Link TLV shall be carried in each LSA, allowing for fine = =20 > granularity changes in topology." >=20 > However, use the term "advertised" rather than "carried". After = all, these are > Link State Advertisements.=20 >=20 > 2. The same comment for all the Sub-TLVs. Here is another example = from=20 > RFC 3630: >=20 > "The Link Type and Link ID sub-TLVs are mandatory, i.e., must = appear > exactly once. All other sub-TLVs defined here may occur at most > once. These restrictions need not apply to future sub-TLVs. > Unrecognized sub-TLVs are ignored." >=20 > The new Sub-TLVs you are defining need this level of = specification.=20 >=20 > 3. I know I told you not to use the term "multi-instance LSA". I = still don't like > the usage of "LSA instance" in the draft. In the base OSPF = specification, RFC 2328,=20 > the term LSA instance is used to denote a particular version of = the same LSA - NOT > an opaque identifier for multiple LSAs of the same type. Refer = to section 12.1 in=20 > RFC 2328.=20 >=20 > The OSPF Opaque LSA RFC (RFC 2370 and its successor RFC 5250) = correctly=20 > identify the last 24 bits of the LSA ID as the Opaque ID. While = RFC 3630 refers > to this field as the "Instance", I believe this term should be = avoided given the=20 > semantics in the OSPF base specification. Hence, I'd suggest the=20= > following changes: >=20 > 225,226c225,226 > < the rest and make use of multiple TE LSA instances per source, = per > < [RFC3630] multiple instance capability. > --- >> the rest and be advertised with multiple TE LSAs per OSPF router, = as >> described in [RFC3630] and [RFC5250]. > 342,344c342,344 > < the dynamic information sub-TLVs into separate LSAs within an = Optical > < Node Property TLV using multiple TE LSA instances per source, per = the > < reference [RFC3630] multiple instance capability. > --- >> the dynamic information sub-TLVs from the static information = sub-TLVs >> and advertise them in OSPF TE LSAs, each with the Optical Node >> Property TLV at the top level ([RFC3630 and RFC5250]).=20 > 392c392 > < into smaller sub-TLVs that can be sent in separate LSA instances. > --- >> into smaller sub-TLVs that can be sent in separate OSPF TE LSAs. > 399c399 > < sub-TLVs that can be sent in multiple LSA instances. The > --- >> sub-TLVs that can be sent in multiple OSPF TE LSAs. The > 473c473 > < into multiple LSA instances each containing a disjoint assembly = of > --- >> into multiple OSPF TE LSAs each containing a disjoint assembly of >=20 > Additionally, I'd add RFC 5250 as at least a informative = reference. >=20 >=20 >=20 > 4. Finally, I'd suggest changing the title from "OSPF = Enhancement..." to=20 > "GMPLS OSPF Enhancement..." since you are not really enhancing = base=20 > OSPF itself. Of course, there are other CCAMP RFCs that do not = make=20 > this distinction.=20 >=20 >=20 > Thanks, > Acee=20 >=20 >=20 >=20 > On Sep 9, 2011, at 3:51 PM, Leeyoung wrote: >=20 >> Hi, >>=20 >> This update added a new section to discuss OSPF scalability and how = to use multiple TE LSA instance technique to keep the LSA under the MTU = limit. Please note that the MTU limit is 1500 bytes and the examples = given in the encoding draft is far below this limit. In case the LSA = size goes above the MTU, this draft discusses how to split the Sub-TLVs' = defined under the Optical Node Property TLV under the MTU limit to avoid = fragmentation.=20 >>=20 >> Take a look at Section 3 and if you have questions, please feel free = to discuss in the mailing list.=20 >>=20 >> Regards, >> Young >>=20 >>=20 >>=20 >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On = Behalf=20 >> Of internet-drafts@ietf.org >> Sent: Thursday, September 08, 2011 5:16 PM >> To: i-d-announce@ietf.org >> Cc: ccamp@ietf.org >> Subject: [CCAMP] I-D Action:=20 >> draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt >>=20 >> 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. >>=20 >> Title : OSPF Enhancement for Signal and Network = Element Compatibility for Wavelength Switched Optical Networks >> Author(s) : Young Lee >> Greg M. Bernstein >> Filename : = draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt >> Pages : 14 >> Date : 2011-09-08 >>=20 >> This document provides GMPLS OSPF routing enhancements to support >> signal compatibility constraints associated with WSON network >> elements. These routing enhancements are required in common optical >> or hybrid electro-optical networks where not all of the optical >> signals in the network are compatible with all network elements >> participating in the network. >>=20 >> This compatibility constraint model is applicable to common optical >> or hybrid electro optical systems such as OEO switches, = regenerators, >> and wavelength converters since such systems can be limited to >> processing only certain types of WSON signals. >>=20 >>=20 >>=20 >> A URL for this Internet-Draft is: >> = http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compa >> tibility-ospf-05.txt >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> This Internet-Draft can be retrieved at: >> = ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compat >> ibility-ospf-05.txt _______________________________________________ >> 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 >=20 --Apple-Mail-6-485708969 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIM8jCCBDQw ggMcoAMCAQICECFWwVQHDV12M/Sr0yNv0sYwDQYJKoZIhvcNAQEFBQAwOTERMA8GA1UECgwIRXJp Y3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTAeFw0xMDEwMDEyMDA0 NTlaFw0xMzEwMDEyMDA0NDhaMG8xETAPBgNVBAoMCEVyaWNzc29uMR8wHQYDVQQDDBZBY2VlIExp bmRlbSBMaW5kZW0gSUlJMRAwDgYDVQQFEwdlYWxmbGluMScwJQYJKoZIhvcNAQkBFhhhY2VlLmxp bmRlbUBlcmljc3Nvbi5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAI/Dc9ALiZuBMyuv bsc3eBxjXZpMi45Z0vzsUQZTJGTBeY7p9JsdzXC9J1uMisBxYVi39R3KJo6I4hXVp9wrA1rxh4AE bnP1+Gxfpj33uWEFYbBnVAJkIWYWF7CYTn8Zm/yd13vPXtuGA6ESeLnnJafwC9Y0YwUQ+4HX7PNv uauVAgMBAAGjggGEMIIBgDCBwAYDVR0fBIG4MIG1MIGyoIGvoIGshjdodHRwOi8vY3JsLnRydXN0 LnRlbGlhLmNvbS9Fcmljc3Nvbk5MSW5kaXZpZHVhbENBMDEuY3JshnFsZGFwOi8vbGRhcC50cnVz dC50ZWxpYS5jb20vY249RXJpY3Nzb24lMjBOTCUyMEluZGl2aWR1YWwlMjBDQTAxLG89RXJpY3Nz b24/Y2VydGlmaWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnk/YmFzZTAjBgNVHREEHDAagRhhY2Vl LmxpbmRlbUBlcmljc3Nvbi5jb20wRgYDVR0gBD8wPTA7BgYqhXBrAQEwMTAvBggrBgEFBQcCARYj aHR0cDovL3d3dy5lcmljc3Nvbi5jb20vbGVnYWwuc2h0bWwwHQYDVR0OBBYEFAgOzAPuplmPr7C1 BTqV94OyqUdhMB8GA1UdIwQYMBaAFJYnw7jepV9dRD45UuVFsXZfYzCbMA4GA1UdDwEB/wQEAwIF oDANBgkqhkiG9w0BAQUFAAOCAQEAE1gyNW6c2t/YsLxW5sm67+gVGK0Lnge4ub+k8dgGrK7Mj7em nkOIFkjdv/tqdJ/SoUy/WEkBXba2TfpZ+lfluMgLYux1vSvqBUxYBsUHeNth2Q/Y6A9sCaDTBPlK vZ2jLz814NavrVfgTCLdxX6zNtGdwzhviz+FyqyxYF43Q86RP8Gd/Npaz1W8pmYAHm0+lezuTx5k F3Av3+SaZ/MR6s+RWuXEIdED36ajeQz+OG8Mh3nplofzdrOeoWGDz53YlfRhgj+TXo+H1lclZAvD WVaMMXPdb27h9Hngsq87dkCW9uAyv8DI993rdhqzlEgUyQIL32icAXfTmTYgoGPOwjCCBEUwggMt oAMCAQICEBPJ6v/eJq2p3KTKI4GDR+MwDQYJKoZIhvcNAQEFBQAwRDEaMBgGA1UECgwRVGVsaWFT b25lcmEgR3JvdXAxJjAkBgNVBAMMHVRlbGlhU29uZXJhIFB1YmxpYyBSb290IENBIHYxMB4XDTA2 MTAwNjEwMDA1M1oXDTE2MTAwMjA1MDQxN1owOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNVBAMM G0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALYQd+Q1HuuHxDyNGFlEPzCxuPPFO5W2xyr+nqCVnNJ4QYFe1HACqavqNLwUGIqIEyHv1rLn fub9LBc7dQpRHjl/dggin0ONOFJ36nbGEbfHjLJz2BzOWvwl84Sc+Fx09IrDU/SZSWFSfhqTu3TT 39h79brHdRkdPBUgBYgsiFKriHI0TjP5G8628H27BDzqUpzGLSYWgt6/tpwuOH5lcfNfHWMcCYXR lobv0Klu8lxG5amWqAnqrH6ECOyYJTRbHTsaTIZOHy9Qw/0eXPujKT7tU5xxSI2SdceJqzUbAz2o FRQ6Px7/GydpM/Rl+qYoGPcauHUL1aSeVJZqDFqcIF0CAwEAAaOCATwwggE4MBIGA1UdEwEB/wQI MAYBAf8CAQAwRgYDVR0gBD8wPTA7BgcqhXAjAgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVw b3NpdG9yeS50cnVzdC50ZWxpYS5jb20wgYkGA1UdHwSBgTB/MH2ge6B5hndsZGFwOi8vbGRhcC50 cnVzdC50ZWxpYS5jb20vY249VGVsaWFTb25lcmElMjBQdWJsaWMlMjBSb290JTIwQ0ElMjB2MSxv PVRlbGlhU29uZXJhJTIwR3JvdXA/YXV0aG9yaXR5cmV2b2NhdGlvbmxpc3Q/YmFzZTAOBgNVHQ8B Af8EBAMCAQYwHQYDVR0OBBYEFJYnw7jepV9dRD45UuVFsXZfYzCbMB8GA1UdIwQYMBaAFEXb8I+4 GmKhqCMbY4g4o9vgGmLxMA0GCSqGSIb3DQEBBQUAA4IBAQB2AEoqQz+M3Ra9alkpn/YnwhXIv6tP jhUvSuNs00Nhd0T9XhlIU3a65CaB/UKSqnayE0t7Q0Qq3r+x/GK3in/mik8i/PK2/q8HutzYFSzz 6Npztpo2JG7AEKOJPVaeebjng45m6vNC7RIfzU9sG2LBR/hewS8s6dFFn70w795xUwJBWZ67OzIK XrIVVvHTOYpbWA+MESKAXwFhnVONrOTWlVwrMUi4HbiPWpOk+xQbgehCEi7mu3cXsaU1Xq3kMXui NuC7VKoob8mFO9o9RT+dlirD2uRXwNpvCu3but6Kyhu0+nvy2iXGKjdlxlWTsdDyulXYz+OYCMZ9 lFWRzMIPMIIEbTCCA1WgAwIBAgIRAJywjASay5cieGNithuGWj0wDQYJKoZIhvcNAQEFBQAwOjEZ MBcGA1UEChMQUlNBIFNlY3VyaXR5IEluYzEdMBsGA1UECxMUUlNBIFNlY3VyaXR5IDIwNDggVjMw HhcNMDYxMDMxMjA0MjI3WhcNMTYxMTAxMTU0MjI1WjBEMRowGAYDVQQKDBFUZWxpYVNvbmVyYSBH cm91cDEmMCQGA1UEAwwdVGVsaWFTb25lcmEgUHVibGljIFJvb3QgQ0EgdjEwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDKTxADapCAq3mplX4R4gNt+WZe5QKGnaVEQSyY7lICKF5DuVdW PMLHDjzhw5IzDd860ZZx/0VrhGB3DmP4SDIWCKo2PxvY5NckdBWPWp/T2uaQdOAwgqHpN0pe1X7/ jel59WsWYXKGg/81Wth73ZK/geE7Gz9Pvj1LU6N4YhLMgooxKnCS+ZjB5icWAg+Qd1QpQhF46H1i bp6LsBWDp56MPpg8F5X6y7MGVcKYLdnLOPs84uxRW9qs1kBopzQBj6s5SyVh8A+j5liDBjghXYpw /+paGEdqHPeSFYxZKeJatmjEKLYlxcZWRKf436KvQA9jBhMEmytMNbGicR1mRH6tAgMBAAGjggFi MIIBXjAfBgNVHSMEGDAWgBQHw1EwpKrpRa41JPr/JCwz0LGdjDAdBgNVHQ4EFgQURdvwj7gaYqGo IxtjiDij2+AaYvEwEgYDVR0TAQH/BAgwBgEB/wIBBDCBhQYDVR0gBH4wfDA9BgkqhkiG9w0FBgEw MDAuBggrBgEFBQcCARYiaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhLmNvbTA7BgcqhXAj AgEBMDAwLgYIKwYBBQUHAgEWImh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYS5jb20wcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3d3dy5yc2FzZWN1cml0eS5jb20vcHJvZHVjdHMva2Vvbi9y ZXBvc2l0b3J5L2NlcnRpZmljYXRlX3N0YXR1cy9SU0FfU2VjdXJpdHlfMjA0OF92My5DUkwwDgYD VR0PAQH/BAQDAgEGMA0GCSqGSIb3DQEBBQUAA4IBAQAEXpos2CnIm7/872ytSrEHWZgvhOUEkUm2 5PWf/XkWko41TaL9vIS1S6AdWChNqWmnYiS7GfaIiDM9s1D6K7hidWBDOm46bNdM3ZwhMyDCfkDJ SgeJ0w+7YmjvChu7gWqDZCsbtZ5gA1ixCTdDnuZB67JGSPGW6r73coraDP8diOpiQouMvM6bKuTP BH/1poLccsUxsKgrQ23JC9LWCRb8cYHkZjXFH1K44TsIl5Lne2oT0JI3pwdA2v6jO4p/OLHntP+n pjwPbedMPUZkDYCkd3LSxj8c3JTxtA8SlPCtIHE1hh65xihg1JRIliSphrqr9kbfwHdeVxPdOI5G tDYPMYICEjCCAg4CAQEwTTA5MREwDwYDVQQKDAhFcmljc3NvbjEkMCIGA1UEAwwbRXJpY3Nzb24g TkwgSW5kaXZpZHVhbCBDQTAxAhAhVsFUBw1ddjP0q9Mjb9LGMAkGBSsOAwIaBQCgggEbMBgGCSqG SIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDkxMzIxMDQwMlowIwYJKoZI hvcNAQkEMRYEFKG159LGiz9gjsNBlunf7EN+711lMFwGCSsGAQQBgjcQBDFPME0wOTERMA8GA1UE CgwIRXJpY3Nzb24xJDAiBgNVBAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcN XXYz9KvTI2/SxjBeBgsqhkiG9w0BCRACCzFPoE0wOTERMA8GA1UECgwIRXJpY3Nzb24xJDAiBgNV BAMMG0VyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EwMQIQIVbBVAcNXXYz9KvTI2/SxjANBgkqhkiG 9w0BAQEFAASBgEac5GqAYUzvoNe7C2Fjzy+O/3bZrWqer9ez7mCZxC7d5eRhaS+oJaj01qXqX/PU x8QnJYkz9ps0GUUtK75Jf06LXIYFDO656YBq1HWAivPFVBstRoA+q+TLzQp64uWLsj1ng0MXtUOh 5IetbSDIpMLFlYK7hQ0g1B43r47mjtXzAAAAAAAA --Apple-Mail-6-485708969-- From internet-drafts@ietf.org Tue Sep 13 16:05:33 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3AC11E8093; Tue, 13 Sep 2011 16:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.582 X-Spam-Level: X-Spam-Status: No, score=-102.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ykfjkpHkCOB; Tue, 13 Sep 2011 16:05:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A8721F8BC4; Tue, 13 Sep 2011 16:05:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110913230533.17993.48137.idtracker@ietfa.amsl.com> Date: Tue, 13 Sep 2011 16:05:33 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signaling-02.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Sep 2011 23:05:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane = Working Group of the IETF. Title : Signaling Extensions for Wavelength Switched Optical Net= works Author(s) : Greg M. Bernstein Sugang Xu Young Lee Giovanni Martinelli Hiroaki Harai Filename : draft-ietf-ccamp-wson-signaling-02.txt Pages : 23 Date : 2011-09-13 This memo provides extensions to Generalized Multi-Protocol Label Switching (GMPLS) signaling for control of wavelength switched optical networks (WSON). Such extensions are necessary in WSONs under a number of conditions including: (a) when optional processing, such as regeneration, must be configured to occur at specific nodes along a path, (b) where equipment must be configured to accept an optical signal with specific attributes, or (c) where equipment must be configured to output an optical signal with specific attributes. In addition this memo provides mechanisms to support distributed wavelength assignment with bidirectional LSPs, and choice in distributed wavelength assignment algorithms. These extensions build on previous work for the control of lambda and G.709 based networks. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signaling-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signaling-02.txt From zhangfatai@huawei.com Tue Sep 13 19:12:03 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B27021F8BC3 for ; Tue, 13 Sep 2011 19:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.552 X-Spam-Level: X-Spam-Status: No, score=-5.552 tagged_above=-999 required=5 tests=[AWL=1.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id inKzipYALyyT for ; Tue, 13 Sep 2011 19:12:02 -0700 (PDT) Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBF821F8BBF for ; Tue, 13 Sep 2011 19:12:01 -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 <0LRH0089EQ7JG1@szxga03-in.huawei.com> for ccamp@ietf.org; Wed, 14 Sep 2011 10:14:07 +0800 (CST) Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRH00C8AQ7JUR@szxga03-in.huawei.com> for ccamp@ietf.org; Wed, 14 Sep 2011 10:14:07 +0800 (CST) Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA) with ESMTP id ADY42993; Wed, 14 Sep 2011 10:14:06 +0800 Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 14 Sep 2011 10:14:00 +0800 Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.184]) by szxeml404-hub.china.huawei.com ([fe80::75b7:3db9:fedc:a56d%13]) with mapi id 14.01.0270.001; Wed, 14 Sep 2011 10:14:03 +0800 Date: Wed, 14 Sep 2011 02:13:22 +0000 From: Zhangfatai In-reply-to: <73C7F487-34D7-49E0-81FC-F3B4F1501D66@ericsson.com> X-Originating-IP: [10.70.76.157] To: Acee Lindem Message-id: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: zh-CN, en-US Thread-topic: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-01.txt Thread-index: AQHMcoP5zZAdowXV40WV+vT66MWarw== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-CFilter-Loop: Reflected References: <7AEB3D6833318045B4AE71C2C87E8E1718166966@DFWEML501-MBX.china.huawei.com> <63CEF1D1-D774-40C9-90BB-04BD5E85BF1B@ericsson.com> <73C7F487-34D7-49E0-81FC-F3B4F1501D66@ericsson.com> Cc: CCAMP Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Sep 2011 02:12:03 -0000 SGkgQWNlZSwNCg0KRm9yIHlvdXIgcG9pbnQgMTogSSB3aWxsIHJlcGxhY2UgUkZDIDIzNzAgd2l0 aCBSRkMgNTI1MCBpbiB0aGUgZnV0dXJlIHZlcnNpb24uDQoNCkZvciB5b3VyIHBvaW50IDI6IFRo ZXJlIHdlcmUgbG90cyBvZiBkaXNjdXNzaW9uIG9uIHdoZXRoZXIgd2Ugc2hvdWxkIHJlbW92ZSB0 aGUgUkZDNTc4NiByZXN0cmljdGlvbiBpbiB0aGUgbWFpbGluZyBsaXN0ICh3ZSBhbHNvIGFza2Vk IGZvciBzdWdnZXN0aW9ucyBmcm9tIHRoZSBhdXRob3JzIG9mIFJGQzU3ODYpLCBob3dldmVyLCB0 aGVyZSB3YXMgbm8gY29uc2Vuc3VzLg0KDQpBY3R1YWxseSwgaWYgd2UgY2FuIHJlbW92ZSB0aGUg UkZDNTc4NiByZXN0cmljdGlvbiwgaXQgY2FuIG1ha2UgdGhpbmdzIHNpbXBsZSwgZm9yIGV4YW1w bGUsIHdlIGRvbid0IG5lZWQgdG8gZGVmaW5lIGFub3RoZXIgbmV3IHRvcCBOb2RlIFRMViAoaWUu LCBPcHRpY2FsIE5vZGUgUHJvcGVydHkgVExWKSB0byBjYXJyeSBXU09OIE9FTyBzdHVmZi4NCg0K SSB3b3VsZCBsaWtlIHRvIGhlYXIgbW9yZSBvcGluaW9ucyBmcm9tIENDQU1QZXJzIGFuZCBPU1BG ZXJzIG9uIHBvaW50IDIuDQoNCg0KVGhhbmtzDQrCoA0KRmF0YWkNCg0KLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCkZyb206IEFjZWUgTGluZGVtIFttYWlsdG86YWNlZS5saW5kZW1AZXJpY3Nz b24uY29tXSANClNlbnQ6IDIwMTHlubQ55pyIMTTml6UgNTowNA0KVG86IFpoYW5nZmF0YWkNCkNj OiBHcmVnIEJlcm5zdGVpbjsgTGVleW91bmc7IENDQU1QDQpTdWJqZWN0OiBSZTogW0NDQU1QXSBG VzogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jY2FtcC13c29uLXNpZ25hbC1jb21wYXRpYmlsaXR5 LW9zcGYtMDUudHh0DQoNCkhpIEZhdGFpLA0KSSBvbmx5IGhhdmUgdHdvIGNvbW1lbnRzIG9uIHRo aXMgZG9jdW1lbnQ6DQoNCiAgMS4gUmVmZXJlbmNlIFJGQyA1MjUwIHJhdGhlciB0aGFuIFJGQyAy MzcwIGFzIHRoZSBmb3JtZXIgb2Jzb2xldGVkIHRoZSBsYXR0ZXIuIA0KICAyLiBQb3NzaWJseSB0 aGlzIGRyYWZ0IHNob3VsZCByZW1vdmUgdGhlIFJGQyA1Nzg2IHJlc3RyaWN0aW9uIHRoYXQgb25s eSBhIHNpbmdsZSBPU1BGIFRFIExTQSBjb250YWluaW5nIGEgdG9wLWxldmVsIFRMViBpcyBhbGxv d2VkLiANCiAgICAgIENvdWxkbid0IHRoZSBjb25uZWN0aXZpdHkgbWF0cml4IGJlY29tZSBxdWl0 ZSBsYXJnZT8gDQoNClRoYW5rcywNCkFjZWUNCg0KDQpPbiBTZXAgMTIsIDIwMTEsIGF0IDExOjQw IFBNLCBaaGFuZ2ZhdGFpIHdyb3RlOg0KDQo+IEhpIEFjZWUsDQo+IA0KPiBTb3JyeSBmb3IgYSBt aXN0YWtlLCA6LSkNCj4gDQo+IEkgc2hvdWxkIHNheSAid2hlbiBJIHVwZGF0ZSBkcmFmdC1pZXRm LWNjYW1wLWdtcGxzLWdlbmVyYWwtY29uc3RyYWludHMtb3NwZi10ZS0wMC50eHQiIGluc3RlYWQg b2YgImRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC1jb25zdHJhaW50cy1vc3BmLXRlLTA1 LnR4dCIuDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IFRoYW5rcw0KPiAgDQo+IEZhdGFpDQo+ IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogWmhhbmdmYXRhaSAN Cj4gU2VudDogMjAxMeW5tDnmnIgxM+aXpSAxMTozOA0KPiBUbzogJ0FjZWUgTGluZGVtJzsgR3Jl ZyBCZXJuc3RlaW47IExlZXlvdW5nDQo+IENjOiBDQ0FNUA0KPiBTdWJqZWN0OiBSRTogW0NDQU1Q XSBGVzogSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jY2FtcC13c29uLXNpZ25hbC1jb21wYXRpYmls aXR5LW9zcGYtMDUudHh0DQo+IA0KPiBIaSBBY2VlLA0KPiANCj4gSSBwZXJzb25hbGx5IGFncmVl IHdpdGggeW91ciBjb21tZW50cyBvbiAibXVsdGktaW5zdGFuY2UgTFNBIi4NCj4gDQo+IEkgd2ls bCB0YWtlIHlvdXIgc3VnZ2VzdGlvbnMgaW50byBhY2NvdW50IHdoZW4gSSB1cGRhdGUgImRyYWZ0 LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC1jb25zdHJhaW50cy1vc3BmLXRlLTA1LnR4dCIuDQo+ IA0KPiANCj4gDQo+IA0KPiBUaGFua3MNCj4gIA0KPiBGYXRhaQ0KPiANCj4gDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQWNlZSBMaW5kZW0NCj4gU2Vu dDogMjAxMeW5tDnmnIgxM+aXpSA2OjU4DQo+IFRvOiBHcmVnIEJlcm5zdGVpbjsgTGVleW91bmcN Cj4gQ2M6IENDQU1QDQo+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIEZXOiBJLUQgQWN0aW9uOiBkcmFm dC1pZXRmLWNjYW1wLXdzb24tc2lnbmFsLWNvbXBhdGliaWxpdHktb3NwZi0wNS50eHQNCj4gDQo+ IEhpIFlvdW5nLCBHcmVnLA0KPiBJIGhhdmUgdGhlIGZvbGxvd2luZyBjb21tZW50czoNCj4gDQo+ ICAgMS4gU3BlY2lmeSB0aGF0IHRoZSBPcHRpY2FsIE5vZGUgUHJvcGVydHkgVExWIGNhcmRpbmFs aXR5IGFuZCBvcmRlciBydWxlcyBwZXIgTFNBLiANCj4gICAgICAgRm9yIGV4YW1wbGUgKGZyb20g UkZDIDM2MzApOiANCj4gDQo+ICAgICAiVGhlIExpbmsgVExWIGRlc2NyaWJlcyBhIHNpbmdsZSBs aW5rLiAgSXQgaXMgY29uc3RydWN0ZWQgb2YgYSBzZXQgb2YNCj4gICAgICAgc3ViLVRMVnMuICBU aGVyZSBhcmUgbm8gb3JkZXJpbmcgcmVxdWlyZW1lbnRzIGZvciB0aGUgc3ViLVRMVnMuDQo+IA0K PiAgICAgIE9ubHkgb25lIExpbmsgVExWIHNoYWxsIGJlIGNhcnJpZWQgaW4gZWFjaCBMU0EsIGFs bG93aW5nIGZvciBmaW5lICANCj4gICAgICBncmFudWxhcml0eSBjaGFuZ2VzIGluIHRvcG9sb2d5 LiINCj4gDQo+ICAgICAgSG93ZXZlciwgdXNlIHRoZSB0ZXJtICJhZHZlcnRpc2VkIiByYXRoZXIg dGhhbiAiY2FycmllZCIuIEFmdGVyIGFsbCwgdGhlc2UgYXJlDQo+ICAgICAgTGluayBTdGF0ZSBB ZHZlcnRpc2VtZW50cy4gDQo+IA0KPiAgIDIuIFRoZSBzYW1lIGNvbW1lbnQgZm9yIGFsbCB0aGUg U3ViLVRMVnMuIEhlcmUgaXMgYW5vdGhlciBleGFtcGxlIGZyb20gDQo+ICAgICAgICBSRkMgMzYz MDoNCj4gDQo+ICAgICAgIlRoZSBMaW5rIFR5cGUgYW5kIExpbmsgSUQgc3ViLVRMVnMgYXJlIG1h bmRhdG9yeSwgaS5lLiwgbXVzdCBhcHBlYXINCj4gICAgICAgZXhhY3RseSBvbmNlLiAgQWxsIG90 aGVyIHN1Yi1UTFZzIGRlZmluZWQgaGVyZSBtYXkgb2NjdXIgYXQgbW9zdA0KPiAgICAgICBvbmNl LiAgVGhlc2UgcmVzdHJpY3Rpb25zIG5lZWQgbm90IGFwcGx5IHRvIGZ1dHVyZSBzdWItVExWcy4N Cj4gICAgICAgVW5yZWNvZ25pemVkIHN1Yi1UTFZzIGFyZSBpZ25vcmVkLiINCj4gDQo+ICAgICAg IFRoZSBuZXcgU3ViLVRMVnMgeW91IGFyZSBkZWZpbmluZyBuZWVkIHRoaXMgbGV2ZWwgb2Ygc3Bl Y2lmaWNhdGlvbi4gDQo+IA0KPiAgIDMuIEkga25vdyBJIHRvbGQgeW91IG5vdCB0byB1c2UgdGhl IHRlcm0gIm11bHRpLWluc3RhbmNlIExTQSIuIEkgc3RpbGwgZG9uJ3QgbGlrZQ0KPiAgICAgICB0 aGUgdXNhZ2Ugb2YgIkxTQSBpbnN0YW5jZSIgaW4gdGhlIGRyYWZ0LiBJbiB0aGUgYmFzZSBPU1BG IHNwZWNpZmljYXRpb24sIFJGQyAyMzI4LCANCj4gICAgICAgdGhlIHRlcm0gTFNBIGluc3RhbmNl IGlzIHVzZWQgdG8gZGVub3RlIGEgcGFydGljdWxhciB2ZXJzaW9uIG9mIHRoZSBzYW1lIExTQSAt IE5PVA0KPiAgICAgICBhbiBvcGFxdWUgaWRlbnRpZmllciBmb3IgbXVsdGlwbGUgTFNBcyBvZiB0 aGUgc2FtZSB0eXBlLiBSZWZlciB0byBzZWN0aW9uIDEyLjEgaW4gDQo+ICAgICAgIFJGQyAyMzI4 LiANCj4gDQo+ICAgICAgVGhlIE9TUEYgT3BhcXVlIExTQSBSRkMgKFJGQyAyMzcwIGFuZCBpdHMg c3VjY2Vzc29yIFJGQyA1MjUwKSBjb3JyZWN0bHkgDQo+ICAgICAgIGlkZW50aWZ5IHRoZSBsYXN0 IDI0IGJpdHMgb2YgdGhlIExTQSBJRCBhcyB0aGUgT3BhcXVlIElELiBXaGlsZSBSRkMgMzYzMCBy ZWZlcnMNCj4gICAgICAgdG8gdGhpcyBmaWVsZCBhcyB0aGUgIkluc3RhbmNlIiwgSSBiZWxpZXZl IHRoaXMgdGVybSBzaG91bGQgYmUgYXZvaWRlZCBnaXZlbiB0aGUgDQo+ICAgICAgIHNlbWFudGlj cyBpbiB0aGUgT1NQRiBiYXNlIHNwZWNpZmljYXRpb24uIEhlbmNlLCBJJ2Qgc3VnZ2VzdCB0aGUg DQo+ICAgICAgIGZvbGxvd2luZyBjaGFuZ2VzOg0KPiANCj4gMjI1LDIyNmMyMjUsMjI2DQo+IDwg ICAgdGhlIHJlc3QgYW5kIG1ha2UgdXNlIG9mIG11bHRpcGxlIFRFIExTQSBpbnN0YW5jZXMgcGVy IHNvdXJjZSwgcGVyDQo+IDwgICAgW1JGQzM2MzBdIG11bHRpcGxlIGluc3RhbmNlIGNhcGFiaWxp dHkuDQo+IC0tLQ0KPj4gICB0aGUgcmVzdCBhbmQgYmUgYWR2ZXJ0aXNlZCB3aXRoIG11bHRpcGxl IFRFIExTQXMgcGVyIE9TUEYgcm91dGVyLCBhcw0KPj4gICBkZXNjcmliZWQgaW4gW1JGQzM2MzBd IGFuZCBbUkZDNTI1MF0uDQo+IDM0MiwzNDRjMzQyLDM0NA0KPiA8ICAgIHRoZSBkeW5hbWljIGlu Zm9ybWF0aW9uIHN1Yi1UTFZzIGludG8gc2VwYXJhdGUgTFNBcyB3aXRoaW4gYW4gT3B0aWNhbA0K PiA8ICAgIE5vZGUgUHJvcGVydHkgVExWIHVzaW5nIG11bHRpcGxlIFRFIExTQSBpbnN0YW5jZXMg cGVyIHNvdXJjZSwgcGVyIHRoZQ0KPiA8ICAgIHJlZmVyZW5jZSBbUkZDMzYzMF0gbXVsdGlwbGUg aW5zdGFuY2UgY2FwYWJpbGl0eS4NCj4gLS0tDQo+PiAgIHRoZSBkeW5hbWljIGluZm9ybWF0aW9u IHN1Yi1UTFZzIGZyb20gdGhlIHN0YXRpYyBpbmZvcm1hdGlvbiBzdWItVExWcw0KPj4gICBhbmQg YWR2ZXJ0aXNlIHRoZW0gaW4gT1NQRiBURSBMU0FzLCBlYWNoIHdpdGggdGhlIE9wdGljYWwgTm9k ZQ0KPj4gICBQcm9wZXJ0eSBUTFYgYXQgdGhlIHRvcCBsZXZlbCAoW1JGQzM2MzAgYW5kIFJGQzUy NTBdKS4gDQo+IDM5MmMzOTINCj4gPCAgICBpbnRvIHNtYWxsZXIgc3ViLVRMVnMgdGhhdCBjYW4g YmUgc2VudCBpbiBzZXBhcmF0ZSBMU0EgaW5zdGFuY2VzLg0KPiAtLS0NCj4+ICAgaW50byBzbWFs bGVyIHN1Yi1UTFZzIHRoYXQgY2FuIGJlIHNlbnQgaW4gc2VwYXJhdGUgT1NQRiBURSBMU0FzLg0K PiAzOTljMzk5DQo+IDwgICAgc3ViLVRMVnMgdGhhdCBjYW4gYmUgc2VudCBpbiBtdWx0aXBsZSBM U0EgaW5zdGFuY2VzLiBUaGUNCj4gLS0tDQo+PiAgIHN1Yi1UTFZzIHRoYXQgY2FuIGJlIHNlbnQg aW4gbXVsdGlwbGUgT1NQRiBURSBMU0FzLiBUaGUNCj4gNDczYzQ3Mw0KPiA8ICAgIGludG8gbXVs dGlwbGUgTFNBIGluc3RhbmNlcyBlYWNoIGNvbnRhaW5pbmcgYSBkaXNqb2ludCBhc3NlbWJseSBv Zg0KPiAtLS0NCj4+ICAgaW50byBtdWx0aXBsZSBPU1BGIFRFIExTQXMgZWFjaCBjb250YWluaW5n IGEgZGlzam9pbnQgYXNzZW1ibHkgb2YNCj4gDQo+ICAgICBBZGRpdGlvbmFsbHksIEknZCBhZGQg UkZDIDUyNTAgYXMgYXQgbGVhc3QgYSBpbmZvcm1hdGl2ZSByZWZlcmVuY2UuDQo+IA0KPiANCj4g DQo+ICAgNC4gRmluYWxseSwgSSdkIHN1Z2dlc3QgY2hhbmdpbmcgdGhlIHRpdGxlIGZyb20gIk9T UEYgRW5oYW5jZW1lbnQuLi4iIHRvIA0KPiAgICAgICAiR01QTFMgT1NQRiBFbmhhbmNlbWVudC4u LiIgc2luY2UgeW91IGFyZSBub3QgcmVhbGx5IGVuaGFuY2luZyBiYXNlIA0KPiAgICAgICBPU1BG IGl0c2VsZi4gIE9mIGNvdXJzZSwgdGhlcmUgYXJlIG90aGVyIENDQU1QIFJGQ3MgdGhhdCBkbyBu b3QgbWFrZSANCj4gICAgICAgdGhpcyBkaXN0aW5jdGlvbi4gDQo+IA0KPiANCj4gVGhhbmtzLA0K PiBBY2VlIA0KPiANCj4gDQo+IA0KPiBPbiBTZXAgOSwgMjAxMSwgYXQgMzo1MSBQTSwgTGVleW91 bmcgd3JvdGU6DQo+IA0KPj4gSGksDQo+PiANCj4+IFRoaXMgdXBkYXRlIGFkZGVkIGEgbmV3IHNl Y3Rpb24gdG8gZGlzY3VzcyBPU1BGIHNjYWxhYmlsaXR5IGFuZCBob3cgdG8gdXNlIG11bHRpcGxl IFRFIExTQSBpbnN0YW5jZSB0ZWNobmlxdWUgdG8ga2VlcCB0aGUgTFNBIHVuZGVyIHRoZSBNVFUg bGltaXQuIFBsZWFzZSBub3RlIHRoYXQgdGhlIE1UVSBsaW1pdCBpcyAxNTAwIGJ5dGVzIGFuZCB0 aGUgZXhhbXBsZXMgZ2l2ZW4gaW4gdGhlIGVuY29kaW5nIGRyYWZ0IGlzIGZhciBiZWxvdyB0aGlz IGxpbWl0LiBJbiBjYXNlIHRoZSBMU0Egc2l6ZSBnb2VzIGFib3ZlIHRoZSBNVFUsIHRoaXMgZHJh ZnQgZGlzY3Vzc2VzIGhvdyB0byBzcGxpdCB0aGUgU3ViLVRMVnMnIGRlZmluZWQgdW5kZXIgdGhl IE9wdGljYWwgTm9kZSBQcm9wZXJ0eSBUTFYgdW5kZXIgdGhlIE1UVSBsaW1pdCB0byBhdm9pZCBm cmFnbWVudGF0aW9uLiANCj4+IA0KPj4gVGFrZSBhIGxvb2sgYXQgU2VjdGlvbiAzIGFuZCBpZiB5 b3UgaGF2ZSBxdWVzdGlvbnMsIHBsZWFzZSBmZWVsIGZyZWUgdG8gZGlzY3VzcyBpbiB0aGUgbWFp bGluZyBsaXN0LiANCj4+IA0KPj4gUmVnYXJkcywNCj4+IFlvdW5nDQo+PiANCj4+IA0KPj4gDQo+ PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogY2NhbXAtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiANCj4+IE9mIGlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KPj4gU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAwOCwg MjAxMSA1OjE2IFBNDQo+PiBUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQo+PiBDYzogY2NhbXBA aWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFtDQ0FNUF0gSS1EIEFjdGlvbjogDQo+PiBkcmFmdC1pZXRm LWNjYW1wLXdzb24tc2lnbmFsLWNvbXBhdGliaWxpdHktb3NwZi0wNS50eHQNCj4+IA0KPj4gQSBO ZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQt RHJhZnRzIGRpcmVjdG9yaWVzLiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBDb21t b24gQ29udHJvbCBhbmQgTWVhc3VyZW1lbnQgUGxhbmUgV29ya2luZyBHcm91cCBvZiB0aGUgSUVU Ri4NCj4+IA0KPj4gCVRpdGxlICAgICAgICAgICA6IE9TUEYgRW5oYW5jZW1lbnQgZm9yIFNpZ25h bCBhbmQgTmV0d29yayBFbGVtZW50IENvbXBhdGliaWxpdHkgZm9yIFdhdmVsZW5ndGggU3dpdGNo ZWQgT3B0aWNhbCBOZXR3b3Jrcw0KPj4gCUF1dGhvcihzKSAgICAgICA6IFlvdW5nIExlZQ0KPj4g ICAgICAgICAgICAgICAgICAgICAgICAgR3JlZyBNLiBCZXJuc3RlaW4NCj4+IAlGaWxlbmFtZSAg ICAgICAgOiBkcmFmdC1pZXRmLWNjYW1wLXdzb24tc2lnbmFsLWNvbXBhdGliaWxpdHktb3NwZi0w NS50eHQNCj4+IAlQYWdlcyAgICAgICAgICAgOiAxNA0KPj4gCURhdGUgICAgICAgICAgICA6IDIw MTEtMDktMDgNCj4+IA0KPj4gIFRoaXMgZG9jdW1lbnQgcHJvdmlkZXMgR01QTFMgT1NQRiByb3V0 aW5nIGVuaGFuY2VtZW50cyB0byBzdXBwb3J0DQo+PiAgc2lnbmFsIGNvbXBhdGliaWxpdHkgY29u c3RyYWludHMgYXNzb2NpYXRlZCB3aXRoIFdTT04gbmV0d29yaw0KPj4gIGVsZW1lbnRzLiBUaGVz ZSByb3V0aW5nIGVuaGFuY2VtZW50cyBhcmUgcmVxdWlyZWQgaW4gY29tbW9uIG9wdGljYWwNCj4+ ICBvciBoeWJyaWQgZWxlY3Ryby1vcHRpY2FsIG5ldHdvcmtzIHdoZXJlIG5vdCBhbGwgb2YgdGhl IG9wdGljYWwNCj4+ICBzaWduYWxzIGluIHRoZSBuZXR3b3JrIGFyZSBjb21wYXRpYmxlIHdpdGgg YWxsIG5ldHdvcmsgZWxlbWVudHMNCj4+ICBwYXJ0aWNpcGF0aW5nIGluIHRoZSBuZXR3b3JrLg0K Pj4gDQo+PiAgVGhpcyBjb21wYXRpYmlsaXR5IGNvbnN0cmFpbnQgbW9kZWwgaXMgYXBwbGljYWJs ZSB0byBjb21tb24gb3B0aWNhbA0KPj4gIG9yIGh5YnJpZCBlbGVjdHJvIG9wdGljYWwgc3lzdGVt cyBzdWNoIGFzIE9FTyBzd2l0Y2hlcywgcmVnZW5lcmF0b3JzLA0KPj4gIGFuZCB3YXZlbGVuZ3Ro IGNvbnZlcnRlcnMgc2luY2Ugc3VjaCBzeXN0ZW1zIGNhbiBiZSBsaW1pdGVkIHRvDQo+PiAgcHJv Y2Vzc2luZyBvbmx5IGNlcnRhaW4gdHlwZXMgb2YgV1NPTiBzaWduYWxzLg0KPj4gDQo+PiANCj4+ IA0KPj4gQSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJhZnQgaXM6DQo+PiBodHRwOi8vd3d3Lmll dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWNjYW1wLXdzb24tc2lnbmFsLWNvbXBh DQo+PiB0aWJpbGl0eS1vc3BmLTA1LnR4dA0KPj4gDQo+PiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFs c28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcv aW50ZXJuZXQtZHJhZnRzLw0KPj4gDQo+PiBUaGlzIEludGVybmV0LURyYWZ0IGNhbiBiZSByZXRy aWV2ZWQgYXQ6DQo+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWll dGYtY2NhbXAtd3Nvbi1zaWduYWwtY29tcGF0DQo+PiBpYmlsaXR5LW9zcGYtMDUudHh0IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBDQ0FNUCBtYWls aW5nIGxpc3QNCj4+IENDQU1QQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2NjYW1wDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPj4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+PiBDQ0FNUEBpZXRmLm9yZw0K Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPiANCg0K From internet-drafts@ietf.org Thu Sep 15 12:47:52 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6A421F8BBF; Thu, 15 Sep 2011 12:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y8IFIkQ2+7iR; Thu, 15 Sep 2011 12:47:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E96E721F8BAA; Thu, 15 Sep 2011 12:47:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.60 Message-ID: <20110915194751.1118.92540.idtracker@ietfa.amsl.com> Date: Thu, 15 Sep 2011 12:47:51 -0700 Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 19:47:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Common Control and Measurement Plane = Working Group of the IETF. Title : GMPLS OSPF Enhancement for Signal and Network Element Co= mpatibility for Wavelength Switched Optical Networks Author(s) : Young Lee Greg M. Bernstein Filename : draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt Pages : 14 Date : 2011-09-15 This document provides GMPLS OSPF routing enhancements to support signal compatibility constraints associated with WSON network elements. These routing enhancements are required in common optical or hybrid electro-optical networks where not all of the optical signals in the network are compatible with all network elements participating in the network. This compatibility constraint model is applicable to common optical or hybrid electro optical systems such as OEO switches, regenerators, and wavelength converters since such systems can be limited to processing only certain types of WSON signals. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compatibil= ity-ospf-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compatibili= ty-ospf-06.txt From leeyoung@huawei.com Thu Sep 15 13:00:23 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2455921F8678 for ; Thu, 15 Sep 2011 13:00:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.55 X-Spam-Level: X-Spam-Status: No, score=-6.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mzRby0-AfkM for ; Thu, 15 Sep 2011 13:00:22 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 56D9811E8087 for ; Thu, 15 Sep 2011 13:00:22 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRK00D9SY707C@usaga04-in.huawei.com> for ccamp@ietf.org; Thu, 15 Sep 2011 14:59:24 -0500 (CDT) Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRK00189Y6ZJY@usaga04-in.huawei.com> for ccamp@ietf.org; Thu, 15 Sep 2011 14:59:24 -0500 (CDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 15 Sep 2011 12:59:17 -0700 Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Thu, 15 Sep 2011 12:59:23 -0700 Date: Thu, 15 Sep 2011 19:59:22 +0000 From: Leeyoung In-reply-to: <20110915194751.1118.92540.idtracker@ietfa.amsl.com> X-Originating-IP: [10.192.11.52] To: "ccamp@ietf.org" Message-id: <7AEB3D6833318045B4AE71C2C87E8E171816B709@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-language: en-US Content-transfer-encoding: 7BIT Accept-Language: en-US Thread-topic: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt Thread-index: AQHMc+DNFGZirNpekU68H0VT9nct2ZVO2fZw X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <20110915194751.1118.92540.idtracker@ietfa.amsl.com> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Sep 2011 20:00:23 -0000 Hi all, After 05 version publication, Acee provided a number of valuable comments and suggestions. This revision (06) reflects those changes. Please note the following updates: - Change the title of the draft to "GMPLS OSPF Enhancement..." from "OSPF Enhancement..." to make sure the changes apply to the GMPLS OSPF rather than the base OSPF. - Add specific OSPF procedures on how sub-TLVs are packaged per [RFC3630] and editorial change including avoiding "multiple instances of TE LSA" to "multiple TE LSAs". Your comments are always appreciated. Thanks. Best Regards. Young -----Original Message----- From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Thursday, September 15, 2011 2:48 PM To: i-d-announce@ietf.org Cc: ccamp@ietf.org Subject: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : GMPLS OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks Author(s) : Young Lee Greg M. Bernstein Filename : draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt Pages : 14 Date : 2011-09-15 This document provides GMPLS OSPF routing enhancements to support signal compatibility constraints associated with WSON network elements. These routing enhancements are required in common optical or hybrid electro-optical networks where not all of the optical signals in the network are compatible with all network elements participating in the network. This compatibility constraint model is applicable to common optical or hybrid electro optical systems such as OEO switches, regenerators, and wavelength converters since such systems can be limited to processing only certain types of WSON signals. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt _______________________________________________ CCAMP mailing list CCAMP@ietf.org https://www.ietf.org/mailman/listinfo/ccamp From leeyoung@huawei.com Fri Sep 16 13:34:57 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9981621F8D66 for ; Fri, 16 Sep 2011 13:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixAM2a2lnNgf for ; Fri, 16 Sep 2011 13:34:56 -0700 (PDT) Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 7176821F8D5A for ; Fri, 16 Sep 2011 13:34:56 -0700 (PDT) Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRM00EK0ULZDT@usaga04-in.huawei.com> for ccamp@ietf.org; Fri, 16 Sep 2011 15:37:11 -0500 (CDT) Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRM00M42ULXYM@usaga04-in.huawei.com> for ccamp@ietf.org; Fri, 16 Sep 2011 15:37:11 -0500 (CDT) Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 16 Sep 2011 13:37:11 -0700 Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Fri, 16 Sep 2011 13:37:08 -0700 Date: Fri, 16 Sep 2011 20:37:08 +0000 From: Leeyoung In-reply-to: X-Originating-IP: [10.192.11.52] To: Zhangfatai , Acee Lindem Message-id: <7AEB3D6833318045B4AE71C2C87E8E171816B9F2@DFWEML501-MBX.china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-language: en-US Content-transfer-encoding: base64 Accept-Language: en-US Thread-topic: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-01.txt Thread-index: AQHMcoP8iuibvv+18E6z4b0GnEvdWpVQd1cA X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <7AEB3D6833318045B4AE71C2C87E8E1718166966@DFWEML501-MBX.china.huawei.com> <63CEF1D1-D774-40C9-90BB-04BD5E85BF1B@ericsson.com> <73C7F487-34D7-49E0-81FC-F3B4F1501D66@ericsson.com> Cc: CCAMP Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-01.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Sep 2011 20:34:57 -0000 SGkgQWNlZSBhbmQgRmF0YWksDQoNCkl0IG1pZ2h0IGJlIGVhc2llciBqdXN0IHRvIGNyZWF0ZSBh IG5ldyBUb3AgTGV2ZWwgVExWIChzYXkgd2UgbmFtZSBpdCwgIkdlbmV0aWMiIE5vZGUgUHJvcGVy dHkgVExWKSB1bmRlciB3aGljaCB3ZSBjYW4gcGFja2FnZSBhbGwgZ2VuZXJpYyBwcm9wZXJ0aWVz IHN1Y2ggY29ubmVjdGl2aXR5IG1hdHJpeCwgZXRjLiANCg0KU2luY2Ugd2UgYXJlIGNvbmNlcm5l ZCBhYm91dCB0aGUgTVRVIGxpbWl0LCB0aGlzIGFwcHJvYWNoIHdvdWxkIGJlIGEgZ29vZCB3YXkg bm90IHRvIG1peCB1cCB3aXRoIG90aGVyIE5vZGUgYXR0cmlidXRlIHN0dWZmcyBjdXJyZW50bHkg ZGVmaW5lZCB1bmRlciBOb2RlIEF0dHJpYnV0ZSBUTFYuIEluIGxpZ2h0IG9mIE9UTiBzdHVmZiBj b21pbmcgZG93biB0aGUgcGlwZSwgY3JlYXRpbmcgYSBuZXcgVG9wLUxldmVsIFRMViB0byBwdXQg YWxsIHRoZXNlIG5ldyBhdHRyaWJ1dGVzIHNvdW5kcyByZWFzb25hYmxlIHRvIG1lLiANCg0KTGlm dGluZyB1cCA1Nzg2IHJlc3RyaWN0aW9uIGlzIG9idmlvdXNseSBmZWFzaWJsZSBidXQgaXQgdGFr ZXMgYW5vdGhlciBkcmFmdCB0byBzb3J0IGl0IG91dC4gRnJvbSBhIHByb2NlZHVyYWwgcGVyc3Bl Y3RpdmUsIGl0IHdpbGwgdGFrZSBhIGxvbmdlciBwYXRoIGFuZCB0aGUgTVRVIGlzc3VlIHdpbGwg Y29udGludWUgdG8gYmUgYW4gaXNzdWUuIA0KDQpSZWdhcmRzLA0KWW91bmcNCg0KDQoNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFpoYW5nZmF0YWkgDQpTZW50OiBUdWVzZGF5 LCBTZXB0ZW1iZXIgMTMsIDIwMTEgOToxMyBQTQ0KVG86IEFjZWUgTGluZGVtDQpDYzogR3JlZyBC ZXJuc3RlaW47IExlZXlvdW5nOyBDQ0FNUA0KU3ViamVjdDogUkU6IFtDQ0FNUF0gRlc6IEktRCBB Y3Rpb246IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC1jb25zdHJhaW50cy1vc3BmLXRl LTAxLnR4dA0KDQpIaSBBY2VlLA0KDQpGb3IgeW91ciBwb2ludCAxOiBJIHdpbGwgcmVwbGFjZSBS RkMgMjM3MCB3aXRoIFJGQyA1MjUwIGluIHRoZSBmdXR1cmUgdmVyc2lvbi4NCg0KRm9yIHlvdXIg cG9pbnQgMjogVGhlcmUgd2VyZSBsb3RzIG9mIGRpc2N1c3Npb24gb24gd2hldGhlciB3ZSBzaG91 bGQgcmVtb3ZlIHRoZSBSRkM1Nzg2IHJlc3RyaWN0aW9uIGluIHRoZSBtYWlsaW5nIGxpc3QgKHdl IGFsc28gYXNrZWQgZm9yIHN1Z2dlc3Rpb25zIGZyb20gdGhlIGF1dGhvcnMgb2YgUkZDNTc4Niks IGhvd2V2ZXIsIHRoZXJlIHdhcyBubyBjb25zZW5zdXMuDQoNCkFjdHVhbGx5LCBpZiB3ZSBjYW4g cmVtb3ZlIHRoZSBSRkM1Nzg2IHJlc3RyaWN0aW9uLCBpdCBjYW4gbWFrZSB0aGluZ3Mgc2ltcGxl LCBmb3IgZXhhbXBsZSwgd2UgZG9uJ3QgbmVlZCB0byBkZWZpbmUgYW5vdGhlciBuZXcgdG9wIE5v ZGUgVExWIChpZS4sIE9wdGljYWwgTm9kZSBQcm9wZXJ0eSBUTFYpIHRvIGNhcnJ5IFdTT04gT0VP IHN0dWZmLg0KDQpJIHdvdWxkIGxpa2UgdG8gaGVhciBtb3JlIG9waW5pb25zIGZyb20gQ0NBTVBl cnMgYW5kIE9TUEZlcnMgb24gcG9pbnQgMi4NCg0KDQpUaGFua3MNCsKgDQpGYXRhaQ0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogQWNlZSBMaW5kZW0gW21haWx0bzphY2VlLmxp bmRlbUBlcmljc3Nvbi5jb21dIA0KU2VudDogMjAxMeW5tDnmnIgxNOaXpSA1OjA0DQpUbzogWmhh bmdmYXRhaQ0KQ2M6IEdyZWcgQmVybnN0ZWluOyBMZWV5b3VuZzsgQ0NBTVANClN1YmplY3Q6IFJl OiBbQ0NBTVBdIEZXOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNjYW1wLXdzb24tc2lnbmFsLWNv bXBhdGliaWxpdHktb3NwZi0wNS50eHQNCg0KSGkgRmF0YWksDQpJIG9ubHkgaGF2ZSB0d28gY29t bWVudHMgb24gdGhpcyBkb2N1bWVudDoNCg0KICAxLiBSZWZlcmVuY2UgUkZDIDUyNTAgcmF0aGVy IHRoYW4gUkZDIDIzNzAgYXMgdGhlIGZvcm1lciBvYnNvbGV0ZWQgdGhlIGxhdHRlci4gDQogIDIu IFBvc3NpYmx5IHRoaXMgZHJhZnQgc2hvdWxkIHJlbW92ZSB0aGUgUkZDIDU3ODYgcmVzdHJpY3Rp b24gdGhhdCBvbmx5IGEgc2luZ2xlIE9TUEYgVEUgTFNBIGNvbnRhaW5pbmcgYSB0b3AtbGV2ZWwg VExWIGlzIGFsbG93ZWQuIA0KICAgICAgQ291bGRuJ3QgdGhlIGNvbm5lY3Rpdml0eSBtYXRyaXgg YmVjb21lIHF1aXRlIGxhcmdlPyANCg0KVGhhbmtzLA0KQWNlZQ0KDQoNCk9uIFNlcCAxMiwgMjAx MSwgYXQgMTE6NDAgUE0sIFpoYW5nZmF0YWkgd3JvdGU6DQoNCj4gSGkgQWNlZSwNCj4gDQo+IFNv cnJ5IGZvciBhIG1pc3Rha2UsIDotKQ0KPiANCj4gSSBzaG91bGQgc2F5ICJ3aGVuIEkgdXBkYXRl IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC1jb25zdHJhaW50cy1vc3BmLXRlLTAwLnR4 dCIgaW5zdGVhZCBvZiAiZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLWNvbnN0cmFpbnRz LW9zcGYtdGUtMDUudHh0Ii4NCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gVGhhbmtzDQo+ICAN Cj4gRmF0YWkNCj4gDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBa aGFuZ2ZhdGFpIA0KPiBTZW50OiAyMDEx5bm0OeaciDEz5pelIDExOjM4DQo+IFRvOiAnQWNlZSBM aW5kZW0nOyBHcmVnIEJlcm5zdGVpbjsgTGVleW91bmcNCj4gQ2M6IENDQU1QDQo+IFN1YmplY3Q6 IFJFOiBbQ0NBTVBdIEZXOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNjYW1wLXdzb24tc2lnbmFs LWNvbXBhdGliaWxpdHktb3NwZi0wNS50eHQNCj4gDQo+IEhpIEFjZWUsDQo+IA0KPiBJIHBlcnNv bmFsbHkgYWdyZWUgd2l0aCB5b3VyIGNvbW1lbnRzIG9uICJtdWx0aS1pbnN0YW5jZSBMU0EiLg0K PiANCj4gSSB3aWxsIHRha2UgeW91ciBzdWdnZXN0aW9ucyBpbnRvIGFjY291bnQgd2hlbiBJIHVw ZGF0ZSAiZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLWNvbnN0cmFpbnRzLW9zcGYtdGUt MDUudHh0Ii4NCj4gDQo+IA0KPiANCj4gDQo+IFRoYW5rcw0KPiAgDQo+IEZhdGFpDQo+IA0KPiAN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogY2NhbXAtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBY2VlIExp bmRlbQ0KPiBTZW50OiAyMDEx5bm0OeaciDEz5pelIDY6NTgNCj4gVG86IEdyZWcgQmVybnN0ZWlu OyBMZWV5b3VuZw0KPiBDYzogQ0NBTVANCj4gU3ViamVjdDogUmU6IFtDQ0FNUF0gRlc6IEktRCBB Y3Rpb246IGRyYWZ0LWlldGYtY2NhbXAtd3Nvbi1zaWduYWwtY29tcGF0aWJpbGl0eS1vc3BmLTA1 LnR4dA0KPiANCj4gSGkgWW91bmcsIEdyZWcsDQo+IEkgaGF2ZSB0aGUgZm9sbG93aW5nIGNvbW1l bnRzOg0KPiANCj4gICAxLiBTcGVjaWZ5IHRoYXQgdGhlIE9wdGljYWwgTm9kZSBQcm9wZXJ0eSBU TFYgY2FyZGluYWxpdHkgYW5kIG9yZGVyIHJ1bGVzIHBlciBMU0EuIA0KPiAgICAgICBGb3IgZXhh bXBsZSAoZnJvbSBSRkMgMzYzMCk6IA0KPiANCj4gICAgICJUaGUgTGluayBUTFYgZGVzY3JpYmVz IGEgc2luZ2xlIGxpbmsuICBJdCBpcyBjb25zdHJ1Y3RlZCBvZiBhIHNldCBvZg0KPiAgICAgICBz dWItVExWcy4gIFRoZXJlIGFyZSBubyBvcmRlcmluZyByZXF1aXJlbWVudHMgZm9yIHRoZSBzdWIt VExWcy4NCj4gDQo+ICAgICAgT25seSBvbmUgTGluayBUTFYgc2hhbGwgYmUgY2FycmllZCBpbiBl YWNoIExTQSwgYWxsb3dpbmcgZm9yIGZpbmUgIA0KPiAgICAgIGdyYW51bGFyaXR5IGNoYW5nZXMg aW4gdG9wb2xvZ3kuIg0KPiANCj4gICAgICBIb3dldmVyLCB1c2UgdGhlIHRlcm0gImFkdmVydGlz ZWQiIHJhdGhlciB0aGFuICJjYXJyaWVkIi4gQWZ0ZXIgYWxsLCB0aGVzZSBhcmUNCj4gICAgICBM aW5rIFN0YXRlIEFkdmVydGlzZW1lbnRzLiANCj4gDQo+ICAgMi4gVGhlIHNhbWUgY29tbWVudCBm b3IgYWxsIHRoZSBTdWItVExWcy4gSGVyZSBpcyBhbm90aGVyIGV4YW1wbGUgZnJvbSANCj4gICAg ICAgIFJGQyAzNjMwOg0KPiANCj4gICAgICAiVGhlIExpbmsgVHlwZSBhbmQgTGluayBJRCBzdWIt VExWcyBhcmUgbWFuZGF0b3J5LCBpLmUuLCBtdXN0IGFwcGVhcg0KPiAgICAgICBleGFjdGx5IG9u Y2UuICBBbGwgb3RoZXIgc3ViLVRMVnMgZGVmaW5lZCBoZXJlIG1heSBvY2N1ciBhdCBtb3N0DQo+ ICAgICAgIG9uY2UuICBUaGVzZSByZXN0cmljdGlvbnMgbmVlZCBub3QgYXBwbHkgdG8gZnV0dXJl IHN1Yi1UTFZzLg0KPiAgICAgICBVbnJlY29nbml6ZWQgc3ViLVRMVnMgYXJlIGlnbm9yZWQuIg0K PiANCj4gICAgICAgVGhlIG5ldyBTdWItVExWcyB5b3UgYXJlIGRlZmluaW5nIG5lZWQgdGhpcyBs ZXZlbCBvZiBzcGVjaWZpY2F0aW9uLiANCj4gDQo+ICAgMy4gSSBrbm93IEkgdG9sZCB5b3Ugbm90 IHRvIHVzZSB0aGUgdGVybSAibXVsdGktaW5zdGFuY2UgTFNBIi4gSSBzdGlsbCBkb24ndCBsaWtl DQo+ICAgICAgIHRoZSB1c2FnZSBvZiAiTFNBIGluc3RhbmNlIiBpbiB0aGUgZHJhZnQuIEluIHRo ZSBiYXNlIE9TUEYgc3BlY2lmaWNhdGlvbiwgUkZDIDIzMjgsIA0KPiAgICAgICB0aGUgdGVybSBM U0EgaW5zdGFuY2UgaXMgdXNlZCB0byBkZW5vdGUgYSBwYXJ0aWN1bGFyIHZlcnNpb24gb2YgdGhl IHNhbWUgTFNBIC0gTk9UDQo+ICAgICAgIGFuIG9wYXF1ZSBpZGVudGlmaWVyIGZvciBtdWx0aXBs ZSBMU0FzIG9mIHRoZSBzYW1lIHR5cGUuIFJlZmVyIHRvIHNlY3Rpb24gMTIuMSBpbiANCj4gICAg ICAgUkZDIDIzMjguIA0KPiANCj4gICAgICBUaGUgT1NQRiBPcGFxdWUgTFNBIFJGQyAoUkZDIDIz NzAgYW5kIGl0cyBzdWNjZXNzb3IgUkZDIDUyNTApIGNvcnJlY3RseSANCj4gICAgICAgaWRlbnRp ZnkgdGhlIGxhc3QgMjQgYml0cyBvZiB0aGUgTFNBIElEIGFzIHRoZSBPcGFxdWUgSUQuIFdoaWxl IFJGQyAzNjMwIHJlZmVycw0KPiAgICAgICB0byB0aGlzIGZpZWxkIGFzIHRoZSAiSW5zdGFuY2Ui LCBJIGJlbGlldmUgdGhpcyB0ZXJtIHNob3VsZCBiZSBhdm9pZGVkIGdpdmVuIHRoZSANCj4gICAg ICAgc2VtYW50aWNzIGluIHRoZSBPU1BGIGJhc2Ugc3BlY2lmaWNhdGlvbi4gSGVuY2UsIEknZCBz dWdnZXN0IHRoZSANCj4gICAgICAgZm9sbG93aW5nIGNoYW5nZXM6DQo+IA0KPiAyMjUsMjI2YzIy NSwyMjYNCj4gPCAgICB0aGUgcmVzdCBhbmQgbWFrZSB1c2Ugb2YgbXVsdGlwbGUgVEUgTFNBIGlu c3RhbmNlcyBwZXIgc291cmNlLCBwZXINCj4gPCAgICBbUkZDMzYzMF0gbXVsdGlwbGUgaW5zdGFu Y2UgY2FwYWJpbGl0eS4NCj4gLS0tDQo+PiAgIHRoZSByZXN0IGFuZCBiZSBhZHZlcnRpc2VkIHdp dGggbXVsdGlwbGUgVEUgTFNBcyBwZXIgT1NQRiByb3V0ZXIsIGFzDQo+PiAgIGRlc2NyaWJlZCBp biBbUkZDMzYzMF0gYW5kIFtSRkM1MjUwXS4NCj4gMzQyLDM0NGMzNDIsMzQ0DQo+IDwgICAgdGhl IGR5bmFtaWMgaW5mb3JtYXRpb24gc3ViLVRMVnMgaW50byBzZXBhcmF0ZSBMU0FzIHdpdGhpbiBh biBPcHRpY2FsDQo+IDwgICAgTm9kZSBQcm9wZXJ0eSBUTFYgdXNpbmcgbXVsdGlwbGUgVEUgTFNB IGluc3RhbmNlcyBwZXIgc291cmNlLCBwZXIgdGhlDQo+IDwgICAgcmVmZXJlbmNlIFtSRkMzNjMw XSBtdWx0aXBsZSBpbnN0YW5jZSBjYXBhYmlsaXR5Lg0KPiAtLS0NCj4+ICAgdGhlIGR5bmFtaWMg aW5mb3JtYXRpb24gc3ViLVRMVnMgZnJvbSB0aGUgc3RhdGljIGluZm9ybWF0aW9uIHN1Yi1UTFZz DQo+PiAgIGFuZCBhZHZlcnRpc2UgdGhlbSBpbiBPU1BGIFRFIExTQXMsIGVhY2ggd2l0aCB0aGUg T3B0aWNhbCBOb2RlDQo+PiAgIFByb3BlcnR5IFRMViBhdCB0aGUgdG9wIGxldmVsIChbUkZDMzYz MCBhbmQgUkZDNTI1MF0pLiANCj4gMzkyYzM5Mg0KPiA8ICAgIGludG8gc21hbGxlciBzdWItVExW cyB0aGF0IGNhbiBiZSBzZW50IGluIHNlcGFyYXRlIExTQSBpbnN0YW5jZXMuDQo+IC0tLQ0KPj4g ICBpbnRvIHNtYWxsZXIgc3ViLVRMVnMgdGhhdCBjYW4gYmUgc2VudCBpbiBzZXBhcmF0ZSBPU1BG IFRFIExTQXMuDQo+IDM5OWMzOTkNCj4gPCAgICBzdWItVExWcyB0aGF0IGNhbiBiZSBzZW50IGlu IG11bHRpcGxlIExTQSBpbnN0YW5jZXMuIFRoZQ0KPiAtLS0NCj4+ICAgc3ViLVRMVnMgdGhhdCBj YW4gYmUgc2VudCBpbiBtdWx0aXBsZSBPU1BGIFRFIExTQXMuIFRoZQ0KPiA0NzNjNDczDQo+IDwg ICAgaW50byBtdWx0aXBsZSBMU0EgaW5zdGFuY2VzIGVhY2ggY29udGFpbmluZyBhIGRpc2pvaW50 IGFzc2VtYmx5IG9mDQo+IC0tLQ0KPj4gICBpbnRvIG11bHRpcGxlIE9TUEYgVEUgTFNBcyBlYWNo IGNvbnRhaW5pbmcgYSBkaXNqb2ludCBhc3NlbWJseSBvZg0KPiANCj4gICAgIEFkZGl0aW9uYWxs eSwgSSdkIGFkZCBSRkMgNTI1MCBhcyBhdCBsZWFzdCBhIGluZm9ybWF0aXZlIHJlZmVyZW5jZS4N Cj4gDQo+IA0KPiANCj4gICA0LiBGaW5hbGx5LCBJJ2Qgc3VnZ2VzdCBjaGFuZ2luZyB0aGUgdGl0 bGUgZnJvbSAiT1NQRiBFbmhhbmNlbWVudC4uLiIgdG8gDQo+ICAgICAgICJHTVBMUyBPU1BGIEVu aGFuY2VtZW50Li4uIiBzaW5jZSB5b3UgYXJlIG5vdCByZWFsbHkgZW5oYW5jaW5nIGJhc2UgDQo+ ICAgICAgIE9TUEYgaXRzZWxmLiAgT2YgY291cnNlLCB0aGVyZSBhcmUgb3RoZXIgQ0NBTVAgUkZD cyB0aGF0IGRvIG5vdCBtYWtlIA0KPiAgICAgICB0aGlzIGRpc3RpbmN0aW9uLiANCj4gDQo+IA0K PiBUaGFua3MsDQo+IEFjZWUgDQo+IA0KPiANCj4gDQo+IE9uIFNlcCA5LCAyMDExLCBhdCAzOjUx IFBNLCBMZWV5b3VuZyB3cm90ZToNCj4gDQo+PiBIaSwNCj4+IA0KPj4gVGhpcyB1cGRhdGUgYWRk ZWQgYSBuZXcgc2VjdGlvbiB0byBkaXNjdXNzIE9TUEYgc2NhbGFiaWxpdHkgYW5kIGhvdyB0byB1 c2UgbXVsdGlwbGUgVEUgTFNBIGluc3RhbmNlIHRlY2huaXF1ZSB0byBrZWVwIHRoZSBMU0EgdW5k ZXIgdGhlIE1UVSBsaW1pdC4gUGxlYXNlIG5vdGUgdGhhdCB0aGUgTVRVIGxpbWl0IGlzIDE1MDAg Ynl0ZXMgYW5kIHRoZSBleGFtcGxlcyBnaXZlbiBpbiB0aGUgZW5jb2RpbmcgZHJhZnQgaXMgZmFy IGJlbG93IHRoaXMgbGltaXQuIEluIGNhc2UgdGhlIExTQSBzaXplIGdvZXMgYWJvdmUgdGhlIE1U VSwgdGhpcyBkcmFmdCBkaXNjdXNzZXMgaG93IHRvIHNwbGl0IHRoZSBTdWItVExWcycgZGVmaW5l ZCB1bmRlciB0aGUgT3B0aWNhbCBOb2RlIFByb3BlcnR5IFRMViB1bmRlciB0aGUgTVRVIGxpbWl0 IHRvIGF2b2lkIGZyYWdtZW50YXRpb24uIA0KPj4gDQo+PiBUYWtlIGEgbG9vayBhdCBTZWN0aW9u IDMgYW5kIGlmIHlvdSBoYXZlIHF1ZXN0aW9ucywgcGxlYXNlIGZlZWwgZnJlZSB0byBkaXNjdXNz IGluIHRoZSBtYWlsaW5nIGxpc3QuIA0KPj4gDQo+PiBSZWdhcmRzLA0KPj4gWW91bmcNCj4+IA0K Pj4gDQo+PiANCj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBjY2FtcC1i b3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IA0KPj4gT2YgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+PiBTZW50OiBUaHVyc2RheSwgU2Vw dGVtYmVyIDA4LCAyMDExIDU6MTYgUE0NCj4+IFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4+ IENjOiBjY2FtcEBpZXRmLm9yZw0KPj4gU3ViamVjdDogW0NDQU1QXSBJLUQgQWN0aW9uOiANCj4+ IGRyYWZ0LWlldGYtY2NhbXAtd3Nvbi1zaWduYWwtY29tcGF0aWJpbGl0eS1vc3BmLTA1LnR4dA0K Pj4gDQo+PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGlu ZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0g b2YgdGhlIENvbW1vbiBDb250cm9sIGFuZCBNZWFzdXJlbWVudCBQbGFuZSBXb3JraW5nIEdyb3Vw IG9mIHRoZSBJRVRGLg0KPj4gDQo+PiAJVGl0bGUgICAgICAgICAgIDogT1NQRiBFbmhhbmNlbWVu dCBmb3IgU2lnbmFsIGFuZCBOZXR3b3JrIEVsZW1lbnQgQ29tcGF0aWJpbGl0eSBmb3IgV2F2ZWxl bmd0aCBTd2l0Y2hlZCBPcHRpY2FsIE5ldHdvcmtzDQo+PiAJQXV0aG9yKHMpICAgICAgIDogWW91 bmcgTGVlDQo+PiAgICAgICAgICAgICAgICAgICAgICAgICBHcmVnIE0uIEJlcm5zdGVpbg0KPj4g CUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtY2NhbXAtd3Nvbi1zaWduYWwtY29tcGF0aWJp bGl0eS1vc3BmLTA1LnR4dA0KPj4gCVBhZ2VzICAgICAgICAgICA6IDE0DQo+PiAJRGF0ZSAgICAg ICAgICAgIDogMjAxMS0wOS0wOA0KPj4gDQo+PiAgVGhpcyBkb2N1bWVudCBwcm92aWRlcyBHTVBM UyBPU1BGIHJvdXRpbmcgZW5oYW5jZW1lbnRzIHRvIHN1cHBvcnQNCj4+ICBzaWduYWwgY29tcGF0 aWJpbGl0eSBjb25zdHJhaW50cyBhc3NvY2lhdGVkIHdpdGggV1NPTiBuZXR3b3JrDQo+PiAgZWxl bWVudHMuIFRoZXNlIHJvdXRpbmcgZW5oYW5jZW1lbnRzIGFyZSByZXF1aXJlZCBpbiBjb21tb24g b3B0aWNhbA0KPj4gIG9yIGh5YnJpZCBlbGVjdHJvLW9wdGljYWwgbmV0d29ya3Mgd2hlcmUgbm90 IGFsbCBvZiB0aGUgb3B0aWNhbA0KPj4gIHNpZ25hbHMgaW4gdGhlIG5ldHdvcmsgYXJlIGNvbXBh dGlibGUgd2l0aCBhbGwgbmV0d29yayBlbGVtZW50cw0KPj4gIHBhcnRpY2lwYXRpbmcgaW4gdGhl IG5ldHdvcmsuDQo+PiANCj4+ICBUaGlzIGNvbXBhdGliaWxpdHkgY29uc3RyYWludCBtb2RlbCBp cyBhcHBsaWNhYmxlIHRvIGNvbW1vbiBvcHRpY2FsDQo+PiAgb3IgaHlicmlkIGVsZWN0cm8gb3B0 aWNhbCBzeXN0ZW1zIHN1Y2ggYXMgT0VPIHN3aXRjaGVzLCByZWdlbmVyYXRvcnMsDQo+PiAgYW5k IHdhdmVsZW5ndGggY29udmVydGVycyBzaW5jZSBzdWNoIHN5c3RlbXMgY2FuIGJlIGxpbWl0ZWQg dG8NCj4+ICBwcm9jZXNzaW5nIG9ubHkgY2VydGFpbiB0eXBlcyBvZiBXU09OIHNpZ25hbHMuDQo+ PiANCj4+IA0KPj4gDQo+PiBBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoNCj4+IGh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtY2NhbXAtd3Nvbi1z aWduYWwtY29tcGENCj4+IHRpYmlsaXR5LW9zcGYtMDUudHh0DQo+PiANCj4+IEludGVybmV0LURy YWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4+IGZ0cDovL2Z0 cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQo+PiANCj4+IFRoaXMgSW50ZXJuZXQtRHJhZnQg Y2FuIGJlIHJldHJpZXZlZCBhdDoNCj4+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFm dHMvZHJhZnQtaWV0Zi1jY2FtcC13c29uLXNpZ25hbC1jb21wYXQNCj4+IGliaWxpdHktb3NwZi0w NS50eHQgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ IENDQU1QIG1haWxpbmcgbGlzdA0KPj4gQ0NBTVBAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4+IENDQU1Q QGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1w DQo+IA0KDQo= From db3546@att.com Mon Sep 19 08:24:31 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6905B21F8C44 for ; Mon, 19 Sep 2011 08:24:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZPwZ9ObWXUNI for ; Mon, 19 Sep 2011 08:24:30 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id B65AA21F8C0C for ; Mon, 19 Sep 2011 08:24:30 -0700 (PDT) X-Env-Sender: db3546@att.com X-Msg-Ref: server-4.tower-120.messagelabs.com!1316446012!38960682!1 X-Originating-IP: [144.160.20.145] X-StarScan-Version: 6.3.6; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29864 invoked from network); 19 Sep 2011 15:26:52 -0000 Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-4.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Sep 2011 15:26:52 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p8JFRJAu029648 for ; Mon, 19 Sep 2011 11:27:19 -0400 Received: from MISOUT7MSGHUB9E.ITServices.sbc.com (misout7msghub9e.itservices.sbc.com [144.151.223.61]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p8JFRBIB029474 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 19 Sep 2011 11:27:14 -0400 Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([169.254.6.215]) by MISOUT7MSGHUB9E.ITServices.sbc.com ([144.151.223.61]) with mapi id 14.01.0289.001; Mon, 19 Sep 2011 11:26:44 -0400 From: "BRUNGARD, DEBORAH A" To: "ccamp@ietf.org" Thread-Topic: WG Last Call on draft-ietf-ccamp-rfc5787bis-03.txt Thread-Index: Acx24Ik9Fl+dh3XcSyuHbZ2eztUwvA== Date: Mon, 19 Sep 2011 15:26:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.16.234.231] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [CCAMP] WG Last Call on draft-ietf-ccamp-rfc5787bis-03.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 15:24:31 -0000 All, This is start a two-week working group last call on draft-ietf-ccamp-rfc578= 7bis-03.txt. This working group last call ends Oct. 3rd. Please send your comments to th= e CCAMP mailing list. Deborah (and Lou) From giomarti@cisco.com Mon Sep 19 13:06:32 2011 Return-Path: X-Original-To: ccamp@ietfa.amsl.com Delivered-To: ccamp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F80421F8D56 for ; Mon, 19 Sep 2011 13:06:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocF68gSbAmkl for ; Mon, 19 Sep 2011 13:06:29 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 406D521F8D43 for ; Mon, 19 Sep 2011 13:06:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=giomarti@cisco.com; l=20523; q=dns/txt; s=iport; t=1316462932; x=1317672532; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=sXK99gTgO4j78SSKaVZUxYrWGRjgSiwGXjF20Q2och0=; b=e17CmME9+NYRCIZVDpOu2mrPyfF9roDP/hqFbchHn4DHDXu70zrpkp+Z WTiSq1ySzSro3C938ePSVjh2idSjIsXsuye5MElqof4LR9NatzvGni3Kn aPUo2jZQ9ZhEtgCVB89NNV3YVj27odji/MpjefxA8jLhZ7PIb+tDuNFJT g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAAAGSgd06Q/khM/2dsb2JhbAA4CphXjmd3gVMBAQEBAgEBAQEPAVQHCgEFBwQLEQQBAQEJDAoIBwkDAgECARUfCAEIBg0BBQIBAQUZh1UElngBniODURODFASTSZEv X-IronPort-AV: E=Sophos;i="4.68,407,1312156800"; d="scan'208,217";a="55197892" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 19 Sep 2011 20:08:51 +0000 Received: from dhcp-10-55-81-111.cisco.com (dhcp-10-55-81-111.cisco.com [10.55.81.111]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p8JK8oLW027104; Mon, 19 Sep 2011 20:08:50 GMT Message-ID: <4E77A151.6000200@cisco.com> Date: Mon, 19 Sep 2011 22:08:49 +0200 From: Giovanni Martinelli User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Acee Lindem References: <7AEB3D6833318045B4AE71C2C87E8E1718166966@DFWEML501-MBX.china.huawei.com> <63CEF1D1-D774-40C9-90BB-04BD5E85BF1B@ericsson.com> <73C7F487-34D7-49E0-81FC-F3B4F1501D66@ericsson.com> In-Reply-To: <73C7F487-34D7-49E0-81FC-F3B4F1501D66@ericsson.com> Content-Type: multipart/alternative; boundary="------------050304090905050603070804" Cc: CCAMP Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt X-BeenThere: ccamp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Discussion list for the CCAMP working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Sep 2011 20:06:32 -0000 This is a multi-part message in MIME format. --------------050304090905050603070804 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, On 9/13/11 11:04 PM, Acee Lindem wrote: > Hi Fatai, > I only have two comments on this document: > > 1. Reference RFC 5250 rather than RFC 2370 as the former obsoleted the latter. > 2. Possibly this draft should remove the RFC 5786 restriction that only a single OSPF TE LSA containing a top-level TLV is allowed. > Couldn't the connectivity matrix become quite large? as far as I've see there is a couple of examples here http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-05 within appendix A3 and A4. So asking authors, any other numbers around? My comment here is that those numbers refers essentially to 2 degree node. I would ask if draft can report some information (formula in the optimal case) that allow to figure out how the connectivity matrix scale. E.g. Thinking about a 16 degree node my guess reading the appendix A4: the last part of the TLV (from "note : line to line" on) we need to add one more 32 bits to identify the out-range, and we need to replicate this link-set tuple 15 times. So in total the "line to line" become 5*15*4 = 300 bytes Is my guess correct? Cheers G > Thanks, > Acee > > > On Sep 12, 2011, at 11:40 PM, Zhangfatai wrote: > >> Hi Acee, >> >> Sorry for a mistake, :-) >> >> I should say "when I update draft-ietf-ccamp-gmpls-general-constraints-ospf-te-00.txt" instead of "draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05.txt". >> >> >> >> >> >> >> Thanks >> >> Fatai >> >> >> -----Original Message----- >> From: Zhangfatai >> Sent: 2011?9?13? 11:38 >> To: 'Acee Lindem'; Greg Bernstein; Leeyoung >> Cc: CCAMP >> Subject: RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt >> >> Hi Acee, >> >> I personally agree with your comments on "multi-instance LSA". >> >> I will take your suggestions into account when I update "draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05.txt". >> >> >> >> >> Thanks >> >> Fatai >> >> >> -----Original Message----- >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Acee Lindem >> Sent: 2011?9?13? 6:58 >> To: Greg Bernstein; Leeyoung >> Cc: CCAMP >> Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt >> >> Hi Young, Greg, >> I have the following comments: >> >> 1. Specify that the Optical Node Property TLV cardinality and order rules per LSA. >> For example (from RFC 3630): >> >> "The Link TLV describes a single link. It is constructed of a set of >> sub-TLVs. There are no ordering requirements for the sub-TLVs. >> >> Only one Link TLV shall be carried in each LSA, allowing for fine >> granularity changes in topology." >> >> However, use the term "advertised" rather than "carried". After all, these are >> Link State Advertisements. >> >> 2. The same comment for all the Sub-TLVs. Here is another example from >> RFC 3630: >> >> "The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear >> exactly once. All other sub-TLVs defined here may occur at most >> once. These restrictions need not apply to future sub-TLVs. >> Unrecognized sub-TLVs are ignored." >> >> The new Sub-TLVs you are defining need this level of specification. >> >> 3. I know I told you not to use the term "multi-instance LSA". I still don't like >> the usage of "LSA instance" in the draft. In the base OSPF specification, RFC 2328, >> the term LSA instance is used to denote a particular version of the same LSA - NOT >> an opaque identifier for multiple LSAs of the same type. Refer to section 12.1 in >> RFC 2328. >> >> The OSPF Opaque LSA RFC (RFC 2370 and its successor RFC 5250) correctly >> identify the last 24 bits of the LSA ID as the Opaque ID. While RFC 3630 refers >> to this field as the "Instance", I believe this term should be avoided given the >> semantics in the OSPF base specification. Hence, I'd suggest the >> following changes: >> >> 225,226c225,226 >> < the rest and make use of multiple TE LSA instances per source, per >> < [RFC3630] multiple instance capability. >> --- >>> the rest and be advertised with multiple TE LSAs per OSPF router, as >>> described in [RFC3630] and [RFC5250]. >> 342,344c342,344 >> < the dynamic information sub-TLVs into separate LSAs within an Optical >> < Node Property TLV using multiple TE LSA instances per source, per the >> < reference [RFC3630] multiple instance capability. >> --- >>> the dynamic information sub-TLVs from the static information sub-TLVs >>> and advertise them in OSPF TE LSAs, each with the Optical Node >>> Property TLV at the top level ([RFC3630 and RFC5250]). >> 392c392 >> < into smaller sub-TLVs that can be sent in separate LSA instances. >> --- >>> into smaller sub-TLVs that can be sent in separate OSPF TE LSAs. >> 399c399 >> < sub-TLVs that can be sent in multiple LSA instances. The >> --- >>> sub-TLVs that can be sent in multiple OSPF TE LSAs. The >> 473c473 >> < into multiple LSA instances each containing a disjoint assembly of >> --- >>> into multiple OSPF TE LSAs each containing a disjoint assembly of >> Additionally, I'd add RFC 5250 as at least a informative reference. >> >> >> >> 4. Finally, I'd suggest changing the title from "OSPF Enhancement..." to >> "GMPLS OSPF Enhancement..." since you are not really enhancing base >> OSPF itself. Of course, there are other CCAMP RFCs that do not make >> this distinction. >> >> >> Thanks, >> Acee >> >> >> >> On Sep 9, 2011, at 3:51 PM, Leeyoung wrote: >> >>> Hi, >>> >>> This update added a new section to discuss OSPF scalability and how to use multiple TE LSA instance technique to keep the LSA under the MTU limit. Please note that the MTU limit is 1500 bytes and the examples given in the encoding draft is far below this limit. In case the LSA size goes above the MTU, this draft discusses how to split the Sub-TLVs' defined under the Optical Node Property TLV under the MTU limit to avoid fragmentation. >>> >>> Take a look at Section 3 and if you have questions, please feel free to discuss in the mailing list. >>> >>> Regards, >>> Young >>> >>> >>> >>> -----Original Message----- >>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf >>> Of internet-drafts@ietf.org >>> Sent: Thursday, September 08, 2011 5:16 PM >>> To: i-d-announce@ietf.org >>> Cc: ccamp@ietf.org >>> Subject: [CCAMP] I-D Action: >>> draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. >>> >>> Title : OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks >>> Author(s) : Young Lee >>> Greg M. Bernstein >>> Filename : draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt >>> Pages : 14 >>> Date : 2011-09-08 >>> >>> This document provides GMPLS OSPF routing enhancements to support >>> signal compatibility constraints associated with WSON network >>> elements. These routing enhancements are required in common optical >>> or hybrid electro-optical networks where not all of the optical >>> signals in the network are compatible with all network elements >>> participating in the network. >>> >>> This compatibility constraint model is applicable to common optical >>> or hybrid electro optical systems such as OEO switches, regenerators, >>> and wavelength converters since such systems can be limited to >>> processing only certain types of WSON signals. >>> >>> >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compa >>> tibility-ospf-05.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> This Internet-Draft can be retrieved at: >>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compat >>> ibility-ospf-05.txt _______________________________________________ >>> 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 --------------050304090905050603070804 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi,

On 9/13/11 11:04 PM, Acee Lindem wrote: 
Hi Fatai,
I only have two comments on this document:

  1. Reference RFC 5250 rather than RFC 2370 as the former obsoleted the latter. 
  2. Possibly this draft should remove the RFC 5786 restriction that only a single OSPF TE LSA containing a top-level TLV is allowed. 
      Couldn't the connectivity matrix become quite large?
as far as I've see there is a couple of  examples here http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-05 within appendix A3 and A4.  So asking authors, any other numbers around?

My comment here is that those numbers refers essentially to 2 degree node. I would ask if draft can report some information (formula in the optimal case) that allow to figure out how the connectivity matrix scale.

E.g. Thinking about a 16 degree node my guess reading the appendix A4: the last part of the TLV (from "note : line to line" on) we need to add one more 32 bits to identify the out-range, and we need to replicate this link-set tuple 15 times.  So in total the "line to line" become 5*15*4 = 300 bytes

Is my guess correct?

Cheers
G




Thanks,
Acee


On Sep 12, 2011, at 11:40 PM, Zhangfatai wrote:


Hi Acee,

Sorry for a mistake, :-)

I should say "when I update draft-ietf-ccamp-gmpls-general-constraints-ospf-te-00.txt" instead of "draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05.txt".






Thanks
 
Fatai


-----Original Message-----
From: Zhangfatai 
Sent: 2011年9月13日 11:38
To: 'Acee Lindem'; Greg Bernstein; Leeyoung
Cc: CCAMP
Subject: RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt

Hi Acee,

I personally agree with your comments on "multi-instance LSA".

I will take your suggestions into account when I update "draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05.txt".




Thanks
 
Fatai


-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Acee Lindem
Sent: 2011年9月13日 6:58
To: Greg Bernstein; Leeyoung
Cc: CCAMP
Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt

Hi Young, Greg,
I have the following comments:

  1. Specify that the Optical Node Property TLV cardinality and order rules per LSA. 
      For example (from RFC 3630): 

    "The Link TLV describes a single link.  It is constructed of a set of
      sub-TLVs.  There are no ordering requirements for the sub-TLVs.

     Only one Link TLV shall be carried in each LSA, allowing for fine  
     granularity changes in topology."

     However, use the term "advertised" rather than "carried". After all, these are
     Link State Advertisements. 

  2. The same comment for all the Sub-TLVs. Here is another example from 
       RFC 3630:

     "The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear
      exactly once.  All other sub-TLVs defined here may occur at most
      once.  These restrictions need not apply to future sub-TLVs.
      Unrecognized sub-TLVs are ignored."

      The new Sub-TLVs you are defining need this level of specification. 

  3. I know I told you not to use the term "multi-instance LSA". I still don't like
      the usage of "LSA instance" in the draft. In the base OSPF specification, RFC 2328, 
      the term LSA instance is used to denote a particular version of the same LSA - NOT
      an opaque identifier for multiple LSAs of the same type. Refer to section 12.1 in 
      RFC 2328. 

     The OSPF Opaque LSA RFC (RFC 2370 and its successor RFC 5250) correctly 
      identify the last 24 bits of the LSA ID as the Opaque ID. While RFC 3630 refers
      to this field as the "Instance", I believe this term should be avoided given the 
      semantics in the OSPF base specification. Hence, I'd suggest the 
      following changes:

225,226c225,226
<    the rest and make use of multiple TE LSA instances per source, per
<    [RFC3630] multiple instance capability.
---

  the rest and be advertised with multiple TE LSAs per OSPF router, as
  described in [RFC3630] and [RFC5250].

342,344c342,344
<    the dynamic information sub-TLVs into separate LSAs within an Optical
<    Node Property TLV using multiple TE LSA instances per source, per the
<    reference [RFC3630] multiple instance capability.
---

  the dynamic information sub-TLVs from the static information sub-TLVs
  and advertise them in OSPF TE LSAs, each with the Optical Node
  Property TLV at the top level ([RFC3630 and RFC5250]). 

392c392
<    into smaller sub-TLVs that can be sent in separate LSA instances.
---

  into smaller sub-TLVs that can be sent in separate OSPF TE LSAs.

399c399
<    sub-TLVs that can be sent in multiple LSA instances. The
---

  sub-TLVs that can be sent in multiple OSPF TE LSAs. The

473c473
<    into multiple LSA instances each containing a disjoint assembly of
---

  into multiple OSPF TE LSAs each containing a disjoint assembly of

    Additionally, I'd add RFC 5250 as at least a informative reference.



  4. Finally, I'd suggest changing the title from "OSPF Enhancement..." to 
      "GMPLS OSPF Enhancement..." since you are not really enhancing base 
      OSPF itself.  Of course, there are other CCAMP RFCs that do not make 
      this distinction. 


Thanks,
Acee 



On Sep 9, 2011, at 3:51 PM, Leeyoung wrote:


Hi,

This update added a new section to discuss OSPF scalability and how to use multiple TE LSA instance technique to keep the LSA under the MTU limit. Please note that the MTU limit is 1500 bytes and the examples given in the encoding draft is far below this limit. In case the LSA size goes above the MTU, this draft discusses how to split the Sub-TLVs' defined under the Optical Node Property TLV under the MTU limit to avoid fragmentation. 

Take a look at Section 3 and if you have questions, please feel free to discuss in the mailing list. 

Regards,
Young



-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf 
Of internet-drafts@ietf.org
Sent: Thursday, September 08, 2011 5:16 PM
To: i-d-announce@ietf.org
Cc: ccamp@ietf.org
Subject: [CCAMP] I-D Action: 
draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

	Title           : OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks
	Author(s)       : Young Lee
                        Greg M. Bernstein
	Filename        : draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt
	Pages           : 14
	Date            : 2011-09-08

 This document provides GMPLS OSPF routing enhancements to support
 signal compatibility constraints associated with WSON network
 elements. These routing enhancements are required in common optical
 or hybrid electro-optical networks where not all of the optical
 signals in the network are compatible with all network elements
 participating in the network.

 This compatibility constraint model is applicable to common optical
 or hybrid electro optical systems such as OEO switches, regenerators,
 and wavelength converters since such systems can be limited to
 processing only certain types of WSON signals.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compa
tibility-ospf-05.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compat
ibility-ospf-05.txt _______________________________________________
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


    

  


--------------050304090905050603070804--

From leeyoung@huawei.com  Mon Sep 19 13:27:58 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F33621F8C54 for ; Mon, 19 Sep 2011 13:27:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level: 
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[AWL=0.046,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkXi0WbhuvZB for ; Mon, 19 Sep 2011 13:27:56 -0700 (PDT)
Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 5781A21F8C44 for ; Mon, 19 Sep 2011 13:27:56 -0700 (PDT)
Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRS00EUSEAJ1X@usaga04-in.huawei.com> for ccamp@ietf.org; Mon, 19 Sep 2011 15:30:19 -0500 (CDT)
Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug  8 2006)) with ESMTP id <0LRS00HMKEADZU@usaga04-in.huawei.com> for ccamp@ietf.org; Mon, 19 Sep 2011 15:30:19 -0500 (CDT)
Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Mon, 19 Sep 2011 13:29:47 -0700
Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Mon, 19 Sep 2011 13:29:46 -0700
Date: Mon, 19 Sep 2011 20:29:45 +0000
From: Leeyoung 
In-reply-to: <4E77A151.6000200@cisco.com>
X-Originating-IP: [10.47.157.24]
To: Giovanni Martinelli , Acee Lindem 
Message-id: <7AEB3D6833318045B4AE71C2C87E8E1718175AE4@DFWEML501-MBX.china.huawei.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_azOx0D1hGzvgQQvz/1fQPw)"
Content-language: en-US
Accept-Language: en-US
Thread-topic: [CCAMP]	FW:	I-D	Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt
Thread-index: AQHMdwgCT7ou37ss6EGFHGVmEyg/W5VVI3DQ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: <7AEB3D6833318045B4AE71C2C87E8E1718166966@DFWEML501-MBX.china.huawei.com> <63CEF1D1-D774-40C9-90BB-04BD5E85BF1B@ericsson.com>  <73C7F487-34D7-49E0-81FC-F3B4F1501D66@ericsson.com> <4E77A151.6000200@cisco.com>
Cc: CCAMP 
Subject: Re: [CCAMP] FW:	I-D	Action:	draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Sep 2011 20:27:58 -0000

--Boundary_(ID_azOx0D1hGzvgQQvz/1fQPw)
Content-type: text/plain; charset=iso-2022-jp
Content-transfer-encoding: 7BIT

Hi Giovanni,

Your worst case analysis for 16 degree node connectivity matrix is subject to verification, but even if this is a right number, 300 bytes is well under 1500 byte MTU limit, so we can package it without sub-dividing the TLV.

We can easily partition the connectivity matrix even if it goes beyond the MTU limit. The last email to the CCAMP was concerning how to do it.

-          We can lift off RFC 5786 restriction to be able to send multiple TLVs under the current Node Attribute TLV.

-          Define a new top level TLV to do that.

I don$B!G(Bt think the scale of the connectivity matrix is a big issue.

Regards,
Young


From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Giovanni Martinelli
Sent: Monday, September 19, 2011 3:09 PM
To: Acee Lindem
Cc: CCAMP
Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt

Hi,

On 9/13/11 11:04 PM, Acee Lindem wrote:

Hi Fatai,

I only have two comments on this document:



  1. Reference RFC 5250 rather than RFC 2370 as the former obsoleted the latter.

  2. Possibly this draft should remove the RFC 5786 restriction that only a single OSPF TE LSA containing a top-level TLV is allowed.

      Couldn't the connectivity matrix become quite large?
as far as I've see there is a couple of  examples here http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-05 within appendix A3 and A4.  So asking authors, any other numbers around?

My comment here is that those numbers refers essentially to 2 degree node. I would ask if draft can report some information (formula in the optimal case) that allow to figure out how the connectivity matrix scale.

E.g. Thinking about a 16 degree node my guess reading the appendix A4: the last part of the TLV (from "note : line to line" on) we need to add one more 32 bits to identify the out-range, and we need to replicate this link-set tuple 15 times.  So in total the "line to line" become 5*15*4 = 300 bytes

Is my guess correct?

Cheers
G








Thanks,

Acee





On Sep 12, 2011, at 11:40 PM, Zhangfatai wrote:



Hi Acee,



Sorry for a mistake, :-)



I should say "when I update draft-ietf-ccamp-gmpls-general-constraints-ospf-te-00.txt" instead of "draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05.txt".













Thanks



Fatai





-----Original Message-----

From: Zhangfatai

Sent: 2011$BG/(B9$B7n(B13$BF|(B 11:38

To: 'Acee Lindem'; Greg Bernstein; Leeyoung

Cc: CCAMP

Subject: RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt



Hi Acee,



I personally agree with your comments on "multi-instance LSA".



I will take your suggestions into account when I update "draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05.txt".









Thanks



Fatai





-----Original Message-----

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Acee Lindem

Sent: 2011$BG/(B9$B7n(B13$BF|(B 6:58

To: Greg Bernstein; Leeyoung

Cc: CCAMP

Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt



Hi Young, Greg,

I have the following comments:



  1. Specify that the Optical Node Property TLV cardinality and order rules per LSA.

      For example (from RFC 3630):



    "The Link TLV describes a single link.  It is constructed of a set of

      sub-TLVs.  There are no ordering requirements for the sub-TLVs.



     Only one Link TLV shall be carried in each LSA, allowing for fine

     granularity changes in topology."



     However, use the term "advertised" rather than "carried". After all, these are

     Link State Advertisements.



  2. The same comment for all the Sub-TLVs. Here is another example from

       RFC 3630:



     "The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear

      exactly once.  All other sub-TLVs defined here may occur at most

      once.  These restrictions need not apply to future sub-TLVs.

      Unrecognized sub-TLVs are ignored."



      The new Sub-TLVs you are defining need this level of specification.



  3. I know I told you not to use the term "multi-instance LSA". I still don't like

      the usage of "LSA instance" in the draft. In the base OSPF specification, RFC 2328,

      the term LSA instance is used to denote a particular version of the same LSA - NOT

      an opaque identifier for multiple LSAs of the same type. Refer to section 12.1 in

      RFC 2328.



     The OSPF Opaque LSA RFC (RFC 2370 and its successor RFC 5250) correctly

      identify the last 24 bits of the LSA ID as the Opaque ID. While RFC 3630 refers

      to this field as the "Instance", I believe this term should be avoided given the

      semantics in the OSPF base specification. Hence, I'd suggest the

      following changes:



225,226c225,226

<    the rest and make use of multiple TE LSA instances per source, per

<    [RFC3630] multiple instance capability.

---

  the rest and be advertised with multiple TE LSAs per OSPF router, as

  described in [RFC3630] and [RFC5250].

342,344c342,344

<    the dynamic information sub-TLVs into separate LSAs within an Optical

<    Node Property TLV using multiple TE LSA instances per source, per the

<    reference [RFC3630] multiple instance capability.

---

  the dynamic information sub-TLVs from the static information sub-TLVs

  and advertise them in OSPF TE LSAs, each with the Optical Node

  Property TLV at the top level ([RFC3630 and RFC5250]).

392c392

<    into smaller sub-TLVs that can be sent in separate LSA instances.

---

  into smaller sub-TLVs that can be sent in separate OSPF TE LSAs.

399c399

<    sub-TLVs that can be sent in multiple LSA instances. The

---

  sub-TLVs that can be sent in multiple OSPF TE LSAs. The

473c473

<    into multiple LSA instances each containing a disjoint assembly of

---

  into multiple OSPF TE LSAs each containing a disjoint assembly of



    Additionally, I'd add RFC 5250 as at least a informative reference.







  4. Finally, I'd suggest changing the title from "OSPF Enhancement..." to

      "GMPLS OSPF Enhancement..." since you are not really enhancing base

      OSPF itself.  Of course, there are other CCAMP RFCs that do not make

      this distinction.





Thanks,

Acee







On Sep 9, 2011, at 3:51 PM, Leeyoung wrote:



Hi,



This update added a new section to discuss OSPF scalability and how to use multiple TE LSA instance technique to keep the LSA under the MTU limit. Please note that the MTU limit is 1500 bytes and the examples given in the encoding draft is far below this limit. In case the LSA size goes above the MTU, this draft discusses how to split the Sub-TLVs' defined under the Optical Node Property TLV under the MTU limit to avoid fragmentation.



Take a look at Section 3 and if you have questions, please feel free to discuss in the mailing list.



Regards,

Young







-----Original Message-----

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf

Of internet-drafts@ietf.org

Sent: Thursday, September 08, 2011 5:16 PM

To: i-d-announce@ietf.org

Cc: ccamp@ietf.org

Subject: [CCAMP] I-D Action:

draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt



A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.



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

   Author(s)       : Young Lee

                        Greg M. Bernstein

   Filename        : draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt

   Pages           : 14

   Date            : 2011-09-08



 This document provides GMPLS OSPF routing enhancements to support

 signal compatibility constraints associated with WSON network

 elements. These routing enhancements are required in common optical

 or hybrid electro-optical networks where not all of the optical

 signals in the network are compatible with all network elements

 participating in the network.



 This compatibility constraint model is applicable to common optical

 or hybrid electro optical systems such as OEO switches, regenerators,

 and wavelength converters since such systems can be limited to

 processing only certain types of WSON signals.







A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compa

tibility-ospf-05.txt



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/



This Internet-Draft can be retrieved at:

ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compat

ibility-ospf-05.txt _______________________________________________

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

--Boundary_(ID_azOx0D1hGzvgQQvz/1fQPw)
Content-type: text/html; charset=iso-2022-jp
Content-transfer-encoding: 7BIT











Hi Giovanni,


 


Your worst case analysis for 16 degree node connectivity matrix is subject to verification, but even if this is a right number, 300 bytes is well under 1500
 byte MTU limit, so we can package it without sub-dividing the TLV.  


 


We can easily partition the connectivity matrix even if it goes beyond the MTU limit. The last email to the CCAMP was concerning how to do it.


-         
We can lift off RFC 5786 restriction to be able to send multiple TLVs under the current Node Attribute TLV.



-         
Define a new top level TLV to do that.



 


I don$B!G(Bt think the scale of the connectivity matrix is a big issue.



 


Regards,


Young


 


 






From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]
On Behalf Of Giovanni Martinelli

Sent: Monday, September 19, 2011 3:09 PM

To: Acee Lindem

Cc: CCAMP

Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt






 


Hi,



On 9/13/11 11:04 PM, Acee Lindem wrote: 


Hi Fatai,


I only have two comments on this document:


 


  1. Reference RFC 5250 rather than RFC 2370 as the former obsoleted the latter. 


  2. Possibly this draft should remove the RFC 5786 restriction that only a single OSPF TE LSA containing a top-level TLV is allowed. 


      Couldn't the connectivity matrix become quite large? 


as far as I've see there is a couple of  examples here 
http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-05 within appendix A3 and A4.  So asking authors, any other numbers around?



My comment here is that those numbers refers essentially to 2 degree node. I would ask if draft can report some information (formula in the optimal case) that allow to figure out how the connectivity matrix scale.



E.g. Thinking about a 16 degree node my guess reading the appendix A4: the last part of the TLV (from "note : line to line" on) we need to add one more 32 bits to identify the out-range, and we need to replicate this link-set tuple 15 times.  So in total the
 "line to line" become 5*15*4 = 300 bytes



Is my guess correct?



Cheers

G














 


Thanks,


Acee


 


 


On Sep 12, 2011, at 11:40 PM, Zhangfatai wrote:


 




Hi Acee,


 


Sorry for a mistake, :-)


 


I should say "when I update draft-ietf-ccamp-gmpls-general-constraints-ospf-te-00.txt" instead of "draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05.txt".


 


 


 


 


 


 


Thanks


 


Fatai


 


 


-----Original Message-----


From: Zhangfatai 


Sent: 2011$BG/(B9$B7n(B13$BF|(B 11:38


To: 'Acee Lindem'; Greg Bernstein; Leeyoung


Cc: CCAMP


Subject: RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt


 


Hi Acee,


 


I personally agree with your comments on "multi-instance LSA".


 


I will take your suggestions into account when I update "draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05.txt".


 


 


 


 


Thanks


 


Fatai


 


 


-----Original Message-----


From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Acee Lindem


Sent: 2011$BG/(B9$B7n(B13$BF|(B 6:58


To: Greg Bernstein; Leeyoung


Cc: CCAMP


Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt


 


Hi Young, Greg,


I have the following comments:


 


  1. Specify that the Optical Node Property TLV cardinality and order rules per LSA. 


      For example (from RFC 3630): 


 


    "The Link TLV describes a single link.  It is constructed of a set of


      sub-TLVs.  There are no ordering requirements for the sub-TLVs.


 


     Only one Link TLV shall be carried in each LSA, allowing for fine  


     granularity changes in topology."


 


     However, use the term "advertised" rather than "carried". After all, these are


     Link State Advertisements. 


 


  2. The same comment for all the Sub-TLVs. Here is another example from 


       RFC 3630:


 


     "The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear


      exactly once.  All other sub-TLVs defined here may occur at most


      once.  These restrictions need not apply to future sub-TLVs.


      Unrecognized sub-TLVs are ignored."


 


      The new Sub-TLVs you are defining need this level of specification. 


 


  3. I know I told you not to use the term "multi-instance LSA". I still don't like


      the usage of "LSA instance" in the draft. In the base OSPF specification, RFC 2328, 


      the term LSA instance is used to denote a particular version of the same LSA - NOT


      an opaque identifier for multiple LSAs of the same type. Refer to section 12.1 in 


      RFC 2328. 


 


     The OSPF Opaque LSA RFC (RFC 2370 and its successor RFC 5250) correctly 


      identify the last 24 bits of the LSA ID as the Opaque ID. While RFC 3630 refers


      to this field as the "Instance", I believe this term should be avoided given the 


      semantics in the OSPF base specification. Hence, I'd suggest the 


      following changes:


 


225,226c225,226


<    the rest and make use of multiple TE LSA instances per source, per


<    [RFC3630] multiple instance capability.


---




  the rest and be advertised with multiple TE LSAs per OSPF router, as


  described in [RFC3630] and [RFC5250].




342,344c342,344


<    the dynamic information sub-TLVs into separate LSAs within an Optical


<    Node Property TLV using multiple TE LSA instances per source, per the


<    reference [RFC3630] multiple instance capability.


---




  the dynamic information sub-TLVs from the static information sub-TLVs


  and advertise them in OSPF TE LSAs, each with the Optical Node


  Property TLV at the top level ([RFC3630 and RFC5250]). 




392c392


<    into smaller sub-TLVs that can be sent in separate LSA instances.


---




  into smaller sub-TLVs that can be sent in separate OSPF TE LSAs.




399c399


<    sub-TLVs that can be sent in multiple LSA instances. The


---




  sub-TLVs that can be sent in multiple OSPF TE LSAs. The




473c473


<    into multiple LSA instances each containing a disjoint assembly of


---




  into multiple OSPF TE LSAs each containing a disjoint assembly of




 


    Additionally, I'd add RFC 5250 as at least a informative reference.


 


 


 


  4. Finally, I'd suggest changing the title from "OSPF Enhancement..." to 


      "GMPLS OSPF Enhancement..." since you are not really enhancing base 


      OSPF itself.  Of course, there are other CCAMP RFCs that do not make 


      this distinction. 


 


 


Thanks,


Acee 


 


 


 


On Sep 9, 2011, at 3:51 PM, Leeyoung wrote:


 




Hi,


 


This update added a new section to discuss OSPF scalability and how to use multiple TE LSA instance technique to keep the LSA under the MTU limit. Please note that the MTU limit is 1500 bytes and the examples given in the encoding draft is far below this limit. In case the LSA size goes above the MTU, this draft discusses how to split the Sub-TLVs' defined under the Optical Node Property TLV under the MTU limit to avoid fragmentation. 


 


Take a look at Section 3 and if you have questions, please feel free to discuss in the mailing list. 


 


Regards,


Young


 


 


 


-----Original Message-----


From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf 


Of internet-drafts@ietf.org


Sent: Thursday, September 08, 2011 5:16 PM


To: i-d-announce@ietf.org


Cc: ccamp@ietf.org


Subject: [CCAMP] I-D Action: 


draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt


 


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.


 


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


   Author(s)       : Young Lee


                        Greg M. Bernstein


   Filename        : draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt


   Pages           : 14


   Date            : 2011-09-08


 


 This document provides GMPLS OSPF routing enhancements to support


 signal compatibility constraints associated with WSON network


 elements. These routing enhancements are required in common optical


 or hybrid electro-optical networks where not all of the optical


 signals in the network are compatible with all network elements


 participating in the network.


 


 This compatibility constraint model is applicable to common optical


 or hybrid electro optical systems such as OEO switches, regenerators,


 and wavelength converters since such systems can be limited to


 processing only certain types of WSON signals.


 


 


 


A URL for this Internet-Draft is:


http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compa


tibility-ospf-05.txt


 


Internet-Drafts are also available by anonymous FTP at:


ftp://ftp.ietf.org/internet-drafts/


 


This Internet-Draft can be retrieved at:


ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compat


ibility-ospf-05.txt _______________________________________________


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






--Boundary_(ID_azOx0D1hGzvgQQvz/1fQPw)--

From giomarti@cisco.com  Tue Sep 20 00:33:46 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D753821F85A4 for ; Tue, 20 Sep 2011 00:33:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Level: 
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GW+p8MyzsOyM for ; Tue, 20 Sep 2011 00:33:45 -0700 (PDT)
Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9500921F84CF for ; Tue, 20 Sep 2011 00:33:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=giomarti@cisco.com; l=42688; q=dns/txt; s=iport; t=1316504169; x=1317713769; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=8xZJOpDCDVraHtzu1LmtNdkspqnyL2w2+O/pzfBnHB0=; b=WvdKMwQ6h/haYceu3h62UyPUpV8Gfe+Wtd+KhNoc6OzKkc4nqzSeA9Fe v3kIZEfHjL/QWFT/dS/ML8f+lmXlIZaAfCLZAmjZJHAnPpq0CVG4H5myg w4EdCdURxppq7OEpyskv2ZX4VkuI7xKLIRcccgvSNrtPM9bWCCyPFwXd5 U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApcAAIpBeE6Q/khN/2dsb2JhbAA4CoJNggqUAo5pd4FTAQEBAQIBAQEBDwEOAQs6BwoBBQcECxEEAQEBCQYGCgEBBgIDAgkDAgECARUfCAEIBg0BBQIBAQUSB4dVBJYjAYw1AZIIg1ITggCBFASTS5Ew
X-IronPort-AV: E=Sophos;i="4.68,410,1312156800";  d="scan'208,217";a="116192352"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 20 Sep 2011 07:36:07 +0000
Received: from mnza1-dhcp-vl250-144-254-172-188.cisco.com (mnza1-dhcp-vl250-144-254-172-188.cisco.com [144.254.172.188]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p8K7a7lO011860; Tue, 20 Sep 2011 07:36:07 GMT
Message-ID: <4E784267.1030609@cisco.com>
Date: Tue, 20 Sep 2011 09:36:07 +0200
From: Giovanni Martinelli 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Leeyoung 
References: <7AEB3D6833318045B4AE71C2C87E8E1718166966@DFWEML501-MBX.china.huawei.com> <63CEF1D1-D774-40C9-90BB-04BD5E85BF1B@ericsson.com>  <73C7F487-34D7-49E0-81FC-F3B4F1501D66@ericsson.com> <4E77A151.6000200@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E1718175AE4@DFWEML501-MBX.china.huawei.com>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E1718175AE4@DFWEML501-MBX.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------010408090909010801080506"
Cc: CCAMP 
Subject: Re: [CCAMP] FW:	I-D	Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Sep 2011 07:33:46 -0000

This is a multi-part message in MIME format.
--------------010408090909010801080506
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit

Hi,

On 9/19/11 10:29 PM, Leeyoung wrote:
>
> Hi Giovanni,
>
> Your worst case analysis for 16 degree node connectivity matrix is
> subject to verification,
>
> but even if this is a right number, 300 bytes is well under 1500 byte
> MTU limit, so we can package it without sub-dividing the TLV.
>
yes , I was not concerned about mtu but how to build a correct
connectivity matrix beyond a simple 2 degree node. If you provide few
more numbers there's probably a better feeling of "how many" bytes are
(well beyond the mtu but well above the 75 bytes in the example).

> We can easily partition the connectivity matrix even if it goes beyond
> the MTU limit.
>
Agree that's a good solution but my comment here is related to how do we
partition. Would it worth to add some text about it? We could probably
guess (e.g. linkset couple) but just to make sure all readers will have
same interpretation.

> The last email to the CCAMP was concerning how to do it.
>
> -We can lift off RFC 5786 restriction to be able to send multiple TLVs
> under the current Node Attribute TLV.
>
> -Define a new top level TLV to do that.
>
I know and I was not replaying on last email but trying to providing
numbers for the connectivity matrix.

> I don$B!G(Bt think the scale of the connectivity matrix is a big issue.
>
Since it has to be "generic" we don't know in principle. Does not look a
problem for *unconstrained* wson nodes. Don't know if others has
different options for wson technology or may be possible other
technologies (otn?).

Cheers
G
>
> Regards,
>
> Young
>
> *From:*ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] *On
> Behalf Of *Giovanni Martinelli
> *Sent:* Monday, September 19, 2011 3:09 PM
> *To:* Acee Lindem
> *Cc:* CCAMP
> *Subject:* Re: [CCAMP] FW: I-D Action:
> draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt
>
> Hi,
>
> On 9/13/11 11:04 PM, Acee Lindem wrote:
>
> Hi Fatai,
> I only have two comments on this document:
>  
>   1. Reference RFC 5250 rather than RFC 2370 as the former obsoleted the latter. 
>   2. Possibly this draft should remove the RFC 5786 restriction that only a single OSPF TE LSA containing a top-level TLV is allowed. 
>       Couldn't the connectivity matrix become quite large? 
>
> as far as I've see there is a couple of examples here
> http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-05
> within appendix A3 and A4. So asking authors, any other numbers around?
>
> My comment here is that those numbers refers essentially to 2 degree
> node. I would ask if draft can report some information (formula in the
> optimal case) that allow to figure out how the connectivity matrix scale.
>
> E.g. Thinking about a 16 degree node my guess reading the appendix A4:
> the last part of the TLV (from "note : line to line" on) we need to
> add one more 32 bits to identify the out-range, and we need to
> replicate this link-set tuple 15 times. So in total the "line to line"
> become 5*15*4 = 300 bytes
>
> Is my guess correct?
>
> Cheers
> G
>
>
>
>
>
>  
> Thanks,
> Acee
>  
>  
> On Sep 12, 2011, at 11:40 PM, Zhangfatai wrote:
>  
>
>     Hi Acee,
>
>      
>
>     Sorry for a mistake, :-)
>
>      
>
>     I should say "when I update draft-ietf-ccamp-gmpls-general-constraints-ospf-te-00.txt" instead of "draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05.txt".
>
>      
>
>      
>
>      
>
>      
>
>      
>
>      
>
>     Thanks
>
>      
>
>     Fatai
>
>      
>
>      
>
>     -----Original Message-----
>
>     From: Zhangfatai 
>
>     Sent: 2011$BG/(B9$B7n(B13$BF|(B 11:38
>
>     To: 'Acee Lindem'; Greg Bernstein; Leeyoung
>
>     Cc: CCAMP
>
>     Subject: RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt
>
>      
>
>     Hi Acee,
>
>      
>
>     I personally agree with your comments on "multi-instance LSA".
>
>      
>
>     I will take your suggestions into account when I update "draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05.txt".
>
>      
>
>      
>
>      
>
>      
>
>     Thanks
>
>      
>
>     Fatai
>
>      
>
>      
>
>     -----Original Message-----
>
>     From: ccamp-bounces@ietf.org  [mailto:ccamp-bounces@ietf.org] On Behalf Of Acee Lindem
>
>     Sent: 2011$BG/(B9$B7n(B13$BF|(B 6:58
>
>     To: Greg Bernstein; Leeyoung
>
>     Cc: CCAMP
>
>     Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt
>
>      
>
>     Hi Young, Greg,
>
>     I have the following comments:
>
>      
>
>       1. Specify that the Optical Node Property TLV cardinality and order rules per LSA. 
>
>           For example (from RFC 3630): 
>
>      
>
>         "The Link TLV describes a single link.  It is constructed of a set of
>
>           sub-TLVs.  There are no ordering requirements for the sub-TLVs.
>
>      
>
>          Only one Link TLV shall be carried in each LSA, allowing for fine  
>
>          granularity changes in topology."
>
>      
>
>          However, use the term "advertised" rather than "carried". After all, these are
>
>          Link State Advertisements. 
>
>      
>
>       2. The same comment for all the Sub-TLVs. Here is another example from 
>
>            RFC 3630:
>
>      
>
>          "The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear
>
>           exactly once.  All other sub-TLVs defined here may occur at most
>
>           once.  These restrictions need not apply to future sub-TLVs.
>
>           Unrecognized sub-TLVs are ignored."
>
>      
>
>           The new Sub-TLVs you are defining need this level of specification. 
>
>      
>
>       3. I know I told you not to use the term "multi-instance LSA". I still don't like
>
>           the usage of "LSA instance" in the draft. In the base OSPF specification, RFC 2328, 
>
>           the term LSA instance is used to denote a particular version of the same LSA - NOT
>
>           an opaque identifier for multiple LSAs of the same type. Refer to section 12.1 in 
>
>           RFC 2328. 
>
>      
>
>          The OSPF Opaque LSA RFC (RFC 2370 and its successor RFC 5250) correctly 
>
>           identify the last 24 bits of the LSA ID as the Opaque ID. While RFC 3630 refers
>
>           to this field as the "Instance", I believe this term should be avoided given the 
>
>           semantics in the OSPF base specification. Hence, I'd suggest the 
>
>           following changes:
>
>      
>
>     225,226c225,226
>
>     <    the rest and make use of multiple TE LSA instances per source, per
>
>     <    [RFC3630] multiple instance capability.
>
>     ---
>
>           the rest and be advertised with multiple TE LSAs per OSPF router, as
>
>           described in [RFC3630] and [RFC5250].
>
>     342,344c342,344
>
>     <    the dynamic information sub-TLVs into separate LSAs within an Optical
>
>     <    Node Property TLV using multiple TE LSA instances per source, per the
>
>     <    reference [RFC3630] multiple instance capability.
>
>     ---
>
>           the dynamic information sub-TLVs from the static information sub-TLVs
>
>           and advertise them in OSPF TE LSAs, each with the Optical Node
>
>           Property TLV at the top level ([RFC3630 and RFC5250]). 
>
>     392c392
>
>     <    into smaller sub-TLVs that can be sent in separate LSA instances.
>
>     ---
>
>           into smaller sub-TLVs that can be sent in separate OSPF TE LSAs.
>
>     399c399
>
>     <    sub-TLVs that can be sent in multiple LSA instances. The
>
>     ---
>
>           sub-TLVs that can be sent in multiple OSPF TE LSAs. The
>
>     473c473
>
>     <    into multiple LSA instances each containing a disjoint assembly of
>
>     ---
>
>           into multiple OSPF TE LSAs each containing a disjoint assembly of
>
>      
>
>         Additionally, I'd add RFC 5250 as at least a informative reference.
>
>      
>
>      
>
>      
>
>       4. Finally, I'd suggest changing the title from "OSPF Enhancement..." to 
>
>           "GMPLS OSPF Enhancement..." since you are not really enhancing base 
>
>           OSPF itself.  Of course, there are other CCAMP RFCs that do not make 
>
>           this distinction. 
>
>      
>
>      
>
>     Thanks,
>
>     Acee 
>
>      
>
>      
>
>      
>
>     On Sep 9, 2011, at 3:51 PM, Leeyoung wrote:
>
>      
>
>         Hi,
>
>          
>
>         This update added a new section to discuss OSPF scalability and how to use multiple TE LSA instance technique to keep the LSA under the MTU limit. Please note that the MTU limit is 1500 bytes and the examples given in the encoding draft is far below this limit. In case the LSA size goes above the MTU, this draft discusses how to split the Sub-TLVs' defined under the Optical Node Property TLV under the MTU limit to avoid fragmentation. 
>
>          
>
>         Take a look at Section 3 and if you have questions, please feel free to discuss in the mailing list. 
>
>          
>
>         Regards,
>
>         Young
>
>          
>
>          
>
>          
>
>         -----Original Message-----
>
>         From: ccamp-bounces@ietf.org  [mailto:ccamp-bounces@ietf.org] On Behalf 
>
>         Of internet-drafts@ietf.org 
>
>         Sent: Thursday, September 08, 2011 5:16 PM
>
>         To: i-d-announce@ietf.org 
>
>         Cc: ccamp@ietf.org 
>
>         Subject: [CCAMP] I-D Action: 
>
>         draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt
>
>          
>
>         A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.
>
>          
>
>            Title           : OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks
>
>            Author(s)       : Young Lee
>
>                                 Greg M. Bernstein
>
>            Filename        : draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt
>
>            Pages           : 14
>
>            Date            : 2011-09-08
>
>          
>
>          This document provides GMPLS OSPF routing enhancements to support
>
>          signal compatibility constraints associated with WSON network
>
>          elements. These routing enhancements are required in common optical
>
>          or hybrid electro-optical networks where not all of the optical
>
>          signals in the network are compatible with all network elements
>
>          participating in the network.
>
>          
>
>          This compatibility constraint model is applicable to common optical
>
>          or hybrid electro optical systems such as OEO switches, regenerators,
>
>          and wavelength converters since such systems can be limited to
>
>          processing only certain types of WSON signals.
>
>          
>
>          
>
>          
>
>         A URL for this Internet-Draft is:
>
>         http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compa
>
>         tibility-ospf-05.txt
>
>          
>
>         Internet-Drafts are also available by anonymous FTP at:
>
>         ftp://ftp.ietf.org/internet-drafts/
>
>          
>
>         This Internet-Draft can be retrieved at:
>
>         ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compat
>
>         ibility-ospf-05.txt _______________________________________________
>
>         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

--------------010408090909010801080506
Content-Type: text/html; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit


  
    
  
  
    Hi,

    

    On 9/19/11 10:29 PM, Leeyoung wrote:
    

      
      
      
      

        
Hi
            Giovanni,

        
 

        
Your worst case analysis for 16 degree node
            connectivity matrix is subject to verification,

      

    

    

      

        

            but even if this is a right number, 300 bytes is well under
            1500 byte MTU limit, so we can package it without
            sub-dividing the TLV.  

        
 

      

    

    yes , I was not concerned about mtu but how to build a correct
    connectivity matrix beyond a simple 2 degree node. If you provide
    few more numbers there's probably a better feeling of "how many"
    bytes are (well beyond the mtu but well above the 75 bytes in the
    example).

    

    

      

        
We can easily partition the connectivity matrix
            even if it goes beyond the MTU limit.

      

    

    Agree that's a good solution  but my comment here is related to how
    do we partition. Would it worth to add some text about it? We could
    probably guess (e.g. linkset couple) but just to make sure all
    readers will have same interpretation. 

    

    

      

        

            The last email to the CCAMP was concerning how to do it.

        
-         
              We
            can lift off RFC 5786 restriction to be able to send
            multiple TLVs under the current Node Attribute TLV.
            

        
-         
              Define
            a new top level TLV to do that.
            

        
 

      

    

    I know and I was not replaying on last email but trying to providing
    numbers for the connectivity matrix.  

    

    

      

        
I
            don$B!G(Bt think the scale of the connectivity matrix is a big
            issue.
            

        
 

      

    

    Since it has to be "generic" we don't know in principle. Does not
    look a problem for *unconstrained* wson nodes. Don't know if others
    has different options for wson technology or may be possible other
    technologies (otn?).

    

    Cheers

    G

    

      

        
Regards,

        
Young

        
 

        
 

        

          

            
From:
                ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]
                On Behalf Of Giovanni Martinelli

                Sent: Monday, September 19, 2011 3:09 PM

                To: Acee Lindem

                Cc: CCAMP

                Subject: Re: [CCAMP] FW: I-D Action:
                draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt

          

        

        
 

        
Hi,

          

          On 9/13/11 11:04 PM, Acee Lindem wrote: 

        
Hi Fatai,

        
I only have two comments on this document:

        
 

        
  1. Reference RFC 5250 rather than RFC 2370 as the former obsoleted the latter. 

        
  2. Possibly this draft should remove the RFC 5786 restriction that only a single OSPF TE LSA containing a top-level TLV is allowed. 

        
      Couldn't the connectivity matrix become quite large? 

        
as far as I've see there is a couple of 
          examples here http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-05
          within appendix A3 and A4.  So asking authors, any other
          numbers around?

          

          My comment here is that those numbers refers essentially to 2
          degree node. I would ask if draft can report some information
          (formula in the optimal case) that allow to figure out how the
          connectivity matrix scale.

          

          E.g. Thinking about a 16 degree node my guess reading the
          appendix A4: the last part of the TLV (from "note : line to
          line" on) we need to add one more 32 bits to identify the
          out-range, and we need to replicate this link-set tuple 15
          times.  So in total the "line to line" become 5*15*4 = 300
          bytes

          

          Is my guess correct?

          

          Cheers

          G

          

          

          

          

          

          

        
 

        
Thanks,

        
Acee

        
 

        
 

        
On Sep 12, 2011, at 11:40 PM, Zhangfatai wrote:

        
 

        

          
Hi Acee,

          
 

          
Sorry for a mistake, :-)

          
 

          
I should say "when I update draft-ietf-ccamp-gmpls-general-constraints-ospf-te-00.txt" instead of "draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05.txt".

          
 

          
 

          
 

          
 

          
 

          
 

          
Thanks

          
 

          
Fatai

          
 

          
 

          
-----Original Message-----

          
From: Zhangfatai 

          
Sent: 2011$BG/(B9$B7n(B13$BF|(B 11:38

          
To: 'Acee Lindem'; Greg Bernstein; Leeyoung

          
Cc: CCAMP

          
Subject: RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt

          
 

          
Hi Acee,

          
 

          
I personally agree with your comments on "multi-instance LSA".

          
 

          
I will take your suggestions into account when I update "draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05.txt".

          
 

          
 

          
 

          
 

          
Thanks

          
 

          
Fatai

          
 

          
 

          
-----Original Message-----

          
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Acee Lindem

          
Sent: 2011$BG/(B9$B7n(B13$BF|(B 6:58

          
To: Greg Bernstein; Leeyoung

          
Cc: CCAMP

          
Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt

          
 

          
Hi Young, Greg,

          
I have the following comments:

          
 

          
  1. Specify that the Optical Node Property TLV cardinality and order rules per LSA. 

          
      For example (from RFC 3630): 

          
 

          
    "The Link TLV describes a single link.  It is constructed of a set of

          
      sub-TLVs.  There are no ordering requirements for the sub-TLVs.

          
 

          
     Only one Link TLV shall be carried in each LSA, allowing for fine  

          
     granularity changes in topology."

          
 

          
     However, use the term "advertised" rather than "carried". After all, these are

          
     Link State Advertisements. 

          
 

          
  2. The same comment for all the Sub-TLVs. Here is another example from 

          
       RFC 3630:

          
 

          
     "The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear

          
      exactly once.  All other sub-TLVs defined here may occur at most

          
      once.  These restrictions need not apply to future sub-TLVs.

          
      Unrecognized sub-TLVs are ignored."

          
 

          
      The new Sub-TLVs you are defining need this level of specification. 

          
 

          
  3. I know I told you not to use the term "multi-instance LSA". I still don't like

          
      the usage of "LSA instance" in the draft. In the base OSPF specification, RFC 2328, 

          
      the term LSA instance is used to denote a particular version of the same LSA - NOT

          
      an opaque identifier for multiple LSAs of the same type. Refer to section 12.1 in 

          
      RFC 2328. 

          
 

          
     The OSPF Opaque LSA RFC (RFC 2370 and its successor RFC 5250) correctly 

          
      identify the last 24 bits of the LSA ID as the Opaque ID. While RFC 3630 refers

          
      to this field as the "Instance", I believe this term should be avoided given the 

          
      semantics in the OSPF base specification. Hence, I'd suggest the 

          
      following changes:

          
 

          
225,226c225,226

          
<    the rest and make use of multiple TE LSA instances per source, per

          
<    [RFC3630] multiple instance capability.

          
---

          

            
  the rest and be advertised with multiple TE LSAs per OSPF router, as

            
  described in [RFC3630] and [RFC5250].

          

          
342,344c342,344

          
<    the dynamic information sub-TLVs into separate LSAs within an Optical

          
<    Node Property TLV using multiple TE LSA instances per source, per the

          
<    reference [RFC3630] multiple instance capability.

          
---

          

            
  the dynamic information sub-TLVs from the static information sub-TLVs

            
  and advertise them in OSPF TE LSAs, each with the Optical Node

            
  Property TLV at the top level ([RFC3630 and RFC5250]). 

          

          
392c392

          
<    into smaller sub-TLVs that can be sent in separate LSA instances.

          
---

          

            
  into smaller sub-TLVs that can be sent in separate OSPF TE LSAs.

          

          
399c399

          
<    sub-TLVs that can be sent in multiple LSA instances. The

          
---

          

            
  sub-TLVs that can be sent in multiple OSPF TE LSAs. The

          

          
473c473

          
<    into multiple LSA instances each containing a disjoint assembly of

          
---

          

            
  into multiple OSPF TE LSAs each containing a disjoint assembly of

          

          
 

          
    Additionally, I'd add RFC 5250 as at least a informative reference.

          
 

          
 

          
 

          
  4. Finally, I'd suggest changing the title from "OSPF Enhancement..." to 

          
      "GMPLS OSPF Enhancement..." since you are not really enhancing base 

          
      OSPF itself.  Of course, there are other CCAMP RFCs that do not make 

          
      this distinction. 

          
 

          
 

          
Thanks,

          
Acee 

          
 

          
 

          
 

          
On Sep 9, 2011, at 3:51 PM, Leeyoung wrote:

          
 

          

            
Hi,

            
 

            
This update added a new section to discuss OSPF scalability and how to use multiple TE LSA instance technique to keep the LSA under the MTU limit. Please note that the MTU limit is 1500 bytes and the examples given in the encoding draft is far below this limit. In case the LSA size goes above the MTU, this draft discusses how to split the Sub-TLVs' defined under the Optical Node Property TLV under the MTU limit to avoid fragmentation. 

            
 

            
Take a look at Section 3 and if you have questions, please feel free to discuss in the mailing list. 

            
 

            
Regards,

            
Young

            
 

            
 

            
 

            
-----Original Message-----

            
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf 

            
Of internet-drafts@ietf.org

            
Sent: Thursday, September 08, 2011 5:16 PM

            
To: i-d-announce@ietf.org

            
Cc: ccamp@ietf.org

            
Subject: [CCAMP] I-D Action: 

            
draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt

            
 

            
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.

            
 

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

            
   Author(s)       : Young Lee

            
                        Greg M. Bernstein

            
   Filename        : draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt

            
   Pages           : 14

            
   Date            : 2011-09-08

            
 

            
 This document provides GMPLS OSPF routing enhancements to support

            
 signal compatibility constraints associated with WSON network

            
 elements. These routing enhancements are required in common optical

            
 or hybrid electro-optical networks where not all of the optical

            
 signals in the network are compatible with all network elements

            
 participating in the network.

            
 

            
 This compatibility constraint model is applicable to common optical

            
 or hybrid electro optical systems such as OEO switches, regenerators,

            
 and wavelength converters since such systems can be limited to

            
 processing only certain types of WSON signals.

            
 

            
 

            
 

            
A URL for this Internet-Draft is:

            
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compa

            
tibility-ospf-05.txt

            
 

            
Internet-Drafts are also available by anonymous FTP at:

            
ftp://ftp.ietf.org/internet-drafts/

            
 

            
This Internet-Draft can be retrieved at:

            
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compat

            
ibility-ospf-05.txt _______________________________________________

            
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

      

    

  


--------------010408090909010801080506--

From internet-drafts@ietf.org  Wed Sep 21 01:28:47 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A73D721F8C2D; Wed, 21 Sep 2011 01:28:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.56
X-Spam-Level: 
X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g2WECIIWj7+N; Wed, 21 Sep 2011 01:28:47 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10BF021F8A96; Wed, 21 Sep 2011 01:28:47 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.60
Message-ID: <20110921082847.9420.50654.idtracker@ietfa.amsl.com>
Date: Wed, 21 Sep 2011 01:28:47 -0700
Cc: ccamp@ietf.org
Subject: [CCAMP] I-D Action: draft-ietf-ccamp-otn-g709-info-model-01.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Sep 2011 08:28:47 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Common Control and Measurement Plane =
Working Group of the IETF.

	Title           : Information model for G.709 Optical Transport Networks (=
OTN)
	Author(s)       : Sergio Belotti
                          Pietro Vittorio Grandi
                          Daniele Ceccarelli
                          Diego Caviglia
                          Fatai Zhang
                          Dan Li
	Filename        : draft-ietf-ccamp-otn-g709-info-model-01.txt
	Pages           : 21
	Date            : 2011-09-21

   The recent revision of ITU-T recommendation G.709 [G.709-v3] has
   introduced new fixed and flexible ODU containers in Optical Transport
   Networks (OTNs), enabling optimized support for an increasingly
   abundant service mix.

   This document provides a model of information needed by the routing
   and signaling process in OTNs to support Generalized Multiprotocol
   Label Switching (GMPLS) control of all currently defined ODU
   containers.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-otn-g709-info-model-01=
.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-otn-g709-info-model-01.=
txt

From sergio.belotti@alcatel-lucent.com  Wed Sep 21 01:39:38 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DAD421F8B6D for ; Wed, 21 Sep 2011 01:39:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.805
X-Spam-Level: 
X-Spam-Status: No, score=-4.805 tagged_above=-999 required=5 tests=[AWL=1.444,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x36lcKwtgMTX for ; Wed, 21 Sep 2011 01:39:37 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 455F521F8B66 for ; Wed, 21 Sep 2011 01:39:36 -0700 (PDT)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p8L8ewqW014960 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 21 Sep 2011 10:41:54 +0200
Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Wed, 21 Sep 2011 10:41:36 +0200
From: "BELOTTI, SERGIO (SERGIO)" 
To: "ccamp@ietf.org" 
Date: Wed, 21 Sep 2011 10:41:35 +0200
Thread-Topic: I-D Action: draft-ietf-ccamp-otn-g709-info-model-01.txt
Thread-Index: Acx4OOY7MBMRcqCzTiWECnF69IVgPQAAFdkQ
Message-ID: 
References: <20110921082847.9420.50654.idtracker@ietfa.amsl.com>
In-Reply-To: <20110921082847.9420.50654.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: it-IT
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80
Subject: [CCAMP] R: I-D Action: draft-ietf-ccamp-otn-g709-info-model-01.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Sep 2011 08:39:38 -0000

Dear all,

The draft uploaded contains modification in par. 4.1 about Tributary slot g=
ranularity information needs in signaling and routing, and relation with HW=
 fallback procedure.

Best Regards

The authors


SERGIO BELOTTI

ALCATEL-LUCENT
Terrestrial System Architect
Optics Portfolio Evolution

via Trento 30 , Vimercate(MI)  Italy
T: +39 0396863033
Sergio.Belotti@alcatel-lucent.com



-----Messaggio originale-----
Da: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] Pe=
r conto di internet-drafts@ietf.org
Inviato: mercoled=EC 21 settembre 2011 10.29
A: i-d-announce@ietf.org
Cc: ccamp@ietf.org
Oggetto: I-D Action: draft-ietf-ccamp-otn-g709-info-model-01.txt

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Common Control and Measurement Plane =
Working Group of the IETF.

	Title           : Information model for G.709 Optical Transport Networks (=
OTN)
	Author(s)       : Sergio Belotti
                          Pietro Vittorio Grandi
                          Daniele Ceccarelli
                          Diego Caviglia
                          Fatai Zhang
                          Dan Li
	Filename        : draft-ietf-ccamp-otn-g709-info-model-01.txt
	Pages           : 21
	Date            : 2011-09-21

   The recent revision of ITU-T recommendation G.709 [G.709-v3] has
   introduced new fixed and flexible ODU containers in Optical Transport
   Networks (OTNs), enabling optimized support for an increasingly
   abundant service mix.

   This document provides a model of information needed by the routing
   and signaling process in OTNs to support Generalized Multiprotocol
   Label Switching (GMPLS) control of all currently defined ODU
   containers.


A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-otn-g709-info-model-01=
.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-otn-g709-info-model-01.=
txt
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

From acee.lindem@ericsson.com  Wed Sep 21 09:01:27 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 587AE1F0CB3 for ; Wed, 21 Sep 2011 09:01:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.54
X-Spam-Level: 
X-Spam-Status: No, score=-6.54 tagged_above=-999 required=5 tests=[AWL=0.059,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iFYved4bCM4h for ; Wed, 21 Sep 2011 09:01:26 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.9]) by ietfa.amsl.com (Postfix) with ESMTP id 3E1961F0CB1 for ; Wed, 21 Sep 2011 09:01:26 -0700 (PDT)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id p8LG3Yit013075; Wed, 21 Sep 2011 11:03:35 -0500
Received: from EUSAACMS0702.eamcs.ericsson.se ([169.254.1.60]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Wed, 21 Sep 2011 12:03:28 -0400
From: Acee Lindem 
To: Leeyoung 
Date: Wed, 21 Sep 2011 12:03:27 -0400
Thread-Topic: [CCAMP] FW:	I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-01.txt
Thread-Index: Acx4d//b4sbwVE/JQ96O+1QK++aGkA==
Message-ID: <99609552-2C2C-450B-A084-FF73EE7B17E0@ericsson.com>
References: <7AEB3D6833318045B4AE71C2C87E8E1718166966@DFWEML501-MBX.china.huawei.com> <63CEF1D1-D774-40C9-90BB-04BD5E85BF1B@ericsson.com>  <73C7F487-34D7-49E0-81FC-F3B4F1501D66@ericsson.com>  <7AEB3D6833318045B4AE71C2C87E8E171816B9F2@DFWEML501-MBX.china.huawei.com>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E171816B9F2@DFWEML501-MBX.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: CCAMP 
Subject: Re: [CCAMP] FW:	I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-01.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Sep 2011 16:01:27 -0000

SGkgWW91bmcsDQoNCk9uIFNlcCAxNiwgMjAxMSwgYXQgNDozNyBQTSwgTGVleW91bmcgd3JvdGU6
DQoNCj4gSGkgQWNlZSBhbmQgRmF0YWksDQo+IA0KPiBJdCBtaWdodCBiZSBlYXNpZXIganVzdCB0
byBjcmVhdGUgYSBuZXcgVG9wIExldmVsIFRMViAoc2F5IHdlIG5hbWUgaXQsICJHZW5ldGljIiBO
b2RlIFByb3BlcnR5IFRMVikgdW5kZXIgd2hpY2ggd2UgY2FuIHBhY2thZ2UgYWxsIGdlbmVyaWMg
cHJvcGVydGllcyBzdWNoIGNvbm5lY3Rpdml0eSBtYXRyaXgsIGV0Yy4gDQo+IA0KPiBTaW5jZSB3
ZSBhcmUgY29uY2VybmVkIGFib3V0IHRoZSBNVFUgbGltaXQsIHRoaXMgYXBwcm9hY2ggd291bGQg
YmUgYSBnb29kIHdheSBub3QgdG8gbWl4IHVwIHdpdGggb3RoZXIgTm9kZSBhdHRyaWJ1dGUgc3R1
ZmZzIGN1cnJlbnRseSBkZWZpbmVkIHVuZGVyIE5vZGUgQXR0cmlidXRlIFRMVi4gSW4gbGlnaHQg
b2YgT1ROIHN0dWZmIGNvbWluZyBkb3duIHRoZSBwaXBlLCBjcmVhdGluZyBhIG5ldyBUb3AtTGV2
ZWwgVExWIHRvIHB1dCBhbGwgdGhlc2UgbmV3IGF0dHJpYnV0ZXMgc291bmRzIHJlYXNvbmFibGUg
dG8gbWUuIA0KDQpJIGFncmVlLiBJZiB0aGUgYXV0aG9ycyBhbmQgV0cgYXJlIGFtZW5hYmxlIHRv
IHRoaXMgc29sdXRpb24sIGl0IHdvdWxkIHNlZW0gdG8gc2ltcGxpZnkgdGhpbmdzLiANCg0KVGhh
bmtzLA0KQWNlZSANCg0KPiANCj4gTGlmdGluZyB1cCA1Nzg2IHJlc3RyaWN0aW9uIGlzIG9idmlv
dXNseSBmZWFzaWJsZSBidXQgaXQgdGFrZXMgYW5vdGhlciBkcmFmdCB0byBzb3J0IGl0IG91dC4g
RnJvbSBhIHByb2NlZHVyYWwgcGVyc3BlY3RpdmUsIGl0IHdpbGwgdGFrZSBhIGxvbmdlciBwYXRo
IGFuZCB0aGUgTVRVIGlzc3VlIHdpbGwgY29udGludWUgdG8gYmUgYW4gaXNzdWUuIA0KPiANCj4g
UmVnYXJkcywNCj4gWW91bmcNCj4gDQo+IA0KPiANCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn
ZS0tLS0tDQo+IEZyb206IFpoYW5nZmF0YWkgDQo+IFNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAx
MywgMjAxMSA5OjEzIFBNDQo+IFRvOiBBY2VlIExpbmRlbQ0KPiBDYzogR3JlZyBCZXJuc3RlaW47
IExlZXlvdW5nOyBDQ0FNUA0KPiBTdWJqZWN0OiBSRTogW0NDQU1QXSBGVzogSS1EIEFjdGlvbjog
ZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLWNvbnN0cmFpbnRzLW9zcGYtdGUtMDEudHh0
DQo+IA0KPiBIaSBBY2VlLA0KPiANCj4gRm9yIHlvdXIgcG9pbnQgMTogSSB3aWxsIHJlcGxhY2Ug
UkZDIDIzNzAgd2l0aCBSRkMgNTI1MCBpbiB0aGUgZnV0dXJlIHZlcnNpb24uDQo+IA0KPiBGb3Ig
eW91ciBwb2ludCAyOiBUaGVyZSB3ZXJlIGxvdHMgb2YgZGlzY3Vzc2lvbiBvbiB3aGV0aGVyIHdl
IHNob3VsZCByZW1vdmUgdGhlIFJGQzU3ODYgcmVzdHJpY3Rpb24gaW4gdGhlIG1haWxpbmcgbGlz
dCAod2UgYWxzbyBhc2tlZCBmb3Igc3VnZ2VzdGlvbnMgZnJvbSB0aGUgYXV0aG9ycyBvZiBSRkM1
Nzg2KSwgaG93ZXZlciwgdGhlcmUgd2FzIG5vIGNvbnNlbnN1cy4NCj4gDQo+IEFjdHVhbGx5LCBp
ZiB3ZSBjYW4gcmVtb3ZlIHRoZSBSRkM1Nzg2IHJlc3RyaWN0aW9uLCBpdCBjYW4gbWFrZSB0aGlu
Z3Mgc2ltcGxlLCBmb3IgZXhhbXBsZSwgd2UgZG9uJ3QgbmVlZCB0byBkZWZpbmUgYW5vdGhlciBu
ZXcgdG9wIE5vZGUgVExWIChpZS4sIE9wdGljYWwgTm9kZSBQcm9wZXJ0eSBUTFYpIHRvIGNhcnJ5
IFdTT04gT0VPIHN0dWZmLg0KPiANCj4gSSB3b3VsZCBsaWtlIHRvIGhlYXIgbW9yZSBvcGluaW9u
cyBmcm9tIENDQU1QZXJzIGFuZCBPU1BGZXJzIG9uIHBvaW50IDIuDQo+IA0KPiANCj4gVGhhbmtz
DQo+ICANCj4gRmF0YWkNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206
IEFjZWUgTGluZGVtIFttYWlsdG86YWNlZS5saW5kZW1AZXJpY3Nzb24uY29tXSANCj4gU2VudDog
MjAxMeW5tDnmnIgxNOaXpSA1OjA0DQo+IFRvOiBaaGFuZ2ZhdGFpDQo+IENjOiBHcmVnIEJlcm5z
dGVpbjsgTGVleW91bmc7IENDQU1QDQo+IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIEZXOiBJLUQgQWN0
aW9uOiBkcmFmdC1pZXRmLWNjYW1wLXdzb24tc2lnbmFsLWNvbXBhdGliaWxpdHktb3NwZi0wNS50
eHQNCj4gDQo+IEhpIEZhdGFpLA0KPiBJIG9ubHkgaGF2ZSB0d28gY29tbWVudHMgb24gdGhpcyBk
b2N1bWVudDoNCj4gDQo+ICAxLiBSZWZlcmVuY2UgUkZDIDUyNTAgcmF0aGVyIHRoYW4gUkZDIDIz
NzAgYXMgdGhlIGZvcm1lciBvYnNvbGV0ZWQgdGhlIGxhdHRlci4gDQo+ICAyLiBQb3NzaWJseSB0
aGlzIGRyYWZ0IHNob3VsZCByZW1vdmUgdGhlIFJGQyA1Nzg2IHJlc3RyaWN0aW9uIHRoYXQgb25s
eSBhIHNpbmdsZSBPU1BGIFRFIExTQSBjb250YWluaW5nIGEgdG9wLWxldmVsIFRMViBpcyBhbGxv
d2VkLiANCj4gICAgICBDb3VsZG4ndCB0aGUgY29ubmVjdGl2aXR5IG1hdHJpeCBiZWNvbWUgcXVp
dGUgbGFyZ2U/IA0KPiANCj4gVGhhbmtzLA0KPiBBY2VlDQo+IA0KPiANCj4gT24gU2VwIDEyLCAy
MDExLCBhdCAxMTo0MCBQTSwgWmhhbmdmYXRhaSB3cm90ZToNCj4gDQo+PiBIaSBBY2VlLA0KPj4g
DQo+PiBTb3JyeSBmb3IgYSBtaXN0YWtlLCA6LSkNCj4+IA0KPj4gSSBzaG91bGQgc2F5ICJ3aGVu
IEkgdXBkYXRlIGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC1jb25zdHJhaW50cy1vc3Bm
LXRlLTAwLnR4dCIgaW5zdGVhZCBvZiAiZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLWNv
bnN0cmFpbnRzLW9zcGYtdGUtMDUudHh0Ii4NCj4+IA0KPj4gDQo+PiANCj4+IA0KPj4gDQo+PiAN
Cj4+IFRoYW5rcw0KPj4gDQo+PiBGYXRhaQ0KPj4gDQo+PiANCj4+IC0tLS0tT3JpZ2luYWwgTWVz
c2FnZS0tLS0tDQo+PiBGcm9tOiBaaGFuZ2ZhdGFpIA0KPj4gU2VudDogMjAxMeW5tDnmnIgxM+aX
pSAxMTozOA0KPj4gVG86ICdBY2VlIExpbmRlbSc7IEdyZWcgQmVybnN0ZWluOyBMZWV5b3VuZw0K
Pj4gQ2M6IENDQU1QDQo+PiBTdWJqZWN0OiBSRTogW0NDQU1QXSBGVzogSS1EIEFjdGlvbjogZHJh
ZnQtaWV0Zi1jY2FtcC13c29uLXNpZ25hbC1jb21wYXRpYmlsaXR5LW9zcGYtMDUudHh0DQo+PiAN
Cj4+IEhpIEFjZWUsDQo+PiANCj4+IEkgcGVyc29uYWxseSBhZ3JlZSB3aXRoIHlvdXIgY29tbWVu
dHMgb24gIm11bHRpLWluc3RhbmNlIExTQSIuDQo+PiANCj4+IEkgd2lsbCB0YWtlIHlvdXIgc3Vn
Z2VzdGlvbnMgaW50byBhY2NvdW50IHdoZW4gSSB1cGRhdGUgImRyYWZ0LWlldGYtY2NhbXAtZ21w
bHMtZ2VuZXJhbC1jb25zdHJhaW50cy1vc3BmLXRlLTA1LnR4dCIuDQo+PiANCj4+IA0KPj4gDQo+
PiANCj4+IFRoYW5rcw0KPj4gDQo+PiBGYXRhaQ0KPj4gDQo+PiANCj4+IC0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2Nh
bXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFjZWUgTGluZGVtDQo+PiBTZW50OiAy
MDEx5bm0OeaciDEz5pelIDY6NTgNCj4+IFRvOiBHcmVnIEJlcm5zdGVpbjsgTGVleW91bmcNCj4+
IENjOiBDQ0FNUA0KPj4gU3ViamVjdDogUmU6IFtDQ0FNUF0gRlc6IEktRCBBY3Rpb246IGRyYWZ0
LWlldGYtY2NhbXAtd3Nvbi1zaWduYWwtY29tcGF0aWJpbGl0eS1vc3BmLTA1LnR4dA0KPj4gDQo+
PiBIaSBZb3VuZywgR3JlZywNCj4+IEkgaGF2ZSB0aGUgZm9sbG93aW5nIGNvbW1lbnRzOg0KPj4g
DQo+PiAgMS4gU3BlY2lmeSB0aGF0IHRoZSBPcHRpY2FsIE5vZGUgUHJvcGVydHkgVExWIGNhcmRp
bmFsaXR5IGFuZCBvcmRlciBydWxlcyBwZXIgTFNBLiANCj4+ICAgICAgRm9yIGV4YW1wbGUgKGZy
b20gUkZDIDM2MzApOiANCj4+IA0KPj4gICAgIlRoZSBMaW5rIFRMViBkZXNjcmliZXMgYSBzaW5n
bGUgbGluay4gIEl0IGlzIGNvbnN0cnVjdGVkIG9mIGEgc2V0IG9mDQo+PiAgICAgIHN1Yi1UTFZz
LiAgVGhlcmUgYXJlIG5vIG9yZGVyaW5nIHJlcXVpcmVtZW50cyBmb3IgdGhlIHN1Yi1UTFZzLg0K
Pj4gDQo+PiAgICAgT25seSBvbmUgTGluayBUTFYgc2hhbGwgYmUgY2FycmllZCBpbiBlYWNoIExT
QSwgYWxsb3dpbmcgZm9yIGZpbmUgIA0KPj4gICAgIGdyYW51bGFyaXR5IGNoYW5nZXMgaW4gdG9w
b2xvZ3kuIg0KPj4gDQo+PiAgICAgSG93ZXZlciwgdXNlIHRoZSB0ZXJtICJhZHZlcnRpc2VkIiBy
YXRoZXIgdGhhbiAiY2FycmllZCIuIEFmdGVyIGFsbCwgdGhlc2UgYXJlDQo+PiAgICAgTGluayBT
dGF0ZSBBZHZlcnRpc2VtZW50cy4gDQo+PiANCj4+ICAyLiBUaGUgc2FtZSBjb21tZW50IGZvciBh
bGwgdGhlIFN1Yi1UTFZzLiBIZXJlIGlzIGFub3RoZXIgZXhhbXBsZSBmcm9tIA0KPj4gICAgICAg
UkZDIDM2MzA6DQo+PiANCj4+ICAgICAiVGhlIExpbmsgVHlwZSBhbmQgTGluayBJRCBzdWItVExW
cyBhcmUgbWFuZGF0b3J5LCBpLmUuLCBtdXN0IGFwcGVhcg0KPj4gICAgICBleGFjdGx5IG9uY2Uu
ICBBbGwgb3RoZXIgc3ViLVRMVnMgZGVmaW5lZCBoZXJlIG1heSBvY2N1ciBhdCBtb3N0DQo+PiAg
ICAgIG9uY2UuICBUaGVzZSByZXN0cmljdGlvbnMgbmVlZCBub3QgYXBwbHkgdG8gZnV0dXJlIHN1
Yi1UTFZzLg0KPj4gICAgICBVbnJlY29nbml6ZWQgc3ViLVRMVnMgYXJlIGlnbm9yZWQuIg0KPj4g
DQo+PiAgICAgIFRoZSBuZXcgU3ViLVRMVnMgeW91IGFyZSBkZWZpbmluZyBuZWVkIHRoaXMgbGV2
ZWwgb2Ygc3BlY2lmaWNhdGlvbi4gDQo+PiANCj4+ICAzLiBJIGtub3cgSSB0b2xkIHlvdSBub3Qg
dG8gdXNlIHRoZSB0ZXJtICJtdWx0aS1pbnN0YW5jZSBMU0EiLiBJIHN0aWxsIGRvbid0IGxpa2UN
Cj4+ICAgICAgdGhlIHVzYWdlIG9mICJMU0EgaW5zdGFuY2UiIGluIHRoZSBkcmFmdC4gSW4gdGhl
IGJhc2UgT1NQRiBzcGVjaWZpY2F0aW9uLCBSRkMgMjMyOCwgDQo+PiAgICAgIHRoZSB0ZXJtIExT
QSBpbnN0YW5jZSBpcyB1c2VkIHRvIGRlbm90ZSBhIHBhcnRpY3VsYXIgdmVyc2lvbiBvZiB0aGUg
c2FtZSBMU0EgLSBOT1QNCj4+ICAgICAgYW4gb3BhcXVlIGlkZW50aWZpZXIgZm9yIG11bHRpcGxl
IExTQXMgb2YgdGhlIHNhbWUgdHlwZS4gUmVmZXIgdG8gc2VjdGlvbiAxMi4xIGluIA0KPj4gICAg
ICBSRkMgMjMyOC4gDQo+PiANCj4+ICAgICBUaGUgT1NQRiBPcGFxdWUgTFNBIFJGQyAoUkZDIDIz
NzAgYW5kIGl0cyBzdWNjZXNzb3IgUkZDIDUyNTApIGNvcnJlY3RseSANCj4+ICAgICAgaWRlbnRp
ZnkgdGhlIGxhc3QgMjQgYml0cyBvZiB0aGUgTFNBIElEIGFzIHRoZSBPcGFxdWUgSUQuIFdoaWxl
IFJGQyAzNjMwIHJlZmVycw0KPj4gICAgICB0byB0aGlzIGZpZWxkIGFzIHRoZSAiSW5zdGFuY2Ui
LCBJIGJlbGlldmUgdGhpcyB0ZXJtIHNob3VsZCBiZSBhdm9pZGVkIGdpdmVuIHRoZSANCj4+ICAg
ICAgc2VtYW50aWNzIGluIHRoZSBPU1BGIGJhc2Ugc3BlY2lmaWNhdGlvbi4gSGVuY2UsIEknZCBz
dWdnZXN0IHRoZSANCj4+ICAgICAgZm9sbG93aW5nIGNoYW5nZXM6DQo+PiANCj4+IDIyNSwyMjZj
MjI1LDIyNg0KPj4gPCAgICB0aGUgcmVzdCBhbmQgbWFrZSB1c2Ugb2YgbXVsdGlwbGUgVEUgTFNB
IGluc3RhbmNlcyBwZXIgc291cmNlLCBwZXINCj4+IDwgICAgW1JGQzM2MzBdIG11bHRpcGxlIGlu
c3RhbmNlIGNhcGFiaWxpdHkuDQo+PiAtLS0NCj4+PiAgdGhlIHJlc3QgYW5kIGJlIGFkdmVydGlz
ZWQgd2l0aCBtdWx0aXBsZSBURSBMU0FzIHBlciBPU1BGIHJvdXRlciwgYXMNCj4+PiAgZGVzY3Jp
YmVkIGluIFtSRkMzNjMwXSBhbmQgW1JGQzUyNTBdLg0KPj4gMzQyLDM0NGMzNDIsMzQ0DQo+PiA8
ICAgIHRoZSBkeW5hbWljIGluZm9ybWF0aW9uIHN1Yi1UTFZzIGludG8gc2VwYXJhdGUgTFNBcyB3
aXRoaW4gYW4gT3B0aWNhbA0KPj4gPCAgICBOb2RlIFByb3BlcnR5IFRMViB1c2luZyBtdWx0aXBs
ZSBURSBMU0EgaW5zdGFuY2VzIHBlciBzb3VyY2UsIHBlciB0aGUNCj4+IDwgICAgcmVmZXJlbmNl
IFtSRkMzNjMwXSBtdWx0aXBsZSBpbnN0YW5jZSBjYXBhYmlsaXR5Lg0KPj4gLS0tDQo+Pj4gIHRo
ZSBkeW5hbWljIGluZm9ybWF0aW9uIHN1Yi1UTFZzIGZyb20gdGhlIHN0YXRpYyBpbmZvcm1hdGlv
biBzdWItVExWcw0KPj4+ICBhbmQgYWR2ZXJ0aXNlIHRoZW0gaW4gT1NQRiBURSBMU0FzLCBlYWNo
IHdpdGggdGhlIE9wdGljYWwgTm9kZQ0KPj4+ICBQcm9wZXJ0eSBUTFYgYXQgdGhlIHRvcCBsZXZl
bCAoW1JGQzM2MzAgYW5kIFJGQzUyNTBdKS4gDQo+PiAzOTJjMzkyDQo+PiA8ICAgIGludG8gc21h
bGxlciBzdWItVExWcyB0aGF0IGNhbiBiZSBzZW50IGluIHNlcGFyYXRlIExTQSBpbnN0YW5jZXMu
DQo+PiAtLS0NCj4+PiAgaW50byBzbWFsbGVyIHN1Yi1UTFZzIHRoYXQgY2FuIGJlIHNlbnQgaW4g
c2VwYXJhdGUgT1NQRiBURSBMU0FzLg0KPj4gMzk5YzM5OQ0KPj4gPCAgICBzdWItVExWcyB0aGF0
IGNhbiBiZSBzZW50IGluIG11bHRpcGxlIExTQSBpbnN0YW5jZXMuIFRoZQ0KPj4gLS0tDQo+Pj4g
IHN1Yi1UTFZzIHRoYXQgY2FuIGJlIHNlbnQgaW4gbXVsdGlwbGUgT1NQRiBURSBMU0FzLiBUaGUN
Cj4+IDQ3M2M0NzMNCj4+IDwgICAgaW50byBtdWx0aXBsZSBMU0EgaW5zdGFuY2VzIGVhY2ggY29u
dGFpbmluZyBhIGRpc2pvaW50IGFzc2VtYmx5IG9mDQo+PiAtLS0NCj4+PiAgaW50byBtdWx0aXBs
ZSBPU1BGIFRFIExTQXMgZWFjaCBjb250YWluaW5nIGEgZGlzam9pbnQgYXNzZW1ibHkgb2YNCj4+
IA0KPj4gICAgQWRkaXRpb25hbGx5LCBJJ2QgYWRkIFJGQyA1MjUwIGFzIGF0IGxlYXN0IGEgaW5m
b3JtYXRpdmUgcmVmZXJlbmNlLg0KPj4gDQo+PiANCj4+IA0KPj4gIDQuIEZpbmFsbHksIEknZCBz
dWdnZXN0IGNoYW5naW5nIHRoZSB0aXRsZSBmcm9tICJPU1BGIEVuaGFuY2VtZW50Li4uIiB0byAN
Cj4+ICAgICAgIkdNUExTIE9TUEYgRW5oYW5jZW1lbnQuLi4iIHNpbmNlIHlvdSBhcmUgbm90IHJl
YWxseSBlbmhhbmNpbmcgYmFzZSANCj4+ICAgICAgT1NQRiBpdHNlbGYuICBPZiBjb3Vyc2UsIHRo
ZXJlIGFyZSBvdGhlciBDQ0FNUCBSRkNzIHRoYXQgZG8gbm90IG1ha2UgDQo+PiAgICAgIHRoaXMg
ZGlzdGluY3Rpb24uIA0KPj4gDQo+PiANCj4+IFRoYW5rcywNCj4+IEFjZWUgDQo+PiANCj4+IA0K
Pj4gDQo+PiBPbiBTZXAgOSwgMjAxMSwgYXQgMzo1MSBQTSwgTGVleW91bmcgd3JvdGU6DQo+PiAN
Cj4+PiBIaSwNCj4+PiANCj4+PiBUaGlzIHVwZGF0ZSBhZGRlZCBhIG5ldyBzZWN0aW9uIHRvIGRp
c2N1c3MgT1NQRiBzY2FsYWJpbGl0eSBhbmQgaG93IHRvIHVzZSBtdWx0aXBsZSBURSBMU0EgaW5z
dGFuY2UgdGVjaG5pcXVlIHRvIGtlZXAgdGhlIExTQSB1bmRlciB0aGUgTVRVIGxpbWl0LiBQbGVh
c2Ugbm90ZSB0aGF0IHRoZSBNVFUgbGltaXQgaXMgMTUwMCBieXRlcyBhbmQgdGhlIGV4YW1wbGVz
IGdpdmVuIGluIHRoZSBlbmNvZGluZyBkcmFmdCBpcyBmYXIgYmVsb3cgdGhpcyBsaW1pdC4gSW4g
Y2FzZSB0aGUgTFNBIHNpemUgZ29lcyBhYm92ZSB0aGUgTVRVLCB0aGlzIGRyYWZ0IGRpc2N1c3Nl
cyBob3cgdG8gc3BsaXQgdGhlIFN1Yi1UTFZzJyBkZWZpbmVkIHVuZGVyIHRoZSBPcHRpY2FsIE5v
ZGUgUHJvcGVydHkgVExWIHVuZGVyIHRoZSBNVFUgbGltaXQgdG8gYXZvaWQgZnJhZ21lbnRhdGlv
bi4gDQo+Pj4gDQo+Pj4gVGFrZSBhIGxvb2sgYXQgU2VjdGlvbiAzIGFuZCBpZiB5b3UgaGF2ZSBx
dWVzdGlvbnMsIHBsZWFzZSBmZWVsIGZyZWUgdG8gZGlzY3VzcyBpbiB0aGUgbWFpbGluZyBsaXN0
LiANCj4+PiANCj4+PiBSZWdhcmRzLA0KPj4+IFlvdW5nDQo+Pj4gDQo+Pj4gDQo+Pj4gDQo+Pj4g
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+PiBGcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYu
b3JnIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIA0KPj4+IE9mIGlu
dGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KPj4+IFNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMDgs
IDIwMTEgNToxNiBQTQ0KPj4+IFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4+PiBDYzogY2Nh
bXBAaWV0Zi5vcmcNCj4+PiBTdWJqZWN0OiBbQ0NBTVBdIEktRCBBY3Rpb246IA0KPj4+IGRyYWZ0
LWlldGYtY2NhbXAtd3Nvbi1zaWduYWwtY29tcGF0aWJpbGl0eS1vc3BmLTA1LnR4dA0KPj4+IA0K
Pj4+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIElu
dGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0
aGUgQ29tbW9uIENvbnRyb2wgYW5kIE1lYXN1cmVtZW50IFBsYW5lIFdvcmtpbmcgR3JvdXAgb2Yg
dGhlIElFVEYuDQo+Pj4gDQo+Pj4gCVRpdGxlICAgICAgICAgICA6IE9TUEYgRW5oYW5jZW1lbnQg
Zm9yIFNpZ25hbCBhbmQgTmV0d29yayBFbGVtZW50IENvbXBhdGliaWxpdHkgZm9yIFdhdmVsZW5n
dGggU3dpdGNoZWQgT3B0aWNhbCBOZXR3b3Jrcw0KPj4+IAlBdXRob3IocykgICAgICAgOiBZb3Vu
ZyBMZWUNCj4+PiAgICAgICAgICAgICAgICAgICAgICAgIEdyZWcgTS4gQmVybnN0ZWluDQo+Pj4g
CUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtY2NhbXAtd3Nvbi1zaWduYWwtY29tcGF0aWJp
bGl0eS1vc3BmLTA1LnR4dA0KPj4+IAlQYWdlcyAgICAgICAgICAgOiAxNA0KPj4+IAlEYXRlICAg
ICAgICAgICAgOiAyMDExLTA5LTA4DQo+Pj4gDQo+Pj4gVGhpcyBkb2N1bWVudCBwcm92aWRlcyBH
TVBMUyBPU1BGIHJvdXRpbmcgZW5oYW5jZW1lbnRzIHRvIHN1cHBvcnQNCj4+PiBzaWduYWwgY29t
cGF0aWJpbGl0eSBjb25zdHJhaW50cyBhc3NvY2lhdGVkIHdpdGggV1NPTiBuZXR3b3JrDQo+Pj4g
ZWxlbWVudHMuIFRoZXNlIHJvdXRpbmcgZW5oYW5jZW1lbnRzIGFyZSByZXF1aXJlZCBpbiBjb21t
b24gb3B0aWNhbA0KPj4+IG9yIGh5YnJpZCBlbGVjdHJvLW9wdGljYWwgbmV0d29ya3Mgd2hlcmUg
bm90IGFsbCBvZiB0aGUgb3B0aWNhbA0KPj4+IHNpZ25hbHMgaW4gdGhlIG5ldHdvcmsgYXJlIGNv
bXBhdGlibGUgd2l0aCBhbGwgbmV0d29yayBlbGVtZW50cw0KPj4+IHBhcnRpY2lwYXRpbmcgaW4g
dGhlIG5ldHdvcmsuDQo+Pj4gDQo+Pj4gVGhpcyBjb21wYXRpYmlsaXR5IGNvbnN0cmFpbnQgbW9k
ZWwgaXMgYXBwbGljYWJsZSB0byBjb21tb24gb3B0aWNhbA0KPj4+IG9yIGh5YnJpZCBlbGVjdHJv
IG9wdGljYWwgc3lzdGVtcyBzdWNoIGFzIE9FTyBzd2l0Y2hlcywgcmVnZW5lcmF0b3JzLA0KPj4+
IGFuZCB3YXZlbGVuZ3RoIGNvbnZlcnRlcnMgc2luY2Ugc3VjaCBzeXN0ZW1zIGNhbiBiZSBsaW1p
dGVkIHRvDQo+Pj4gcHJvY2Vzc2luZyBvbmx5IGNlcnRhaW4gdHlwZXMgb2YgV1NPTiBzaWduYWxz
Lg0KPj4+IA0KPj4+IA0KPj4+IA0KPj4+IEEgVVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlz
Og0KPj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtY2Nh
bXAtd3Nvbi1zaWduYWwtY29tcGENCj4+PiB0aWJpbGl0eS1vc3BmLTA1LnR4dA0KPj4+IA0KPj4+
IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoN
Cj4+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4+IA0KPj4+IFRoaXMg
SW50ZXJuZXQtRHJhZnQgY2FuIGJlIHJldHJpZXZlZCBhdDoNCj4+PiBmdHA6Ly9mdHAuaWV0Zi5v
cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtY2NhbXAtd3Nvbi1zaWduYWwtY29tcGF0DQo+
Pj4gaWJpbGl0eS1vc3BmLTA1LnR4dCBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KPj4+IENDQU1QIG1haWxpbmcgbGlzdA0KPj4+IENDQU1QQGlldGYub3Jn
DQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPj4+IF9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pj4gQ0NBTVAg
bWFpbGluZyBsaXN0DQo+Pj4gQ0NBTVBAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9y
Zy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+PiANCj4gDQoNCg==

From wwwrun@rfc-editor.org  Wed Sep 21 12:07:27 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E2E1F0C71; Wed, 21 Sep 2011 12:07:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.03
X-Spam-Level: 
X-Spam-Status: No, score=-102.03 tagged_above=-999 required=5 tests=[AWL=-0.353, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yBRSNSq8AEH5; Wed, 21 Sep 2011 12:07:27 -0700 (PDT)
Received: from rfc-editor.org (rfcpa.amsl.com [12.22.58.47]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6C11F0C48; Wed, 21 Sep 2011 12:07:27 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id F404798C26B; Wed, 21 Sep 2011 12:09:56 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20110921190956.F404798C26B@rfc-editor.org>
Date: Wed, 21 Sep 2011 12:09:56 -0700 (PDT)
Cc: ccamp@ietf.org, rfc-editor@rfc-editor.org
Subject: [CCAMP] RFC 6373 on MPLS Transport Profile (MPLS-TP) Control Plane Framework
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Sep 2011 19:07:27 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 6373

        Title:      MPLS Transport Profile (MPLS-TP) Control 
                    Plane Framework 
        Author:     L. Andersson, Ed.,
                    L. Berger, Ed.,
                    L. Fang, Ed.,
                    N. Bitar, Ed.,
                    E. Gray, Ed.
        Status:     Informational
        Stream:     IETF
        Date:       September 2011
        Mailbox:    loa.andersson@ericsson.com, 
                    lberger@labn.net, 
                    lufang@cisco.com,  nabil.n.bitar@verizon.com, 
                    Eric.Gray@Ericsson.com
        Pages:      57
        Characters: 144259
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-ccamp-mpls-tp-cp-framework-06.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6373.txt

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 Label Switched Paths
(LSPs).  MPLS-TP also uses the pseudowire (PW) control plane for
pseudowires.  Management-plane functions are out of scope of
this document.

This document is a product of a joint Internet Engineering Task Force
(IETF) / International Telecommunication Union Telecommunication
Standardization Sector (ITU-T) effort to include an MPLS Transport
Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge
(PWE3) architectures to support the capabilities and functionalities
of a packet transport network as defined by the ITU-T.

This document is not an Internet Standards Track specification; it is
published for informational purposes.

This document is a product of the Common Control and Measurement Plane Working Group of the IETF.


INFORMATIONAL: This memo provides information for the Internet community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From internet-drafts@ietf.org  Thu Sep 22 02:06:27 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F7B21F8CED; Thu, 22 Sep 2011 02:06:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.562
X-Spam-Level: 
X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjdwiVWb+NtM; Thu, 22 Sep 2011 02:06:27 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000D321F8B47; Thu, 22 Sep 2011 02:06:26 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 3.60
Message-ID: <20110922090626.6373.58763.idtracker@ietfa.amsl.com>
Date: Thu, 22 Sep 2011 02:06:26 -0700
Cc: ccamp@ietf.org
Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Sep 2011 09:06:27 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Common Control and Measurement Plane =
Working Group of the IETF.

	Title           : OSPF-TE Extensions for General Network Element Constrain=
ts
	Author(s)       : Fatai Zhang
                          Young Lee
                          Jianrui Han
                          Greg Bernstein
                          Yunbin Xu
	Filename        : draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt
	Pages           : 14
	Date            : 2011-09-22

   Generalized Multiprotocol Label Switching can be used to control a
   wide variety of technologies including packet switching (e.g., MPLS),
   time-division (e.g., SONET/SDH, OTN), wavelength (lambdas), and
   spatial switching (e.g., incoming port or fiber to outgoing port or
   fiber). 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 describes OSPF routing protocol extensions to
   support these kinds of constraints under the control of Generalized
   MPLS (GMPLS).



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-general-constrai=
nts-ospf-te-02.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-general-constrain=
ts-ospf-te-02.txt

From zhangfatai@huawei.com  Thu Sep 22 02:15:05 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4065C21F8D24 for ; Thu, 22 Sep 2011 02:15:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.597
X-Spam-Level: 
X-Spam-Status: No, score=-5.597 tagged_above=-999 required=5 tests=[AWL=1.002,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rLa6Wl8Zn0N2 for ; Thu, 22 Sep 2011 02:15:04 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 7263821F8D0F for ; Thu, 22 Sep 2011 02:15:04 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRX009QU3596B@szxga04-in.huawei.com> for ccamp@ietf.org; Thu, 22 Sep 2011 17:17:33 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRX00CAC358TG@szxga04-in.huawei.com> for ccamp@ietf.org; Thu, 22 Sep 2011 17:17:33 +0800 (CST)
Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AEC44519; Thu, 22 Sep 2011 17:17:32 +0800
Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 22 Sep 2011 17:17:22 +0800
Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.142]) by szxeml405-hub.china.huawei.com ([10.82.67.60]) with mapi id 14.01.0270.001; Thu, 22 Sep 2011 17:17:25 +0800
Date: Thu, 22 Sep 2011 09:17:24 +0000
From: Zhangfatai 
In-reply-to: <20110922090626.6373.58763.idtracker@ietfa.amsl.com>
X-Originating-IP: [10.70.76.157]
To: "ccamp@ietf.org" 
Message-id: 
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-language: en-US
Content-transfer-encoding: base64
Accept-Language: zh-CN, en-US
Thread-topic: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt
Thread-index: AQHMeQhw4fH7IgNgHEuaM0yhaE8MRg==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <20110922090626.6373.58763.idtracker@ietfa.amsl.com>
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Sep 2011 09:15:05 -0000

SGkgQ0NBTVBlcnMsDQoNCkEgbmV3IHZlcnNpb24gaGFzIGJlZW4gc3VibWl0dGVkIHRvIGFkZHJl
c3MgdGhlIGNvbW1lbnRzIGZyb20gdGhlIFdHIGRpc2N1c3Npb24uDQoNCldlIGFjY2VwdGVkIEFj
ZWUgYW5kIFlvdW5nJ3Mgc3VnZ2VzdGlvbiB0byBpbnRyb2R1Y2UgYSBuZXcgdG9wLWxldmVsIG5v
ZGUgVExWIChHZW5lcmljIE5vZGUgQXR0cmlidXRlIFRMVikgdG8gc2ltcGxpZnkgdGhpbmdzIGFu
ZCBhIG5ldyBzZWN0aW9uIChTZWN0aW9uIDUpIHdhcyBhZGRlZCB0byBkZXNjcmliZSBzY2FsYWJp
bGl0eSBpc3N1ZS4NCg0KTW9yZSBpbmZvcm1hdGlvbiBmcm9tOiBodHRwOi8vd3d3LmlldGYub3Jn
L2lkL2RyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC1jb25zdHJhaW50cy1vc3BmLXRlLTAy
LnR4dA0KDQpQbGVhc2UgY2hlY2sgb3V0IGZvciBkZXRhaWxzIGFuZCBjb21tZW50cyBhcmUgYWx3
YXlzIHdlbGNvbWUuDQoNCg0KVGhhbmtzDQrCoA0KRmF0YWkNCg0KDQotLS0tLU9yaWdpbmFsIE1l
c3NhZ2UtLS0tLQ0KRnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJv
dW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNClNl
bnQ6IDIwMTHlubQ55pyIMjLml6UgMTc6MDYNClRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCkNj
OiBjY2FtcEBpZXRmLm9yZw0KU3ViamVjdDogW0NDQU1QXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRm
LWNjYW1wLWdtcGxzLWdlbmVyYWwtY29uc3RyYWludHMtb3NwZi10ZS0wMi50eHQNCg0KQSBOZXcg
SW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJh
ZnRzIGRpcmVjdG9yaWVzLiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBDb21tb24g
Q29udHJvbCBhbmQgTWVhc3VyZW1lbnQgUGxhbmUgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4N
Cg0KCVRpdGxlICAgICAgICAgICA6IE9TUEYtVEUgRXh0ZW5zaW9ucyBmb3IgR2VuZXJhbCBOZXR3
b3JrIEVsZW1lbnQgQ29uc3RyYWludHMNCglBdXRob3IocykgICAgICAgOiBGYXRhaSBaaGFuZw0K
ICAgICAgICAgICAgICAgICAgICAgICAgICBZb3VuZyBMZWUNCiAgICAgICAgICAgICAgICAgICAg
ICAgICAgSmlhbnJ1aSBIYW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgR3JlZyBCZXJuc3Rl
aW4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgWXVuYmluIFh1DQoJRmlsZW5hbWUgICAgICAg
IDogZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLWNvbnN0cmFpbnRzLW9zcGYtdGUtMDIu
dHh0DQoJUGFnZXMgICAgICAgICAgIDogMTQNCglEYXRlICAgICAgICAgICAgOiAyMDExLTA5LTIy
DQoNCiAgIEdlbmVyYWxpemVkIE11bHRpcHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nIGNhbiBiZSB1
c2VkIHRvIGNvbnRyb2wgYQ0KICAgd2lkZSB2YXJpZXR5IG9mIHRlY2hub2xvZ2llcyBpbmNsdWRp
bmcgcGFja2V0IHN3aXRjaGluZyAoZS5nLiwgTVBMUyksDQogICB0aW1lLWRpdmlzaW9uIChlLmcu
LCBTT05FVC9TREgsIE9UTiksIHdhdmVsZW5ndGggKGxhbWJkYXMpLCBhbmQNCiAgIHNwYXRpYWwg
c3dpdGNoaW5nIChlLmcuLCBpbmNvbWluZyBwb3J0IG9yIGZpYmVyIHRvIG91dGdvaW5nIHBvcnQg
b3INCiAgIGZpYmVyKS4gSW4gc29tZSBvZiB0aGVzZSB0ZWNobm9sb2dpZXMgbmV0d29yayBlbGVt
ZW50cyBhbmQgbGlua3MgbWF5DQogICBpbXBvc2UgYWRkaXRpb25hbCByb3V0aW5nIGNvbnN0cmFp
bnRzIHN1Y2ggYXMgYXN5bW1ldHJpYyBzd2l0Y2gNCiAgIGNvbm5lY3Rpdml0eSwgbm9uLWxvY2Fs
IGxhYmVsIGFzc2lnbm1lbnQsIGFuZCBsYWJlbCByYW5nZSBsaW1pdGF0aW9ucw0KICAgb24gbGlu
a3MuIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIE9TUEYgcm91dGluZyBwcm90b2NvbCBleHRlbnNp
b25zIHRvDQogICBzdXBwb3J0IHRoZXNlIGtpbmRzIG9mIGNvbnN0cmFpbnRzIHVuZGVyIHRoZSBj
b250cm9sIG9mIEdlbmVyYWxpemVkDQogICBNUExTIChHTVBMUykuDQoNCg0KDQpBIFVSTCBmb3Ig
dGhpcyBJbnRlcm5ldC1EcmFmdCBpczoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh
ZnRzL2RyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC1jb25zdHJhaW50cy1vc3BmLXRlLTAy
LnR4dA0KDQpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBG
VFAgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KDQpUaGlzIEludGVy
bmV0LURyYWZ0IGNhbiBiZSByZXRyaWV2ZWQgYXQ6DQpmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJu
ZXQtZHJhZnRzL2RyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC1jb25zdHJhaW50cy1vc3Bm
LXRlLTAyLnR4dA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCkNDQU1QIG1haWxpbmcgbGlzdA0KQ0NBTVBAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCg==

From fred.gruman@us.fujitsu.com  Thu Sep 22 10:23:30 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 418C121F8BEB for ; Thu, 22 Sep 2011 10:23:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.598
X-Spam-Level: 
X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2PpL4bQXiCs8 for ; Thu, 22 Sep 2011 10:23:29 -0700 (PDT)
Received: from fncnmp04.fnc.fujitsu.com (fncnmp04.fnc.fujitsu.com [168.127.0.57]) by ietfa.amsl.com (Postfix) with ESMTP id 47B1A21F8B94 for ; Thu, 22 Sep 2011 10:23:29 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.68,424,1312174800";  d="scan'208,217";a="478946602"
Received: from rchemxp01.fnc.net.local ([168.127.134.111]) by fncnmp02.fnc.fujitsu.com with ESMTP; 22 Sep 2011 12:26:00 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC794C.B292CF8A"
Date: Thu, 22 Sep 2011 12:26:00 -0500
Message-ID: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Questions/comments on OTN signaling
Thread-Index: Acx5TLK62imqLTNqRbO9SLfzHCpWGg==
From: "Gruman, Fred" 
To: 
Subject: [CCAMP] Questions/comments on OTN signaling
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Sep 2011 17:23:30 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC794C.B292CF8A
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello Fatai,

=20

I have some comments/questions on
draft-zhang-ccamp-gmpls-evolving-g709-09.

=20

1) I think the draft should discuss the Generalized Label Request
object.  Will this object use the new OTN switching capability
(Switching Type =3D 101)?

=20

2)  How is ODUflex(GFP) signaled? In general, the draft seems to lack
detail on ODUflex(GFP).

=20

More specifically, the draft states "In case of ODUflex(CBR), the
Bit_Rate and Tolerance fields MUST be used together to represent the
actual bandwidth of ODUflex" and later "In case of other ODUk signal
types, the Bit_Rate and Tolerance fields are not necessary and MUST be
set to 0."  It is not clear if this implies that ODUflex(GFP) should set
Bit_rate and Tolerance to zero.  I would assume ODUflex(GFP) would need
Bit_Rate, but unsure if tolerance is needed.

=20

3) G.709 Amendment 2 (2011-04) Table 7-9 has a row to cover the generic
ODUflex(CBR) with notes to the formulas to calculate the number of
tributary slots.  Additionally, this table has specific rows to cover
ODUflex(CBR) IB SDR, IB DDR, IB QDR, FC-400, and FC-800 and specifies
the explicit number of tributary slot assignments when mapped into
ODUflex into HO-OPUk).  =20

=20

It seems that the generic formula for ODUflex(CBR) does not result in
the same number of tributary slots for some of these client signals.
For example, IB SDR over HO-OPU3 has nominal bit rate of 2,500,000
kbits/s and bit rate tolerance of +/-100ppm (from G.709 Amend2 Table
17-14).  Using the generic ODUflex(CBR) formula, you get:

=20

N =3D ceiling [(2500000 * (1+100/1e6)) / ( 1254703.729 * (1-20/1e6)) ]

    =3D ceiling [2500250 / 1254678.635]

    =3D ceiling [1.99274135]

    =3D 2

 =20

Table 7-9 shows that IB SDR mapped into ODUflex over HO-OPU3 would use 3
tributary slots, not 2.

=20

Please verify my math but if the generic ODUflex formula does not apply
to the IB or FC clients, then we may need to have explicit signal types
for these clients.

=20

I found that the IB clients do not match the generic formula for some
HO-OPUk but the FC clients do match.  This may mean we only would need
explicit signal types for:

- ODUflex(CBR)-IB-SDR

- ODUflex(CBR)-IB-DDR

- ODUflex(CBR)-IB-QDR

=20

Please let me know what you think.

=20

Thanks,

Fred


------_=_NextPart_001_01CC794C.B292CF8A
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
















Hello Fatai,



 



I have some comments/questions on
draft-zhang-ccamp-gmpls-evolving-g709-09.



 



1) I think the draft should discuss the Generalized =
Label
Request object.  Will this object use the new OTN switching =
capability
(Switching Type =3D 101)?



 



2)  How is ODUflex(GFP) signaled? In general, =
the draft
seems to lack detail on ODUflex(GFP).



 



More specifically, the draft states "In case =
of
ODUflex(CBR), the Bit_Rate and Tolerance fields MUST be used together to
represent the actual bandwidth of ODUflex" and later "In case =
of
other ODUk signal types, the Bit_Rate and Tolerance fields are not =
necessary
and MUST be set to 0."  It is not clear if this implies that =
ODUflex(GFP)
should set Bit_rate and Tolerance to zero.  I would assume =
ODUflex(GFP)
would need Bit_Rate, but unsure if tolerance is needed.



 



3) G.709 Amendment 2 (2011-04) Table 7-9 has a row =
to cover
the generic ODUflex(CBR) with notes to the formulas to calculate the =
number of
tributary slots.  Additionally, this table has specific rows to =
cover
ODUflex(CBR) IB SDR, IB DDR, IB QDR, FC-400, and FC-800 and specifies =
the
explicit number of tributary slot assignments when mapped into ODUflex =
into
HO-OPUk).   



 



It seems that the generic formula for ODUflex(CBR) =
does not
result in the same number of tributary slots for some of these client =
signals. 
For example, IB SDR over HO-OPU3 has nominal bit rate of 2,500,000 =
kbits/s and
bit rate tolerance of +/-100ppm (from G.709 Amend2 Table 17-14).  =
Using
the generic ODUflex(CBR) formula, you get:



 



N =3D ceiling [(2500000 * (1+100/1e6)) / ( =
1254703.729 *
(1-20/1e6)) ]



    =3D ceiling [2500250 / =
1254678.635]



    =3D ceiling =
[1.99274135]



    =3D 2



  



Table 7-9 shows that IB SDR mapped into ODUflex =
over HO-OPU3
would use 3 tributary slots, not 2.



 



Please verify my math but if the generic ODUflex =
formula
does not apply to the IB or FC clients, then we may need to have =
explicit
signal types for these clients.



 



I found that the IB clients do not match the =
generic formula
for some HO-OPUk but the FC clients do match.  This may mean we =
only would
need explicit signal types for:



- ODUflex(CBR)-IB-SDR



- ODUflex(CBR)-IB-DDR



- ODUflex(CBR)-IB-QDR



 



Please let me know what you think.



 



Thanks,



Fred









------_=_NextPart_001_01CC794C.B292CF8A--

From db3546@att.com  Thu Sep 22 11:06:55 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DCA221F85F2; Thu, 22 Sep 2011 11:06:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N4DtDTkvs2fL; Thu, 22 Sep 2011 11:06:54 -0700 (PDT)
Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 5FA1121F8551; Thu, 22 Sep 2011 11:06:54 -0700 (PDT)
X-Env-Sender: db3546@att.com
X-Msg-Ref: server-12.tower-120.messagelabs.com!1316714964!39598807!1
X-Originating-IP: [144.160.20.145]
X-StarScan-Version: 6.3.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 696 invoked from network); 22 Sep 2011 18:09:25 -0000
Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-12.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Sep 2011 18:09:25 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p8MI9nFC014434; Thu, 22 Sep 2011 14:09:51 -0400
Received: from MISOUT7MSGHUB9D.ITServices.sbc.com (misout7msghub9d.itservices.sbc.com [144.151.223.93]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p8MI9fUJ013996 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Sep 2011 14:09:42 -0400
Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([169.254.6.215]) by MISOUT7MSGHUB9D.ITServices.sbc.com ([144.151.223.93]) with mapi id 14.01.0289.001; Thu, 22 Sep 2011 14:09:14 -0400
From: "BRUNGARD, DEBORAH A" 
To: "ccamp@ietf.org" , "iesg-secretary@ietf.org" 
Thread-Topic: Please publish draft-ietf-ccamp-attribute-bnf-02
Thread-Index: Acx5Urppc3egytCkRdibbkcpkgj9iA==
Date: Thu, 22 Sep 2011 18:09:14 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-cr-hashedpuzzle: Fdaj Gw1F G+bs KuNj LMUT MMmI Q8Lt RDvR Tf9X T6pQ Uszj XLeS X8bC Y0k/ bC9Y eGRi; 3; YQBkAHIAaQBhAG4AQABvAGwAZABkAG8AZwAuAGMAbwAuAHUAawA7AGMAYwBhAG0AcABAAGkAZQB0AGYALgBvAHIAZwA7AGkAZQBzAGcALQBzAGUAYwByAGUAdABhAHIAeQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {D4B1595B-FA28-435F-A059-1EC3B117E90B}; ZABiADMANQA0ADYAQABhAHQAdAAuAGMAbwBtAA==; Thu, 22 Sep 2011 18:09:10 GMT; UABsAGUAYQBzAGUAIABwAHUAYgBsAGkAcwBoACAAZAByAGEAZgB0AC0AaQBlAHQAZgAtAGMAYwBhAG0AcAAtAGEAdAB0AHIAaQBiAHUAdABlAC0AYgBuAGYALQAwADIA
x-cr-puzzleid: {D4B1595B-FA28-435F-A059-1EC3B117E90B}
x-originating-ip: [135.16.234.231]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [CCAMP] Please publish draft-ietf-ccamp-attribute-bnf-02
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Sep 2011 18:06:55 -0000

PROTO-write-up for:     draft-ietf-ccamp-attribute-bnf-02.txt
Intended status:  Standards Track

   (1.a) Who is the Document Shepherd for this document? Has the
         Document Shepherd personally reviewed this version of the
         document and, in particular, does he or she believe this
         version is ready for forwarding to the IESG for publication?

Deborah Brungard is the Document Shepherd.
She has reviewed the document and believes it is ready for forwarding to
the IESG for publication.

   (1.b) Has the document had adequate review both from key WG members
         and from key non-WG members? Does the Document Shepherd have
         any concerns about the depth or breadth of the reviews that
         have been performed?

Yes.  No concerns.

   (1.c) Does the Document Shepherd have concerns that the document
         needs more review from a particular or broader perspective,
         e.g., security, operational complexity, someone familiar with
         AAA, internationalization or XML?

No concerns or additional review needed.

   (1.d) Does the Document Shepherd have any specific concerns or
         issues with this document that the Responsible Area Director
         and/or the IESG should be aware of? For example, perhaps he
         or she is uncomfortable with certain parts of the document, or
         has concerns whether there really is a need for it. In any
         event, if the WG has discussed those issues and has indicated
         that it still wishes to advance the document, detail those
         concerns here. Has an IPR disclosure related to this document
         been filed? If so, please include a reference to the
         disclosure and summarize the WG discussion and conclusion on
         this issue.

No concerns or issues.

   (1.e) How solid is the WG consensus behind this document? Does it
         represent the strong concurrence of a few individuals, with
         others being silent, or does the WG as a whole understand and
         agree with it?

There is solid consensus behind this document.

   (1.f) Has anyone threatened an appeal or otherwise indicated extreme
         discontent? If so, please summarise the areas of conflict in
         separate email messages to the Responsible Area Director. (It
         should be in a separate email because this questionnaire is
         entered into the ID Tracker.)

No.

   (1.g) Has the Document Shepherd personally verified that the
         document satisfies all ID nits? (See the Internet-Drafts
Checklist
         and http://tools.ietf.org/tools/idnits/). Boilerplate checks
are
         not enough; this check needs to be thorough. Has the document
         met all formal review criteria it needs to, such as the MIB
         Doctor, media type and URI type reviews?

Yes.  No issues identified by idnits.  No other reviews are required.

   (1.h) Has the document split its references into normative and
         informative? Are there normative references to documents that
         are not ready for advancement or are otherwise in an unclear
         state? If such normative references exist, what is the
         strategy for their completion? Are there normative references
         that are downward references, as described in [RFC3967]? If
         so, list these downward references to support the Area
         Director in the Last Call procedure for them [RFC3967].

Split looks good.

   (1.i) Has the Document Shepherd verified that the document IANA
         consideration section exists and is consistent with the body
         of the document? If the document specifies protocol
         extensions, are reservations requested in appropriate IANA
         registries? Are the IANA registries clearly identified? If
         the document creates a new registry, does it define the
         proposed initial contents of the registry and an allocation
         procedure for future registrations? Does it suggest a
         reasonable name for the new registry? See [RFC5226]. If the
         document describes an Expert Review process has Shepherd
         conferred with the Responsible Area Director so that the IESG
         can appoint the needed Expert during the IESG Evaluation?

No new IANA assignments.

   (1.j) Has the Document Shepherd verified that sections of the
         document that are written in a formal language, such as XML
         code, BNF rules, MIB definitions, etc., validate correctly in
         an automated checker?

Yes.

   (1.k) The IESG approval announcement includes a Document
         Announcement Write-Up. Please provide such a Document
         Announcement Write-Up? Recent examples can be found in the
         "Action" announcements for approved documents. The approval
         announcement contains the following sections:

      Technical Summary
         Relevant content can frequently be found in the abstract
         and/or introduction of the document. If not, this may be
         an indication that there are deficiencies in the abstract
         or introduction.

Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
established using the Resource Reservation Protocol Traffic
Engineering (RSVP-TE) extensions may be signaled with a set of LSP
specific attributes.  These attributes may be carried in both Path
and Resv messages.  This document specifies how LSP attribute are
to be carried in RSVP Path and Resv messages using the Routing
Backus-Naur Form, and clarifies related Resv message formats.
This document updates RFC 4875 and RFC 5420.

      Working Group Summary
         Was there anything in WG process that is worth noting? For
         example, was there controversy about particular points or
         were there decisions where the consensus was particularly
         rough?

No. The document is considered to be both stable and
complete.

      Document Quality
         Are there existing implementations of the protocol? Have a
         significant number of vendors indicated their plan to
         implement the specification? Are there any reviewers that
         merit special mention as having done a thorough review,
         e.g., one that resulted in important changes or a
         conclusion that the document had no substantive issues? If
         there was a MIB Doctor, Media Type or other expert review,
         what was its course (briefly)? In the case of a Media Type
         review, on what date was the request posted?

No implementations have been publicly discussed.




From leeyoung@huawei.com  Thu Sep 22 12:41:06 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E76141F0C6D for ; Thu, 22 Sep 2011 12:41:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.554
X-Spam-Level: 
X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[AWL=0.044,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2CeKhwOKQ0p for ; Thu, 22 Sep 2011 12:41:04 -0700 (PDT)
Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id AF8121F0C3C for ; Thu, 22 Sep 2011 12:41:04 -0700 (PDT)
Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LRX00BHOW4O0T@usaga04-in.huawei.com> for ccamp@ietf.org; Thu, 22 Sep 2011 14:43:36 -0500 (CDT)
Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug  8 2006)) with ESMTP id <0LRX00FQ2W4JUW@usaga04-in.huawei.com> for ccamp@ietf.org; Thu, 22 Sep 2011 14:43:36 -0500 (CDT)
Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 22 Sep 2011 12:43:28 -0700
Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Thu, 22 Sep 2011 12:43:31 -0700
Date: Thu, 22 Sep 2011 19:43:30 +0000
From: Leeyoung 
In-reply-to: <4E784267.1030609@cisco.com>
X-Originating-IP: [10.47.155.83]
To: Giovanni Martinelli 
Message-id: <7AEB3D6833318045B4AE71C2C87E8E171817C223@DFWEML501-MBX.china.huawei.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_+1D9t8HS+aIQ5HAMRN8zQA)"
Content-language: en-US
Accept-Language: en-US
Thread-topic: [CCAMP]	FW:	I-D	Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt
Thread-index: AQHMd2gaTs+pek618EWLs4jSVdjhwpVZx+lg
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: <7AEB3D6833318045B4AE71C2C87E8E1718166966@DFWEML501-MBX.china.huawei.com> <63CEF1D1-D774-40C9-90BB-04BD5E85BF1B@ericsson.com>  <73C7F487-34D7-49E0-81FC-F3B4F1501D66@ericsson.com> <4E77A151.6000200@cisco.com> <7AEB3D6833318045B4AE71C2C87E8E1718175AE4@DFWEML501-MBX.china.huawei.com> <4E784267.1030609@cisco.com>
Cc: CCAMP 
Subject: Re: [CCAMP] FW:	I-D	Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Sep 2011 19:41:07 -0000

--Boundary_(ID_+1D9t8HS+aIQ5HAMRN8zQA)
Content-type: text/plain; charset=iso-2022-jp
Content-transfer-encoding: 7BIT

Hi Giovanni,

We have updated the generic OSPF draft (thanks to Fatai).


*         Point #1: Regarding your concern on how to build a connectivity matrix in case we need to decompose into several sub-TLV$B!G(Bs, we have added the following subsection in the revision:

5.2. Decomposing a Connectivity Matrix into Multiple Matrices

   In the highly unlikely event that a Connectivity matrix sub-TLV by
   itself would result in an LSA exceeding the MTU, a single large
   matrix can be decomposed into sub-matrices. Per [GEN-Encode] a
   connectivity matrix just consists of pairs of input and output ports
   that can reach each other and hence such this decomposition would be
   straightforward. Each of these sub-matrices would get a unique matrix
   identifier per [GEN-Encode].

Please let us know if you still have a question after reviewing the text.



*         Point  #2: In addition, the revision proposed a new solution that allows multiple sub-TLV$B!G(Bs defined in a top-level TLV. Please see Section 2 in which we added the following text:

   This document defines a new top TLV named the Generic Node Attribute
   TLV which carries attributes related to a general network element.
   This Generic Node Attribute TLV contains one or more sub-TLVs

And in Section 7.1, we added

   This document introduces a new Top Level Node TLV (Generic Node
   Attribute TLV) under the OSPF TE LSA defined in [RFC3630].

      Value    TLV Type

      TBA      Generic Node Attribute

Please let us know if this seems to be a viable solution. If not, please suggest an alternative solution.



*         Point #3: Finally, concerning your question/comment: Since it has to be "generic" we don't know in principle. Does not look a problem for *unconstrained* wson nodes. Don't know if others has different options for wson technology or may be possible other technologies (otn?).

I am not clear what you are asking for here. But if I guess, you are concerned about $B!H(Bgeneric$B!I(B technology connectivity matrix. Please note that the reason why we needed the connectivity matrix in WSON was due to the nature of asymmetric nature of ROADM switching technology.

If switches are symmetric, we don$B!G(Bt need to advertise the connectivity matrix. This means any port can be switched to any other ports. Please see the last paragraph of Section 2:

   In some specific technologies, e.g., WSON networks, Connectivity
   Matrix sub-TLV may be optional, which depends on the control plane
   implementations. Usually, for example, in WSON networks, Connectivity
   Matrix sub-TLV may appear in the LSAs because WSON switches are
   asymmetric at present. It is assumed that the switches are symmetric
   switching, if there is no Connectivity Matrix sub-TLV in the LSAs.

Please let us know if you still have a question after reviewing the text.

Best Regards,
Young

From: Giovanni Martinelli [mailto:giomarti@cisco.com]
Sent: Tuesday, September 20, 2011 2:36 AM
To: Leeyoung
Cc: Acee Lindem; CCAMP
Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt

Hi,

On 9/19/11 10:29 PM, Leeyoung wrote:
Hi Giovanni,

Your worst case analysis for 16 degree node connectivity matrix is subject to verification,
but even if this is a right number, 300 bytes is well under 1500 byte MTU limit, so we can package it without sub-dividing the TLV.

yes , I was not concerned about mtu but how to build a correct connectivity matrix beyond a simple 2 degree node. If you provide few more numbers there's probably a better feeling of "how many" bytes are (well beyond the mtu but well above the 75 bytes in the example).


We can easily partition the connectivity matrix even if it goes beyond the MTU limit.
Agree that's a good solution  but my comment here is related to how do we partition. Would it worth to add some text about it? We could probably guess (e.g. linkset couple) but just to make sure all readers will have same interpretation.


The last email to the CCAMP was concerning how to do it.

-          We can lift off RFC 5786 restriction to be able to send multiple TLVs under the current Node Attribute TLV.

-          Define a new top level TLV to do that.

I know and I was not replaying on last email but trying to providing numbers for the connectivity matrix.


I don$B!G(Bt think the scale of the connectivity matrix is a big issue.

Since it has to be "generic" we don't know in principle. Does not look a problem for *unconstrained* wson nodes. Don't know if others has different options for wson technology or may be possible other technologies (otn?).

Cheers
G

Regards,
Young


From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Giovanni Martinelli
Sent: Monday, September 19, 2011 3:09 PM
To: Acee Lindem
Cc: CCAMP
Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt

Hi,

On 9/13/11 11:04 PM, Acee Lindem wrote:

Hi Fatai,

I only have two comments on this document:



  1. Reference RFC 5250 rather than RFC 2370 as the former obsoleted the latter.

  2. Possibly this draft should remove the RFC 5786 restriction that only a single OSPF TE LSA containing a top-level TLV is allowed.

      Couldn't the connectivity matrix become quite large?
as far as I've see there is a couple of  examples here http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-05 within appendix A3 and A4.  So asking authors, any other numbers around?

My comment here is that those numbers refers essentially to 2 degree node. I would ask if draft can report some information (formula in the optimal case) that allow to figure out how the connectivity matrix scale.

E.g. Thinking about a 16 degree node my guess reading the appendix A4: the last part of the TLV (from "note : line to line" on) we need to add one more 32 bits to identify the out-range, and we need to replicate this link-set tuple 15 times.  So in total the "line to line" become 5*15*4 = 300 bytes

Is my guess correct?

Cheers
G









Thanks,

Acee





On Sep 12, 2011, at 11:40 PM, Zhangfatai wrote:



Hi Acee,



Sorry for a mistake, :-)



I should say "when I update draft-ietf-ccamp-gmpls-general-constraints-ospf-te-00.txt" instead of "draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05.txt".













Thanks



Fatai





-----Original Message-----

From: Zhangfatai

Sent: 2011$BG/(B9$B7n(B13$BF|(B 11:38

To: 'Acee Lindem'; Greg Bernstein; Leeyoung

Cc: CCAMP

Subject: RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt



Hi Acee,



I personally agree with your comments on "multi-instance LSA".



I will take your suggestions into account when I update "draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05.txt".









Thanks



Fatai





-----Original Message-----

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Acee Lindem

Sent: 2011$BG/(B9$B7n(B13$BF|(B 6:58

To: Greg Bernstein; Leeyoung

Cc: CCAMP

Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt



Hi Young, Greg,

I have the following comments:



  1. Specify that the Optical Node Property TLV cardinality and order rules per LSA.

      For example (from RFC 3630):



    "The Link TLV describes a single link.  It is constructed of a set of

      sub-TLVs.  There are no ordering requirements for the sub-TLVs.



     Only one Link TLV shall be carried in each LSA, allowing for fine

     granularity changes in topology."



     However, use the term "advertised" rather than "carried". After all, these are

     Link State Advertisements.



  2. The same comment for all the Sub-TLVs. Here is another example from

       RFC 3630:



     "The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear

      exactly once.  All other sub-TLVs defined here may occur at most

      once.  These restrictions need not apply to future sub-TLVs.

      Unrecognized sub-TLVs are ignored."



      The new Sub-TLVs you are defining need this level of specification.



  3. I know I told you not to use the term "multi-instance LSA". I still don't like

      the usage of "LSA instance" in the draft. In the base OSPF specification, RFC 2328,

      the term LSA instance is used to denote a particular version of the same LSA - NOT

      an opaque identifier for multiple LSAs of the same type. Refer to section 12.1 in

      RFC 2328.



     The OSPF Opaque LSA RFC (RFC 2370 and its successor RFC 5250) correctly

      identify the last 24 bits of the LSA ID as the Opaque ID. While RFC 3630 refers

      to this field as the "Instance", I believe this term should be avoided given the

      semantics in the OSPF base specification. Hence, I'd suggest the

      following changes:



225,226c225,226

<    the rest and make use of multiple TE LSA instances per source, per

<    [RFC3630] multiple instance capability.

---

  the rest and be advertised with multiple TE LSAs per OSPF router, as

  described in [RFC3630] and [RFC5250].

342,344c342,344

<    the dynamic information sub-TLVs into separate LSAs within an Optical

<    Node Property TLV using multiple TE LSA instances per source, per the

<    reference [RFC3630] multiple instance capability.

---

  the dynamic information sub-TLVs from the static information sub-TLVs

  and advertise them in OSPF TE LSAs, each with the Optical Node

  Property TLV at the top level ([RFC3630 and RFC5250]).

392c392

<    into smaller sub-TLVs that can be sent in separate LSA instances.

---

  into smaller sub-TLVs that can be sent in separate OSPF TE LSAs.

399c399

<    sub-TLVs that can be sent in multiple LSA instances. The

---

  sub-TLVs that can be sent in multiple OSPF TE LSAs. The

473c473

<    into multiple LSA instances each containing a disjoint assembly of

---

  into multiple OSPF TE LSAs each containing a disjoint assembly of



    Additionally, I'd add RFC 5250 as at least a informative reference.







  4. Finally, I'd suggest changing the title from "OSPF Enhancement..." to

      "GMPLS OSPF Enhancement..." since you are not really enhancing base

      OSPF itself.  Of course, there are other CCAMP RFCs that do not make

      this distinction.





Thanks,

Acee







On Sep 9, 2011, at 3:51 PM, Leeyoung wrote:



Hi,



This update added a new section to discuss OSPF scalability and how to use multiple TE LSA instance technique to keep the LSA under the MTU limit. Please note that the MTU limit is 1500 bytes and the examples given in the encoding draft is far below this limit. In case the LSA size goes above the MTU, this draft discusses how to split the Sub-TLVs' defined under the Optical Node Property TLV under the MTU limit to avoid fragmentation.



Take a look at Section 3 and if you have questions, please feel free to discuss in the mailing list.



Regards,

Young







-----Original Message-----

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf

Of internet-drafts@ietf.org

Sent: Thursday, September 08, 2011 5:16 PM

To: i-d-announce@ietf.org

Cc: ccamp@ietf.org

Subject: [CCAMP] I-D Action:

draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt



A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.



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

   Author(s)       : Young Lee

                        Greg M. Bernstein

   Filename        : draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt

   Pages           : 14

   Date            : 2011-09-08



 This document provides GMPLS OSPF routing enhancements to support

 signal compatibility constraints associated with WSON network

 elements. These routing enhancements are required in common optical

 or hybrid electro-optical networks where not all of the optical

 signals in the network are compatible with all network elements

 participating in the network.



 This compatibility constraint model is applicable to common optical

 or hybrid electro optical systems such as OEO switches, regenerators,

 and wavelength converters since such systems can be limited to

 processing only certain types of WSON signals.







A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compa

tibility-ospf-05.txt



Internet-Drafts are also available by anonymous FTP at:

ftp://ftp.ietf.org/internet-drafts/



This Internet-Draft can be retrieved at:

ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compat

ibility-ospf-05.txt _______________________________________________

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

--Boundary_(ID_+1D9t8HS+aIQ5HAMRN8zQA)
Content-type: text/html; charset=iso-2022-jp
Content-transfer-encoding: 7BIT











Hi Giovanni,


 


We have updated the generic OSPF draft (thanks to Fatai).



 



·        
Point #1: Regarding your concern on how to build a connectivity matrix in case we need to decompose into several sub-TLV$B!G(Bs, we have added the following
 subsection in the revision:


 


5.2. Decomposing a Connectivity Matrix into Multiple Matrices



 


   In the highly unlikely event that a Connectivity matrix sub-TLV by



   itself would result in an LSA exceeding the MTU, a single large



   matrix can be decomposed into sub-matrices. Per [GEN-Encode] a



   connectivity matrix just consists of pairs of input and output ports



   that can reach each other and hence such this decomposition would be



   straightforward. Each of these sub-matrices would get a unique matrix



   identifier per [GEN-Encode].



 


Please let us know if you still have a question after reviewing the text.


 


 



·        
Point  #2: In addition, the revision proposed a new solution that allows multiple sub-TLV$B!G(Bs defined in a top-level TLV. Please see Section 2 in
 which we added the following text:


 


   This document defines a new top TLV named the Generic Node Attribute



   TLV which carries attributes related to a general network element.



   This Generic Node Attribute TLV contains one or more sub-TLVs



 


And in Section 7.1, we added



 


   This document introduces a new Top Level Node TLV (Generic Node



   Attribute TLV) under the OSPF TE LSA defined in [RFC3630].



 


      Value    TLV Type



 


      TBA      Generic Node Attribute



 


Please let us know if this seems to be a viable solution. If not, please suggest an alternative solution.



 


 



·        
Point #3: Finally, concerning your question/comment:
Since it has to be "generic" we don't know in principle. Does not look a problem for *unconstrained* wson nodes. Don't know if others has different options for wson technology or may be possible other technologies (otn?).






I am not clear what you are asking for here. But if I guess, you are concerned about $B!H(Bgeneric$B!I(B technology connectivity matrix. Please note that the reason
 why we needed the connectivity matrix in WSON was due to the nature of asymmetric nature of ROADM switching technology.



 


If switches are symmetric, we don$B!G(Bt need to advertise the connectivity matrix. This means any port can be switched to any other ports. Please see the last
 paragraph of Section 2:


 


   In some specific technologies, e.g., WSON networks, Connectivity



   Matrix sub-TLV may be optional, which depends on the control plane



   implementations. Usually, for example, in WSON networks, Connectivity



   Matrix sub-TLV may appear in the LSAs because WSON switches are



   asymmetric at present. It is assumed that the switches are symmetric



   switching, if there is no Connectivity Matrix sub-TLV in the LSAs. 



 


Please let us know if you still have a question after reviewing the text.


 


Best Regards,


Young


 






From: Giovanni Martinelli [mailto:giomarti@cisco.com]


Sent: Tuesday, September 20, 2011 2:36 AM

To: Leeyoung

Cc: Acee Lindem; CCAMP

Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt






 


Hi,



On 9/19/11 10:29 PM, Leeyoung wrote: 


Hi Giovanni,


 


Your worst case analysis for 16 degree node connectivity matrix is subject to verification,




but even if this is a right number, 300 bytes is well under 1500 byte MTU limit, so we can package it without sub-dividing the TLV.  


 




yes , I was not concerned about mtu but how to build a correct connectivity matrix beyond a simple 2 degree node. If you provide few more numbers there's probably a better feeling of "how many" bytes are (well beyond the mtu but well above
 the 75 bytes in the example).








We can easily partition the connectivity matrix even if it goes beyond the MTU limit.


Agree that's a good solution  but my comment here is related to how do we partition. Would it worth to add some text about it? We could probably guess (e.g. linkset couple) but just to make sure all readers will have same interpretation.









The last email to the CCAMP was concerning how to do it.


-         
We can lift off RFC 5786 restriction to be able to send multiple TLVs under the current Node Attribute TLV.



-         
Define a new top level TLV to do that.



 


I know and I was not replaying on last email but trying to providing numbers for the connectivity matrix. 









I don$B!G(Bt think the scale of the connectivity matrix is a big issue.



 


Since it has to be "generic" we don't know in principle. Does not look a problem for *unconstrained* wson nodes. Don't know if others has different options for wson technology or may be possible other technologies (otn?).



Cheers

G






Regards,


Young


 


 






From:
ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org]
On Behalf Of Giovanni Martinelli

Sent: Monday, September 19, 2011 3:09 PM

To: Acee Lindem

Cc: CCAMP

Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt






 


Hi,



On 9/13/11 11:04 PM, Acee Lindem wrote: 


Hi Fatai,


I only have two comments on this document:


 


  1. Reference RFC 5250 rather than RFC 2370 as the former obsoleted the latter. 


  2. Possibly this draft should remove the RFC 5786 restriction that only a single OSPF TE LSA containing a top-level TLV is allowed. 


      Couldn't the connectivity matrix become quite large? 


as far as I've see there is a couple of  examples here 
http://tools.ietf.org/html/draft-ietf-ccamp-general-constraint-encode-05 within appendix A3 and A4.  So asking authors, any other numbers around?



My comment here is that those numbers refers essentially to 2 degree node. I would ask if draft can report some information (formula in the optimal case) that allow to figure out how the connectivity matrix scale.



E.g. Thinking about a 16 degree node my guess reading the appendix A4: the last part of the TLV (from "note : line to line" on) we need to add one more 32 bits to identify the out-range, and we need to replicate this link-set tuple 15 times.  So in total the
 "line to line" become 5*15*4 = 300 bytes



Is my guess correct?



Cheers

G
















 


Thanks,


Acee


 


 


On Sep 12, 2011, at 11:40 PM, Zhangfatai wrote:


 




Hi Acee,


 


Sorry for a mistake, :-)


 


I should say "when I update draft-ietf-ccamp-gmpls-general-constraints-ospf-te-00.txt" instead of "draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05.txt".


 


 


 


 


 


 


Thanks


 


Fatai


 


 


-----Original Message-----


From: Zhangfatai 


Sent: 2011$BG/(B9$B7n(B13$BF|(B 11:38


To: 'Acee Lindem'; Greg Bernstein; Leeyoung


Cc: CCAMP


Subject: RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt


 


Hi Acee,


 


I personally agree with your comments on "multi-instance LSA".


 


I will take your suggestions into account when I update "draft-ietf-ccamp-gmpls-general-constraints-ospf-te-05.txt".


 


 


 


 


Thanks


 


Fatai


 


 


-----Original Message-----


From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Acee Lindem


Sent: 2011$BG/(B9$B7n(B13$BF|(B 6:58


To: Greg Bernstein; Leeyoung


Cc: CCAMP


Subject: Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt


 


Hi Young, Greg,


I have the following comments:


 


  1. Specify that the Optical Node Property TLV cardinality and order rules per LSA. 


      For example (from RFC 3630): 


 


    "The Link TLV describes a single link.  It is constructed of a set of


      sub-TLVs.  There are no ordering requirements for the sub-TLVs.


 


     Only one Link TLV shall be carried in each LSA, allowing for fine  


     granularity changes in topology."


 


     However, use the term "advertised" rather than "carried". After all, these are


     Link State Advertisements. 


 


  2. The same comment for all the Sub-TLVs. Here is another example from 


       RFC 3630:


 


     "The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear


      exactly once.  All other sub-TLVs defined here may occur at most


      once.  These restrictions need not apply to future sub-TLVs.


      Unrecognized sub-TLVs are ignored."


 


      The new Sub-TLVs you are defining need this level of specification. 


 


  3. I know I told you not to use the term "multi-instance LSA". I still don't like


      the usage of "LSA instance" in the draft. In the base OSPF specification, RFC 2328, 


      the term LSA instance is used to denote a particular version of the same LSA - NOT


      an opaque identifier for multiple LSAs of the same type. Refer to section 12.1 in 


      RFC 2328. 


 


     The OSPF Opaque LSA RFC (RFC 2370 and its successor RFC 5250) correctly 


      identify the last 24 bits of the LSA ID as the Opaque ID. While RFC 3630 refers


      to this field as the "Instance", I believe this term should be avoided given the 


      semantics in the OSPF base specification. Hence, I'd suggest the 


      following changes:


 


225,226c225,226


<    the rest and make use of multiple TE LSA instances per source, per


<    [RFC3630] multiple instance capability.


---




  the rest and be advertised with multiple TE LSAs per OSPF router, as


  described in [RFC3630] and [RFC5250].




342,344c342,344


<    the dynamic information sub-TLVs into separate LSAs within an Optical


<    Node Property TLV using multiple TE LSA instances per source, per the


<    reference [RFC3630] multiple instance capability.


---




  the dynamic information sub-TLVs from the static information sub-TLVs


  and advertise them in OSPF TE LSAs, each with the Optical Node


  Property TLV at the top level ([RFC3630 and RFC5250]). 




392c392


<    into smaller sub-TLVs that can be sent in separate LSA instances.


---




  into smaller sub-TLVs that can be sent in separate OSPF TE LSAs.




399c399


<    sub-TLVs that can be sent in multiple LSA instances. The


---




  sub-TLVs that can be sent in multiple OSPF TE LSAs. The




473c473


<    into multiple LSA instances each containing a disjoint assembly of


---




  into multiple OSPF TE LSAs each containing a disjoint assembly of




 


    Additionally, I'd add RFC 5250 as at least a informative reference.


 


 


 


  4. Finally, I'd suggest changing the title from "OSPF Enhancement..." to 


      "GMPLS OSPF Enhancement..." since you are not really enhancing base 


      OSPF itself.  Of course, there are other CCAMP RFCs that do not make 


      this distinction. 


 


 


Thanks,


Acee 


 


 


 


On Sep 9, 2011, at 3:51 PM, Leeyoung wrote:


 




Hi,


 


This update added a new section to discuss OSPF scalability and how to use multiple TE LSA instance technique to keep the LSA under the MTU limit. Please note that the MTU limit is 1500 bytes and the examples given in the encoding draft is far below this limit. In case the LSA size goes above the MTU, this draft discusses how to split the Sub-TLVs' defined under the Optical Node Property TLV under the MTU limit to avoid fragmentation. 


 


Take a look at Section 3 and if you have questions, please feel free to discuss in the mailing list. 


 


Regards,


Young


 


 


 


-----Original Message-----


From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf 


Of internet-drafts@ietf.org


Sent: Thursday, September 08, 2011 5:16 PM


To: i-d-announce@ietf.org


Cc: ccamp@ietf.org


Subject: [CCAMP] I-D Action: 


draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt


 


A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.


 


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


   Author(s)       : Young Lee


                        Greg M. Bernstein


   Filename        : draft-ietf-ccamp-wson-signal-compatibility-ospf-05.txt


   Pages           : 14


   Date            : 2011-09-08


 


 This document provides GMPLS OSPF routing enhancements to support


 signal compatibility constraints associated with WSON network


 elements. These routing enhancements are required in common optical


 or hybrid electro-optical networks where not all of the optical


 signals in the network are compatible with all network elements


 participating in the network.


 


 This compatibility constraint model is applicable to common optical


 or hybrid electro optical systems such as OEO switches, regenerators,


 and wavelength converters since such systems can be limited to


 processing only certain types of WSON signals.


 


 


 


A URL for this Internet-Draft is:


http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compa


tibility-ospf-05.txt


 


Internet-Drafts are also available by anonymous FTP at:


ftp://ftp.ietf.org/internet-drafts/


 


This Internet-Draft can be retrieved at:


ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compat


ibility-ospf-05.txt _______________________________________________


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






--Boundary_(ID_+1D9t8HS+aIQ5HAMRN8zQA)--

From db3546@att.com  Thu Sep 22 13:19:27 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8268D11E80A2; Thu, 22 Sep 2011 13:19:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eM74vMsnA9x9; Thu, 22 Sep 2011 13:19:26 -0700 (PDT)
Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC6F11E80A1; Thu, 22 Sep 2011 13:19:25 -0700 (PDT)
X-Env-Sender: db3546@att.com
X-Msg-Ref: server-8.tower-119.messagelabs.com!1316722916!40634605!1
X-Originating-IP: [144.160.20.145]
X-StarScan-Version: 6.3.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 4723 invoked from network); 22 Sep 2011 20:21:57 -0000
Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-8.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 22 Sep 2011 20:21:57 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p8MKMNat003706; Thu, 22 Sep 2011 16:22:23 -0400
Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (misout7msghub9b.itservices.sbc.com [144.151.223.72]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p8MKMMVW003698 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 22 Sep 2011 16:22:22 -0400
Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([169.254.6.215]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.01.0289.001; Thu, 22 Sep 2011 16:21:55 -0400
From: "BRUNGARD, DEBORAH A" 
To: "ccamp@ietf.org" , "iesg-secretary@ietf.org" 
Thread-Topic: Please publish draft-ietf-ccamp-wson-impairments-07
Thread-Index: Acx5ZT+afLGnWVBjQj+LLf/iQl7YwQ==
Date: Thu, 22 Sep 2011 20:21:55 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.16.234.231]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [CCAMP] Please publish draft-ietf-ccamp-wson-impairments-07
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Sep 2011 20:19:27 -0000

PROTO-write-up for:     draft-ietf-ccamp-wson-impairments-07.txt
Intended status:  Informational

   (1.a) Who is the Document Shepherd for this document? Has the
         Document Shepherd personally reviewed this version of the
         document and, in particular, does he or she believe this
         version is ready for forwarding to the IESG for publication?

Deborah Brungard is the Document Shepherd.
She has reviewed the document and believes it is ready for forwarding to
the IESG for publication.

   (1.b) Has the document had adequate review both from key WG members
         and from key non-WG members? Does the Document Shepherd have
         any concerns about the depth or breadth of the reviews that
         have been performed?

Yes. No concerns. The WG Last Call was cc'd with the PCE WG. Additionally, =
liaisons were
exchanged with SG15 on data plane aspects.

   (1.c) Does the Document Shepherd have concerns that the document
         needs more review from a particular or broader perspective,
         e.g., security, operational complexity, someone familiar with
         AAA, internationalization or XML?

No concerns or additional review needed.

   (1.d) Does the Document Shepherd have any specific concerns or
         issues with this document that the Responsible Area Director
         and/or the IESG should be aware of? For example, perhaps he
         or she is uncomfortable with certain parts of the document, or
         has concerns whether there really is a need for it. In any
         event, if the WG has discussed those issues and has indicated
         that it still wishes to advance the document, detail those
         concerns here. Has an IPR disclosure related to this document
         been filed? If so, please include a reference to the
         disclosure and summarize the WG discussion and conclusion on
         this issue.

No concerns or issues.

   (1.e) How solid is the WG consensus behind this document? Does it
         represent the strong concurrence of a few individuals, with
         others being silent, or does the WG as a whole understand and
         agree with it?

There is solid consensus behind this document.

   (1.f) Has anyone threatened an appeal or otherwise indicated extreme
         discontent? If so, please summarise the areas of conflict in
         separate email messages to the Responsible Area Director. (It
         should be in a separate email because this questionnaire is
         entered into the ID Tracker.)

No.

   (1.g) Has the Document Shepherd personally verified that the
         document satisfies all ID nits? (See the Internet-Drafts
Checklist
         and http://tools.ietf.org/tools/idnits/). Boilerplate checks
are
         not enough; this check needs to be thorough. Has the document
         met all formal review criteria it needs to, such as the MIB
         Doctor, media type and URI type reviews?

Yes.  No issues identified by idnits.  No other reviews are required.

   (1.h) Has the document split its references into normative and
         informative? Are there normative references to documents that
         are not ready for advancement or are otherwise in an unclear
         state? If such normative references exist, what is the
         strategy for their completion? Are there normative references
         that are downward references, as described in [RFC3967]? If
         so, list these downward references to support the Area
         Director in the Last Call procedure for them [RFC3967].

Split looks good.

   (1.i) Has the Document Shepherd verified that the document IANA
         consideration section exists and is consistent with the body
         of the document? If the document specifies protocol
         extensions, are reservations requested in appropriate IANA
         registries? Are the IANA registries clearly identified? If
         the document creates a new registry, does it define the
         proposed initial contents of the registry and an allocation
         procedure for future registrations? Does it suggest a
         reasonable name for the new registry? See [RFC5226]. If the
         document describes an Expert Review process has Shepherd
         conferred with the Responsible Area Director so that the IESG
         can appoint the needed Expert during the IESG Evaluation?

Not applicable.

   (1.j) Has the Document Shepherd verified that sections of the
         document that are written in a formal language, such as XML
         code, BNF rules, MIB definitions, etc., validate correctly in
         an automated checker?

Not applicable.

   (1.k) The IESG approval announcement includes a Document
         Announcement Write-Up. Please provide such a Document
         Announcement Write-Up? Recent examples can be found in the
         "Action" announcements for approved documents. The approval
         announcement contains the following sections:

      Technical Summary
         Relevant content can frequently be found in the abstract
         and/or introduction of the document. If not, this may be
         an indication that there are deficiencies in the abstract
         or introduction.

This document provides a framework for applying GMPLS protocols and
the PCE architecture to support Impairment Aware Routing and
Wavelength Assignment (IA-RWA) in wavelength switched optical
networks. This document does not define optical data plane aspects;
impairment parameters, measurement of, or assessment and
qualification of a route, but rather it describes the architectural
and information components for protocol solutions.

      Working Group Summary
         Was there anything in WG process that is worth noting? For
         example, was there controversy about particular points or
         were there decisions where the consensus was particularly
         rough?

No. The document is considered to be both stable and
complete.

      Document Quality
         Are there existing implementations of the protocol? Have a
         significant number of vendors indicated their plan to
         implement the specification? Are there any reviewers that
         merit special mention as having done a thorough review,
         e.g., one that resulted in important changes or a
         conclusion that the document had no substantive issues? If
         there was a MIB Doctor, Media Type or other expert review,
         what was its course (briefly)? In the case of a Media Type
         review, on what date was the request posted?

This document is informational.




From lberger@labn.net  Fri Sep 23 04:37:54 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FDE221F8B0D for ; Fri, 23 Sep 2011 04:37:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.886
X-Spam-Level: 
X-Spam-Status: No, score=-100.886 tagged_above=-999 required=5 tests=[AWL=-0.725, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LZtP3CWwMMYX for ; Fri, 23 Sep 2011 04:37:53 -0700 (PDT)
Received: from oproxy3-pub.bluehost.com (oproxy3.bluehost.com [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id 8A64321F8888 for ; Fri, 23 Sep 2011 04:37:45 -0700 (PDT)
Received: (qmail 23272 invoked by uid 0); 23 Sep 2011 11:40:15 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy3.bluehost.com with SMTP; 23 Sep 2011 11:40:15 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default;  h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=U265mC3mLL2yTYuGlMdi6xNo8FyDRSFpzMDWaHIMLfY=;  b=tVrAucc3MN30Z4vh9Lk7i849IFnDkLFYKUhKOdv95rLrxC3DFJmZaONw25ST+GS/2tJJDQbqstxEmGWXZrE4N32f8Bm6Vje/rx2mUcLliuV0L7eJ2tXtEwYrRNN0qm0F;
Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1R7475-0002Xx-JU; Fri, 23 Sep 2011 05:40:15 -0600
Message-ID: <4E7C7021.9010806@labn.net>
Date: Fri, 23 Sep 2011 07:40:17 -0400
From: Lou Berger 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Zhangfatai 
References: <20110922090626.6373.58763.idtracker@ietfa.amsl.com> 
In-Reply-To: 
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Sep 2011 11:37:54 -0000

Fatai/Authors,

A couple of suggestions on the document:

1- I suggest taking another pass through the document to see
   which portions can be made truly generic, and to use WSON
   only as an example or specific case.  Clearly this isn't
   possible in all cases, but should be in others, e.g., the
   section on scaling.

2- While narrative/informative language is important to have,
   it's the normative language that is the main point of a
   standards track document. I suggest reviewing the document
   to ensure that the document has RFC2119 conformance language
   covering any definition related to behavior on the wire.

Much thanks,

Lou

On 9/22/2011 5:17 AM, Zhangfatai wrote:
> Hi CCAMPers,
> 
> A new version has been submitted to address the comments from the WG
> discussion.
> 
> We accepted Acee and Young's suggestion to introduce a new top-level
> node TLV (Generic Node Attribute TLV) to simplify things and a new
> section (Section 5) was added to describe scalability issue.
> 
> More information from:
> http://www.ietf.org/id/draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt
>
>  Please check out for details and comments are always welcome.
> 
> 
> Thanks
>  
> Fatai
> 
> 
> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
> Sent: 2011年9月22日 17:06
> To: i-d-announce@ietf.org
> Cc: ccamp@ietf.org
> Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.
> 
> 	Title           : OSPF-TE Extensions for General Network Element Constraints
> 	Author(s)       : Fatai Zhang
>                           Young Lee
>                           Jianrui Han
>                           Greg Bernstein
>                           Yunbin Xu
> 	Filename        : draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt
> 	Pages           : 14
> 	Date            : 2011-09-22
> 
>    Generalized Multiprotocol Label Switching can be used to control a
>    wide variety of technologies including packet switching (e.g., MPLS),
>    time-division (e.g., SONET/SDH, OTN), wavelength (lambdas), and
>    spatial switching (e.g., incoming port or fiber to outgoing port or
>    fiber). 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 describes OSPF routing protocol extensions to
>    support these kinds of constraints under the control of Generalized
>    MPLS (GMPLS).
> 
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt
> _______________________________________________
> 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 wwwrun@rfc-editor.org  Fri Sep 23 16:07:06 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C9321F8AA8; Fri, 23 Sep 2011 16:07:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.722
X-Spam-Level: 
X-Spam-Status: No, score=-101.722 tagged_above=-999 required=5 tests=[AWL=-0.645, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, J_CHICKENPOX_93=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2Ty+hDeWjdc; Fri, 23 Sep 2011 16:07:06 -0700 (PDT)
Received: from rfc-editor.org (rfcpa.amsl.com [12.22.58.47]) by ietfa.amsl.com (Postfix) with ESMTP id 06FBF21F8A56; Fri, 23 Sep 2011 16:07:06 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id B1C5298C277; Fri, 23 Sep 2011 16:09:41 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
From: rfc-editor@rfc-editor.org
Message-Id: <20110923230941.B1C5298C277@rfc-editor.org>
Date: Fri, 23 Sep 2011 16:09:41 -0700 (PDT)
Cc: ccamp@ietf.org, rfc-editor@rfc-editor.org
Subject: [CCAMP] RFC 6387 on GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Sep 2011 23:07:06 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 6387

        Title:      GMPLS Asymmetric Bandwidth Bidirectional Label 
                    Switched Paths (LSPs) 
        Author:     A. Takacs, L. Berger,
                    D. Caviglia, D. Fedyk,
                    J. Meuric
        Status:     Standards Track
        Stream:     IETF
        Date:       September 2011
        Mailbox:    attila.takacs@ericsson.com, 
                    lberger@labn.net, 
                    diego.caviglia@ericsson.com,  
                    donald.fedyk@alcatel-lucent.com, 
                    julien.meuric@orange.com
        Pages:      11
        Characters: 23329
        Obsoletes:  RFC5467

        I-D Tag:    draft-ietf-ccamp-asymm-bw-bidir-lsps-bis-03.txt

        URL:        http://www.rfc-editor.org/rfc/rfc6387.txt

This document defines a method for the support of GMPLS asymmetric
bandwidth bidirectional Label Switched Paths (LSPs).  The approach
presented is applicable to any switching technology and builds on the
original Resource Reservation Protocol (RSVP) model for the transport
of traffic-related parameters.  This document moves the experiment
documented in RFC 5467 to the standards track and obsoletes RFC 5467.
[STANDARDS-TRACK]

This document is a product of the Common Control and Measurement Plane Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From zhangfatai@huawei.com  Fri Sep 23 18:05:14 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3155121F8CCA for ; Fri, 23 Sep 2011 18:05:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.639
X-Spam-Level: 
X-Spam-Status: No, score=-5.639 tagged_above=-999 required=5 tests=[AWL=0.960,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Veg539pQP+aJ for ; Fri, 23 Sep 2011 18:05:13 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 300DD21F8CC3 for ; Fri, 23 Sep 2011 18:05:13 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS000H9Q5RH09@szxga04-in.huawei.com> for ccamp@ietf.org; Sat, 24 Sep 2011 09:06:53 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS000CKP5RHBR@szxga04-in.huawei.com> for ccamp@ietf.org; Sat, 24 Sep 2011 09:06:53 +0800 (CST)
Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AED13116; Sat, 24 Sep 2011 09:06:53 +0800
Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sat, 24 Sep 2011 09:06:39 +0800
Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.142]) by szxeml407-hub.china.huawei.com ([10.82.67.94]) with mapi id 14.01.0270.001; Sat, 24 Sep 2011 09:06:52 +0800
Date: Sat, 24 Sep 2011 01:06:50 +0000
From: Zhangfatai 
In-reply-to: <4E7C7021.9010806@labn.net>
X-Originating-IP: [10.70.76.157]
To: Lou Berger 
Message-id: 
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-language: en-US
Content-transfer-encoding: base64
Accept-Language: zh-CN, en-US
Thread-topic: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt
Thread-index: AQHMeQhw4fH7IgNgHEuaM0yhaE8MRpVaUvSAgAFj8CA=
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <20110922090626.6373.58763.idtracker@ietfa.amsl.com>  <4E7C7021.9010806@labn.net>
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Sep 2011 01:05:14 -0000

SGkgTG91LA0KDQpUaGFua3MgZm9yIHlvdXIgc3VnZ2VzdGlvbnMuIA0KDQpGb3IgcG9pbnQgMSwg
V2Ugd291bGQgbGlrZSB0byBleGFtaW5lIHRoZSBkb2N1bWVudCBhZ2FpbiB0byBzZWUgd2hpY2gg
cG9ydGlvbnMgY2FuIGJlIHRydWx5IGdlbmVyaWMuIEkgYW0gbm90IHN1cmUgdGhhdCBJIGdvdCB0
aGUgbWVhbmluZyBvZiB0aGUgc2VudGVuY2U6ICIgQ2xlYXJseSB0aGlzIGlzbid0IHBvc3NpYmxl
IGluIGFsbCBjYXNlcywgYnV0IHNob3VsZCBiZSBpbiBvdGhlcnMsIGUuZy4sIHRoZSBzZWN0aW9u
IG9uIHNjYWxpbmcuIiAgRGlkIHlvdSBtZWFuIHRoYXQgdGhlIHNlY3Rpb24gb24gc2NhbGluZyBp
cyBub3QgdHJ1bHkgZ2VuZXJpYz8gQ291bGQgeW91IGV4cGxhaW4gbW9yZT8NCg0KRm9yIHRoaXMg
cG9pbnQsIHdlIGFsc28gbGlrZSB0byBzZWUgdGhlIGNvbW1lbnRzIGZyb20gdGhlIFdHLg0KDQpG
b3IgcG9pbnQgMiwgYWdyZWUgd2l0aCB5b3UuIFdlIHdpbGwgdXBkYXRlIHRoaXMgZHJhZnQgaW4g
dGhlIG5leHQgdmVyc2lvbiBiYXNlZCBvbiB5b3VyIHN1Z2dlc3Rpb24uDQoNCg0KDQoNCg0KVGhh
bmtzDQrCoA0KRmF0YWkNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExvdSBC
ZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XSANClNlbnQ6IDIwMTHlubQ55pyIMjPml6Ug
MTk6NDANClRvOiBaaGFuZ2ZhdGFpDQpDYzogY2NhbXBAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb
Q0NBTVBdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC1jb25zdHJh
aW50cy1vc3BmLXRlLTAyLnR4dA0KDQpGYXRhaS9BdXRob3JzLA0KDQpBIGNvdXBsZSBvZiBzdWdn
ZXN0aW9ucyBvbiB0aGUgZG9jdW1lbnQ6DQoNCjEtIEkgc3VnZ2VzdCB0YWtpbmcgYW5vdGhlciBw
YXNzIHRocm91Z2ggdGhlIGRvY3VtZW50IHRvIHNlZQ0KICAgd2hpY2ggcG9ydGlvbnMgY2FuIGJl
IG1hZGUgdHJ1bHkgZ2VuZXJpYywgYW5kIHRvIHVzZSBXU09ODQogICBvbmx5IGFzIGFuIGV4YW1w
bGUgb3Igc3BlY2lmaWMgY2FzZS4gIENsZWFybHkgdGhpcyBpc24ndA0KICAgcG9zc2libGUgaW4g
YWxsIGNhc2VzLCBidXQgc2hvdWxkIGJlIGluIG90aGVycywgZS5nLiwgdGhlDQogICBzZWN0aW9u
IG9uIHNjYWxpbmcuDQoNCjItIFdoaWxlIG5hcnJhdGl2ZS9pbmZvcm1hdGl2ZSBsYW5ndWFnZSBp
cyBpbXBvcnRhbnQgdG8gaGF2ZSwNCiAgIGl0J3MgdGhlIG5vcm1hdGl2ZSBsYW5ndWFnZSB0aGF0
IGlzIHRoZSBtYWluIHBvaW50IG9mIGENCiAgIHN0YW5kYXJkcyB0cmFjayBkb2N1bWVudC4gSSBz
dWdnZXN0IHJldmlld2luZyB0aGUgZG9jdW1lbnQNCiAgIHRvIGVuc3VyZSB0aGF0IHRoZSBkb2N1
bWVudCBoYXMgUkZDMjExOSBjb25mb3JtYW5jZSBsYW5ndWFnZQ0KICAgY292ZXJpbmcgYW55IGRl
ZmluaXRpb24gcmVsYXRlZCB0byBiZWhhdmlvciBvbiB0aGUgd2lyZS4NCg0KTXVjaCB0aGFua3Ms
DQoNCkxvdQ0KDQpPbiA5LzIyLzIwMTEgNToxNyBBTSwgWmhhbmdmYXRhaSB3cm90ZToNCj4gSGkg
Q0NBTVBlcnMsDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIGhhcyBiZWVuIHN1Ym1pdHRlZCB0byBhZGRy
ZXNzIHRoZSBjb21tZW50cyBmcm9tIHRoZSBXRw0KPiBkaXNjdXNzaW9uLg0KPiANCj4gV2UgYWNj
ZXB0ZWQgQWNlZSBhbmQgWW91bmcncyBzdWdnZXN0aW9uIHRvIGludHJvZHVjZSBhIG5ldyB0b3At
bGV2ZWwNCj4gbm9kZSBUTFYgKEdlbmVyaWMgTm9kZSBBdHRyaWJ1dGUgVExWKSB0byBzaW1wbGlm
eSB0aGluZ3MgYW5kIGEgbmV3DQo+IHNlY3Rpb24gKFNlY3Rpb24gNSkgd2FzIGFkZGVkIHRvIGRl
c2NyaWJlIHNjYWxhYmlsaXR5IGlzc3VlLg0KPiANCj4gTW9yZSBpbmZvcm1hdGlvbiBmcm9tOg0K
PiBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC1j
b25zdHJhaW50cy1vc3BmLXRlLTAyLnR4dA0KPg0KPiAgUGxlYXNlIGNoZWNrIG91dCBmb3IgZGV0
YWlscyBhbmQgY29tbWVudHMgYXJlIGFsd2F5cyB3ZWxjb21lLg0KPiANCj4gDQo+IFRoYW5rcw0K
PiAgDQo+IEZhdGFpDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv
bTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmdd
IE9uIEJlaGFsZiBPZiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj4gU2VudDogMjAxMeW5tDnm
nIgyMuaXpSAxNzowNg0KPiBUbzogaS1kLWFubm91bmNlQGlldGYub3JnDQo+IENjOiBjY2FtcEBp
ZXRmLm9yZw0KPiBTdWJqZWN0OiBbQ0NBTVBdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2NhbXAt
Z21wbHMtZ2VuZXJhbC1jb25zdHJhaW50cy1vc3BmLXRlLTAyLnR4dA0KPiANCj4gQSBOZXcgSW50
ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRz
IGRpcmVjdG9yaWVzLiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBDb21tb24gQ29u
dHJvbCBhbmQgTWVhc3VyZW1lbnQgUGxhbmUgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4NCj4g
DQo+IAlUaXRsZSAgICAgICAgICAgOiBPU1BGLVRFIEV4dGVuc2lvbnMgZm9yIEdlbmVyYWwgTmV0
d29yayBFbGVtZW50IENvbnN0cmFpbnRzDQo+IAlBdXRob3IocykgICAgICAgOiBGYXRhaSBaaGFu
Zw0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIFlvdW5nIExlZQ0KPiAgICAgICAgICAgICAg
ICAgICAgICAgICAgIEppYW5ydWkgSGFuDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgR3Jl
ZyBCZXJuc3RlaW4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICBZdW5iaW4gWHUNCj4gCUZp
bGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC1jb25zdHJhaW50
cy1vc3BmLXRlLTAyLnR4dA0KPiAJUGFnZXMgICAgICAgICAgIDogMTQNCj4gCURhdGUgICAgICAg
ICAgICA6IDIwMTEtMDktMjINCj4gDQo+ICAgIEdlbmVyYWxpemVkIE11bHRpcHJvdG9jb2wgTGFi
ZWwgU3dpdGNoaW5nIGNhbiBiZSB1c2VkIHRvIGNvbnRyb2wgYQ0KPiAgICB3aWRlIHZhcmlldHkg
b2YgdGVjaG5vbG9naWVzIGluY2x1ZGluZyBwYWNrZXQgc3dpdGNoaW5nIChlLmcuLCBNUExTKSwN
Cj4gICAgdGltZS1kaXZpc2lvbiAoZS5nLiwgU09ORVQvU0RILCBPVE4pLCB3YXZlbGVuZ3RoIChs
YW1iZGFzKSwgYW5kDQo+ICAgIHNwYXRpYWwgc3dpdGNoaW5nIChlLmcuLCBpbmNvbWluZyBwb3J0
IG9yIGZpYmVyIHRvIG91dGdvaW5nIHBvcnQgb3INCj4gICAgZmliZXIpLiBJbiBzb21lIG9mIHRo
ZXNlIHRlY2hub2xvZ2llcyBuZXR3b3JrIGVsZW1lbnRzIGFuZCBsaW5rcyBtYXkNCj4gICAgaW1w
b3NlIGFkZGl0aW9uYWwgcm91dGluZyBjb25zdHJhaW50cyBzdWNoIGFzIGFzeW1tZXRyaWMgc3dp
dGNoDQo+ICAgIGNvbm5lY3Rpdml0eSwgbm9uLWxvY2FsIGxhYmVsIGFzc2lnbm1lbnQsIGFuZCBs
YWJlbCByYW5nZSBsaW1pdGF0aW9ucw0KPiAgICBvbiBsaW5rcy4gVGhpcyBkb2N1bWVudCBkZXNj
cmliZXMgT1NQRiByb3V0aW5nIHByb3RvY29sIGV4dGVuc2lvbnMgdG8NCj4gICAgc3VwcG9ydCB0
aGVzZSBraW5kcyBvZiBjb25zdHJhaW50cyB1bmRlciB0aGUgY29udHJvbCBvZiBHZW5lcmFsaXpl
ZA0KPiAgICBNUExTIChHTVBMUykuDQo+IA0KPiANCj4gDQo+IEEgVVJMIGZvciB0aGlzIEludGVy
bmV0LURyYWZ0IGlzOg0KPiBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFm
dC1pZXRmLWNjYW1wLWdtcGxzLWdlbmVyYWwtY29uc3RyYWludHMtb3NwZi10ZS0wMi50eHQNCj4g
DQo+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBh
dDoNCj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gDQo+IFRoaXMgSW50
ZXJuZXQtRHJhZnQgY2FuIGJlIHJldHJpZXZlZCBhdDoNCj4gZnRwOi8vZnRwLmlldGYub3JnL2lu
dGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWdlbmVyYWwtY29uc3RyYWludHMt
b3NwZi10ZS0wMi50eHQNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCj4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+IENDQU1QQGlldGYub3JnDQo+IGh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCj4gX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+
IENDQU1QQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v
Y2NhbXANCg==

From zhangfatai@huawei.com  Sat Sep 24 01:23:46 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A52921F86A1 for ; Sat, 24 Sep 2011 01:23:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.611
X-Spam-Level: 
X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[AWL=-1.216, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2MjaQYY5hH-6 for ; Sat, 24 Sep 2011 01:23:45 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 42BAE21F86A0 for ; Sat, 24 Sep 2011 01:23:44 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS00061SQ3VU7@szxga04-in.huawei.com> for ccamp@ietf.org; Sat, 24 Sep 2011 16:26:19 +0800 (CST)
Received: from szxrg01-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS000M2HQ3PH5@szxga04-in.huawei.com> for ccamp@ietf.org; Sat, 24 Sep 2011 16:26:19 +0800 (CST)
Received: from szxeml208-edg.china.huawei.com ([172.24.2.119]) by szxrg01-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id AED28583; Sat, 24 Sep 2011 16:26:18 +0800
Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml208-edg.china.huawei.com (172.24.2.60) with Microsoft SMTP Server (TLS) id 14.1.270.1; Sat, 24 Sep 2011 16:26:09 +0800
Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.142]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Sat, 24 Sep 2011 16:26:11 +0800
Date: Sat, 24 Sep 2011 08:26:10 +0000
From: Zhangfatai 
In-reply-to: 
X-Originating-IP: [10.70.76.157]
To: "Gruman, Fred" , "ccamp@ietf.org" 
Message-id: 
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_PvVvdEkGRCeoahAN/ysa4A)"
Content-language: en-US
Accept-Language: zh-CN, en-US
Thread-topic: Questions/comments on OTN signaling
Thread-index: Acx5TLK62imqLTNqRbO9SLfzHCpWGgBQ60nA
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: 
Subject: Re: [CCAMP] Questions/comments on OTN signaling
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Sep 2011 08:23:46 -0000

--Boundary_(ID_PvVvdEkGRCeoahAN/ysa4A)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: base64

SGkgRnJlZCwNCg0KVGhhbmtzIGZvciB5b3VyIHVzZWZ1bCBjb21tZW50cyBhbmQgd2Ugd2lsbCBy
ZWZsZWN0IHRoZSBsYXRlc3QgcHJvZ3Jlc3Mgb2YgRy43MDkgaW4gdGhlIG5leHQgdmVyc2lvbi4N
Cg0KUGxlYXNlIHNlZSBtb3JlIGluLWxpbmUgYmVsb3cuDQoNCg0KDQpUaGFua3MNCg0KRmF0YWkN
Cg0KRnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0
Zi5vcmddIE9uIEJlaGFsZiBPZiBHcnVtYW4sIEZyZWQNClNlbnQ6IDIwMTHE6jnUwjIzyNUgMToy
Ng0KVG86IGNjYW1wQGlldGYub3JnDQpTdWJqZWN0OiBbQ0NBTVBdIFF1ZXN0aW9ucy9jb21tZW50
cyBvbiBPVE4gc2lnbmFsaW5nDQoNCkhlbGxvIEZhdGFpLA0KDQpJIGhhdmUgc29tZSBjb21tZW50
cy9xdWVzdGlvbnMgb24gZHJhZnQtemhhbmctY2NhbXAtZ21wbHMtZXZvbHZpbmctZzcwOS0wOS4N
Cg0KMSkgSSB0aGluayB0aGUgZHJhZnQgc2hvdWxkIGRpc2N1c3MgdGhlIEdlbmVyYWxpemVkIExh
YmVsIFJlcXVlc3Qgb2JqZWN0LiAgV2lsbCB0aGlzIG9iamVjdCB1c2UgdGhlIG5ldyBPVE4gc3dp
dGNoaW5nIGNhcGFiaWxpdHkgKFN3aXRjaGluZyBUeXBlID0gMTAxKT8NCg0KW0ZhdGFpXSBZZXMs
IGFncmVlIHdpdGggeW91LiBXZSBoYXZlIGNhcHR1cmVkIHRoaXMgaW4gdGhlIEZXSyBkb2N1bWVu
dCBhbmQgd2lsbCB1cGRhdGUgdGhlIHNpZ25hbGluZyBkcmFmdCBpbiB0aGUgbmV4dCB2ZXJzaW9u
Lg0KDQoyKSAgSG93IGlzIE9EVWZsZXgoR0ZQKSBzaWduYWxlZD8gSW4gZ2VuZXJhbCwgdGhlIGRy
YWZ0IHNlZW1zIHRvIGxhY2sgZGV0YWlsIG9uIE9EVWZsZXgoR0ZQKS4NCg0KTW9yZSBzcGVjaWZp
Y2FsbHksIHRoZSBkcmFmdCBzdGF0ZXMgIkluIGNhc2Ugb2YgT0RVZmxleChDQlIpLCB0aGUgQml0
X1JhdGUgYW5kIFRvbGVyYW5jZSBmaWVsZHMgTVVTVCBiZSB1c2VkIHRvZ2V0aGVyIHRvIHJlcHJl
c2VudCB0aGUgYWN0dWFsIGJhbmR3aWR0aCBvZiBPRFVmbGV4IiBhbmQgbGF0ZXIgIkluIGNhc2Ug
b2Ygb3RoZXIgT0RVayBzaWduYWwgdHlwZXMsIHRoZSBCaXRfUmF0ZSBhbmQgVG9sZXJhbmNlIGZp
ZWxkcyBhcmUgbm90IG5lY2Vzc2FyeSBhbmQgTVVTVCBiZSBzZXQgdG8gMC4iICBJdCBpcyBub3Qg
Y2xlYXIgaWYgdGhpcyBpbXBsaWVzIHRoYXQgT0RVZmxleChHRlApIHNob3VsZCBzZXQgQml0X3Jh
dGUgYW5kIFRvbGVyYW5jZSB0byB6ZXJvLiAgSSB3b3VsZCBhc3N1bWUgT0RVZmxleChHRlApIHdv
dWxkIG5lZWQgQml0X1JhdGUsIGJ1dCB1bnN1cmUgaWYgdG9sZXJhbmNlIGlzIG5lZWRlZC4NCg0K
W0ZhdGFpXSBUaGUgYml0IHJhdGVzIGFuZCB0b2xlcmFuY2Ugb2YgT0RVZmxleChHRlApIHdhcyBu
b3Qgc3RhbmRhcmRpemVkIHVudGlsIHRoZSBHLjcwOSBBbWQyIHdhcyBpc3N1ZWQsIHNvIHdlIGRp
ZG6hr3QgdG91Y2ggaXQgaW4gdGhpcyBkcmFmdCBzbyBmYXIuDQpJbiB0aGUgRy43MDkgQW1kMiwg
aXQgc2F5czogobBBbnkgYml0IHJhdGUgaXMgcG9zc2libGUgZm9yIGFuIE9EVWZsZXgoR0ZQKSBz
aWduYWwsIGhvd2V2ZXIgaXQgaXMgc3VnZ2VzdGVkIGZvciBtYXhpbXVtIGVmZmljaWVuY3kgdGhh
dCB0aGUgT0RVZmxleChHRlApIHdpbGwgZmlsbCBhbiBpbnRlZ3JhbCBudW1iZXIgb2YgdHJpYnV0
YXJ5IHNsb3RzIG9mIHRoZSBzbWFsbGVzdCBITyBPRFVrIHBhdGggb3ZlciB3aGljaCB0aGUgT0RV
ZmxleChHRlApIG1heSBiZSBjYXJyaWVkLiBUaGUgcmVjb21tZW5kZWQgYml0LXJhdGVzIHRvIG1l
ZXQgdGhpcyBjcml0ZXJpYSBhcmUgc3BlY2lmaWVkIGluIFRhYmxlIDctOC6hsQ0KDQpXZSBjYW4g
dW5kZXJzdGFuZCB0aGF0IE9OTFkgODAgdmFsdWVzIGFyZSBhbGxvd2VkICBhbmQgdGhlIGludGVy
bWVkaWF0ZSB2YWx1ZXMgYXJlIG5vdCBhbGxvd2VkIChzZWUgVGFibGUgNy04IGluIEcuNzA5IEFt
ZDIpLiBFYWNoIG9mIHRoZSA4MCB2YWx1ZXMgaXMgcmlnaWRseSBhc3NvY2lhdGVkIHRvIGEgbnVt
YmVyIG9mIHRyaWJ1dGFyeSBzbG90cyBhbmQgdGhhdCB0aGUgdG9sZXJhbmNlIGlzIGZpeGVkIHRv
ICsvLSAxMDBwcG0uIE5vdGUgdGhhdCB0aGUgdG9sZXJhbmNlIGlzIGFscmVhZHkgY29tcHJpc2Vk
IGluIHRoZSA4MCB2YWx1ZXMuDQoNClNvLCB3ZSBhZ3JlZSB3aXRoIHlvdSB0aGF0IE9EVWZsZXgo
R0ZQKSB3b3VsZCBuZWVkIEJpcl9SYXRlLCBidXQgaXQgZG9lcyBub3QgbmVlZCB0b2xlcmFuY2Uu
DQoNCldlIHdpbGwgYWRkIHNvbWUgdGV4dCB0byBhZGRyZXNzIE9EVWZsZXgoR0ZQKS4NCg0KMykg
Ry43MDkgQW1lbmRtZW50IDIgKDIwMTEtMDQpIFRhYmxlIDctOSBoYXMgYSByb3cgdG8gY292ZXIg
dGhlIGdlbmVyaWMgT0RVZmxleChDQlIpIHdpdGggbm90ZXMgdG8gdGhlIGZvcm11bGFzIHRvIGNh
bGN1bGF0ZSB0aGUgbnVtYmVyIG9mIHRyaWJ1dGFyeSBzbG90cy4gIEFkZGl0aW9uYWxseSwgdGhp
cyB0YWJsZSBoYXMgc3BlY2lmaWMgcm93cyB0byBjb3ZlciBPRFVmbGV4KENCUikgSUIgU0RSLCBJ
QiBERFIsIElCIFFEUiwgRkMtNDAwLCBhbmQgRkMtODAwIGFuZCBzcGVjaWZpZXMgdGhlIGV4cGxp
Y2l0IG51bWJlciBvZiB0cmlidXRhcnkgc2xvdCBhc3NpZ25tZW50cyB3aGVuIG1hcHBlZCBpbnRv
IE9EVWZsZXggaW50byBITy1PUFVrKS4NCg0KSXQgc2VlbXMgdGhhdCB0aGUgZ2VuZXJpYyBmb3Jt
dWxhIGZvciBPRFVmbGV4KENCUikgZG9lcyBub3QgcmVzdWx0IGluIHRoZSBzYW1lIG51bWJlciBv
ZiB0cmlidXRhcnkgc2xvdHMgZm9yIHNvbWUgb2YgdGhlc2UgY2xpZW50IHNpZ25hbHMuICBGb3Ig
ZXhhbXBsZSwgSUIgU0RSIG92ZXIgSE8tT1BVMyBoYXMgbm9taW5hbCBiaXQgcmF0ZSBvZiAyLDUw
MCwwMDAga2JpdHMvcyBhbmQgYml0IHJhdGUgdG9sZXJhbmNlIG9mICsvLTEwMHBwbSAoZnJvbSBH
LjcwOSBBbWVuZDIgVGFibGUgMTctMTQpLiAgVXNpbmcgdGhlIGdlbmVyaWMgT0RVZmxleChDQlIp
IGZvcm11bGEsIHlvdSBnZXQ6DQoNCk4gPSBjZWlsaW5nIFsoMjUwMDAwMCAqICgxKzEwMC8xZTYp
KSAvICggMTI1NDcwMy43MjkgKiAoMS0yMC8xZTYpKSBdDQogICAgPSBjZWlsaW5nIFsyNTAwMjUw
IC8gMTI1NDY3OC42MzVdDQogICAgPSBjZWlsaW5nIFsxLjk5Mjc0MTM1XQ0KICAgID0gMg0KDQpU
YWJsZSA3LTkgc2hvd3MgdGhhdCBJQiBTRFIgbWFwcGVkIGludG8gT0RVZmxleCBvdmVyIEhPLU9Q
VTMgd291bGQgdXNlIDMgdHJpYnV0YXJ5IHNsb3RzLCBub3QgMi4NCg0KUGxlYXNlIHZlcmlmeSBt
eSBtYXRoIGJ1dCBpZiB0aGUgZ2VuZXJpYyBPRFVmbGV4IGZvcm11bGEgZG9lcyBub3QgYXBwbHkg
dG8gdGhlIElCIG9yIEZDIGNsaWVudHMsIHRoZW4gd2UgbWF5IG5lZWQgdG8gaGF2ZSBleHBsaWNp
dCBzaWduYWwgdHlwZXMgZm9yIHRoZXNlIGNsaWVudHMuDQoNCkkgZm91bmQgdGhhdCB0aGUgSUIg
Y2xpZW50cyBkbyBub3QgbWF0Y2ggdGhlIGdlbmVyaWMgZm9ybXVsYSBmb3Igc29tZSBITy1PUFVr
IGJ1dCB0aGUgRkMgY2xpZW50cyBkbyBtYXRjaC4gIFRoaXMgbWF5IG1lYW4gd2Ugb25seSB3b3Vs
ZCBuZWVkIGV4cGxpY2l0IHNpZ25hbCB0eXBlcyBmb3I6DQotIE9EVWZsZXgoQ0JSKS1JQi1TRFIN
Ci0gT0RVZmxleChDQlIpLUlCLUREUg0KLSBPRFVmbGV4KENCUiktSUItUURSDQoNCltGYXRhaV0g
IElmIHlvdSBhbHNvIHRha2UgaW50byBhY2NvdW50IHRoZSBUcmFuc2NvZGluZyBGYWN0b3IgZGVz
Y3JpYmVkIGluIEcuNzA5IGFuZCBhc3NvY2lhdGVkIHRvIDhCLzEwQiBhbmQgNjRCLzY1QiwgeW91
IHdpbGwgZmluZCB0aGUgbnVtYmVyIG9mIHRyaWJ1dGFyeSBzbG90IGlzIGNvcnJlY3QgZm9yIHlv
dXIgZXhhbXBsZS4NCg0KVGhlIGZvcm11bGFzIGRlc2NyaWJlZCBpbiBUYWJsZSA3LTkgb2YgRy43
MDlWMygxMi8yMDA5KSBhcmUgYXMgZm9sbG93czoNCk51bWJlciBvZiB0cmlidXRhcnkgc2xvdHMg
PSBDZWlsaW5nKE9EVWZsZXgoQ0JSKSBub21pbmFsIGJpdCByYXRlLyhUocFPRFRVMi50cyBub21p
bmFsIGJpdCByYXRlKSChwSAoMStPRFVmbGV4KENCUikgYml0IHJhdGUgdG9sZXJhbmNlKS8oMS1I
TyBPUFUyIGJpdCByYXRlIHRvbGVyYW5jZSkpLg0KTnVtYmVyIG9mIHRyaWJ1dGFyeSBzbG90cyA9
IENlaWxpbmcoT0RVZmxleChDQlIpIG5vbWluYWwgYml0IHJhdGUvKFShwU9EVFUzLnRzIG5vbWlu
YWwgYml0IHJhdGUpIKHBICgxK09EVWZsZXgoQ0JSKSBiaXQgcmF0ZSB0b2xlcmFuY2UpLygxLUhP
IE9QVTMgYml0IHJhdGUgdG9sZXJhbmNlKSkuDQpOdW1iZXIgb2YgdHJpYnV0YXJ5IHNsb3RzID0g
Q2VpbGluZyhPRFVmbGV4KENCUikgbm9taW5hbCBiaXQgcmF0ZS8oVKHBT0RUVTQudHMgbm9taW5h
bCBiaXQgcmF0ZSkgocEgKDErT0RVZmxleChDQlIpIGJpdCByYXRlIHRvbGVyYW5jZSkvKDEtSE8g
T1BVNCBiaXQgcmF0ZSB0b2xlcmFuY2UpKS4NCg0KV0lUSCBUIHNwZWNpZmllZCBhcyBmb2xsb3dz
Og0KDQpUPTE2LzE1IGZvciA4Qi8xMEIgZW5jb2RlZCBDQlIgY2xpZW50cywgVD0xMDI3LzEwMjQg
Zm9yIDY0Qi82NkIgZW5jb2RlZCBDQlIgY2xpZW50cyBhbmQgVD0xIGZvciBvdGhlciBjbGllbnRz
DQoNCldlIHdpbGwgdXBkYXRlIHRoaXMgZHJhZnQgd2l0aCB0aGlzIGZvcm11bGE6DQoNCk51bWJl
ciBvZiB0cmlidXRhcnkgc2xvdHMgPSBDZWlsaW5nKE9EVWZsZXgoQ0JSKSBub21pbmFsIGJpdCBy
YXRlLyhUocFPRFRVai50cyBub21pbmFsIGJpdCByYXRlKSChwSAoMStPRFVmbGV4KENCUikgYml0
IHJhdGUgdG9sZXJhbmNlKS8oMS1ITyBPUFVqIGJpdCByYXRlIHRvbGVyYW5jZSkpLg0KDQpJbnNl
cnRpbmcgYWxzbyB0aGUgbWVhbmluZyBvZiBULg0KDQpTbywgd2UgZG9uoa90IG5lZWQgdG8gaW50
cm9kdWNlIHRoZSBuZXcgc2lnbmFsIHR5cGVzLCB3ZSBqdXN0IG5lZWQgdG8gdXNlIHRoZSB1cGRh
dGVkIGZvcm11bGEuDQoNClBsZWFzZSBsZXQgbWUga25vdyB3aGF0IHlvdSB0aGluay4NCg0KVGhh
bmtzLA0KRnJlZA0K

--Boundary_(ID_PvVvdEkGRCeoahAN/ysa4A)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: quoted-printable











Hi F=
red,


 


Thanks for your usefu=
l comments and we will reflect the latest progress of G.709 in the next ver=
sion.



 


Please see more in-li=
ne below.=





 


 


 


Thanks

 

Fatai




 






From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org=
]
On Behalf Of Gruman, Fred

Sent: 2011=C4=EA9=D4=C223=C8=
=D5
 1:26

To: ccamp@ietf.org

Subject: [CCAMP] Questions/comments on OTN signaling






 


Hello Fatai,<=
/p>

 


I have some comments/questions =
on draft-zhang-ccamp-gmpls-evolving-g709-09.


 


1) I think the draft should dis=
cuss the Generalized Label Request object.  Will this object use the n=
ew OTN switching capability (Switching Type =3D 101)?


 


[Fatai] Yes, agree with you. We have captured this in the FWK docume=
nt and will update the signaling draft in the next version.


 


2)  How is ODUflex(GFP) si=
gnaled? In general, the draft seems to lack detail on ODUflex(GFP).


 


More specifically, the draft st=
ates "In case of ODUflex(CBR), the Bit_Rate and Tolerance fields MUST =
be used together to represent the actual bandwidth of ODUflex" and lat=
er "In case of other ODUk signal types, the Bit_Rate
 and Tolerance fields are not necessary and MUST be set to 0."  I=
t is not clear if this implies that ODUflex(GFP) should set Bit_rate and To=
lerance to zero.  I would assume ODUflex(GFP) would need Bit_Rate, but=
 unsure if tolerance is needed.


 


[Fatai] The bit rates and tolerance of ODUflex(GFP) was not standard=
ized until the G.709 Amd2 was issued, so we didn=A1=AFt touch it in this dr=
aft so far. 



In the G.709 Amd2, it says: =A1=B0Any=
 bit rate is possible for an ODUflex(GFP) signal, however it is suggested f=
or maximum efficiency that the ODUflex(GFP) will
 fill an integral number of tributary slots of the smallest HO ODUk path ov=
er which the ODUflex(GFP) may be carried. The recommended bit-rates to meet=
 this criteria are specified in Table 7-8.<=
/span>=A1=B1<=
o:p>


 


We can understand that ONLY 80 values are allowed  and the inte=
rmediate values are not allowed (see Table 7-8 in G.709 Amd2). Each of the =
80 values is rigidly associated to a number
 of tributary slots and that the tolerance is fixed to +/- 100ppm. Note=
 that the tolerance is already comprised in the 80 values.


 


So, we agree with you that ODUflex(GFP) would need Bir_Rate, but it =
does not need tolerance.


 


We will add some text to address ODUflex(GFP).


 


3) G.709 Amendment 2 (2011-04) =
Table 7-9 has a row to cover the generic ODUflex(CBR) with notes to the for=
mulas to calculate the number of tributary slots.  Additionally, this =
table has specific rows to cover ODUflex(CBR)
 IB SDR, IB DDR, IB QDR, FC-400, and FC-800 and specifies the explicit numb=
er of tributary slot assignments when mapped into ODUflex into HO-OPUk). &n=
bsp; 


 


It seems that the generic formu=
la for ODUflex(CBR) does not result in the same number of tributary slots f=
or some of these client signals.  For example, IB SDR over HO-OPU3 has=
 nominal bit rate of 2,500,000 kbits/s and
 bit rate tolerance of +/-100ppm (from G.709 Amend2 Table 17-14). =
 Using the generic ODUflex(CBR) formula, you get:


 


N =3D ceiling [(2500000 * (1=
3;100/1e6)) / ( 1254703.729 * (1-20/1e6)) ]


    =3D ceiling =
[2500250 / 1254678.635]


    =3D ceiling =
[1.99274135]


    =3D 2


  


Table 7-9 shows that IB SDR map=
ped into ODUflex over HO-OPU3 would use 3 tributary slots, not 2.


 


Please verify my math but if th=
e generic ODUflex formula does not apply to the IB or FC clients, then we m=
ay need to have explicit signal types for these clients.<=
/p>

 


I found that the IB clients do =
not match the generic formula for some HO-OPUk but the FC clients do match.=
  This may mean we only would need explicit signal types for:


- ODUflex(CBR)-IB-SDR


- ODUflex(CBR)-IB-DDR


- ODUflex(CBR)-IB-QDR


 


[Fatai]  If you also take into account the Transcoding Factor d=
escribed in G.709 and associated to 8B/10B and 64B/65B, you will find the n=
umber of tributary slot is correct for your
 example.


 


The formulas described in Table 7-9 of G.709V3(12/2009) are as follo=
ws:


Number of tributary slots =3D Ceiling(=
ODUflex(CBR) nominal bit rate/(T=A1=C1ODTU2.ts
 nominal bit rate) =A1=C1 (1+ODUflex(CBR) bit rate tolerance)/(1-HO OPU=
2 bit rate tolerance)).


Number of tributary slots =3D Ceiling(=
ODUflex(CBR) nominal bit rate/(T=A1=C1ODTU3.ts
 nominal bit rate) =A1=C1 (1+ODUflex(CBR) bit rate tolerance)/(1-HO OPU=
3 bit rate tolerance)).


Number of tributary slots =3D Ceiling(=
ODUflex(CBR) nominal bit rate/(T=A1=C1ODTU4.ts
 nominal bit rate) =A1=C1 (1+ODUflex(CBR) bit rate tolerance)/(1-HO OPU=
4 bit rate tolerance)).


 


WITH T specified as follows:


 


T=3D16/15 for 8B/10B encoded CBR clien=
ts, T=3D1027/1024 for 64B/66B encoded CBR clients and T=3D1 for other clien=
ts


 


We will update this draft with this formula:


 


Number of tributary slots =3D Ceiling(=
ODUflex(CBR) nominal bit rate/(T=A1=C1ODTUj.ts
 nominal bit rate) =A1=C1 (1+ODUflex(CBR) bit rate tolerance)/(1-HO OPU=
j bit rate tolerance)).


 


Inserting also the meaning of T.


 


So, we don=A1=AFt need to introduce the new signal types, we just ne=
ed to use the updated formula.


 


Please let me know what you thi=
nk.


 


Thanks,


Fred






--Boundary_(ID_PvVvdEkGRCeoahAN/ysa4A)--

From fred.gruman@us.fujitsu.com  Sat Sep 24 05:15:28 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00A4A21F8AF9 for ; Sat, 24 Sep 2011 05:15:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.598
X-Spam-Level: 
X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 56yaheD8U-yV for ; Sat, 24 Sep 2011 05:15:26 -0700 (PDT)
Received: from fncnmp04.fnc.fujitsu.com (fncnmp04.fnc.fujitsu.com [168.127.0.57]) by ietfa.amsl.com (Postfix) with ESMTP id 8D00A21F84AB for ; Sat, 24 Sep 2011 05:15:26 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.68,435,1312174800";  d="scan'208,217";a="479203788"
Received: from rchemxp01.fnc.net.local ([168.127.134.111]) by fncnmp02.fnc.fujitsu.com with ESMTP; 24 Sep 2011 07:18:02 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC7AB4.017E14CA"
Date: Sat, 24 Sep 2011 07:17:59 -0500
Message-ID: 
In-Reply-To: A
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Questions/comments on OTN signaling
Thread-Index: Acx5TLK62imqLTNqRbO9SLfzHCpWGgBQ60nAAAfOoIA=
References:  A
From: "Gruman, Fred" 
To: "Zhangfatai" , 
Subject: Re: [CCAMP] Questions/comments on OTN signaling
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Sep 2011 12:15:28 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC7AB4.017E14CA
Content-Type: text/plain;
	charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit

Hello Fatai,

 

Thank you for your response on these items

 

On item #3, I found the error in my calculation.  The problem was not with the transcoding factor (as T>=1 and in the denominator, it would actually only tend to reduce the number of TS required).

 

I was using the client bit rate for IB in the formula instead of the ODUflex bit rate.  The ODUflex bit rate should be 239/238 x client bit rate.  Taking account this factor results in the correct number of TS per G.709 Table 7-9.

 

I apologize for the confusion.

 

Regards,

Fred

 

 

 

 

 

From: Zhangfatai [mailto:zhangfatai@huawei.com] 
Sent: Saturday, September 24, 2011 3:26 AM
To: Gruman, Fred; ccamp@ietf.org
Subject: RE: Questions/comments on OTN signaling

 

Hi Fred,

 

Thanks for your useful comments and we will reflect the latest progress of G.709 in the next version. 

 

Please see more in-line below.

 

 

 

Thanks
 
Fatai

 

From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Gruman, Fred
Sent: 2011$BG/(J9$B7n(J23$BF|(J 1:26
To: ccamp@ietf.org
Subject: [CCAMP] Questions/comments on OTN signaling

 

Hello Fatai,

 

I have some comments/questions on draft-zhang-ccamp-gmpls-evolving-g709-09.

 

1) I think the draft should discuss the Generalized Label Request object.  Will this object use the new OTN switching capability (Switching Type = 101)?

 

[Fatai] Yes, agree with you. We have captured this in the FWK document and will update the signaling draft in the next version.

 

2)  How is ODUflex(GFP) signaled? In general, the draft seems to lack detail on ODUflex(GFP).

 

More specifically, the draft states "In case of ODUflex(CBR), the Bit_Rate and Tolerance fields MUST be used together to represent the actual bandwidth of ODUflex" and later "In case of other ODUk signal types, the Bit_Rate and Tolerance fields are not necessary and MUST be set to 0."  It is not clear if this implies that ODUflex(GFP) should set Bit_rate and Tolerance to zero.  I would assume ODUflex(GFP) would need Bit_Rate, but unsure if tolerance is needed.

 

[Fatai] The bit rates and tolerance of ODUflex(GFP) was not standardized until the G.709 Amd2 was issued, so we didn$B!G(Jt touch it in this draft so far.  

In the G.709 Amd2, it says: $B!H(JAny bit rate is possible for an ODUflex(GFP) signal, however it is suggested for maximum efficiency that the ODUflex(GFP) will fill an integral number of tributary slots of the smallest HO ODUk path over which the ODUflex(GFP) may be carried. The recommended bit-rates to meet this criteria are specified in Table 7-8.$B!I(J

 

We can understand that ONLY 80 values are allowed  and the intermediate values are not allowed (see Table 7-8 in G.709 Amd2). Each of the 80 values is rigidly associated to a number of tributary slots and that the tolerance is fixed to +/- 100ppm. Note that the tolerance is already comprised in the 80 values.

 

So, we agree with you that ODUflex(GFP) would need Bir_Rate, but it does not need tolerance.

 

We will add some text to address ODUflex(GFP).

 

3) G.709 Amendment 2 (2011-04) Table 7-9 has a row to cover the generic ODUflex(CBR) with notes to the formulas to calculate the number of tributary slots.  Additionally, this table has specific rows to cover ODUflex(CBR) IB SDR, IB DDR, IB QDR, FC-400, and FC-800 and specifies the explicit number of tributary slot assignments when mapped into ODUflex into HO-OPUk).   

 

It seems that the generic formula for ODUflex(CBR) does not result in the same number of tributary slots for some of these client signals.  For example, IB SDR over HO-OPU3 has nominal bit rate of 2,500,000 kbits/s and bit rate tolerance of +/-100ppm (from G.709 Amend2 Table 17-14).  Using the generic ODUflex(CBR) formula, you get:

 

N = ceiling [(2500000 * (1+100/1e6)) / ( 1254703.729 * (1-20/1e6)) ]

    = ceiling [2500250 / 1254678.635]

    = ceiling [1.99274135]

    = 2

  

Table 7-9 shows that IB SDR mapped into ODUflex over HO-OPU3 would use 3 tributary slots, not 2.

 

Please verify my math but if the generic ODUflex formula does not apply to the IB or FC clients, then we may need to have explicit signal types for these clients.

 

I found that the IB clients do not match the generic formula for some HO-OPUk but the FC clients do match.  This may mean we only would need explicit signal types for:

- ODUflex(CBR)-IB-SDR

- ODUflex(CBR)-IB-DDR

- ODUflex(CBR)-IB-QDR

 

[Fatai]  If you also take into account the Transcoding Factor described in G.709 and associated to 8B/10B and 64B/65B, you will find the number of tributary slot is correct for your example.

 

The formulas described in Table 7-9 of G.709V3(12/2009) are as follows:

Number of tributary slots = Ceiling(ODUflex(CBR) nominal bit rate/(T$B!_(JODTU2.ts nominal bit rate) $B!_(J (1+ODUflex(CBR) bit rate tolerance)/(1-HO OPU2 bit rate tolerance)).

Number of tributary slots = Ceiling(ODUflex(CBR) nominal bit rate/(T$B!_(JODTU3.ts nominal bit rate) $B!_(J (1+ODUflex(CBR) bit rate tolerance)/(1-HO OPU3 bit rate tolerance)).

Number of tributary slots = Ceiling(ODUflex(CBR) nominal bit rate/(T$B!_(JODTU4.ts nominal bit rate) $B!_(J (1+ODUflex(CBR) bit rate tolerance)/(1-HO OPU4 bit rate tolerance)).

 

WITH T specified as follows:

 

T=16/15 for 8B/10B encoded CBR clients, T=1027/1024 for 64B/66B encoded CBR clients and T=1 for other clients

 

We will update this draft with this formula:

 

Number of tributary slots = Ceiling(ODUflex(CBR) nominal bit rate/(T$B!_(JODTUj.ts nominal bit rate) $B!_(J (1+ODUflex(CBR) bit rate tolerance)/(1-HO OPUj bit rate tolerance)).

 

Inserting also the meaning of T.

 

So, we don$B!G(Jt need to introduce the new signal types, we just need to use the updated formula.

 

Please let me know what you think.

 

Thanks,

Fred


------_=_NextPart_001_01CC7AB4.017E14CA
Content-Type: text/html;
	charset="iso-2022-jp"
Content-Transfer-Encoding: 7bit
















Hello Fatai,



 



Thank you for your response on
these items



 



On item #3, I found the error in
my calculation.  The problem was not with the transcoding factor (as
T>=1 and in the denominator, it would actually only tend to reduce the
number of TS required).



 



I was using the client bit rate
for IB in the formula instead of the ODUflex bit rate.  The ODUflex bit
rate should be 239/238 x client bit rate.  Taking account this factor
results in the correct number of TS per G.709 Table 7-9.



 



I apologize for the confusion.



 



Regards,



Fred



 



 



 



 



 









From: Zhangfatai
[mailto:zhangfatai@huawei.com] 

Sent: Saturday, September 24, 2011 3:26 AM

To: Gruman, Fred; ccamp@ietf.org

Subject: RE: Questions/comments on OTN signaling









 



Hi Fred,



 



Thanks for your useful comments and we will reflect
the latest progress of G.709 in the next version. 



 



Please see more in-line below.






 



 



 



Thanks

 

Fatai






 









From:
ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Gruman,
Fred

Sent: 2011$BG/(B9$B7n(B23$BF|(B 1:26

To: ccamp@ietf.org

Subject: [CCAMP] Questions/comments on OTN signaling









 



Hello Fatai,



 



I have some comments/questions on
draft-zhang-ccamp-gmpls-evolving-g709-09.



 



1) I think the draft should discuss the Generalized Label
Request object.  Will this object use the new OTN switching capability
(Switching Type = 101)?



 



[Fatai] Yes, agree
with you. We have captured this in the FWK document and will update the
signaling draft in the next version.



 



2)  How is ODUflex(GFP) signaled? In general, the draft
seems to lack detail on ODUflex(GFP).



 



More specifically, the draft states "In case of
ODUflex(CBR), the Bit_Rate and Tolerance fields MUST be used together to
represent the actual bandwidth of ODUflex" and later "In case of
other ODUk signal types, the Bit_Rate and Tolerance fields are not necessary
and MUST be set to 0."  It is not clear if this implies that
ODUflex(GFP) should set Bit_rate and Tolerance to zero.  I would assume
ODUflex(GFP) would need Bit_Rate, but unsure if tolerance is needed.



 



[Fatai] The bit
rates and tolerance of ODUflex(GFP) was not standardized until the G.709 Amd2
was issued, so we didn$B!G(Bt touch it in this draft so far.  



In the G.709 Amd2,
it says: $B!H(BAny bit rate is possible for an ODUflex(GFP) signal,
however it is suggested for maximum efficiency that the ODUflex(GFP) will fill
an integral number of tributary slots of the smallest HO ODUk path over which
the ODUflex(GFP) may be carried. The recommended bit-rates to meet this
criteria are specified in Table 7-8.$B!I(B



 



We can understand
that ONLY 80 values are allowed  and the intermediate values are not
allowed (see Table 7-8 in G.709 Amd2). Each of the 80 values is rigidly
associated to a number of tributary slots and that the tolerance is fixed to
+/- 100ppm. Note that the tolerance is already comprised in the 80 values.



 



So, we agree with
you that ODUflex(GFP) would need Bir_Rate, but it does not need tolerance.



 



We will add some
text to address ODUflex(GFP).



 



3) G.709 Amendment 2 (2011-04) Table 7-9 has a row to cover
the generic ODUflex(CBR) with notes to the formulas to calculate the number of
tributary slots.  Additionally, this table has specific rows to cover
ODUflex(CBR) IB SDR, IB DDR, IB QDR, FC-400, and FC-800 and specifies the
explicit number of tributary slot assignments when mapped into ODUflex into
HO-OPUk).   



 



It seems that the generic formula for ODUflex(CBR) does not
result in the same number of tributary slots for some of these client
signals.  For example, IB SDR over HO-OPU3 has nominal bit rate of
2,500,000 kbits/s and bit rate tolerance of +/-100ppm (from G.709 Amend2 Table
17-14).  Using the generic ODUflex(CBR) formula, you get:



 



N = ceiling [(2500000 * (1+100/1e6)) / ( 1254703.729 * (1-20/1e6))
]



    = ceiling [2500250 / 1254678.635]



    = ceiling [1.99274135]



    = 2



  



Table 7-9 shows that IB SDR mapped into ODUflex over HO-OPU3
would use 3 tributary slots, not 2.



 



Please verify my math but if the generic ODUflex formula
does not apply to the IB or FC clients, then we may need to have explicit
signal types for these clients.



 



I found that the IB clients do not match the generic formula
for some HO-OPUk but the FC clients do match.  This may mean we only would
need explicit signal types for:



- ODUflex(CBR)-IB-SDR



- ODUflex(CBR)-IB-DDR



- ODUflex(CBR)-IB-QDR



 



[Fatai]  If
you also take into account the Transcoding Factor described in G.709 and
associated to 8B/10B and 64B/65B, you will find the number of tributary slot is
correct for your example.



 



The formulas
described in Table 7-9 of G.709V3(12/2009) are as follows:



Number of tributary slots = Ceiling(ODUflex(CBR) nominal bit
rate/(T$B!_(BODTU2.ts nominal bit rate) $B!_(B
(1+ODUflex(CBR) bit rate tolerance)/(1-HO OPU2 bit rate tolerance)).



Number of tributary slots = Ceiling(ODUflex(CBR) nominal bit
rate/(T$B!_(BODTU3.ts nominal bit rate) $B!_(B
(1+ODUflex(CBR) bit rate tolerance)/(1-HO OPU3 bit rate tolerance)).



Number of tributary slots = Ceiling(ODUflex(CBR) nominal bit
rate/(T$B!_(BODTU4.ts nominal bit rate) $B!_(B (1+ODUflex(CBR)
bit rate tolerance)/(1-HO OPU4 bit rate tolerance)).



 



WITH T specified as follows:



 



T=16/15 for 8B/10B encoded CBR clients, T=1027/1024 for 64B/66B
encoded CBR clients and T=1 for other clients



 



We will update
this draft with this formula:



 



Number of tributary slots = Ceiling(ODUflex(CBR) nominal bit
rate/(T$B!_(BODTUj.ts nominal bit rate) $B!_(B
(1+ODUflex(CBR) bit rate tolerance)/(1-HO OPUj bit rate tolerance)).



 



Inserting also the
meaning of T.



 



So, we don$B!G(Bt need
to introduce the new signal types, we just need to use the updated formula.



 



Please let me know what you think.



 



Thanks,



Fred









------_=_NextPart_001_01CC7AB4.017E14CA--

From lberger@labn.net  Sat Sep 24 08:08:27 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42A421F8A67 for ; Sat, 24 Sep 2011 08:08:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.875
X-Spam-Level: 
X-Spam-Status: No, score=-100.875 tagged_above=-999 required=5 tests=[AWL=-0.714, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bv6fjkQHmGm for ; Sat, 24 Sep 2011 08:08:27 -0700 (PDT)
Received: from oproxy5-pub.bluehost.com (oproxy5.bluehost.com [IPv6:2605:dc00:100:2::a5]) by ietfa.amsl.com (Postfix) with SMTP id 2005021F8A64 for ; Sat, 24 Sep 2011 08:08:27 -0700 (PDT)
Received: (qmail 29237 invoked by uid 0); 24 Sep 2011 15:11:03 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy2.bluehost.com with SMTP; 24 Sep 2011 15:11:03 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default;  h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=hwqy1XmNnWfjWDsKfMq+d5G2E46+ckbKxO86HYAgLgs=;  b=rH2k+Kr8cRUWdLzucQdPBC/As9veUJNjK4bIvfzznHp57e7gFDTD1wdys9XXsNZrGYziUZboWI2B/+NBmL/Za0hcH668OJwUXMeA/QYkdLx90GJFIp/QyoF5fDoDbaec;
Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1R7Tsd-0000G3-0w; Sat, 24 Sep 2011 09:11:03 -0600
Message-ID: <4E7DF30A.70806@labn.net>
Date: Sat, 24 Sep 2011 11:11:06 -0400
From: Lou Berger 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Zhangfatai 
References: <20110922090626.6373.58763.idtracker@ietfa.amsl.com>  <4E7C7021.9010806@labn.net> 
In-Reply-To: 
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Sep 2011 15:08:28 -0000

Fatai,



On 9/23/2011 9:06 PM, Zhangfatai wrote:
> Hi Lou,
> 
> Thanks for your suggestions.
> 
> For point 1, We would like to examine the document again to see which
> portions can be truly generic. I am not sure that I got the meaning
> of the sentence: " Clearly this isn't possible in all cases, but
> should be in others, e.g., the section on scaling."  Did you mean
> that the section on scaling is not truly generic? Could you explain
> more?
>

opps, that should have read "e.g., Available Labels section".  The
standards section was supposed to be the example for the second point.

Looking at Section 3.2., the WSON related text in the section really
should be generalized to be technology agnostic. I also don't see why
the WSON label format is included in this document.  (If anything, it
can be included in the GEN-Encoding document as in an example of how to
encode a bitmap label set.)

Lou

> For this point, we also like to see the comments from the WG.
> 
> For point 2, agree with you. We will update this draft in the next
> version based on your suggestion.
> 
> 
> 
> 
> 
> Thanks
>  
> Fatai
> 
> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net] 
> Sent: 2011年9月23日 19:40
> To: Zhangfatai
> Cc: ccamp@ietf.org
> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt
> 
> Fatai/Authors,
> 
> A couple of suggestions on the document:
> 
> 1- I suggest taking another pass through the document to see
>    which portions can be made truly generic, and to use WSON
>    only as an example or specific case.  Clearly this isn't
>    possible in all cases, but should be in others, e.g., the
>    section on scaling.
> 
> 2- While narrative/informative language is important to have,
>    it's the normative language that is the main point of a
>    standards track document. I suggest reviewing the document
>    to ensure that the document has RFC2119 conformance language
>    covering any definition related to behavior on the wire.
> 
> Much thanks,
> 
> Lou
> 
> On 9/22/2011 5:17 AM, Zhangfatai wrote:
>> Hi CCAMPers,
>>
>> A new version has been submitted to address the comments from the WG
>> discussion.
>>
>> We accepted Acee and Young's suggestion to introduce a new top-level
>> node TLV (Generic Node Attribute TLV) to simplify things and a new
>> section (Section 5) was added to describe scalability issue.
>>
>> More information from:
>> http://www.ietf.org/id/draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt
>>
>>  Please check out for details and comments are always welcome.
>>
>>
>> Thanks
>>  
>> Fatai
>>
>>
>> -----Original Message-----
>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org
>> Sent: 2011年9月22日 17:06
>> To: i-d-announce@ietf.org
>> Cc: ccamp@ietf.org
>> Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF.
>>
>> 	Title           : OSPF-TE Extensions for General Network Element Constraints
>> 	Author(s)       : Fatai Zhang
>>                           Young Lee
>>                           Jianrui Han
>>                           Greg Bernstein
>>                           Yunbin Xu
>> 	Filename        : draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt
>> 	Pages           : 14
>> 	Date            : 2011-09-22
>>
>>    Generalized Multiprotocol Label Switching can be used to control a
>>    wide variety of technologies including packet switching (e.g., MPLS),
>>    time-division (e.g., SONET/SDH, OTN), wavelength (lambdas), and
>>    spatial switching (e.g., incoming port or fiber to outgoing port or
>>    fiber). 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 describes OSPF routing protocol extensions to
>>    support these kinds of constraints under the control of Generalized
>>    MPLS (GMPLS).
>>
>>
>>
>> A URL for this Internet-Draft is:
>> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> This Internet-Draft can be retrieved at:
>> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt
>> _______________________________________________
>> 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 cyril.margaria@nsn.com  Mon Sep 26 01:01:07 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C587921F8A97 for ; Mon, 26 Sep 2011 01:01:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.546
X-Spam-Level: 
X-Spam-Status: No, score=-6.546 tagged_above=-999 required=5 tests=[AWL=0.053,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5fuM18hXNWm for ; Mon, 26 Sep 2011 01:01:07 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id D96DC21F8A6C for ; Mon, 26 Sep 2011 01:01:06 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p8Q83it1003046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Sep 2011 10:03:44 +0200
Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p8Q83dec015367; Mon, 26 Sep 2011 10:03:44 +0200
Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 26 Sep 2011 10:03:44 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Mon, 26 Sep 2011 10:03:42 +0200
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt
Thread-Index: AQHMeQhw4fH7IgNgHEuaM0yhaE8MRpVfUxog
References: <20110922090626.6373.58763.idtracker@ietfa.amsl.com> 
From: "Margaria, Cyril (NSN - DE/Munich)" 
To: "ext Zhangfatai" , 
X-OriginalArrivalTime: 26 Sep 2011 08:03:44.0373 (UTC) FILETIME=[CFC99A50:01CC7C22]
Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Sep 2011 08:01:07 -0000

SGksIA0KDQpJIGhhdmUgdGhlIGZvbGxvd2luZyBjb21tZW50cy9xdWVzdGlvbiByZWdhcmRpbmcg
dGhpcyByZXZpc2lvbg0KDQozLjIuIEF2YWlsYWJsZSBMYWJlbHM6DQoNClRoZSB0ZXh0IHN0YXRl
IDog4oCcVGhlIEF2YWlsYWJsZSBMYWJlbHMgc3ViLVRMViAgIG1heSBvY2N1ciBhdCBtb3N0IG9u
Y2Ugd2l0aGluIHRoZSBsaW5rIFRMVi7igJ0NCg0KSG93IHRvIGVuY29kZSBkaWZmZXJlbnQgbGFi
ZWwgZm9ybWF0IGluIHRoYXQgY2FzZT8gSSB0aGluayB0aGUgbGFiZWwgZm9ybWF0IHdvdWxkIGRl
cGVuZCANCm9uIHRoZSBJU0NELCBhbmQgYXMgd2UgbWlnaHQgaGF2ZSBzZXZlcmFsIElTQ0QsIGhh
dmluZyBzZXZlcmFsIEF2YWlsYWJsZSBMYWJlbCBzdWItVExWIG1ha2Ugc2Vuc2UuDQpUaGlzIGFs
c28gYXBwbHkgdG8gMy4zLiBTaGFyZWQgQmFja3VwIExhYmVscy4NCg0KSW4gY2FzZSBvZiBzZXZl
cmFsIElTQ0QgYXJlIHByZXNlbnQgZm9yIGEgZ2l2ZW4gYWR2ZXJ0aXNlbWVudCBob3cgdG8gaW50
ZXJwcmV0IHRoZSBsYWJlbCBmb3JtYXQgaW4gdGhlIA0KbGFiZWwtcmVsYXRlZCBzdWItVExWcz8N
Cg0KQ291bGQgeW91IGNsYXJpZnkgdGhpcyBwb2ludCwgaXQgd291bGQgYmUgdXNlZnVsIGZvciBp
bnN0YW5jZSB0byBjb25zaWRlciB0aGUgZXhhbXBsZSBvZiBhIGxpbmsgc3VwcG9ydGluZyBTREgN
CihubyBWQzQtc3dpdGNoaW5nKSwgT0RVIChHLjcwOSwgYXMgb2YgUkZDNDMyOCwgYW5kIGZvciB0
aGUgY3VycmVudCBHLjcwOSB2MyBsYWJlbCBmb3JtYXQpLg0KDQpUaGUgdGV4dCBpcyB2ZXJ5IGZv
Y3VzZWQgb24gV1NPTiwgd2hpbGUgaXQgaXMgYSB2ZXJ5IGludGVyZXN0aW5nIGV4YW1wbGUsIGhh
dmluZyBvdGhlciB0ZWNobm9sb2d5IChPVE4gZm9yDQpleGFtcGxlIHdvdWxkIGhlbHAgdG8gc2hv
dyB0aGF0IHRoZSBzb2x1dGlvbiBpcyBnZW5lcmljLg0KDQoNCkJlc3QgUmVnYXJkcywgDQpDeXJp
bA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGNjYW1wLWJvdW5jZXNA
aWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2Yg
ZXh0IFpoYW5nZmF0YWkNCj4gU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAyMiwgMjAxMSAxMTox
NyBBTQ0KPiBUbzogY2NhbXBAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtDQ0FNUF0gSS1EIEFj
dGlvbjogZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLQ0KPiBjb25zdHJhaW50cy1vc3Bm
LXRlLTAyLnR4dA0KPiANCj4gSGkgQ0NBTVBlcnMsDQo+IA0KPiBBIG5ldyB2ZXJzaW9uIGhhcyBi
ZWVuIHN1Ym1pdHRlZCB0byBhZGRyZXNzIHRoZSBjb21tZW50cyBmcm9tIHRoZSBXRw0KPiBkaXNj
dXNzaW9uLg0KPiANCj4gV2UgYWNjZXB0ZWQgQWNlZSBhbmQgWW91bmcncyBzdWdnZXN0aW9uIHRv
IGludHJvZHVjZSBhIG5ldyB0b3AtbGV2ZWwNCj4gbm9kZSBUTFYgKEdlbmVyaWMgTm9kZSBBdHRy
aWJ1dGUgVExWKSB0byBzaW1wbGlmeSB0aGluZ3MgYW5kIGEgbmV3DQo+IHNlY3Rpb24gKFNlY3Rp
b24gNSkgd2FzIGFkZGVkIHRvIGRlc2NyaWJlIHNjYWxhYmlsaXR5IGlzc3VlLg0KPiANCj4gTW9y
ZSBpbmZvcm1hdGlvbiBmcm9tOiBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtY2Nh
bXAtZ21wbHMtDQo+IGdlbmVyYWwtY29uc3RyYWludHMtb3NwZi10ZS0wMi50eHQNCj4gDQo+IFBs
ZWFzZSBjaGVjayBvdXQgZm9yIGRldGFpbHMgYW5kIGNvbW1lbnRzIGFyZSBhbHdheXMgd2VsY29t
ZS4NCj4gDQo+IA0KPiBUaGFua3MNCj4gDQo+IEZhdGFpDQo+IA0KPiANCj4gLS0tLS1PcmlnaW5h
bCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNj
YW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZiBpbnRlcm5ldC1kcmFmdHNAaWV0
Zi5vcmcNCj4gU2VudDogMjAxMeW5tDnmnIgyMuaXpSAxNzowNg0KPiBUbzogaS1kLWFubm91bmNl
QGlldGYub3JnDQo+IENjOiBjY2FtcEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBbQ0NBTVBdIEktRCBB
Y3Rpb246IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC0NCj4gY29uc3RyYWludHMtb3Nw
Zi10ZS0wMi50eHQNCj4gDQo+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9t
IHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KPiBkaXJlY3Rvcmllcy4gVGhpcyBkcmFmdCBp
cyBhIHdvcmsgaXRlbSBvZiB0aGUgQ29tbW9uIENvbnRyb2wgYW5kDQo+IE1lYXN1cmVtZW50IFBs
YW5lIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+IA0KPiAJVGl0bGUgICAgICAgICAgIDog
T1NQRi1URSBFeHRlbnNpb25zIGZvciBHZW5lcmFsIE5ldHdvcmsgRWxlbWVudA0KPiBDb25zdHJh
aW50cw0KPiAJQXV0aG9yKHMpICAgICAgIDogRmF0YWkgWmhhbmcNCj4gICAgICAgICAgICAgICAg
ICAgICAgICAgICBZb3VuZyBMZWUNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICBKaWFucnVp
IEhhbg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIEdyZWcgQmVybnN0ZWluDQo+ICAgICAg
ICAgICAgICAgICAgICAgICAgICAgWXVuYmluIFh1DQo+IAlGaWxlbmFtZSAgICAgICAgOiBkcmFm
dC1pZXRmLWNjYW1wLWdtcGxzLWdlbmVyYWwtY29uc3RyYWludHMtDQo+IG9zcGYtdGUtMDIudHh0
DQo+IAlQYWdlcyAgICAgICAgICAgOiAxNA0KPiAJRGF0ZSAgICAgICAgICAgIDogMjAxMS0wOS0y
Mg0KPiANCj4gICAgR2VuZXJhbGl6ZWQgTXVsdGlwcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgY2Fu
IGJlIHVzZWQgdG8gY29udHJvbCBhDQo+ICAgIHdpZGUgdmFyaWV0eSBvZiB0ZWNobm9sb2dpZXMg
aW5jbHVkaW5nIHBhY2tldCBzd2l0Y2hpbmcgKGUuZy4sDQo+IE1QTFMpLA0KPiAgICB0aW1lLWRp
dmlzaW9uIChlLmcuLCBTT05FVC9TREgsIE9UTiksIHdhdmVsZW5ndGggKGxhbWJkYXMpLCBhbmQN
Cj4gICAgc3BhdGlhbCBzd2l0Y2hpbmcgKGUuZy4sIGluY29taW5nIHBvcnQgb3IgZmliZXIgdG8g
b3V0Z29pbmcgcG9ydCBvcg0KPiAgICBmaWJlcikuIEluIHNvbWUgb2YgdGhlc2UgdGVjaG5vbG9n
aWVzIG5ldHdvcmsgZWxlbWVudHMgYW5kIGxpbmtzIG1heQ0KPiAgICBpbXBvc2UgYWRkaXRpb25h
bCByb3V0aW5nIGNvbnN0cmFpbnRzIHN1Y2ggYXMgYXN5bW1ldHJpYyBzd2l0Y2gNCj4gICAgY29u
bmVjdGl2aXR5LCBub24tbG9jYWwgbGFiZWwgYXNzaWdubWVudCwgYW5kIGxhYmVsIHJhbmdlDQo+
IGxpbWl0YXRpb25zDQo+ICAgIG9uIGxpbmtzLiBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBPU1BG
IHJvdXRpbmcgcHJvdG9jb2wgZXh0ZW5zaW9ucw0KPiB0bw0KPiAgICBzdXBwb3J0IHRoZXNlIGtp
bmRzIG9mIGNvbnN0cmFpbnRzIHVuZGVyIHRoZSBjb250cm9sIG9mIEdlbmVyYWxpemVkDQo+ICAg
IE1QTFMgKEdNUExTKS4NCj4gDQo+IA0KPiANCj4gQSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJh
ZnQgaXM6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYt
Y2NhbXAtZ21wbHMtZ2VuZXJhbC0NCj4gY29uc3RyYWludHMtb3NwZi10ZS0wMi50eHQNCj4gDQo+
IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoN
Cj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy8NCj4gDQo+IFRoaXMgSW50ZXJu
ZXQtRHJhZnQgY2FuIGJlIHJldHJpZXZlZCBhdDoNCj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVy
bmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWdlbmVyYWwtDQo+IGNvbnN0cmFpbnRz
LW9zcGYtdGUtMDIudHh0DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQo+IENDQU1QIG1haWxpbmcgbGlzdA0KPiBDQ0FNUEBpZXRmLm9yZw0KPiBodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo+IF9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IENDQU1QIG1haWxpbmcgbGlzdA0K
PiBDQ0FNUEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv
L2NjYW1wDQo=

From cyril.margaria@nsn.com  Mon Sep 26 08:56:19 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2761011E80A5 for ; Mon, 26 Sep 2011 08:56:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.549
X-Spam-Level: 
X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pyhEY-lVRYo for ; Mon, 26 Sep 2011 08:56:18 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id C069011E80A0 for ; Mon, 26 Sep 2011 08:56:17 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p8QFwtxR009664 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 26 Sep 2011 17:58:56 +0200
Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p8QFwtIr012930; Mon, 26 Sep 2011 17:58:55 +0200
Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675);  Mon, 26 Sep 2011 17:58:55 +0200
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: Mon, 26 Sep 2011 17:58:54 +0200
Message-ID: 
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E17181669D3@DFWEML501-MBX.china.huawei.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [CCAMP] FW:  I-D Action: draft-ietf-ccamp-rwa-info-12.txt
Thread-Index: AQHMbzaIDI6/KZa+pUuuGsK1nP8d9ZVFjvuQgBpcR2A=
References: <7AEB3D6833318045B4AE71C2C87E8E17181669D3@DFWEML501-MBX.china.huawei.com>
From: "Margaria, Cyril (NSN - DE/Munich)" 
To: "ext Leeyoung" , 
X-OriginalArrivalTime: 26 Sep 2011 15:58:55.0820 (UTC) FILETIME=[31EF28C0:01CC7C65]
Subject: Re: [CCAMP] FW:  I-D Action: draft-ietf-ccamp-rwa-info-12.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Sep 2011 15:56:19 -0000

Hi,=20
I have the following comments on  draft-ietf-ccamp-rwa-wson-encode-12
after it being updated and in light of the WG discussions:

1) section 3.1. Resource Block Set Field:
   The information model indicates that the resource block set is
optional for the  "Resource Block Information", hence the text should be
modified as follow:
"0 - Inclusive List

     Indicates that the TLV contains zero or more RB elements that are
     included in the list."

2) section 3.1. Resource Block Set Field:
RB Identifier: as stated in section "3. Resources, Blocks, Sets, and the
Resource Pool", Resources and Resource Blocks are related to interface
cards.

GMPLS implementations are using 32-bit unnumbered interface IDs to
identify GMPLS links and also the corresponding physical resources.
OEO devices and, in the context of this document, resource or resource
group can also be identified by 32-bit unnumbered interface IDs.

 From an implementation point of view, having 16-bit resource block IDs
have several drawbacks because of the following points:
  a) Mapping exists between physical resource and unnumbered interface
IDs, this mapping is generally known by management system,
      introducing a different ID space is not optimal (new mapping
needed);
  b) Those OEOs might be used as links in a multi-node model, thus being
identified by a 32-bit unnumbered interface IDs, introducing another
space is also not optimal.

Therefore, it would be better if the resource block IDs were 32-bit
interface IDs (to be unique within the node, not because they are
representing links in this document).


3) section 3.1. Resource Block Set Field Why not define a bit set=20
action, similar to the label set?


4) section 4.3. Resource Pool State Sub-TLV

The RB state refers to the number of available resources within the=20
resource block, the first sentence mentions the resource pool only.
In addition, a bit map can be used even in case the resource block
contains several resources.
The following text tries to reflect this, please consider it.

    "The state of the pool is given by the number of resources available
    with particular characteristics. A resource block set is used to
    encode all or a subset of the resources of interest. The usage state
    of resources within a resource block set is encoded as either a list
    of 16-bit integer values, indicating the number of available
resources
    in the resource block, or a map of bits, indicating whether a
particular
    resource is available or not."

5) section 4.3. Resource Pool State Sub-TLV
   Typo: "RB Usage state:  Variable Length but must be a multiple of 4=20
bytes." (byes->bytes)

6) section 5.1. Resource Block Information Sub-TLV

Having an Input Modulation Type List sub-sub-TLV containing a list of=20
modulation formats (with an input-output bit) and an Output Modulation=20
Type List sub-sub-TLV containing a list of modulation formats (with an
input-output bit) seems redundant because the bit I already indicates if
it is an output or input modulation format.

Having a single Modulation Type List sub-sub-TLV is providing the same
information with an efficient encoding, a single sub-sub-TLV type should
be used.

Same reasoning apply to the FEC Type List Sub-Sub-TLV.


7) section 5.1. Resource Block Information Sub-TLV
  Add the following text: "The order of sub-sub-TLVs does not matter,
the sub-sub-TLVs MAY be in any order."


Best Regards,=20
Cyril Margaria


> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of ext Leeyoung
> Sent: Friday, September 09, 2011 11:30 PM
> To: ccamp@ietf.org
> Subject: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-info-12.txt
>=20
> Hi,
>=20
> This update (version 12) includes the following:
>=20
> (i) Replaced all instances of "ingress" with "input" and all instances
> of "egress" with "output".
> (ii) Added clarifying text on relationship between resource block
model
> and physical entities such as line cards.
>=20
> This draft is now very mature and incorporated all the comments raised
> in the mailing list and the last meetings.
>=20
> Thanks,
> Young
>=20
> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of internet-drafts@ietf.org
> Sent: Friday, September 09, 2011 4:20 PM
> To: i-d-announce@ietf.org
> Cc: ccamp@ietf.org
> Subject: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-info-12.txt
>=20
> 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.
>=20
> 	Title           : Routing and Wavelength Assignment Information
> Model for Wavelength Switched Optical Networks
> 	Author(s)       : Young Lee
>                           Greg M. Bernstein
>                           Dan Li
>                           Wataru Imajuku
> 	Filename        : draft-ietf-ccamp-rwa-info-12.txt
> 	Pages           : 27
> 	Date            : 2011-09-09
>=20
>    This document provides a model of information needed by the routing
>    and wavelength assignment (RWA) process in wavelength switched
>    optical networks (WSONs).  The purpose of the information described
>    in this model is to facilitate constrained lightpath computation in
>    WSONs. This model takes into account compatibility constraints
>    between WSON signal attributes and network elements but does not
>    include constraints due to optical impairments. Aspects of this
>    information that may be of use to other technologies utilizing a
>    GMPLS control plane are discussed.
>=20
>=20
>=20
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-12.txt
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-12.txt
> _______________________________________________
> 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 iesg-secretary@ietf.org  Mon Sep 26 13:10:50 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B7DD21F8CF6; Mon, 26 Sep 2011 13:10:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.507
X-Spam-Level: 
X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0c06I+VsmmzU; Mon, 26 Sep 2011 13:10:50 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F4421F8CEA; Mon, 26 Sep 2011 13:10:50 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IETF-Announce 
X-Test-IDTracker: no
X-IETF-IDTracker: 3.60
Message-ID: <20110926201050.16507.39664.idtracker@ietfa.amsl.com>
Date: Mon, 26 Sep 2011 13:10:50 -0700
Cc: ccamp@ietf.org
Subject: [CCAMP] Last Call:  (LSP Attributes	Related Routing Backus-Naur Form) to Proposed Standard
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ietf@ietf.org
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Sep 2011 20:10:50 -0000

The IESG has received a request from the Common Control and Measurement
Plane WG (ccamp) to consider the following document:
- 'LSP Attributes Related Routing Backus-Naur Form'
   as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-10-10. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
   established using the Resource Reservation Protocol Traffic
   Engineering (RSVP-TE) extensions may be signaled with a set of LSP
   specific attributes.  These attributes may be carried in both Path
   and Resv messages.  This document specifies how LSP attribute are
   to be carried in RSVP Path and Resv messages using the Routing
   Backus-Naur Form, and clarifies related Resv message formats.
   This document updates RFC 4875 and RFC 5420.


The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ccamp-attribute-bnf/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ccamp-attribute-bnf/


No IPR declarations have been submitted directly on this I-D.

From pierre.peloso@alcatel-lucent.com  Tue Sep 27 01:25:56 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 430DC21F8DA0 for ; Tue, 27 Sep 2011 01:25:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.586
X-Spam-Level: 
X-Spam-Status: No, score=-5.586 tagged_above=-999 required=5 tests=[AWL=0.663,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuajvPOjprvU for ; Tue, 27 Sep 2011 01:25:55 -0700 (PDT)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3216421F8D9D for ; Tue, 27 Sep 2011 01:25:54 -0700 (PDT)
Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p8R8SBZP018620 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 27 Sep 2011 10:28:33 +0200
Received: from FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 27 Sep 2011 10:28:24 +0200
From: "PELOSO, PIERRE (PIERRE)" 
To: Leeyoung , "ccamp@ietf.org" 
Date: Tue, 27 Sep 2011 10:28:23 +0200
Thread-Topic: [CCAMP] I-D	Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
Thread-Index: AQHMc+DNFGZirNpekU68H0VT9nct2ZVO2fZwgBIQYsA=
Message-ID: 
References: <20110915194751.1118.92540.idtracker@ietfa.amsl.com> <7AEB3D6833318045B4AE71C2C87E8E171816B709@DFWEML501-MBX.china.huawei.com>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E171816B709@DFWEML501-MBX.china.huawei.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR, en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83
Subject: Re: [CCAMP] I-D	Action:	draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Sep 2011 08:25:56 -0000

Hi Young, and CCAMPers,

I was off the mailing lists for the last two weeks and being back I notice =
a lot of exchanges, which I'm very glad of.
I've also noticed many drafts have been updated.
Concerning this specific draft-ietf-ccamp-wson-signal-compatibility-ospf-06=
, I wanted to comment section 3.
Back in Quebec, I expressed my point of view (shared with Cyril, Julien and=
 Giovanni) that current drafts were lacking guidance regarding the way to d=
esign LSAs that were to depict an WSON node with OEOs.
This section 3 provides additional material to help designing the LSA.
I would like to know whether authors are willing to pursue further in this =
direction, which is to my mind a real corner stone, that would help everyon=
e agree on a solution.
A first point could concern the Resource Block Information (reminder:  ::=3D ([]   ):
     We all agree that these information are static, that we should not rep=
licate this TLV whatever the number not the layout of OEO boards of a given=
 type.
Then, we could dedicate a specific independant flooding entity. This would =
be defined once for all, and that would not leave room to different interpr=
etations.
What about this first point?

Regards,

Pierre

-----Message d'origine-----
De : ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] De la part de L=
eeyoung
Envoy=E9 : jeudi 15 septembre 2011 21:59
=C0 : ccamp@ietf.org
Objet : Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-=
ospf-06.txt

Hi all,

After 05 version publication, Acee provided a number of valuable comments a=
nd suggestions. This revision (06) reflects those changes. Please note the =
following updates:

- Change the title of the draft to "GMPLS OSPF Enhancement..." from "OSPF E=
nhancement..." to make sure the changes apply to the GMPLS OSPF rather than=
 the base OSPF.=20

- Add specific OSPF procedures on how sub-TLVs are packaged per [RFC3630] a=
nd editorial change including avoiding "multiple instances of TE LSA" to "m=
ultiple TE LSAs".=20

Your comments are always appreciated. Thanks.

Best Regards.
Young


-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of i=
nternet-drafts@ietf.org
Sent: Thursday, September 15, 2011 2:48 PM
To: i-d-announce@ietf.org
Cc: ccamp@ietf.org
Subject: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-osp=
f-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Common Control and Measurement Plane =
Working Group of the IETF.

	Title           : GMPLS OSPF Enhancement for Signal and Network Element Co=
mpatibility for Wavelength Switched Optical Networks
	Author(s)       : Young Lee
                          Greg M. Bernstein
	Filename        : draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
	Pages           : 14
	Date            : 2011-09-15

   This document provides GMPLS OSPF routing enhancements to support
   signal compatibility constraints associated with WSON network
   elements. These routing enhancements are required in common optical
   or hybrid electro-optical networks where not all of the optical
   signals in the network are compatible with all network elements
   participating in the network.

   This compatibility constraint model is applicable to common optical
   or hybrid electro optical systems such as OEO switches, regenerators,
   and wavelength converters since such systems can be limited to
   processing only certain types of WSON signals.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compatibil=
ity-ospf-06.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compatibili=
ty-ospf-06.txt
_______________________________________________
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 Ben.Wright@metaswitch.com  Tue Sep 27 02:08:07 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9B8721F8CE3 for ; Tue, 27 Sep 2011 02:08:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Aw737PlPvqe for ; Tue, 27 Sep 2011 02:08:06 -0700 (PDT)
Received: from enfiets1.dataconnection.com (enfiets1.dataconnection.com [192.91.191.38]) by ietfa.amsl.com (Postfix) with ESMTP id 50C8B21F8CE1 for ; Tue, 27 Sep 2011 02:08:06 -0700 (PDT)
Received: from ENFICSCAS1.datcon.co.uk (172.18.4.13) by enfiets1.dataconnection.com (172.18.4.21) with Microsoft SMTP Server (TLS) id 8.3.192.1; Tue, 27 Sep 2011 10:11:03 +0100
Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFICSCAS1.datcon.co.uk ([::1]) with mapi id 14.01.0289.001; Tue, 27 Sep 2011 10:10:50 +0100
From: Ben Wright 
To: "ccamp@ietf.org" 
Thread-Topic: Question on NMC in draft-zhang-ccamp-gmpls-evolving-g709
Thread-Index: Acx89VlrIwvIizXFQ3623ojG/v0sWw==
Date: Tue, 27 Sep 2011 09:10:49 +0000
Message-ID: 
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.18.71.11]
Content-Type: multipart/alternative; boundary="_000_B3B6FD81D3159A45B5421AF9DD500F880B9CC2ENFICSMBX1datconc_"
MIME-Version: 1.0
Subject: [CCAMP] Question on NMC in draft-zhang-ccamp-gmpls-evolving-g709
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Sep 2011 09:08:08 -0000

--_000_B3B6FD81D3159A45B5421AF9DD500F880B9CC2ENFICSMBX1datconc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

I had a detailed query about the NMC usage in draft-zhang-ccamp-gmpls-evolv=
ing-g709.   This inherits the usage of the NMC from RFC4328, which would in=
dicate the number of tributary slots requested for this signal type.   I th=
ink the following are both true.

-          This information is strictly speaking redundant because the labe=
l now describes how the signal type will be multiplexed onto a given link.

-          With the introduction of the 1.25Gbps size, the tributary slot s=
ize can vary in a network.   Therefore, to preserve the usage of the NMC fr=
om RFC4328 nodes which supported both TS sizes would need to translate the =
SENDER_TSPEC object at each hop to encode the right NMC value given the TS =
to be used on a given hop.   This isn't typical behaviour for a SENDER_TSPE=
C.

Given the above, it seems to me easier to revert back to the original defin=
ition, which deprecated this field from RFC4328.   To preserve back-compati=
bility with RFC4328, I understand you've already agreed that nodes supporti=
ng draft-zhang-ccamp-gmpls-evolving-g709 should signal OTN LSPs with switch=
ing capability 101 (OTN-TDM capable).  This makes it safe to deprecate the =
NMC field in this new usage.

What do you think?

Cheers,

Ben

--_000_B3B6FD81D3159A45B5421AF9DD500F880B9CC2ENFICSMBX1datconc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi all, 


 =



I had a detailed query a=
bout the NMC usage in draft-zhang-ccamp-gmpls-evolving-g709.   Th=
is inherits the usage of the NMC from RFC4328, which would indicate the num=
ber of tributary slots requested for this signal
 type.   I think the following are both true.  


-&nbs=
p;        
This information=
 is strictly speaking redundant because the label now describes how the sig=
nal type will be multiplexed onto a given link.



-&nbs=
p;        
With the introdu=
ction of the 1.25Gbps size, the tributary slot size can vary in a network.&=
nbsp;  Therefore, to preserve the usage of the NMC from RFC4328 nodes =
which supported both TS sizes would need to
 translate the SENDER_TSPEC object at each hop to encode the right NMC valu=
e given the TS to be used on a given hop.   This isn’t typi=
cal behaviour for a SENDER_TSPEC.   


 =



Given the above, it seem=
s to me easier to revert back to the original definition, which deprecated =
this field from RFC4328.   To preserve back-compatibility with RF=
C4328, I understand you’ve already agreed that
 nodes supporting draft-zhang-ccamp-gmpls-evolving-g709 should signal OTN L=
SPs with switching capability 101 (OTN-TDM capable).  This makes it sa=
fe to deprecate the NMC field in this new usage.


 =



What do you think? =
 


 =



Cheers, 


 =



Ben





--_000_B3B6FD81D3159A45B5421AF9DD500F880B9CC2ENFICSMBX1datconc_--

From zhangfatai@huawei.com  Tue Sep 27 02:14:42 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24B7021F8D66 for ; Tue, 27 Sep 2011 02:14:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.143
X-Spam-Level: 
X-Spam-Status: No, score=-1.143 tagged_above=-999 required=5 tests=[AWL=-3.593, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJw2BRT8FZxD for ; Tue, 27 Sep 2011 02:14:41 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8E04721F8D67 for ; Tue, 27 Sep 2011 02:14:39 -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 <0LS6007ADCGYJ7@szxga03-in.huawei.com> for ccamp@ietf.org; Tue, 27 Sep 2011 17:17:22 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS6008LWCG7AO@szxga03-in.huawei.com> for ccamp@ietf.org; Tue, 27 Sep 2011 17:17:22 +0800 (CST)
Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id ADX86617; Tue, 27 Sep 2011 17:17:22 +0800
Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 27 Sep 2011 17:17:19 +0800
Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.142]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0270.001; Tue, 27 Sep 2011 17:17:15 +0800
Date: Tue, 27 Sep 2011 09:17:14 +0000
From: Zhangfatai 
In-reply-to: 
X-Originating-IP: [172.24.2.40]
To: "Margaria, Cyril (NSN - DE/Munich)" , "ccamp@ietf.org" 
Message-id: 
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_xLAo+ZicKoE95aLwlx1vnA)"
Content-language: zh-CN
Accept-Language: zh-CN, en-US
Thread-topic: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt
Thread-index: AQHMeQhw4fH7IgNgHEuaM0yhaE8MRpVfUxoggAGhYTk=
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <20110922090626.6373.58763.idtracker@ietfa.amsl.com>  
Subject: [CCAMP] =?gb2312?b?tPC4tDogIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2Nh?= =?gb2312?b?bXAtZ21wbHMtZ2VuZXJhbC1jb25zdHJhaW50cy1vc3BmLXRlLTAyLnR4dA==?=
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Sep 2011 09:14:42 -0000

--Boundary_(ID_xLAo+ZicKoE95aLwlx1vnA)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: base64

SGkgQ3lyaWwsDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZXRzLg0KDQpQbGVhc2Ugc2VlIGluLWxp
bmUgYmVsb3cuDQoNCg0KRmF0YWkNCg0KVGhhbmtzDQoNCg0KDQpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fDQq3orz+yMs6IE1hcmdhcmlhLCBDeXJpbCAoTlNOIC0gREUv
TXVuaWNoKSBbY3lyaWwubWFyZ2FyaWFAbnNuLmNvbV0NCreiy83KsbzkOiAyMDExxOo51MIyNsjV
IDE2OjAzDQq1vTogWmhhbmdmYXRhaTsgY2NhbXBAaWV0Zi5vcmcNCtb3zOI6IFJFOiBbQ0NBTVBd
IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC1jb25zdHJhaW50cy1v
c3BmLXRlLTAyLnR4dA0KDQpIaSwNCg0KSSBoYXZlIHRoZSBmb2xsb3dpbmcgY29tbWVudHMvcXVl
c3Rpb24gcmVnYXJkaW5nIHRoaXMgcmV2aXNpb24NCg0KMy4yLiBBdmFpbGFibGUgTGFiZWxzOg0K
DQpUaGUgdGV4dCBzdGF0ZSA6IKGwVGhlIEF2YWlsYWJsZSBMYWJlbHMgc3ViLVRMViAgIG1heSBv
Y2N1ciBhdCBtb3N0IG9uY2Ugd2l0aGluIHRoZSBsaW5rIFRMVi6hsQ0KDQpIb3cgdG8gZW5jb2Rl
IGRpZmZlcmVudCBsYWJlbCBmb3JtYXQgaW4gdGhhdCBjYXNlPyBJIHRoaW5rIHRoZSBsYWJlbCBm
b3JtYXQgd291bGQgZGVwZW5kDQpvbiB0aGUgSVNDRCwgYW5kIGFzIHdlIG1pZ2h0IGhhdmUgc2V2
ZXJhbCBJU0NELCBoYXZpbmcgc2V2ZXJhbCBBdmFpbGFibGUgTGFiZWwgc3ViLVRMViBtYWtlIHNl
bnNlLg0KVGhpcyBhbHNvIGFwcGx5IHRvIDMuMy4gU2hhcmVkIEJhY2t1cCBMYWJlbHMuDQoNCltG
YXRhaV0gVGhpcyAibWF5IiBzaG91bGQgYmUgIk1BWSIgYWNjb3JkaW5nIHRvIExvdSdzIHN1Z2dl
c3Rpb24sIHNvIGl0IGRvZXMgbm90IHByZXZlbnQgeW91IHRvIGhhdmUgc2V2ZXJhbCBhdmFpbGFi
bGUgbGFiZWwgc3ViLVRMVnMuDQoNCkluIGNhc2Ugb2Ygc2V2ZXJhbCBJU0NEIGFyZSBwcmVzZW50
IGZvciBhIGdpdmVuIGFkdmVydGlzZW1lbnQgaG93IHRvIGludGVycHJldCB0aGUgbGFiZWwgZm9y
bWF0IGluIHRoZQ0KbGFiZWwtcmVsYXRlZCBzdWItVExWcz8NCg0KW0ZhdGFpXSBJdCBpcyBlYXN5
IHRvIGFjaGl2ZSB0aGF0LiBlLmcsIGluIFNESCBuZXR3b3JrLCBhIG5vZGUgY2FuIGFkdmVydGlz
ZSBzZXZlcmFsIElTQ0RzIHdpdGggb25lIG9yIG11bHRpcGxlIGxhYmVsIHN1Yi1UTFZzIChJIGFz
c3VtZSAiSUYiIGxhYmVsIGluZm9ybWF0aW9uIGlzIG5lZWRlZCB0byBiZSBhZHZlcnRpc2VkIGhl
cmUpLCB3aHkgaXQgY2Fubm90IGludGVycHJldCB0aGUgbGFiZWxzIGFyZSBTREggbGFiZWxzPw0K
DQpDb3VsZCB5b3UgY2xhcmlmeSB0aGlzIHBvaW50LCBpdCB3b3VsZCBiZSB1c2VmdWwgZm9yIGlu
c3RhbmNlIHRvIGNvbnNpZGVyIHRoZSBleGFtcGxlIG9mIGEgbGluayBzdXBwb3J0aW5nIFNESA0K
KG5vIFZDNC1zd2l0Y2hpbmcpLCBPRFUgKEcuNzA5LCBhcyBvZiBSRkM0MzI4LCBhbmQgZm9yIHRo
ZSBjdXJyZW50IEcuNzA5IHYzIGxhYmVsIGZvcm1hdCkuDQoNCg0KDQpbRmF0YWldICBEbyB5b3Ug
bWVhbiB0byBoYXZlIGFuIGV4YW1wbGUgb24gaHlicmlkIG5vZGU/IEkgd2lsbCBub3QgdXNlIGEg
Y29tcGxleCBleGFtcGxlIHRvIGV4cGxhaW4gYSBraW5kIG9mIHNpbXBsZSB0aGluZyAoSXQgd2ls
bCBjb25mdXNlIHBlb3BsZSkuDQoNClRoZSB0ZXh0IGlzIHZlcnkgZm9jdXNlZCBvbiBXU09OLCB3
aGlsZSBpdCBpcyBhIHZlcnkgaW50ZXJlc3RpbmcgZXhhbXBsZSwgaGF2aW5nIG90aGVyIHRlY2hu
b2xvZ3kgKE9UTiBmb3INCmV4YW1wbGUgd291bGQgaGVscCB0byBzaG93IHRoYXQgdGhlIHNvbHV0
aW9uIGlzIGdlbmVyaWMuDQoNCltGYXRhaV0gSSB0aGluayBvbmUgdHlwaWNhbCBleGFtcGxlIGlz
IHN1ZmZpY2llbnQgZm9yIHBlb3BsZSB0byB1bmRlcnN0YW5kIHRoaW5ncy4gVERNIG5ldHdvcmsg
aXMgZGlmZmVyZW50IGZyb20gV1NPTiBuZXR3b3JrLiBJbiBURE0gbmV0d29yaywgdXN1YWxseSBp
dCB3aWxsIG5vdCBhZHZlcnRpc2UgbGFiZWwgaW5mb3JtYXRpb24gZXZlbiB0aG91Z2ggbGFiZWwg
aW5mb3JtYXRpb24gY291bGQgYmUgYWR2ZXJ0aXNlZC4NCg0KDQpCZXN0IFJlZ2FyZHMsDQpDeXJp
bA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGNjYW1wLWJvdW5jZXNA
aWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2Yg
ZXh0IFpoYW5nZmF0YWkNCj4gU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAyMiwgMjAxMSAxMTox
NyBBTQ0KPiBUbzogY2NhbXBAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtDQ0FNUF0gSS1EIEFj
dGlvbjogZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLQ0KPiBjb25zdHJhaW50cy1vc3Bm
LXRlLTAyLnR4dA0KPg0KPiBIaSBDQ0FNUGVycywNCj4NCj4gQSBuZXcgdmVyc2lvbiBoYXMgYmVl
biBzdWJtaXR0ZWQgdG8gYWRkcmVzcyB0aGUgY29tbWVudHMgZnJvbSB0aGUgV0cNCj4gZGlzY3Vz
c2lvbi4NCj4NCj4gV2UgYWNjZXB0ZWQgQWNlZSBhbmQgWW91bmcncyBzdWdnZXN0aW9uIHRvIGlu
dHJvZHVjZSBhIG5ldyB0b3AtbGV2ZWwNCj4gbm9kZSBUTFYgKEdlbmVyaWMgTm9kZSBBdHRyaWJ1
dGUgVExWKSB0byBzaW1wbGlmeSB0aGluZ3MgYW5kIGEgbmV3DQo+IHNlY3Rpb24gKFNlY3Rpb24g
NSkgd2FzIGFkZGVkIHRvIGRlc2NyaWJlIHNjYWxhYmlsaXR5IGlzc3VlLg0KPg0KPiBNb3JlIGlu
Zm9ybWF0aW9uIGZyb206IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1jY2FtcC1n
bXBscy0NCj4gZ2VuZXJhbC1jb25zdHJhaW50cy1vc3BmLXRlLTAyLnR4dA0KPg0KPiBQbGVhc2Ug
Y2hlY2sgb3V0IGZvciBkZXRhaWxzIGFuZCBjb21tZW50cyBhcmUgYWx3YXlzIHdlbGNvbWUuDQo+
DQo+DQo+IFRoYW5rcw0KPg0KPiBGYXRhaQ0KPg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLQ0KPiBGcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAtYm91bmNl
c0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+IE9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KPiBT
ZW50OiAyMDExxOo51MIyMsjVIDE3OjA2DQo+IFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4g
Q2M6IGNjYW1wQGlldGYub3JnDQo+IFN1YmplY3Q6IFtDQ0FNUF0gSS1EIEFjdGlvbjogZHJhZnQt
aWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLQ0KPiBjb25zdHJhaW50cy1vc3BmLXRlLTAyLnR4dA0K
Pg0KPiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJ
bnRlcm5ldC1EcmFmdHMNCj4gZGlyZWN0b3JpZXMuIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0g
b2YgdGhlIENvbW1vbiBDb250cm9sIGFuZA0KPiBNZWFzdXJlbWVudCBQbGFuZSBXb3JraW5nIEdy
b3VwIG9mIHRoZSBJRVRGLg0KPg0KPiAgICAgICBUaXRsZSAgICAgICAgICAgOiBPU1BGLVRFIEV4
dGVuc2lvbnMgZm9yIEdlbmVyYWwgTmV0d29yayBFbGVtZW50DQo+IENvbnN0cmFpbnRzDQo+ICAg
ICAgIEF1dGhvcihzKSAgICAgICA6IEZhdGFpIFpoYW5nDQo+ICAgICAgICAgICAgICAgICAgICAg
ICAgICAgWW91bmcgTGVlDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgSmlhbnJ1aSBIYW4N
Cj4gICAgICAgICAgICAgICAgICAgICAgICAgICBHcmVnIEJlcm5zdGVpbg0KPiAgICAgICAgICAg
ICAgICAgICAgICAgICAgIFl1bmJpbiBYdQ0KPiAgICAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFm
dC1pZXRmLWNjYW1wLWdtcGxzLWdlbmVyYWwtY29uc3RyYWludHMtDQo+IG9zcGYtdGUtMDIudHh0
DQo+ICAgICAgIFBhZ2VzICAgICAgICAgICA6IDE0DQo+ICAgICAgIERhdGUgICAgICAgICAgICA6
IDIwMTEtMDktMjINCj4NCj4gICAgR2VuZXJhbGl6ZWQgTXVsdGlwcm90b2NvbCBMYWJlbCBTd2l0
Y2hpbmcgY2FuIGJlIHVzZWQgdG8gY29udHJvbCBhDQo+ICAgIHdpZGUgdmFyaWV0eSBvZiB0ZWNo
bm9sb2dpZXMgaW5jbHVkaW5nIHBhY2tldCBzd2l0Y2hpbmcgKGUuZy4sDQo+IE1QTFMpLA0KPiAg
ICB0aW1lLWRpdmlzaW9uIChlLmcuLCBTT05FVC9TREgsIE9UTiksIHdhdmVsZW5ndGggKGxhbWJk
YXMpLCBhbmQNCj4gICAgc3BhdGlhbCBzd2l0Y2hpbmcgKGUuZy4sIGluY29taW5nIHBvcnQgb3Ig
ZmliZXIgdG8gb3V0Z29pbmcgcG9ydCBvcg0KPiAgICBmaWJlcikuIEluIHNvbWUgb2YgdGhlc2Ug
dGVjaG5vbG9naWVzIG5ldHdvcmsgZWxlbWVudHMgYW5kIGxpbmtzIG1heQ0KPiAgICBpbXBvc2Ug
YWRkaXRpb25hbCByb3V0aW5nIGNvbnN0cmFpbnRzIHN1Y2ggYXMgYXN5bW1ldHJpYyBzd2l0Y2gN
Cj4gICAgY29ubmVjdGl2aXR5LCBub24tbG9jYWwgbGFiZWwgYXNzaWdubWVudCwgYW5kIGxhYmVs
IHJhbmdlDQo+IGxpbWl0YXRpb25zDQo+ICAgIG9uIGxpbmtzLiBUaGlzIGRvY3VtZW50IGRlc2Ny
aWJlcyBPU1BGIHJvdXRpbmcgcHJvdG9jb2wgZXh0ZW5zaW9ucw0KPiB0bw0KPiAgICBzdXBwb3J0
IHRoZXNlIGtpbmRzIG9mIGNvbnN0cmFpbnRzIHVuZGVyIHRoZSBjb250cm9sIG9mIEdlbmVyYWxp
emVkDQo+ICAgIE1QTFMgKEdNUExTKS4NCj4NCj4NCj4NCj4gQSBVUkwgZm9yIHRoaXMgSW50ZXJu
ZXQtRHJhZnQgaXM6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0
LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC0NCj4gY29uc3RyYWludHMtb3NwZi10ZS0wMi50eHQN
Cj4NCj4gSW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQ
IGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPg0KPiBUaGlzIElu
dGVybmV0LURyYWZ0IGNhbiBiZSByZXRyaWV2ZWQgYXQ6DQo+IGZ0cDovL2Z0cC5pZXRmLm9yZy9p
bnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLQ0KPiBjb25zdHJh
aW50cy1vc3BmLXRlLTAyLnR4dA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KPiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4gQ0NBTVBAaWV0Zi5vcmcNCj4g
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPiBfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBDQ0FNUCBtYWlsaW5nIGxp
c3QNCj4gQ0NBTVBAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0
aW5mby9jY2FtcA0K

--Boundary_(ID_xLAo+ZicKoE95aLwlx1vnA)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: quoted-printable










Hi Cyril,



Thanks for your commets.



Please see in-line below.





Fatai



Thanks







________________________________________

=B7=A2=BC=FE=C8=CB: Margaria, Cyril (NSN - DE/Munich) [cyril.margaria@nsn.c=
om]

=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA9=D4=C226=C8=D5 16:03

=B5=BD: Zhangfatai; ccamp@ietf.org

=D6=F7=CC=E2: RE: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-constr=
aints-ospf-te-02.txt



Hi,



I have the following comments/question regarding this revision



3.2. Available Labels:



The text state : =A1=B0The Available Labels sub-TLV   may occur a=
t most once within the link TLV.=A1=B1



How to encode different label format in that case? I think the label format=
 would depend

on the ISCD, and as we might have several ISCD, having several Available La=
bel sub-TLV make sense.

This also apply to 3.3. Shared Backup Labels.



[Fatai] This "may" should be "MAY&qu=
ot; according to Lou's suggestion, so it does not prevent you to have sever=
al available label sub-TLVs.




In case of several ISCD are present for a given advertisement how to interp=
ret the label format in the

label-related sub-TLVs?




[Fatai] It is easy to achive that. e.g, in SDH=
 network, a node can advertise several ISCDs with one or multiple labe=
l sub-TLVs (I assume "IF" label information is needed to be adver=
tised here), why it cannot interpret the labels are SDH
 labels?




Could you clarify this point, it would be useful for instance to consider t=
he example of a link supporting SDH

(no VC4-switching), ODU (G.709, as of RFC4328, and for the current G.709 v3=
 label format).


 


[Fatai]  Do you mean to have an example on =
hybrid node? I will not use a complex example to explain a&n=
bsp;kind of simple thing (It will confuse people).





The text is very focused on WSON, while it is a very interesting example, h=
aving other technology (OTN for

example would help to show that the solution is generic.




[Fatai] I think one typical example is sufficien=
t for people to understand things. TDM network is different from WSON netwo=
rk. In TDM network, usually it will not advertise label information ev=
en though label information could be advertised.






Best Regards,

Cyril



> -----Original Message-----

> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf=


> Of ext Zhangfatai

> Sent: Thursday, September 22, 2011 11:17 AM

> To: ccamp@ietf.org

> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-

> constraints-ospf-te-02.txt

>

> Hi CCAMPers,

>

> A new version has been submitted to address the comments from the WG
> discussion.

>

> We accepted Acee and Young's suggestion to introduce a new top-level
> node TLV (Generic Node Attribute TLV) to simplify things and a new

> section (Section 5) was added to describe scalability issue.

>

> More information from: http://www.ietf.org/id/draft-ietf-ccamp-gmpls-<=
br>
> general-constraints-ospf-te-02.txt

>

> Please check out for details and comments are always welcome.

>

>

> Thanks

>

> Fatai

>

>

> -----Original Message-----

> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf=


> Of internet-drafts@ietf.org

> Sent: 2011=C4=EA9=D4=C222=C8=D5 17:06

> To: i-d-announce@ietf.org

> Cc: ccamp@ietf.org

> Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-

> constraints-ospf-te-02.txt

>

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

> directories. This draft is a work item of the Common Control and

> Measurement Plane Working Group of the IETF.

>

>       Title     =
;      : OSPF-TE Extensions for General Network El=
ement

> Constraints

>       Author(s)    &=
nbsp;  : Fatai Zhang

>            =
;            &n=
bsp;  Young Lee

>            =
;            &n=
bsp;  Jianrui Han

>            =
;            &n=
bsp;  Greg Bernstein

>            =
;            &n=
bsp;  Yunbin Xu

>       Filename    &n=
bsp;   : draft-ietf-ccamp-gmpls-general-constraints-

> ospf-te-02.txt

>       Pages     =
;      : 14

>       Date     =
       : 2011-09-22

>

>    Generalized Multiprotocol Label Switching can be use=
d to control a

>    wide variety of technologies including packet switch=
ing (e.g.,

> MPLS),

>    time-division (e.g., SONET/SDH, OTN), wavelength (la=
mbdas), and

>    spatial switching (e.g., incoming port or fiber to o=
utgoing port or

>    fiber). In some of these technologies network elemen=
ts and links may

>    impose additional routing constraints such as asymme=
tric switch

>    connectivity, non-local label assignment, and label =
range

> limitations

>    on links. This document describes OSPF routing proto=
col extensions

> to

>    support these kinds of constraints under the control=
 of Generalized

>    MPLS (GMPLS).

>

>

>

> A URL for this Internet-Draft is:

> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-general-
> constraints-ospf-te-02.txt

>

> Internet-Drafts are also available by anonymous FTP at:

> ftp://ftp.ietf.org/internet-drafts/

>

> This Internet-Draft can be retrieved at:

> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-general-

> constraints-ospf-te-02.txt

> _______________________________________________

> 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






--Boundary_(ID_xLAo+ZicKoE95aLwlx1vnA)--

From cyril.margaria@nsn.com  Tue Sep 27 02:36:17 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFB1421F8DEC for ; Tue, 27 Sep 2011 02:36:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.904
X-Spam-Level: 
X-Spam-Status: No, score=-2.904 tagged_above=-999 required=5 tests=[AWL=-3.601, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DIAgw7Jx8tAV for ; Tue, 27 Sep 2011 02:36:16 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 9693A21F8D88 for ; Tue, 27 Sep 2011 02:36:15 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p8R9cpZE010548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Sep 2011 11:38:51 +0200
Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p8R9cmM2011150; Tue, 27 Sep 2011 11:38:50 +0200
Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675);  Tue, 27 Sep 2011 11:38:50 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC7CF9.42FD745B"
Date: Tue, 27 Sep 2011 11:38:48 +0200
Message-ID: 
In-Reply-To: A
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: =?gb2312?B?ILTwuLQ6IFtDQ0FNUF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jYw==?= =?gb2312?B?YW1wLWdtcGxzLWdlbmVyYWwtY29uc3RyYWludHMtb3NwZi10ZS0wMi50eHQ=?=
Thread-Index: AQHMeQhw4fH7IgNgHEuaM0yhaE8MRpVfUxoggAGhYTmAAAbksA==
References: <20110922090626.6373.58763.idtracker@ietfa.amsl.com>   A
From: "Margaria, Cyril (NSN - DE/Munich)" 
To: "ext Zhangfatai" , 
X-OriginalArrivalTime: 27 Sep 2011 09:38:50.0837 (UTC) FILETIME=[4384A850:01CC7CF9]
Subject: Re: [CCAMP] =?gb2312?b?tPC4tDogIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2Nh?= =?gb2312?b?bXAtZ21wbHMtZ2VuZXJhbC1jb25zdHJhaW50cy1vc3BmLXRlLTAy?= =?gb2312?b?LnR4dA==?=
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Sep 2011 09:36:17 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC7CF9.42FD745B
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable

Hi,=20

=20

Thanks for the answer,=20

=20

Please see inline

=20

=20

From: ext Zhangfatai [mailto:zhangfatai@huawei.com]=20
Sent: Tuesday, September 27, 2011 11:17 AM
To: Margaria, Cyril (NSN - DE/Munich); ccamp@ietf.org
Subject: =B4=F0=B8=B4: [CCAMP] I-D Action: =
draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt

=20

Hi Cyril,

Thanks for your commets.

Please see in-line below.


Fatai

Thanks



________________________________________
=B7=A2=BC=FE=C8=CB: Margaria, Cyril (NSN - DE/Munich) =
[cyril.margaria@nsn.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA9=D4=C226=C8=D5 16:03
=B5=BD: Zhangfatai; ccamp@ietf.org
=D6=F7=CC=E2: RE: [CCAMP] I-D Action: =
draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt

Hi,

I have the following comments/question regarding this revision

3.2. Available Labels:

The text state : =A1=B0The Available Labels sub-TLV   may occur at most =
once within the link TLV.=A1=B1

How to encode different label format in that case? I think the label =
format would depend
on the ISCD, and as we might have several ISCD, having several Available =
Label sub-TLV make sense.
This also apply to 3.3. Shared Backup Labels.

[Fatai] This "may" should be "MAY" according to Lou's suggestion, so it =
does not prevent you to have several available label sub-TLVs.=20



[Cyril] Stating =A1=B0The Available Labels sub-TLV   MAY  occur more =
than once within the link TLV.=A1=B1  Would be more accurate and easier =
to understand.

=20


In case of several ISCD are present for a given advertisement how to =
interpret the label format in the
label-related sub-TLVs?


[Fatai] It is easy to achive that. e.g, in SDH network, a node can =
advertise several ISCDs with one or multiple label sub-TLVs (I assume =
"IF" label information is needed to be advertised here), why it cannot =
interpret the labels are SDH labels?

[Cyril]  If there is 2 ISCD sub-TLV and 2 available label sub-TLV, how =
to tell which available label sub-TLV relate to which ISCD sub-TLV?

=20


Could you clarify this point, it would be useful for instance to =
consider the example of a link supporting SDH
(no VC4-switching), ODU (G.709, as of RFC4328, and for the current G.709 =
v3 label format).

=20

[Fatai]  Do you mean to have an example on hybrid node? I will not use a =
complex example to explain a kind of simple thing (It will confuse =
people).=20

[Cyril] It may not be so simple, I have trouble to interpret label =
without knowing the ISCD considered and I do not see clearly the =
relation between the two in the document.


The text is very focused on WSON, while it is a very interesting =
example, having other technology (OTN for
example would help to show that the solution is generic.

[Fatai] I think one typical example is sufficient for people to =
understand things. TDM network is different from WSON network. In TDM =
network, usually it will not advertise label information even though =
label information could be advertised.

[Cyril] They are indeed different, but from label point of view it =
should not make a difference. A usual use case of connectivity matrix =
would be for example on client cards with switching restriction : fixed =
Multiplex and label assignment due to the fixed MUX (ODU2->ODU1 for =
instance)  on DWDM node :

the restriction can be modeled as one connectivity matrix per client =
port,

        the client port have then ISCD TDM,=20

        the other ports can do DWDM and TDM,=20

        for the connectivity matrix corresponding to a client port the =
only ODU label to be assigned (due to fixed MUX) is specified=20

=20

First, is this modeling correct?=20

Second, how to make sure the label restriction are to be interpreted as =
ODU labels?

=20

I think it is also important to show that the extensions are also =
working outside the framework they were born (WSON).

=20

BR



Best Regards,
Cyril

> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of ext Zhangfatai
> Sent: Thursday, September 22, 2011 11:17 AM
> To: ccamp@ietf.org
> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-
> constraints-ospf-te-02.txt
>
> Hi CCAMPers,
>
> A new version has been submitted to address the comments from the WG
> discussion.
>
> We accepted Acee and Young's suggestion to introduce a new top-level
> node TLV (Generic Node Attribute TLV) to simplify things and a new
> section (Section 5) was added to describe scalability issue.
>
> More information from: http://www.ietf.org/id/draft-ietf-ccamp-gmpls-
> general-constraints-ospf-te-02.txt
>
> Please check out for details and comments are always welcome.
>
>
> Thanks
>
> Fatai
>
>
> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of internet-drafts@ietf.org
> Sent: 2011=C4=EA9=D4=C222=C8=D5 17:06
> To: i-d-announce@ietf.org
> Cc: ccamp@ietf.org
> Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-
> constraints-ospf-te-02.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Common Control and
> Measurement Plane Working Group of the IETF.
>
>       Title           : OSPF-TE Extensions for General Network Element
> Constraints
>       Author(s)       : Fatai Zhang
>                           Young Lee
>                           Jianrui Han
>                           Greg Bernstein
>                           Yunbin Xu
>       Filename        : draft-ietf-ccamp-gmpls-general-constraints-
> ospf-te-02.txt
>       Pages           : 14
>       Date            : 2011-09-22
>
>    Generalized Multiprotocol Label Switching can be used to control a
>    wide variety of technologies including packet switching (e.g.,
> MPLS),
>    time-division (e.g., SONET/SDH, OTN), wavelength (lambdas), and
>    spatial switching (e.g., incoming port or fiber to outgoing port or
>    fiber). 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 describes OSPF routing protocol extensions
> to
>    support these kinds of constraints under the control of Generalized
>    MPLS (GMPLS).
>
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-general-
> constraints-ospf-te-02.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-general-
> constraints-ospf-te-02.txt
> _______________________________________________
> 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


------_=_NextPart_001_01CC7CF9.42FD745B
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable


Hi, 
 
Thanks for the answer, 
 
Please see inline
 
 
From:=
 =
ext Zhangfatai [mailto:zhangfatai@huawei.com] 
Sent: Tuesday, =
September 27, 2011 11:17 AM
To: Margaria, Cyril (NSN - =
DE/Munich); ccamp@ietf.org
Subject: =B4=F0=B8=B4: [CCAMP] =
I-D Action: =
draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt
 
=
Hi Cyril,

Thanks for your commets.

Please see in-line =
below.


Fatai

Thanks



____________________=
____________________
=B7=A2=BC=FE=C8=CB=
: Margaria, Cyril (NSN - DE/Munich) =
[cyril.margaria@nsn.com]
=B7=A2=CB=CD=CA=B1=BC=E4=
: 2011=C4=EA=
9=D4=C2=
26=C8=D5=
 16:03
=B5=BD=
: Zhangfatai; ccamp@ietf.org
=D6=F7=CC=E2=
: RE: [CCAMP] I-D Action: =
draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt

Hi,
<=
br>I have the following comments/question regarding this =
revision

3.2. Available Labels:

The text state : =A1=B0The =
Available Labels sub-TLV   may occur at most once within the =
link TLV.=A1=B1

How to encode different label format in that =
case? I think the label format would depend
on the ISCD, and as we =
might have several ISCD, having several Available Label sub-TLV make =
sense.
This also apply to 3.3. Shared Backup =
Labels.

[=
Fatai] This "may" should be "MAY" according to Lou's =
suggestion, so it does not prevent you to have several available label =
sub-TLVs. =


[Cyril] Stating =A1=B0The Available Labels sub-TLV   MAY =
 occur more than once within the link TLV.=A1=B1  Would be =
more accurate and easier to understand.
 
=

In case of several ISCD are present for a given advertisement how to =
interpret the label format in the
label-related =
sub-TLVs?
=

[=
Fatai] It is easy to achive that. e.g, in SDH network, a node can =
advertise several ISCDs with one or multiple label sub-TLVs (I =
assume "IF" label information is needed to be advertised =
here), why it cannot interpret the labels are SDH labels?=

[Cyril]  If there is 2 ISCD sub-TLV and 2 available label =
sub-TLV, how to tell which available label sub-TLV relate to which ISCD =
sub-TLV?
 
=

Could you clarify this point, it would be useful for instance to =
consider the example of a link supporting SDH
(no VC4-switching), ODU =
(G.709, as of RFC4328, and for the current G.709 v3 label =
format).
=
 
[=
Fatai]  Do you mean to have an example on hybrid node? I will =
not use a complex example to explain a kind of =
simple thing (It will confuse people). =

[Cyril] It may not be so simple, I have trouble to interpret label =
without knowing the ISCD considered and I do not see clearly the =
relation between the two in the document.
=

The text is very focused on WSON, while it is a very interesting =
example, having other technology (OTN for
example would help to show =
that the solution is generic.
[=
Fatai] I think one typical example is sufficient for people to =
understand things. TDM network is different from WSON network. In =
TDM network, usually it will not advertise label information even though =
label information could be advertised.=

[Cyril] They are indeed different, but from label point of view it =
should not make a difference. A usual use case of connectivity matrix =
would be for example on client cards with switching restriction : fixed =
Multiplex and label assignment due to the fixed MUX (ODU2->ODU1 for =
instance)  on DWDM node :
the restriction can be modeled as one connectivity matrix per client =
port,
        the client port have then =
ISCD TDM, 
        the other ports can do =
DWDM and TDM, 
        for the connectivity =
matrix corresponding to a client port the only ODU label to be assigned =
(due to fixed MUX) is specified 
 
First, is this modeling correct? 
Second, how to make sure the label restriction are to be interpreted =
as ODU labels?
 
I think it is also important to show that the extensions are also =
working outside the framework they were born =
(WSON).
 
BR
=


Best Regards,
Cyril

> -----Original =
Message-----
> From: ccamp-bounces@ietf.org =
[mailto:ccamp-bounces@ietf.org] On Behalf
> Of ext =
Zhangfatai
> Sent: Thursday, September 22, 2011 11:17 AM
> =
To: ccamp@ietf.org
> Subject: Re: [CCAMP] I-D Action: =
draft-ietf-ccamp-gmpls-general-
> =
constraints-ospf-te-02.txt
>
> Hi CCAMPers,
>
> =
A new version has been submitted to address the comments from the =
WG
> discussion.
>
> We accepted Acee and Young's =
suggestion to introduce a new top-level
> node TLV (Generic Node =
Attribute TLV) to simplify things and a new
> section (Section 5) =
was added to describe scalability issue.
>
> More =
information from: http://www.ietf.org/id/draft-ietf-ccamp-gmpls-
> =
general-constraints-ospf-te-02.txt
>
> Please check out for =
details and comments are always welcome.
>
>
> =
Thanks
>
> Fatai
>
>
> -----Original =
Message-----
> From: ccamp-bounces@ietf.org =
[mailto:ccamp-bounces@ietf.org] On Behalf
> Of =
internet-drafts@ietf.org
> Sent: 2011=C4=EA=
9=D4=C2=
22=C8=D5=
 17:06
> To: i-d-announce@ietf.org
> Cc: =
ccamp@ietf.org
> Subject: [CCAMP] I-D Action: =
draft-ietf-ccamp-gmpls-general-
> =
constraints-ospf-te-02.txt
>
> A New Internet-Draft is =
available from the on-line Internet-Drafts
> directories. This =
draft is a work item of the Common Control and
> Measurement Plane =
Working Group of the =
IETF.
>
>       =
Title           : =
OSPF-TE Extensions for General Network Element
> =
Constraints
>       =
Author(s)       : Fatai =
Zhang
>          =
            &=
nbsp;    Young =
Lee
>          &n=
bsp;           &nb=
sp;    Jianrui =
Han
>          &n=
bsp;           &nb=
sp;    Greg =
Bernstein
>         &n=
bsp;           &nb=
sp;     Yunbin =
Xu
>       =
Filename        : =
draft-ietf-ccamp-gmpls-general-constraints-
> =
ospf-te-02.txt
>       =
Pages           : =
14
>       =
Date            : =
2011-09-22
>
>    Generalized Multiprotocol =
Label Switching can be used to control a
>    wide =
variety of technologies including packet switching (e.g.,
> =
MPLS),
>    time-division (e.g., SONET/SDH, OTN), =
wavelength (lambdas), and
>    spatial switching =
(e.g., incoming port or fiber to outgoing port =
or
>    fiber). 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 describes =
OSPF routing protocol extensions
> to
>    =
support these kinds of constraints under the control of =
Generalized
>    MPLS =
(GMPLS).
>
>
>
> A URL for this Internet-Draft =
is:
> =
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-general-
&g=
t; constraints-ospf-te-02.txt
>
> Internet-Drafts are also =
available by anonymous FTP at:
> =
ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft =
can be retrieved at:
> =
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-general-
>=
; constraints-ospf-te-02.txt
> =
_______________________________________________
> 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

------_=_NextPart_001_01CC7CF9.42FD745B--

From lberger@labn.net  Tue Sep 27 06:17:43 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84BCB21F8CC1 for ; Tue, 27 Sep 2011 06:17:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.864
X-Spam-Level: 
X-Spam-Status: No, score=-100.864 tagged_above=-999 required=5 tests=[AWL=-0.703, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hS4FYmrknMl1 for ; Tue, 27 Sep 2011 06:17:43 -0700 (PDT)
Received: from oproxy3-pub.bluehost.com (oproxy3.bluehost.com [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id D7E4421F8C57 for ; Tue, 27 Sep 2011 06:17:42 -0700 (PDT)
Received: (qmail 20109 invoked by uid 0); 27 Sep 2011 13:20:26 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy3.bluehost.com with SMTP; 27 Sep 2011 13:20:26 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default;  h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=8muXCtNMlX7Apnzc7xSwAiQHc3rj8JpJJSs41cDT4/I=;  b=LuNwUO3V69cAbO8zzW9b1B/lgd3y72ocWoXbW5XJn84nOZhsZ+uefdB+JHkSWHRZMY4eS+zkjIqCb+BslsR6eJroR2gwXDnG/IsaV4RQ03sh477NjauFqMp/Wvph1iyc;
Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1R8XaE-00044b-By for ccamp@ietf.org; Tue, 27 Sep 2011 07:20:26 -0600
Message-ID: <4E81CD97.3020209@labn.net>
Date: Tue, 27 Sep 2011 09:20:23 -0400
From: Lou Berger 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: CCAMP 
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Subject: [CCAMP] Thought on where to carry G.709-v3 TSG
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Sep 2011 13:17:43 -0000

All / G.709 draft authors,

	We have a few slightly unaligned proposals on where to indicate the
[G.709-v3] Tributary Slot Granularity:

1: G-PID
    draft-ietf-ccamp-otn-g709-info-model-01 says:
    One possible solution is the G-PID field of the GENERALIZED LABEL
    REQUEST Object.

2: A new field:
   draft-ceccarelli-ccamp-gmpls-ospf-g709-07 says:
      - TSG: Tributary Slot Granularity (2bit): Used for the
      advertisement of the supported Tributary Slot granularity

3: Implicitly:
   draft-zhang-ccamp-gmpls-evolving-g709-09 doesn't explicitly
   signal TSG, but rather has it implied in the new ODU label.

Some other alternatives include:

4: GMPLS Encoding
   Currently used to indicate G.709 (which is also what the Switch
   cap essentially indicates) An alternative would use:
      12              G.709 ODUk (Digital Path, 2.5G)[RFC4328]
      TBA (e.g., 15)  G.709 ODUk (Digital Path, 1.25G)

   In routing, 15 would imply support for both 1.25 and 2.5G, as
   support for both by 1.25 capable interfaces is required by
   [G.709-v3]. (At least as I understand it.)

5: Signal Type
   Carried in routing ISCD/SCSI and signaling traffic parameters.
   Could enumerate all ODUx types to indicate either 1.25G or 2.5G.
   Existing types indicate 2.5G, new types would need to be enumerated
   for the new 1.25 and 2.5 types.  Hereto, the 1.25 types would imply
   support for both 1.25 and 2.5 types in routing.

As I understand it, TSG is needed at:
  (a) the endpoints that terminate the signal/LSP to ensure proper
      adaptation.
  (b) the 2nd and penultimate hops to ensure the proper
      interface/H-LSP selection.
  (c) Intermediate nodes for proper TS allocation.

It seems to me that we have enough existing fields in GMPLS (for G.709)
that we should consider these before introducing new ones.  Of the
existing fields, we have 1, 4 and 5.:

   Option 1, G-PID, is really designed to support end-point client
   adaptation, so as an end-point only field it really only supports
   need (a), so I don't think G-PID is the right place to indicate TSG.

   Option 4, Encoding, is used to support (a) and (b)-type checks in
   GMPLS, but not (c).  So, while this field is definitely a better
   place than G-PID to indicate TSG, it doesn't satisfy all the needs.

   Option 5, Signal Type, is used to support all needs.

Given all this, I'd like to propose that we use Option 5, Signal Type,
to indicate TSG, and that this be reflected in the relevant WG drafts.
(Authors, let me know if you'd like specific text proposals.)

Comments?

Much thanks,
Lou (as WG contributor)


From jdrake@juniper.net  Tue Sep 27 07:24:31 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F5BE21F8CBD for ; Tue, 27 Sep 2011 07:24:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.158
X-Spam-Level: 
X-Spam-Status: No, score=-6.158 tagged_above=-999 required=5 tests=[AWL=0.441,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6cJl5x8hAgb for ; Tue, 27 Sep 2011 07:24:31 -0700 (PDT)
Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id B734D21F8D50 for ; Tue, 27 Sep 2011 07:24:30 -0700 (PDT)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKToHdQrR88Py9ePCG0V2BNBSkTRMQc/6j@postini.com; Tue, 27 Sep 2011 07:27:16 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 27 Sep 2011 07:23:06 -0700
From: John E Drake 
To: Lou Berger , CCAMP 
Date: Tue, 27 Sep 2011 07:23:05 -0700
Thread-Topic: [CCAMP] Thought on where to carry G.709-v3 TSG
Thread-Index: Acx9GEIXgPgXg83DQFmsEU66LpzYCwAB30IQ
Message-ID: <5E893DB832F57341992548CDBB333163A28E05ED10@EMBX01-HQ.jnpr.net>
References: <4E81CD97.3020209@labn.net>
In-Reply-To: <4E81CD97.3020209@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
Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Sep 2011 14:24:31 -0000

Lou,

In routing (draft-ceccarelli-ccamp-gmpls-ospf-g709-07) we advertise tributa=
ry slot granularity in a new field.  In signaling (draft-zhang-ccamp-gmpls-=
evolving-g709-09), it is derived from the length of the TS bit map and the =
size of the ODUk/OTUk on which the LSP is to be established.

Thanks,

John

> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of Lou Berger
> Sent: Tuesday, September 27, 2011 9:20 AM
> To: CCAMP
> Subject: [CCAMP] Thought on where to carry G.709-v3 TSG
>=20
> All / G.709 draft authors,
>=20
> 	We have a few slightly unaligned proposals on where to indicate
> the
> [G.709-v3] Tributary Slot Granularity:
>=20
> 1: G-PID
>     draft-ietf-ccamp-otn-g709-info-model-01 says:
>     One possible solution is the G-PID field of the GENERALIZED LABEL
>     REQUEST Object.
>=20
> 2: A new field:
>    draft-ceccarelli-ccamp-gmpls-ospf-g709-07 says:
>       - TSG: Tributary Slot Granularity (2bit): Used for the
>       advertisement of the supported Tributary Slot granularity
>=20
> 3: Implicitly:
>    draft-zhang-ccamp-gmpls-evolving-g709-09 doesn't explicitly
>    signal TSG, but rather has it implied in the new ODU label.
>=20
> Some other alternatives include:
>=20
> 4: GMPLS Encoding
>    Currently used to indicate G.709 (which is also what the Switch
>    cap essentially indicates) An alternative would use:
>       12              G.709 ODUk (Digital Path, 2.5G)[RFC4328]
>       TBA (e.g., 15)  G.709 ODUk (Digital Path, 1.25G)
>=20
>    In routing, 15 would imply support for both 1.25 and 2.5G, as
>    support for both by 1.25 capable interfaces is required by
>    [G.709-v3]. (At least as I understand it.)
>=20
> 5: Signal Type
>    Carried in routing ISCD/SCSI and signaling traffic parameters.
>    Could enumerate all ODUx types to indicate either 1.25G or 2.5G.
>    Existing types indicate 2.5G, new types would need to be enumerated
>    for the new 1.25 and 2.5 types.  Hereto, the 1.25 types would imply
>    support for both 1.25 and 2.5 types in routing.
>=20
> As I understand it, TSG is needed at:
>   (a) the endpoints that terminate the signal/LSP to ensure proper
>       adaptation.
>   (b) the 2nd and penultimate hops to ensure the proper
>       interface/H-LSP selection.
>   (c) Intermediate nodes for proper TS allocation.
>=20
> It seems to me that we have enough existing fields in GMPLS (for G.709)
> that we should consider these before introducing new ones.  Of the
> existing fields, we have 1, 4 and 5.:
>=20
>    Option 1, G-PID, is really designed to support end-point client
>    adaptation, so as an end-point only field it really only supports
>    need (a), so I don't think G-PID is the right place to indicate TSG.
>=20
>    Option 4, Encoding, is used to support (a) and (b)-type checks in
>    GMPLS, but not (c).  So, while this field is definitely a better
>    place than G-PID to indicate TSG, it doesn't satisfy all the needs.
>=20
>    Option 5, Signal Type, is used to support all needs.
>=20
> Given all this, I'd like to propose that we use Option 5, Signal Type,
> to indicate TSG, and that this be reflected in the relevant WG drafts.
> (Authors, let me know if you'd like specific text proposals.)
>=20
> Comments?
>=20
> Much thanks,
> Lou (as WG contributor)
>=20
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp

From lberger@labn.net  Tue Sep 27 07:29:19 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C48C21F8BAC for ; Tue, 27 Sep 2011 07:29:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.853
X-Spam-Level: 
X-Spam-Status: No, score=-100.853 tagged_above=-999 required=5 tests=[AWL=-0.692, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huIzu9Cz2PM2 for ; Tue, 27 Sep 2011 07:29:18 -0700 (PDT)
Received: from oproxy3-pub.bluehost.com (oproxy3.bluehost.com [IPv6:2605:dc00:100:2::a3]) by ietfa.amsl.com (Postfix) with SMTP id E350B21F8CDB for ; Tue, 27 Sep 2011 07:29:09 -0700 (PDT)
Received: (qmail 30919 invoked by uid 0); 27 Sep 2011 14:31:54 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy3.bluehost.com with SMTP; 27 Sep 2011 14:31:54 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default;  h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=+51ktNvf2hy37RL8a5kQtExgUrDL/bFr4wvXxVa9oro=;  b=m8Dgl+IwWGynQJDgVvVgCC7iNvf2roBqdrAbsFMgQ6087pByw+KYDGaE6GQaL9M8anhgYF33EtYsHBeXo5jRupa0/+COnZKGVHA/IjA+Su64HGdmwqzAJ2hc1N7TMqtk;
Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1R8YhO-00044P-9B; Tue, 27 Sep 2011 08:31:54 -0600
Message-ID: <4E81DE57.1080601@labn.net>
Date: Tue, 27 Sep 2011 10:31:51 -0400
From: Lou Berger 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: John E Drake 
References: <4E81CD97.3020209@labn.net> <5E893DB832F57341992548CDBB333163A28E05ED10@EMBX01-HQ.jnpr.net>
In-Reply-To: <5E893DB832F57341992548CDBB333163A28E05ED10@EMBX01-HQ.jnpr.net>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Cc: CCAMP 
Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Sep 2011 14:29:19 -0000

John,
	I guess I should have titled my mail "Proposal on..." so that the
proposal would actually get read...

Lou


On 9/27/2011 10:23 AM, John E Drake wrote:
> Lou,
> 
> In routing (draft-ceccarelli-ccamp-gmpls-ospf-g709-07) we advertise
> tributary slot granularity in a new field.  In signaling
> (draft-zhang-ccamp-gmpls-evolving-g709-09), it is derived from the
> length of the TS bit map and the size of the ODUk/OTUk on which the
> LSP is to be established.
> 
> Thanks,
> 
> John
> 
>> -----Original Message-----
>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
>> Of Lou Berger
>> Sent: Tuesday, September 27, 2011 9:20 AM
>> To: CCAMP
>> Subject: [CCAMP] Thought on where to carry G.709-v3 TSG
>>
>> All / G.709 draft authors,
>>
>> 	We have a few slightly unaligned proposals on where to indicate
>> the
>> [G.709-v3] Tributary Slot Granularity:
>>
>> 1: G-PID
>>     draft-ietf-ccamp-otn-g709-info-model-01 says:
>>     One possible solution is the G-PID field of the GENERALIZED LABEL
>>     REQUEST Object.
>>
>> 2: A new field:
>>    draft-ceccarelli-ccamp-gmpls-ospf-g709-07 says:
>>       - TSG: Tributary Slot Granularity (2bit): Used for the
>>       advertisement of the supported Tributary Slot granularity
>>
>> 3: Implicitly:
>>    draft-zhang-ccamp-gmpls-evolving-g709-09 doesn't explicitly
>>    signal TSG, but rather has it implied in the new ODU label.
>>
>> Some other alternatives include:
>>
>> 4: GMPLS Encoding
>>    Currently used to indicate G.709 (which is also what the Switch
>>    cap essentially indicates) An alternative would use:
>>       12              G.709 ODUk (Digital Path, 2.5G)[RFC4328]
>>       TBA (e.g., 15)  G.709 ODUk (Digital Path, 1.25G)
>>
>>    In routing, 15 would imply support for both 1.25 and 2.5G, as
>>    support for both by 1.25 capable interfaces is required by
>>    [G.709-v3]. (At least as I understand it.)
>>
>> 5: Signal Type
>>    Carried in routing ISCD/SCSI and signaling traffic parameters.
>>    Could enumerate all ODUx types to indicate either 1.25G or 2.5G.
>>    Existing types indicate 2.5G, new types would need to be enumerated
>>    for the new 1.25 and 2.5 types.  Hereto, the 1.25 types would imply
>>    support for both 1.25 and 2.5 types in routing.
>>
>> As I understand it, TSG is needed at:
>>   (a) the endpoints that terminate the signal/LSP to ensure proper
>>       adaptation.
>>   (b) the 2nd and penultimate hops to ensure the proper
>>       interface/H-LSP selection.
>>   (c) Intermediate nodes for proper TS allocation.
>>
>> It seems to me that we have enough existing fields in GMPLS (for G.709)
>> that we should consider these before introducing new ones.  Of the
>> existing fields, we have 1, 4 and 5.:
>>
>>    Option 1, G-PID, is really designed to support end-point client
>>    adaptation, so as an end-point only field it really only supports
>>    need (a), so I don't think G-PID is the right place to indicate TSG.
>>
>>    Option 4, Encoding, is used to support (a) and (b)-type checks in
>>    GMPLS, but not (c).  So, while this field is definitely a better
>>    place than G-PID to indicate TSG, it doesn't satisfy all the needs.
>>
>>    Option 5, Signal Type, is used to support all needs.
>>
>> Given all this, I'd like to propose that we use Option 5, Signal Type,
>> to indicate TSG, and that this be reflected in the relevant WG drafts.
>> (Authors, let me know if you'd like specific text proposals.)
>>
>> Comments?
>>
>> Much thanks,
>> Lou (as WG contributor)
>>
>> _______________________________________________
>> CCAMP mailing list
>> CCAMP@ietf.org
>> https://www.ietf.org/mailman/listinfo/ccamp
> 
> 
> 
> 

From jdrake@juniper.net  Tue Sep 27 07:38:26 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21F0C21F8D6F for ; Tue, 27 Sep 2011 07:38:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.162
X-Spam-Level: 
X-Spam-Status: No, score=-6.162 tagged_above=-999 required=5 tests=[AWL=0.437,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkvyESvmLVyI for ; Tue, 27 Sep 2011 07:38:25 -0700 (PDT)
Received: from exprod7og110.obsmtp.com (exprod7og110.obsmtp.com [64.18.2.173]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0BA21F8CC9 for ; Tue, 27 Sep 2011 07:38:23 -0700 (PDT)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP ID DSNKToHghfjMixLSyceh+R3sL/ZYPFD/0Esw@postini.com; Tue, 27 Sep 2011 07:41:11 PDT
Received: from P-EMHUB11-HQ.jnpr.net (172.24.192.58) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.83.0; Tue, 27 Sep 2011 07:37:20 -0700
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB11-HQ.jnpr.net ([::1]) with mapi; Tue, 27 Sep 2011 07:37:20 -0700
From: John E Drake 
To: Lou Berger 
Date: Tue, 27 Sep 2011 07:37:18 -0700
Thread-Topic: [CCAMP] Thought on where to carry G.709-v3 TSG
Thread-Index: Acx9IjYEvfqGAdNpSlKaQX4SsHqO1QAAEVHA
Message-ID: <5E893DB832F57341992548CDBB333163A28E05ED28@EMBX01-HQ.jnpr.net>
References: <4E81CD97.3020209@labn.net> <5E893DB832F57341992548CDBB333163A28E05ED10@EMBX01-HQ.jnpr.net> <4E81DE57.1080601@labn.net>
In-Reply-To: <4E81DE57.1080601@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
Cc: CCAMP 
Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Sep 2011 14:38:26 -0000

Nevermind.  What is wrong with the current signaling approach, which by the=
 way I think is great?

> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Tuesday, September 27, 2011 10:32 AM
> To: John E Drake
> Cc: CCAMP
> Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG
>=20
> John,
> 	I guess I should have titled my mail "Proposal on..." so that the
> proposal would actually get read...
>=20
> Lou
>=20
>=20
> On 9/27/2011 10:23 AM, John E Drake wrote:
> > Lou,
> >
> > In routing (draft-ceccarelli-ccamp-gmpls-ospf-g709-07) we advertise
> > tributary slot granularity in a new field.  In signaling
> > (draft-zhang-ccamp-gmpls-evolving-g709-09), it is derived from the
> > length of the TS bit map and the size of the ODUk/OTUk on which the
> > LSP is to be established.
> >
> > Thanks,
> >
> > John
> >
> >> -----Original Message-----
> >> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On
> Behalf
> >> Of Lou Berger
> >> Sent: Tuesday, September 27, 2011 9:20 AM
> >> To: CCAMP
> >> Subject: [CCAMP] Thought on where to carry G.709-v3 TSG
> >>
> >> All / G.709 draft authors,
> >>
> >> 	We have a few slightly unaligned proposals on where to indicate
> >> the
> >> [G.709-v3] Tributary Slot Granularity:
> >>
> >> 1: G-PID
> >>     draft-ietf-ccamp-otn-g709-info-model-01 says:
> >>     One possible solution is the G-PID field of the GENERALIZED
> LABEL
> >>     REQUEST Object.
> >>
> >> 2: A new field:
> >>    draft-ceccarelli-ccamp-gmpls-ospf-g709-07 says:
> >>       - TSG: Tributary Slot Granularity (2bit): Used for the
> >>       advertisement of the supported Tributary Slot granularity
> >>
> >> 3: Implicitly:
> >>    draft-zhang-ccamp-gmpls-evolving-g709-09 doesn't explicitly
> >>    signal TSG, but rather has it implied in the new ODU label.
> >>
> >> Some other alternatives include:
> >>
> >> 4: GMPLS Encoding
> >>    Currently used to indicate G.709 (which is also what the Switch
> >>    cap essentially indicates) An alternative would use:
> >>       12              G.709 ODUk (Digital Path, 2.5G)[RFC4328]
> >>       TBA (e.g., 15)  G.709 ODUk (Digital Path, 1.25G)
> >>
> >>    In routing, 15 would imply support for both 1.25 and 2.5G, as
> >>    support for both by 1.25 capable interfaces is required by
> >>    [G.709-v3]. (At least as I understand it.)
> >>
> >> 5: Signal Type
> >>    Carried in routing ISCD/SCSI and signaling traffic parameters.
> >>    Could enumerate all ODUx types to indicate either 1.25G or 2.5G.
> >>    Existing types indicate 2.5G, new types would need to be
> enumerated
> >>    for the new 1.25 and 2.5 types.  Hereto, the 1.25 types would
> imply
> >>    support for both 1.25 and 2.5 types in routing.
> >>
> >> As I understand it, TSG is needed at:
> >>   (a) the endpoints that terminate the signal/LSP to ensure proper
> >>       adaptation.
> >>   (b) the 2nd and penultimate hops to ensure the proper
> >>       interface/H-LSP selection.
> >>   (c) Intermediate nodes for proper TS allocation.
> >>
> >> It seems to me that we have enough existing fields in GMPLS (for
> G.709)
> >> that we should consider these before introducing new ones.  Of the
> >> existing fields, we have 1, 4 and 5.:
> >>
> >>    Option 1, G-PID, is really designed to support end-point client
> >>    adaptation, so as an end-point only field it really only supports
> >>    need (a), so I don't think G-PID is the right place to indicate
> TSG.
> >>
> >>    Option 4, Encoding, is used to support (a) and (b)-type checks in
> >>    GMPLS, but not (c).  So, while this field is definitely a better
> >>    place than G-PID to indicate TSG, it doesn't satisfy all the
> needs.
> >>
> >>    Option 5, Signal Type, is used to support all needs.
> >>
> >> Given all this, I'd like to propose that we use Option 5, Signal
> Type,
> >> to indicate TSG, and that this be reflected in the relevant WG
> drafts.
> >> (Authors, let me know if you'd like specific text proposals.)
> >>
> >> Comments?
> >>
> >> Much thanks,
> >> Lou (as WG contributor)
> >>
> >> _______________________________________________
> >> CCAMP mailing list
> >> CCAMP@ietf.org
> >> https://www.ietf.org/mailman/listinfo/ccamp
> >
> >
> >
> >

From lberger@labn.net  Tue Sep 27 07:55:41 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C2621F8DE4 for ; Tue, 27 Sep 2011 07:55:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.843
X-Spam-Level: 
X-Spam-Status: No, score=-100.843 tagged_above=-999 required=5 tests=[AWL=-0.682, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4de1PnfqZYa for ; Tue, 27 Sep 2011 07:55:40 -0700 (PDT)
Received: from oproxy4-pub.bluehost.com (oproxy4.bluehost.com [IPv6:2605:dc00:100:2::a4]) by ietfa.amsl.com (Postfix) with SMTP id CF87721F8D67 for ; Tue, 27 Sep 2011 07:55:37 -0700 (PDT)
Received: (qmail 14408 invoked by uid 0); 27 Sep 2011 14:58:22 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy1.bluehost.com with SMTP; 27 Sep 2011 14:58:21 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default;  h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=MtVPJpHvqRI6Jj4JXwCRyrD5Ul0PHPaHDHToDHSh3gU=;  b=KbHLsTLFr6kUlnl5DnhNQwL23S7OuidV6rk/LAU4lecwN+IwaP3u6OeVr/Ye8WPqxHP/AyOQeHbL6TXgzK0wqkXCCfPAApXZttpRTJRXfhBDZuVhy3bpapRYEAovZD3S;
Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1R8Z6z-0002Oe-Mk; Tue, 27 Sep 2011 08:58:21 -0600
Message-ID: <4E81E48B.8090102@labn.net>
Date: Tue, 27 Sep 2011 10:58:19 -0400
From: Lou Berger 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: John E Drake 
References: <4E81CD97.3020209@labn.net> <5E893DB832F57341992548CDBB333163A28E05ED10@EMBX01-HQ.jnpr.net> <4E81DE57.1080601@labn.net> <5E893DB832F57341992548CDBB333163A28E05ED28@EMBX01-HQ.jnpr.net>
In-Reply-To: <5E893DB832F57341992548CDBB333163A28E05ED28@EMBX01-HQ.jnpr.net>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Cc: CCAMP 
Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Sep 2011 14:55:41 -0000

John,
	There isn't alignment in the WG info-model and the individual routing
and signaling drafts.  I think we have enough ways of explicitly
carrying signal information that we can leverage to come up with a clean
an unified approach that satisfies all the needs for TSG information, i.e.:

> Given all this [see below], I'd like to propose that we use Option 5,
> Signal Type, to indicate TSG

Do you see an issue with using Signal Type to indicate the *service*
TSG?  I don't think there would be any change to your proposed
(hop-by-hop) label encoding.

Lou


On 9/27/2011 10:37 AM, John E Drake wrote:
> Nevermind.  What is wrong with the current signaling approach, which by the way I think is great?
> 
>> -----Original Message-----
>> From: Lou Berger [mailto:lberger@labn.net]
>> Sent: Tuesday, September 27, 2011 10:32 AM
>> To: John E Drake
>> Cc: CCAMP
>> Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG
>>
>> John,
>> 	I guess I should have titled my mail "Proposal on..." so that the
>> proposal would actually get read...
>>
>> Lou
>>
>>
>> On 9/27/2011 10:23 AM, John E Drake wrote:
>>> Lou,
>>>
>>> In routing (draft-ceccarelli-ccamp-gmpls-ospf-g709-07) we advertise
>>> tributary slot granularity in a new field.  In signaling
>>> (draft-zhang-ccamp-gmpls-evolving-g709-09), it is derived from the
>>> length of the TS bit map and the size of the ODUk/OTUk on which the
>>> LSP is to be established.
>>>
>>> Thanks,
>>>
>>> John
>>>
>>>> -----Original Message-----
>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On
>> Behalf
>>>> Of Lou Berger
>>>> Sent: Tuesday, September 27, 2011 9:20 AM
>>>> To: CCAMP
>>>> Subject: [CCAMP] Thought on where to carry G.709-v3 TSG
>>>>
>>>> All / G.709 draft authors,
>>>>
>>>> 	We have a few slightly unaligned proposals on where to indicate
>>>> the
>>>> [G.709-v3] Tributary Slot Granularity:
>>>>
>>>> 1: G-PID
>>>>     draft-ietf-ccamp-otn-g709-info-model-01 says:
>>>>     One possible solution is the G-PID field of the GENERALIZED
>> LABEL
>>>>     REQUEST Object.
>>>>
>>>> 2: A new field:
>>>>    draft-ceccarelli-ccamp-gmpls-ospf-g709-07 says:
>>>>       - TSG: Tributary Slot Granularity (2bit): Used for the
>>>>       advertisement of the supported Tributary Slot granularity
>>>>
>>>> 3: Implicitly:
>>>>    draft-zhang-ccamp-gmpls-evolving-g709-09 doesn't explicitly
>>>>    signal TSG, but rather has it implied in the new ODU label.
>>>>
>>>> Some other alternatives include:
>>>>
>>>> 4: GMPLS Encoding
>>>>    Currently used to indicate G.709 (which is also what the Switch
>>>>    cap essentially indicates) An alternative would use:
>>>>       12              G.709 ODUk (Digital Path, 2.5G)[RFC4328]
>>>>       TBA (e.g., 15)  G.709 ODUk (Digital Path, 1.25G)
>>>>
>>>>    In routing, 15 would imply support for both 1.25 and 2.5G, as
>>>>    support for both by 1.25 capable interfaces is required by
>>>>    [G.709-v3]. (At least as I understand it.)
>>>>
>>>> 5: Signal Type
>>>>    Carried in routing ISCD/SCSI and signaling traffic parameters.
>>>>    Could enumerate all ODUx types to indicate either 1.25G or 2.5G.
>>>>    Existing types indicate 2.5G, new types would need to be
>> enumerated
>>>>    for the new 1.25 and 2.5 types.  Hereto, the 1.25 types would
>> imply
>>>>    support for both 1.25 and 2.5 types in routing.
>>>>
>>>> As I understand it, TSG is needed at:
>>>>   (a) the endpoints that terminate the signal/LSP to ensure proper
>>>>       adaptation.
>>>>   (b) the 2nd and penultimate hops to ensure the proper
>>>>       interface/H-LSP selection.
>>>>   (c) Intermediate nodes for proper TS allocation.
>>>>
>>>> It seems to me that we have enough existing fields in GMPLS (for
>> G.709)
>>>> that we should consider these before introducing new ones.  Of the
>>>> existing fields, we have 1, 4 and 5.:
>>>>
>>>>    Option 1, G-PID, is really designed to support end-point client
>>>>    adaptation, so as an end-point only field it really only supports
>>>>    need (a), so I don't think G-PID is the right place to indicate
>> TSG.
>>>>
>>>>    Option 4, Encoding, is used to support (a) and (b)-type checks in
>>>>    GMPLS, but not (c).  So, while this field is definitely a better
>>>>    place than G-PID to indicate TSG, it doesn't satisfy all the
>> needs.
>>>>
>>>>    Option 5, Signal Type, is used to support all needs.
>>>>
>>>> Given all this, I'd like to propose that we use Option 5, Signal
>> Type,
>>>> to indicate TSG, and that this be reflected in the relevant WG
>> drafts.
>>>> (Authors, let me know if you'd like specific text proposals.)
>>>>
>>>> Comments?
>>>>
>>>> Much thanks,
>>>> Lou (as WG contributor)
>>>>
>>>> _______________________________________________
>>>> CCAMP mailing list
>>>> CCAMP@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>
>>>
>>>
>>>
> 
> 
> 
> 

From jdrake@juniper.net  Tue Sep 27 08:15:37 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 935E121F8E19 for ; Tue, 27 Sep 2011 08:15:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.166
X-Spam-Level: 
X-Spam-Status: No, score=-6.166 tagged_above=-999 required=5 tests=[AWL=0.433,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OTb7+hLvZXvr for ; Tue, 27 Sep 2011 08:15:36 -0700 (PDT)
Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id 1065721F8E18 for ; Tue, 27 Sep 2011 08:15:34 -0700 (PDT)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKToHpO26KQpoAFcWsZUQc7fCCjdCX5eea@postini.com; Tue, 27 Sep 2011 08:18:22 PDT
Received: from P-EMHUB11-HQ.jnpr.net (172.24.192.58) by P-EMHUB02-HQ.jnpr.net (172.24.192.36) with Microsoft SMTP Server (TLS) id 8.3.83.0; Tue, 27 Sep 2011 08:13:23 -0700
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB11-HQ.jnpr.net ([::1]) with mapi; Tue, 27 Sep 2011 08:13:22 -0700
From: John E Drake 
To: Lou Berger 
Date: Tue, 27 Sep 2011 08:13:20 -0700
Thread-Topic: [CCAMP] Thought on where to carry G.709-v3 TSG
Thread-Index: Acx9JekMUlrRKCh/TJ+U0+YrhxMqFgAAccOA
Message-ID: <5E893DB832F57341992548CDBB333163A28E05ED83@EMBX01-HQ.jnpr.net>
References: <4E81CD97.3020209@labn.net> <5E893DB832F57341992548CDBB333163A28E05ED10@EMBX01-HQ.jnpr.net> <4E81DE57.1080601@labn.net> <5E893DB832F57341992548CDBB333163A28E05ED28@EMBX01-HQ.jnpr.net> <4E81E48B.8090102@labn.net>
In-Reply-To: <4E81E48B.8090102@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
Cc: CCAMP 
Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Sep 2011 15:15:37 -0000

Lou,

Clearly, the info-model draft needs to be updated, but I am quite happy wit=
h the what is currently in the signaling and routing drafts and I haven't h=
eard a compelling reason to change.

Thanks,

John

> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Tuesday, September 27, 2011 10:58 AM
> To: John E Drake
> Cc: CCAMP
> Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG
>=20
> John,
> 	There isn't alignment in the WG info-model and the individual
> routing
> and signaling drafts.  I think we have enough ways of explicitly
> carrying signal information that we can leverage to come up with a
> clean
> an unified approach that satisfies all the needs for TSG information,
> i.e.:
>=20
> > Given all this [see below], I'd like to propose that we use Option 5,
> > Signal Type, to indicate TSG
>=20
> Do you see an issue with using Signal Type to indicate the *service*
> TSG?  I don't think there would be any change to your proposed
> (hop-by-hop) label encoding.
>=20
> Lou
>=20
>=20
> On 9/27/2011 10:37 AM, John E Drake wrote:
> > Nevermind.  What is wrong with the current signaling approach, which
> by the way I think is great?
> >
> >> -----Original Message-----
> >> From: Lou Berger [mailto:lberger@labn.net]
> >> Sent: Tuesday, September 27, 2011 10:32 AM
> >> To: John E Drake
> >> Cc: CCAMP
> >> Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG
> >>
> >> John,
> >> 	I guess I should have titled my mail "Proposal on..." so that the
> >> proposal would actually get read...
> >>
> >> Lou
> >>
> >>
> >> On 9/27/2011 10:23 AM, John E Drake wrote:
> >>> Lou,
> >>>
> >>> In routing (draft-ceccarelli-ccamp-gmpls-ospf-g709-07) we advertise
> >>> tributary slot granularity in a new field.  In signaling
> >>> (draft-zhang-ccamp-gmpls-evolving-g709-09), it is derived from the
> >>> length of the TS bit map and the size of the ODUk/OTUk on which the
> >>> LSP is to be established.
> >>>
> >>> Thanks,
> >>>
> >>> John
> >>>
> >>>> -----Original Message-----
> >>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On
> >> Behalf
> >>>> Of Lou Berger
> >>>> Sent: Tuesday, September 27, 2011 9:20 AM
> >>>> To: CCAMP
> >>>> Subject: [CCAMP] Thought on where to carry G.709-v3 TSG
> >>>>
> >>>> All / G.709 draft authors,
> >>>>
> >>>> 	We have a few slightly unaligned proposals on where to indicate
> >>>> the
> >>>> [G.709-v3] Tributary Slot Granularity:
> >>>>
> >>>> 1: G-PID
> >>>>     draft-ietf-ccamp-otn-g709-info-model-01 says:
> >>>>     One possible solution is the G-PID field of the GENERALIZED
> >> LABEL
> >>>>     REQUEST Object.
> >>>>
> >>>> 2: A new field:
> >>>>    draft-ceccarelli-ccamp-gmpls-ospf-g709-07 says:
> >>>>       - TSG: Tributary Slot Granularity (2bit): Used for the
> >>>>       advertisement of the supported Tributary Slot granularity
> >>>>
> >>>> 3: Implicitly:
> >>>>    draft-zhang-ccamp-gmpls-evolving-g709-09 doesn't explicitly
> >>>>    signal TSG, but rather has it implied in the new ODU label.
> >>>>
> >>>> Some other alternatives include:
> >>>>
> >>>> 4: GMPLS Encoding
> >>>>    Currently used to indicate G.709 (which is also what the Switch
> >>>>    cap essentially indicates) An alternative would use:
> >>>>       12              G.709 ODUk (Digital Path, 2.5G)[RFC4328]
> >>>>       TBA (e.g., 15)  G.709 ODUk (Digital Path, 1.25G)
> >>>>
> >>>>    In routing, 15 would imply support for both 1.25 and 2.5G, as
> >>>>    support for both by 1.25 capable interfaces is required by
> >>>>    [G.709-v3]. (At least as I understand it.)
> >>>>
> >>>> 5: Signal Type
> >>>>    Carried in routing ISCD/SCSI and signaling traffic parameters.
> >>>>    Could enumerate all ODUx types to indicate either 1.25G or
> 2.5G.
> >>>>    Existing types indicate 2.5G, new types would need to be
> >> enumerated
> >>>>    for the new 1.25 and 2.5 types.  Hereto, the 1.25 types would
> >> imply
> >>>>    support for both 1.25 and 2.5 types in routing.
> >>>>
> >>>> As I understand it, TSG is needed at:
> >>>>   (a) the endpoints that terminate the signal/LSP to ensure proper
> >>>>       adaptation.
> >>>>   (b) the 2nd and penultimate hops to ensure the proper
> >>>>       interface/H-LSP selection.
> >>>>   (c) Intermediate nodes for proper TS allocation.
> >>>>
> >>>> It seems to me that we have enough existing fields in GMPLS (for
> >> G.709)
> >>>> that we should consider these before introducing new ones.  Of the
> >>>> existing fields, we have 1, 4 and 5.:
> >>>>
> >>>>    Option 1, G-PID, is really designed to support end-point client
> >>>>    adaptation, so as an end-point only field it really only
> supports
> >>>>    need (a), so I don't think G-PID is the right place to indicate
> >> TSG.
> >>>>
> >>>>    Option 4, Encoding, is used to support (a) and (b)-type checks
> in
> >>>>    GMPLS, but not (c).  So, while this field is definitely a
> better
> >>>>    place than G-PID to indicate TSG, it doesn't satisfy all the
> >> needs.
> >>>>
> >>>>    Option 5, Signal Type, is used to support all needs.
> >>>>
> >>>> Given all this, I'd like to propose that we use Option 5, Signal
> >> Type,
> >>>> to indicate TSG, and that this be reflected in the relevant WG
> >> drafts.
> >>>> (Authors, let me know if you'd like specific text proposals.)
> >>>>
> >>>> Comments?
> >>>>
> >>>> Much thanks,
> >>>> Lou (as WG contributor)
> >>>>
> >>>> _______________________________________________
> >>>> CCAMP mailing list
> >>>> CCAMP@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/ccamp
> >>>
> >>>
> >>>
> >>>
> >
> >
> >
> >

From lberger@labn.net  Tue Sep 27 08:26:03 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3328921F8D7C for ; Tue, 27 Sep 2011 08:26:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.833
X-Spam-Level: 
X-Spam-Status: No, score=-100.833 tagged_above=-999 required=5 tests=[AWL=-0.672, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDdRxwEsrmBO for ; Tue, 27 Sep 2011 08:26:02 -0700 (PDT)
Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by ietfa.amsl.com (Postfix) with SMTP id 7085121F8D92 for ; Tue, 27 Sep 2011 08:26:02 -0700 (PDT)
Received: (qmail 19809 invoked by uid 0); 27 Sep 2011 15:28:48 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy1.bluehost.com with SMTP; 27 Sep 2011 15:28:48 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default;  h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=5USCOZlavG7oi+zaqWUk//2xcPEbyi1urmnDfcW7NeE=;  b=xVHLHoCCDyP0R4XnBCMZxJeQSO+GfdnPm3JeGPRWRG+qTtq9TSdPIVczkytPF7xw8K55M401co7XLPlJPLwUIy8TkH82SomghQwid938oikgtFthUvFuUMujqb78EhJ6;
Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1R8ZaR-0002ET-Pe; Tue, 27 Sep 2011 09:28:47 -0600
Message-ID: <4E81EBAD.1050204@labn.net>
Date: Tue, 27 Sep 2011 11:28:45 -0400
From: Lou Berger 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: John E Drake 
References: <4E81CD97.3020209@labn.net> <5E893DB832F57341992548CDBB333163A28E05ED10@EMBX01-HQ.jnpr.net> <4E81DE57.1080601@labn.net> <5E893DB832F57341992548CDBB333163A28E05ED28@EMBX01-HQ.jnpr.net> <4E81E48B.8090102@labn.net> <5E893DB832F57341992548CDBB333163A28E05ED83@EMBX01-HQ.jnpr.net>
In-Reply-To: <5E893DB832F57341992548CDBB333163A28E05ED83@EMBX01-HQ.jnpr.net>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Cc: CCAMP 
Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Sep 2011 15:26:03 -0000

John,
	Two points:

As a general rule, it doesn't make sense to invent yet another way to
carry information when an existing one will do.  This is actually a
pretty fundamental tenant of GMPLS.

Also, in GMPLS the general model for allocation is to carry resource
requirements in the TS not the label.  Such use of the TS ensures that
the information is unambiguous in all cases.  (For example, consider the
corner case where you have a unidirectional LSP, where is TSG
requirements of the sender/upstream node indicated in the Path message.)

Lou

On 9/27/2011 11:13 AM, John E Drake wrote:
> Lou,
> 
> Clearly, the info-model draft needs to be updated, but I am quite
> happy with the what is currently in the signaling and routing drafts
> and I haven't heard a compelling reason to change.
> 
> Thanks,
> 
> John
> 
>> -----Original Message-----
>> From: Lou Berger [mailto:lberger@labn.net]
>> Sent: Tuesday, September 27, 2011 10:58 AM
>> To: John E Drake
>> Cc: CCAMP
>> Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG
>>
>> John,
>> 	There isn't alignment in the WG info-model and the individual
>> routing
>> and signaling drafts.  I think we have enough ways of explicitly
>> carrying signal information that we can leverage to come up with a
>> clean
>> an unified approach that satisfies all the needs for TSG information,
>> i.e.:
>>
>>> Given all this [see below], I'd like to propose that we use Option 5,
>>> Signal Type, to indicate TSG
>>
>> Do you see an issue with using Signal Type to indicate the *service*
>> TSG?  I don't think there would be any change to your proposed
>> (hop-by-hop) label encoding.
>>
>> Lou
>>
>>
>> On 9/27/2011 10:37 AM, John E Drake wrote:
>>> Nevermind.  What is wrong with the current signaling approach, which
>> by the way I think is great?
>>>
>>>> -----Original Message-----
>>>> From: Lou Berger [mailto:lberger@labn.net]
>>>> Sent: Tuesday, September 27, 2011 10:32 AM
>>>> To: John E Drake
>>>> Cc: CCAMP
>>>> Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG
>>>>
>>>> John,
>>>> 	I guess I should have titled my mail "Proposal on..." so that the
>>>> proposal would actually get read...
>>>>
>>>> Lou
>>>>
>>>>
>>>> On 9/27/2011 10:23 AM, John E Drake wrote:
>>>>> Lou,
>>>>>
>>>>> In routing (draft-ceccarelli-ccamp-gmpls-ospf-g709-07) we advertise
>>>>> tributary slot granularity in a new field.  In signaling
>>>>> (draft-zhang-ccamp-gmpls-evolving-g709-09), it is derived from the
>>>>> length of the TS bit map and the size of the ODUk/OTUk on which the
>>>>> LSP is to be established.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> John
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On
>>>> Behalf
>>>>>> Of Lou Berger
>>>>>> Sent: Tuesday, September 27, 2011 9:20 AM
>>>>>> To: CCAMP
>>>>>> Subject: [CCAMP] Thought on where to carry G.709-v3 TSG
>>>>>>
>>>>>> All / G.709 draft authors,
>>>>>>
>>>>>> 	We have a few slightly unaligned proposals on where to indicate
>>>>>> the
>>>>>> [G.709-v3] Tributary Slot Granularity:
>>>>>>
>>>>>> 1: G-PID
>>>>>>     draft-ietf-ccamp-otn-g709-info-model-01 says:
>>>>>>     One possible solution is the G-PID field of the GENERALIZED
>>>> LABEL
>>>>>>     REQUEST Object.
>>>>>>
>>>>>> 2: A new field:
>>>>>>    draft-ceccarelli-ccamp-gmpls-ospf-g709-07 says:
>>>>>>       - TSG: Tributary Slot Granularity (2bit): Used for the
>>>>>>       advertisement of the supported Tributary Slot granularity
>>>>>>
>>>>>> 3: Implicitly:
>>>>>>    draft-zhang-ccamp-gmpls-evolving-g709-09 doesn't explicitly
>>>>>>    signal TSG, but rather has it implied in the new ODU label.
>>>>>>
>>>>>> Some other alternatives include:
>>>>>>
>>>>>> 4: GMPLS Encoding
>>>>>>    Currently used to indicate G.709 (which is also what the Switch
>>>>>>    cap essentially indicates) An alternative would use:
>>>>>>       12              G.709 ODUk (Digital Path, 2.5G)[RFC4328]
>>>>>>       TBA (e.g., 15)  G.709 ODUk (Digital Path, 1.25G)
>>>>>>
>>>>>>    In routing, 15 would imply support for both 1.25 and 2.5G, as
>>>>>>    support for both by 1.25 capable interfaces is required by
>>>>>>    [G.709-v3]. (At least as I understand it.)
>>>>>>
>>>>>> 5: Signal Type
>>>>>>    Carried in routing ISCD/SCSI and signaling traffic parameters.
>>>>>>    Could enumerate all ODUx types to indicate either 1.25G or
>> 2.5G.
>>>>>>    Existing types indicate 2.5G, new types would need to be
>>>> enumerated
>>>>>>    for the new 1.25 and 2.5 types.  Hereto, the 1.25 types would
>>>> imply
>>>>>>    support for both 1.25 and 2.5 types in routing.
>>>>>>
>>>>>> As I understand it, TSG is needed at:
>>>>>>   (a) the endpoints that terminate the signal/LSP to ensure proper
>>>>>>       adaptation.
>>>>>>   (b) the 2nd and penultimate hops to ensure the proper
>>>>>>       interface/H-LSP selection.
>>>>>>   (c) Intermediate nodes for proper TS allocation.
>>>>>>
>>>>>> It seems to me that we have enough existing fields in GMPLS (for
>>>> G.709)
>>>>>> that we should consider these before introducing new ones.  Of the
>>>>>> existing fields, we have 1, 4 and 5.:
>>>>>>
>>>>>>    Option 1, G-PID, is really designed to support end-point client
>>>>>>    adaptation, so as an end-point only field it really only
>> supports
>>>>>>    need (a), so I don't think G-PID is the right place to indicate
>>>> TSG.
>>>>>>
>>>>>>    Option 4, Encoding, is used to support (a) and (b)-type checks
>> in
>>>>>>    GMPLS, but not (c).  So, while this field is definitely a
>> better
>>>>>>    place than G-PID to indicate TSG, it doesn't satisfy all the
>>>> needs.
>>>>>>
>>>>>>    Option 5, Signal Type, is used to support all needs.
>>>>>>
>>>>>> Given all this, I'd like to propose that we use Option 5, Signal
>>>> Type,
>>>>>> to indicate TSG, and that this be reflected in the relevant WG
>>>> drafts.
>>>>>> (Authors, let me know if you'd like specific text proposals.)
>>>>>>
>>>>>> Comments?
>>>>>>
>>>>>> Much thanks,
>>>>>> Lou (as WG contributor)
>>>>>>
>>>>>> _______________________________________________
>>>>>> CCAMP mailing list
>>>>>> CCAMP@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>
> 
> 
> 
> 

From jdrake@juniper.net  Tue Sep 27 09:41:37 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E71E721F8E1C for ; Tue, 27 Sep 2011 09:41:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.169
X-Spam-Level: 
X-Spam-Status: No, score=-6.169 tagged_above=-999 required=5 tests=[AWL=0.430,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8tyMU6ZsG5MM for ; Tue, 27 Sep 2011 09:41:37 -0700 (PDT)
Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id CEAF721F8DB5 for ; Tue, 27 Sep 2011 09:41:36 -0700 (PDT)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKToH9Zf9h5rfVtXnB6A5XXh3JwDXV1Z8L@postini.com; Tue, 27 Sep 2011 09:44:23 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Tue, 27 Sep 2011 09:40:35 -0700
From: John E Drake 
To: Lou Berger 
Date: Tue, 27 Sep 2011 09:40:33 -0700
Thread-Topic: [CCAMP] Thought on where to carry G.709-v3 TSG
Thread-Index: Acx9Kig/BGXjMHrHRIq2npNfMCscKQACaaVA
Message-ID: <5E893DB832F57341992548CDBB333163A28E05EF17@EMBX01-HQ.jnpr.net>
References: <4E81CD97.3020209@labn.net> <5E893DB832F57341992548CDBB333163A28E05ED10@EMBX01-HQ.jnpr.net> <4E81DE57.1080601@labn.net> <5E893DB832F57341992548CDBB333163A28E05ED28@EMBX01-HQ.jnpr.net> <4E81E48B.8090102@labn.net> <5E893DB832F57341992548CDBB333163A28E05ED83@EMBX01-HQ.jnpr.net> <4E81EBAD.1050204@labn.net>
In-Reply-To: <4E81EBAD.1050204@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
Cc: CCAMP 
Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Sep 2011 16:41:38 -0000

Lou,

Using Signal Type in signaling in addition to the bit map label is probably=
 okay.  I don't think it makes any sense in routing and would prefer to con=
tinue to just have the two bits.

Thanks,

John

> -----Original Message-----
> From: Lou Berger [mailto:lberger@labn.net]
> Sent: Tuesday, September 27, 2011 11:29 AM
> To: John E Drake
> Cc: CCAMP
> Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG
>=20
> John,
> 	Two points:
>=20
> As a general rule, it doesn't make sense to invent yet another way to
> carry information when an existing one will do.  This is actually a
> pretty fundamental tenant of GMPLS.
>=20
> Also, in GMPLS the general model for allocation is to carry resource
> requirements in the TS not the label.  Such use of the TS ensures that
> the information is unambiguous in all cases.  (For example, consider
> the
> corner case where you have a unidirectional LSP, where is TSG
> requirements of the sender/upstream node indicated in the Path
> message.)
>=20
> Lou
>=20
> On 9/27/2011 11:13 AM, John E Drake wrote:
> > Lou,
> >
> > Clearly, the info-model draft needs to be updated, but I am quite
> > happy with the what is currently in the signaling and routing drafts
> > and I haven't heard a compelling reason to change.
> >
> > Thanks,
> >
> > John
> >
> >> -----Original Message-----
> >> From: Lou Berger [mailto:lberger@labn.net]
> >> Sent: Tuesday, September 27, 2011 10:58 AM
> >> To: John E Drake
> >> Cc: CCAMP
> >> Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG
> >>
> >> John,
> >> 	There isn't alignment in the WG info-model and the individual
> >> routing
> >> and signaling drafts.  I think we have enough ways of explicitly
> >> carrying signal information that we can leverage to come up with a
> >> clean
> >> an unified approach that satisfies all the needs for TSG
> information,
> >> i.e.:
> >>
> >>> Given all this [see below], I'd like to propose that we use Option
> 5,
> >>> Signal Type, to indicate TSG
> >>
> >> Do you see an issue with using Signal Type to indicate the *service*
> >> TSG?  I don't think there would be any change to your proposed
> >> (hop-by-hop) label encoding.
> >>
> >> Lou
> >>
> >>
> >> On 9/27/2011 10:37 AM, John E Drake wrote:
> >>> Nevermind.  What is wrong with the current signaling approach,
> which
> >> by the way I think is great?
> >>>
> >>>> -----Original Message-----
> >>>> From: Lou Berger [mailto:lberger@labn.net]
> >>>> Sent: Tuesday, September 27, 2011 10:32 AM
> >>>> To: John E Drake
> >>>> Cc: CCAMP
> >>>> Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG
> >>>>
> >>>> John,
> >>>> 	I guess I should have titled my mail "Proposal on..." so that the
> >>>> proposal would actually get read...
> >>>>
> >>>> Lou
> >>>>
> >>>>
> >>>> On 9/27/2011 10:23 AM, John E Drake wrote:
> >>>>> Lou,
> >>>>>
> >>>>> In routing (draft-ceccarelli-ccamp-gmpls-ospf-g709-07) we
> advertise
> >>>>> tributary slot granularity in a new field.  In signaling
> >>>>> (draft-zhang-ccamp-gmpls-evolving-g709-09), it is derived from
> the
> >>>>> length of the TS bit map and the size of the ODUk/OTUk on which
> the
> >>>>> LSP is to be established.
> >>>>>
> >>>>> Thanks,
> >>>>>
> >>>>> John
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On
> >>>> Behalf
> >>>>>> Of Lou Berger
> >>>>>> Sent: Tuesday, September 27, 2011 9:20 AM
> >>>>>> To: CCAMP
> >>>>>> Subject: [CCAMP] Thought on where to carry G.709-v3 TSG
> >>>>>>
> >>>>>> All / G.709 draft authors,
> >>>>>>
> >>>>>> 	We have a few slightly unaligned proposals on where to
> indicate
> >>>>>> the
> >>>>>> [G.709-v3] Tributary Slot Granularity:
> >>>>>>
> >>>>>> 1: G-PID
> >>>>>>     draft-ietf-ccamp-otn-g709-info-model-01 says:
> >>>>>>     One possible solution is the G-PID field of the GENERALIZED
> >>>> LABEL
> >>>>>>     REQUEST Object.
> >>>>>>
> >>>>>> 2: A new field:
> >>>>>>    draft-ceccarelli-ccamp-gmpls-ospf-g709-07 says:
> >>>>>>       - TSG: Tributary Slot Granularity (2bit): Used for the
> >>>>>>       advertisement of the supported Tributary Slot granularity
> >>>>>>
> >>>>>> 3: Implicitly:
> >>>>>>    draft-zhang-ccamp-gmpls-evolving-g709-09 doesn't explicitly
> >>>>>>    signal TSG, but rather has it implied in the new ODU label.
> >>>>>>
> >>>>>> Some other alternatives include:
> >>>>>>
> >>>>>> 4: GMPLS Encoding
> >>>>>>    Currently used to indicate G.709 (which is also what the
> Switch
> >>>>>>    cap essentially indicates) An alternative would use:
> >>>>>>       12              G.709 ODUk (Digital Path, 2.5G)[RFC4328]
> >>>>>>       TBA (e.g., 15)  G.709 ODUk (Digital Path, 1.25G)
> >>>>>>
> >>>>>>    In routing, 15 would imply support for both 1.25 and 2.5G, as
> >>>>>>    support for both by 1.25 capable interfaces is required by
> >>>>>>    [G.709-v3]. (At least as I understand it.)
> >>>>>>
> >>>>>> 5: Signal Type
> >>>>>>    Carried in routing ISCD/SCSI and signaling traffic
> parameters.
> >>>>>>    Could enumerate all ODUx types to indicate either 1.25G or
> >> 2.5G.
> >>>>>>    Existing types indicate 2.5G, new types would need to be
> >>>> enumerated
> >>>>>>    for the new 1.25 and 2.5 types.  Hereto, the 1.25 types would
> >>>> imply
> >>>>>>    support for both 1.25 and 2.5 types in routing.
> >>>>>>
> >>>>>> As I understand it, TSG is needed at:
> >>>>>>   (a) the endpoints that terminate the signal/LSP to ensure
> proper
> >>>>>>       adaptation.
> >>>>>>   (b) the 2nd and penultimate hops to ensure the proper
> >>>>>>       interface/H-LSP selection.
> >>>>>>   (c) Intermediate nodes for proper TS allocation.
> >>>>>>
> >>>>>> It seems to me that we have enough existing fields in GMPLS (for
> >>>> G.709)
> >>>>>> that we should consider these before introducing new ones.  Of
> the
> >>>>>> existing fields, we have 1, 4 and 5.:
> >>>>>>
> >>>>>>    Option 1, G-PID, is really designed to support end-point
> client
> >>>>>>    adaptation, so as an end-point only field it really only
> >> supports
> >>>>>>    need (a), so I don't think G-PID is the right place to
> indicate
> >>>> TSG.
> >>>>>>
> >>>>>>    Option 4, Encoding, is used to support (a) and (b)-type
> checks
> >> in
> >>>>>>    GMPLS, but not (c).  So, while this field is definitely a
> >> better
> >>>>>>    place than G-PID to indicate TSG, it doesn't satisfy all the
> >>>> needs.
> >>>>>>
> >>>>>>    Option 5, Signal Type, is used to support all needs.
> >>>>>>
> >>>>>> Given all this, I'd like to propose that we use Option 5, Signal
> >>>> Type,
> >>>>>> to indicate TSG, and that this be reflected in the relevant WG
> >>>> drafts.
> >>>>>> (Authors, let me know if you'd like specific text proposals.)
> >>>>>>
> >>>>>> Comments?
> >>>>>>
> >>>>>> Much thanks,
> >>>>>> Lou (as WG contributor)
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> CCAMP mailing list
> >>>>>> CCAMP@ietf.org
> >>>>>> https://www.ietf.org/mailman/listinfo/ccamp
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >>>
> >
> >
> >
> >

From adrian@olddog.co.uk  Tue Sep 27 11:32:56 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B2221F8C00 for ; Tue, 27 Sep 2011 11:32:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.475
X-Spam-Level: 
X-Spam-Status: No, score=-2.475 tagged_above=-999 required=5 tests=[AWL=0.124,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cyc2tEsOO9Aj for ; Tue, 27 Sep 2011 11:32:55 -0700 (PDT)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id 4D32A21F8B49 for ; Tue, 27 Sep 2011 11:32:55 -0700 (PDT)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id p8RIZaVX000880;  Tue, 27 Sep 2011 19:35:36 +0100
Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id p8RIZYY9000874 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Sep 2011 19:35:35 +0100
From: "Adrian Farrel" 
To: 
Date: Tue, 27 Sep 2011 19:35:32 +0100
Message-ID: <0a3401cc7d44$3df50e20$b9df2a60$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: Acx9Q+JZpkovM+DrQLSntV3Q9tAGEQ==
Content-Language: en-gb
Cc: ccamp@ietf.org
Subject: [CCAMP] AD review of draft-ietf-ccamp-wson-impairments
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Sep 2011 18:32:56 -0000

Hi,

My AD review of this draft has only yielded a few editorial comments and it is
not worth your effort to spin a new revision at this point. Can I ask you to
hold these comments and pick them up after IETF Last Call with any issues that
are raised during the last call.

Thanks,
Adrian

===

Please expand "PCE" in the Abstract

---

Please expand 3R in Section 1

---

Section 1

   In order to provision an optical connection (an optical path) through
   a WSON, a combination of path continuity, resource availability and
   impairments constraints

s/impairments/impairment/

---
                                                            
Section 2

s/Multiplexers/Multiplexer/

---

Section 4

Formatting got a bit munged.

---

Please decide "bit error rate" or "bit error ratio" and update the
document accordingly

---

Section 4.3

Can I suggest that you renumber the two options in Figure 3 as (d) and
(e) to avoid confusion with the options in Figure 2. Then you can also
make things a bit clearer by numbering the bullets.


From leeyoung@huawei.com  Tue Sep 27 11:36:20 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14DE121F8F37 for ; Tue, 27 Sep 2011 11:36:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.556
X-Spam-Level: 
X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiywe6+5vPn6 for ; Tue, 27 Sep 2011 11:36:19 -0700 (PDT)
Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 8794221F8F1D for ; Tue, 27 Sep 2011 11:36:19 -0700 (PDT)
Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS700L2B2H40X@usaga04-in.huawei.com> for ccamp@ietf.org; Tue, 27 Sep 2011 13:39:05 -0500 (CDT)
Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug  8 2006)) with ESMTP id <0LS700FLG2H3N8@usaga04-in.huawei.com> for ccamp@ietf.org; Tue, 27 Sep 2011 13:39:04 -0500 (CDT)
Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 27 Sep 2011 11:38:59 -0700
Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0270.001; Tue, 27 Sep 2011 11:38:54 -0700
Date: Tue, 27 Sep 2011 18:38:53 +0000
From: Leeyoung 
In-reply-to: <0a3401cc7d44$3df50e20$b9df2a60$@olddog.co.uk>
X-Originating-IP: [10.47.152.70]
To: "adrian@olddog.co.uk" , "draft-ietf-ccamp-wson-impairments@tools.ietf.org" 
Message-id: <7AEB3D6833318045B4AE71C2C87E8E171817CD18@DFWEML501-MBX.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: en-US
Content-transfer-encoding: 7BIT
Accept-Language: en-US, zh-CN
Thread-topic: [CCAMP] AD review of draft-ietf-ccamp-wson-impairments
Thread-index: Acx9Q+JZpkovM+DrQLSntV3Q9tAGEQAAK42g
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: <0a3401cc7d44$3df50e20$b9df2a60$@olddog.co.uk>
Cc: "ccamp@ietf.org" 
Subject: Re: [CCAMP] AD review of draft-ietf-ccamp-wson-impairments
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Sep 2011 18:36:20 -0000

Hi Adrian,

Thanks for your quick review. Yes, we will hold your comments until IETF LC. 

Regards,
Young

-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Adrian Farrel
Sent: Tuesday, September 27, 2011 1:36 PM
To: draft-ietf-ccamp-wson-impairments@tools.ietf.org
Cc: ccamp@ietf.org
Subject: [CCAMP] AD review of draft-ietf-ccamp-wson-impairments

Hi,

My AD review of this draft has only yielded a few editorial comments and it is
not worth your effort to spin a new revision at this point. Can I ask you to
hold these comments and pick them up after IETF Last Call with any issues that
are raised during the last call.

Thanks,
Adrian

===

Please expand "PCE" in the Abstract

---

Please expand 3R in Section 1

---

Section 1

   In order to provision an optical connection (an optical path) through
   a WSON, a combination of path continuity, resource availability and
   impairments constraints

s/impairments/impairment/

---
                                                            
Section 2

s/Multiplexers/Multiplexer/

---

Section 4

Formatting got a bit munged.

---

Please decide "bit error rate" or "bit error ratio" and update the
document accordingly

---

Section 4.3

Can I suggest that you renumber the two options in Figure 3 as (d) and
(e) to avoid confusion with the options in Figure 2. Then you can also
make things a bit clearer by numbering the bullets.

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

From iesg-secretary@ietf.org  Tue Sep 27 12:44:36 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6203621F8F2B; Tue, 27 Sep 2011 12:44:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.505
X-Spam-Level: 
X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 872NCnE0dK2N; Tue, 27 Sep 2011 12:44:33 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB4BD21F8ED3; Tue, 27 Sep 2011 12:44:29 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IETF-Announce 
X-Test-IDTracker: no
X-IETF-IDTracker: 3.60
Message-ID: <20110927194429.8284.17876.idtracker@ietfa.amsl.com>
Date: Tue, 27 Sep 2011 12:44:29 -0700
Cc: ccamp@ietf.org
Subject: [CCAMP] Last Call:  (A Framework	for the Control of Wavelength Switched Optical Networks (WSON)	with Impairments) to Informational RFC
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: ietf@ietf.org
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Sep 2011 19:44:36 -0000

The IESG has received a request from the Common Control and Measurement
Plane WG (ccamp) to consider the following document:
- 'A Framework for the Control of Wavelength Switched Optical Networks
   (WSON) with Impairments'
   as an Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-10-11. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

As an optical signal progresses along its path it may be altered by
the various physical processes in the optical fibers and devices it
encounters. When such alterations result in signal degradation, these
processes are usually referred to as "impairments". These physical
characteristics may be important constraints to consider when using a
GMPLS control plane to support path setup and maintenance in
wavelength switched optical networks.

This document provides a framework for applying GMPLS protocols and
the PCE architecture to support Impairment Aware Routing and
Wavelength Assignment (IA-RWA) in wavelength switched optical
networks. This document does not define optical data plane aspects;
impairment parameters, measurement of, or assessment and
qualification of a route, but rather it describes the architectural
and information components for protocol solutions.



The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-impairments/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-impairments/


No IPR declarations have been submitted directly on this I-D.

From lberger@labn.net  Tue Sep 27 14:10:02 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1550021F8F6B for ; Tue, 27 Sep 2011 14:09:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.814
X-Spam-Level: 
X-Spam-Status: No, score=-100.814 tagged_above=-999 required=5 tests=[AWL=-0.653, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LyiMR2y2uSbR for ; Tue, 27 Sep 2011 14:09:56 -0700 (PDT)
Received: from oproxy6-pub.bluehost.com (oproxy6.bluehost.com [IPv6:2605:dc00:100:2::a6]) by ietfa.amsl.com (Postfix) with SMTP id D592F21F8F64 for ; Tue, 27 Sep 2011 14:09:54 -0700 (PDT)
Received: (qmail 22031 invoked by uid 0); 27 Sep 2011 21:12:40 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy3.bluehost.com with SMTP; 27 Sep 2011 21:12:40 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default;  h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=Ec6trZku9VA4HiSRvkPbiybDiFg7+CJKBR9cRxJNK5s=;  b=hmWWyh225/8eYmkILi5bhvj5O3AWCntzxMuZIcz23DS5Ube5fb7l7lmIGEAlY4pSybDtTGxj5f1+LRVkcym04cY6KE5iQo4hl0ADDpzY78I7O2XlsLTRjV/m/YSb77Kg;
Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1R8exD-0000Bg-R7; Tue, 27 Sep 2011 15:12:40 -0600
Message-ID: <4E823C45.6040501@labn.net>
Date: Tue, 27 Sep 2011 17:12:37 -0400
From: Lou Berger 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: John E Drake 
References: <4E81CD97.3020209@labn.net> <5E893DB832F57341992548CDBB333163A28E05ED10@EMBX01-HQ.jnpr.net> <4E81DE57.1080601@labn.net> <5E893DB832F57341992548CDBB333163A28E05ED28@EMBX01-HQ.jnpr.net> <4E81E48B.8090102@labn.net> <5E893DB832F57341992548CDBB333163A28E05ED83@EMBX01-HQ.jnpr.net> <4E81EBAD.1050204@labn.net> <5E893DB832F57341992548CDBB333163A28E05EF17@EMBX01-HQ.jnpr.net>
In-Reply-To: <5E893DB832F57341992548CDBB333163A28E05EF17@EMBX01-HQ.jnpr.net>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Cc: CCAMP 
Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Sep 2011 21:10:02 -0000

On 9/27/2011 12:40 PM, John E Drake wrote:
> Lou,
> 
> Using Signal Type in signaling in addition to the bit map label is
> probably okay. 


> I don't think it makes any sense in routing and would
> prefer to continue to just have the two bits.
> 

On what basis?

Lou

> Thanks,
> 
> John
> 
>> -----Original Message-----
>> From: Lou Berger [mailto:lberger@labn.net]
>> Sent: Tuesday, September 27, 2011 11:29 AM
>> To: John E Drake
>> Cc: CCAMP
>> Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG
>>
>> John,
>> 	Two points:
>>
>> As a general rule, it doesn't make sense to invent yet another way to
>> carry information when an existing one will do.  This is actually a
>> pretty fundamental tenant of GMPLS.
>>
>> Also, in GMPLS the general model for allocation is to carry resource
>> requirements in the TS not the label.  Such use of the TS ensures that
>> the information is unambiguous in all cases.  (For example, consider
>> the
>> corner case where you have a unidirectional LSP, where is TSG
>> requirements of the sender/upstream node indicated in the Path
>> message.)
>>
>> Lou
>>
>> On 9/27/2011 11:13 AM, John E Drake wrote:
>>> Lou,
>>>
>>> Clearly, the info-model draft needs to be updated, but I am quite
>>> happy with the what is currently in the signaling and routing drafts
>>> and I haven't heard a compelling reason to change.
>>>
>>> Thanks,
>>>
>>> John
>>>
>>>> -----Original Message-----
>>>> From: Lou Berger [mailto:lberger@labn.net]
>>>> Sent: Tuesday, September 27, 2011 10:58 AM
>>>> To: John E Drake
>>>> Cc: CCAMP
>>>> Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG
>>>>
>>>> John,
>>>> 	There isn't alignment in the WG info-model and the individual
>>>> routing
>>>> and signaling drafts.  I think we have enough ways of explicitly
>>>> carrying signal information that we can leverage to come up with a
>>>> clean
>>>> an unified approach that satisfies all the needs for TSG
>> information,
>>>> i.e.:
>>>>
>>>>> Given all this [see below], I'd like to propose that we use Option
>> 5,
>>>>> Signal Type, to indicate TSG
>>>>
>>>> Do you see an issue with using Signal Type to indicate the *service*
>>>> TSG?  I don't think there would be any change to your proposed
>>>> (hop-by-hop) label encoding.
>>>>
>>>> Lou
>>>>
>>>>
>>>> On 9/27/2011 10:37 AM, John E Drake wrote:
>>>>> Nevermind.  What is wrong with the current signaling approach,
>> which
>>>> by the way I think is great?
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Lou Berger [mailto:lberger@labn.net]
>>>>>> Sent: Tuesday, September 27, 2011 10:32 AM
>>>>>> To: John E Drake
>>>>>> Cc: CCAMP
>>>>>> Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG
>>>>>>
>>>>>> John,
>>>>>> 	I guess I should have titled my mail "Proposal on..." so that the
>>>>>> proposal would actually get read...
>>>>>>
>>>>>> Lou
>>>>>>
>>>>>>
>>>>>> On 9/27/2011 10:23 AM, John E Drake wrote:
>>>>>>> Lou,
>>>>>>>
>>>>>>> In routing (draft-ceccarelli-ccamp-gmpls-ospf-g709-07) we
>> advertise
>>>>>>> tributary slot granularity in a new field.  In signaling
>>>>>>> (draft-zhang-ccamp-gmpls-evolving-g709-09), it is derived from
>> the
>>>>>>> length of the TS bit map and the size of the ODUk/OTUk on which
>> the
>>>>>>> LSP is to be established.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> John
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On
>>>>>> Behalf
>>>>>>>> Of Lou Berger
>>>>>>>> Sent: Tuesday, September 27, 2011 9:20 AM
>>>>>>>> To: CCAMP
>>>>>>>> Subject: [CCAMP] Thought on where to carry G.709-v3 TSG
>>>>>>>>
>>>>>>>> All / G.709 draft authors,
>>>>>>>>
>>>>>>>> 	We have a few slightly unaligned proposals on where to
>> indicate
>>>>>>>> the
>>>>>>>> [G.709-v3] Tributary Slot Granularity:
>>>>>>>>
>>>>>>>> 1: G-PID
>>>>>>>>     draft-ietf-ccamp-otn-g709-info-model-01 says:
>>>>>>>>     One possible solution is the G-PID field of the GENERALIZED
>>>>>> LABEL
>>>>>>>>     REQUEST Object.
>>>>>>>>
>>>>>>>> 2: A new field:
>>>>>>>>    draft-ceccarelli-ccamp-gmpls-ospf-g709-07 says:
>>>>>>>>       - TSG: Tributary Slot Granularity (2bit): Used for the
>>>>>>>>       advertisement of the supported Tributary Slot granularity
>>>>>>>>
>>>>>>>> 3: Implicitly:
>>>>>>>>    draft-zhang-ccamp-gmpls-evolving-g709-09 doesn't explicitly
>>>>>>>>    signal TSG, but rather has it implied in the new ODU label.
>>>>>>>>
>>>>>>>> Some other alternatives include:
>>>>>>>>
>>>>>>>> 4: GMPLS Encoding
>>>>>>>>    Currently used to indicate G.709 (which is also what the
>> Switch
>>>>>>>>    cap essentially indicates) An alternative would use:
>>>>>>>>       12              G.709 ODUk (Digital Path, 2.5G)[RFC4328]
>>>>>>>>       TBA (e.g., 15)  G.709 ODUk (Digital Path, 1.25G)
>>>>>>>>
>>>>>>>>    In routing, 15 would imply support for both 1.25 and 2.5G, as
>>>>>>>>    support for both by 1.25 capable interfaces is required by
>>>>>>>>    [G.709-v3]. (At least as I understand it.)
>>>>>>>>
>>>>>>>> 5: Signal Type
>>>>>>>>    Carried in routing ISCD/SCSI and signaling traffic
>> parameters.
>>>>>>>>    Could enumerate all ODUx types to indicate either 1.25G or
>>>> 2.5G.
>>>>>>>>    Existing types indicate 2.5G, new types would need to be
>>>>>> enumerated
>>>>>>>>    for the new 1.25 and 2.5 types.  Hereto, the 1.25 types would
>>>>>> imply
>>>>>>>>    support for both 1.25 and 2.5 types in routing.
>>>>>>>>
>>>>>>>> As I understand it, TSG is needed at:
>>>>>>>>   (a) the endpoints that terminate the signal/LSP to ensure
>> proper
>>>>>>>>       adaptation.
>>>>>>>>   (b) the 2nd and penultimate hops to ensure the proper
>>>>>>>>       interface/H-LSP selection.
>>>>>>>>   (c) Intermediate nodes for proper TS allocation.
>>>>>>>>
>>>>>>>> It seems to me that we have enough existing fields in GMPLS (for
>>>>>> G.709)
>>>>>>>> that we should consider these before introducing new ones.  Of
>> the
>>>>>>>> existing fields, we have 1, 4 and 5.:
>>>>>>>>
>>>>>>>>    Option 1, G-PID, is really designed to support end-point
>> client
>>>>>>>>    adaptation, so as an end-point only field it really only
>>>> supports
>>>>>>>>    need (a), so I don't think G-PID is the right place to
>> indicate
>>>>>> TSG.
>>>>>>>>
>>>>>>>>    Option 4, Encoding, is used to support (a) and (b)-type
>> checks
>>>> in
>>>>>>>>    GMPLS, but not (c).  So, while this field is definitely a
>>>> better
>>>>>>>>    place than G-PID to indicate TSG, it doesn't satisfy all the
>>>>>> needs.
>>>>>>>>
>>>>>>>>    Option 5, Signal Type, is used to support all needs.
>>>>>>>>
>>>>>>>> Given all this, I'd like to propose that we use Option 5, Signal
>>>>>> Type,
>>>>>>>> to indicate TSG, and that this be reflected in the relevant WG
>>>>>> drafts.
>>>>>>>> (Authors, let me know if you'd like specific text proposals.)
>>>>>>>>
>>>>>>>> Comments?
>>>>>>>>
>>>>>>>> Much thanks,
>>>>>>>> Lou (as WG contributor)
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> CCAMP mailing list
>>>>>>>> CCAMP@ietf.org
>>>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>>
> 
> 
> 
> 

From lberger@labn.net  Tue Sep 27 14:11:11 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85E4421F8FA2 for ; Tue, 27 Sep 2011 14:11:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.505
X-Spam-Level: 
X-Spam-Status: No, score=-100.505 tagged_above=-999 required=5 tests=[AWL=-0.944, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_47=0.6, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uZqOxeNb+Cmh for ; Tue, 27 Sep 2011 14:11:10 -0700 (PDT)
Received: from oproxy8-pub.bluehost.com (oproxy8.bluehost.com [IPv6:2605:dc00:100:2::a8]) by ietfa.amsl.com (Postfix) with SMTP id 1223821F8E0C for ; Tue, 27 Sep 2011 14:11:09 -0700 (PDT)
Received: (qmail 10861 invoked by uid 0); 27 Sep 2011 21:13:51 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy8.bluehost.com with SMTP; 27 Sep 2011 21:13:50 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default;  h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=H4g/yDcCgpujSEbm+/bI7FV5EXQTm2IVwzPRO0HVV60=;  b=TmzZloO+mSpLPU9v0JXnnGwuRFhmwNFi6KZMl1EFfIKWO4fZlJX4HBibkNnAb+JSdKZewNlqFBAee0z6MyURXh/Urc11ciVkhl+uaA2/T77Ls1+VMrD1qIVcvFHFnN0o;
Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1R8eyM-0000QK-QC for ccamp@ietf.org; Tue, 27 Sep 2011 15:13:50 -0600
Message-ID: <4E823C8C.5070405@labn.net>
Date: Tue, 27 Sep 2011 17:13:48 -0400
From: Lou Berger 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: CCAMP 
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=windows-1252
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] In case anyone missed it: IAB Appoints John Drake as IETF, Liaison to ITU-T SG-15 (Optical Control Plane)
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Sep 2011 21:11:11 -0000

The IAB has announced the following appointment:

http://www.iab.org/2011/08/10/iab-appoints-john-drake-as-ietf-liaison-to-itu-t-sg-15-optical-control-plane/

    IAB Appoints John Drake as IETF Liaison to ITU-T
    SG-15 (Optical Control Plane)

    Posted on August 10, 2011 by baboba

    The IAB has appointed John Drake as IETF liaison to ITU-T
    SG-15 (optical control plane), replacing Adrian Farrel.
    Mr. Drake has been active in the IETF since 1995, primarily
    in the Routing Area.  His areas of expertise include MPLS and
    GMPLS and he is currently a member of the Routing Area and
    Smart Grid Directorates.  He has worked with SG15 on the
    development of GMPLS extensions in support of the ITU’s ASON
    architecture, MPLS-TP, and GMPLS support for OTN. The IAB
    extends its thanks to the outgoing liaison manager, Adrian
    Farrel.

We recognize Adrian's fine service in this area and look forward to John
continuing in this role.

Lou and Deborah

From leeyoung@huawei.com  Tue Sep 27 15:03:38 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65CB021F8F4D for ; Tue, 27 Sep 2011 15:03:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.557
X-Spam-Level: 
X-Spam-Status: No, score=-6.557 tagged_above=-999 required=5 tests=[AWL=0.042,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MbpU+S92x9o9 for ; Tue, 27 Sep 2011 15:03:37 -0700 (PDT)
Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 8C80821F8F48 for ; Tue, 27 Sep 2011 15:03:37 -0700 (PDT)
Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS700LVIC2N5T@usaga04-in.huawei.com> for ccamp@ietf.org; Tue, 27 Sep 2011 17:06:24 -0500 (CDT)
Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug  8 2006)) with ESMTP id <0LS700HCXC2MRE@usaga04-in.huawei.com> for ccamp@ietf.org; Tue, 27 Sep 2011 17:06:23 -0500 (CDT)
Received: from DFWEML401-HUB.china.huawei.com (10.193.5.101) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Tue, 27 Sep 2011 15:06:19 -0700
Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML401-HUB.china.huawei.com ([fe80::f07f:889f:78ef:8df3%13]) with mapi id 14.01.0270.001; Tue, 27 Sep 2011 15:06:01 -0700
Date: Tue, 27 Sep 2011 22:06:00 +0000
From: Leeyoung 
In-reply-to: 
X-Originating-IP: [10.47.152.70]
To: "PELOSO, PIERRE (PIERRE)" , "ccamp@ietf.org" 
Message-id: <7AEB3D6833318045B4AE71C2C87E8E171817CE25@DFWEML501-MBX.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-language: en-US
Content-transfer-encoding: quoted-printable
Accept-Language: en-US
Thread-topic: [CCAMP] I-D	Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
Thread-index: AQHMfO94tnV8wbm4z0mVmmskErrIZJVhuEzA
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: <20110915194751.1118.92540.idtracker@ietfa.amsl.com> <7AEB3D6833318045B4AE71C2C87E8E171816B709@DFWEML501-MBX.china.huawei.com> 
Subject: Re: [CCAMP] I-D	Action:	draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Sep 2011 22:03:38 -0000

Hi Pierre,=20

Please see-inline for my reply to your first point.=20

Regards,
Young

-----Original Message-----
From: PELOSO, PIERRE (PIERRE) [mailto:pierre.peloso@alcatel-lucent.com]=20
Sent: Tuesday, September 27, 2011 3:28 AM
To: Leeyoung; ccamp@ietf.org
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility=
-ospf-06.txt

Hi Young, and CCAMPers,

I was off the mailing lists for the last two weeks and being back I notice =
a lot of exchanges, which I'm very glad of.
I've also noticed many drafts have been updated.
Concerning this specific draft-ietf-ccamp-wson-signal-compatibility-ospf-06=
, I wanted to comment section 3.
Back in Quebec, I expressed my point of view (shared with Cyril, Julien and=
 Giovanni) that current drafts were lacking guidance regarding the way to d=
esign LSAs that were to depict an WSON node with OEOs.
This section 3 provides additional material to help designing the LSA.
I would like to know whether authors are willing to pursue further in this =
direction, which is to my mind a real corner stone, that would help everyon=
e agree on a solution.
A first point could concern the Resource Block Information (reminder:  ::=3D ([]   ):
     We all agree that these information are static, that we should not rep=
licate this TLV whatever the number not the layout of OEO boards of a given=
 type.
Then, we could dedicate a specific independant flooding entity. This would =
be defined once for all, and that would not leave room to different interpr=
etations.
What about this first point?

YOUNG>> If I understand you correctly, what you are saying is since the Res=
ource Block Info sub-TLV is very static in nature, advertisement of this su=
b-TLV should be treated differently from the rest of static-TLVs (which may=
 change over time). Is this what you are saying?

If my interpretation of your comment is correct,=20

- The current mechanism allows what you want: Please see the first paragrap=
h in Section 3.2
   "In the highly unlikely event that a WSON sub-TLV by itself would
   result in an LSA exceeding the MTU, all five WSON specific sub-TLVs
   in this document provide mechanisms that allow them to be subdivided
   into smaller sub-TLVs that can be sent in separate OSPF TE LSAs."

According to this clause, you can separate the Resource Block Info Sub-TLV =
as the sole entry defined in the Optical Node property TLV in a separate TE=
 LSA from the rest if you will. Nothing prevents this particular way of pac=
kaging. (Isn't this what you meant "a specific independent flooding entity"=
?)=20

- Please let me know if this explanation satisfies you. Thanks --- Young

Regards,

Pierre

-----Message d'origine-----
De : ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] De la part de L=
eeyoung
Envoy=E9 : jeudi 15 septembre 2011 21:59
=C0 : ccamp@ietf.org
Objet : Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-=
ospf-06.txt

Hi all,

After 05 version publication, Acee provided a number of valuable comments a=
nd suggestions. This revision (06) reflects those changes. Please note the =
following updates:

- Change the title of the draft to "GMPLS OSPF Enhancement..." from "OSPF E=
nhancement..." to make sure the changes apply to the GMPLS OSPF rather than=
 the base OSPF.=20

- Add specific OSPF procedures on how sub-TLVs are packaged per [RFC3630] a=
nd editorial change including avoiding "multiple instances of TE LSA" to "m=
ultiple TE LSAs".=20

Your comments are always appreciated. Thanks.

Best Regards.
Young


-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of i=
nternet-drafts@ietf.org
Sent: Thursday, September 15, 2011 2:48 PM
To: i-d-announce@ietf.org
Cc: ccamp@ietf.org
Subject: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-osp=
f-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Common Control and Measurement Plane =
Working Group of the IETF.

	Title           : GMPLS OSPF Enhancement for Signal and Network Element Co=
mpatibility for Wavelength Switched Optical Networks
	Author(s)       : Young Lee
                          Greg M. Bernstein
	Filename        : draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
	Pages           : 14
	Date            : 2011-09-15

   This document provides GMPLS OSPF routing enhancements to support
   signal compatibility constraints associated with WSON network
   elements. These routing enhancements are required in common optical
   or hybrid electro-optical networks where not all of the optical
   signals in the network are compatible with all network elements
   participating in the network.

   This compatibility constraint model is applicable to common optical
   or hybrid electro optical systems such as OEO switches, regenerators,
   and wavelength converters since such systems can be limited to
   processing only certain types of WSON signals.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compatibil=
ity-ospf-06.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compatibili=
ty-ospf-06.txt
_______________________________________________
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 prvs=22519de429=lyong@ciena.com  Tue Sep 27 16:33:49 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71EE121F8FFD for ; Tue, 27 Sep 2011 16:33:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.432
X-Spam-Level: 
X-Spam-Status: No, score=-103.432 tagged_above=-999 required=5 tests=[AWL=-0.167, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhLWYOytVb0u for ; Tue, 27 Sep 2011 16:33:48 -0700 (PDT)
Received: from mx0a-00103a01.pphosted.com (mx0a-00103a01.pphosted.com [67.231.144.234]) by ietfa.amsl.com (Postfix) with ESMTP id 99BD721F8B29 for ; Tue, 27 Sep 2011 16:33:48 -0700 (PDT)
Received: from pps.filterd (m0000419 [127.0.0.1]) by mx0a-00103a01.pphosted.com (8.14.3/8.14.3) with SMTP id p8RNZdVm028140; Tue, 27 Sep 2011 19:36:35 -0400
Received: from mdwexght02.ciena.com (LIN1-118-36-29.ciena.com [63.118.36.29]) by mx0a-00103a01.pphosted.com with ESMTP id 103mwu8r11-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 27 Sep 2011 19:36:35 -0400
Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXGHT02.ciena.com ([::1]) with mapi; Tue, 27 Sep 2011 19:36:34 -0400
From: "Ong, Lyndon" 
To: Lou Berger , John E Drake 
Content-Class: urn:content-classes:message
Date: Tue, 27 Sep 2011 19:36:32 -0400
Thread-Topic: [CCAMP] Thought on where to carry G.709-v3 TSG
Thread-Index: Acx9WjpQPVAnZYIRSJ6aliqyvE6dewAE7Lhg
Message-ID: 
References: <4E81CD97.3020209@labn.net><5E893DB832F57341992548CDBB333163A28E05ED10@EMBX01-HQ.jnpr.net><4E81DE57.1080601@labn.net><5E893DB832F57341992548CDBB333163A28E05ED28@EMBX01-HQ.jnpr.net><4E81E48B.8090102@labn.net><5E893DB832F57341992548CDBB333163A28E05ED83@EMBX01-HQ.jnpr.net><4E81EBAD.1050204@labn.net><5E893DB832F57341992548CDBB333163A28E05EF17@EMBX01-HQ.jnpr.net> <4E823C45.6040501@labn.net>
In-Reply-To: <4E823C45.6040501@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
x-tm-as-product-ver: SMEX-10.0.0.1412-6.800.1017-18412.002
x-tm-as-result: No--64.152500-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-09-27_11:2011-09-28, 2011-09-27, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=1 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1109270284
Cc: CCAMP 
Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Sep 2011 23:33:49 -0000

Hi Lou,

Not quite sure what you are proposing - would this mean the signal type cha=
nges hop by hop if you are creating a connection that goes over links suppo=
rting different TS granularity?

Thanks,

Lyndon



-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L=
ou Berger
Sent: Tuesday, September 27, 2011 2:13 PM
To: John E Drake
Cc: CCAMP
Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG




On 9/27/2011 12:40 PM, John E Drake wrote:
> Lou,
>
> Using Signal Type in signaling in addition to the bit map label is
> probably okay.


> I don't think it makes any sense in routing and would
> prefer to continue to just have the two bits.
>

On what basis?

Lou

> Thanks,
>
> John
>
>> -----Original Message-----
>> From: Lou Berger [mailto:lberger@labn.net]
>> Sent: Tuesday, September 27, 2011 11:29 AM
>> To: John E Drake
>> Cc: CCAMP
>> Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG
>>
>> John,
>>      Two points:
>>
>> As a general rule, it doesn't make sense to invent yet another way to
>> carry information when an existing one will do.  This is actually a
>> pretty fundamental tenant of GMPLS.
>>
>> Also, in GMPLS the general model for allocation is to carry resource
>> requirements in the TS not the label.  Such use of the TS ensures that
>> the information is unambiguous in all cases.  (For example, consider
>> the
>> corner case where you have a unidirectional LSP, where is TSG
>> requirements of the sender/upstream node indicated in the Path
>> message.)
>>
>> Lou
>>
>> On 9/27/2011 11:13 AM, John E Drake wrote:
>>> Lou,
>>>
>>> Clearly, the info-model draft needs to be updated, but I am quite
>>> happy with the what is currently in the signaling and routing drafts
>>> and I haven't heard a compelling reason to change.
>>>
>>> Thanks,
>>>
>>> John
>>>
>>>> -----Original Message-----
>>>> From: Lou Berger [mailto:lberger@labn.net]
>>>> Sent: Tuesday, September 27, 2011 10:58 AM
>>>> To: John E Drake
>>>> Cc: CCAMP
>>>> Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG
>>>>
>>>> John,
>>>>    There isn't alignment in the WG info-model and the individual
>>>> routing
>>>> and signaling drafts.  I think we have enough ways of explicitly
>>>> carrying signal information that we can leverage to come up with a
>>>> clean
>>>> an unified approach that satisfies all the needs for TSG
>> information,
>>>> i.e.:
>>>>
>>>>> Given all this [see below], I'd like to propose that we use Option
>> 5,
>>>>> Signal Type, to indicate TSG
>>>>
>>>> Do you see an issue with using Signal Type to indicate the *service*
>>>> TSG?  I don't think there would be any change to your proposed
>>>> (hop-by-hop) label encoding.
>>>>
>>>> Lou
>>>>
>>>>
>>>> On 9/27/2011 10:37 AM, John E Drake wrote:
>>>>> Nevermind.  What is wrong with the current signaling approach,
>> which
>>>> by the way I think is great?
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Lou Berger [mailto:lberger@labn.net]
>>>>>> Sent: Tuesday, September 27, 2011 10:32 AM
>>>>>> To: John E Drake
>>>>>> Cc: CCAMP
>>>>>> Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG
>>>>>>
>>>>>> John,
>>>>>>  I guess I should have titled my mail "Proposal on..." so that the
>>>>>> proposal would actually get read...
>>>>>>
>>>>>> Lou
>>>>>>
>>>>>>
>>>>>> On 9/27/2011 10:23 AM, John E Drake wrote:
>>>>>>> Lou,
>>>>>>>
>>>>>>> In routing (draft-ceccarelli-ccamp-gmpls-ospf-g709-07) we
>> advertise
>>>>>>> tributary slot granularity in a new field.  In signaling
>>>>>>> (draft-zhang-ccamp-gmpls-evolving-g709-09), it is derived from
>> the
>>>>>>> length of the TS bit map and the size of the ODUk/OTUk on which
>> the
>>>>>>> LSP is to be established.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> John
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On
>>>>>> Behalf
>>>>>>>> Of Lou Berger
>>>>>>>> Sent: Tuesday, September 27, 2011 9:20 AM
>>>>>>>> To: CCAMP
>>>>>>>> Subject: [CCAMP] Thought on where to carry G.709-v3 TSG
>>>>>>>>
>>>>>>>> All / G.709 draft authors,
>>>>>>>>
>>>>>>>>        We have a few slightly unaligned proposals on where to
>> indicate
>>>>>>>> the
>>>>>>>> [G.709-v3] Tributary Slot Granularity:
>>>>>>>>
>>>>>>>> 1: G-PID
>>>>>>>>     draft-ietf-ccamp-otn-g709-info-model-01 says:
>>>>>>>>     One possible solution is the G-PID field of the GENERALIZED
>>>>>> LABEL
>>>>>>>>     REQUEST Object.
>>>>>>>>
>>>>>>>> 2: A new field:
>>>>>>>>    draft-ceccarelli-ccamp-gmpls-ospf-g709-07 says:
>>>>>>>>       - TSG: Tributary Slot Granularity (2bit): Used for the
>>>>>>>>       advertisement of the supported Tributary Slot granularity
>>>>>>>>
>>>>>>>> 3: Implicitly:
>>>>>>>>    draft-zhang-ccamp-gmpls-evolving-g709-09 doesn't explicitly
>>>>>>>>    signal TSG, but rather has it implied in the new ODU label.
>>>>>>>>
>>>>>>>> Some other alternatives include:
>>>>>>>>
>>>>>>>> 4: GMPLS Encoding
>>>>>>>>    Currently used to indicate G.709 (which is also what the
>> Switch
>>>>>>>>    cap essentially indicates) An alternative would use:
>>>>>>>>       12              G.709 ODUk (Digital Path, 2.5G)[RFC4328]
>>>>>>>>       TBA (e.g., 15)  G.709 ODUk (Digital Path, 1.25G)
>>>>>>>>
>>>>>>>>    In routing, 15 would imply support for both 1.25 and 2.5G, as
>>>>>>>>    support for both by 1.25 capable interfaces is required by
>>>>>>>>    [G.709-v3]. (At least as I understand it.)
>>>>>>>>
>>>>>>>> 5: Signal Type
>>>>>>>>    Carried in routing ISCD/SCSI and signaling traffic
>> parameters.
>>>>>>>>    Could enumerate all ODUx types to indicate either 1.25G or
>>>> 2.5G.
>>>>>>>>    Existing types indicate 2.5G, new types would need to be
>>>>>> enumerated
>>>>>>>>    for the new 1.25 and 2.5 types.  Hereto, the 1.25 types would
>>>>>> imply
>>>>>>>>    support for both 1.25 and 2.5 types in routing.
>>>>>>>>
>>>>>>>> As I understand it, TSG is needed at:
>>>>>>>>   (a) the endpoints that terminate the signal/LSP to ensure
>> proper
>>>>>>>>       adaptation.
>>>>>>>>   (b) the 2nd and penultimate hops to ensure the proper
>>>>>>>>       interface/H-LSP selection.
>>>>>>>>   (c) Intermediate nodes for proper TS allocation.
>>>>>>>>
>>>>>>>> It seems to me that we have enough existing fields in GMPLS (for
>>>>>> G.709)
>>>>>>>> that we should consider these before introducing new ones.  Of
>> the
>>>>>>>> existing fields, we have 1, 4 and 5.:
>>>>>>>>
>>>>>>>>    Option 1, G-PID, is really designed to support end-point
>> client
>>>>>>>>    adaptation, so as an end-point only field it really only
>>>> supports
>>>>>>>>    need (a), so I don't think G-PID is the right place to
>> indicate
>>>>>> TSG.
>>>>>>>>
>>>>>>>>    Option 4, Encoding, is used to support (a) and (b)-type
>> checks
>>>> in
>>>>>>>>    GMPLS, but not (c).  So, while this field is definitely a
>>>> better
>>>>>>>>    place than G-PID to indicate TSG, it doesn't satisfy all the
>>>>>> needs.
>>>>>>>>
>>>>>>>>    Option 5, Signal Type, is used to support all needs.
>>>>>>>>
>>>>>>>> Given all this, I'd like to propose that we use Option 5, Signal
>>>>>> Type,
>>>>>>>> to indicate TSG, and that this be reflected in the relevant WG
>>>>>> drafts.
>>>>>>>> (Authors, let me know if you'd like specific text proposals.)
>>>>>>>>
>>>>>>>> Comments?
>>>>>>>>
>>>>>>>> Much thanks,
>>>>>>>> Lou (as WG contributor)
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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  Tue Sep 27 19:02:33 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9C521F8B17 for ; Tue, 27 Sep 2011 19:02:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.015
X-Spam-Level: 
X-Spam-Status: No, score=-1.015 tagged_above=-999 required=5 tests=[AWL=-3.465, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyFjd2LcI5SO for ; Tue, 27 Sep 2011 19:02:32 -0700 (PDT)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 4B30C21F8B11 for ; Tue, 27 Sep 2011 19:02:32 -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 <0LS7003IQN4KJR@szxga05-in.huawei.com> for ccamp@ietf.org; Wed, 28 Sep 2011 10:05:08 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS700IO3N4BM3@szxga05-in.huawei.com> for ccamp@ietf.org; Wed, 28 Sep 2011 10:05:08 +0800 (CST)
Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id ADY26517; Wed, 28 Sep 2011 10:05:07 +0800
Received: from SZXEML409-HUB.china.huawei.com (10.82.67.136) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 28 Sep 2011 10:05:04 +0800
Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.142]) by szxeml409-hub.china.huawei.com ([10.82.67.136]) with mapi id 14.01.0270.001; Wed, 28 Sep 2011 10:04:58 +0800
Date: Wed, 28 Sep 2011 02:04:58 +0000
From: Zhangfatai 
In-reply-to: 
X-Originating-IP: [172.24.2.40]
To: Ben Wright , "ccamp@ietf.org" 
Message-id: 
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_m1n9JcmwHNVegDToov9AEA)"
Content-language: zh-CN
Accept-Language: zh-CN, en-US
Thread-topic: Question on NMC in draft-zhang-ccamp-gmpls-evolving-g709
Thread-index: Acx89VlrIwvIizXFQ3623ojG/v0sWwAjP4Ef
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: 
Subject: [CCAMP] =?gb2312?b?tPC4tDogUXVlc3Rpb24gb24gTk1DIGluIGRyYWZ0LXpo?= =?gb2312?b?YW5nLWNjYW1wLWdtcGxzLWV2b2x2aW5nLWc3MDk=?=
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Sep 2011 02:02:33 -0000

--Boundary_(ID_m1n9JcmwHNVegDToov9AEA)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: base64

SGkgQmVuLA0KDQoNCg0KSSBwZXJzb25hbGx5IHF1aXRlIGFncmVlIHdpdGggeW91IHRoYXQgdGhl
IGVhc3kgd2F5IGlzIHRvIGRlcHJlY2F0ZSBOTUMuDQoNCg0KDQpXZSB3aWxsIGFkZCBzb21lIHRl
eHQgdG8gYWRkcmVzcyB0aGF0IChhdCBsZWFzdCBhbiBlZGl0b3JzJyBub3RlIHdpbGwgYmUgYWRk
ZWQgdG8gY2FwdHVyZSB0aGF0KS4NCg0KDQoNCkZhdGFpDQoNCg0KDQpUaGFua3MNCg0KDQoNCg0K
DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCreivP7IyzogY2NhbXAtYm91
bmNlc0BpZXRmLm9yZyBbY2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gtPqx7SBCZW4gV3JpZ2h0IFtC
ZW4uV3JpZ2h0QG1ldGFzd2l0Y2guY29tXQ0Kt6LLzcqxvOQ6IDIwMTHE6jnUwjI3yNUgMTc6MTAN
CrW9OiBjY2FtcEBpZXRmLm9yZw0K1vfM4jogW0NDQU1QXSBRdWVzdGlvbiBvbiBOTUMgaW4gZHJh
ZnQtemhhbmctY2NhbXAtZ21wbHMtZXZvbHZpbmctZzcwOQ0KDQpIaSBhbGwsDQoNCkkgaGFkIGEg
ZGV0YWlsZWQgcXVlcnkgYWJvdXQgdGhlIE5NQyB1c2FnZSBpbiBkcmFmdC16aGFuZy1jY2FtcC1n
bXBscy1ldm9sdmluZy1nNzA5LiAgIFRoaXMgaW5oZXJpdHMgdGhlIHVzYWdlIG9mIHRoZSBOTUMg
ZnJvbSBSRkM0MzI4LCB3aGljaCB3b3VsZCBpbmRpY2F0ZSB0aGUgbnVtYmVyIG9mIHRyaWJ1dGFy
eSBzbG90cyByZXF1ZXN0ZWQgZm9yIHRoaXMgc2lnbmFsIHR5cGUuICAgSSB0aGluayB0aGUgZm9s
bG93aW5nIGFyZSBib3RoIHRydWUuDQoNCi0gICAgICAgICAgVGhpcyBpbmZvcm1hdGlvbiBpcyBz
dHJpY3RseSBzcGVha2luZyByZWR1bmRhbnQgYmVjYXVzZSB0aGUgbGFiZWwgbm93IGRlc2NyaWJl
cyBob3cgdGhlIHNpZ25hbCB0eXBlIHdpbGwgYmUgbXVsdGlwbGV4ZWQgb250byBhIGdpdmVuIGxp
bmsuDQoNCi0gICAgICAgICAgV2l0aCB0aGUgaW50cm9kdWN0aW9uIG9mIHRoZSAxLjI1R2JwcyBz
aXplLCB0aGUgdHJpYnV0YXJ5IHNsb3Qgc2l6ZSBjYW4gdmFyeSBpbiBhIG5ldHdvcmsuICAgVGhl
cmVmb3JlLCB0byBwcmVzZXJ2ZSB0aGUgdXNhZ2Ugb2YgdGhlIE5NQyBmcm9tIFJGQzQzMjggbm9k
ZXMgd2hpY2ggc3VwcG9ydGVkIGJvdGggVFMgc2l6ZXMgd291bGQgbmVlZCB0byB0cmFuc2xhdGUg
dGhlIFNFTkRFUl9UU1BFQyBvYmplY3QgYXQgZWFjaCBob3AgdG8gZW5jb2RlIHRoZSByaWdodCBO
TUMgdmFsdWUgZ2l2ZW4gdGhlIFRTIHRvIGJlIHVzZWQgb24gYSBnaXZlbiBob3AuICAgVGhpcyBp
c26hr3QgdHlwaWNhbCBiZWhhdmlvdXIgZm9yIGEgU0VOREVSX1RTUEVDLg0KDQpHaXZlbiB0aGUg
YWJvdmUsIGl0IHNlZW1zIHRvIG1lIGVhc2llciB0byByZXZlcnQgYmFjayB0byB0aGUgb3JpZ2lu
YWwgZGVmaW5pdGlvbiwgd2hpY2ggZGVwcmVjYXRlZCB0aGlzIGZpZWxkIGZyb20gUkZDNDMyOC4g
ICBUbyBwcmVzZXJ2ZSBiYWNrLWNvbXBhdGliaWxpdHkgd2l0aCBSRkM0MzI4LCBJIHVuZGVyc3Rh
bmQgeW91oa92ZSBhbHJlYWR5IGFncmVlZCB0aGF0IG5vZGVzIHN1cHBvcnRpbmcgZHJhZnQtemhh
bmctY2NhbXAtZ21wbHMtZXZvbHZpbmctZzcwOSBzaG91bGQgc2lnbmFsIE9UTiBMU1BzIHdpdGgg
c3dpdGNoaW5nIGNhcGFiaWxpdHkgMTAxIChPVE4tVERNIGNhcGFibGUpLiAgVGhpcyBtYWtlcyBp
dCBzYWZlIHRvIGRlcHJlY2F0ZSB0aGUgTk1DIGZpZWxkIGluIHRoaXMgbmV3IHVzYWdlLg0KDQpX
aGF0IGRvIHlvdSB0aGluaz8NCg0KQ2hlZXJzLA0KDQpCZW4NCg==

--Boundary_(ID_m1n9JcmwHNVegDToov9AEA)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: quoted-printable










Hi Ben,


 


I personally quite agree with you that the easy way is to deprecate NMC.=
 


 


We will add some text to address that (at least an editors' note will be=
 added to capture that).


 


Fatai


 


Thanks


 


 


 




=B7=A2=BC=FE=C8=CB: ccamp-bounces@ietf.org=
 [ccamp-bounces@ietf.org] =B4=FA=B1=ED Ben Wright [Ben.Wright@metaswitch.co=
m]

=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA9=D4=C227=C8=D5 17:10

=B5=BD: ccamp@ietf.org

=D6=F7=CC=E2: [CCAMP] Question on NMC in draft-zhang-ccamp-gmpls-evo=
lving-g709












Hi all, 


 


I had a detailed query =
about the NMC usage in draft-zhang-ccamp-gmpls-evolving-g709.   T=
his inherits the usage of the NMC from RFC4328, which would indicate the nu=
mber of tributary slots requested for this signal
 type.   I think the following are both true.  


-  =
;       
This information is stric=
tly speaking redundant because the label now describes how the signal type =
will be multiplexed onto a given link.



-  =
;       
With the introduction of =
the 1.25Gbps size, the tributary slot size can vary in a network. &nbs=
p; Therefore, to preserve the usage of the NMC from RFC4328 nodes which sup=
ported both TS sizes would need to translate
 the SENDER_TSPEC object at each hop to encode the right NMC value given th=
e TS to be used on a given hop.   This isn=A1=AFt typical behavio=
ur for a SENDER_TSPEC.   


 


Given the above, it see=
ms to me easier to revert back to the original definition, which deprecated=
 this field from RFC4328.   To preserve back-compatibility with R=
FC4328, I understand you=A1=AFve already agreed that
 nodes supporting draft-zhang-ccamp-gmpls-evolving-g709 should signal OTN L=
SPs with switching capability 101 (OTN-TDM capable).  This makes it sa=
fe to deprecate the NMC field in this new usage.


 


What do you think? =
; 


 


Cheers, 


 


Ben












--Boundary_(ID_m1n9JcmwHNVegDToov9AEA)--

From zhangfatai@huawei.com  Tue Sep 27 19:27:21 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39CE41F0C42 for ; Tue, 27 Sep 2011 19:27:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.895
X-Spam-Level: 
X-Spam-Status: No, score=-0.895 tagged_above=-999 required=5 tests=[AWL=-3.345, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id to1A4v60+x4p for ; Tue, 27 Sep 2011 19:27:20 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id E620211E8073 for ; Tue, 27 Sep 2011 19:27:14 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS700C71O9V55@szxga04-in.huawei.com> for ccamp@ietf.org; Wed, 28 Sep 2011 10:29:55 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS700AYJO7KV7@szxga04-in.huawei.com> for ccamp@ietf.org; Wed, 28 Sep 2011 10:29:55 +0800 (CST)
Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id ADY28995; Wed, 28 Sep 2011 10:29:52 +0800
Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 28 Sep 2011 10:29:49 +0800
Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.142]) by szxeml403-hub.china.huawei.com ([10.82.67.35]) with mapi id 14.01.0270.001; Wed, 28 Sep 2011 10:29:42 +0800
Date: Wed, 28 Sep 2011 02:29:42 +0000
From: Zhangfatai 
In-reply-to: 
X-Originating-IP: [172.24.2.40]
To: "Margaria, Cyril (NSN - DE/Munich)" , "ccamp@ietf.org" 
Message-id: 
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_R/sRx6EyrsvZjE7AekKJ2w)"
Content-language: zh-CN
Accept-Language: zh-CN, en-US
Thread-topic: =?gb2312?B?ILTwuLQ6IFtDQ0FNUF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jY2FtcC1n?= =?gb2312?Q?mpls-general-constraints-ospf-te-02.txt?=
Thread-index: AQHMeQhw4fH7IgNgHEuaM0yhaE8MRpVfUxoggAGhYTmAAAbksIABGMsG
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <20110922090626.6373.58763.idtracker@ietfa.amsl.com>   A  
Subject: [CCAMP] =?gb2312?b?tPC4tDogILTwuLQ6ICBJLUQgQWN0aW9uOiBkcmFmdC1p?= =?gb2312?b?ZXRmLWNjYW1wLWdtcGxzLWdlbmVyYWwtY29uc3RyYWludHMtb3NwZi10ZS0w?= =?gb2312?b?Mi50eHQ=?=
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Sep 2011 02:27:21 -0000

--Boundary_(ID_R/sRx6EyrsvZjE7AekKJ2w)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: base64

SGkgQ3lyaWwsDQoNCg0KDQpJIGFncmVlIG9uIHlvdXIgZmlyc3Qgc3VnZ2VzdGlvbi4NCg0KDQoN
ClNlY29uZGx5LCB0aGlzIGRyYWZ0IGlzIGdlbmVyaWMsIHdoZW4gaXQgbmVlZHMgdG8gYWR2ZXJ0
aXNlIGxhYmVsIGluZm9ybWF0aW9uIGZvciBzb21lIHNwZWNpZmljIHRlY2ggKGUuZy4sIFRETSks
IHRoZSBkb2N1bWVudCBhYm91dCBzcGVjaWZpYyB0ZWNoIGNhbiByZWZlciB0byB0aGlzIGRyYWZ0
IGFuZCBzaG91bGQgZGVmaW5lIGhvdyB0byBjb3JyZWxhdGUgdGhlIElTQ0RzIGFuZCBsYWJlbCBz
dWItVExWcyBpZiB0aGVyZSBpcyBubyBleHBsaWNpdCBvciBpbXBsaWNpdCByZWxhdGlvbnNoaXAg
YmV0d2VlbiB0aGVtIChJIHRoaW5rIHRoZXJlIGFyZSBsb3RzIG9mIHBvdGVudGlhbCBzb2x1dGlv
bnMgdG8gaGFuZGxlIHRoYXQsIGl0IGlzIHF1aXRlIHRlY2ggc3BlY2lmaWMgc3R1ZmYpLg0KDQoN
Cg0KDQoNCkZhdGFpDQoNCg0KDQpUaGFua3MNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0Kt6K8/sjLOiBNYXJnYXJpYSwgQ3lyaWwgKE5TTiAtIERFL011bmljaCkg
W2N5cmlsLm1hcmdhcmlhQG5zbi5jb21dDQq3osvNyrG85DogMjAxMcTqOdTCMjfI1SAxNzozOA0K
tb06IFpoYW5nZmF0YWk7IGNjYW1wQGlldGYub3JnDQrW98ziOiBSRTogtPC4tDogW0NDQU1QXSBJ
LUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWdlbmVyYWwtY29uc3RyYWludHMtb3Nw
Zi10ZS0wMi50eHQNCg0KSGksDQoNClRoYW5rcyBmb3IgdGhlIGFuc3dlciwNCg0KUGxlYXNlIHNl
ZSBpbmxpbmUNCg0KDQpGcm9tOiBleHQgWmhhbmdmYXRhaSBbbWFpbHRvOnpoYW5nZmF0YWlAaHVh
d2VpLmNvbV0NClNlbnQ6IFR1ZXNkYXksIFNlcHRlbWJlciAyNywgMjAxMSAxMToxNyBBTQ0KVG86
IE1hcmdhcmlhLCBDeXJpbCAoTlNOIC0gREUvTXVuaWNoKTsgY2NhbXBAaWV0Zi5vcmcNClN1Ympl
Y3Q6ILTwuLQ6IFtDQ0FNUF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5l
cmFsLWNvbnN0cmFpbnRzLW9zcGYtdGUtMDIudHh0DQoNCg0KSGkgQ3lyaWwsDQoNClRoYW5rcyBm
b3IgeW91ciBjb21tZXRzLg0KDQpQbGVhc2Ugc2VlIGluLWxpbmUgYmVsb3cuDQoNCg0KRmF0YWkN
Cg0KVGhhbmtzDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
DQq3orz+yMs6IE1hcmdhcmlhLCBDeXJpbCAoTlNOIC0gREUvTXVuaWNoKSBbY3lyaWwubWFyZ2Fy
aWFAbnNuLmNvbV0NCreiy83KsbzkOiAyMDExxOo51MIyNsjVIDE2OjAzDQq1vTogWmhhbmdmYXRh
aTsgY2NhbXBAaWV0Zi5vcmcNCtb3zOI6IFJFOiBbQ0NBTVBdIEktRCBBY3Rpb246IGRyYWZ0LWll
dGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC1jb25zdHJhaW50cy1vc3BmLXRlLTAyLnR4dA0KDQpIaSwN
Cg0KSSBoYXZlIHRoZSBmb2xsb3dpbmcgY29tbWVudHMvcXVlc3Rpb24gcmVnYXJkaW5nIHRoaXMg
cmV2aXNpb24NCg0KMy4yLiBBdmFpbGFibGUgTGFiZWxzOg0KDQpUaGUgdGV4dCBzdGF0ZSA6IKGw
VGhlIEF2YWlsYWJsZSBMYWJlbHMgc3ViLVRMViAgIG1heSBvY2N1ciBhdCBtb3N0IG9uY2Ugd2l0
aGluIHRoZSBsaW5rIFRMVi6hsQ0KDQpIb3cgdG8gZW5jb2RlIGRpZmZlcmVudCBsYWJlbCBmb3Jt
YXQgaW4gdGhhdCBjYXNlPyBJIHRoaW5rIHRoZSBsYWJlbCBmb3JtYXQgd291bGQgZGVwZW5kDQpv
biB0aGUgSVNDRCwgYW5kIGFzIHdlIG1pZ2h0IGhhdmUgc2V2ZXJhbCBJU0NELCBoYXZpbmcgc2V2
ZXJhbCBBdmFpbGFibGUgTGFiZWwgc3ViLVRMViBtYWtlIHNlbnNlLg0KVGhpcyBhbHNvIGFwcGx5
IHRvIDMuMy4gU2hhcmVkIEJhY2t1cCBMYWJlbHMuDQoNCltGYXRhaV0gVGhpcyAibWF5IiBzaG91
bGQgYmUgIk1BWSIgYWNjb3JkaW5nIHRvIExvdSdzIHN1Z2dlc3Rpb24sIHNvIGl0IGRvZXMgbm90
IHByZXZlbnQgeW91IHRvIGhhdmUgc2V2ZXJhbCBhdmFpbGFibGUgbGFiZWwgc3ViLVRMVnMuDQoN
Cg0KW0N5cmlsXSBTdGF0aW5nIKGwVGhlIEF2YWlsYWJsZSBMYWJlbHMgc3ViLVRMViAgIE1BWSAg
b2NjdXIgbW9yZSB0aGFuIG9uY2Ugd2l0aGluIHRoZSBsaW5rIFRMVi6hsSAgV291bGQgYmUgbW9y
ZSBhY2N1cmF0ZSBhbmQgZWFzaWVyIHRvIHVuZGVyc3RhbmQuDQoNCg0KDQpJbiBjYXNlIG9mIHNl
dmVyYWwgSVNDRCBhcmUgcHJlc2VudCBmb3IgYSBnaXZlbiBhZHZlcnRpc2VtZW50IGhvdyB0byBp
bnRlcnByZXQgdGhlIGxhYmVsIGZvcm1hdCBpbiB0aGUNCmxhYmVsLXJlbGF0ZWQgc3ViLVRMVnM/
DQoNCltGYXRhaV0gSXQgaXMgZWFzeSB0byBhY2hpdmUgdGhhdC4gZS5nLCBpbiBTREggbmV0d29y
aywgYSBub2RlIGNhbiBhZHZlcnRpc2Ugc2V2ZXJhbCBJU0NEcyB3aXRoIG9uZSBvciBtdWx0aXBs
ZSBsYWJlbCBzdWItVExWcyAoSSBhc3N1bWUgIklGIiBsYWJlbCBpbmZvcm1hdGlvbiBpcyBuZWVk
ZWQgdG8gYmUgYWR2ZXJ0aXNlZCBoZXJlKSwgd2h5IGl0IGNhbm5vdCBpbnRlcnByZXQgdGhlIGxh
YmVscyBhcmUgU0RIIGxhYmVscz8NCg0KW0N5cmlsXSAgSWYgdGhlcmUgaXMgMiBJU0NEIHN1Yi1U
TFYgYW5kIDIgYXZhaWxhYmxlIGxhYmVsIHN1Yi1UTFYsIGhvdyB0byB0ZWxsIHdoaWNoIGF2YWls
YWJsZSBsYWJlbCBzdWItVExWIHJlbGF0ZSB0byB3aGljaCBJU0NEIHN1Yi1UTFY/DQoNCg0KDQpD
b3VsZCB5b3UgY2xhcmlmeSB0aGlzIHBvaW50LCBpdCB3b3VsZCBiZSB1c2VmdWwgZm9yIGluc3Rh
bmNlIHRvIGNvbnNpZGVyIHRoZSBleGFtcGxlIG9mIGEgbGluayBzdXBwb3J0aW5nIFNESA0KKG5v
IFZDNC1zd2l0Y2hpbmcpLCBPRFUgKEcuNzA5LCBhcyBvZiBSRkM0MzI4LCBhbmQgZm9yIHRoZSBj
dXJyZW50IEcuNzA5IHYzIGxhYmVsIGZvcm1hdCkuDQoNCg0KDQpbRmF0YWldICBEbyB5b3UgbWVh
biB0byBoYXZlIGFuIGV4YW1wbGUgb24gaHlicmlkIG5vZGU/IEkgd2lsbCBub3QgdXNlIGEgY29t
cGxleCBleGFtcGxlIHRvIGV4cGxhaW4gYSBraW5kIG9mIHNpbXBsZSB0aGluZyAoSXQgd2lsbCBj
b25mdXNlIHBlb3BsZSkuDQoNCltDeXJpbF0gSXQgbWF5IG5vdCBiZSBzbyBzaW1wbGUsIEkgaGF2
ZSB0cm91YmxlIHRvIGludGVycHJldCBsYWJlbCB3aXRob3V0IGtub3dpbmcgdGhlIElTQ0QgY29u
c2lkZXJlZCBhbmQgSSBkbyBub3Qgc2VlIGNsZWFybHkgdGhlIHJlbGF0aW9uIGJldHdlZW4gdGhl
IHR3byBpbiB0aGUgZG9jdW1lbnQuDQoNClRoZSB0ZXh0IGlzIHZlcnkgZm9jdXNlZCBvbiBXU09O
LCB3aGlsZSBpdCBpcyBhIHZlcnkgaW50ZXJlc3RpbmcgZXhhbXBsZSwgaGF2aW5nIG90aGVyIHRl
Y2hub2xvZ3kgKE9UTiBmb3INCmV4YW1wbGUgd291bGQgaGVscCB0byBzaG93IHRoYXQgdGhlIHNv
bHV0aW9uIGlzIGdlbmVyaWMuDQoNCltGYXRhaV0gSSB0aGluayBvbmUgdHlwaWNhbCBleGFtcGxl
IGlzIHN1ZmZpY2llbnQgZm9yIHBlb3BsZSB0byB1bmRlcnN0YW5kIHRoaW5ncy4gVERNIG5ldHdv
cmsgaXMgZGlmZmVyZW50IGZyb20gV1NPTiBuZXR3b3JrLiBJbiBURE0gbmV0d29yaywgdXN1YWxs
eSBpdCB3aWxsIG5vdCBhZHZlcnRpc2UgbGFiZWwgaW5mb3JtYXRpb24gZXZlbiB0aG91Z2ggbGFi
ZWwgaW5mb3JtYXRpb24gY291bGQgYmUgYWR2ZXJ0aXNlZC4NCg0KW0N5cmlsXSBUaGV5IGFyZSBp
bmRlZWQgZGlmZmVyZW50LCBidXQgZnJvbSBsYWJlbCBwb2ludCBvZiB2aWV3IGl0IHNob3VsZCBu
b3QgbWFrZSBhIGRpZmZlcmVuY2UuIEEgdXN1YWwgdXNlIGNhc2Ugb2YgY29ubmVjdGl2aXR5IG1h
dHJpeCB3b3VsZCBiZSBmb3IgZXhhbXBsZSBvbiBjbGllbnQgY2FyZHMgd2l0aCBzd2l0Y2hpbmcg
cmVzdHJpY3Rpb24gOiBmaXhlZCBNdWx0aXBsZXggYW5kIGxhYmVsIGFzc2lnbm1lbnQgZHVlIHRv
IHRoZSBmaXhlZCBNVVggKE9EVTItPk9EVTEgZm9yIGluc3RhbmNlKSAgb24gRFdETSBub2RlIDoN
Cg0KdGhlIHJlc3RyaWN0aW9uIGNhbiBiZSBtb2RlbGVkIGFzIG9uZSBjb25uZWN0aXZpdHkgbWF0
cml4IHBlciBjbGllbnQgcG9ydCwNCg0KICAgICAgICB0aGUgY2xpZW50IHBvcnQgaGF2ZSB0aGVu
IElTQ0QgVERNLA0KDQogICAgICAgIHRoZSBvdGhlciBwb3J0cyBjYW4gZG8gRFdETSBhbmQgVERN
LA0KDQogICAgICAgIGZvciB0aGUgY29ubmVjdGl2aXR5IG1hdHJpeCBjb3JyZXNwb25kaW5nIHRv
IGEgY2xpZW50IHBvcnQgdGhlIG9ubHkgT0RVIGxhYmVsIHRvIGJlIGFzc2lnbmVkIChkdWUgdG8g
Zml4ZWQgTVVYKSBpcyBzcGVjaWZpZWQNCg0KDQoNCkZpcnN0LCBpcyB0aGlzIG1vZGVsaW5nIGNv
cnJlY3Q/DQoNClNlY29uZCwgaG93IHRvIG1ha2Ugc3VyZSB0aGUgbGFiZWwgcmVzdHJpY3Rpb24g
YXJlIHRvIGJlIGludGVycHJldGVkIGFzIE9EVSBsYWJlbHM/DQoNCg0KDQpJIHRoaW5rIGl0IGlz
IGFsc28gaW1wb3J0YW50IHRvIHNob3cgdGhhdCB0aGUgZXh0ZW5zaW9ucyBhcmUgYWxzbyB3b3Jr
aW5nIG91dHNpZGUgdGhlIGZyYW1ld29yayB0aGV5IHdlcmUgYm9ybiAoV1NPTikuDQoNCg0KDQpC
Ug0KDQoNCkJlc3QgUmVnYXJkcywNCkN5cmlsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t
LS0NCj4gRnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNA
aWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZiBleHQgWmhhbmdmYXRhaQ0KPiBTZW50OiBUaHVyc2Rh
eSwgU2VwdGVtYmVyIDIyLCAyMDExIDExOjE3IEFNDQo+IFRvOiBjY2FtcEBpZXRmLm9yZw0KPiBT
dWJqZWN0OiBSZTogW0NDQU1QXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWdl
bmVyYWwtDQo+IGNvbnN0cmFpbnRzLW9zcGYtdGUtMDIudHh0DQo+DQo+IEhpIENDQU1QZXJzLA0K
Pg0KPiBBIG5ldyB2ZXJzaW9uIGhhcyBiZWVuIHN1Ym1pdHRlZCB0byBhZGRyZXNzIHRoZSBjb21t
ZW50cyBmcm9tIHRoZSBXRw0KPiBkaXNjdXNzaW9uLg0KPg0KPiBXZSBhY2NlcHRlZCBBY2VlIGFu
ZCBZb3VuZydzIHN1Z2dlc3Rpb24gdG8gaW50cm9kdWNlIGEgbmV3IHRvcC1sZXZlbA0KPiBub2Rl
IFRMViAoR2VuZXJpYyBOb2RlIEF0dHJpYnV0ZSBUTFYpIHRvIHNpbXBsaWZ5IHRoaW5ncyBhbmQg
YSBuZXcNCj4gc2VjdGlvbiAoU2VjdGlvbiA1KSB3YXMgYWRkZWQgdG8gZGVzY3JpYmUgc2NhbGFi
aWxpdHkgaXNzdWUuDQo+DQo+IE1vcmUgaW5mb3JtYXRpb24gZnJvbTogaHR0cDovL3d3dy5pZXRm
Lm9yZy9pZC9kcmFmdC1pZXRmLWNjYW1wLWdtcGxzLQ0KPiBnZW5lcmFsLWNvbnN0cmFpbnRzLW9z
cGYtdGUtMDIudHh0DQo+DQo+IFBsZWFzZSBjaGVjayBvdXQgZm9yIGRldGFpbHMgYW5kIGNvbW1l
bnRzIGFyZSBhbHdheXMgd2VsY29tZS4NCj4NCj4NCj4gVGhhbmtzDQo+DQo+IEZhdGFpDQo+DQo+
DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGNjYW1wLWJvdW5jZXNAaWV0
Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2YgaW50
ZXJuZXQtZHJhZnRzQGlldGYub3JnDQo+IFNlbnQ6IDIwMTHE6jnUwjIyyNUgMTc6MDYNCj4gVG86
IGktZC1hbm5vdW5jZUBpZXRmLm9yZw0KPiBDYzogY2NhbXBAaWV0Zi5vcmcNCj4gU3ViamVjdDog
W0NDQU1QXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWdlbmVyYWwtDQo+IGNv
bnN0cmFpbnRzLW9zcGYtdGUtMDIudHh0DQo+DQo+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2
YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KPiBkaXJlY3Rvcmllcy4g
VGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQ29tbW9uIENvbnRyb2wgYW5kDQo+IE1l
YXN1cmVtZW50IFBsYW5lIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+DQo+ICAgICAgIFRp
dGxlICAgICAgICAgICA6IE9TUEYtVEUgRXh0ZW5zaW9ucyBmb3IgR2VuZXJhbCBOZXR3b3JrIEVs
ZW1lbnQNCj4gQ29uc3RyYWludHMNCj4gICAgICAgQXV0aG9yKHMpICAgICAgIDogRmF0YWkgWmhh
bmcNCj4gICAgICAgICAgICAgICAgICAgICAgICAgICBZb3VuZyBMZWUNCj4gICAgICAgICAgICAg
ICAgICAgICAgICAgICBKaWFucnVpIEhhbg0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIEdy
ZWcgQmVybnN0ZWluDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgWXVuYmluIFh1DQo+ICAg
ICAgIEZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC1jb25z
dHJhaW50cy0NCj4gb3NwZi10ZS0wMi50eHQNCj4gICAgICAgUGFnZXMgICAgICAgICAgIDogMTQN
Cj4gICAgICAgRGF0ZSAgICAgICAgICAgIDogMjAxMS0wOS0yMg0KPg0KPiAgICBHZW5lcmFsaXpl
ZCBNdWx0aXByb3RvY29sIExhYmVsIFN3aXRjaGluZyBjYW4gYmUgdXNlZCB0byBjb250cm9sIGEN
Cj4gICAgd2lkZSB2YXJpZXR5IG9mIHRlY2hub2xvZ2llcyBpbmNsdWRpbmcgcGFja2V0IHN3aXRj
aGluZyAoZS5nLiwNCj4gTVBMUyksDQo+ICAgIHRpbWUtZGl2aXNpb24gKGUuZy4sIFNPTkVUL1NE
SCwgT1ROKSwgd2F2ZWxlbmd0aCAobGFtYmRhcyksIGFuZA0KPiAgICBzcGF0aWFsIHN3aXRjaGlu
ZyAoZS5nLiwgaW5jb21pbmcgcG9ydCBvciBmaWJlciB0byBvdXRnb2luZyBwb3J0IG9yDQo+ICAg
IGZpYmVyKS4gSW4gc29tZSBvZiB0aGVzZSB0ZWNobm9sb2dpZXMgbmV0d29yayBlbGVtZW50cyBh
bmQgbGlua3MgbWF5DQo+ICAgIGltcG9zZSBhZGRpdGlvbmFsIHJvdXRpbmcgY29uc3RyYWludHMg
c3VjaCBhcyBhc3ltbWV0cmljIHN3aXRjaA0KPiAgICBjb25uZWN0aXZpdHksIG5vbi1sb2NhbCBs
YWJlbCBhc3NpZ25tZW50LCBhbmQgbGFiZWwgcmFuZ2UNCj4gbGltaXRhdGlvbnMNCj4gICAgb24g
bGlua3MuIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIE9TUEYgcm91dGluZyBwcm90b2NvbCBleHRl
bnNpb25zDQo+IHRvDQo+ICAgIHN1cHBvcnQgdGhlc2Uga2luZHMgb2YgY29uc3RyYWludHMgdW5k
ZXIgdGhlIGNvbnRyb2wgb2YgR2VuZXJhbGl6ZWQNCj4gICAgTVBMUyAoR01QTFMpLg0KPg0KPg0K
Pg0KPiBBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFmdCBpczoNCj4gaHR0cDovL3d3dy5pZXRm
Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLQ0KPiBj
b25zdHJhaW50cy1vc3BmLXRlLTAyLnR4dA0KPg0KPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28g
YXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRl
cm5ldC1kcmFmdHMvDQo+DQo+IFRoaXMgSW50ZXJuZXQtRHJhZnQgY2FuIGJlIHJldHJpZXZlZCBh
dDoNCj4gZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWNjYW1w
LWdtcGxzLWdlbmVyYWwtDQo+IGNvbnN0cmFpbnRzLW9zcGYtdGUtMDIudHh0DQo+IF9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IENDQU1QIG1haWxpbmcg
bGlzdA0KPiBDQ0FNUEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp
c3RpbmZvL2NjYW1wDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQo+IENDQU1QIG1haWxpbmcgbGlzdA0KPiBDQ0FNUEBpZXRmLm9yZw0KPiBodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQo=

--Boundary_(ID_R/sRx6EyrsvZjE7AekKJ2w)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: quoted-printable










Hi Cyril,


 


I agree on your first suggestion.


 


Secondly, this draft is generic, when it needs to advertise label i=
nformation for some specific tech (e.g., TDM), the document about spec=
ific tech can refer to this draft and should define how to correl=
ate the ISCDs and label sub-TLVs if there is no explicit
 or implicit relationship between them (I think there are lo=
ts of potential solutions to handle that, it is quite tech specific stuff).



 


 


Fatai


 


Thanks


 


 




=B7=A2=BC=FE=C8=CB: Margaria, Cyril (NSN -=
 DE/Munich) [cyril.margaria@nsn.com]

=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA9=D4=C227=C8=D5 17:38

=B5=BD: Zhangfatai; ccamp@ietf.org

=D6=F7=CC=E2: RE: =B4=F0=B8=B4: [CCAMP] I-D Action: draft-ietf-ccamp=
-gmpls-general-constraints-ospf-te-02.txt












Hi,



 


Thanks for the answer,



 


Please see inline


 


 








From: ext Zhangfatai [mailto:zhangfatai@huawei.com]


Sent: Tuesday, September 27, 2011 11:17 AM

To: Margaria, Cyril (NSN - DE/Munich); ccamp@ietf.org

Subject: =B4=
=F0=B8=B4: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-constraints-o=
spf-te-02.txt






 




Hi Cyril,



Thanks for your commets.



Please see in-line below.





Fatai



Thanks







________________________________________

=B7=A2=
=BC=FE=C8=CB: Margaria, Cyril (NSN - DE/Munich) [cyril.margar=
ia@nsn.com]

=B7=A2=
=CB=CD=CA=B1=BC=E4: 2011=C4=EA9=D4=C226<=
span style=3D"COLOR: black; FONT-SIZE: 10pt" lang=3D"ZH-CN">=C8=D5
 16:03

=B5=BD<=
/span>: Zhangfatai; ccamp@ietf.org

=D6=F7=
=CC=E2: RE: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-genera=
l-constraints-ospf-te-02.txt



Hi,



I have the following comments/question regarding this revision



3.2. Available Labels:



The text state : =A1=B0The Available Labels sub-TLV   may occur a=
t most once within the link TLV.=A1=B1



How to encode different label format in that case? I think the label format=
 would depend

on the ISCD, and as we might have several ISCD, having several Available La=
bel sub-TLV make sense.

This also apply to 3.3. Shared Backup Labels.



[Fatai] This "may" should be "MAY" accordi=
ng to Lou's suggestion, so it does not prevent you to have several availabl=
e label sub-TLVs.







[Cyril] Stating =A1=B0The Available Labels sub-TLV  =
 MAY  occur more than once within the link TLV.=A1=B1  Would be m=
ore accurate and easier to understand.


 




In case of several ISCD are present for a given advertisement how to interp=
ret the label format in the

label-related sub-TLVs?




[Fatai] It is easy to achive that. e.g, in SDH network, a=
 node can advertise several ISCDs with one or multiple label sub-TLVs =
(I assume "IF" label information is needed to
 be advertised here), why it cannot interpret the labels are SDH labels?


[Cyril]  If there is 2 ISCD sub-TLV and 2 available label =
sub-TLV, how to tell which available label sub-TLV relate to which ISCD sub=
-TLV?


 




Could you clarify this point, it would be useful for instance to consider t=
he example of a link supporting SDH

(no VC4-switching), ODU (G.709, as of RFC4328, and for the current G.709 v3=
 label format).


 


[Fatai]  Do you mean to have an example on hybrid node? I wil=
l not use a complex example to explain a kind of simple=
 thing (It will confuse people).



[Cyril] It may not be so simple, I have trouble to interpret l=
abel without knowing the ISCD considered and I do not see clearly the relat=
ion between the two in the document.




The text is very focused on WSON, while it is a very interesting example, h=
aving other technology (OTN for

example would help to show that the solution is generic.


[Fatai] I think one typical example is sufficient for people to un=
derstand things. TDM network is different from WSON network. In TDM ne=
twork, usually it will not advertise label
 information even though label information could be advertised.[Cyril] They are indeed different, but from label point of view=
 it should not make a difference. A usual use case of connectivity matrix w=
ould be for example on client cards
 with switching restriction : fixed Multiplex and label assignment due to t=
he fixed MUX (ODU2->ODU1 for instance)  on DWDM node :


the restric=
tion can be modeled as one connectivity matrix per client port,


     &nb=
sp;  the client port have then ISCD TDM,



     &nb=
sp;  the other ports can do DWDM and TDM,



     &nb=
sp;  for the connectivity matrix corresponding to a client port t=
he only ODU label to be assigned (due to fixed MUX) is specified



 


First, is this modeling correct?



Second, how to make sure the label restriction are to be inter=
preted as ODU labels?


 


I think it is also important to show that the extensions are a=
lso working outside the framework they were born (WSON).


 


BR






Best Regards,

Cyril



> -----Original Message-----

> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf=


> Of ext Zhangfatai

> Sent: Thursday, September 22, 2011 11:17 AM

> To: ccamp@ietf.org

> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-

> constraints-ospf-te-02.txt

>

> Hi CCAMPers,

>

> A new version has been submitted to address the comments from the WG
> discussion.

>

> We accepted Acee and Young's suggestion to introduce a new top-level
> node TLV (Generic Node Attribute TLV) to simplify things and a new

> section (Section 5) was added to describe scalability issue.

>

> More information from: http://www.ietf.org/id/draft-ietf-ccamp-gmpls-<=
br>
> general-constraints-ospf-te-02.txt

>

> Please check out for details and comments are always welcome.

>

>

> Thanks

>

> Fatai

>

>

> -----Original Message-----

> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf=


> Of internet-drafts@ietf.org

> Sent: 2011=C4=EA9=D4=C222=C8=D5
 17:06

> To: i-d-announce@ietf.org

> Cc: ccamp@ietf.org

> Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-

> constraints-ospf-te-02.txt

>

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

> directories. This draft is a work item of the Common Control and

> Measurement Plane Working Group of the IETF.

>

>       Title     =
;      : OSPF-TE Extensions for General Network El=
ement

> Constraints

>       Author(s)    &=
nbsp;  : Fatai Zhang

>            =
;            &n=
bsp;  Young Lee

>            =
;            &n=
bsp;  Jianrui Han

>            =
;            &n=
bsp;  Greg Bernstein

>            =
;            &n=
bsp;  Yunbin Xu

>       Filename    &n=
bsp;   : draft-ietf-ccamp-gmpls-general-constraints-

> ospf-te-02.txt

>       Pages     =
;      : 14

>       Date     =
       : 2011-09-22

>

>    Generalized Multiprotocol Label Switching can be use=
d to control a

>    wide variety of technologies including packet switch=
ing (e.g.,

> MPLS),

>    time-division (e.g., SONET/SDH, OTN), wavelength (la=
mbdas), and

>    spatial switching (e.g., incoming port or fiber to o=
utgoing port or

>    fiber). In some of these technologies network elemen=
ts and links may

>    impose additional routing constraints such as asymme=
tric switch

>    connectivity, non-local label assignment, and label =
range

> limitations

>    on links. This document describes OSPF routing proto=
col extensions

> to

>    support these kinds of constraints under the control=
 of Generalized

>    MPLS (GMPLS).

>

>

>

> A URL for this Internet-Draft is:

> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-general-
> constraints-ospf-te-02.txt

>

> Internet-Drafts are also available by anonymous FTP at:

> ftp://ftp.ietf.org/internet-drafts/

>

> This Internet-Draft can be retrieved at:

> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-general-

> constraints-ospf-te-02.txt

> _______________________________________________

> 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
















--Boundary_(ID_R/sRx6EyrsvZjE7AekKJ2w)--

From lberger@labn.net  Wed Sep 28 04:33:28 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23CBE21F8B4A for ; Wed, 28 Sep 2011 04:33:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.792
X-Spam-Level: 
X-Spam-Status: No, score=-100.792 tagged_above=-999 required=5 tests=[AWL=-0.631, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moUPNlyzPgn1 for ; Wed, 28 Sep 2011 04:33:27 -0700 (PDT)
Received: from oproxy4-pub.bluehost.com (oproxy4.bluehost.com [IPv6:2605:dc00:100:2::a4]) by ietfa.amsl.com (Postfix) with SMTP id 25CB621F8B39 for ; Wed, 28 Sep 2011 04:33:27 -0700 (PDT)
Received: (qmail 4418 invoked by uid 0); 28 Sep 2011 11:36:12 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by cpoproxy1.bluehost.com with SMTP; 28 Sep 2011 11:36:12 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default;  h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=hKVglnFo+t4yDuqxeVzjklgdCr6Pd7v/M30na+4bGf4=;  b=tgCniSRn63lgeQ3sbidWgIgQ/sn1fBMzDmnpLyyu//WNCqRKl8Dqu8WUbiTetQX07loy9NJjdKMu2hP06sdDgzP6Cu0k6a7evqM8a32TxB52yCXm2KN5b2iBuzwqz1tx;
Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1R8sQu-0000rg-7R; Wed, 28 Sep 2011 05:36:12 -0600
Message-ID: <4E8306AA.60308@labn.net>
Date: Wed, 28 Sep 2011 07:36:10 -0400
From: Lou Berger 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: "Ong, Lyndon" 
References: <4E81CD97.3020209@labn.net><5E893DB832F57341992548CDBB333163A28E05ED10@EMBX01-HQ.jnpr.net><4E81DE57.1080601@labn.net><5E893DB832F57341992548CDBB333163A28E05ED28@EMBX01-HQ.jnpr.net><4E81E48B.8090102@labn.net><5E893DB832F57341992548CDBB333163A28E05ED83@EMBX01-HQ.jnpr.net><4E81EBAD.1050204@labn.net><5E893DB832F57341992548CDBB333163A28E05EF17@EMBX01-HQ.jnpr.net> <4E823C45.6040501@labn.net> 
In-Reply-To: 
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=windows-1252
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] Thought on where to carry G.709-v3 TSG
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Sep 2011 11:33:28 -0000

Lyndon,
	This is actually one of the reasons to make the change. Signal type
will represent the e2e constant connection characteristics, i.e., not
change, while label can change hop-by-hop as is needed to represent
how/where the connection is being carried on a a link.

Lou

On 9/27/2011 7:36 PM, Ong, Lyndon wrote:
> Hi Lou,
> 
> Not quite sure what you are proposing - would this mean the signal
> type changes hop by hop if you are creating a connection that goes
> over links supporting different TS granularity?
> 
> Thanks,
> 
> Lyndon
> 
> 
> 
> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger
> Sent: Tuesday, September 27, 2011 2:13 PM
> To: John E Drake
> Cc: CCAMP
> Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG
> 
> 
> 
> 
> On 9/27/2011 12:40 PM, John E Drake wrote:
>> Lou,
>>
>> Using Signal Type in signaling in addition to the bit map label is
>> probably okay.
> 
> 
>> I don't think it makes any sense in routing and would
>> prefer to continue to just have the two bits.
>>
> 
> On what basis?
> 
> Lou
> 
>> Thanks,
>>
>> John
>>
>>> -----Original Message-----
>>> From: Lou Berger [mailto:lberger@labn.net]
>>> Sent: Tuesday, September 27, 2011 11:29 AM
>>> To: John E Drake
>>> Cc: CCAMP
>>> Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG
>>>
>>> John,
>>>      Two points:
>>>
>>> As a general rule, it doesn't make sense to invent yet another way to
>>> carry information when an existing one will do.  This is actually a
>>> pretty fundamental tenant of GMPLS.
>>>
>>> Also, in GMPLS the general model for allocation is to carry resource
>>> requirements in the TS not the label.  Such use of the TS ensures that
>>> the information is unambiguous in all cases.  (For example, consider
>>> the
>>> corner case where you have a unidirectional LSP, where is TSG
>>> requirements of the sender/upstream node indicated in the Path
>>> message.)
>>>
>>> Lou
>>>
>>> On 9/27/2011 11:13 AM, John E Drake wrote:
>>>> Lou,
>>>>
>>>> Clearly, the info-model draft needs to be updated, but I am quite
>>>> happy with the what is currently in the signaling and routing drafts
>>>> and I haven't heard a compelling reason to change.
>>>>
>>>> Thanks,
>>>>
>>>> John
>>>>
>>>>> -----Original Message-----
>>>>> From: Lou Berger [mailto:lberger@labn.net]
>>>>> Sent: Tuesday, September 27, 2011 10:58 AM
>>>>> To: John E Drake
>>>>> Cc: CCAMP
>>>>> Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG
>>>>>
>>>>> John,
>>>>>    There isn't alignment in the WG info-model and the individual
>>>>> routing
>>>>> and signaling drafts.  I think we have enough ways of explicitly
>>>>> carrying signal information that we can leverage to come up with a
>>>>> clean
>>>>> an unified approach that satisfies all the needs for TSG
>>> information,
>>>>> i.e.:
>>>>>
>>>>>> Given all this [see below], I'd like to propose that we use Option
>>> 5,
>>>>>> Signal Type, to indicate TSG
>>>>>
>>>>> Do you see an issue with using Signal Type to indicate the *service*
>>>>> TSG?  I don't think there would be any change to your proposed
>>>>> (hop-by-hop) label encoding.
>>>>>
>>>>> Lou
>>>>>
>>>>>
>>>>> On 9/27/2011 10:37 AM, John E Drake wrote:
>>>>>> Nevermind.  What is wrong with the current signaling approach,
>>> which
>>>>> by the way I think is great?
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Lou Berger [mailto:lberger@labn.net]
>>>>>>> Sent: Tuesday, September 27, 2011 10:32 AM
>>>>>>> To: John E Drake
>>>>>>> Cc: CCAMP
>>>>>>> Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG
>>>>>>>
>>>>>>> John,
>>>>>>>  I guess I should have titled my mail "Proposal on..." so that the
>>>>>>> proposal would actually get read...
>>>>>>>
>>>>>>> Lou
>>>>>>>
>>>>>>>
>>>>>>> On 9/27/2011 10:23 AM, John E Drake wrote:
>>>>>>>> Lou,
>>>>>>>>
>>>>>>>> In routing (draft-ceccarelli-ccamp-gmpls-ospf-g709-07) we
>>> advertise
>>>>>>>> tributary slot granularity in a new field.  In signaling
>>>>>>>> (draft-zhang-ccamp-gmpls-evolving-g709-09), it is derived from
>>> the
>>>>>>>> length of the TS bit map and the size of the ODUk/OTUk on which
>>> the
>>>>>>>> LSP is to be established.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> John
>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On
>>>>>>> Behalf
>>>>>>>>> Of Lou Berger
>>>>>>>>> Sent: Tuesday, September 27, 2011 9:20 AM
>>>>>>>>> To: CCAMP
>>>>>>>>> Subject: [CCAMP] Thought on where to carry G.709-v3 TSG
>>>>>>>>>
>>>>>>>>> All / G.709 draft authors,
>>>>>>>>>
>>>>>>>>>        We have a few slightly unaligned proposals on where to
>>> indicate
>>>>>>>>> the
>>>>>>>>> [G.709-v3] Tributary Slot Granularity:
>>>>>>>>>
>>>>>>>>> 1: G-PID
>>>>>>>>>     draft-ietf-ccamp-otn-g709-info-model-01 says:
>>>>>>>>>     One possible solution is the G-PID field of the GENERALIZED
>>>>>>> LABEL
>>>>>>>>>     REQUEST Object.
>>>>>>>>>
>>>>>>>>> 2: A new field:
>>>>>>>>>    draft-ceccarelli-ccamp-gmpls-ospf-g709-07 says:
>>>>>>>>>       - TSG: Tributary Slot Granularity (2bit): Used for the
>>>>>>>>>       advertisement of the supported Tributary Slot granularity
>>>>>>>>>
>>>>>>>>> 3: Implicitly:
>>>>>>>>>    draft-zhang-ccamp-gmpls-evolving-g709-09 doesn't explicitly
>>>>>>>>>    signal TSG, but rather has it implied in the new ODU label.
>>>>>>>>>
>>>>>>>>> Some other alternatives include:
>>>>>>>>>
>>>>>>>>> 4: GMPLS Encoding
>>>>>>>>>    Currently used to indicate G.709 (which is also what the
>>> Switch
>>>>>>>>>    cap essentially indicates) An alternative would use:
>>>>>>>>>       12              G.709 ODUk (Digital Path, 2.5G)[RFC4328]
>>>>>>>>>       TBA (e.g., 15)  G.709 ODUk (Digital Path, 1.25G)
>>>>>>>>>
>>>>>>>>>    In routing, 15 would imply support for both 1.25 and 2.5G, as
>>>>>>>>>    support for both by 1.25 capable interfaces is required by
>>>>>>>>>    [G.709-v3]. (At least as I understand it.)
>>>>>>>>>
>>>>>>>>> 5: Signal Type
>>>>>>>>>    Carried in routing ISCD/SCSI and signaling traffic
>>> parameters.
>>>>>>>>>    Could enumerate all ODUx types to indicate either 1.25G or
>>>>> 2.5G.
>>>>>>>>>    Existing types indicate 2.5G, new types would need to be
>>>>>>> enumerated
>>>>>>>>>    for the new 1.25 and 2.5 types.  Hereto, the 1.25 types would
>>>>>>> imply
>>>>>>>>>    support for both 1.25 and 2.5 types in routing.
>>>>>>>>>
>>>>>>>>> As I understand it, TSG is needed at:
>>>>>>>>>   (a) the endpoints that terminate the signal/LSP to ensure
>>> proper
>>>>>>>>>       adaptation.
>>>>>>>>>   (b) the 2nd and penultimate hops to ensure the proper
>>>>>>>>>       interface/H-LSP selection.
>>>>>>>>>   (c) Intermediate nodes for proper TS allocation.
>>>>>>>>>
>>>>>>>>> It seems to me that we have enough existing fields in GMPLS (for
>>>>>>> G.709)
>>>>>>>>> that we should consider these before introducing new ones.  Of
>>> the
>>>>>>>>> existing fields, we have 1, 4 and 5.:
>>>>>>>>>
>>>>>>>>>    Option 1, G-PID, is really designed to support end-point
>>> client
>>>>>>>>>    adaptation, so as an end-point only field it really only
>>>>> supports
>>>>>>>>>    need (a), so I don't think G-PID is the right place to
>>> indicate
>>>>>>> TSG.
>>>>>>>>>
>>>>>>>>>    Option 4, Encoding, is used to support (a) and (b)-type
>>> checks
>>>>> in
>>>>>>>>>    GMPLS, but not (c).  So, while this field is definitely a
>>>>> better
>>>>>>>>>    place than G-PID to indicate TSG, it doesn't satisfy all the
>>>>>>> needs.
>>>>>>>>>
>>>>>>>>>    Option 5, Signal Type, is used to support all needs.
>>>>>>>>>
>>>>>>>>> Given all this, I'd like to propose that we use Option 5, Signal
>>>>>>> Type,
>>>>>>>>> to indicate TSG, and that this be reflected in the relevant WG
>>>>>>> drafts.
>>>>>>>>> (Authors, let me know if you'd like specific text proposals.)
>>>>>>>>>
>>>>>>>>> Comments?
>>>>>>>>>
>>>>>>>>> Much thanks,
>>>>>>>>> Lou (as WG contributor)
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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 sergio.belotti@alcatel-lucent.com  Wed Sep 28 05:00:12 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D45121F8D15 for ; Wed, 28 Sep 2011 05:00:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.902
X-Spam-Level: 
X-Spam-Status: No, score=-4.902 tagged_above=-999 required=5 tests=[AWL=1.347,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m1qqIGMd1Uba for ; Wed, 28 Sep 2011 05:00:11 -0700 (PDT)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by ietfa.amsl.com (Postfix) with ESMTP id 5BEC921F8D23 for ; Wed, 28 Sep 2011 05:00:11 -0700 (PDT)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p8SC2QnN023891 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 28 Sep 2011 14:02:57 +0200
Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 28 Sep 2011 14:02:41 +0200
From: "BELOTTI, SERGIO (SERGIO)" 
To: "'Lou Berger'" 
Date: Wed, 28 Sep 2011 14:02:40 +0200
Thread-Topic: [CCAMP] Thought on where to carry G.709-v3 TSG
Thread-Index: Acx9GEaCdOFyEue6RSmRSU4oGnToQAAnq79g
Message-ID: 
References: <4E81CD97.3020209@labn.net>
In-Reply-To: <4E81CD97.3020209@labn.net>
Accept-Language: en-US
Content-Language: it-IT
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13
Cc: CCAMP 
Subject: [CCAMP] R:  Thought on where to carry G.709-v3 TSG
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Sep 2011 12:00:12 -0000

Hi Lou,

Please see in line .

BR

Sergio and Pietro


-----Messaggio originale-----
Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Lou=
 Berger
Inviato: marted=EC 27 settembre 2011 15.20
A: CCAMP
Oggetto: [CCAMP] Thought on where to carry G.709-v3 TSG

All / G.709 draft authors,

	We have a few slightly unaligned proposals on where to indicate the
[G.709-v3] Tributary Slot Granularity:



1: G-PID
    draft-ietf-ccamp-otn-g709-info-model-01 says:
    One possible solution is the G-PID field of the GENERALIZED LABEL
    REQUEST Object.

[ALU]What inserted in the INFO draft , is the result of the discussion made=
 in July on the subject, in the mailing , taking into account suggestion an=
d comments coming from John, Jonathan and others participating at the discu=
ssion.
Our opinion is that the ending draft for signaling should be aligned to the=
 info model draft incorporating the required changes to GPID. The motivatio=
ns behind our opinion can be better understood reading the other comments.

2: A new field:
   draft-ceccarelli-ccamp-gmpls-ospf-g709-07 says:
      - TSG: Tributary Slot Granularity (2bit): Used for the
      advertisement of the supported Tributary Slot granularity
[ALU] In the INFO we have explained the need also for TSG in routing (follo=
wing conclusion of mailing list discussion) and the routing draft simply pr=
oposes a possible encoding of the information.
This solution, for the sake of truth, can be getting better, taking into ac=
count the AutoPayloadtype flag information. This information is a typical M=
I information , described in in G.798, and it simply tells us whether Fallb=
ack procedure is enabled or not.=20
Since this information is typically configured by the manager we do not thi=
nk it has to be considered directly in the control plane (neither signaled =
or advertised ). However we have to take into account the fact that
auto-payload type set to off generates interfaces that can support 1.25 TSG=
 only.=20

This fact can be incorporated in routing by adding a new meaning in the two=
 bits encodings:

         - 00 - 1.25 Gbps (AutoPayloadtype off)

         - 01 - 1.25 Gbps (AutoPayloadType on)

         - 10 - 2.5 Gbps=20

         - 11 - Reserved


3: Implicitly:
   draft-zhang-ccamp-gmpls-evolving-g709-09 doesn't explicitly
   signal TSG, but rather has it implied in the new ODU label.

[ALU] There is nothing implicitly. The reality is that at the moment signal=
ing draft does not address the problem . What you consider as "implicitly d=
educed" is in fact the TSG granularity with which the client is mapped in t=
he server ODUk/OTUK or FA/H-LSP. What has to be clarified is that what we n=
eed to signal is an adaptation information regarding what the server can ex=
pose to the client regarding TS granularity capability.=20
TS size is an attribute of the adaptation used to put an ODUj into an ODUk.
What you consider as implicit is just how ODUj is mapped into ODUk, but the=
 problem is to signal ODUk with the correct adaptation attribute.

Some other alternatives include:

4: GMPLS Encoding
   Currently used to indicate G.709 (which is also what the Switch
   cap essentially indicates) An alternative would use:
      12              G.709 ODUk (Digital Path, 2.5G)[RFC4328]
      TBA (e.g., 15)  G.709 ODUk (Digital Path, 1.25G)

   In routing, 15 would imply support for both 1.25 and 2.5G, as
   support for both by 1.25 capable interfaces is required by
   [G.709-v3]. (At least as I understand it.)

[ALU] Encoding field should define the nature of the LSP : RFC 4328 defined=
 two OTN new values G.709 ODUk (Digital Path) and G.709 Optical Channel. We=
 do not see any reason to link encoding with information that would need to=
 choose interfaces (as TSG) since the "nature " of LSP does not change depe=
ndently of the usage of 1.25 or 2.5 ODUk tributary slot.

5: Signal Type
   Carried in routing ISCD/SCSI and signaling traffic parameters.
   Could enumerate all ODUx types to indicate either 1.25G or 2.5G.
   Existing types indicate 2.5G, new types would need to be enumerated
   for the new 1.25 and 2.5 types.  Hereto, the 1.25 types would imply
   support for both 1.25 and 2.5 types in routing.

[ALU] During the discussion in July the usage of Signal Type was one of the=
 first possibilities analyzed. We definitely leave out signal type for the =
reason above regarding adaptation information.
TS granularity is an information that server LSP has to expose to client LS=
P. What is related to the client is conveyed in the G-PID not in the Signal=
 Type .=20
There are no different Signal Type for the same ODU in OTN: e.g. ODU2 it is=
 the same , what can change is the adaptation attribute towards client (e.g=
. 1.25 or 2.5 TSG for ODU1 client).=20

As I understand it, TSG is needed at:
  (a) the endpoints that terminate the signal/LSP to ensure proper
      adaptation.
  (b) the 2nd and penultimate hops to ensure the proper
      interface/H-LSP selection.
  (c) Intermediate nodes for proper TS allocation.

[ALU] Item (c) is not correct. Intermediate nodes do not need to demultiple=
x client, you can have ODU0 LSPs , that surely need to have 1,25 interfaces=
 in the end points but using 2.5 TSG in the middle of the network since the=
y have tunneled on 2.5 structured containers.=20



It seems to me that we have enough existing fields in GMPLS (for G.709)
that we should consider these before introducing new ones.  Of the
existing fields, we have 1, 4 and 5.:

   Option 1, G-PID, is really designed to support end-point client
   adaptation, so as an end-point only field it really only supports
   need (a), so I don't think G-PID is the right place to indicate TSG.

[ALU] G-PID is the correct place :
 1) It contains information related to client of an LSP that is exactly wha=
t we need.
2) As reported in RFC 3471 " This is used by the nodes at the endpoints of =
the LSP, and in some cases by the penultimate hop." We are exactly in these=
 "some cases"

   Option 4, Encoding, is used to support (a) and (b)-type checks in
   GMPLS, but not (c).  So, while this field is definitely a better
   place than G-PID to indicate TSG, it doesn't satisfy all the needs.

   Option 5, Signal Type, is used to support all needs.

[ALU] Already commented why not the right places.

Given all this, I'd like to propose that we use Option 5, Signal Type,
to indicate TSG, and that this be reflected in the relevant WG drafts.
(Authors, let me know if you'd like specific text proposals.)

Comments?

Much thanks,
Lou (as WG contributor)

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

From lberger@labn.net  Wed Sep 28 08:34:15 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5331F0C6B for ; Wed, 28 Sep 2011 08:34:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.784
X-Spam-Level: 
X-Spam-Status: No, score=-100.784 tagged_above=-999 required=5 tests=[AWL=-0.623, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boKxlC-KBsaw for ; Wed, 28 Sep 2011 08:34:14 -0700 (PDT)
Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id 48C031F0C68 for ; Wed, 28 Sep 2011 08:34:14 -0700 (PDT)
Received: (qmail 30698 invoked by uid 0); 28 Sep 2011 15:37:01 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy7.bluehost.com with SMTP; 28 Sep 2011 15:37:01 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default;  h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=ILkZfnJdHurmadnOBwOIBwEqF5Pdj63TtCqejeRB0WU=;  b=CGcQeUY0f/yNiOw8NkNUKD2zj1upxRKtgPWrbS3iR+0cJuqbewU2P5QKbanoNFfyzBUmpcOvY+AzLjTwawu/O3Pizc4GUmRsNV9sfPajRtaqOnbUTeOaEOFjk4dWtIaq;
Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1R8wBx-0002X1-KO; Wed, 28 Sep 2011 09:37:01 -0600
Message-ID: <4E833F1B.4040004@labn.net>
Date: Wed, 28 Sep 2011 11:36:59 -0400
From: Lou Berger 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: "BELOTTI, SERGIO (SERGIO)" 
References: <4E81CD97.3020209@labn.net> 
In-Reply-To: 
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Cc: CCAMP 
Subject: Re: [CCAMP] R:  Thought on where to carry G.709-v3 TSG
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Sep 2011 15:34:15 -0000

Sergio and Pietro,

It sounds like we should get in-sync on where TSG information is needed
first then talk about how to carry it.  So, I said:

> As I understand it, TSG is needed at:
>   (a) the endpoints that terminate the signal/LSP to ensure proper
>       adaptation.
>   (b) the 2nd and penultimate hops to ensure the proper
>       interface/H-LSP selection.
>   (c) Intermediate nodes for proper TS allocation.
>

>From your mail, I infer that you agree on (a) and (b).  Is this correct?

WRT to (c) you said:
> [ALU] Item (c) is not correct. Intermediate nodes do not need to
demultiplex client, you can have ODU0 LSPs , that surely need to have
1,25 interfaces in the end points but using 2.5 TSG in the middle of the
network since they have tunneled on 2.5 structured containers.
>
>

I'm having a hard time parsing your statement.  Are you saying (i) you
client ODU0 carried over an ODUn (n>0) H-LSP or (ii) and ODU0 which is
carried over links OTUn links and 2.5G slots in the intermediate links,
or (iii) something completely different.

Either way, isn't the case that it would be optimal to use 1.25 TSs for
certain ODUs (e.g., OD0, ODUFlex) on transit links when both ends of the
link support 1.25?

You also said:
> [ALU] In the INFO we have explained the need also for TSG in routing
> (following conclusion of mailing list discussion) and the routing
> draft simply proposes a possible encoding of the information.
>
> This solution, for the sake of truth, can be getting better, taking
> into account the AutoPayloadtype flag information. This information
> is a typical MI information , described in in G.798, and it simply
> tells us whether Fallback procedure is enabled or not.
> 
> Since this information is typically configured by the manager we do
> not think it has to be considered directly in the control plane
> (neither signaled or advertised ). However we have to take into
> account the fact that auto-payload type set to off generates
> interfaces that can support 1.25 TSG only.
> 

Okay, now I'm really confused.  This seems to imply that you are saying
the (c) above is needed.  What am I missing?

Much thanks,
Lou


On 9/28/2011 8:02 AM, BELOTTI, SERGIO (SERGIO) wrote:
> Hi Lou,
> 
> Please see in line .
> 
> BR
> 
> Sergio and Pietro
> 
> 
> -----Messaggio originale-----
> Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Lou Berger
> Inviato: martedì 27 settembre 2011 15.20
> A: CCAMP
> Oggetto: [CCAMP] Thought on where to carry G.709-v3 TSG
> 
> All / G.709 draft authors,
> 
> 	We have a few slightly unaligned proposals on where to indicate the
> [G.709-v3] Tributary Slot Granularity:
> 
> 
> 
> 1: G-PID
>     draft-ietf-ccamp-otn-g709-info-model-01 says:
>     One possible solution is the G-PID field of the GENERALIZED LABEL
>     REQUEST Object.
> 
> [ALU]What inserted in the INFO draft , is the result of the discussion made in July on the subject, in the mailing , taking into account suggestion and comments coming from John, Jonathan and others participating at the discussion.
> Our opinion is that the ending draft for signaling should be aligned to the info model draft incorporating the required changes to GPID. The motivations behind our opinion can be better understood reading the other comments.
> 
> 2: A new field:
>    draft-ceccarelli-ccamp-gmpls-ospf-g709-07 says:
>       - TSG: Tributary Slot Granularity (2bit): Used for the
>       advertisement of the supported Tributary Slot granularity
> [ALU] In the INFO we have explained the need also for TSG in routing (following conclusion of mailing list discussion) and the routing draft simply proposes a possible encoding of the information.
> This solution, for the sake of truth, can be getting better, taking into account the AutoPayloadtype flag information. This information is a typical MI information , described in in G.798, and it simply tells us whether Fallback procedure is enabled or not. 
> Since this information is typically configured by the manager we do not think it has to be considered directly in the control plane (neither signaled or advertised ). However we have to take into account the fact that
> auto-payload type set to off generates interfaces that can support 1.25 TSG only. 
> 
> This fact can be incorporated in routing by adding a new meaning in the two bits encodings:
> 
>          - 00 - 1.25 Gbps (AutoPayloadtype off)
> 
>          - 01 - 1.25 Gbps (AutoPayloadType on)
> 
>          - 10 - 2.5 Gbps 
> 
>          - 11 - Reserved
> 
> 
> 3: Implicitly:
>    draft-zhang-ccamp-gmpls-evolving-g709-09 doesn't explicitly
>    signal TSG, but rather has it implied in the new ODU label.
> 
> [ALU] There is nothing implicitly. The reality is that at the moment signaling draft does not address the problem . What you consider as "implicitly deduced" is in fact the TSG granularity with which the client is mapped in the server ODUk/OTUK or FA/H-LSP. What has to be clarified is that what we need to signal is an adaptation information regarding what the server can expose to the client regarding TS granularity capability. 
> TS size is an attribute of the adaptation used to put an ODUj into an ODUk.
> What you consider as implicit is just how ODUj is mapped into ODUk, but the problem is to signal ODUk with the correct adaptation attribute.
> 
> Some other alternatives include:
> 
> 4: GMPLS Encoding
>    Currently used to indicate G.709 (which is also what the Switch
>    cap essentially indicates) An alternative would use:
>       12              G.709 ODUk (Digital Path, 2.5G)[RFC4328]
>       TBA (e.g., 15)  G.709 ODUk (Digital Path, 1.25G)
> 
>    In routing, 15 would imply support for both 1.25 and 2.5G, as
>    support for both by 1.25 capable interfaces is required by
>    [G.709-v3]. (At least as I understand it.)
> 
> [ALU] Encoding field should define the nature of the LSP : RFC 4328 defined two OTN new values G.709 ODUk (Digital Path) and G.709 Optical Channel. We do not see any reason to link encoding with information that would need to choose interfaces (as TSG) since the "nature " of LSP does not change dependently of the usage of 1.25 or 2.5 ODUk tributary slot.
> 
> 5: Signal Type
>    Carried in routing ISCD/SCSI and signaling traffic parameters.
>    Could enumerate all ODUx types to indicate either 1.25G or 2.5G.
>    Existing types indicate 2.5G, new types would need to be enumerated
>    for the new 1.25 and 2.5 types.  Hereto, the 1.25 types would imply
>    support for both 1.25 and 2.5 types in routing.
> 
> [ALU] During the discussion in July the usage of Signal Type was one of the first possibilities analyzed. We definitely leave out signal type for the reason above regarding adaptation information.
> TS granularity is an information that server LSP has to expose to client LSP. What is related to the client is conveyed in the G-PID not in the Signal Type . 
> There are no different Signal Type for the same ODU in OTN: e.g. ODU2 it is the same , what can change is the adaptation attribute towards client (e.g. 1.25 or 2.5 TSG for ODU1 client). 
> 
> As I understand it, TSG is needed at:
>   (a) the endpoints that terminate the signal/LSP to ensure proper
>       adaptation.
>   (b) the 2nd and penultimate hops to ensure the proper
>       interface/H-LSP selection.
>   (c) Intermediate nodes for proper TS allocation.
> 
> [ALU] Item (c) is not correct. Intermediate nodes do not need to demultiplex client, you can have ODU0 LSPs , that surely need to have 1,25 interfaces in the end points but using 2.5 TSG in the middle of the network since they have tunneled on 2.5 structured containers. 
> 
> 
> 
> It seems to me that we have enough existing fields in GMPLS (for G.709)
> that we should consider these before introducing new ones.  Of the
> existing fields, we have 1, 4 and 5.:
> 
>    Option 1, G-PID, is really designed to support end-point client
>    adaptation, so as an end-point only field it really only supports
>    need (a), so I don't think G-PID is the right place to indicate TSG.
> 
> [ALU] G-PID is the correct place :
>  1) It contains information related to client of an LSP that is exactly what we need.
> 2) As reported in RFC 3471 " This is used by the nodes at the endpoints of the LSP, and in some cases by the penultimate hop." We are exactly in these "some cases"
> 
>    Option 4, Encoding, is used to support (a) and (b)-type checks in
>    GMPLS, but not (c).  So, while this field is definitely a better
>    place than G-PID to indicate TSG, it doesn't satisfy all the needs.
> 
>    Option 5, Signal Type, is used to support all needs.
> 
> [ALU] Already commented why not the right places.
> 
> Given all this, I'd like to propose that we use Option 5, Signal Type,
> to indicate TSG, and that this be reflected in the relevant WG drafts.
> (Authors, let me know if you'd like specific text proposals.)
> 
> Comments?
> 
> Much thanks,
> Lou (as WG contributor)
> 
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
> 
> 
> 
> 

From bertietf@bwijnen.net  Wed Sep 28 08:29:55 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 243381F0C60; Wed, 28 Sep 2011 08:29:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.588
X-Spam-Level: 
X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CqVXcpwf7Yc3; Wed, 28 Sep 2011 08:29:54 -0700 (PDT)
Received: from postgirl.ripe.net (postgirl.ipv6.ripe.net [IPv6:2001:67c:2e8:11::c100:1342]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFE31F0C5F; Wed, 28 Sep 2011 08:29:52 -0700 (PDT)
Received: from dodo.ripe.net ([193.0.23.4]) by postgirl.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1R8w7g-000301-3X; Wed, 28 Sep 2011 17:32:37 +0200
Received: from dog.ripe.net ([193.0.1.217] helo=BWMACBOOK.local) by dodo.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1R8w7f-0002WQ-GF; Wed, 28 Sep 2011 17:32:35 +0200
Message-ID: <4E833E13.20008@bwijnen.net>
Date: Wed, 28 Sep 2011 17:32:35 +0200
From: "Bert Wijnen (IETF)" 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: ccamp@ietf.org
References: 
In-Reply-To: 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-RIPE-Spam-Level: --
X-RIPE-Spam-Report: Spam Total Points:   -2.9 points pts rule name              description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00               BODY: Bayes spam probability is 0 to 1% [score: 0.0000]
X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4e2fb21bdc6bd2704877ebab75cd58d76
X-Mailman-Approved-At: Wed, 28 Sep 2011 08:34:41 -0700
Cc: "Romascanu, Dan \(Dan\)" , ops-dir@ietf.org, ccamp-chairs@tools.ietf.org, Ron Bonica 
Subject: [CCAMP] Operations Directorate Review of draft-ietf-ccamp-wson-impairments-07
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Sep 2011 15:29:55 -0000

[I am not on ccamp list, so this posting may have
to be approved explicitly]

I did an OPS-DIR review for document

    draft-ietf-ccamp-wson-impairments-07

As the document writeup states:

   This document is an informational framework with nothing to implement.
   There are a number of drafts being progressed that address various
   aspects of the framework.

So it would be those documents being progressed that would have
to include any discussion about operational or manageability aspects
of the various solutions.

At the other hand, it might have been useful if this document
would have touched upon some operational/manageability aspects
for each of the possible solutions. It seems clear that there
are different characteristics depending on which solution is
chosen. Specifically the talk about "black links" makes me
worried that solutions can become complex and less
interoperable.

So I think it is probably best top let this Informational doc
pass and be published. But please make sure that the follow up
documents DO discuss operational and management aspects of the
chosen solution.

Bert Wijnen
p.s. I am not on the ccamp list so if you want me to see any
answers, pls copy me explicitly.

On 9/28/11 2:14 AM, Tina TSOU wrote:
> Hello,
> As a member of the Operations Directorate you are being asked to review the following draft which is in IETF last call for it's operational impact.
>
> IETF Last Call:
> The file can be obtained via
> http://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-impairments/
>
> IESG discussion can be tracked via
> http://datatracker.ietf.org/doc/draft-ietf-ccamp-wson-impairments/
>
> Please provide comments and review to the Ops-dir mailing list
> (ops-dir@ietf.org) before 2011-10-11, and include the authors of the
> draft as well.
>
> A Check-list of possible questions/topics to address in an OPS-DIR
> review may be found in Appendix A of RFC 5706.
> Only include the questions that apply to your review.
>
> Would you add the review requests and update the status yourself at our wiki page?
> http://trac.tools.ietf.org/area/ops/trac/wiki/Directorates
>
>
> Thank you,
> Tina
> http://tinatsou.weebly.com
>
>

From lberger@labn.net  Wed Sep 28 09:29:27 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9214911E80D9 for ; Wed, 28 Sep 2011 09:29:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.775
X-Spam-Level: 
X-Spam-Status: No, score=-100.775 tagged_above=-999 required=5 tests=[AWL=-0.614, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, IP_NOT_FRIENDLY=0.334, RDNS_NONE=0.1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DXp6pn7hIagE for ; Wed, 28 Sep 2011 09:29:27 -0700 (PDT)
Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by ietfa.amsl.com (Postfix) with SMTP id E4EFD11E80D4 for ; Wed, 28 Sep 2011 09:29:26 -0700 (PDT)
Received: (qmail 18419 invoked by uid 0); 28 Sep 2011 16:32:14 -0000
Received: from unknown (HELO box313.bluehost.com) (69.89.31.113) by oproxy1.bluehost.com with SMTP; 28 Sep 2011 16:32:14 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default;  h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=hAbJ5SCfr0cNtAeOsaF3mPLmZ4DzY3/zX9VIbo4bY0w=;  b=GgD4sxRHUGgR5MmcfOw5tBH6YYOVXY4exZYnrwgYtyFJ1gV2liI1KPbMbxR3o/6Ayn1Zhqibz5gJW0nr0bjLir01ASluOMH1CmmOv5CZeYEXO1hcZm1HVUC5nXB2z28u;
Received: from box313.bluehost.com ([69.89.31.113] helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.76) (envelope-from ) id 1R8x3O-0001qv-Ni for ccamp@ietf.org; Wed, 28 Sep 2011 10:32:14 -0600
Message-ID: <4E834C0D.5030800@labn.net>
Date: Wed, 28 Sep 2011 12:32:13 -0400
From: Lou Berger 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: CCAMP 
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net}
Subject: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG documents
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Sep 2011 16:29:27 -0000

This message starts a two week poll on making the documents listed below
ccamp working group documents.  Please send a mail to the mailing list
indicating "yes/support to both" or "no/do not support either".  Of
course, you may also support one but not the other.  (We will assume
that you support/object to both if you don't specify.)

If indicating no, please state your technical reservations with the
document.

The documents being polled are:
http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-ospf-g709-07
http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-evolving-g709-09

The poll ends Wednesday October 12.

Please also bear in mind that WG adoption does not signify that work is
complete on the documents or that the technical details are fixed, but
rather that further development of the documents will take place based
on WG process.

Much thanks,
Lou (and Deborah)

From jdrake@juniper.net  Wed Sep 28 10:26:06 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A978011E80FA for ; Wed, 28 Sep 2011 10:26:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.173
X-Spam-Level: 
X-Spam-Status: No, score=-6.173 tagged_above=-999 required=5 tests=[AWL=0.426,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vLiekP7BWYnc for ; Wed, 28 Sep 2011 10:26:06 -0700 (PDT)
Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by ietfa.amsl.com (Postfix) with ESMTP id B865011E8091 for ; Wed, 28 Sep 2011 10:26:05 -0700 (PDT)
Received: from P-EMHUB02-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKToNZVU1QqRgFTSg+8VRFQi50wMhVavSR@postini.com; Wed, 28 Sep 2011 10:28:54 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::99ad:1ca:2a64:e987]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 28 Sep 2011 10:26:48 -0700
From: John E Drake 
To: Lou Berger , CCAMP 
Date: Wed, 28 Sep 2011 10:26:46 -0700
Thread-Topic: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG documents
Thread-Index: Acx9/DKt8NsjT6suSLmH9jX/rnSepwAB5Pzg
Message-ID: <5E893DB832F57341992548CDBB333163A43FFBFEEB@EMBX01-HQ.jnpr.net>
References: <4E834C0D.5030800@labn.net>
In-Reply-To: <4E834C0D.5030800@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
Subject: Re: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG	documents
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Sep 2011 17:26:06 -0000

Yes to both

> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of Lou Berger
> Sent: Wednesday, September 28, 2011 12:32 PM
> To: CCAMP
> Subject: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG
> documents
>=20
> This message starts a two week poll on making the documents listed
> below
> ccamp working group documents.  Please send a mail to the mailing list
> indicating "yes/support to both" or "no/do not support either".  Of
> course, you may also support one but not the other.  (We will assume
> that you support/object to both if you don't specify.)
>=20
> If indicating no, please state your technical reservations with the
> document.
>=20
> The documents being polled are:
> http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-ospf-g709-07
> http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-evolving-g709-09
>=20
> The poll ends Wednesday October 12.
>=20
> Please also bear in mind that WG adoption does not signify that work is
> complete on the documents or that the technical details are fixed, but
> rather that further development of the documents will take place based
> on WG process.
>=20
> Much thanks,
> Lou (and Deborah)
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp

From prvs=325227afd3=lyong@ciena.com  Wed Sep 28 10:28:45 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09DD21F8D7B for ; Wed, 28 Sep 2011 10:28:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.39
X-Spam-Level: 
X-Spam-Status: No, score=-103.39 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0nc55s1IbycD for ; Wed, 28 Sep 2011 10:28:45 -0700 (PDT)
Received: from mx0b-00103a01.pphosted.com (mx0b-00103a01.pphosted.com [67.231.152.227]) by ietfa.amsl.com (Postfix) with ESMTP id 65EA821F8CCB for ; Wed, 28 Sep 2011 10:28:45 -0700 (PDT)
Received: from pps.filterd (m0001124 [127.0.0.1]) by mx0b-00103a01.pphosted.com (8.14.3/8.14.3) with SMTP id p8SHUGsw029431; Wed, 28 Sep 2011 13:31:33 -0400
Received: from mdwexght01.ciena.com (LIN1-118-36-28.ciena.com [63.118.36.28]) by mx0b-00103a01.pphosted.com with ESMTP id 1047ucg1rp-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 28 Sep 2011 13:31:28 -0400
Received: from MDWEXGMB02.ciena.com ([::1]) by MDWEXGHT01.ciena.com ([::1]) with mapi; Wed, 28 Sep 2011 13:31:29 -0400
From: "Ong, Lyndon" 
To: Lou Berger , CCAMP 
Content-Class: urn:content-classes:message
Date: Wed, 28 Sep 2011 13:31:29 -0400
Thread-Topic: [CCAMP] Poll on making G.709 Routing and Signaling drafts WGdocuments
Thread-Index: Acx9/DOeJL3al7rQRUSyCaDKssN+MQACATMw
Message-ID: 
References: <4E834C0D.5030800@labn.net>
In-Reply-To: <4E834C0D.5030800@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
x-tm-as-product-ver: SMEX-10.0.0.1412-6.800.1017-18414.000
x-tm-as-result: No--39.560200-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.4.6813, 1.0.211, 0.0.0000 definitions=2011-09-28_05:2011-09-28, 2011-09-27, 1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 ipscore=0 suspectscore=2 phishscore=0 bulkscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx engine=6.0.2-1012030000 definitions=main-1109280195
Subject: Re: [CCAMP] Poll on making G.709 Routing and Signaling drafts WGdocuments
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Sep 2011 17:28:46 -0000

Support both (contributor to both, though).

Lyndon



-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L=
ou Berger
Sent: Wednesday, September 28, 2011 9:32 AM
To: CCAMP
Subject: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG docum=
ents

This message starts a two week poll on making the documents listed below
ccamp working group documents.  Please send a mail to the mailing list
indicating "yes/support to both" or "no/do not support either".  Of
course, you may also support one but not the other.  (We will assume
that you support/object to both if you don't specify.)

If indicating no, please state your technical reservations with the
document.

The documents being polled are:
http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-ospf-g709-07
http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-evolving-g709-09

The poll ends Wednesday October 12.

Please also bear in mind that WG adoption does not signify that work is
complete on the documents or that the technical details are fixed, but
rather that further development of the documents will take place based
on WG process.

Much thanks,
Lou (and Deborah)
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp



From leeyoung@huawei.com  Wed Sep 28 14:44:29 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA70D1F0C8C for ; Wed, 28 Sep 2011 14:44:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.558
X-Spam-Level: 
X-Spam-Status: No, score=-6.558 tagged_above=-999 required=5 tests=[AWL=0.041,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y-29ac1y286E for ; Wed, 28 Sep 2011 14:44:28 -0700 (PDT)
Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 8C87C1F0C81 for ; Wed, 28 Sep 2011 14:44:28 -0700 (PDT)
Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS9000FU5URNI@usaga02-in.huawei.com> for ccamp@ietf.org; Wed, 28 Sep 2011 16:47:16 -0500 (CDT)
Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug  8 2006)) with ESMTPS id <0LS900JG35U2GB@usaga02-in.huawei.com> for ccamp@ietf.org; Wed, 28 Sep 2011 16:47:15 -0500 (CDT)
Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Wed, 28 Sep 2011 14:47:14 -0700
Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0270.001; Wed, 28 Sep 2011 14:47:04 -0700
Date: Wed, 28 Sep 2011 21:47:02 +0000
From: Leeyoung 
In-reply-to: 
X-Originating-IP: [10.47.132.107]
To: "Margaria, Cyril (NSN - DE/Munich)" , "ccamp@ietf.org" 
Message-id: <7AEB3D6833318045B4AE71C2C87E8E171817E09A@DFWEML501-MBX.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: en-US
Content-transfer-encoding: 7BIT
Accept-Language: en-US, zh-CN
Thread-topic: [CCAMP] FW:  I-D Action: draft-ietf-ccamp-rwa-info-12.txt
Thread-index: AQHMfGU421ASISnyGEauN0YmoQNTfpVjNyIg
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: <7AEB3D6833318045B4AE71C2C87E8E17181669D3@DFWEML501-MBX.china.huawei.com> 
Subject: Re: [CCAMP] FW:  I-D Action: draft-ietf-ccamp-rwa-info-12.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Sep 2011 21:44:29 -0000

Hi Cyril,

Thanks for your review and suggestions. It looks like there are two issues pending: Point #2 and #3. 
We can close the rest of the points you raised with the action specified in-line. Please let me know otherwise. 

Thanks.

Young


-----Original Message-----
From: Margaria, Cyril (NSN - DE/Munich) [mailto:cyril.margaria@nsn.com] 
Sent: Monday, September 26, 2011 10:59 AM
To: Leeyoung; ccamp@ietf.org
Subject: RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-info-12.txt


Hi, 
I have the following comments on  draft-ietf-ccamp-rwa-wson-encode-12
after it being updated and in light of the WG discussions:

1) section 3.1. Resource Block Set Field:
   The information model indicates that the resource block set is
optional for the  "Resource Block Information", hence the text should be
modified as follow:
"0 - Inclusive List

     Indicates that the TLV contains zero or more RB elements that are
     included in the list."

YOUNG>> Will do in the next revision. (Closure) 

2) section 3.1. Resource Block Set Field:
RB Identifier: as stated in section "3. Resources, Blocks, Sets, and the
Resource Pool", Resources and Resource Blocks are related to interface
cards.

GMPLS implementations are using 32-bit unnumbered interface IDs to
identify GMPLS links and also the corresponding physical resources.
OEO devices and, in the context of this document, resource or resource
group can also be identified by 32-bit unnumbered interface IDs.

 From an implementation point of view, having 16-bit resource block IDs
have several drawbacks because of the following points:
  a) Mapping exists between physical resource and unnumbered interface
IDs, this mapping is generally known by management system,
      introducing a different ID space is not optimal (new mapping
needed);
  b) Those OEOs might be used as links in a multi-node model, thus being
identified by a 32-bit unnumbered interface IDs, introducing another
space is also not optimal.

Therefore, it would be better if the resource block IDs were 32-bit
interface IDs (to be unique within the node, not because they are
representing links in this document).

YOUNG>> The only motivation why we used 16 bits for RB ID is to reduce the space. And I think this is an internal link so it is not the real interface per se and thus there is no need to keep track of the state of RB ID like other legitimate interfaces. I don't think there is a substantial implementation issue here whether we use 16 bits or 32 bits, but if there is a strong support to use 32 bit ID over 16 bit ID, I am fine with this. Lou and Deborah, do you have any suggestion on this issue? Or other implementers? 


3) section 3.1. Resource Block Set Field Why not define a bit set 
action, similar to the label set?

YOUNG>> Are you referring the Label Set encoding as follows from draft-ietf-ccamp-general-constraint-encode-05.txt

  0                   1                   2                   3 
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     | Action|    Num Labels         |          Length               | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |                          Base Label                           | 
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
     |     Additional fields as necessary per action                 |


The current Resource Block Set Field is encoded as follows:

  0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |    Action     |E|C| Reserved  |        Length                 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |     RB Identifier 1           |        RB Identifier 2        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      :                               :                               : 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |     RB Identifier n-1         |        RB Identifier n        | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

YOUNG>> Can you be specific about your suggestion? Are you concerned about label being 32 bit vs RB identifier being 16 bits? --- then this is basically related to your point #2. If you have other concerns, please spell them out (e.g., action field (4 bits vs 8 bits), etc..) The Num Labels field is necessary when we are indicating bit maps (Action = 4), which Is not needed for Resource Block Set; E bit is not necessary when we adopt 32 bit RB ID, but C bit is needed to indicate the connectivity nature of Resource Pool Accessibility. 

YOUNG>> Would the following encoding is what you are envisioning? If not, please suggest in detail. 

  0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      | Action|C|                     |        Length                 | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                         RB Identifier 1                       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      :                               :                               : 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                         RB Identifier n                       | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




4) section 4.3. Resource Pool State Sub-TLV

The RB state refers to the number of available resources within the 
resource block, the first sentence mentions the resource pool only.
In addition, a bit map can be used even in case the resource block
contains several resources.
The following text tries to reflect this, please consider it.

    "The state of the pool is given by the number of resources available
    with particular characteristics. A resource block set is used to
    encode all or a subset of the resources of interest. The usage state
    of resources within a resource block set is encoded as either a list
    of 16-bit integer values, indicating the number of available
resources
    in the resource block, or a map of bits, indicating whether a
particular
    resource is available or not."

YOUNG>> Thanks. This is fine. Will add as you suggested in the revision (Closure)


5) section 4.3. Resource Pool State Sub-TLV
   Typo: "RB Usage state:  Variable Length but must be a multiple of 4 
bytes." (byes->bytes)

YOUNG>>  Thanks. Will do s/byes/bytes in Section 4.3 (Closure)

6) section 5.1. Resource Block Information Sub-TLV

Having an Input Modulation Type List sub-sub-TLV containing a list of 
modulation formats (with an input-output bit) and an Output Modulation 
Type List sub-sub-TLV containing a list of modulation formats (with an
input-output bit) seems redundant because the bit I already indicates if
it is an output or input modulation format.

Having a single Modulation Type List sub-sub-TLV is providing the same
information with an efficient encoding, a single sub-sub-TLV type should
be used.

Same reasoning apply to the FEC Type List Sub-Sub-TLV.

YOUNG>> I guess what you are suggesting is as follows: 

    0                   1                   2                   3 
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |                     RB Set Field                              | 
      :                                                               : 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |I|E|                      Reserved                             | 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |           Modulation Type List Sub-Sub-TLV  (opt)             | 
      :                                                               : 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |           FEC Type List Sub-Sub-TLV    (opt)                  | 
      :                                                               : 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Input Client Signal Type Sub-Sub-TLV      (opt)       | 
      :                                                               : 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Input Bit Rate Range List  Sub-Sub-TLV (opt)          | 
      :                                                               : 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
      |         Processing Capabilities List Sub-Sub-TLV (opt)        | 
      :                                                               : 
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


YOUNG>> If that's what you suggested, that is fine with me. If that is that case, I will revise with this figure in the revision. (Closure) 


7) section 5.1. Resource Block Information Sub-TLV
  Add the following text: "The order of sub-sub-TLVs does not matter,
the sub-sub-TLVs MAY be in any order."

YOUNG>> Thanks. This will be added in the revision (Closure)


Best Regards, 
Cyril Margaria


> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of ext Leeyoung
> Sent: Friday, September 09, 2011 11:30 PM
> To: ccamp@ietf.org
> Subject: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-info-12.txt
> 
> Hi,
> 
> This update (version 12) includes the following:
> 
> (i) Replaced all instances of "ingress" with "input" and all instances
> of "egress" with "output".
> (ii) Added clarifying text on relationship between resource block
model
> and physical entities such as line cards.
> 
> This draft is now very mature and incorporated all the comments raised
> in the mailing list and the last meetings.
> 
> Thanks,
> Young
> 
> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of internet-drafts@ietf.org
> Sent: Friday, September 09, 2011 4:20 PM
> To: i-d-announce@ietf.org
> Cc: ccamp@ietf.org
> Subject: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-info-12.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Common Control and
> Measurement Plane Working Group of the IETF.
> 
> 	Title           : Routing and Wavelength Assignment Information
> Model for Wavelength Switched Optical Networks
> 	Author(s)       : Young Lee
>                           Greg M. Bernstein
>                           Dan Li
>                           Wataru Imajuku
> 	Filename        : draft-ietf-ccamp-rwa-info-12.txt
> 	Pages           : 27
> 	Date            : 2011-09-09
> 
>    This document provides a model of information needed by the routing
>    and wavelength assignment (RWA) process in wavelength switched
>    optical networks (WSONs).  The purpose of the information described
>    in this model is to facilitate constrained lightpath computation in
>    WSONs. This model takes into account compatibility constraints
>    between WSON signal attributes and network elements but does not
>    include constraints due to optical impairments. Aspects of this
>    information that may be of use to other technologies utilizing a
>    GMPLS control plane are discussed.
> 
> 
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-12.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-12.txt
> _______________________________________________
> 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 rrao@infinera.com  Wed Sep 28 17:15:39 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4F6C21F8E3E for ; Wed, 28 Sep 2011 17:15:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJ0JiGHnrRIW for ; Wed, 28 Sep 2011 17:15:39 -0700 (PDT)
Received: from sv-casht-prod2.infinera.com (sv-casht-prod2.infinera.com [8.4.225.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4822821F8E3D for ; Wed, 28 Sep 2011 17:15:38 -0700 (PDT)
Received: from SV-EXDB-PROD1.infinera.com ([fe80::dc68:4e20:6002:a8f9]) by sv-casht-prod2.infinera.com ([::1]) with mapi id 14.01.0323.003; Wed, 28 Sep 2011 17:18:26 -0700
From: Rajan Rao 
To: Lou Berger , CCAMP 
Thread-Topic: [CCAMP] Poll on making G.709 Routing and Signaling drafts WGdocuments
Thread-Index: Acx9/DOeJL3al7rQRUSyCaDKssN+MQACATMwAAgh3vA=
Date: Thu, 29 Sep 2011 00:18:26 +0000
Message-ID: <650AA355E323C34D9D4AAEED952E053D0AB8EA6C@SV-EXDB-PROD1.infinera.com>
References: <4E834C0D.5030800@labn.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.100.96.93]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [CCAMP] Poll on making G.709 Routing and Signaling drafts WGdocuments
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Sep 2011 00:15:39 -0000

Yes to both drafts.

Thanks
Rajan
(co-author)

-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L=
ou Berger
Sent: Wednesday, September 28, 2011 9:32 AM
To: CCAMP
Subject: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG docum=
ents

This message starts a two week poll on making the documents listed below
ccamp working group documents.  Please send a mail to the mailing list
indicating "yes/support to both" or "no/do not support either".  Of
course, you may also support one but not the other.  (We will assume
that you support/object to both if you don't specify.)

If indicating no, please state your technical reservations with the
document.

The documents being polled are:
http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-ospf-g709-07
http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-evolving-g709-09

The poll ends Wednesday October 12.

Please also bear in mind that WG adoption does not signify that work is
complete on the documents or that the technical details are fixed, but
rather that further development of the documents will take place based
on WG process.

Much thanks,
Lou (and Deborah)
_______________________________________________
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 fu.xihua@zte.com.cn  Wed Sep 28 17:34:10 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A6B11E816C; Wed, 28 Sep 2011 17:34:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.702
X-Spam-Level: 
X-Spam-Status: No, score=-97.702 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_00=-2.599, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oa9cHRDuX6Zb; Wed, 28 Sep 2011 17:34:10 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 22C8811E816A; Wed, 28 Sep 2011 17:34:05 -0700 (PDT)
Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 417131461793122; Thu, 29 Sep 2011 08:35:23 +0800 (CST)
Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 75544.1973556129; Thu, 29 Sep 2011 08:36:48 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id p8T0ailu030994; Thu, 29 Sep 2011 08:36:44 +0800 (GMT-8) (envelope-from fu.xihua@zte.com.cn)
In-Reply-To: <4E834C0D.5030800@labn.net>
To: Lou Berger 
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: 
From: fu.xihua@zte.com.cn
Date: Thu, 29 Sep 2011 08:36:42 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-09-29 08:36:44, Serialize complete at 2011-09-29 08:36:44
Content-Type: multipart/alternative; boundary="=_alternative 00035E754825791A_="
X-MAIL: mse01.zte.com.cn p8T0ailu030994
Cc: CCAMP , ccamp-bounces@ietf.org
Subject: Re: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG documents
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Sep 2011 00:34:10 -0000

This is a multipart message in MIME format.
--=_alternative 00035E754825791A_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

WWVzL1N1cHBvcnQgYm90aCBkcmFmdHMuDQoNCg0KQmVzdCBSZWdhcmRzLA0KDQpYaWh1YSBGdQ0K
DQpaVEUgQ29ycG9yYXRpb24NCk1vYmlsZTogKzg2LTE1ODAyOTIxMjIzDQpQaG9uZTogKzg2LTAy
OS04ODQ1ODA1OA0KRS1tYWlsOmZ1LnhpaHVhQHp0ZS5jb20uY24NCg0KDQoNCkxvdSBCZXJnZXIg
PGxiZXJnZXJAbGFibi5uZXQ+IA0Kt6K8/sjLOiAgY2NhbXAtYm91bmNlc0BpZXRmLm9yZw0KMjAx
MS0wOS0yOSAwMDozMg0KDQrK1bz+yMsNCkNDQU1QIDxjY2FtcEBpZXRmLm9yZz4NCrOty80NCg0K
1vfM4g0KW0NDQU1QXSBQb2xsIG9uIG1ha2luZyBHLjcwOSBSb3V0aW5nIGFuZCBTaWduYWxpbmcg
ZHJhZnRzIFdHICAgIGRvY3VtZW50cw0KDQoNCg0KDQoNCg0KVGhpcyBtZXNzYWdlIHN0YXJ0cyBh
IHR3byB3ZWVrIHBvbGwgb24gbWFraW5nIHRoZSBkb2N1bWVudHMgbGlzdGVkIGJlbG93DQpjY2Ft
cCB3b3JraW5nIGdyb3VwIGRvY3VtZW50cy4gIFBsZWFzZSBzZW5kIGEgbWFpbCB0byB0aGUgbWFp
bGluZyBsaXN0DQppbmRpY2F0aW5nICJ5ZXMvc3VwcG9ydCB0byBib3RoIiBvciAibm8vZG8gbm90
IHN1cHBvcnQgZWl0aGVyIi4gIE9mDQpjb3Vyc2UsIHlvdSBtYXkgYWxzbyBzdXBwb3J0IG9uZSBi
dXQgbm90IHRoZSBvdGhlci4gIChXZSB3aWxsIGFzc3VtZQ0KdGhhdCB5b3Ugc3VwcG9ydC9vYmpl
Y3QgdG8gYm90aCBpZiB5b3UgZG9uJ3Qgc3BlY2lmeS4pDQoNCklmIGluZGljYXRpbmcgbm8sIHBs
ZWFzZSBzdGF0ZSB5b3VyIHRlY2huaWNhbCByZXNlcnZhdGlvbnMgd2l0aCB0aGUNCmRvY3VtZW50
Lg0KDQpUaGUgZG9jdW1lbnRzIGJlaW5nIHBvbGxlZCBhcmU6DQpodHRwOi8vdG9vbHMuaWV0Zi5v
cmcvaHRtbC9kcmFmdC1jZWNjYXJlbGxpLWNjYW1wLWdtcGxzLW9zcGYtZzcwOS0wNw0KaHR0cDov
L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctY2NhbXAtZ21wbHMtZXZvbHZpbmctZzcw
OS0wOQ0KDQpUaGUgcG9sbCBlbmRzIFdlZG5lc2RheSBPY3RvYmVyIDEyLg0KDQpQbGVhc2UgYWxz
byBiZWFyIGluIG1pbmQgdGhhdCBXRyBhZG9wdGlvbiBkb2VzIG5vdCBzaWduaWZ5IHRoYXQgd29y
ayBpcw0KY29tcGxldGUgb24gdGhlIGRvY3VtZW50cyBvciB0aGF0IHRoZSB0ZWNobmljYWwgZGV0
YWlscyBhcmUgZml4ZWQsIGJ1dA0KcmF0aGVyIHRoYXQgZnVydGhlciBkZXZlbG9wbWVudCBvZiB0
aGUgZG9jdW1lbnRzIHdpbGwgdGFrZSBwbGFjZSBiYXNlZA0Kb24gV0cgcHJvY2Vzcy4NCg0KTXVj
aCB0aGFua3MsDQpMb3UgKGFuZCBEZWJvcmFoKQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX18NCkNDQU1QIG1haWxpbmcgbGlzdA0KQ0NBTVBAaWV0Zi5vcmcN
Cmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCg0KDQoNCg==
--=_alternative 00035E754825791A_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlllcy9TdXBwb3J0IGJvdGggZHJh
ZnRzLjxicj4NCjxicj4NCjxicj4NCkJlc3QgUmVnYXJkcyw8YnI+DQo8YnI+DQpYaWh1YSBGdTxi
cj4NCjxicj4NClpURSBDb3Jwb3JhdGlvbjxicj4NCk1vYmlsZTogKzg2LTE1ODAyOTIxMjIzPGJy
Pg0KUGhvbmU6ICs4Ni0wMjktODg0NTgwNTg8YnI+DQpFLW1haWw6ZnUueGlodWFAenRlLmNvbS5j
bjwvZm9udD4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGln
bj10b3A+DQo8dGQgd2lkdGg9MzUlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5M
b3UgQmVyZ2VyICZsdDtsYmVyZ2VyQGxhYm4ubmV0Jmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9u
dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtjY2FtcC1ib3VuY2VzQGll
dGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMTEtMDkt
MjkgMDA6MzI8L2ZvbnQ+DQo8dGQgd2lkdGg9NjQlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIg
dmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh
bnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu
cy1zZXJpZiI+Q0NBTVAgJmx0O2NjYW1wQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249
dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp
ZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBh
bGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rp
dj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+W0NDQU1QXSBQb2xsIG9uIG1h
a2luZyBHLjcwOSBSb3V0aW5nDQphbmQgU2lnbmFsaW5nIGRyYWZ0cyBXRyAmbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDtkb2N1bWVudHM8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0
ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxi
cj4NCjxicj48Zm9udCBzaXplPTI+PHR0PlRoaXMgbWVzc2FnZSBzdGFydHMgYSB0d28gd2VlayBw
b2xsIG9uIG1ha2luZyB0aGUNCmRvY3VtZW50cyBsaXN0ZWQgYmVsb3c8YnI+DQpjY2FtcCB3b3Jr
aW5nIGdyb3VwIGRvY3VtZW50cy4gJm5ic3A7UGxlYXNlIHNlbmQgYSBtYWlsIHRvIHRoZSBtYWls
aW5nDQpsaXN0PGJyPg0KaW5kaWNhdGluZyAmcXVvdDt5ZXMvc3VwcG9ydCB0byBib3RoJnF1b3Q7
IG9yICZxdW90O25vL2RvIG5vdCBzdXBwb3J0IGVpdGhlciZxdW90Oy4NCiZuYnNwO09mPGJyPg0K
Y291cnNlLCB5b3UgbWF5IGFsc28gc3VwcG9ydCBvbmUgYnV0IG5vdCB0aGUgb3RoZXIuICZuYnNw
OyhXZSB3aWxsIGFzc3VtZTxicj4NCnRoYXQgeW91IHN1cHBvcnQvb2JqZWN0IHRvIGJvdGggaWYg
eW91IGRvbid0IHNwZWNpZnkuKTxicj4NCjxicj4NCklmIGluZGljYXRpbmcgbm8sIHBsZWFzZSBz
dGF0ZSB5b3VyIHRlY2huaWNhbCByZXNlcnZhdGlvbnMgd2l0aCB0aGU8YnI+DQpkb2N1bWVudC48
YnI+DQo8YnI+DQpUaGUgZG9jdW1lbnRzIGJlaW5nIHBvbGxlZCBhcmU6PGJyPg0KaHR0cDovL3Rv
b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2VjY2FyZWxsaS1jY2FtcC1nbXBscy1vc3BmLWc3MDkt
MDc8YnI+DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFuZy1jY2FtcC1nbXBs
cy1ldm9sdmluZy1nNzA5LTA5PGJyPg0KPGJyPg0KVGhlIHBvbGwgZW5kcyBXZWRuZXNkYXkgT2N0
b2JlciAxMi48YnI+DQo8YnI+DQpQbGVhc2UgYWxzbyBiZWFyIGluIG1pbmQgdGhhdCBXRyBhZG9w
dGlvbiBkb2VzIG5vdCBzaWduaWZ5IHRoYXQgd29yayBpczxicj4NCmNvbXBsZXRlIG9uIHRoZSBk
b2N1bWVudHMgb3IgdGhhdCB0aGUgdGVjaG5pY2FsIGRldGFpbHMgYXJlIGZpeGVkLCBidXQ8YnI+
DQpyYXRoZXIgdGhhdCBmdXJ0aGVyIGRldmVsb3BtZW50IG9mIHRoZSBkb2N1bWVudHMgd2lsbCB0
YWtlIHBsYWNlIGJhc2VkPGJyPg0Kb24gV0cgcHJvY2Vzcy48YnI+DQo8YnI+DQpNdWNoIHRoYW5r
cyw8YnI+DQpMb3UgKGFuZCBEZWJvcmFoKTxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fPGJyPg0KQ0NBTVAgbWFpbGluZyBsaXN0PGJyPg0KQ0NBTVBA
aWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1w
PGJyPg0KPGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+DQo=
--=_alternative 00035E754825791A_=--


From zhangfatai@huawei.com  Wed Sep 28 19:01:07 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD691F0C6C for ; Wed, 28 Sep 2011 19:01:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.661
X-Spam-Level: 
X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[AWL=-2.357, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4,  SARE_SUB_ENC_GB2312=1.345]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMAGMp02fCZj for ; Wed, 28 Sep 2011 19:01:06 -0700 (PDT)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id 476391F0C4B for ; Wed, 28 Sep 2011 19:01:06 -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 <0LS9008YWHOP7I@szxga05-in.huawei.com> for ccamp@ietf.org; Thu, 29 Sep 2011 10:02:49 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS9008O8HONVK@szxga05-in.huawei.com> for ccamp@ietf.org; Thu, 29 Sep 2011 10:02:49 +0800 (CST)
Received: from szxeml205-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id ADZ10367; Thu, 29 Sep 2011 10:02:48 +0800
Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by szxeml205-edg.china.huawei.com (172.24.2.57) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 29 Sep 2011 10:02:43 +0800
Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.142]) by szxeml411-hub.china.huawei.com ([10.82.67.138]) with mapi id 14.01.0270.001; Thu, 29 Sep 2011 10:02:40 +0800
Date: Thu, 29 Sep 2011 02:02:38 +0000
From: Zhangfatai 
In-reply-to: <5E893DB832F57341992548CDBB333163A43FFBFEEB@EMBX01-HQ.jnpr.net>
X-Originating-IP: [172.24.2.40]
To: Lou Berger , CCAMP 
Message-id: 
MIME-version: 1.0
Content-type: text/plain; charset=gb2312
Content-language: zh-CN
Content-transfer-encoding: 7BIT
Accept-Language: zh-CN, en-US
Thread-topic: [CCAMP] Poll on making G.709 Routing and Signaling drafts	WG documents
Thread-index: AQHMfgR4NvgM5NNDeUu6zIJgvTOJrJVjmzl5
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <4E834C0D.5030800@labn.net> <5E893DB832F57341992548CDBB333163A43FFBFEEB@EMBX01-HQ.jnpr.net>
Subject: [CCAMP] =?gb2312?b?tPC4tDogIFBvbGwgb24gbWFraW5nIEcuNzA5IFJvdXRp?= =?gb2312?b?bmcgYW5kIFNpZ25hbGluZyBkcmFmdHMJV0cJZG9jdW1lbnRz?=
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Sep 2011 02:01:07 -0000

Yes to both (as co-author of both).


Thanks

Fatai


> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of Lou Berger
> Sent: Wednesday, September 28, 2011 12:32 PM
> To: CCAMP
> Subject: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG
> documents
>
> This message starts a two week poll on making the documents listed
> below
> ccamp working group documents.  Please send a mail to the mailing list
> indicating "yes/support to both" or "no/do not support either".  Of
> course, you may also support one but not the other.  (We will assume
> that you support/object to both if you don't specify.)
>
> If indicating no, please state your technical reservations with the
> document.
>
> The documents being polled are:
> http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-ospf-g709-07
> http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-evolving-g709-09
>
> The poll ends Wednesday October 12.
>
> Please also bear in mind that WG adoption does not signify that work is
> complete on the documents or that the technical details are fixed, but
> rather that further development of the documents will take place based
> on WG process.
>
> Much thanks,
> Lou (and Deborah)
> _______________________________________________

From huawei.danli@huawei.com  Wed Sep 28 19:08:38 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 236D01F0C79 for ; Wed, 28 Sep 2011 19:08:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.444
X-Spam-Level: 
X-Spam-Status: No, score=-0.444 tagged_above=-999 required=5 tests=[AWL=-2.893, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6z6B9uNePCKV for ; Wed, 28 Sep 2011 19:08:36 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8DBBF1F0C4B for ; Wed, 28 Sep 2011 19:08:36 -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 <0LS900FMDI2H04@szxga03-in.huawei.com> for ccamp@ietf.org; Thu, 29 Sep 2011 10:11:05 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LS900C0UI2H07@szxga03-in.huawei.com> for ccamp@ietf.org; Thu, 29 Sep 2011 10:11:05 +0800 (CST)
Received: from szxeml203-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id ADZ11174; Thu, 29 Sep 2011 10:11:05 +0800
Received: from SZXEML403-HUB.china.huawei.com (10.82.67.35) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 29 Sep 2011 10:10:59 +0800
Received: from SZXEML526-MBS.china.huawei.com ([169.254.7.147]) by szxeml403-hub.china.huawei.com ([10.82.67.35]) with mapi id 14.01.0270.001; Thu, 29 Sep 2011 10:10:58 +0800
Date: Thu, 29 Sep 2011 02:10:58 +0000
From: Huawei danli 
In-reply-to: <4E834C0D.5030800@labn.net>
X-Originating-IP: [172.24.2.40]
To: Lou Berger , CCAMP 
Message-id: <92A1F6CF27D54D4DA5364E59D892A02AF4BE6B@szxeml526-mbs.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=gb2312
Content-language: zh-CN
Content-transfer-encoding: base64
Accept-Language: zh-CN, en-US
Thread-topic: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG documents
Thread-index: AQHMffzoHlNzKeLy3UyfFlgovXDxv5VjndAh
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <4E834C0D.5030800@labn.net>
Subject: [CCAMP] =?gb2312?b?tPC4tDogIFBvbGwgb24gbWFraW5nIEcuNzA5IFJvdXRp?= =?gb2312?b?bmcgYW5kIFNpZ25hbGluZyBkcmFmdHMgV0cJZG9jdW1lbnRz?=
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Sep 2011 02:08:38 -0000

WWVzLCBzdXBwb3J0IHRvIGJvdGghCgpEYW4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18Kt6K8/sjLOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFtjY2FtcC1ib3VuY2Vz
QGlldGYub3JnXSC0+rHtIExvdSBCZXJnZXIgW2xiZXJnZXJAbGFibi5uZXRdCreiy83KsbzkOiAy
MDExxOo51MIyOcjVIDA6MzIKtb06IENDQU1QCtb3zOI6IFtDQ0FNUF0gUG9sbCBvbiBtYWtpbmcg
Ry43MDkgUm91dGluZyBhbmQgU2lnbmFsaW5nIGRyYWZ0cyBXRyAgICAgICAgZG9jdW1lbnRzCgpU
aGlzIG1lc3NhZ2Ugc3RhcnRzIGEgdHdvIHdlZWsgcG9sbCBvbiBtYWtpbmcgdGhlIGRvY3VtZW50
cyBsaXN0ZWQgYmVsb3cKY2NhbXAgd29ya2luZyBncm91cCBkb2N1bWVudHMuICBQbGVhc2Ugc2Vu
ZCBhIG1haWwgdG8gdGhlIG1haWxpbmcgbGlzdAppbmRpY2F0aW5nICJ5ZXMvc3VwcG9ydCB0byBi
b3RoIiBvciAibm8vZG8gbm90IHN1cHBvcnQgZWl0aGVyIi4gIE9mCmNvdXJzZSwgeW91IG1heSBh
bHNvIHN1cHBvcnQgb25lIGJ1dCBub3QgdGhlIG90aGVyLiAgKFdlIHdpbGwgYXNzdW1lCnRoYXQg
eW91IHN1cHBvcnQvb2JqZWN0IHRvIGJvdGggaWYgeW91IGRvbid0IHNwZWNpZnkuKQoKSWYgaW5k
aWNhdGluZyBubywgcGxlYXNlIHN0YXRlIHlvdXIgdGVjaG5pY2FsIHJlc2VydmF0aW9ucyB3aXRo
IHRoZQpkb2N1bWVudC4KClRoZSBkb2N1bWVudHMgYmVpbmcgcG9sbGVkIGFyZToKaHR0cDovL3Rv
b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY2VjY2FyZWxsaS1jY2FtcC1nbXBscy1vc3BmLWc3MDkt
MDcKaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhhbmctY2NhbXAtZ21wbHMtZXZv
bHZpbmctZzcwOS0wOQoKVGhlIHBvbGwgZW5kcyBXZWRuZXNkYXkgT2N0b2JlciAxMi4KClBsZWFz
ZSBhbHNvIGJlYXIgaW4gbWluZCB0aGF0IFdHIGFkb3B0aW9uIGRvZXMgbm90IHNpZ25pZnkgdGhh
dCB3b3JrIGlzCmNvbXBsZXRlIG9uIHRoZSBkb2N1bWVudHMgb3IgdGhhdCB0aGUgdGVjaG5pY2Fs
IGRldGFpbHMgYXJlIGZpeGVkLCBidXQKcmF0aGVyIHRoYXQgZnVydGhlciBkZXZlbG9wbWVudCBv
ZiB0aGUgZG9jdW1lbnRzIHdpbGwgdGFrZSBwbGFjZSBiYXNlZApvbiBXRyBwcm9jZXNzLgoKTXVj
aCB0aGFua3MsCkxvdSAoYW5kIERlYm9yYWgpCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fCkNDQU1QIG1haWxpbmcgbGlzdApDQ0FNUEBpZXRmLm9yZwpodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wCg==

From wang.qilei@zte.com.cn  Wed Sep 28 19:38:57 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 860FA1F0D20 for ; Wed, 28 Sep 2011 19:38:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -91.987
X-Spam-Level: 
X-Spam-Status: No, score=-91.987 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, MSGID_FROM_MTA_HEADER=0.803, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVj88DmcDrbb for ; Wed, 28 Sep 2011 19:38:57 -0700 (PDT)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id DA4141F0D1E for ; Wed, 28 Sep 2011 19:38:56 -0700 (PDT)
Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 46621473195744; Thu, 29 Sep 2011 10:38:47 +0800 (CST)
Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 75544.473195744; Thu, 29 Sep 2011 10:41:32 +0800 (CST)
Received: (from root@localhost) by mse02.zte.com.cn id p8T2fVTr040355 for ; Thu, 29 Sep 2011 10:41:31 +0800 (GMT-8) (envelope-from wang.qilei@zte.com.cn)
Message-Id: <201109290241.p8T2fVTr040355@mse02.zte.com.cn>
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p8T28UPD039592; Thu, 29 Sep 2011 10:08:30 +0800 (GMT-8) (envelope-from wang.qilei@zte.com.cn)
In-Reply-To: <4E834C0D.5030800@labn.net>
To: Lou Berger 
MIME-Version: 1.0
X-KeepSent: F2008244:EB6B1F32-4825791A:000B9486; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007
From: wang.qilei@zte.com.cn
Date: Thu, 29 Sep 2011 10:08:20 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-09-29 10:08:31, Serialize complete at 2011-09-29 10:08:31
Content-Type: multipart/alternative; boundary="=_alternative 000BC5474825791A_="
X-MAIL: mse02.zte.com.cn p8T2fVTr040355
X-MSS: AUDITRELEASE@mse02.zte.com.cn
Cc: CCAMP , ccamp-bounces@ietf.org
Subject: [CCAMP] =?gb2312?b?tPC4tDogIFBvbGwgb24gbWFraW5nIEcuNzA5IFJvdXRp?= =?gb2312?b?bmcgYW5kIFNpZ25hbGluZyBkcmFmdHMgV0cJZG9jdW1lbnRz?=
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Sep 2011 02:38:57 -0000

This is a multipart message in MIME format.
--=_alternative 000BC5474825791A_=
Content-Type: text/plain; charset="GB2312"
Content-Transfer-Encoding: base64

c3VwcG9ydCBib3RoDQoNCnRoYW5rcw0KUWlsZWkgV2FuZw0KDQoNCg0KDQpMb3UgQmVyZ2VyIDxs
YmVyZ2VyQGxhYm4ubmV0PiANCreivP7IyzogIGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTEt
MDktMjkgMDA6MzINCg0KytW8/sjLDQpDQ0FNUCA8Y2NhbXBAaWV0Zi5vcmc+DQqzrcvNDQoNCtb3
zOINCltDQ0FNUF0gUG9sbCBvbiBtYWtpbmcgRy43MDkgUm91dGluZyBhbmQgU2lnbmFsaW5nIGRy
YWZ0cyBXRyAgICBkb2N1bWVudHMNCg0KDQoNCg0KDQoNClRoaXMgbWVzc2FnZSBzdGFydHMgYSB0
d28gd2VlayBwb2xsIG9uIG1ha2luZyB0aGUgZG9jdW1lbnRzIGxpc3RlZCBiZWxvdw0KY2NhbXAg
d29ya2luZyBncm91cCBkb2N1bWVudHMuICBQbGVhc2Ugc2VuZCBhIG1haWwgdG8gdGhlIG1haWxp
bmcgbGlzdA0KaW5kaWNhdGluZyAieWVzL3N1cHBvcnQgdG8gYm90aCIgb3IgIm5vL2RvIG5vdCBz
dXBwb3J0IGVpdGhlciIuICBPZg0KY291cnNlLCB5b3UgbWF5IGFsc28gc3VwcG9ydCBvbmUgYnV0
IG5vdCB0aGUgb3RoZXIuICAoV2Ugd2lsbCBhc3N1bWUNCnRoYXQgeW91IHN1cHBvcnQvb2JqZWN0
IHRvIGJvdGggaWYgeW91IGRvbid0IHNwZWNpZnkuKQ0KDQpJZiBpbmRpY2F0aW5nIG5vLCBwbGVh
c2Ugc3RhdGUgeW91ciB0ZWNobmljYWwgcmVzZXJ2YXRpb25zIHdpdGggdGhlDQpkb2N1bWVudC4N
Cg0KVGhlIGRvY3VtZW50cyBiZWluZyBwb2xsZWQgYXJlOg0KaHR0cDovL3Rvb2xzLmlldGYub3Jn
L2h0bWwvZHJhZnQtY2VjY2FyZWxsaS1jY2FtcC1nbXBscy1vc3BmLWc3MDktMDcNCmh0dHA6Ly90
b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXpoYW5nLWNjYW1wLWdtcGxzLWV2b2x2aW5nLWc3MDkt
MDkNCg0KVGhlIHBvbGwgZW5kcyBXZWRuZXNkYXkgT2N0b2JlciAxMi4NCg0KUGxlYXNlIGFsc28g
YmVhciBpbiBtaW5kIHRoYXQgV0cgYWRvcHRpb24gZG9lcyBub3Qgc2lnbmlmeSB0aGF0IHdvcmsg
aXMNCmNvbXBsZXRlIG9uIHRoZSBkb2N1bWVudHMgb3IgdGhhdCB0aGUgdGVjaG5pY2FsIGRldGFp
bHMgYXJlIGZpeGVkLCBidXQNCnJhdGhlciB0aGF0IGZ1cnRoZXIgZGV2ZWxvcG1lbnQgb2YgdGhl
IGRvY3VtZW50cyB3aWxsIHRha2UgcGxhY2UgYmFzZWQNCm9uIFdHIHByb2Nlc3MuDQoNCk11Y2gg
dGhhbmtzLA0KTG91IChhbmQgRGVib3JhaCkNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQpDQ0FNUCBtYWlsaW5nIGxpc3QNCkNDQU1QQGlldGYub3JnDQpo
dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NjYW1wDQoNCg0KDQo=
--=_alternative 000BC5474825791A_=
Content-Type: text/html; charset="GB2312"
Content-Transfer-Encoding: base64

DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPnN1cHBvcnQgYm90aDwvZm9udD4N
Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+dGhhbmtzPC9mb250Pg0K
PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5RaWxlaSBXYW5nPC9mb250Pjxmb250
IHNpemU9Mz48YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAw
JT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fu
cy1zZXJpZiI+PGI+TG91IEJlcmdlciAmbHQ7bGJlcmdlckBsYWJuLm5ldCZndDs8L2I+DQo8L2Zv
bnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7IyzogJm5ic3A7Y2Nh
bXAtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl
cmlmIj4yMDExLTA5LTI5IDAwOjMyPC9mb250Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0
aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNp
emU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6
ZT0xIGZhY2U9InNhbnMtc2VyaWYiPkNDQU1QICZsdDtjY2FtcEBpZXRmLm9yZyZndDs8L2ZvbnQ+
DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZh
Y2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+DQo8dHIgdmFsaWduPXRvcD4N
Cjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPtb3
zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPltDQ0FN
UF0gUG9sbCBvbiBtYWtpbmcgRy43MDkgUm91dGluZw0KYW5kIFNpZ25hbGluZyBkcmFmdHMgV0cg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZG9jdW1lbnRzPC9mb250PjwvdGFibGU+DQo8YnI+
DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFi
bGU+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5UaGlzIG1lc3NhZ2Ugc3RhcnRz
IGEgdHdvIHdlZWsgcG9sbCBvbiBtYWtpbmcgdGhlDQpkb2N1bWVudHMgbGlzdGVkIGJlbG93PGJy
Pg0KY2NhbXAgd29ya2luZyBncm91cCBkb2N1bWVudHMuICZuYnNwO1BsZWFzZSBzZW5kIGEgbWFp
bCB0byB0aGUgbWFpbGluZw0KbGlzdDxicj4NCmluZGljYXRpbmcgJnF1b3Q7eWVzL3N1cHBvcnQg
dG8gYm90aCZxdW90OyBvciAmcXVvdDtuby9kbyBub3Qgc3VwcG9ydCBlaXRoZXImcXVvdDsuDQom
bmJzcDtPZjxicj4NCmNvdXJzZSwgeW91IG1heSBhbHNvIHN1cHBvcnQgb25lIGJ1dCBub3QgdGhl
IG90aGVyLiAmbmJzcDsoV2Ugd2lsbCBhc3N1bWU8YnI+DQp0aGF0IHlvdSBzdXBwb3J0L29iamVj
dCB0byBib3RoIGlmIHlvdSBkb24ndCBzcGVjaWZ5Lik8YnI+DQo8YnI+DQpJZiBpbmRpY2F0aW5n
IG5vLCBwbGVhc2Ugc3RhdGUgeW91ciB0ZWNobmljYWwgcmVzZXJ2YXRpb25zIHdpdGggdGhlPGJy
Pg0KZG9jdW1lbnQuPGJyPg0KPGJyPg0KVGhlIGRvY3VtZW50cyBiZWluZyBwb2xsZWQgYXJlOjxi
cj4NCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWNlY2NhcmVsbGktY2NhbXAtZ21w
bHMtb3NwZi1nNzA5LTA3PGJyPg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtemhh
bmctY2NhbXAtZ21wbHMtZXZvbHZpbmctZzcwOS0wOTxicj4NCjxicj4NClRoZSBwb2xsIGVuZHMg
V2VkbmVzZGF5IE9jdG9iZXIgMTIuPGJyPg0KPGJyPg0KUGxlYXNlIGFsc28gYmVhciBpbiBtaW5k
IHRoYXQgV0cgYWRvcHRpb24gZG9lcyBub3Qgc2lnbmlmeSB0aGF0IHdvcmsgaXM8YnI+DQpjb21w
bGV0ZSBvbiB0aGUgZG9jdW1lbnRzIG9yIHRoYXQgdGhlIHRlY2huaWNhbCBkZXRhaWxzIGFyZSBm
aXhlZCwgYnV0PGJyPg0KcmF0aGVyIHRoYXQgZnVydGhlciBkZXZlbG9wbWVudCBvZiB0aGUgZG9j
dW1lbnRzIHdpbGwgdGFrZSBwbGFjZSBiYXNlZDxicj4NCm9uIFdHIHByb2Nlc3MuPGJyPg0KPGJy
Pg0KTXVjaCB0aGFua3MsPGJyPg0KTG91IChhbmQgRGVib3JhaCk8YnI+DQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCkNDQU1QIG1haWxpbmcgbGlz
dDxicj4NCkNDQU1QQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s
aXN0aW5mby9jY2FtcDxicj4NCjxicj4NCjwvZm9udD48L3R0Pg0KPGJyPg0K
--=_alternative 000BC5474825791A_=--


From huubatwork@gmail.com  Wed Sep 28 20:16:38 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEEF01F0CDE for ; Wed, 28 Sep 2011 20:16:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.149
X-Spam-Level: 
X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iebLXEizrSfy for ; Wed, 28 Sep 2011 20:16:38 -0700 (PDT)
Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 131C41F0CAE for ; Wed, 28 Sep 2011 20:16:37 -0700 (PDT)
Received: by pzk37 with SMTP id 37so485901pzk.9 for ; Wed, 28 Sep 2011 20:19:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:disposition-notification-to:date:from:reply-to :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=o7gf9EHY+JYTJmRE0Y5srNJ6DNXlcxBlKNulnYVZ57Y=; b=FNVI850nlKqzCE/6OsitYYt3oNwgIsQh+pVRov1gEf1Z6s4yzlv+++ITPdG+14XrB1 zfifgBqYp/u9F5QUvZNjdQqJCm7kZzoPE+cbNcjOMEZhDLVkYEC+AOdT1m3BvB+fpf3n DOWUT/1BfEJbKg8tz6dlzfxWZh/AuFDOQCisY=
Received: by 10.68.7.132 with SMTP id j4mr49210955pba.102.1317266360829; Wed, 28 Sep 2011 20:19:20 -0700 (PDT)
Received: from McAsterix.local ([118.112.186.108]) by mx.google.com with ESMTPS id h5sm1570105pbq.11.2011.09.28.20.19.17 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 28 Sep 2011 20:19:19 -0700 (PDT)
Message-ID: <4E83E3AA.6020203@gmail.com>
Date: Thu, 29 Sep 2011 05:19:06 +0200
From: Huub van Helvoort 
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3
MIME-Version: 1.0
To: CCAMP 
References: <4E834C0D.5030800@labn.net> <92A1F6CF27D54D4DA5364E59D892A02AF4BE6B@szxeml526-mbs.china.huawei.com>
In-Reply-To: <92A1F6CF27D54D4DA5364E59D892A02AF4BE6B@szxeml526-mbs.china.huawei.com>
Content-Type: text/plain; charset=GB2312
Content-Transfer-Encoding: 8bit
Subject: Re: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG documents
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: huubatwork@gmail.com
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Sep 2011 03:16:39 -0000

Yes, support to both!

Regards, Huub.

> ________________________________________
> ·¢¼þÈË: ccamp-bounces@ietf.org [ccamp-bounces@ietf.org] ´ú±í Lou Berger [lberger@labn.net]
> ·¢ËÍʱ¼ä: 2011Äê9ÔÂ29ÈÕ 0:32
> µ½: CCAMP
> Ö÷Ìâ: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG documents
> 
> This message starts a two week poll on making the documents listed below
> ccamp working group documents.  Please send a mail to the mailing list
> indicating "yes/support to both" or "no/do not support either".  Of
> course, you may also support one but not the other.  (We will assume
> that you support/object to both if you don't specify.)
> 
> If indicating no, please state your technical reservations with the
> document.
> 
> The documents being polled are:
> http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-ospf-g709-07
> http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-evolving-g709-09
> 
> The poll ends Wednesday October 12.
> 
> Please also bear in mind that WG adoption does not signify that work is
> complete on the documents or that the technical details are fixed, but
> rather that further development of the documents will take place based
> on WG process.
> 
> Much thanks,
> Lou (and Deborah)

From tochio@jp.fujitsu.com  Wed Sep 28 20:30:44 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE87221F8DF3 for ; Wed, 28 Sep 2011 20:30:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.09
X-Spam-Level: 
X-Spam-Status: No, score=-104.09 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265,  RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUXAXXGD153q for ; Wed, 28 Sep 2011 20:30:44 -0700 (PDT)
Received: from fgwmail5.fujitsu.co.jp (fgwmail5.fujitsu.co.jp [192.51.44.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3187521F8DF4 for ; Wed, 28 Sep 2011 20:30:44 -0700 (PDT)
Received: from m1.gw.fujitsu.co.jp (unknown [10.0.50.71]) by fgwmail5.fujitsu.co.jp (Postfix) with ESMTP id 5D9803EE081 for ; Thu, 29 Sep 2011 12:33:33 +0900 (JST)
Received: from smail (m1 [127.0.0.1]) by outgoing.m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 414E145DE56 for ; Thu, 29 Sep 2011 12:33:33 +0900 (JST)
Received: from s1.gw.fujitsu.co.jp (s1.gw.fujitsu.co.jp [10.0.50.91]) by m1.gw.fujitsu.co.jp (Postfix) with ESMTP id 2AD1945DE55 for ; Thu, 29 Sep 2011 12:33:33 +0900 (JST)
Received: from s1.gw.fujitsu.co.jp (localhost.localdomain [127.0.0.1]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id 1FCA01DB8051 for ; Thu, 29 Sep 2011 12:33:33 +0900 (JST)
Received: from sw11.gw.fujitsu.co.jp (sw11.gw.fujitsu.co.jp [10.0.76.51]) by s1.gw.fujitsu.co.jp (Postfix) with ESMTP id E514F1DB8049 for ; Thu, 29 Sep 2011 12:33:32 +0900 (JST)
Received: from [127.0.0.1] ([172.31.165.90]) by sw11.gw.fujitsu.co.jp with ESMTP id p8T3XG9l033083 for ; Thu, 29 Sep 2011 12:33:31 +0900 (JST)
X-SecurityPolicyCheck: OK by SHieldMailChecker v1.5.1
Message-ID: <4E83E6F2.7030602@jp.fujitsu.com>
Date: Thu, 29 Sep 2011 12:33:06 +0900
From: Yuji Tochio 
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: CCAMP 
References: <4E834C0D.5030800@labn.net>
In-Reply-To: <4E834C0D.5030800@labn.net>
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Subject: Re: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG documents
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Sep 2011 03:30:44 -0000

Support for both.

Thanks, Yuji

(2011/09/29 1:32), Lou Berger wrote:
> This message starts a two week poll on making the documents listed below
> ccamp working group documents.  Please send a mail to the mailing list
> indicating "yes/support to both" or "no/do not support either".  Of
> course, you may also support one but not the other.  (We will assume
> that you support/object to both if you don't specify.)
>
> If indicating no, please state your technical reservations with the
> document.
>
> The documents being polled are:
> http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-ospf-g709-07
> http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-evolving-g709-09
>
> The poll ends Wednesday October 12.
>
> Please also bear in mind that WG adoption does not signify that work is
> complete on the documents or that the technical details are fixed, but
> rather that further development of the documents will take place based
> on WG process.
>
> Much thanks,
> Lou (and Deborah)
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
>
>



From ping@pingpan.org  Wed Sep 28 20:46:31 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A10AF11E80CC for ; Wed, 28 Sep 2011 20:46:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.834
X-Spam-Level: 
X-Spam-Status: No, score=-5.834 tagged_above=-999 required=5 tests=[AWL=0.142,  BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWxcUDXhCzI2 for ; Wed, 28 Sep 2011 20:46:31 -0700 (PDT)
Received: from exprod7og118.obsmtp.com (exprod7og118.obsmtp.com [64.18.2.8]) by ietfa.amsl.com (Postfix) with SMTP id CA9A311E80A4 for ; Wed, 28 Sep 2011 20:46:30 -0700 (PDT)
Received: from mail-vw0-f45.google.com ([209.85.212.45]) (using TLSv1) by exprod7ob118.postini.com ([64.18.6.12]) with SMTP ID DSNKToPquTZ91eub74PN6kXhF2XO355968e7@postini.com; Wed, 28 Sep 2011 20:49:21 PDT
Received: by vws17 with SMTP id 17so157793vws.4 for ; Wed, 28 Sep 2011 20:49:13 -0700 (PDT)
Received: by 10.52.97.36 with SMTP id dx4mr9238907vdb.146.1317268153066; Wed, 28 Sep 2011 20:49:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.160.40 with HTTP; Wed, 28 Sep 2011 20:48:29 -0700 (PDT)
In-Reply-To: <4E834C0D.5030800@labn.net>
References: <4E834C0D.5030800@labn.net>
From: Ping Pan 
Date: Thu, 29 Sep 2011 11:48:29 +0800
Message-ID: 
To: Lou Berger 
Content-Type: multipart/alternative; boundary=20cf307f31a656655704ae0c6405
Cc: CCAMP 
Subject: Re: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG documents
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Sep 2011 03:46:31 -0000

--20cf307f31a656655704ae0c6405
Content-Type: text/plain; charset=ISO-8859-1

Yes to both.

On Thu, Sep 29, 2011 at 12:32 AM, Lou Berger  wrote:

> This message starts a two week poll on making the documents listed below
> ccamp working group documents.  Please send a mail to the mailing list
> indicating "yes/support to both" or "no/do not support either".  Of
> course, you may also support one but not the other.  (We will assume
> that you support/object to both if you don't specify.)
>
> If indicating no, please state your technical reservations with the
> document.
>
> The documents being polled are:
> http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-ospf-g709-07
> http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-evolving-g709-09
>
> The poll ends Wednesday October 12.
>
> Please also bear in mind that WG adoption does not signify that work is
> complete on the documents or that the technical details are fixed, but
> rather that further development of the documents will take place based
> on WG process.
>
> Much thanks,
> Lou (and Deborah)
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
>

--20cf307f31a656655704ae0c6405
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Yes to both.

On Thu, Sep 29, 2011 at 12:3=
2 AM, Lou Berger <=
lberger@labn.net> wrote:


This message starts a two week poll on making the documents listed below
ccamp working group documents. =A0Please send a mail to the mailing list
indicating "yes/support to both" or "no/do not support eithe=
r". =A0Of

course, you may also support one but not the other. =A0(We will assume

that you support/object to both if you don't specify.)



If indicating no, please state your technical reservations with the

document.



The documents being polled are:

http://tools.ietf.org/html/draft-ceccarelli-ccamp-g=
mpls-ospf-g709-07

http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-e=
volving-g709-09



The poll ends Wednesday October 12.



Please also bear in mind that WG adoption does not signify that work is

complete on the documents or that the technical details are fixed, but

rather that further development of the documents will take place based

on WG process.



Much thanks,

Lou (and Deborah)

_______________________________________________

CCAMP mailing list

CCAMP@ietf.org

h=
ttps://www.ietf.org/mailman/listinfo/ccamp





--20cf307f31a656655704ae0c6405--

From pietro_vittorio.grandi@alcatel-lucent.com  Thu Sep 29 00:24:50 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F047321F8D25 for ; Thu, 29 Sep 2011 00:24:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.556
X-Spam-Level: 
X-Spam-Status: No, score=-5.556 tagged_above=-999 required=5 tests=[AWL=0.693,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZHZOaOFDjxMH for ; Thu, 29 Sep 2011 00:24:50 -0700 (PDT)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 2A71921F8B8A for ; Thu, 29 Sep 2011 00:24:49 -0700 (PDT)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p8T7RYXu016608 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 29 Sep 2011 09:27:39 +0200
Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 29 Sep 2011 09:26:58 +0200
From: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" 
To: Lou Berger , CCAMP 
Date: Thu, 29 Sep 2011 09:26:55 +0200
Thread-Topic: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG documents
Thread-Index: Acx9/DV+jQ6dp5WsR9CyZ0GrQm6tnAAfOhYg
Message-ID: 
References: <4E834C0D.5030800@labn.net>
In-Reply-To: <4E834C0D.5030800@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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13
Subject: Re: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG	documents
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Sep 2011 07:24:51 -0000

Support both as co-author :-)

=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
Pietro Vittorio Grandi
Terrestrial Optics Portfolio Evolution
Alcatel-Lucent Vimercate (Italy)
Tel: +39 039 686 4930
Mail: pietro_vittorio.grandi@alcatel-lucent.com
=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
Put your hand on a hot stove for a minute, and it seems like an hour.
Sit with a pretty girl for an hour, and it seems like a  minute. That's rel=
ativity.
(A. Einstein)


-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L=
ou Berger
Sent: mercoled=EC 28 settembre 2011 18.32
To: CCAMP
Subject: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG docum=
ents

This message starts a two week poll on making the documents listed below
ccamp working group documents.  Please send a mail to the mailing list
indicating "yes/support to both" or "no/do not support either".  Of
course, you may also support one but not the other.  (We will assume
that you support/object to both if you don't specify.)

If indicating no, please state your technical reservations with the
document.

The documents being polled are:
http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-ospf-g709-07
http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-evolving-g709-09

The poll ends Wednesday October 12.

Please also bear in mind that WG adoption does not signify that work is
complete on the documents or that the technical details are fixed, but
rather that further development of the documents will take place based
on WG process.

Much thanks,
Lou (and Deborah)
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

From pierre.peloso@alcatel-lucent.com  Thu Sep 29 00:26:23 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0FB021F8D3F for ; Thu, 29 Sep 2011 00:26:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.66
X-Spam-Level: 
X-Spam-Status: No, score=-5.66 tagged_above=-999 required=5 tests=[AWL=0.589,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvuWqjyymGeJ for ; Thu, 29 Sep 2011 00:26:22 -0700 (PDT)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 38F5621F8B9F for ; Thu, 29 Sep 2011 00:26:21 -0700 (PDT)
Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p8T7SRRB029158 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 29 Sep 2011 09:28:56 +0200
Received: from FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 29 Sep 2011 09:28:39 +0200
From: "PELOSO, PIERRE (PIERRE)" 
To: Leeyoung , "Margaria, Cyril (NSN - DE/Munich)" , "ccamp@ietf.org" 
Date: Thu, 29 Sep 2011 09:28:38 +0200
Thread-Topic: [CCAMP] FW:  I-D Action: draft-ietf-ccamp-rwa-info-12.txt
Thread-Index: AQHMfGU421ASISnyGEauN0YmoQNTfpVjNyIggADAUzA=
Message-ID: 
References: <7AEB3D6833318045B4AE71C2C87E8E17181669D3@DFWEML501-MBX.china.huawei.com>  <7AEB3D6833318045B4AE71C2C87E8E171817E09A@DFWEML501-MBX.china.huawei.com>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E171817E09A@DFWEML501-MBX.china.huawei.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR, en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83
Subject: Re: [CCAMP] FW:  I-D Action: draft-ietf-ccamp-rwa-info-12.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Sep 2011 07:26:23 -0000

Hi Young,

See in line.
=20
Best regards,

- pierre

-----Message d'origine-----
De : ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] De la part de L=
eeyoung
Envoy=E9 : mercredi 28 septembre 2011 23:47
=C0 : Margaria, Cyril (NSN - DE/Munich); ccamp@ietf.org
Objet : Re: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-info-12.txt

Hi Cyril,

Thanks for your review and suggestions. It looks like there are two issues =
pending: Point #2 and #3.=20
We can close the rest of the points you raised with the action specified in=
-line. Please let me know otherwise.=20

Thanks.

Young


-----Original Message-----
From: Margaria, Cyril (NSN - DE/Munich) [mailto:cyril.margaria@nsn.com]
Sent: Monday, September 26, 2011 10:59 AM
To: Leeyoung; ccamp@ietf.org
Subject: RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-info-12.txt


Hi,=20
I have the following comments on  draft-ietf-ccamp-rwa-wson-encode-12
after it being updated and in light of the WG discussions:

1) section 3.1. Resource Block Set Field:
   The information model indicates that the resource block set is
optional for the  "Resource Block Information", hence the text should be
modified as follow:
"0 - Inclusive List

     Indicates that the TLV contains zero or more RB elements that are
     included in the list."

YOUNG>> Will do in the next revision. (Closure)=20

2) section 3.1. Resource Block Set Field:
RB Identifier: as stated in section "3. Resources, Blocks, Sets, and the
Resource Pool", Resources and Resource Blocks are related to interface
cards.

GMPLS implementations are using 32-bit unnumbered interface IDs to
identify GMPLS links and also the corresponding physical resources.
OEO devices and, in the context of this document, resource or resource
group can also be identified by 32-bit unnumbered interface IDs.

 From an implementation point of view, having 16-bit resource block IDs
have several drawbacks because of the following points:
  a) Mapping exists between physical resource and unnumbered interface
IDs, this mapping is generally known by management system,
      introducing a different ID space is not optimal (new mapping
needed);
  b) Those OEOs might be used as links in a multi-node model, thus being
identified by a 32-bit unnumbered interface IDs, introducing another
space is also not optimal.

Therefore, it would be better if the resource block IDs were 32-bit
interface IDs (to be unique within the node, not because they are
representing links in this document).

YOUNG>> The only motivation why we used 16 bits for RB ID is to reduce the =
space. And I think this is an internal link so it is not the real interface=
 per se and thus there is no need to keep track of the state of RB ID like =
other legitimate interfaces. I don't think there is a substantial implement=
ation issue here whether we use 16 bits or 32 bits, but if there is a stron=
g support to use 32 bit ID over 16 bit ID, I am fine with this. Lou and Deb=
orah, do you have any suggestion on this issue? Or other implementers?=20

PIERRE>> As an implementer I am in favor of 32 bits, which I find more conv=
enient for the same reasons as the one exposed by Cyril.


3) section 3.1. Resource Block Set Field Why not define a bit set=20
action, similar to the label set?

YOUNG>> Are you referring the Label Set encoding as follows from draft-ietf=
-ccamp-general-constraint-encode-05.txt

  0                   1                   2                   3=20
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
     | Action|    Num Labels         |          Length               |=20
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
     |                          Base Label                           |=20
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
     |     Additional fields as necessary per action                 |


The current Resource Block Set Field is encoded as follows:

  0                   1                   2                   3=20
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
      |    Action     |E|C| Reserved  |        Length                 |=20
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
      |     RB Identifier 1           |        RB Identifier 2        |=20
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
      :                               :                               :=20
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
      |     RB Identifier n-1         |        RB Identifier n        |=20
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

YOUNG>> Can you be specific about your suggestion? Are you concerned about =
label being 32 bit vs RB identifier being 16 bits? --- then this is basical=
ly related to your point #2. If you have other concerns, please spell them =
out (e.g., action field (4 bits vs 8 bits), etc..) The Num Labels field is =
necessary when we are indicating bit maps (Action =3D 4), which Is not need=
ed for Resource Block Set; E bit is not necessary when we adopt 32 bit RB I=
D, but C bit is needed to indicate the connectivity nature of Resource Pool=
 Accessibility.=20

YOUNG>> Would the following encoding is what you are envisioning? If not, p=
lease suggest in detail.=20

  0                   1                   2                   3=20
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
      | Action|C|                     |        Length                 |=20
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
      |                         RB Identifier 1                       |=20
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
      :                               :                               :=20
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
      |                         RB Identifier n                       |=20
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




4) section 4.3. Resource Pool State Sub-TLV

The RB state refers to the number of available resources within the=20
resource block, the first sentence mentions the resource pool only.
In addition, a bit map can be used even in case the resource block
contains several resources.
The following text tries to reflect this, please consider it.

    "The state of the pool is given by the number of resources available
    with particular characteristics. A resource block set is used to
    encode all or a subset of the resources of interest. The usage state
    of resources within a resource block set is encoded as either a list
    of 16-bit integer values, indicating the number of available
resources
    in the resource block, or a map of bits, indicating whether a
particular
    resource is available or not."

YOUNG>> Thanks. This is fine. Will add as you suggested in the revision (Cl=
osure)


5) section 4.3. Resource Pool State Sub-TLV
   Typo: "RB Usage state:  Variable Length but must be a multiple of 4=20
bytes." (byes->bytes)

YOUNG>>  Thanks. Will do s/byes/bytes in Section 4.3 (Closure)

6) section 5.1. Resource Block Information Sub-TLV

Having an Input Modulation Type List sub-sub-TLV containing a list of=20
modulation formats (with an input-output bit) and an Output Modulation=20
Type List sub-sub-TLV containing a list of modulation formats (with an
input-output bit) seems redundant because the bit I already indicates if
it is an output or input modulation format.

Having a single Modulation Type List sub-sub-TLV is providing the same
information with an efficient encoding, a single sub-sub-TLV type should
be used.

Same reasoning apply to the FEC Type List Sub-Sub-TLV.

YOUNG>> I guess what you are suggesting is as follows:=20

    0                   1                   2                   3=20
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=20
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
      |                     RB Set Field                              |=20
      :                                                               :=20
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
      |I|E|                      Reserved                             |=20
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
      |           Modulation Type List Sub-Sub-TLV  (opt)             |=20
      :                                                               :=20
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
      |           FEC Type List Sub-Sub-TLV    (opt)                  |=20
      :                                                               :=20
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
      |         Input Client Signal Type Sub-Sub-TLV      (opt)       |=20
      :                                                               :=20
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
      |         Input Bit Rate Range List  Sub-Sub-TLV (opt)          |=20
      :                                                               :=20
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20
      |         Processing Capabilities List Sub-Sub-TLV (opt)        |=20
      :                                                               :=20
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=20


YOUNG>> If that's what you suggested, that is fine with me. If that is that=
 case, I will revise with this figure in the revision. (Closure)=20

PIERRE>> Actually Young, I take the modification proposed is slightly diffr=
ent it is more to have an I and E bits directly inside each of the Modulati=
on Type and each of the FEC type field.
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |S|I|E|    Modulation ID        |          Length               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

I bit set to 1 states that the modulation is valid as ingress
E bit set to 1 states that the modulation is valid as egress

The same for the FEC type list.
      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |S|I|E|       FEC ID            |          Length               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

7) section 5.1. Resource Block Information Sub-TLV
  Add the following text: "The order of sub-sub-TLVs does not matter,
the sub-sub-TLVs MAY be in any order."

YOUNG>> Thanks. This will be added in the revision (Closure)


Best Regards,=20
Cyril Margaria


> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of ext Leeyoung
> Sent: Friday, September 09, 2011 11:30 PM
> To: ccamp@ietf.org
> Subject: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-info-12.txt
>=20
> Hi,
>=20
> This update (version 12) includes the following:
>=20
> (i) Replaced all instances of "ingress" with "input" and all instances
> of "egress" with "output".
> (ii) Added clarifying text on relationship between resource block
model
> and physical entities such as line cards.
>=20
> This draft is now very mature and incorporated all the comments raised
> in the mailing list and the last meetings.
>=20
> Thanks,
> Young
>=20
> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of internet-drafts@ietf.org
> Sent: Friday, September 09, 2011 4:20 PM
> To: i-d-announce@ietf.org
> Cc: ccamp@ietf.org
> Subject: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-info-12.txt
>=20
> 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.
>=20
> 	Title           : Routing and Wavelength Assignment Information
> Model for Wavelength Switched Optical Networks
> 	Author(s)       : Young Lee
>                           Greg M. Bernstein
>                           Dan Li
>                           Wataru Imajuku
> 	Filename        : draft-ietf-ccamp-rwa-info-12.txt
> 	Pages           : 27
> 	Date            : 2011-09-09
>=20
>    This document provides a model of information needed by the routing
>    and wavelength assignment (RWA) process in wavelength switched
>    optical networks (WSONs).  The purpose of the information described
>    in this model is to facilitate constrained lightpath computation in
>    WSONs. This model takes into account compatibility constraints
>    between WSON signal attributes and network elements but does not
>    include constraints due to optical impairments. Aspects of this
>    information that may be of use to other technologies utilizing a
>    GMPLS control plane are discussed.
>=20
>=20
>=20
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-12.txt
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-12.txt
> _______________________________________________
> 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 sergio.belotti@alcatel-lucent.com  Thu Sep 29 00:49:18 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED43721F8CE9 for ; Thu, 29 Sep 2011 00:49:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.986
X-Spam-Level: 
X-Spam-Status: No, score=-4.986 tagged_above=-999 required=5 tests=[AWL=1.263,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5sQ7DcUlmAPU for ; Thu, 29 Sep 2011 00:49:18 -0700 (PDT)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9F921F8CDD for ; Thu, 29 Sep 2011 00:49:17 -0700 (PDT)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p8T7jgT4006270 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 29 Sep 2011 09:52:07 +0200
Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 29 Sep 2011 09:51:40 +0200
From: "BELOTTI, SERGIO (SERGIO)" 
To: Lou Berger , CCAMP 
Date: Thu, 29 Sep 2011 09:51:38 +0200
Thread-Topic: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG documents
Thread-Index: Acx9/DV+jQ6dp5WsR9CyZ0GrQm6tnAAgD75w
Message-ID: 
References: <4E834C0D.5030800@labn.net>
In-Reply-To: <4E834C0D.5030800@labn.net>
Accept-Language: en-US
Content-Language: it-IT
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83
Subject: [CCAMP] R: Poll on making G.709 Routing and Signaling drafts WG	documents
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Sep 2011 07:49:19 -0000

Support both (as co-authors)

SERGIO BELOTTI

ALCATEL-LUCENT
Terrestrial System Architect
Optics Portfolio Evolution

via Trento 30 , Vimercate(MI)  Italy
T: +39 0396863033
Sergio.Belotti@alcatel-lucent.com



-----Messaggio originale-----
Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di Lou=
 Berger
Inviato: mercoled=EC 28 settembre 2011 18.32
A: CCAMP
Oggetto: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG docum=
ents

This message starts a two week poll on making the documents listed below
ccamp working group documents.  Please send a mail to the mailing list
indicating "yes/support to both" or "no/do not support either".  Of
course, you may also support one but not the other.  (We will assume
that you support/object to both if you don't specify.)

If indicating no, please state your technical reservations with the
document.

The documents being polled are:
http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-ospf-g709-07
http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-evolving-g709-09

The poll ends Wednesday October 12.

Please also bear in mind that WG adoption does not signify that work is
complete on the documents or that the technical details are fixed, but
rather that further development of the documents will take place based
on WG process.

Much thanks,
Lou (and Deborah)
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

From pietro_vittorio.grandi@alcatel-lucent.com  Thu Sep 29 01:46:19 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D8521F8D87 for ; Thu, 29 Sep 2011 01:46:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.605
X-Spam-Level: 
X-Spam-Status: No, score=-5.605 tagged_above=-999 required=5 tests=[AWL=0.644,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6+74uoRS6mt for ; Thu, 29 Sep 2011 01:46:18 -0700 (PDT)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id D8E4521F8D7C for ; Thu, 29 Sep 2011 01:46:17 -0700 (PDT)
Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p8T8hYlL000904 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 29 Sep 2011 10:49:02 +0200
Received: from FRMRSSXCHMBSB1.dc-m.alcatel-lucent.com ([135.120.45.41]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 29 Sep 2011 10:48:27 +0200
From: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" 
To: Lou Berger 
Date: Thu, 29 Sep 2011 10:48:25 +0200
Thread-Topic: R: [CCAMP] Thought on where to carry G.709-v3 TSG
Thread-Index: Acx99H1JIz/e22M8SvyqX/cniM/HiAAjm2sg
Message-ID: 
References: <4E81CD97.3020209@labn.net>  <4E833F1B.4040004@labn.net>
In-Reply-To: <4E833F1B.4040004@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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83
Cc: CCAMP 
Subject: Re: [CCAMP] R:  Thought on where to carry G.709-v3 TSG
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Sep 2011 08:46:19 -0000

Hello Lou,

we try to make further clarification, with a long explanation in line ( sor=
ry for this :-))

Pietro and Sergio

=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
Pietro Vittorio Grandi
Terrestrial Optics Portfolio Evolution
Alcatel-Lucent Vimercate (Italy)
Tel: +39 039 686 4930
Mail: pietro_vittorio.grandi@alcatel-lucent.com
=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
Put your hand on a hot stove for a minute, and it seems like an hour.
Sit with a pretty girl for an hour, and it seems like a  minute. That's rel=
ativity.
(A. Einstein)


-----Original Message-----
From: Lou Berger [mailto:lberger@labn.net]=20
Sent: mercoled=EC 28 settembre 2011 17.37
To: BELOTTI, SERGIO (SERGIO)
Cc: CCAMP; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Subject: Re: R: [CCAMP] Thought on where to carry G.709-v3 TSG


Sergio and Pietro,

It sounds like we should get in-sync on where TSG information is needed
first then talk about how to carry it.  So, I said:

> As I understand it, TSG is needed at:
>   (a) the endpoints that terminate the signal/LSP to ensure proper
>       adaptation.
>   (b) the 2nd and penultimate hops to ensure the proper
>       interface/H-LSP selection.
>   (c) Intermediate nodes for proper TS allocation.
>

>From your mail, I infer that you agree on (a) and (b).  Is this correct?
[[ALU]] We agree on (a) and (b).=20

WRT to (c) you said:
> [ALU] Item (c) is not correct. Intermediate nodes do not need to
demultiplex client, you can have ODU0 LSPs , that surely need to have
1,25 interfaces in the end points but using 2.5 TSG in the middle of the
network since they have tunneled on 2.5 structured containers.
>
>

I'm having a hard time parsing your statement.  Are you saying (i) you
client ODU0 carried over an ODUn (n>0) H-LSP or (ii) and ODU0 which is
carried over links OTUn links and 2.5G slots in the intermediate links,
or (iii) something completely different.
=20
[[ALU]] We think that the better way to understand the problem is having in=
 mind a reference model composed by:

A) The current LSP that we are drawing.=20

B) The server resources used by the current LSP. These resources can be dif=
ferent link by link. The server resources can be represented in control pla=
ne either by TE-link or FA-LSP. When the server capacity is higher then
the capacity of the current LSP (we mean not at the same rate of the client=
) , the server is structured and the current LSP is adapted in the server u=
sing 1.25 or 2.5 tributary slots depending
from the capability of both the endpoints of the server.

C) A resource that is a client of the current LSP. This client can either b=
e
an ODU or use a different technology.=20


If the client in point c) is an ODU (or better a set of ODUs at different r=
ates) then the current LSP will have (in future) to be structured in such a=
 way that the ODU client(s) will be carried.=20
In order to ensure that a client can be set two things must happen at the e=
ndpoint of the current LSP. The first one is that both endpoints declare th=
e same set of clients, and the second is that both endpoint can support
the same tributary slot granularity. Note that it is not possible to infer =
the tributary slot granularity from the client-server hierarchies declared
by a TE-link. Just to make an example, take a TE-link that declares to supp=
ort ODU2 over ODU3, ODU2 can be mapped over ODU3 either using 2.5 or 1.25 t=
ributary slots. To complicate things, it is not always true that an interfa=
ce supporting 1.25 tributary slots can also support 2.5 tributary slots, be=
cause this specific functionality (known as fallback support setting auto-p=
ayload flag to ON) can be either not present in HW or disabled by NMS.  =20

In conclusion to this reasoning, when we signal the current LSP (of point A=
)
we need to transfer two information: The desired tributary slot granularity
that the current LSP will export to future clients and the set of clients (=
point C) that has to be supported (if known).
The desired tributary slot granularity to be exported to future clients dir=
ectly affects the adaptation that will be instantiated when drawing a clien=
t.=20
The desired tributary slot granularity is the entity that we are debating. =
Note that the desired tributary slot granularity for client does not
affect the label signaled for the current LSP. These labels are only affect=
ed by the tributary slot granularity exported by the server that is
carrying the current LSP.

Last but not least, note that the tributary slot granularity is not=20
part of current LSP in the sense that does not exist an ODU2 at 1.25 TS
and does not exist an ODU2 at 2.5 TS. It only exist an ODU2 at a nominal ra=
te mapped over a higher rate server using 2.5 or 1.25 TS.     =20
   =20

> Either way, isn't the case that it would be optimal to use 1.25 TSs for
> certain ODUs (e.g., OD0, ODUFlex) on transit links when both ends of the
> link support 1.25?

[[ALU]] Tributary Slots were originally introduced in order to avoid link d=
efragmentation. They started at 2.5 that was correct for all ODUs (at that =
time) and following it was introduced 1.25 in order to better accommodate G=
bEthernet client (into ODU0 at 1,25) and also ODU-flex (CBR) .

ODU0 and ODU flex MUST be mapped over their server at 1.25. Just to make an=
 example let's take an ODU0 LSP that has to be carried over an ODU2 LSP tha=
t in turn is mapped over several ODU3 LSPs.=20

When signaling the ODU2 LSP we must ensure that at the endpoints the ODU2 L=
SP supports at the endpoints the 1.25 TS granularity. There is no need
(and it is not an optimization) to force the ODU2 LSP to use ODU3 LSPs
that export 1.25 TS. =20


You also said:
> [ALU] In the INFO we have explained the need also for TSG in routing
> (following conclusion of mailing list discussion) and the routing
> draft simply proposes a possible encoding of the information.
>
> This solution, for the sake of truth, can be getting better, taking
> into account the AutoPayloadtype flag information. This information
> is a typical MI information , described in in G.798, and it simply
> tells us whether Fallback procedure is enabled or not.
>=20
> Since this information is typically configured by the manager we do
> not think it has to be considered directly in the control plane
> (neither signaled or advertised ). However we have to take into
> account the fact that auto-payload type set to off generates
> interfaces that can support 1.25 TSG only.
>=20

> Okay, now I'm really confused.  This seems to imply that you are saying
> the (c) above is needed.  What am I missing?

[[ALU]] the advertising of TS information in routing is coming from the req=
uirement found in ITU-T's G.7715.1 stating the need for links to advertise =
the adaptations supported by a link end (i.e. TE-Link end). As said before =
TS size is an adaptation attribute. When the TE-Link advertisement (whether=
 a TE-Link created by an FA or a TE-Link that uses a physical link) include=
s details related to TSG, it is possible for routing to validate the compat=
ibility of the endpoints with the service requested.
This has nothing to do with point c of your statement that would imply alwa=
ys along the path to have only one type of TS size.

Much thanks,
Lou


On 9/28/2011 8:02 AM, BELOTTI, SERGIO (SERGIO) wrote:
> Hi Lou,
>=20
> Please see in line .
>=20
> BR
>=20
> Sergio and Pietro
>=20
>=20
> -----Messaggio originale-----
> Da: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] Per conto di L=
ou Berger
> Inviato: marted=EC 27 settembre 2011 15.20
> A: CCAMP
> Oggetto: [CCAMP] Thought on where to carry G.709-v3 TSG
>=20
> All / G.709 draft authors,
>=20
> 	We have a few slightly unaligned proposals on where to indicate the
> [G.709-v3] Tributary Slot Granularity:
>=20
>=20
>=20
> 1: G-PID
>     draft-ietf-ccamp-otn-g709-info-model-01 says:
>     One possible solution is the G-PID field of the GENERALIZED LABEL
>     REQUEST Object.
>=20
> [ALU]What inserted in the INFO draft , is the result of the discussion ma=
de in July on the subject, in the mailing , taking into account suggestion =
and comments coming from John, Jonathan and others participating at the dis=
cussion.
> Our opinion is that the ending draft for signaling should be aligned to t=
he info model draft incorporating the required changes to GPID. The motivat=
ions behind our opinion can be better understood reading the other comments=
.
>=20
> 2: A new field:
>    draft-ceccarelli-ccamp-gmpls-ospf-g709-07 says:
>       - TSG: Tributary Slot Granularity (2bit): Used for the
>       advertisement of the supported Tributary Slot granularity
> [ALU] In the INFO we have explained the need also for TSG in routing (fol=
lowing conclusion of mailing list discussion) and the routing draft simply =
proposes a possible encoding of the information.
> This solution, for the sake of truth, can be getting better, taking into =
account the AutoPayloadtype flag information. This information is a typical=
 MI information , described in in G.798, and it simply tells us whether Fal=
lback procedure is enabled or not.=20
> Since this information is typically configured by the manager we do not t=
hink it has to be considered directly in the control plane (neither signale=
d or advertised ). However we have to take into account the fact that
> auto-payload type set to off generates interfaces that can support 1.25 T=
SG only.=20
>=20
> This fact can be incorporated in routing by adding a new meaning in the t=
wo bits encodings:
>=20
>          - 00 - 1.25 Gbps (AutoPayloadtype off)
>=20
>          - 01 - 1.25 Gbps (AutoPayloadType on)
>=20
>          - 10 - 2.5 Gbps=20
>=20
>          - 11 - Reserved
>=20
>=20
> 3: Implicitly:
>    draft-zhang-ccamp-gmpls-evolving-g709-09 doesn't explicitly
>    signal TSG, but rather has it implied in the new ODU label.
>=20
> [ALU] There is nothing implicitly. The reality is that at the moment sign=
aling draft does not address the problem . What you consider as "implicitly=
 deduced" is in fact the TSG granularity with which the client is mapped in=
 the server ODUk/OTUK or FA/H-LSP. What has to be clarified is that what we=
 need to signal is an adaptation information regarding what the server can =
expose to the client regarding TS granularity capability.=20
> TS size is an attribute of the adaptation used to put an ODUj into an ODU=
k.
> What you consider as implicit is just how ODUj is mapped into ODUk, but t=
he problem is to signal ODUk with the correct adaptation attribute.
>=20
> Some other alternatives include:
>=20
> 4: GMPLS Encoding
>    Currently used to indicate G.709 (which is also what the Switch
>    cap essentially indicates) An alternative would use:
>       12              G.709 ODUk (Digital Path, 2.5G)[RFC4328]
>       TBA (e.g., 15)  G.709 ODUk (Digital Path, 1.25G)
>=20
>    In routing, 15 would imply support for both 1.25 and 2.5G, as
>    support for both by 1.25 capable interfaces is required by
>    [G.709-v3]. (At least as I understand it.)
>=20
> [ALU] Encoding field should define the nature of the LSP : RFC 4328 defin=
ed two OTN new values G.709 ODUk (Digital Path) and G.709 Optical Channel. =
We do not see any reason to link encoding with information that would need =
to choose interfaces (as TSG) since the "nature " of LSP does not change de=
pendently of the usage of 1.25 or 2.5 ODUk tributary slot.
>=20
> 5: Signal Type
>    Carried in routing ISCD/SCSI and signaling traffic parameters.
>    Could enumerate all ODUx types to indicate either 1.25G or 2.5G.
>    Existing types indicate 2.5G, new types would need to be enumerated
>    for the new 1.25 and 2.5 types.  Hereto, the 1.25 types would imply
>    support for both 1.25 and 2.5 types in routing.
>=20
> [ALU] During the discussion in July the usage of Signal Type was one of t=
he first possibilities analyzed. We definitely leave out signal type for th=
e reason above regarding adaptation information.
> TS granularity is an information that server LSP has to expose to client =
LSP. What is related to the client is conveyed in the G-PID not in the Sign=
al Type .=20
> There are no different Signal Type for the same ODU in OTN: e.g. ODU2 it =
is the same , what can change is the adaptation attribute towards client (e=
.g. 1.25 or 2.5 TSG for ODU1 client).=20
>=20
> As I understand it, TSG is needed at:
>   (a) the endpoints that terminate the signal/LSP to ensure proper
>       adaptation.
>   (b) the 2nd and penultimate hops to ensure the proper
>       interface/H-LSP selection.
>   (c) Intermediate nodes for proper TS allocation.
>=20
> [ALU] Item (c) is not correct. Intermediate nodes do not need to demultip=
lex client, you can have ODU0 LSPs , that surely need to have 1,25 interfac=
es in the end points but using 2.5 TSG in the middle of the network since t=
hey have tunneled on 2.5 structured containers.=20
>=20
>=20
>=20
> It seems to me that we have enough existing fields in GMPLS (for G.709)
> that we should consider these before introducing new ones.  Of the
> existing fields, we have 1, 4 and 5.:
>=20
>    Option 1, G-PID, is really designed to support end-point client
>    adaptation, so as an end-point only field it really only supports
>    need (a), so I don't think G-PID is the right place to indicate TSG.
>=20
> [ALU] G-PID is the correct place :
>  1) It contains information related to client of an LSP that is exactly w=
hat we need.
> 2) As reported in RFC 3471 " This is used by the nodes at the endpoints o=
f the LSP, and in some cases by the penultimate hop." We are exactly in the=
se "some cases"
>=20
>    Option 4, Encoding, is used to support (a) and (b)-type checks in
>    GMPLS, but not (c).  So, while this field is definitely a better
>    place than G-PID to indicate TSG, it doesn't satisfy all the needs.
>=20
>    Option 5, Signal Type, is used to support all needs.
>=20
> [ALU] Already commented why not the right places.
>=20
> Given all this, I'd like to propose that we use Option 5, Signal Type,
> to indicate TSG, and that this be reflected in the relevant WG drafts.
> (Authors, let me know if you'd like specific text proposals.)
>=20
> Comments?
>=20
> Much thanks,
> Lou (as WG contributor)
>=20
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp
>=20
>=20
>=20
>=20

From cyril.margaria@nsn.com  Thu Sep 29 02:05:38 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D93BB21F8DAE for ; Thu, 29 Sep 2011 02:05:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.839
X-Spam-Level: 
X-Spam-Status: No, score=-4.839 tagged_above=-999 required=5 tests=[AWL=-1.305, BAYES_00=-2.599, FRT_LOLITA1=1.865, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x1Ou1IotfkBd for ; Thu, 29 Sep 2011 02:05:37 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0BD21F8CB5 for ; Thu, 29 Sep 2011 02:05:37 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p8T97ocX004575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 11:07:50 +0200
Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p8T97ku2001412; Thu, 29 Sep 2011 11:07:50 +0200
Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 29 Sep 2011 11:07:44 +0200
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, 29 Sep 2011 11:07:40 +0200
Message-ID: 
In-Reply-To: A<7AEB3D6833318045B4AE71C2C87E8E171817E09A@DFWEML501-MBX.china.huawei.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [CCAMP] FW:  I-D Action: draft-ietf-ccamp-rwa-wson-encode-12
Thread-Index: AQHMfGU421ASISnyGEauN0YmoQNTfpVjNyIggADVR7A=
References: <7AEB3D6833318045B4AE71C2C87E8E17181669D3@DFWEML501-MBX.china.huawei.com>  A<7AEB3D6833318045B4AE71C2C87E8E171817E09A@DFWEML501-MBX.china.huawei.com>
From: "Margaria, Cyril (NSN - DE/Munich)" 
To: "ext Leeyoung" , 
X-OriginalArrivalTime: 29 Sep 2011 09:07:44.0746 (UTC) FILETIME=[401144A0:01CC7E87]
Subject: Re: [CCAMP] FW:  I-D Action: draft-ietf-ccamp-rwa-wson-encode-12
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Sep 2011 09:05:39 -0000

Hi Young,=20

For point 1,4,5,7 its ok.
I updated the title BTW=20

I clarified some points inline.=20

Best Regards
Cyril

> -----Original Message-----
> From: ext Leeyoung [mailto:leeyoung@huawei.com]
> Sent: Wednesday, September 28, 2011 11:47 PM
> To: Margaria, Cyril (NSN - DE/Munich); ccamp@ietf.org
> Subject: RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-info-12.txt
>=20
> Hi Cyril,
>=20
> Thanks for your review and suggestions. It looks like there are two
> issues pending: Point #2 and #3.
> We can close the rest of the points you raised with the action
> specified in-line. Please let me know otherwise.
>=20
> Thanks.
>=20
> Young
>=20
>=20
> -----Original Message-----
> From: Margaria, Cyril (NSN - DE/Munich)
[mailto:cyril.margaria@nsn.com]
> Sent: Monday, September 26, 2011 10:59 AM
> To: Leeyoung; ccamp@ietf.org
> Subject: RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-info-12.txt
>=20
>=20
> Hi,
> I have the following comments on  draft-ietf-ccamp-rwa-wson-encode-12
> after it being updated and in light of the WG discussions:




> 2) section 3.1. Resource Block Set Field:
> RB Identifier: as stated in section "3. Resources, Blocks, Sets, and
> the
> Resource Pool", Resources and Resource Blocks are related to interface
> cards.
>=20
> GMPLS implementations are using 32-bit unnumbered interface IDs to
> identify GMPLS links and also the corresponding physical resources.
> OEO devices and, in the context of this document, resource or resource
> group can also be identified by 32-bit unnumbered interface IDs.
>=20
>  From an implementation point of view, having 16-bit resource block
IDs
> have several drawbacks because of the following points:
>   a) Mapping exists between physical resource and unnumbered interface
> IDs, this mapping is generally known by management system,
>       introducing a different ID space is not optimal (new mapping
> needed);
>   b) Those OEOs might be used as links in a multi-node model, thus
> being
> identified by a 32-bit unnumbered interface IDs, introducing another
> space is also not optimal.
>=20
> Therefore, it would be better if the resource block IDs were 32-bit
> interface IDs (to be unique within the node, not because they are
> representing links in this document).
>=20
> YOUNG>> The only motivation why we used 16 bits for RB ID is to reduce
> the space. And I think this is an internal link so it is not the real
> interface per se and thus there is no need to keep track of the state
> of RB ID like other legitimate interfaces. I don't think there is a
> substantial implementation issue here whether we use 16 bits or 32
> bits, but if there is a strong support to use 32 bit ID over 16 bit
ID,
> I am fine with this. Lou and Deborah, do you have any suggestion on
> this issue? Or other implementers?

CYRIL>> The most bothering point of having 16 bit is for management
system
 that needs to learn a new mapping between control plane resources and=20
 management plane resource. Having 32 bit ids make this more transparent
to=20
 management applications.=20

>=20
>=20
> 3) section 3.1. Resource Block Set Field Why not define a bit set
> action, similar to the label set?
>=20
> YOUNG>> Are you referring the Label Set encoding as follows from
draft-
> ietf-ccamp-general-constraint-encode-05.txt
>=20
>   0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      | Action|    Num Labels         |          Length               |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                          Base Label                           |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |     Additional fields as necessary per action                 |
>=20
>=20
> The current Resource Block Set Field is encoded as follows:
>=20
>   0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |    Action     |E|C| Reserved  |        Length
|
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |     RB Identifier 1           |        RB Identifier 2
|
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       :                               :
:
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |     RB Identifier n-1         |        RB Identifier n
|
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
> YOUNG>> Can you be specific about your suggestion? Are you concerned
> about label being 32 bit vs RB identifier being 16 bits? --- then this
> is basically related to your point #2.

CYRIL>> No, this is independent to the length of the RB identifier

> If you have other concerns,
> please spell them out (e.g., action field (4 bits vs 8 bits), etc..)
> The Num Labels field is necessary when we are indicating bit maps
> (Action =3D 4), which Is not needed for Resource Block Set; E bit is =
not
> necessary when we adopt 32 bit RB ID, but C bit is needed to indicate
> the connectivity nature of Resource Pool Accessibility.
>=20
> YOUNG>> Would the following encoding is what you are envisioning? If
> not, please suggest in detail.
>=20
>   0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       | Action|C|                     |        Length
|
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                         RB Identifier 1
|
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       :                               :
:
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                         RB Identifier n
|
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


My suggestion is to add the following text and format :=20
Action :=20
  1 - Reserved
  3 - Reserved=09
  4 - Bitmap Set

When Action is 4 (bitmap set) the format of the Resource block set is
the following (with 16 bit ids):
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Action =3D 4 |E|C| Reserved  |        Length                 =
|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     base RB Identifier        |Bit Map(Lowest numerical RB Id)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                               :                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Bit Map(Highest numerical RB Id)                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Each bit in the bit map represents a
   particular RB Id with a value of 1/0 indicating whether the RB id is
   in the set or not. Bit position zero represents the lowest RB Id and
   corresponds to the base RB identifier, while each succeeding bit
position
   represents the next RB identifier in numerical order.=20

For example=20

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Action =3D 4 |E|C| Reserved  |        Length                 =
|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     base RB Identifier =3D10    =
|1|0|1|1|0|0|0|0|1|0|1|1|0|1|0|1|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|0|0|0|1|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Correspond to the following set of RB ids:
10,12,13,18,20,21,23,25,30

With 32 bits ids :=20
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Action =3D 4 |E|C| Reserved  |        Length                 =
|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     base RB Identifier                                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Bit Map Word #1 (Lowest numerical RB Id)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                               :                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Bit Map Word #N(Highest numerical RB Id)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The previous example will be :=20
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Action =3D 4 |E|C| Reserved  |        Length                 =
|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     base RB Identifier =3D10                                    =
|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|1|1|0|0|0|0|1|0|1|1|0|1|0|1|0|0|0|0|1|0|0|0|0|0|0|0|0|0|0|0|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

General constraints encoding introduce a bitmap set for a set of IDs=20
for efficiency, this can apply to each encoding representing a set of
ids where you
can define a group/calculate ID =3D baseID + n.
=20
>=20
>=20
> 6) section 5.1. Resource Block Information Sub-TLV
>=20
> Having an Input Modulation Type List sub-sub-TLV containing a list of
> modulation formats (with an input-output bit) and an Output Modulation
> Type List sub-sub-TLV containing a list of modulation formats (with an
> input-output bit) seems redundant because the bit I already indicates
> if
> it is an output or input modulation format.
>=20
> Having a single Modulation Type List sub-sub-TLV is providing the same
> information with an efficient encoding, a single sub-sub-TLV type
> should
> be used.
>=20
> Same reasoning apply to the FEC Type List Sub-Sub-TLV.
>=20
> YOUNG>> I guess what you are suggesting is as follows:
>=20
>     0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                     RB Set Field
|
>       :
:
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |I|E|                      Reserved
|
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |           Modulation Type List Sub-Sub-TLV  (opt)
|
>       :
:
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |           FEC Type List Sub-Sub-TLV    (opt)
|
>       :
:
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |         Input Client Signal Type Sub-Sub-TLV      (opt)
|
>       :
:
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |         Input Bit Rate Range List  Sub-Sub-TLV (opt)
|
>       :
:
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |         Processing Capabilities List Sub-Sub-TLV (opt)
|
>       :
:
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
>=20
> YOUNG>> If that's what you suggested, that is fine with me. If that is
> that case, I will revise with this figure in the revision. (Closure)

This is what I mean, the logic of "if no egress FEC/Modulation is
present,=20
this is implicitly the same as the ingress FEC/Modulation". =20

This proposal do not change the format of the FEC and Modulation.

 

From cyril.margaria@nsn.com  Thu Sep 29 02:33:55 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC2621F8CF6 for ; Thu, 29 Sep 2011 02:33:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.661
X-Spam-Level: 
X-Spam-Status: No, score=-2.661 tagged_above=-999 required=5 tests=[AWL=-3.358, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3oLTdrfLfh38 for ; Thu, 29 Sep 2011 02:33:54 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 5EDA821F8CF5 for ; Thu, 29 Sep 2011 02:33:53 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p8T9aNxX022758 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 11:36:23 +0200
Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p8T9aLPo018198; Thu, 29 Sep 2011 11:36:23 +0200
Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 29 Sep 2011 11:36:22 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC7E8B.3D81107B"
Date: Thu, 29 Sep 2011 11:36:16 +0200
Message-ID: 
In-Reply-To: A
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: =?gb2312?B?ILTwuLQ6ICC08Li0OiBbQ0NBTVBdIEktRCBBY3Rpb246IGRyYWZ0LQ==?= =?gb2312?B?aWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLWNvbnN0cmFpbnRzLW9zcA==?= =?gb2312?B?Zi10ZS0wMi50eHQ=?=
Thread-Index: AQHMeQhw4fH7IgNgHEuaM0yhaE8MRpVfUxoggAGhYTmAAAbksIABGMsGgAIOXpA=
References: <20110922090626.6373.58763.idtracker@ietfa.amsl.com>   A   A
From: "Margaria, Cyril (NSN - DE/Munich)" 
To: "ext Zhangfatai" , 
X-OriginalArrivalTime: 29 Sep 2011 09:36:22.0199 (UTC) FILETIME=[3FBFCC70:01CC7E8B]
Subject: Re: [CCAMP] =?gb2312?b?tPC4tDogILTwuLQ6ICBJLUQgQWN0aW9uOiBkcmFmdC1p?= =?gb2312?b?ZXRmLWNjYW1wLWdtcGxzLWdlbmVyYWwtY29uc3RyYWludHMtb3Nw?= =?gb2312?b?Zi10ZS0wMi50eHQ=?=
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Sep 2011 09:33:55 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC7E8B.3D81107B
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable

Hi,=20

=20

If I understand correctly, you state that there is not explicit or =
implicit relationship between the ISCD and label sub-TLV, correct?

I would expect a new generic draft to be applicable to all already =
defined label format, so  it seems missing in the document.

=20

Could you consider my last point regarding the example of switching =
restriction in G.709 v2 and DWDM context, it would be helpful=20

 to have some statement even though it will not be in the document.

=20

Best Regards.

=20

=20

From: ext Zhangfatai [mailto:zhangfatai@huawei.com]=20
Sent: Wednesday, September 28, 2011 4:30 AM
To: Margaria, Cyril (NSN - DE/Munich); ccamp@ietf.org
Subject: =B4=F0=B8=B4: =B4=F0=B8=B4: [CCAMP] I-D Action: =
draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt

=20

Hi Cyril,

=20

I agree on your first suggestion.

=20

Secondly, this draft is generic, when it needs to advertise label =
information for some specific tech (e.g., TDM), the document about =
specific tech can refer to this draft and should define how to correlate =
the ISCDs and label sub-TLVs if there is no explicit or implicit =
relationship between them (I think there are lots of potential solutions =
to handle that, it is quite tech specific stuff).=20

=20

=20

Fatai

=20

Thanks

=20

=20

________________________________

=B7=A2=BC=FE=C8=CB: Margaria, Cyril (NSN - DE/Munich) =
[cyril.margaria@nsn.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA9=D4=C227=C8=D5 17:38
=B5=BD: Zhangfatai; ccamp@ietf.org
=D6=F7=CC=E2: RE: =B4=F0=B8=B4: [CCAMP] I-D Action: =
draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt

Hi,=20

=20

Thanks for the answer,=20

=20

Please see inline

=20

=20

From: ext Zhangfatai [mailto:zhangfatai@huawei.com]=20
Sent: Tuesday, September 27, 2011 11:17 AM
To: Margaria, Cyril (NSN - DE/Munich); ccamp@ietf.org
Subject: =B4=F0=B8=B4: [CCAMP] I-D Action: =
draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt

=20

Hi Cyril,

Thanks for your commets.

Please see in-line below.


Fatai

Thanks



________________________________________
=B7=A2=BC=FE=C8=CB: Margaria, Cyril (NSN - DE/Munich) =
[cyril.margaria@nsn.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA9=D4=C226=C8=D5 16:03
=B5=BD: Zhangfatai; ccamp@ietf.org
=D6=F7=CC=E2: RE: [CCAMP] I-D Action: =
draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt

Hi,

I have the following comments/question regarding this revision

3.2. Available Labels:

The text state : =A1=B0The Available Labels sub-TLV   may occur at most =
once within the link TLV.=A1=B1

How to encode different label format in that case? I think the label =
format would depend
on the ISCD, and as we might have several ISCD, having several Available =
Label sub-TLV make sense.
This also apply to 3.3. Shared Backup Labels.

[Fatai] This "may" should be "MAY" according to Lou's suggestion, so it =
does not prevent you to have several available label sub-TLVs.=20

[Cyril] Stating =A1=B0The Available Labels sub-TLV   MAY  occur more =
than once within the link TLV.=A1=B1  Would be more accurate and easier =
to understand.

=20


In case of several ISCD are present for a given advertisement how to =
interpret the label format in the
label-related sub-TLVs?


[Fatai] It is easy to achive that. e.g, in SDH network, a node can =
advertise several ISCDs with one or multiple label sub-TLVs (I assume =
"IF" label information is needed to be advertised here), why it cannot =
interpret the labels are SDH labels?

[Cyril]  If there is 2 ISCD sub-TLV and 2 available label sub-TLV, how =
to tell which available label sub-TLV relate to which ISCD sub-TLV?

=20


Could you clarify this point, it would be useful for instance to =
consider the example of a link supporting SDH
(no VC4-switching), ODU (G.709, as of RFC4328, and for the current G.709 =
v3 label format).

=20

[Fatai]  Do you mean to have an example on hybrid node? I will not use a =
complex example to explain a kind of simple thing (It will confuse =
people).=20

[Cyril] It may not be so simple, I have trouble to interpret label =
without knowing the ISCD considered and I do not see clearly the =
relation between the two in the document.


The text is very focused on WSON, while it is a very interesting =
example, having other technology (OTN for
example would help to show that the solution is generic.

[Fatai] I think one typical example is sufficient for people to =
understand things. TDM network is different from WSON network. In TDM =
network, usually it will not advertise label information even though =
label information could be advertised.

[Cyril] They are indeed different, but from label point of view it =
should not make a difference. A usual use case of connectivity matrix =
would be for example on client cards with switching restriction : fixed =
Multiplex and label assignment due to the fixed MUX (ODU2->ODU1 for =
instance)  on DWDM node :

the restriction can be modeled as one connectivity matrix per client =
port,

        the client port have then ISCD TDM,=20

        the other ports can do DWDM and TDM,=20

        for the connectivity matrix corresponding to a client port the =
only ODU label to be assigned (due to fixed MUX) is specified=20

=20

First, is this modeling correct?=20

Second, how to make sure the label restriction are to be interpreted as =
ODU labels?

=20

I think it is also important to show that the extensions are also =
working outside the framework they were born (WSON).

=20

BR



Best Regards,
Cyril

> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of ext Zhangfatai
> Sent: Thursday, September 22, 2011 11:17 AM
> To: ccamp@ietf.org
> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-
> constraints-ospf-te-02.txt
>
> Hi CCAMPers,
>
> A new version has been submitted to address the comments from the WG
> discussion.
>
> We accepted Acee and Young's suggestion to introduce a new top-level
> node TLV (Generic Node Attribute TLV) to simplify things and a new
> section (Section 5) was added to describe scalability issue.
>
> More information from: http://www.ietf.org/id/draft-ietf-ccamp-gmpls-
> general-constraints-ospf-te-02.txt
>
> Please check out for details and comments are always welcome.
>
>
> Thanks
>
> Fatai
>
>
> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of internet-drafts@ietf.org
> Sent: 2011=C4=EA9=D4=C222=C8=D5 17:06
> To: i-d-announce@ietf.org
> Cc: ccamp@ietf.org
> Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-
> constraints-ospf-te-02.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Common Control and
> Measurement Plane Working Group of the IETF.
>
>       Title           : OSPF-TE Extensions for General Network Element
> Constraints
>       Author(s)       : Fatai Zhang
>                           Young Lee
>                           Jianrui Han
>                           Greg Bernstein
>                           Yunbin Xu
>       Filename        : draft-ietf-ccamp-gmpls-general-constraints-
> ospf-te-02.txt
>       Pages           : 14
>       Date            : 2011-09-22
>
>    Generalized Multiprotocol Label Switching can be used to control a
>    wide variety of technologies including packet switching (e.g.,
> MPLS),
>    time-division (e.g., SONET/SDH, OTN), wavelength (lambdas), and
>    spatial switching (e.g., incoming port or fiber to outgoing port or
>    fiber). 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 describes OSPF routing protocol extensions
> to
>    support these kinds of constraints under the control of Generalized
>    MPLS (GMPLS).
>
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-general-
> constraints-ospf-te-02.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-general-
> constraints-ospf-te-02.txt
> _______________________________________________
> 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


------_=_NextPart_001_01CC7E8B.3D81107B
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable


Hi, 
 
If I understand correctly, you state that there is not explicit or =
implicit relationship between the ISCD and label sub-TLV, =
correct?
I would expect a new generic draft to be applicable to all already =
defined label format, so  it seems missing in the =
document.
 
Could you consider my last point regarding the example of switching =
restriction in G.709 v2 and DWDM context, it would be helpful =

 to have some statement even though it will not be in the =
document.
 
Best Regards.
 
 
From:=
 =
ext Zhangfatai [mailto:zhangfatai@huawei.com] 
Sent: =
Wednesday, September 28, 2011 4:30 AM
To: Margaria, Cyril (NSN =
- DE/Munich); ccamp@ietf.org
Subject: =B4=F0=B8=B4: =
=B4=F0=B8=B4: [CCAMP] =
I-D Action: =
draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt
 
=
Hi Cyril,
=
 
=
I agree on your first suggestion.
=
 
=
Secondly, this draft is generic, when it needs to advertise label =
information for some specific tech (e.g., TDM), the document =
about specific tech can refer to this draft and should =
define how to correlate the ISCDs and label sub-TLVs if there is =
no explicit or implicit relationship between them (I =
think there are lots of potential solutions to handle that, it is quite =
tech specific stuff). 
=
 
=
 
=
Fatai
=
 
=
Thanks
=
 
=
 
=B7=A2=BC=FE=C8=CB=
:=
 Margaria, Cyril (NSN - DE/Munich) =
[cyril.margaria@nsn.com]
=B7=A2=CB=CD=CA=B1=BC=E4=
:=
 2011=C4=EA=
9=D4=C2=
27=C8=D5=
 17:38
=B5=BD=
:=
 Zhangfatai; ccamp@ietf.org
=D6=F7=CC=E2=
:=
 RE: =B4=F0=B8=B4=
: [CCAMP] I-D Action: =
draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt
Hi, 
 
Thanks for the answer, 
 
Please see inline
 
 
=
From:=
 ext Zhangfatai [mailto:zhangfatai@huawei.com] 
Sent: Tuesday, =
September 27, 2011 11:17 AM
To: Margaria, Cyril (NSN - =
DE/Munich); ccamp@ietf.org
Subject: =B4=F0=B8=B4=
: [CCAMP] I-D Action: =
draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt
 
=
Hi Cyril,

Thanks for your commets.

Please see in-line =
below.


Fatai

Thanks



____________________=
____________________
=B7=A2=BC=FE=C8=CB=
: Margaria, Cyril (NSN - DE/Munich) =
[cyril.margaria@nsn.com]
=B7=A2=CB=CD=CA=B1=BC=E4=
: 2011=C4=EA=
9=D4=C2=
26=C8=D5=
 16:03
=B5=BD=
: Zhangfatai; ccamp@ietf.org
=D6=F7=CC=E2=
: RE: [CCAMP] I-D Action: =
draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt

Hi,
<=
br>I have the following comments/question regarding this =
revision

3.2. Available Labels:

The text state : =A1=B0The =
Available Labels sub-TLV   may occur at most once within the =
link TLV.=A1=B1

How to encode different label format in that =
case? I think the label format would depend
on the ISCD, and as we =
might have several ISCD, having several Available Label sub-TLV make =
sense.
This also apply to 3.3. Shared Backup =
Labels.

[=
Fatai] This "may" should be "MAY" according to Lou's =
suggestion, so it does not prevent you to have several available label =
sub-TLVs. 
[Cyril] Stating =A1=B0The Available Labels sub-TLV   MAY =
 occur more than once within the link TLV.=A1=B1  Would be =
more accurate and easier to understand.
 
=

In case of several ISCD are present for a given advertisement how to =
interpret the label format in the
label-related sub-TLVs?
=

[=
Fatai] It is easy to achive that. e.g, in SDH network, a node can =
advertise several ISCDs with one or multiple label sub-TLVs (I =
assume "IF" label information is needed to be advertised =
here), why it cannot interpret the labels are SDH labels?
[Cyril]  If there is 2 ISCD sub-TLV and 2 available label =
sub-TLV, how to tell which available label sub-TLV relate to which ISCD =
sub-TLV?
 
=

Could you clarify this point, it would be useful for instance to =
consider the example of a link supporting SDH
(no VC4-switching), ODU =
(G.709, as of RFC4328, and for the current G.709 v3 label =
format).
 
[=
Fatai]  Do you mean to have an example on hybrid node? I will =
not use a complex example to explain a kind of =
simple thing (It will confuse people). 
[Cyril] It may not be so simple, I have trouble to interpret label =
without knowing the ISCD considered and I do not see clearly the =
relation between the two in the document.
=

The text is very focused on WSON, while it is a very interesting =
example, having other technology (OTN for
example would help to show =
that the solution is generic.
[=
Fatai] I think one typical example is sufficient for people to =
understand things. TDM network is different from WSON network. In =
TDM network, usually it will not advertise label information even though =
label information could be advertised.
[Cyril] They are indeed different, but from label point of view it =
should not make a difference. A usual use case of connectivity matrix =
would be for example on client cards with switching restriction : fixed =
Multiplex and label assignment due to the fixed MUX (ODU2->ODU1 for =
instance)  on DWDM node :
the restriction can be modeled as one connectivity matrix per client =
port,
        the client port have then =
ISCD TDM, 
        the other ports can do =
DWDM and TDM, 
        for the connectivity =
matrix corresponding to a client port the only ODU label to be assigned =
(due to fixed MUX) is specified 
 
First, is this modeling correct? 
Second, how to make sure the label restriction are to be interpreted =
as ODU labels?
 
I think it is also important to show that the extensions are also =
working outside the framework they were born (WSON).
 
BR
=


Best Regards,
Cyril

> -----Original =
Message-----
> From: ccamp-bounces@ietf.org =
[mailto:ccamp-bounces@ietf.org] On Behalf
> Of ext =
Zhangfatai
> Sent: Thursday, September 22, 2011 11:17 AM
> =
To: ccamp@ietf.org
> Subject: Re: [CCAMP] I-D Action: =
draft-ietf-ccamp-gmpls-general-
> =
constraints-ospf-te-02.txt
>
> Hi CCAMPers,
>
> =
A new version has been submitted to address the comments from the =
WG
> discussion.
>
> We accepted Acee and Young's =
suggestion to introduce a new top-level
> node TLV (Generic Node =
Attribute TLV) to simplify things and a new
> section (Section 5) =
was added to describe scalability issue.
>
> More =
information from: http://www.ietf.org/id/draft-ietf-ccamp-gmpls-
> =
general-constraints-ospf-te-02.txt
>
> Please check out for =
details and comments are always welcome.
>
>
> =
Thanks
>
> Fatai
>
>
> -----Original =
Message-----
> From: ccamp-bounces@ietf.org =
[mailto:ccamp-bounces@ietf.org] On Behalf
> Of =
internet-drafts@ietf.org
> Sent: 2011=C4=EA=
9=D4=C2=
22=C8=D5=
 17:06
> To: i-d-announce@ietf.org
> Cc: =
ccamp@ietf.org
> Subject: [CCAMP] I-D Action: =
draft-ietf-ccamp-gmpls-general-
> =
constraints-ospf-te-02.txt
>
> A New Internet-Draft is =
available from the on-line Internet-Drafts
> directories. This =
draft is a work item of the Common Control and
> Measurement Plane =
Working Group of the =
IETF.
>
>       =
Title           : =
OSPF-TE Extensions for General Network Element
> =
Constraints
>       =
Author(s)       : Fatai =
Zhang
>          =
            &=
nbsp;    Young =
Lee
>          &n=
bsp;           &nb=
sp;    Jianrui =
Han
>          &n=
bsp;           &nb=
sp;    Greg =
Bernstein
>         &n=
bsp;           &nb=
sp;     Yunbin =
Xu
>       =
Filename        : =
draft-ietf-ccamp-gmpls-general-constraints-
> =
ospf-te-02.txt
>       =
Pages           : =
14
>       =
Date            : =
2011-09-22
>
>    Generalized Multiprotocol =
Label Switching can be used to control a
>    wide =
variety of technologies including packet switching (e.g.,
> =
MPLS),
>    time-division (e.g., SONET/SDH, OTN), =
wavelength (lambdas), and
>    spatial switching =
(e.g., incoming port or fiber to outgoing port =
or
>    fiber). 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 describes =
OSPF routing protocol extensions
> to
>    =
support these kinds of constraints under the control of =
Generalized
>    MPLS =
(GMPLS).
>
>
>
> A URL for this Internet-Draft =
is:
> =
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-general-
&g=
t; constraints-ospf-te-02.txt
>
> Internet-Drafts are also =
available by anonymous FTP at:
> =
ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft =
can be retrieved at:
> =
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-general-
>=
; constraints-ospf-te-02.txt
> =
_______________________________________________
> 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

------_=_NextPart_001_01CC7E8B.3D81107B--

From cyril.margaria@nsn.com  Thu Sep 29 02:46:58 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEFDC21F86F6 for ; Thu, 29 Sep 2011 02:46:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.157
X-Spam-Level: 
X-Spam-Status: No, score=-6.157 tagged_above=-999 required=5 tests=[AWL=0.442,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5rTSQMvfZy3h for ; Thu, 29 Sep 2011 02:46:58 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id A4DAA21F84DA for ; Thu, 29 Sep 2011 02:46:57 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p8T9nSdb026807 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 11:49:29 +0200
Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p8T9nN21024352; Thu, 29 Sep 2011 11:49:28 +0200
Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 29 Sep 2011 11:49:27 +0200
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, 29 Sep 2011 11:49:26 +0200
Message-ID: 
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E17181669D3@DFWEML501-MBX.china.huawei.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [CCAMP] FW:  I-D Action: draft-ietf-ccamp-rwa-info-12.txt
Thread-Index: AQHMbzaIDI6/KZa+pUuuGsK1nP8d9ZVFjvuQgB6rF2A=
References: <7AEB3D6833318045B4AE71C2C87E8E17181669D3@DFWEML501-MBX.china.huawei.com>
From: "Margaria, Cyril (NSN - DE/Munich)" 
To: "ext Leeyoung" , 
X-OriginalArrivalTime: 29 Sep 2011 09:49:27.0547 (UTC) FILETIME=[13DA64B0:01CC7E8D]
Subject: Re: [CCAMP] FW:  I-D Action: draft-ietf-ccamp-rwa-info-12.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Sep 2011 09:46:59 -0000

Hi,=20


I have the following comments/question regarding the document
draft-ietf-ccamp-rwa-info-12:

1) Section 5:
The paragraph
"A resource block may contain one or more resources.
   As resource blocks are the smallest identifiable unit of processing
   resource, one can group together resources into blocks if they have
   similar characteristics relevant to the optical system being modeled,
   e.g., processing properties, accessibility, etc."

It's a bit confusing to me, from the previous paragraph I understand
that a resource can be :=20
- One regenerator
- One wavelength converter
- One OEO
In summary one resource can process one signal/Label.

>From this I would understand that the resource (not the resource group)
is=20
the smallest identifiable unit of signal processing and in the
information model=20
we do only need to address the resource block because all resources
within that group=20
are equivalent.

In that case the following change would be maybe more understandable

"A resource block may contain one or more resources.
 As resources are the smallest identifiable unit of signal processing,
 one can group together resources into blocks if they have
 similar characteristics relevant to the optical system being modeled,
e.g., processing properties, accessibility, etc.

For routing the information model identifies the resource block because
all resources in the resource block  are equivalent.
"


2) Section 5.2.
  Change the definitions as  follow (according to the encoding):
 ::=3D ([] 
   [] )*

 ::=3D  []
   [] [] []

 :=3D  []
   []

 ::=3D []
   [][][]


3) 5.3.6. Processing Capability List
  As previous comment :=20
 ::=3D []
   [][][]

4) 5.3.6. Processing Capability List=09
  The document state :=20
"The processing capability list sub-TLV is a list of processing
  functions that the WSON network element (NE) can perform on the
signal including:"

I think this is mixing signal processing capabilities and resource block
configuration,
The following text would be more accurate:
"The processing capability list contain the list of processing
   capabilities that the identified resources can perform on the  signal
and the number of those resources"

As the list contains the capabilities of the resources and their maximum
number. Maybe a statement why the maximum number of resource is
considered in the capabilities rather than the state would help clarify.

5) Section 5.3.1. Shared Input or Output Indication:
  Indentation is not correct

6) Section 5.3.1. Shared Input or Output Indication:
  The following text could be added : "This is similar to the Link Label
Exclusivity restriction"

7) Section   6.6. Port Label (Wavelength) Restrictions
   The Label are not only applicable to Wavelength label, removing  the
Wavelength from the title section would make this more clear.
The section mention only wavelengths but is generally applicable (For
instance in OTN with fixed multiplex structure), wavelength should
always be in parenthesis.

>From the information model it is implicit that label restriction coming
from the connectivity matrix are reflected on all the links connected to
this matrix. Making this explicit would help the document to be more
clear. Another possibility would be to add this information to the
connectivity matrix encoding itself, as it is static.



> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of ext Leeyoung
> Sent: Friday, September 09, 2011 11:30 PM
> To: ccamp@ietf.org
> Subject: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-info-12.txt
>=20
> Hi,
>=20
> This update (version 12) includes the following:
>=20
> (i) Replaced all instances of "ingress" with "input" and all instances
> of "egress" with "output".
> (ii) Added clarifying text on relationship between resource block
model
> and physical entities such as line cards.
>=20
> This draft is now very mature and incorporated all the comments raised
> in the mailing list and the last meetings.
>=20
> Thanks,
> Young
>=20
> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of internet-drafts@ietf.org
> Sent: Friday, September 09, 2011 4:20 PM
> To: i-d-announce@ietf.org
> Cc: ccamp@ietf.org
> Subject: [CCAMP] I-D Action: draft-ietf-ccamp-rwa-info-12.txt
>=20
> 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.
>=20
> 	Title           : Routing and Wavelength Assignment Information
> Model for Wavelength Switched Optical Networks
> 	Author(s)       : Young Lee
>                           Greg M. Bernstein
>                           Dan Li
>                           Wataru Imajuku
> 	Filename        : draft-ietf-ccamp-rwa-info-12.txt
> 	Pages           : 27
> 	Date            : 2011-09-09
>=20
>    This document provides a model of information needed by the routing
>    and wavelength assignment (RWA) process in wavelength switched
>    optical networks (WSONs).  The purpose of the information described
>    in this model is to facilitate constrained lightpath computation in
>    WSONs. This model takes into account compatibility constraints
>    between WSON signal attributes and network elements but does not
>    include constraints due to optical impairments. Aspects of this
>    information that may be of use to other technologies utilizing a
>    GMPLS control plane are discussed.
>=20
>=20
>=20
>=20
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-12.txt
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-rwa-info-12.txt
> _______________________________________________
> 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 cyril.margaria@nsn.com  Thu Sep 29 02:53:02 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41DEA21F8CDC for ; Thu, 29 Sep 2011 02:53:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.176
X-Spam-Level: 
X-Spam-Status: No, score=-6.176 tagged_above=-999 required=5 tests=[AWL=0.423,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vx4Eg+c9wKCA for ; Thu, 29 Sep 2011 02:53:01 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 72A6D21F8CD7 for ; Thu, 29 Sep 2011 02:53:01 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p8T9tjbH011627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 11:55:45 +0200
Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p8T9tdVx023054; Thu, 29 Sep 2011 11:55:45 +0200
Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 29 Sep 2011 11:55:43 +0200
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, 29 Sep 2011 11:55:42 +0200
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [CCAMP] FW:  I-D Action: draft-ietf-ccamp-rwa-info-12.txt
Thread-Index: AQHMfGU421ASISnyGEauN0YmoQNTfpVjNyIggADAUzCAACopAA==
References: <7AEB3D6833318045B4AE71C2C87E8E17181669D3@DFWEML501-MBX.china.huawei.com> <7AEB3D6833318045B4AE71C2C87E8E171817E09A@DFWEML501-MBX.china.huawei.com> 
From: "Margaria, Cyril (NSN - DE/Munich)" 
To: "ext PELOSO, PIERRE (PIERRE)" , "Leeyoung" , 
X-OriginalArrivalTime: 29 Sep 2011 09:55:43.0901 (UTC) FILETIME=[F42D74D0:01CC7E8D]
Subject: Re: [CCAMP] FW:  I-D Action: draft-ietf-ccamp-rwa-info-12.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Sep 2011 09:53:02 -0000

Hi Young, Pierre=20

Please see inline,=20

BR,
 Cyril



>=20
> 6) section 5.1. Resource Block Information Sub-TLV
>=20
> Having an Input Modulation Type List sub-sub-TLV containing a list of
> modulation formats (with an input-output bit) and an Output Modulation
> Type List sub-sub-TLV containing a list of modulation formats (with an
> input-output bit) seems redundant because the bit I already indicates
> if it is an output or input modulation format.
>=20
> Having a single Modulation Type List sub-sub-TLV is providing the same
> information with an efficient encoding, a single sub-sub-TLV type
> should be used.
>=20
> Same reasoning apply to the FEC Type List Sub-Sub-TLV.
>=20
> YOUNG>> I guess what you are suggesting is as follows:
>=20
>     0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                     RB Set Field
|
>       :
:
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |I|E|                      Reserved
|
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |           Modulation Type List Sub-Sub-TLV  (opt)
|
>       :
:
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |           FEC Type List Sub-Sub-TLV    (opt)
|
>       :
:
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |         Input Client Signal Type Sub-Sub-TLV      (opt)
|
>       :
:
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |         Input Bit Rate Range List  Sub-Sub-TLV (opt)
|
>       :
:
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |         Processing Capabilities List Sub-Sub-TLV (opt)
|
>       :
:
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
>=20
> YOUNG>> If that's what you suggested, that is fine with me. If that is
> YOUNG>> that case, I will revise with this figure in the revision.
> YOUNG>> (Closure)
>=20
> PIERRE>> Actually Young, I take the modification proposed is slightly
> diffrent it is more to have an I and E bits directly inside each of
the
> Modulation Type and each of the FEC type field.
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |S|I|E|    Modulation ID        |          Length               |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20
> I bit set to 1 states that the modulation is valid as ingress E bit
set
> to 1 states that the modulation is valid as egress
>=20
> The same for the FEC type list.
>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |S|I|E|       FEC ID            |          Length               |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>=20

Cyril>> As stated in the other response, this proposal of having a bit
 for Ingress and Egress is another proposal, also interesting but it
 checked against the signaling document.=20
 It possible to keep the FEC and Modulation Type as existing and use
well=20
 defined processing rules=20
=20

BR



From zhangfatai@huawei.com  Thu Sep 29 03:18:05 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22AD321F8C8A for ; Thu, 29 Sep 2011 03:18:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.708
X-Spam-Level: 
X-Spam-Status: No, score=-0.708 tagged_above=-999 required=5 tests=[AWL=-3.158, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVgeuMVvkNtF for ; Thu, 29 Sep 2011 03:18:03 -0700 (PDT)
Received: from szxga04-in.huawei.com (szxga04-in.huawei.com [119.145.14.67]) by ietfa.amsl.com (Postfix) with ESMTP id 048A121F8C82 for ; Thu, 29 Sep 2011 03:18:03 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSA006O64OQPD@szxga04-in.huawei.com> for ccamp@ietf.org; Thu, 29 Sep 2011 18:19:38 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSA00L624OCA9@szxga04-in.huawei.com> for ccamp@ietf.org; Thu, 29 Sep 2011 18:19:38 +0800 (CST)
Received: from szxeml202-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id ADZ59205; Thu, 29 Sep 2011 18:19:38 +0800
Received: from SZXEML408-HUB.china.huawei.com (10.82.67.95) by szxeml202-edg.china.huawei.com (172.24.2.42) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 29 Sep 2011 18:19:28 +0800
Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.142]) by szxeml408-hub.china.huawei.com ([10.82.67.95]) with mapi id 14.01.0270.001; Thu, 29 Sep 2011 18:19:27 +0800
Date: Thu, 29 Sep 2011 10:19:26 +0000
From: Zhangfatai 
In-reply-to: 
X-Originating-IP: [172.24.2.40]
To: "Margaria, Cyril (NSN - DE/Munich)" , "ccamp@ietf.org" 
Message-id: 
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_kywcaBB42AnxZAaG/2P9CQ)"
Content-language: zh-CN
Accept-Language: zh-CN, en-US
Thread-topic: =?gb2312?B?ILTwuLQ6ICC08Li0OiBbQ0NBTVBdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYt?= =?gb2312?Q?ccamp-gmpls-general-constraints-ospf-te-02.txt?=
Thread-index: AQHMeQhw4fH7IgNgHEuaM0yhaE8MRpVfUxoggAGhYTmAAAbksIABGMsGgAIOXpCAAAelMA==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <20110922090626.6373.58763.idtracker@ietfa.amsl.com>   A   A  
Subject: [CCAMP] =?gb2312?b?tPC4tDogILTwuLQ6ICC08Li0OiAgSS1EIEFjdGlvbjog?= =?gb2312?b?ZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLWNvbnN0cmFpbnRzLW9z?= =?gb2312?b?cGYtdGUtMDIudHh0?=
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Sep 2011 10:18:05 -0000

--Boundary_(ID_kywcaBB42AnxZAaG/2P9CQ)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: base64

SGkgQ3lyaWwsDQoNCg0KDQpVc3VhbGx5LCBvbmUgVEUgbGluayBhZHZlcnRpc2VtZW50ICh3aXRo
IHNlcnZlcmFsIElTQ0RzIGFuZCBtdWx0aXBsZSBsYWJlbCBzdWItVExWcykgaGFzIHRoZSBzYW1l
IFN3aXRjaGluZyBDYXBhYmlsaXR5LCBzbyB0aGVyZSBpcyBpbXBsaWNpdCByZWxhdGlvbnNoaXAg
YmV0d2VlbiB0aGUgSVNDRHMgYW5kIGxhYmVsIHN1Yi1UTFZzLg0KDQoNCg0KSSB3b3VsZCBsaWtl
IHRvIGNvbnNpZGVyIHlvdXIgbGFzdCBwb2ludCB3aGVuIEkgdWRwYXRlIHRoaXMgZHJhZnQgaW4g
dGhlIG5leHQgdmVyc2lvbi4NCg0KDQoNCkJ1dCBJIGhhdmUgYSBxdWVzdGlvbiBvbiB5b3VyIGV4
YW1wbGUsIGRvIHlvdSBzZWUgdGhhdCB0aGVyZSBpcyBhIGxpbmUgcG9ydCAob3IgaW50ZXJmYWNl
KSBjYW4gc3VwcG9ydCBib3RoIERXRE0gYW5kIFRETSBpbiB0aGUgd29ybGQ/IEkgdGhpbmsgaWYg
YSBsaW5lIHBvcnQgY2FuIHN1cHBvcnQgRFdETSwgdGhlIFdTT04gVEUgbGluayAod2l0aCBXU09O
IHJlbGF0ZWQgbGFiZWwgKHdhdmVsZW5ndGgpIGluZm9ybWF0aW9uKSBzaG91bGQgYmUgYWR2ZXJ0
aXNlZCBmb3IgdGhpcyBsaW5lIHBvcnQ7IGlmIGEgbGluZSBwb3J0IGNhbiBzdXBwb3J0IFRETSwg
dGhlbiB0aGUgVERNIFRFIGxpbmsgKGUuZy4sIE9EVSkgZm9yIHRoaXMgbGluZSBwb3J0IHNob3Vs
ZCBiZSBhZHZlcnRpc2VkLiBFdmVuIHRob3VnaCB0aGVyZSB3YXMgb25lIHBvcnQgY291bGQgc3Vw
cG9ydCBib3RoIERXRE0gYW5kIFRETSwgSSB0aGluayB1c3VhbGx5IGl0IHNob3VsZCBhZHZlcnRp
c2UgdGhlc2UgdHdvIHR5cGVzIG9mIGNhcGFiaWxpdHkgc2VwYXJhdGVseSwgaWUuLCB1c2Ugc2Vw
ZXJhdGUgVEUgbGluayBhZHZlcnRpc2VtZW50cy4gc28sIEkgdGhpbmsgdGhlcmUgaXMgaW1wbGlj
aXQgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIElTQ0RzIGFuZCBsYWJlbCBzdWItVExWcy4NCg0K
DQoNCkV2ZW4gdGhvdWdoIEkgdGhpbmsgd2Ugc2hvdWxkIG5vdCB1c2UgYSBraW5kIG9mIHNwZWNp
YWwgYW5kIGNvbXBsZXggZXhhbXBsZSB0byBleHBsYWluIHNvbWV0aGluZywgSSB3aWxsIGJlYXIg
eW91ciBleGFtcGxlIGluIG15IG1pbmQgd2hlbiBJIHVwZGF0ZSB0aGUgZHJhZnQgKGFzIEkgc2Fp
ZCBpbiB0aGUgc2Vjb25kIHNlbnRlbmNlIGFib3ZlKS4NCg0KDQoNClRoYW5rcw0KDQoNCg0KRmF0
YWkNCg0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBN
YXJnYXJpYSwgQ3lyaWwgKE5TTiAtIERFL011bmljaCkgW2N5cmlsLm1hcmdhcmlhQG5zbi5jb21d
DQq3osvNyrG85DogMjAxMcTqOdTCMjnI1SAxNzozNg0Ktb06IFpoYW5nZmF0YWk7IGNjYW1wQGll
dGYub3JnDQrW98ziOiBSRTogtPC4tDogtPC4tDogW0NDQU1QXSBJLUQgQWN0aW9uOiBkcmFmdC1p
ZXRmLWNjYW1wLWdtcGxzLWdlbmVyYWwtY29uc3RyYWludHMtb3NwZi10ZS0wMi50eHQNCg0KSGks
DQoNCklmIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHksIHlvdSBzdGF0ZSB0aGF0IHRoZXJlIGlzIG5v
dCBleHBsaWNpdCBvciBpbXBsaWNpdCByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aGUgSVNDRCBhbmQg
bGFiZWwgc3ViLVRMViwgY29ycmVjdD8NCkkgd291bGQgZXhwZWN0IGEgbmV3IGdlbmVyaWMgZHJh
ZnQgdG8gYmUgYXBwbGljYWJsZSB0byBhbGwgYWxyZWFkeSBkZWZpbmVkIGxhYmVsIGZvcm1hdCwg
c28gIGl0IHNlZW1zIG1pc3NpbmcgaW4gdGhlIGRvY3VtZW50Lg0KDQpDb3VsZCB5b3UgY29uc2lk
ZXIgbXkgbGFzdCBwb2ludCByZWdhcmRpbmcgdGhlIGV4YW1wbGUgb2Ygc3dpdGNoaW5nIHJlc3Ry
aWN0aW9uIGluIEcuNzA5IHYyIGFuZCBEV0RNIGNvbnRleHQsIGl0IHdvdWxkIGJlIGhlbHBmdWwN
CiB0byBoYXZlIHNvbWUgc3RhdGVtZW50IGV2ZW4gdGhvdWdoIGl0IHdpbGwgbm90IGJlIGluIHRo
ZSBkb2N1bWVudC4NCg0KQmVzdCBSZWdhcmRzLg0KDQoNCkZyb206IGV4dCBaaGFuZ2ZhdGFpIFtt
YWlsdG86emhhbmdmYXRhaUBodWF3ZWkuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIg
MjgsIDIwMTEgNDozMCBBTQ0KVG86IE1hcmdhcmlhLCBDeXJpbCAoTlNOIC0gREUvTXVuaWNoKTsg
Y2NhbXBAaWV0Zi5vcmcNClN1YmplY3Q6ILTwuLQ6ILTwuLQ6IFtDQ0FNUF0gSS1EIEFjdGlvbjog
ZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLWNvbnN0cmFpbnRzLW9zcGYtdGUtMDIudHh0
DQoNCg0KSGkgQ3lyaWwsDQoNCg0KDQpJIGFncmVlIG9uIHlvdXIgZmlyc3Qgc3VnZ2VzdGlvbi4N
Cg0KDQoNClNlY29uZGx5LCB0aGlzIGRyYWZ0IGlzIGdlbmVyaWMsIHdoZW4gaXQgbmVlZHMgdG8g
YWR2ZXJ0aXNlIGxhYmVsIGluZm9ybWF0aW9uIGZvciBzb21lIHNwZWNpZmljIHRlY2ggKGUuZy4s
IFRETSksIHRoZSBkb2N1bWVudCBhYm91dCBzcGVjaWZpYyB0ZWNoIGNhbiByZWZlciB0byB0aGlz
IGRyYWZ0IGFuZCBzaG91bGQgZGVmaW5lIGhvdyB0byBjb3JyZWxhdGUgdGhlIElTQ0RzIGFuZCBs
YWJlbCBzdWItVExWcyBpZiB0aGVyZSBpcyBubyBleHBsaWNpdCBvciBpbXBsaWNpdCByZWxhdGlv
bnNoaXAgYmV0d2VlbiB0aGVtIChJIHRoaW5rIHRoZXJlIGFyZSBsb3RzIG9mIHBvdGVudGlhbCBz
b2x1dGlvbnMgdG8gaGFuZGxlIHRoYXQsIGl0IGlzIHF1aXRlIHRlY2ggc3BlY2lmaWMgc3R1ZmYp
Lg0KDQoNCg0KDQoNCkZhdGFpDQoNCg0KDQpUaGFua3MNCg0KDQoNCg0KDQpfX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0Kt6K8/sjLOiBNYXJnYXJpYSwgQ3lyaWwgKE5TTiAtIERFL011
bmljaCkgW2N5cmlsLm1hcmdhcmlhQG5zbi5jb21dDQq3osvNyrG85DogMjAxMcTqOdTCMjfI1SAx
NzozOA0Ktb06IFpoYW5nZmF0YWk7IGNjYW1wQGlldGYub3JnDQrW98ziOiBSRTogtPC4tDogW0ND
QU1QXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWdlbmVyYWwtY29uc3RyYWlu
dHMtb3NwZi10ZS0wMi50eHQNCkhpLA0KDQpUaGFua3MgZm9yIHRoZSBhbnN3ZXIsDQoNClBsZWFz
ZSBzZWUgaW5saW5lDQoNCg0KRnJvbTogZXh0IFpoYW5nZmF0YWkgW21haWx0bzp6aGFuZ2ZhdGFp
QGh1YXdlaS5jb21dDQpTZW50OiBUdWVzZGF5LCBTZXB0ZW1iZXIgMjcsIDIwMTEgMTE6MTcgQU0N
ClRvOiBNYXJnYXJpYSwgQ3lyaWwgKE5TTiAtIERFL011bmljaCk7IGNjYW1wQGlldGYub3JnDQpT
dWJqZWN0OiC08Li0OiBbQ0NBTVBdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMt
Z2VuZXJhbC1jb25zdHJhaW50cy1vc3BmLXRlLTAyLnR4dA0KDQoNCkhpIEN5cmlsLA0KDQpUaGFu
a3MgZm9yIHlvdXIgY29tbWV0cy4NCg0KUGxlYXNlIHNlZSBpbi1saW5lIGJlbG93Lg0KDQoNCkZh
dGFpDQoNClRoYW5rcw0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXw0Kt6K8/sjLOiBNYXJnYXJpYSwgQ3lyaWwgKE5TTiAtIERFL011bmljaCkgW2N5cmlsLm1h
cmdhcmlhQG5zbi5jb21dDQq3osvNyrG85DogMjAxMcTqOdTCMjbI1SAxNjowMw0Ktb06IFpoYW5n
ZmF0YWk7IGNjYW1wQGlldGYub3JnDQrW98ziOiBSRTogW0NDQU1QXSBJLUQgQWN0aW9uOiBkcmFm
dC1pZXRmLWNjYW1wLWdtcGxzLWdlbmVyYWwtY29uc3RyYWludHMtb3NwZi10ZS0wMi50eHQNCg0K
SGksDQoNCkkgaGF2ZSB0aGUgZm9sbG93aW5nIGNvbW1lbnRzL3F1ZXN0aW9uIHJlZ2FyZGluZyB0
aGlzIHJldmlzaW9uDQoNCjMuMi4gQXZhaWxhYmxlIExhYmVsczoNCg0KVGhlIHRleHQgc3RhdGUg
OiChsFRoZSBBdmFpbGFibGUgTGFiZWxzIHN1Yi1UTFYgICBtYXkgb2NjdXIgYXQgbW9zdCBvbmNl
IHdpdGhpbiB0aGUgbGluayBUTFYuobENCg0KSG93IHRvIGVuY29kZSBkaWZmZXJlbnQgbGFiZWwg
Zm9ybWF0IGluIHRoYXQgY2FzZT8gSSB0aGluayB0aGUgbGFiZWwgZm9ybWF0IHdvdWxkIGRlcGVu
ZA0Kb24gdGhlIElTQ0QsIGFuZCBhcyB3ZSBtaWdodCBoYXZlIHNldmVyYWwgSVNDRCwgaGF2aW5n
IHNldmVyYWwgQXZhaWxhYmxlIExhYmVsIHN1Yi1UTFYgbWFrZSBzZW5zZS4NClRoaXMgYWxzbyBh
cHBseSB0byAzLjMuIFNoYXJlZCBCYWNrdXAgTGFiZWxzLg0KDQpbRmF0YWldIFRoaXMgIm1heSIg
c2hvdWxkIGJlICJNQVkiIGFjY29yZGluZyB0byBMb3UncyBzdWdnZXN0aW9uLCBzbyBpdCBkb2Vz
IG5vdCBwcmV2ZW50IHlvdSB0byBoYXZlIHNldmVyYWwgYXZhaWxhYmxlIGxhYmVsIHN1Yi1UTFZz
Lg0KDQpbQ3lyaWxdIFN0YXRpbmcgobBUaGUgQXZhaWxhYmxlIExhYmVscyBzdWItVExWICAgTUFZ
ICBvY2N1ciBtb3JlIHRoYW4gb25jZSB3aXRoaW4gdGhlIGxpbmsgVExWLqGxICBXb3VsZCBiZSBt
b3JlIGFjY3VyYXRlIGFuZCBlYXNpZXIgdG8gdW5kZXJzdGFuZC4NCg0KDQoNCkluIGNhc2Ugb2Yg
c2V2ZXJhbCBJU0NEIGFyZSBwcmVzZW50IGZvciBhIGdpdmVuIGFkdmVydGlzZW1lbnQgaG93IHRv
IGludGVycHJldCB0aGUgbGFiZWwgZm9ybWF0IGluIHRoZQ0KbGFiZWwtcmVsYXRlZCBzdWItVExW
cz8NCg0KW0ZhdGFpXSBJdCBpcyBlYXN5IHRvIGFjaGl2ZSB0aGF0LiBlLmcsIGluIFNESCBuZXR3
b3JrLCBhIG5vZGUgY2FuIGFkdmVydGlzZSBzZXZlcmFsIElTQ0RzIHdpdGggb25lIG9yIG11bHRp
cGxlIGxhYmVsIHN1Yi1UTFZzIChJIGFzc3VtZSAiSUYiIGxhYmVsIGluZm9ybWF0aW9uIGlzIG5l
ZWRlZCB0byBiZSBhZHZlcnRpc2VkIGhlcmUpLCB3aHkgaXQgY2Fubm90IGludGVycHJldCB0aGUg
bGFiZWxzIGFyZSBTREggbGFiZWxzPw0KDQpbQ3lyaWxdICBJZiB0aGVyZSBpcyAyIElTQ0Qgc3Vi
LVRMViBhbmQgMiBhdmFpbGFibGUgbGFiZWwgc3ViLVRMViwgaG93IHRvIHRlbGwgd2hpY2ggYXZh
aWxhYmxlIGxhYmVsIHN1Yi1UTFYgcmVsYXRlIHRvIHdoaWNoIElTQ0Qgc3ViLVRMVj8NCg0KDQoN
CkNvdWxkIHlvdSBjbGFyaWZ5IHRoaXMgcG9pbnQsIGl0IHdvdWxkIGJlIHVzZWZ1bCBmb3IgaW5z
dGFuY2UgdG8gY29uc2lkZXIgdGhlIGV4YW1wbGUgb2YgYSBsaW5rIHN1cHBvcnRpbmcgU0RIDQoo
bm8gVkM0LXN3aXRjaGluZyksIE9EVSAoRy43MDksIGFzIG9mIFJGQzQzMjgsIGFuZCBmb3IgdGhl
IGN1cnJlbnQgRy43MDkgdjMgbGFiZWwgZm9ybWF0KS4NCg0KDQoNCltGYXRhaV0gIERvIHlvdSBt
ZWFuIHRvIGhhdmUgYW4gZXhhbXBsZSBvbiBoeWJyaWQgbm9kZT8gSSB3aWxsIG5vdCB1c2UgYSBj
b21wbGV4IGV4YW1wbGUgdG8gZXhwbGFpbiBhIGtpbmQgb2Ygc2ltcGxlIHRoaW5nIChJdCB3aWxs
IGNvbmZ1c2UgcGVvcGxlKS4NCg0KW0N5cmlsXSBJdCBtYXkgbm90IGJlIHNvIHNpbXBsZSwgSSBo
YXZlIHRyb3VibGUgdG8gaW50ZXJwcmV0IGxhYmVsIHdpdGhvdXQga25vd2luZyB0aGUgSVNDRCBj
b25zaWRlcmVkIGFuZCBJIGRvIG5vdCBzZWUgY2xlYXJseSB0aGUgcmVsYXRpb24gYmV0d2VlbiB0
aGUgdHdvIGluIHRoZSBkb2N1bWVudC4NCg0KVGhlIHRleHQgaXMgdmVyeSBmb2N1c2VkIG9uIFdT
T04sIHdoaWxlIGl0IGlzIGEgdmVyeSBpbnRlcmVzdGluZyBleGFtcGxlLCBoYXZpbmcgb3RoZXIg
dGVjaG5vbG9neSAoT1ROIGZvcg0KZXhhbXBsZSB3b3VsZCBoZWxwIHRvIHNob3cgdGhhdCB0aGUg
c29sdXRpb24gaXMgZ2VuZXJpYy4NCg0KW0ZhdGFpXSBJIHRoaW5rIG9uZSB0eXBpY2FsIGV4YW1w
bGUgaXMgc3VmZmljaWVudCBmb3IgcGVvcGxlIHRvIHVuZGVyc3RhbmQgdGhpbmdzLiBURE0gbmV0
d29yayBpcyBkaWZmZXJlbnQgZnJvbSBXU09OIG5ldHdvcmsuIEluIFRETSBuZXR3b3JrLCB1c3Vh
bGx5IGl0IHdpbGwgbm90IGFkdmVydGlzZSBsYWJlbCBpbmZvcm1hdGlvbiBldmVuIHRob3VnaCBs
YWJlbCBpbmZvcm1hdGlvbiBjb3VsZCBiZSBhZHZlcnRpc2VkLg0KDQpbQ3lyaWxdIFRoZXkgYXJl
IGluZGVlZCBkaWZmZXJlbnQsIGJ1dCBmcm9tIGxhYmVsIHBvaW50IG9mIHZpZXcgaXQgc2hvdWxk
IG5vdCBtYWtlIGEgZGlmZmVyZW5jZS4gQSB1c3VhbCB1c2UgY2FzZSBvZiBjb25uZWN0aXZpdHkg
bWF0cml4IHdvdWxkIGJlIGZvciBleGFtcGxlIG9uIGNsaWVudCBjYXJkcyB3aXRoIHN3aXRjaGlu
ZyByZXN0cmljdGlvbiA6IGZpeGVkIE11bHRpcGxleCBhbmQgbGFiZWwgYXNzaWdubWVudCBkdWUg
dG8gdGhlIGZpeGVkIE1VWCAoT0RVMi0+T0RVMSBmb3IgaW5zdGFuY2UpICBvbiBEV0RNIG5vZGUg
Og0KDQp0aGUgcmVzdHJpY3Rpb24gY2FuIGJlIG1vZGVsZWQgYXMgb25lIGNvbm5lY3Rpdml0eSBt
YXRyaXggcGVyIGNsaWVudCBwb3J0LA0KDQogICAgICAgIHRoZSBjbGllbnQgcG9ydCBoYXZlIHRo
ZW4gSVNDRCBURE0sDQoNCiAgICAgICAgdGhlIG90aGVyIHBvcnRzIGNhbiBkbyBEV0RNIGFuZCBU
RE0sDQoNCiAgICAgICAgZm9yIHRoZSBjb25uZWN0aXZpdHkgbWF0cml4IGNvcnJlc3BvbmRpbmcg
dG8gYSBjbGllbnQgcG9ydCB0aGUgb25seSBPRFUgbGFiZWwgdG8gYmUgYXNzaWduZWQgKGR1ZSB0
byBmaXhlZCBNVVgpIGlzIHNwZWNpZmllZA0KDQoNCg0KRmlyc3QsIGlzIHRoaXMgbW9kZWxpbmcg
Y29ycmVjdD8NCg0KU2Vjb25kLCBob3cgdG8gbWFrZSBzdXJlIHRoZSBsYWJlbCByZXN0cmljdGlv
biBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgT0RVIGxhYmVscz8NCg0KDQoNCkkgdGhpbmsgaXQg
aXMgYWxzbyBpbXBvcnRhbnQgdG8gc2hvdyB0aGF0IHRoZSBleHRlbnNpb25zIGFyZSBhbHNvIHdv
cmtpbmcgb3V0c2lkZSB0aGUgZnJhbWV3b3JrIHRoZXkgd2VyZSBib3JuIChXU09OKS4NCg0KDQoN
CkJSDQoNCg0KQmVzdCBSZWdhcmRzLA0KQ3lyaWwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut
LS0tLQ0KPiBGcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAtYm91bmNl
c0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+IE9mIGV4dCBaaGFuZ2ZhdGFpDQo+IFNlbnQ6IFRodXJz
ZGF5LCBTZXB0ZW1iZXIgMjIsIDIwMTEgMTE6MTcgQU0NCj4gVG86IGNjYW1wQGlldGYub3JnDQo+
IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMt
Z2VuZXJhbC0NCj4gY29uc3RyYWludHMtb3NwZi10ZS0wMi50eHQNCj4NCj4gSGkgQ0NBTVBlcnMs
DQo+DQo+IEEgbmV3IHZlcnNpb24gaGFzIGJlZW4gc3VibWl0dGVkIHRvIGFkZHJlc3MgdGhlIGNv
bW1lbnRzIGZyb20gdGhlIFdHDQo+IGRpc2N1c3Npb24uDQo+DQo+IFdlIGFjY2VwdGVkIEFjZWUg
YW5kIFlvdW5nJ3Mgc3VnZ2VzdGlvbiB0byBpbnRyb2R1Y2UgYSBuZXcgdG9wLWxldmVsDQo+IG5v
ZGUgVExWIChHZW5lcmljIE5vZGUgQXR0cmlidXRlIFRMVikgdG8gc2ltcGxpZnkgdGhpbmdzIGFu
ZCBhIG5ldw0KPiBzZWN0aW9uIChTZWN0aW9uIDUpIHdhcyBhZGRlZCB0byBkZXNjcmliZSBzY2Fs
YWJpbGl0eSBpc3N1ZS4NCj4NCj4gTW9yZSBpbmZvcm1hdGlvbiBmcm9tOiBodHRwOi8vd3d3Lmll
dGYub3JnL2lkL2RyYWZ0LWlldGYtY2NhbXAtZ21wbHMtDQo+IGdlbmVyYWwtY29uc3RyYWludHMt
b3NwZi10ZS0wMi50eHQNCj4NCj4gUGxlYXNlIGNoZWNrIG91dCBmb3IgZGV0YWlscyBhbmQgY29t
bWVudHMgYXJlIGFsd2F5cyB3ZWxjb21lLg0KPg0KPg0KPiBUaGFua3MNCj4NCj4gRmF0YWkNCj4N
Cj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogY2NhbXAtYm91bmNlc0Bp
ZXRmLm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZiBp
bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj4gU2VudDogMjAxMcTqOdTCMjLI1SAxNzowNg0KPiBU
bzogaS1kLWFubm91bmNlQGlldGYub3JnDQo+IENjOiBjY2FtcEBpZXRmLm9yZw0KPiBTdWJqZWN0
OiBbQ0NBTVBdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC0NCj4g
Y29uc3RyYWludHMtb3NwZi10ZS0wMi50eHQNCj4NCj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMg
YXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+IGRpcmVjdG9yaWVz
LiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBDb21tb24gQ29udHJvbCBhbmQNCj4g
TWVhc3VyZW1lbnQgUGxhbmUgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4NCj4NCj4gICAgICAg
VGl0bGUgICAgICAgICAgIDogT1NQRi1URSBFeHRlbnNpb25zIGZvciBHZW5lcmFsIE5ldHdvcmsg
RWxlbWVudA0KPiBDb25zdHJhaW50cw0KPiAgICAgICBBdXRob3IocykgICAgICAgOiBGYXRhaSBa
aGFuZw0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIFlvdW5nIExlZQ0KPiAgICAgICAgICAg
ICAgICAgICAgICAgICAgIEppYW5ydWkgSGFuDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAg
R3JlZyBCZXJuc3RlaW4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICBZdW5iaW4gWHUNCj4g
ICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLWNv
bnN0cmFpbnRzLQ0KPiBvc3BmLXRlLTAyLnR4dA0KPiAgICAgICBQYWdlcyAgICAgICAgICAgOiAx
NA0KPiAgICAgICBEYXRlICAgICAgICAgICAgOiAyMDExLTA5LTIyDQo+DQo+ICAgIEdlbmVyYWxp
emVkIE11bHRpcHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nIGNhbiBiZSB1c2VkIHRvIGNvbnRyb2wg
YQ0KPiAgICB3aWRlIHZhcmlldHkgb2YgdGVjaG5vbG9naWVzIGluY2x1ZGluZyBwYWNrZXQgc3dp
dGNoaW5nIChlLmcuLA0KPiBNUExTKSwNCj4gICAgdGltZS1kaXZpc2lvbiAoZS5nLiwgU09ORVQv
U0RILCBPVE4pLCB3YXZlbGVuZ3RoIChsYW1iZGFzKSwgYW5kDQo+ICAgIHNwYXRpYWwgc3dpdGNo
aW5nIChlLmcuLCBpbmNvbWluZyBwb3J0IG9yIGZpYmVyIHRvIG91dGdvaW5nIHBvcnQgb3INCj4g
ICAgZmliZXIpLiBJbiBzb21lIG9mIHRoZXNlIHRlY2hub2xvZ2llcyBuZXR3b3JrIGVsZW1lbnRz
IGFuZCBsaW5rcyBtYXkNCj4gICAgaW1wb3NlIGFkZGl0aW9uYWwgcm91dGluZyBjb25zdHJhaW50
cyBzdWNoIGFzIGFzeW1tZXRyaWMgc3dpdGNoDQo+ICAgIGNvbm5lY3Rpdml0eSwgbm9uLWxvY2Fs
IGxhYmVsIGFzc2lnbm1lbnQsIGFuZCBsYWJlbCByYW5nZQ0KPiBsaW1pdGF0aW9ucw0KPiAgICBv
biBsaW5rcy4gVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgT1NQRiByb3V0aW5nIHByb3RvY29sIGV4
dGVuc2lvbnMNCj4gdG8NCj4gICAgc3VwcG9ydCB0aGVzZSBraW5kcyBvZiBjb25zdHJhaW50cyB1
bmRlciB0aGUgY29udHJvbCBvZiBHZW5lcmFsaXplZA0KPiAgICBNUExTIChHTVBMUykuDQo+DQo+
DQo+DQo+IEEgVVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlzOg0KPiBodHRwOi8vd3d3Lmll
dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWdlbmVyYWwtDQo+
IGNvbnN0cmFpbnRzLW9zcGYtdGUtMDIudHh0DQo+DQo+IEludGVybmV0LURyYWZ0cyBhcmUgYWxz
byBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gZnRwOi8vZnRwLmlldGYub3JnL2lu
dGVybmV0LWRyYWZ0cy8NCj4NCj4gVGhpcyBJbnRlcm5ldC1EcmFmdCBjYW4gYmUgcmV0cmlldmVk
IGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtY2Nh
bXAtZ21wbHMtZ2VuZXJhbC0NCj4gY29uc3RyYWludHMtb3NwZi10ZS0wMi50eHQNCj4gX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQ0NBTVAgbWFpbGlu
ZyBsaXN0DQo+IENDQU1QQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vY2NhbXANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCj4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+IENDQU1QQGlldGYub3JnDQo+IGh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCg==

--Boundary_(ID_kywcaBB42AnxZAaG/2P9CQ)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: quoted-printable










Hi Cyril,


 


Usually, one TE link advertisement (with serveral ISCDs and multiple lab=
el sub-TLVs) has the same Switching Capability, so there is implicit relati=
onship between the ISCDs and label sub-TLVs.


 


I would like to consider your last point when I udpate this draft i=
n the next version.



 


But I have a question on your example, do you see that there is a line p=
ort (or interface) can support both DWDM and TDM in the world? I think=
 if a line port can support DWDM, the WSON TE link (with WSON related label=
 (wavelength) information) should be
 advertised for this line port; if a line port can support TDM, then the TD=
M TE link (e.g., ODU) for this line port should be advertised. Even th=
ough there was one port could support both DWDM and TDM, I think usual=
ly it should advertise these two types of
 capability separately, ie., use seperate TE link advertisements. so, I thi=
nk there is implicit relationship between the ISCDs and label sub-TLVs.


 


Even though I think we should not use a kind of special and complex=
 example to explain something, I will bear your example in my min=
d when I update the draft (as I said in the second sentence above).


 


Thanks


 


Fatai


 


 




=B7=A2=BC=FE=C8=CB: Margaria, Cyril (NSN -=
 DE/Munich) [cyril.margaria@nsn.com]

=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA9=D4=C229=C8=D5 17:36

=B5=BD: Zhangfatai; ccamp@ietf.org

=D6=F7=CC=E2: RE: =B4=F0=B8=B4: =B4=F0=B8=B4: [CCAMP] I-D Action: dr=
aft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt












Hi,



 


If I understand correctly, you state that =
there is not explicit or implicit relationship between the ISCD and label s=
ub-TLV, correct?


I would expect a new generic draft to be a=
pplicable to all already defined label format, so  it seems missing in=
 the document.


 


Could you consider my last point regarding=
 the example of switching restriction in G.709 v2 and DWDM context, it woul=
d be helpful



 to have some statement even though i=
t will not be in the document.


 


Best Regards.


 


 








From: ext Zhangfatai [mailto:zhangfatai@huawei.com]


Sent: Wednesday, September 28, 2011 4:30 AM

To: Margaria, Cyril (NSN - DE/Munich); ccamp@ietf.org

Subject: =B4=
=F0=B8=B4:
=B4=F0=B8=B4: [CCAMP]=
 I-D Action: draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt






 




Hi Cyril,


 


I agree on your first suggestion.


 


Secondly, this draft is generic, when it needs to advertise =
label information for some specific tech (e.g., TDM), the document about&nb=
sp;specific tech can refer to this draft and
 should define how to correlate the ISCDs and label sub-TLVs if there is no=
 explicit or implicit relationship between them (I thin=
k there are lots of potential solutions to handle that, it is quite tech sp=
ecific stuff).



 


 


Fatai


 


Thanks


 


 












=B7=A2=BC=FE=C8=CB<=
span style=3D"FONT-FAMILY: 'Tahoma','sans-serif'; COLOR: black; FONT-SIZE: =
10pt">:
 Margaria, Cyril (NSN - DE/Munich) [cyril.margaria@nsn.com]

=B7=
=A2=CB=CD=CA=B1=BC=E4:
 2011=
=C4=EA9=D4=C2
 17:38

=B5=
=BD: Zhangfatai;
 ccamp@ietf.org

=D6=
=F7=CC=E2: RE:
=B4=F0=
=B8=B4: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-co=
nstraints-ospf-te-02.txt








Hi,



 


Thanks for the answer,



 


Please see inline


 


 








From: ext Zhangfatai [ma=
ilto:zhangfatai@huawei.com]


Sent: Tuesday, September 27, 2011 11:17 AM

To: Margaria, Cyril (NSN - DE/Munich); ccamp@ietf.org

Subject: =B4=F0=B8=B4: [CCAMP] I-D Action: draft-ietf-ccamp=
-gmpls-general-constraints-ospf-te-02.txt 




Hi Cyril,



Thanks for your commets.



Please see in-line below.





Fatai



Thanks







________________________________________

=B7=A2=
=BC=FE=C8=CB: Margaria, Cyril (NSN - DE/Munich) [cyril.margar=
ia@nsn.com]

=B7=A2=
=CB=CD=CA=B1=BC=E4: 2011=C4=EA9=D4=C226<=
span style=3D"COLOR: black; FONT-SIZE: 10pt" lang=3D"ZH-CN">=C8=D5
 16:03

=B5=BD<=
/span>: Zhangfatai; ccamp@ietf.org

=D6=F7=
=CC=E2: RE: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-genera=
l-constraints-ospf-te-02.txt



Hi,



I have the following comments/question regarding this revision



3.2. Available Labels:



The text state : =A1=B0The Available Labels sub-TLV   may occur a=
t most once within the link TLV.=A1=B1



How to encode different label format in that case? I think the label format=
 would depend

on the ISCD, and as we might have several ISCD, having several Available La=
bel sub-TLV make sense.

This also apply to 3.3. Shared Backup Labels.



[Fatai] This "may" should be "MAY" accordi=
ng to Lou's suggestion, so it does not prevent you to have several availabl=
e label sub-TLVs.



[Cyril] Stating =A1=B0The Available Labels sub-TLV  =
 MAY  occur more than once within the link TLV.=A1=B1  Would be m=
ore accurate and easier to understand.


 




In case of several ISCD are present for a given advertisement how to interp=
ret the label format in the

label-related sub-TLVs?




[Fatai] It is easy to achive that. e.g, in SDH network, a=
 node can advertise several ISCDs with one or multiple label sub-TLVs =
(I assume "IF" label information is needed to
 be advertised here), why it cannot interpret the labels are SDH labels?


[Cyril]  If there is 2 ISCD sub-TLV and 2 available label =
sub-TLV, how to tell which available label sub-TLV relate to which ISCD sub=
-TLV?


 




Could you clarify this point, it would be useful for instance to consider t=
he example of a link supporting SDH

(no VC4-switching), ODU (G.709, as of RFC4328, and for the current G.709 v3=
 label format).


 


[Fatai]  Do you mean to have an example on hybrid node? I wil=
l not use a complex example to explain a kind of simple=
 thing (It will confuse people).



[Cyril] It may not be so simple, I have trouble to interpret l=
abel without knowing the ISCD considered and I do not see clearly the relat=
ion between the two in the document.




The text is very focused on WSON, while it is a very interesting example, h=
aving other technology (OTN for

example would help to show that the solution is generic.


[Fatai] I think one typical example is sufficient for people to un=
derstand things. TDM network is different from WSON network. In TDM ne=
twork, usually it will not advertise label
 information even though label information could be advertised.


[Cyril] They are indeed different, but from label point of view=
 it should not make a difference. A usual use case of connectivity matrix w=
ould be for example on client cards
 with switching restriction : fixed Multiplex and label assignment due to t=
he fixed MUX (ODU2->ODU1 for instance)  on DWDM node :


the restric=
tion can be modeled as one connectivity matrix per client port,


     &nb=
sp;  the client port have then ISCD TDM,



     &nb=
sp;  the other ports can do DWDM and TDM,



     &nb=
sp;  for the connectivity matrix corresponding to a client port t=
he only ODU label to be assigned (due to fixed MUX) is specified



 


First, is this modeling correct?



Second, how to make sure the label restriction are to be inter=
preted as ODU labels?


 


I think it is also important to show that the extensions are a=
lso working outside the framework they were born (WSON).


 


BR






Best Regards,

Cyril



> -----Original Message-----

> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf=


> Of ext Zhangfatai

> Sent: Thursday, September 22, 2011 11:17 AM

> To: ccamp@ietf.org

> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-

> constraints-ospf-te-02.txt

>

> Hi CCAMPers,

>

> A new version has been submitted to address the comments from the WG
> discussion.

>

> We accepted Acee and Young's suggestion to introduce a new top-level
> node TLV (Generic Node Attribute TLV) to simplify things and a new

> section (Section 5) was added to describe scalability issue.

>

> More information from: http://www.ietf.org/id/draft-ietf-ccamp-gmpls-<=
br>
> general-constraints-ospf-te-02.txt

>

> Please check out for details and comments are always welcome.

>

>

> Thanks

>

> Fatai

>

>

> -----Original Message-----

> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf=


> Of internet-drafts@ietf.org

> Sent: 2011=C4=EA9=D4=C222=C8=D5
 17:06

> To: i-d-announce@ietf.org

> Cc: ccamp@ietf.org

> Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-

> constraints-ospf-te-02.txt

>

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

> directories. This draft is a work item of the Common Control and

> Measurement Plane Working Group of the IETF.

>

>       Title     =
;      : OSPF-TE Extensions for General Network El=
ement

> Constraints

>       Author(s)    &=
nbsp;  : Fatai Zhang

>            =
;            &n=
bsp;  Young Lee

>            =
;            &n=
bsp;  Jianrui Han

>            =
;            &n=
bsp;  Greg Bernstein

>            =
;            &n=
bsp;  Yunbin Xu

>       Filename    &n=
bsp;   : draft-ietf-ccamp-gmpls-general-constraints-

> ospf-te-02.txt

>       Pages     =
;      : 14

>       Date     =
       : 2011-09-22

>

>    Generalized Multiprotocol Label Switching can be use=
d to control a

>    wide variety of technologies including packet switch=
ing (e.g.,

> MPLS),

>    time-division (e.g., SONET/SDH, OTN), wavelength (la=
mbdas), and

>    spatial switching (e.g., incoming port or fiber to o=
utgoing port or

>    fiber). In some of these technologies network elemen=
ts and links may

>    impose additional routing constraints such as asymme=
tric switch

>    connectivity, non-local label assignment, and label =
range

> limitations

>    on links. This document describes OSPF routing proto=
col extensions

> to

>    support these kinds of constraints under the control=
 of Generalized

>    MPLS (GMPLS).

>

>

>

> A URL for this Internet-Draft is:

> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-general-
> constraints-ospf-te-02.txt

>

> Internet-Drafts are also available by anonymous FTP at:

> ftp://ftp.ietf.org/internet-drafts/

>

> This Internet-Draft can be retrieved at:

> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-general-

> constraints-ospf-te-02.txt

> _______________________________________________

> 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


























--Boundary_(ID_kywcaBB42AnxZAaG/2P9CQ)--

From Steve.Balls@metaswitch.com  Thu Sep 29 03:35:12 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B8521F8C8A for ; Thu, 29 Sep 2011 03:35:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001,  BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RK8Ybrfzj4WY for ; Thu, 29 Sep 2011 03:35:12 -0700 (PDT)
Received: from ENFICSETS1.metaswitch.com (enficsets1.metaswitch.com [192.91.191.5]) by ietfa.amsl.com (Postfix) with ESMTP id CB9F621F8BEF for ; Thu, 29 Sep 2011 03:35:11 -0700 (PDT)
Received: from ENFIRHMBX1.datcon.co.uk (172.18.74.36) by ENFICSETS1.metaswitch.com (172.18.4.19) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 29 Sep 2011 11:38:08 +0100
Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFIRHMBX1.datcon.co.uk ([fe80::b06d:4d13:5f63:3715%19]) with mapi id 14.01.0289.001; Thu, 29 Sep 2011 11:38:01 +0100
From: Steve Balls 
To: CCAMP 
Thread-Topic: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG documents
Thread-Index: AQHMffwx7qAEnLzzbU+7Wl7LaiWSj5VkKj5w
Date: Thu, 29 Sep 2011 10:36:00 +0000
Deferred-Delivery: Thu, 29 Sep 2011 10:36:00 +0000
Message-ID: <1508F62A2F511042B45D315CFF74E22911CA0477@ENFICSMBX1.datcon.co.uk>
References: <4E834C0D.5030800@labn.net>
In-Reply-To: <4E834C0D.5030800@labn.net>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.18.72.110]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG	documents
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Sep 2011 10:35:13 -0000

Yes to both=20
(contributor to routing draft)
Steve

-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L=
ou Berger
Sent: 28 September 2011 17:32
To: CCAMP
Subject: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG docum=
ents

This message starts a two week poll on making the documents listed below
ccamp working group documents.  Please send a mail to the mailing list
indicating "yes/support to both" or "no/do not support either".  Of
course, you may also support one but not the other.  (We will assume
that you support/object to both if you don't specify.)

If indicating no, please state your technical reservations with the
document.

The documents being polled are:
http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-ospf-g709-07
http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-evolving-g709-09

The poll ends Wednesday October 12.

Please also bear in mind that WG adoption does not signify that work is
complete on the documents or that the technical details are fixed, but
rather that further development of the documents will take place based
on WG process.

Much thanks,
Lou (and Deborah)
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

From cyril.margaria@nsn.com  Thu Sep 29 04:02:32 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7EF221F8B20 for ; Thu, 29 Sep 2011 04:02:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.546
X-Spam-Level: 
X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=-3.243, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pHMwZIgHMj63 for ; Thu, 29 Sep 2011 04:02:30 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 752BD21F8B34 for ; Thu, 29 Sep 2011 04:02:29 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p8TB5BDX028025 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 13:05:11 +0200
Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p8TB5AOx008770; Thu, 29 Sep 2011 13:05:11 +0200
Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 29 Sep 2011 13:05:05 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC7E97.A41D123B"
Date: Thu, 29 Sep 2011 13:05:03 +0200
Message-ID: 
In-Reply-To: A
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: =?gb2312?B?ILTwuLQ6ICC08Li0OiAgtPC4tDogW0NDQU1QXSBJLUQgQWN0aW9uOg==?= =?gb2312?B?IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC1jb25zdHJhaW50cy0=?= =?gb2312?B?b3NwZi10ZS0wMi50eHQ=?=
Thread-Index: AQHMeQhw4fH7IgNgHEuaM0yhaE8MRpVfUxoggAGhYTmAAAbksIABGMsGgAIOXpCAAAelMIAAB0lQ
References: <20110922090626.6373.58763.idtracker@ietfa.amsl.com>   A   A   A
From: "Margaria, Cyril (NSN - DE/Munich)" 
To: "ext Zhangfatai" , 
X-OriginalArrivalTime: 29 Sep 2011 11:05:05.0289 (UTC) FILETIME=[A48EDF90:01CC7E97]
Subject: Re: [CCAMP] =?gb2312?b?tPC4tDogILTwuLQ6ICC08Li0OiAgSS1EIEFjdGlvbjog?= =?gb2312?b?ZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLWNvbnN0cmFp?= =?gb2312?b?bnRzLW9zcGYtdGUtMDIudHh0?=
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Sep 2011 11:02:32 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC7E97.A41D123B
Content-Type: text/plain;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable

Hi Fatai,=20

=20

For my example I took the example from RFC5339 (also following the logic =
of RFC4202 section 2.4.6), adjusting the capabilities and extended the =
number of ports:

=20

                             Network element

                        .............................

                        :            --------       :

              TDM       :           |  TDM   |      :

            Port1-------------<->---|#a      |      :

            Port2-------------<->---|#b      |      :

            Port3-------------<->---|#c      |      :

            Port4-------------<->---|#d      |      :

                        :  +--<->---|#e      |      :

                        :  |         --------       :

                        :  |        ----------      :

              DWDM      :  +--<->--|#f  DWDM  |     :

            Port5 ------------<->--|#g        |     :

                        :           ----------      :

                        :............................

=20

                           Figure 1a.  Hybrid node.

=20

>From ISCD point of view:

TE link 1 (Port1):

     - ISCD sub-TLV: TDM  (ODU2)=20

TE link 2 (Port1):

     - ISCD sub-TLV: TDM  (ODU2)=20

=A1=AD

TE-Link 5 (port 2) :=20

     - ISCD #1 sub-TLV: DWDM=20

     - ISCD #2 sub-TLV: TDM, G.709 ODUk (ODU3)=20

=20

The ISCD #2 represent the DWDM-TDM adjustement capability

I am leaving out in this thread how to know the OEO capability of port =
#f/#e ;-)

=20

=20

With the following connectivity matrix (with the following convention : =
({Link Set A#1},{Link set B#1}),({Link Set A#2},{Link set B#2}),=A1=AD

=20

Matrix #1 ({Port 1}, {Port 5})=20

Matrix #2 ({Port 2}, {Port 5})

Matrix #3 ({Port 3}, {Port 5})

Matrix #4 ({Port 4}, {Port 5})

=20

TE-Link 5 (port 2) :=20

     - ISCD #1 sub-TLV: DWDM=20

     - ISCD #2 sub-TLV: TDM, G.709 ODUk (here ODU3, because of the port =
#e)

     - Port Label restriction : Matrix #1, =
RestrictionType=3DSIMPLE_LABEL, Label =3D TS :16,12,8,4 (can we be sure =
of the interpretation ?)

     - Port Label restriction : Matrix #2, =
RestrictionType=3DSIMPLE_LABEL, Label =3D TS :15,11,7,3

     - Port Label restriction : Matrix #3, =
RestrictionType=3DSIMPLE_LABEL, Label =3D TS :14,10,6,2

     - Port Label restriction : Matrix #3, =
RestrictionType=3DSIMPLE_LABEL, Label =3D TS :13,09,5,1

I am not 100% sure that we can always interpret the label as ODU label, =
RFC4202 section 2.4.7 on how to interpret the

Label on a TE-Link would indicate that if one end support TDM and the =
other LSC, the label should represent a lambda,=20

but the case where there is several ISCD is not well described.

=20

The draft should detail the rules on which label encoding to use in case =
of connectivity matrix in that case.

=20

In that example we have fixed MUX ODU3->ODU2 AND each ODU2 is assigned =
to an port: the port label restriction is used,=20

Rules for port label restriction should allow to interpret correctly the =
label.

=20

However on case of Fixes MUX and flexible ODU2 to port assignment one =
allowed possibility is the following :=20

Matrix #11 ({Port 1, Port 2, Port 3, Port 4,}, {Port 5})

=20

TE-Link 5 (port 2) :=20

     - ISCD #1 sub-TLV: DWDM=20

     - ISCD #2 sub-TLV: TDM, G.709 ODUk (ODU3)=20

    - Available  Labels : ? TS :15,11,7,3 ?, ? TS :14,10,6,2 ?, ? TS =
:13,09,5,1 ?, ? TS :16,12,8,4=A1=B1

     - Available  Labels : channels (DWDM)=20

=20

How to make sure the interpretation is correct, This is an typical case =
covered by the generic GMPLS RFCs, so=20

 It should  be covered in my opinion by the generic extensions.

=20

=20

=20

=20

=20

From: ext Zhangfatai [mailto:zhangfatai@huawei.com]=20
Sent: Thursday, September 29, 2011 12:19 PM
To: Margaria, Cyril (NSN - DE/Munich); ccamp@ietf.org
Subject: =B4=F0=B8=B4: =B4=F0=B8=B4: =B4=F0=B8=B4: [CCAMP] I-D Action: =
draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt

=20

Hi Cyril,

=20

Usually, one TE link advertisement (with serveral ISCDs and multiple =
label sub-TLVs) has the same Switching Capability, so there is implicit =
relationship between the ISCDs and label sub-TLVs.

=20

I would like to consider your last point when I udpate this draft in the =
next version.=20

=20

But I have a question on your example, do you see that there is a line =
port (or interface) can support both DWDM and TDM in the world? I think =
if a line port can support DWDM, the WSON TE link (with WSON related =
label (wavelength) information) should be advertised for this line port; =
if a line port can support TDM, then the TDM TE link (e.g., ODU) for =
this line port should be advertised. Even though there was one port =
could support both DWDM and TDM, I think usually it should advertise =
these two types of capability separately, ie., use seperate TE link =
advertisements. so, I think there is implicit relationship between the =
ISCDs and label sub-TLVs.

=20

Even though I think we should not use a kind of special and complex =
example to explain something, I will bear your example in my mind when I =
update the draft (as I said in the second sentence above).

=20

Thanks

=20

Fatai

=20

=20

________________________________

=B7=A2=BC=FE=C8=CB: Margaria, Cyril (NSN - DE/Munich) =
[cyril.margaria@nsn.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA9=D4=C229=C8=D5 17:36
=B5=BD: Zhangfatai; ccamp@ietf.org
=D6=F7=CC=E2: RE: =B4=F0=B8=B4: =B4=F0=B8=B4: [CCAMP] I-D Action: =
draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt

Hi,=20

=20

If I understand correctly, you state that there is not explicit or =
implicit relationship between the ISCD and label sub-TLV, correct?

I would expect a new generic draft to be applicable to all already =
defined label format, so  it seems missing in the document.

=20

Could you consider my last point regarding the example of switching =
restriction in G.709 v2 and DWDM context, it would be helpful=20

 to have some statement even though it will not be in the document.

=20

Best Regards.

=20

=20

From: ext Zhangfatai [mailto:zhangfatai@huawei.com]=20
Sent: Wednesday, September 28, 2011 4:30 AM
To: Margaria, Cyril (NSN - DE/Munich); ccamp@ietf.org
Subject: =B4=F0=B8=B4: =B4=F0=B8=B4: [CCAMP] I-D Action: =
draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt

=20

Hi Cyril,

=20

I agree on your first suggestion.

=20

Secondly, this draft is generic, when it needs to advertise label =
information for some specific tech (e.g., TDM), the document about =
specific tech can refer to this draft and should define how to correlate =
the ISCDs and label sub-TLVs if there is no explicit or implicit =
relationship between them (I think there are lots of potential solutions =
to handle that, it is quite tech specific stuff).=20

=20

=20

Fatai

=20

Thanks

=20

=20

________________________________

=B7=A2=BC=FE=C8=CB: Margaria, Cyril (NSN - DE/Munich) =
[cyril.margaria@nsn.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA9=D4=C227=C8=D5 17:38
=B5=BD: Zhangfatai; ccamp@ietf.org
=D6=F7=CC=E2: RE: =B4=F0=B8=B4: [CCAMP] I-D Action: =
draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt

Hi,=20

=20

Thanks for the answer,=20

=20

Please see inline

=20

=20

From: ext Zhangfatai [mailto:zhangfatai@huawei.com]=20
Sent: Tuesday, September 27, 2011 11:17 AM
To: Margaria, Cyril (NSN - DE/Munich); ccamp@ietf.org
Subject: =B4=F0=B8=B4: [CCAMP] I-D Action: =
draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt

=20

Hi Cyril,

Thanks for your commets.

Please see in-line below.


Fatai

Thanks



________________________________________
=B7=A2=BC=FE=C8=CB: Margaria, Cyril (NSN - DE/Munich) =
[cyril.margaria@nsn.com]
=B7=A2=CB=CD=CA=B1=BC=E4: 2011=C4=EA9=D4=C226=C8=D5 16:03
=B5=BD: Zhangfatai; ccamp@ietf.org
=D6=F7=CC=E2: RE: [CCAMP] I-D Action: =
draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt

Hi,

I have the following comments/question regarding this revision

3.2. Available Labels:

The text state : =A1=B0The Available Labels sub-TLV   may occur at most =
once within the link TLV.=A1=B1

How to encode different label format in that case? I think the label =
format would depend
on the ISCD, and as we might have several ISCD, having several Available =
Label sub-TLV make sense.
This also apply to 3.3. Shared Backup Labels.

[Fatai] This "may" should be "MAY" according to Lou's suggestion, so it =
does not prevent you to have several available label sub-TLVs.=20

[Cyril] Stating =A1=B0The Available Labels sub-TLV   MAY  occur more =
than once within the link TLV.=A1=B1  Would be more accurate and easier =
to understand.

=20


In case of several ISCD are present for a given advertisement how to =
interpret the label format in the
label-related sub-TLVs?


[Fatai] It is easy to achive that. e.g, in SDH network, a node can =
advertise several ISCDs with one or multiple label sub-TLVs (I assume =
"IF" label information is needed to be advertised here), why it cannot =
interpret the labels are SDH labels?

[Cyril]  If there is 2 ISCD sub-TLV and 2 available label sub-TLV, how =
to tell which available label sub-TLV relate to which ISCD sub-TLV?

=20


Could you clarify this point, it would be useful for instance to =
consider the example of a link supporting SDH
(no VC4-switching), ODU (G.709, as of RFC4328, and for the current G.709 =
v3 label format).

=20

[Fatai]  Do you mean to have an example on hybrid node? I will not use a =
complex example to explain a kind of simple thing (It will confuse =
people).=20

[Cyril] It may not be so simple, I have trouble to interpret label =
without knowing the ISCD considered and I do not see clearly the =
relation between the two in the document.


The text is very focused on WSON, while it is a very interesting =
example, having other technology (OTN for
example would help to show that the solution is generic.

[Fatai] I think one typical example is sufficient for people to =
understand things. TDM network is different from WSON network. In TDM =
network, usually it will not advertise label information even though =
label information could be advertised.

[Cyril] They are indeed different, but from label point of view it =
should not make a difference. A usual use case of connectivity matrix =
would be for example on client cards with switching restriction : fixed =
Multiplex and label assignment due to the fixed MUX (ODU2->ODU1 for =
instance)  on DWDM node :

the restriction can be modeled as one connectivity matrix per client =
port,

        the client port have then ISCD TDM,=20

        the other ports can do DWDM and TDM,=20

        for the connectivity matrix corresponding to a client port the =
only ODU label to be assigned (due to fixed MUX) is specified=20

=20

First, is this modeling correct?=20

Second, how to make sure the label restriction are to be interpreted as =
ODU labels?

=20

I think it is also important to show that the extensions are also =
working outside the framework they were born (WSON).

=20

BR



Best Regards,
Cyril

> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of ext Zhangfatai
> Sent: Thursday, September 22, 2011 11:17 AM
> To: ccamp@ietf.org
> Subject: Re: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-
> constraints-ospf-te-02.txt
>
> Hi CCAMPers,
>
> A new version has been submitted to address the comments from the WG
> discussion.
>
> We accepted Acee and Young's suggestion to introduce a new top-level
> node TLV (Generic Node Attribute TLV) to simplify things and a new
> section (Section 5) was added to describe scalability issue.
>
> More information from: http://www.ietf.org/id/draft-ietf-ccamp-gmpls-
> general-constraints-ospf-te-02.txt
>
> Please check out for details and comments are always welcome.
>
>
> Thanks
>
> Fatai
>
>
> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of internet-drafts@ietf.org
> Sent: 2011=C4=EA9=D4=C222=C8=D5 17:06
> To: i-d-announce@ietf.org
> Cc: ccamp@ietf.org
> Subject: [CCAMP] I-D Action: draft-ietf-ccamp-gmpls-general-
> constraints-ospf-te-02.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Common Control and
> Measurement Plane Working Group of the IETF.
>
>       Title           : OSPF-TE Extensions for General Network Element
> Constraints
>       Author(s)       : Fatai Zhang
>                           Young Lee
>                           Jianrui Han
>                           Greg Bernstein
>                           Yunbin Xu
>       Filename        : draft-ietf-ccamp-gmpls-general-constraints-
> ospf-te-02.txt
>       Pages           : 14
>       Date            : 2011-09-22
>
>    Generalized Multiprotocol Label Switching can be used to control a
>    wide variety of technologies including packet switching (e.g.,
> MPLS),
>    time-division (e.g., SONET/SDH, OTN), wavelength (lambdas), and
>    spatial switching (e.g., incoming port or fiber to outgoing port or
>    fiber). 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 describes OSPF routing protocol extensions
> to
>    support these kinds of constraints under the control of Generalized
>    MPLS (GMPLS).
>
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-general-
> constraints-ospf-te-02.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-general-
> constraints-ospf-te-02.txt
> _______________________________________________
> 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


------_=_NextPart_001_01CC7E97.A41D123B
Content-Type: text/html;
	charset="gb2312"
Content-Transfer-Encoding: quoted-printable


Hi =
Fatai, 
 
For my example I took the example from RFC5339 (also =
following the logic of RFC4202 section 2.4.6), adjusting the =
capabilities and extended the number of ports:
 
         =
;            =
        Network =
element
         =
;            =
   .............................
         =
;            =
   =
:            =
--------       :
         =
;     TDM       =
:           |  =
TDM   |      =
:
         =
;   =
Port1-------------<->---|#a      =
|      :
         =
;   =
Port2-------------<->---|#b      =
|      :
         =
;   =
Port3-------------<->---|#c      =
|      :
         =
;   =
Port4-------------<->---|#d      =
|      :
         =
;            =
   :  =
+--<->---|#e      =
|      :
         =
;            =
   :  |         =
--------       :
         =
;            =
   :  |        =
----------      :
         =
;     DWDM      :  =
+--<->--|#f  DWDM  |     =
:
         =
;   Port5 =
------------<->--|#g        =
|     :
         =
;            =
   =
:           =
----------      :
         =
;            =
   :............................
 
         =
;            =
      Figure 1a.  Hybrid =
node.
 
From ISCD point of view:
TE link 1 (Port1):
     - ISCD sub-TLV: TDM =
 (ODU2) 
TE =
link 2 (Port1):
     - ISCD sub-TLV: TDM =
 (ODU2) 
=A1=AD
TE-Link 5 (port 2) : 
     - ISCD #1 sub-TLV: =
DWDM 
     - ISCD #2 sub-TLV: =
TDM, G.709 ODUk (ODU3) 
 
The ISCD #2 represent the DWDM-TDM adjustement =
capability
I am =
leaving out in this thread how to know the OEO capability of port #f/#e =
;-)
 
 
With the following connectivity matrix (with the =
following convention : ({Link Set A#1},{Link set B#1}),({Link Set =
A#2},{Link set B#2}),=A1=AD
 
Matrix #1 ({Port 1}, {Port 5}) =

Matrix #2 ({Port 2}, {Port =
5})
Matrix #3 ({Port 3}, {Port =
5})
Matrix #4 ({Port 4}, {Port =
5})
 
TE-Link 5 (port 2) : 
     - ISCD #1 sub-TLV: =
DWDM 
     - ISCD #2 sub-TLV: =
TDM, G.709 ODUk (here ODU3, because of the port =
#e)
     - Port Label =
restriction : Matrix #1, RestrictionType=3DSIMPLE_LABEL, Label =3D =
TS :16,12,8,4 (can we be sure of the =
interpretation ?)
     - =
Port Label restriction : Matrix #2, RestrictionType=3DSIMPLE_LABEL, =
Label =3D TS :15,11,7,3
     - Port Label =
restriction : Matrix #3, RestrictionType=3DSIMPLE_LABEL, Label =3D =
TS :14,10,6,2
     - Port Label =
restriction : Matrix #3, RestrictionType=3DSIMPLE_LABEL, Label =3D =
TS :13,09,5,1
 
I am =
not 100% sure that we can always interpret the label as ODU label, =
RFC4202 section 2.4.7 on how to interpret the
Label on a TE-Link would indicate that if one end =
support TDM and the other LSC, the label should represent a lambda, =

but =
the case where there is several ISCD is not well =
described.
 
The draft should detail the rules on which label =
encoding to use in case of connectivity matrix in that =
case.
 
In that example we have fixed MUX ODU3->ODU2 AND =
each ODU2 is assigned to an port: the port label restriction is used, =

Rules =
for port label restriction should allow to interpret correctly the =
label.
 
However on case of Fixes MUX and flexible ODU2 to =
port assignment one allowed possibility is the following : =

Matrix #11 ({Port 1, Port 2, Port 3, Port 4,}, {Port =
5})
 
TE-Link 5 (port 2) : 
     - ISCD #1 sub-TLV: =
DWDM 
     - ISCD #2 sub-TLV: =
TDM, G.709 ODUk (ODU3) 
    - Available =
 Labels : « TS :15,11,7,3 », =
« TS :14,10,6,2 », « TS :=
13,09,5,1 », « TS :16,12,8,4=A1=B1
     - Available =
 Labels : channels (DWDM) 
 
How to make sure the interpretation is correct, This =
is an typical case covered by the generic GMPLS RFCs, so =

 It should  be covered in my opinion by =
the generic extensions.
 
 
 
 
 
From:=
 =
ext Zhangfatai [mailto:zhangfatai@huawei.com] 
Sent: Thursday, =
September 29, 2011 12:19 PM
To: Margaria, Cyril (NSN - =
DE/Munich); ccamp@ietf.org
Subject: =B4=F0=B8=B4: =
=B4=F0=B8=B4: =
=B4=F0=B8=B4: [CCAMP] =
I-D Action: =
draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt
 
=
Hi Cyril,
=
 
=
Usually, one TE link advertisement (with serveral ISCDs and multiple =
label sub-TLVs) has the same Switching Capability, so there is implicit =
relationship between the ISCDs and label =
sub-TLVs.
=
 
=
I would like to consider your last point when I udpate this draft =
in the next version. 
=
 
=
But I have a question on your example, do you see that there is a line =
port (or interface) can support both DWDM and TDM in the world? I =
think if a line port can support DWDM, the WSON TE link (with WSON =
related label (wavelength) information) should be advertised for =
this line port; if a line port can support TDM, then the TDM TE link =
(e.g., ODU) for this line port should be advertised. Even though =
there was one port could support both DWDM and TDM, I think usually =
it should advertise these two types of capability separately, ie., use =
seperate TE link advertisements. so, I think there is implicit =
relationship between the ISCDs and label =
sub-TLVs.
=
 
=
Even though I think we should not use a kind of special and =
complex example to explain something, I will bear your example =
in my mind when I update the draft (as I said in the second sentence =
above).
=
 
=
Thanks
=
 
=
Fatai
=
 
=
 
=B7=A2=BC=FE=C8=CB=
:=
 Margaria, Cyril (NSN - DE/Munich) =
[cyril.margaria@nsn.com]
=B7=A2=CB=CD=CA=B1=BC=E4=
:=
 2011=C4=EA=
9=D4=C2=
29=C8=D5=
 17:36
=B5=BD=
:=
 Zhangfatai; ccamp@ietf.org
=D6=F7=CC=E2=
:=
 RE: =B4=F0=B8=B4=
: =B4=F0=B8=B4=
: [CCAMP] I-D Action: =
draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt
Hi, 
 
If I understand correctly, you state that there is not explicit or =
implicit relationship between the ISCD and label sub-TLV, =
correct?
I would expect a new generic draft to be applicable to all already =
defined label format, so  it seems missing in the =
document.
 
Could you consider my last point regarding the example of switching =
restriction in G.709 v2 and DWDM context, it would be helpful =

 to have some statement even though it will not be in the =
document.
 
Best Regards.
 
 
=
From:=
 ext Zhangfatai [mailto:zhangfatai@huawei.com] 
Sent: =
Wednesday, September 28, 2011 4:30 AM
To: Margaria, Cyril (NSN =
- DE/Munich); ccamp@ietf.org
Subject: =B4=F0=B8=B4=
: =B4=F0=B8=B4=
: [CCAMP] I-D Action: =
draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt
 
=
Hi Cyril,
 
=
I agree on your first suggestion.
 
=
Secondly, this draft is generic, when it needs to advertise label =
information for some specific tech (e.g., TDM), the document =
about specific tech can refer to this draft and should =
define how to correlate the ISCDs and label sub-TLVs if there is =
no explicit or implicit relationship between them (I =
think there are lots of potential solutions to handle that, it is quite =
tech specific stuff). 
 
 
=
Fatai
 
=
Thanks
 
 
=B7=A2=BC=FE=C8=CB=
:=
 Margaria, Cyril (NSN - DE/Munich) =
[cyril.margaria@nsn.com]
=B7=A2=CB=CD=CA=B1=BC=E4=
:=
 2011=C4=EA=
9=D4=C2=
27=C8=D5=
 17:38
=B5=BD=
:=
 Zhangfatai; ccamp@ietf.org
=D6=F7=CC=E2=
:=
 RE: =B4=F0=B8=B4=
: [CCAMP] I-D Action: =
draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt
Hi, 
 
Thanks for the answer, 
 
Please see inline
 
 
=
From:=
 ext Zhangfatai [mailto:zhangfatai@huawei.com] 
Sent: Tuesday, =
September 27, 2011 11:17 AM
To: Margaria, Cyril (NSN - =
DE/Munich); ccamp@ietf.org
Subject: =B4=F0=B8=B4=
: [CCAMP] I-D Action: =
draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt
 
=
Hi Cyril,

Thanks for your commets.

Please see in-line =
below.


Fatai

Thanks



____________________=
____________________
=B7=A2=BC=FE=C8=CB=
: Margaria, Cyril (NSN - DE/Munich) =
[cyril.margaria@nsn.com]
=B7=A2=CB=CD=CA=B1=BC=E4=
: 2011=C4=EA=
9=D4=C2=
26=C8=D5=
 16:03
=B5=BD=
: Zhangfatai; ccamp@ietf.org
=D6=F7=CC=E2=
: RE: [CCAMP] I-D Action: =
draft-ietf-ccamp-gmpls-general-constraints-ospf-te-02.txt

Hi,
<=
br>I have the following comments/question regarding this =
revision

3.2. Available Labels:

The text state : =A1=B0The =
Available Labels sub-TLV   may occur at most once within the =
link TLV.=A1=B1

How to encode different label format in that =
case? I think the label format would depend
on the ISCD, and as we =
might have several ISCD, having several Available Label sub-TLV make =
sense.
This also apply to 3.3. Shared Backup =
Labels.

[=
Fatai] This "may" should be "MAY" according to Lou's =
suggestion, so it does not prevent you to have several available label =
sub-TLVs. 
[Cyril] Stating =A1=B0The Available Labels sub-TLV   MAY =
 occur more than once within the link TLV.=A1=B1  Would be =
more accurate and easier to understand.
 
=

In case of several ISCD are present for a given advertisement how to =
interpret the label format in the
label-related sub-TLVs?
=

[=
Fatai] It is easy to achive that. e.g, in SDH network, a node can =
advertise several ISCDs with one or multiple label sub-TLVs (I =
assume "IF" label information is needed to be advertised =
here), why it cannot interpret the labels are SDH labels?
[Cyril]  If there is 2 ISCD sub-TLV and 2 available label =
sub-TLV, how to tell which available label sub-TLV relate to which ISCD =
sub-TLV?
 
=

Could you clarify this point, it would be useful for instance to =
consider the example of a link supporting SDH
(no VC4-switching), ODU =
(G.709, as of RFC4328, and for the current G.709 v3 label =
format).
 
[=
Fatai]  Do you mean to have an example on hybrid node? I will =
not use a complex example to explain a kind of =
simple thing (It will confuse people). 
[Cyril] It may not be so simple, I have trouble to interpret label =
without knowing the ISCD considered and I do not see clearly the =
relation between the two in the document.
=

The text is very focused on WSON, while it is a very interesting =
example, having other technology (OTN for
example would help to show =
that the solution is generic.
[=
Fatai] I think one typical example is sufficient for people to =
understand things. TDM network is different from WSON network. In =
TDM network, usually it will not advertise label information even though =
label information could be advertised.
[Cyril] They are indeed different, but from label point of view it =
should not make a difference. A usual use case of connectivity matrix =
would be for example on client cards with switching restriction : fixed =
Multiplex and label assignment due to the fixed MUX (ODU2->ODU1 for =
instance)  on DWDM node :
the restriction can be modeled as one connectivity matrix per client =
port,
        the client port have then =
ISCD TDM, 
        the other ports can do =
DWDM and TDM, 
        for the connectivity =
matrix corresponding to a client port the only ODU label to be assigned =
(due to fixed MUX) is specified 
 
First, is this modeling correct? 
Second, how to make sure the label restriction are to be interpreted =
as ODU labels?
 
I think it is also important to show that the extensions are also =
working outside the framework they were born (WSON).
 
BR
=


Best Regards,
Cyril

> -----Original =
Message-----
> From: ccamp-bounces@ietf.org =
[mailto:ccamp-bounces@ietf.org] On Behalf
> Of ext =
Zhangfatai
> Sent: Thursday, September 22, 2011 11:17 AM
> =
To: ccamp@ietf.org
> Subject: Re: [CCAMP] I-D Action: =
draft-ietf-ccamp-gmpls-general-
> =
constraints-ospf-te-02.txt
>
> Hi CCAMPers,
>
> =
A new version has been submitted to address the comments from the =
WG
> discussion.
>
> We accepted Acee and Young's =
suggestion to introduce a new top-level
> node TLV (Generic Node =
Attribute TLV) to simplify things and a new
> section (Section 5) =
was added to describe scalability issue.
>
> More =
information from: http://www.ietf.org/id/draft-ietf-ccamp-gmpls-
> =
general-constraints-ospf-te-02.txt
>
> Please check out for =
details and comments are always welcome.
>
>
> =
Thanks
>
> Fatai
>
>
> -----Original =
Message-----
> From: ccamp-bounces@ietf.org =
[mailto:ccamp-bounces@ietf.org] On Behalf
> Of =
internet-drafts@ietf.org
> Sent: 2011=C4=EA=
9=D4=C2=
22=C8=D5=
 17:06
> To: i-d-announce@ietf.org
> Cc: =
ccamp@ietf.org
> Subject: [CCAMP] I-D Action: =
draft-ietf-ccamp-gmpls-general-
> =
constraints-ospf-te-02.txt
>
> A New Internet-Draft is =
available from the on-line Internet-Drafts
> directories. This =
draft is a work item of the Common Control and
> Measurement Plane =
Working Group of the =
IETF.
>
>       =
Title           : =
OSPF-TE Extensions for General Network Element
> =
Constraints
>       =
Author(s)       : Fatai =
Zhang
>          =
            &=
nbsp;    Young =
Lee
>          &n=
bsp;           &nb=
sp;    Jianrui =
Han
>          &n=
bsp;           &nb=
sp;    Greg =
Bernstein
>         &n=
bsp;           &nb=
sp;     Yunbin =
Xu
>       =
Filename        : =
draft-ietf-ccamp-gmpls-general-constraints-
> =
ospf-te-02.txt
>       =
Pages           : =
14
>       =
Date            : =
2011-09-22
>
>    Generalized Multiprotocol =
Label Switching can be used to control a
>    wide =
variety of technologies including packet switching (e.g.,
> =
MPLS),
>    time-division (e.g., SONET/SDH, OTN), =
wavelength (lambdas), and
>    spatial switching =
(e.g., incoming port or fiber to outgoing port =
or
>    fiber). 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 describes =
OSPF routing protocol extensions
> to
>    =
support these kinds of constraints under the control of =
Generalized
>    MPLS =
(GMPLS).
>
>
>
> A URL for this Internet-Draft =
is:
> =
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-general-
&g=
t; constraints-ospf-te-02.txt
>
> Internet-Drafts are also =
available by anonymous FTP at:
> =
ftp://ftp.ietf.org/internet-drafts/
>
> This Internet-Draft =
can be retrieved at:
> =
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-general-
>=
; constraints-ospf-te-02.txt
> =
_______________________________________________
> 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

------_=_NextPart_001_01CC7E97.A41D123B--

From eve.varma@alcatel-lucent.com  Thu Sep 29 04:49:43 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7976C21F8CBE for ; Thu, 29 Sep 2011 04:49:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kAhkCpmK6eHb for ; Thu, 29 Sep 2011 04:49:42 -0700 (PDT)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id D042321F8CBC for ; Thu, 29 Sep 2011 04:49:42 -0700 (PDT)
Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p8TBqW3x022344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 06:52:32 -0500 (CDT)
Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p8TBqVT2012837 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 29 Sep 2011 06:52:32 -0500
Received: from USNAVSXCHMBSA3.ndc.alcatel-lucent.com ([135.3.39.125]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Thu, 29 Sep 2011 06:52:31 -0500
From: "Varma, Eve L (Eve)" 
To: Lou Berger , CCAMP 
Date: Thu, 29 Sep 2011 06:52:29 -0500
Thread-Topic: [CCAMP] Poll on making G.709 Routing and Signaling drafts	WG documents
Thread-Index: Acx9/DV+jQ6dp5WsR9CyZ0GrQm6tnAAfOhYgAAlEN7A=
Message-ID: <84208699E388BB4B83AD8BEA84A04AC7250CEA2428@USNAVSXCHMBSA3.ndc.alcatel-lucent.com>
References: <4E834C0D.5030800@labn.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
Subject: [CCAMP] Poll on making G.709 Routing and Signaling drafts	WG	documents
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Sep 2011 11:49:43 -0000

Support both!

Regards,
Eve
-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L=
ou Berger
Sent: mercoled=EC 28 settembre 2011 18.32
To: CCAMP
Subject: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG docum=
ents

This message starts a two week poll on making the documents listed below
ccamp working group documents.  Please send a mail to the mailing list
indicating "yes/support to both" or "no/do not support either".  Of
course, you may also support one but not the other.  (We will assume
that you support/object to both if you don't specify.)

If indicating no, please state your technical reservations with the
document.

The documents being polled are:
http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-ospf-g709-07
http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-evolving-g709-09

The poll ends Wednesday October 12.

Please also bear in mind that WG adoption does not signify that work is
complete on the documents or that the technical details are fixed, but
rather that further development of the documents will take place based
on WG process.

Much thanks,
Lou (and Deborah)
_______________________________________________
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 pierre.peloso@alcatel-lucent.com  Thu Sep 29 05:05:26 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7947821F8C5A for ; Thu, 29 Sep 2011 05:05:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.719
X-Spam-Level: 
X-Spam-Status: No, score=-5.719 tagged_above=-999 required=5 tests=[AWL=0.530,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id utuVBf9Qh8u7 for ; Thu, 29 Sep 2011 05:05:26 -0700 (PDT)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id BA20121F8C58 for ; Thu, 29 Sep 2011 05:05:25 -0700 (PDT)
Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p8TC78GL020905 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 29 Sep 2011 14:08:15 +0200
Received: from FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Thu, 29 Sep 2011 14:07:57 +0200
From: "PELOSO, PIERRE (PIERRE)" 
To: CCAMP 
Date: Thu, 29 Sep 2011 14:07:56 +0200
Thread-Topic: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG documents
Thread-Index: Acx9/DWZGDSP8U/MQJmJSPjZZ6uDlQApCavA
Message-ID: 
References: <4E834C0D.5030800@labn.net>
In-Reply-To: <4E834C0D.5030800@labn.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR, en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83
Subject: Re: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG	documents
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Sep 2011 12:05:26 -0000

Support both=20


- p

-----Message d'origine-----
De : ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] De la part de L=
ou Berger
Envoy=E9 : mercredi 28 septembre 2011 18:32
=C0 : CCAMP
Objet : [CCAMP] Poll on making G.709 Routing and Signaling drafts WG docume=
nts

This message starts a two week poll on making the documents listed below cc=
amp working group documents.  Please send a mail to the mailing list indica=
ting "yes/support to both" or "no/do not support either".  Of course, you m=
ay also support one but not the other.  (We will assume that you support/ob=
ject to both if you don't specify.)

If indicating no, please state your technical reservations with the documen=
t.

The documents being polled are:
http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-ospf-g709-07
http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-evolving-g709-09

The poll ends Wednesday October 12.

Please also bear in mind that WG adoption does not signify that work is com=
plete on the documents or that the technical details are fixed, but rather =
that further development of the documents will take place based on WG proce=
ss.

Much thanks,
Lou (and Deborah)
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

From cyril.margaria@nsn.com  Thu Sep 29 05:31:32 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE1DC21F8CE5 for ; Thu, 29 Sep 2011 05:31:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.084
X-Spam-Level: 
X-Spam-Status: No, score=-6.084 tagged_above=-999 required=5 tests=[AWL=0.515,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PGliJc0uOa7A for ; Thu, 29 Sep 2011 05:31:32 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 9DE6621F8CE4 for ; Thu, 29 Sep 2011 05:31:31 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p8TCYL9M028534 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 14:34:21 +0200
Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p8TCYK6b031177; Thu, 29 Sep 2011 14:34:21 +0200
Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675);  Thu, 29 Sep 2011 14:34:12 +0200
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, 29 Sep 2011 14:34:10 +0200
Message-ID: 
In-Reply-To: <4E834C0D.5030800@labn.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [CCAMP] Poll on making G.709 Routing and Signaling drafts WGdocuments
Thread-Index: Acx9/DJJVs7VcE26SYyMXYx2JVEwpAAp9/YA
References: <4E834C0D.5030800@labn.net>
From: "Margaria, Cyril (NSN - DE/Munich)" 
To: "ext Lou Berger" , "CCAMP" 
X-OriginalArrivalTime: 29 Sep 2011 12:34:12.0012 (UTC) FILETIME=[17740EC0:01CC7EA4]
Subject: Re: [CCAMP] Poll on making G.709 Routing and Signaling drafts WGdocuments
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Sep 2011 12:31:33 -0000

Support both


> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of ext Lou Berger
> Sent: Wednesday, September 28, 2011 6:32 PM
> To: CCAMP
> Subject: [CCAMP] Poll on making G.709 Routing and Signaling drafts
> WGdocuments
>=20
> This message starts a two week poll on making the documents listed
> below ccamp working group documents.  Please send a mail to the
mailing
> list indicating "yes/support to both" or "no/do not support either".
> Of course, you may also support one but not the other.  (We will
assume
> that you support/object to both if you don't specify.)
>=20
> If indicating no, please state your technical reservations with the
> document.
>=20
> The documents being polled are:
> http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-ospf-g709-07
> http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-evolving-g709-09
>=20
> The poll ends Wednesday October 12.
>=20
> Please also bear in mind that WG adoption does not signify that work
is
> complete on the documents or that the technical details are fixed, but
> rather that further development of the documents will take place based
> on WG process.
>=20
> Much thanks,
> Lou (and Deborah)
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp

From dieter.beller@alcatel-lucent.com  Thu Sep 29 06:29:41 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFB3C21F8C7C for ; Thu, 29 Sep 2011 06:29:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.791
X-Spam-Level: 
X-Spam-Status: No, score=-4.791 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Do1nN9MHdOe for ; Thu, 29 Sep 2011 06:29:39 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id D039C21F8C44 for ; Thu, 29 Sep 2011 06:29:38 -0700 (PDT)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p8TDWNBU029303 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 29 Sep 2011 15:32:26 +0200
Received: from [149.204.106.170] (135.120.57.7) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.137.0; Thu, 29 Sep 2011 15:32:25 +0200
Message-ID: <4E847366.1000303@alcatel-lucent.com>
Date: Thu, 29 Sep 2011 15:32:22 +0200
From: Dieter Beller 
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Lou Berger , CCAMP 
References: <4E834C0D.5030800@labn.net>
In-Reply-To: <4E834C0D.5030800@labn.net>
Content-Type: multipart/related; boundary="------------000802030006080508070608"
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80
Subject: Re: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG documents
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Sep 2011 13:29:42 -0000

--------------000802030006080508070608
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


  
    
  
  
    yes to both

    

    

    Thanks,

    Dieter

    

    On 28.09.2011 18:32, Lou Berger wrote:
    

      
This message starts a two week poll on making the documents listed below
ccamp working group documents.  Please send a mail to the mailing list
indicating "yes/support to both" or "no/do not support either".  Of
course, you may also support one but not the other.  (We will assume
that you support/object to both if you don't specify.)

If indicating no, please state your technical reservations with the
document.

The documents being polled are:
http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-ospf-g709-07
http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-evolving-g709-09

The poll ends Wednesday October 12.

Please also bear in mind that WG adoption does not signify that work is
complete on the documents or that the technical details are fixed, but
rather that further development of the documents will take place based
on WG process.

Much thanks,
Lou (and Deborah)
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp


    

    

    
-- 

      
      
      

      

        
DIETER

                BELLER

          

            

              
 ALCATEL-LUCENT

                  PROJECT


                    MANAGER ASON/GMPLS CONTROL PLANE

                    NETWORKS GROUP, OPTICS DIVISION

                    TERRESTRIAL OPTICS UNIT

                    Lorenzstrasse 10

                    70435 Stuttgart, Germany

                  T:



                    +49 711 821 43125

                    M: +49 175 7266874

                  Dieter.Beller@alcatel-lucent.com

                      

                    Alcatel-Lucent Deutschland
                      AG

                      Domicile of the Company: Stuttgart · Local Court
                      Stuttgart HRB 4026

                      Chairman of the Supervisory Board: Michael
                      Oppenhoff

                      Board of Management: Alf Henryk Wulf (Chairman) ·
                      Hans-Jörg Daub ·

                    Dr. Rainer Fechner · Peter
                      Kury

                      

                    This e-mail and its
                      attachments, if any, may contain confidential
                      information.

                      If you have received this e-mail in error, please
                      notify us and delete or destroy the

                      e-mail and its attachments, if any, immediately.
                      If you have received this e-mail in

                      error, you must not forward or make use of the
                      e-mail and its attachments, if any.

              

            

          

        

      

    

  


--------------000802030006080508070608
Content-Type: image/jpeg; name="Corporate-sig-logo.jpg"
Content-Transfer-Encoding: base64
Content-ID: 
Content-Disposition: inline; filename="Corporate-sig-logo.jpg"

/9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAZAAA/+4ADkFkb2JlAGTAAAAA
Af/bAIQAAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgIC
AgICAgICAwMDAwMDAwMDAwEBAQEBAQECAQECAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMD
AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD/8AAEQgAGgEUAwERAAIRAQMRAf/EAaIAAAAG
AgMBAAAAAAAAAAAAAAcIBgUECQMKAgEACwEAAAYDAQEBAAAAAAAAAAAABgUEAwcCCAEJAAoL
EAACAQMEAQMDAgMDAwIGCXUBAgMEEQUSBiEHEyIACDEUQTIjFQlRQhZhJDMXUnGBGGKRJUOh
sfAmNHIKGcHRNSfhUzaC8ZKiRFRzRUY3R2MoVVZXGrLC0uLyZIN0k4Rlo7PD0+MpOGbzdSo5
OkhJSlhZWmdoaWp2d3h5eoWGh4iJipSVlpeYmZqkpaanqKmqtLW2t7i5usTFxsfIycrU1dbX
2Nna5OXm5+jp6vT19vf4+foRAAIBAwIEBAMFBAQEBgYFbQECAxEEIRIFMQYAIhNBUQcyYRRx
CEKBI5EVUqFiFjMJsSTB0UNy8BfhgjQlklMYY0TxorImNRlUNkVkJwpzg5NGdMLS4vJVZXVW
N4SFo7PD0+PzKRqUpLTE1OT0laW1xdXl9ShHV2Y4doaWprbG1ub2Z3eHl6e3x9fn90hYaHiI
mKi4yNjo+DlJWWl5iZmpucnZ6fkqOkpaanqKmqq6ytrq+v/aAAwDAQACEQMRAD8A3+Pfuvde
9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69
1737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737
r3Xvfuvde9+691737r3XvfuvdBd3V3L178fOrd59ydq52Pbmw9h4hsvnsm0T1ExVp4aKgx+P
pIrzV+XzGTqoaSjp09c9VOiDlvZ1y7y9u3Ne92/L2xxGbdLqTSi8BwJZmPBVRQWdjhVBPl09
bwS3MywQisjGg/1eg4nrV9ov5uX8w/5z90Zjr34TbW6/6R2LhKTKZ/I7w3njcLnDsnYeNhlS
t353Dvvd9LmdlbaxVLGv3Rho8U0kUn+TRvkGXVLmlJ7D+0/tpy7HuvuPPdblucjKixQs6eNO
xxBaQxFJpGPw1eShHeREDQC47Jtm3QCXcGaSQ4oKip9FAoSftPzx0vKP+cN8sPhR8jj0B88q
XqnuzbS0208zlOyuk6abF5vEbe3tiKHP4vPYilbFbYx+4aOjxmRRpMbV4bEV76Syzspj8pXJ
7Acje43KP9afbBr7brysqLb3hDI8kLFGRjqkaMllNJFllQcCoNdLZ2Oyv7X6nbtcb5Gl+BIN
KHjT7QSPl1slf6Zurf8ARH/p6/vxgv8AQ9/cf/SR/f8A+5b+A/3I/hP8c/j/AJfH9x9v/DP3
PH4/Pq/b0eT0e8QP6vb3+/v6r/TS/wBYPqfp/Ap3+Nq0aPSurFa6fOtM9BTwJvH+m0nx9WnT
51rSnRWch3x82aXqD5bbupPhHS13afUna+9NrfGHq9O+NjJF8n+rMRkMLDtLtSXczwDHdYz7
jxFdV1j4TJaq6J6L7a/lkQ+ybqlFqM46Eyq7R+TEXdvx72PT/GWlm6h391turc3fXcX+lna1
+i9/YvC0VVt7r6j2f9umY7C/jeenND/EKErAIyaiwSGQN7rVBQ5z0EmS77+d9P0J8nN+Y/4K
Yys7u617g3DtL45dIN8iev44/kN1HjtxbVx+G7brN9GnXb/XFTltuZTKZJcFXk12rFimJSWp
jPv3W6LUZx0MlV2X8lI/kD0/sOm+NlBN0Tu7qrPbp7Z7wPbm2vvOpuzaFUOI6zp9gGgTN72i
yUrrGMrSNHTESPIQggKy+61QUrXPQIZD5AfPqn+N3ePY1F8CsRXfIXZXc2b2f0r8e0+SXX0d
L3J1DQ7r2zisX2zU9l1NDTbe2PUZLb2QylcuHrkFWRjEDeM1aInut0WtK46Hyr7F+REPyX2R
1xT/AB5oar46ZzpvKbu3h8hl7S26lZsvt2kzn2dH1SvWb0i7jz1LWYYx1K5iFkpWMrKQhgZZ
PdaoKVrnovdX8iPn5D8Xuwez6X4BY6q+SO3O4a7Z+yPjePkh1/HTdgdV0u+MRhIO0YOz5aBN
t4F6vbFXV1642tSKo00ev6SxxN7rdFrSuOjIVfYffEPylxPVlL0HFV/Gyr6SrN75T5Mnsfb0
E2L7gh3lJhqbpxeqmgfdNYs+1Fjy38aDrQ/umD/ORMG91qgpWuei2z/In5+r8YMp2ZT/AAAo
JPkjF3NLsrE/HGX5I9ex0lX1YN8Q4KHtSr7QWifbdMr7bZ65seEacKol5Q6Pfut0WtK4+zox
q9hfIA/KmTq5ugKRfjGvSabzj+TQ7M241ZJ3G27/AOEt1AepfCN1JAm1Qcoc1qNESRCCZCQv
utUFK1z0XSl+Qn8wOT4x7X7JqfgDg6f5JZLuSn2duf45j5N7AloNt9USbyrsNUdqR9ppiTtr
KyQbehgrf4XChqWjm8g5U0/v3W6LWlcfZ0YWk7F+Q03yg3V1lU/HqjpfjZiulcfvLbXyRbtD
bklVuXuGo3LHjqnqJ+rUpm3TiqaDbzS15zTl6NDTiM6nqEVPdaoKVrnov9F8hPn0/wAaOm+y
8h8B8ZSfIfdvc2G2f298dYvkh19UxdV9R1m8dw4XIdr0XZcVE22d31NJt2hxuR/hFMBUpHkm
1HVSyx+/dbotaVx0PuO7I+Q0/wAj+y+ua/4709J8f9t9T7e3d153/H2dtyWfsHsvIV09NmOr
5+uzTrn9ttjaeJpRk5mkpAsaljeeNU91qgpWuegMoPkD87Kj45fHTsWr+B9HQ9/di9zbf2b3
10AfkPsCeDoPqKv3bvDF5nt1ex0pBgN/y43a2GxGS/guOjNarZoxetqObV7rdFqRXHQx0vaH
yVl787t2HP8AGeli6R2R1Zt3dPT3dTdt7YSfufsrJUs82X63bZK0c+X2LBiayJqZsnXloRoW
YI8c6BPdaoKcc9BLi++PnVU9IfFzeuR+DWKoO5Oze29u7V+SnT3+zDbDki+OXU+Qz+46HNdq
0W8o6WTC9mVWJ29j8dkP4JjmWtL5E0wLSQSN791ui1OcdChF2l8o27g+Sm0ZPi9jh1R1z11t
fcXx07THcm1UqPkPv7J7Xq8luHYNbtE0L5Hq6PCbphGL/iOTdoGTTVKHim0xe61QUGc9B3Q9
5/N6frX4hbjq/hJjKbsTtvsfbe3vlT1+vyA2M8Pxb66yE2TXP9h0u4jSLj+1ajCY+mgqv4Ti
z91JJL9ojPIfKPdbotTnHS4h7Z+VknYny1203xVx8ex+qtk7ZzfxX38/cu1Ei+UW8MpsbKZn
ObMyOENGcj1AuB3vSU+GauygkgeOo+6UNEvv3WqDGf8AY6S1D3l8yKjY/wAOs3UfC+Cm3h3H
urA4v5VbRfvLZSp8Vdr1mFrqzN7qiyv2rU/aL4ytgjCUON0zOT4L+V1ce63Rc5+zrXk/m+/N
PFbK/mPYDftH2D2bjP8AhsDB/HnedF13szZHZuc232Zu/uztHa27fkrt/dO69n7RzOydsQYf
4iU2PeI7jyWNhlmyLrTl5VdffunEWq09f9X+Hoato/JfvGi7+7f+PHQveG1+kG+YX8475J7R
HyT3PtrE9nU2yto7C+Efxg7FwWy+ssBu2V9gVW+e2crWRUuB/iZnoyRP4aWqqJI09+69QUqR
Wi/5elF81Pm/81PjvuHsOg6Y+R28e/st8L4PjUnyifG/Gf40bR6NpZu29x4qSiou3N0bl7bh
7frN1dj7SzMDRUnWuHEGGeWKWcwo7rH7rSqp4jjw6Lpg/lJ8sfj3gPlxuLrnuTeNU/yP/n3f
If4hYeGfYXV2/Mv0rjo9x5rMJunYdf2puLbOK3JvfcOz9kYvae2MDuPIrtmgpyjQxiRIIJvd
WoppXyWvRxuouxfmbnfnD/L+oflVtXcFB2FtnD/zXtv7Fl3NR7E683H3X1fhdsfDnO9Wb57D
2f1juzfPX2y93Vcu4avE1UNJMaaKWgaqigSOoAZyFY3mVJm0QlgGamrSCRVtNRWgzSorwr1q
iUOe2or506MHuvtXszM/PD+Uluv5A7LpPjrvPcfSH8y1t89YVXYeF3NhcHXYuf4z0G2xU7ox
c9PgMzNkcNHFkIVGp6Q1rQE+RHJO+aLDY9s324seXL47lssZXwrkxND4gKKzfpv3Locsmfi0
6hgjpyeOGOR0t38SEEUahFcZwc4OPy6D/eP8wPvPG7A+WGVxHY21TuPrn+cT8ffiR1jEmD2f
Uz/7L/2dlPieazAU9AaOT+PVefw3Ye6ZqTKuk1aYg8kM1qRTGQdM6Rj/AEtf8PQFVf8AMA+Z
9H8DvlB/M/h762NkqPau5e3uv9l/CCPqDZq4fpLIbb7xm6O23VdjdgVOVxPama37srHPFu7c
FNU1VJjK2i/ap6emp5EqT7reldQT+fTHvz5dfzWOr9sbB2nkd25rGYru35mfBjpLpf5P959F
/HbE7ly+F+TNX2FtPtHBZLqXpHtDeWyM/tvZuSxGFzeDylNU4qsqKerekmqJtInb3WwEP7D0
w757Y+YnYXdnSPxf7A+V0sPZHRn83PMdKbd+SO3OsNjbard07PynwD3P3LtEb36h0y9V5/cu
LyO9Jsch+0SllkaGaKnjqY1d9deooBIGCv8Al6H7/hQ7W75qfjn8beq9vy1mal7A7yo6KvpK
KlWKu3TuPEbTyFBtyiENMY4AMhk8/JKKYDxtULEwA8S+8sfulw7fFzVu283xVTabWSHbgiNI
pkb5UWMZ8lLDz6EPK4jFzLM/4Y+PoK5P8ugz2x0Z8dPjZt742fyrYqvMb7+RvyK33s7fPy0o
NgZ2kxNA+KxuNk3fkMd2XuOPH12Yrdm7O2pSVlRt7bFI9EMg9NHkq9o6Srnp8od3vMvNvOF3
vHvcyx2vKO02ssO1tOhZtTN4Stbx6gglllKLPcMH0BjDEC8avC89xdXbS7xhbWJSI9Qr8u0c
Kk01Ma04DIBFNvyb7hn+V/yn+auZ3Njtl5Dr/BR92brwe9U2dtXH7329iut5Jtr9LVf9/cbi
8bu7PR7jz0G3dtPR5WsyNHHQZfxwwxvTUUtNkHyby+vI3JPLlvZPcJusps4nh8WVoZGuKSXY
8BmaJPDQz3AeJY3LxVZiHkVz20gFlZ26oWEp0AipodWWxwFBqaoANR8zU2v+l7sL/oHv/u5/
EKv+Ff7NJ/oh8tp/N/o9/iX+lT+H/dX1faf3y/Zvfx+D/J/0+n2BP3BtP/BWfV6F8f8Acn1V
MU8fT9Nqp6+Dn11d/HPSHwIv6zaqZ8HV/tqaf8H+frdN987OgH1737r3Xvfuvde9+691737r
3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvf
uvde9+691737r3XvfuvdBG3QfSb4ruHBSdVbClw/yDqMvV95Y2bbGKmo+2p89tml2XmX7Ahl
pnTdC5HaVFFjpVq/KrUaCK2m49+63U/s6C/cHwY+HO6urNx9I7j+M/TGZ6m3buij3xn9hV2w
8FNt+u3vjtqYfY2O3olKaQNQ7vxuzsBRYynylO0VdBRUyRRyqgt7917U1a1NekDlv5Y38vjN
z7Oqcl8PuhpZthbewm09sNDsPE0S0u2ttOJNu4XIx0MdNHuHH4KYeSjjyIqxTS+uPS/q9+63
rb1PSw3N8BfhPvPcvbe8N2fFforce5e+sZRYjuXL5nrjbVfUdkUeOytBnaN91LUUDw5LIQZ3
FUlcKtl+7NZSQTmQywxuvuvam9TjpWdV/EL4xdIpsNeqOj+vNjydYf3/AP8AR/WYbAwLk9qP
2ocC3ZMuJy1SajJwz75O18d/FJDKz1n2MPkLeNbe60WJ49c+/viJ8X/lT/dP/ZkehOq+8P7i
fx3+5n+kzZuG3b/dj+9H8G/vF/BP4tTVH8P/AI1/d2h+58dvL9pFqvoFvdeDEcD0g8f/AC8/
g1ie0dgd1Yz4odFUHanVeB2htrrze1L15t+HMbSxHX2Dx22tgxYlkpBTRVmx9vYejosPVtG1
XjKWkgjppYkhjC+63qalKmnT6vwa+HK9t7673/2WTpN+3Oz9uZ/aXY2+JuvduT5TfO392U70
m7MfuuKahfH53+9dFI1PlJamGSfJU58VS8sfp9+61qalKmnTL13/AC+vhL1NjosR1z8Yen9p
4yn7L2P3FR0ON2lQmmx3Z3WVTkazrneWLjqRULi8vsOpy9U+HNP4o8aaiT7dYw7X91ssx4np
T9o/Cz4ld14Pem2+2vjr1F2FhOxN+4rtLe1DujZWGyi7i7Jwe26PZuJ33Xzz0xqTuyh2hQxY
pK9HSp/hoNMXMLuje60GYcD0D/8AMU+E+M+anxYzHS+Enxu2t57XrcTvHp7LVQlpsPg947Zo
6vHY/HZA0cUtRT4LM4HI1eNlaNJPthUJULHI0CI0oe0PuG/trznDvsitJtUiNBcotNTQuQSV
BoNaOqSKCRq0lKgMSDHar87fdicgmIijD5H0+YND/Lz60/8A4v8AZG/P5dP8xDafaPzZ2D2x
HndrPvii3icrAue3tWtunZed2jS7twWV3BlIcdvTHpLk471lNk3inoWkaCWUhYpM/edNo2v3
b9pp9l9uLqxNrP4Ji0nRCPDmSUxOqKWhainsaMFXoGVcsBxeRR7ptbQ7eyaWpTyGCDQgDH2U
49O+U2xR/NrKYD4ofy3fjBvPG9c02+Kffe/O2u0ammz/AGhvPcn8Or8NQbx7p7Eplq9uddbN
25jcvXfa4WgqWpqqrqHmSKorpYoQngvJPbiGXnn3e3q3fdzbGGC1tgUtoY9Su0VpAaSTyyMi
apnXUqqFLJErN1UOdvBvN1mUy6aBVwoHGirxYmgyeHyHW1l/w2h1x/w3J/sgf8Z/Y/ufq/0h
/wANi+4/0ufxn++n9/v4fq838P8A77f8ofn8/wDBv8i+4/3b7we/1493/wBdz/XS8Pu+o/sN
WPpdHg+Bq4avB/Hpp4v6mny6Bv72l/ev7yp+L4f6NKaf2efrmnVmnuG+inr3v3Xuve/de697
917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r
3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3X
uve/de697917r3v3XugA+RP/AB59D/zID/i6xf8AZRP/AB5/6D/wB/6uv+p/2n2KeU/+Sg3/
ACVfgP8AuB/a/n/R9elNr/af6Lw/Bx/4rpS9J/8AMv8AF/8AMpf87N/zJP8A5l/+mL/i1/8A
N3/V/wCGn2j5j/5Kr/7n8B/uZ/b+fxfL0/Pqtx/an4/9v8X59C17IumOv//Z
--------------000802030006080508070608--

From malcolm.betts@zte.com.cn  Thu Sep 29 08:11:14 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D36121F8E1A for ; Thu, 29 Sep 2011 08:11:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.638
X-Spam-Level: 
X-Spam-Status: No, score=-101.638 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7FKmEXdHiLIx for ; Thu, 29 Sep 2011 08:11:13 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 58B7521F8E19 for ; Thu, 29 Sep 2011 08:11:13 -0700 (PDT)
Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 41713473195744; Thu, 29 Sep 2011 23:12:34 +0800 (CST)
Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 75544.984958751; Thu, 29 Sep 2011 23:14:01 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p8TFDs45023792; Thu, 29 Sep 2011 23:13:54 +0800 (GMT-8) (envelope-from Malcolm.BETTS@zte.com.cn)
In-Reply-To: <4E834C0D.5030800@labn.net>
References: <4E834C0D.5030800@labn.net>
To: Lou Berger 
MIME-Version: 1.0
X-KeepSent: C306BB6C:B6A1A037-8525791A:00539C68; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009
Message-ID: 
From: Malcolm.BETTS@zte.com.cn
Date: Thu, 29 Sep 2011 11:13:33 -0400
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-09-29 23:13:58, Serialize complete at 2011-09-29 23:13:58
Content-Type: multipart/alternative; boundary="=_alternative 0053AC9C8525791A_="
X-MAIL: mse02.zte.com.cn p8TFDs45023792
Cc: CCAMP 
Subject: Re: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG	documents
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Sep 2011 15:11:14 -0000

This is a multipart message in MIME format.
--=_alternative 0053AC9C8525791A_=
Content-Type: text/plain; charset="US-ASCII"

Yes, support both.

Regards,

Malcolm




Lou Berger  
Sent by: ccamp-bounces@ietf.org
28/09/2011 12:32 PM

To
CCAMP 
cc

Subject
[CCAMP] Poll on making G.709 Routing and Signaling drafts WG    documents






This message starts a two week poll on making the documents listed below
ccamp working group documents.  Please send a mail to the mailing list
indicating "yes/support to both" or "no/do not support either".  Of
course, you may also support one but not the other.  (We will assume
that you support/object to both if you don't specify.)

If indicating no, please state your technical reservations with the
document.

The documents being polled are:
http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-ospf-g709-07
http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-evolving-g709-09

The poll ends Wednesday October 12.

Please also bear in mind that WG adoption does not signify that work is
complete on the documents or that the technical details are fixed, but
rather that further development of the documents will take place based
on WG process.

Much thanks,
Lou (and Deborah)
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp



--=_alternative 0053AC9C8525791A_=
Content-Type: text/html; charset="US-ASCII"

Yes, support both.



Regards,



Malcolm












Lou Berger <lberger@labn.net>


Sent by: ccamp-bounces@ietf.org

28/09/2011 12:32 PM








To

CCAMP <ccamp@ietf.org>




cc






Subject

[CCAMP] Poll on making G.709 Routing
and Signaling drafts WG        documents

















This message starts a two week poll on making the
documents listed below

ccamp working group documents.  Please send a mail to the mailing
list

indicating "yes/support to both" or "no/do not support either".
 Of

course, you may also support one but not the other.  (We will assume

that you support/object to both if you don't specify.)



If indicating no, please state your technical reservations with the

document.



The documents being polled are:

http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-ospf-g709-07

http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-evolving-g709-09



The poll ends Wednesday October 12.



Please also bear in mind that WG adoption does not signify that work is

complete on the documents or that the technical details are fixed, but

rather that further development of the documents will take place based

on WG process.



Much thanks,

Lou (and Deborah)

_______________________________________________

CCAMP mailing list

CCAMP@ietf.org

https://www.ietf.org/mailman/listinfo/ccamp






--=_alternative 0053AC9C8525791A_=--


From leeyoung@huawei.com  Thu Sep 29 08:16:05 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E5C21F8D94 for ; Thu, 29 Sep 2011 08:16:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.56
X-Spam-Level: 
X-Spam-Status: No, score=-6.56 tagged_above=-999 required=5 tests=[AWL=0.039,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYPF4ZwXKVYw for ; Thu, 29 Sep 2011 08:16:05 -0700 (PDT)
Received: from usaga04-in.huawei.com (usaga04-in.huawei.com [206.16.17.180]) by ietfa.amsl.com (Postfix) with ESMTP id 4DE1021F8D70 for ; Thu, 29 Sep 2011 08:16:05 -0700 (PDT)
Received: from huawei.com (usaga04-in [172.18.4.101]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSA00AYNIFYRX@usaga04-in.huawei.com> for ccamp@ietf.org; Thu, 29 Sep 2011 10:16:46 -0500 (CDT)
Received: from dfweml202-edg.china.huawei.com ([172.18.4.104]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug  8 2006)) with ESMTP id <0LSA00KU9IFX11@usaga04-in.huawei.com> for ccamp@ietf.org; Thu, 29 Sep 2011 10:16:46 -0500 (CDT)
Received: from DFWEML402-HUB.china.huawei.com (10.193.5.102) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 29 Sep 2011 08:16:46 -0700
Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by DFWEML402-HUB.china.huawei.com ([::1]) with mapi id 14.01.0270.001; Thu, 29 Sep 2011 08:16:38 -0700
Date: Thu, 29 Sep 2011 15:16:37 +0000
From: Leeyoung 
In-reply-to: <4E834C0D.5030800@labn.net>
X-Originating-IP: [10.47.131.9]
To: Lou Berger , CCAMP 
Message-id: <7AEB3D6833318045B4AE71C2C87E8E171817E21A@DFWEML501-MBX.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: en-US
Content-transfer-encoding: 7BIT
Accept-Language: en-US
Thread-topic: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG documents
Thread-index: AQHMffzqJFSDykXTbU+9Wa1Hisj6R5VkeYVA
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: <4E834C0D.5030800@labn.net>
Subject: Re: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG	documents
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Sep 2011 15:16:05 -0000

Support both.

Young

-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of Lou Berger
Sent: Wednesday, September 28, 2011 11:32 AM
To: CCAMP
Subject: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG documents

This message starts a two week poll on making the documents listed below
ccamp working group documents.  Please send a mail to the mailing list
indicating "yes/support to both" or "no/do not support either".  Of
course, you may also support one but not the other.  (We will assume
that you support/object to both if you don't specify.)

If indicating no, please state your technical reservations with the
document.

The documents being polled are:
http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-ospf-g709-07
http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-evolving-g709-09

The poll ends Wednesday October 12.

Please also bear in mind that WG adoption does not signify that work is
complete on the documents or that the technical details are fixed, but
rather that further development of the documents will take place based
on WG process.

Much thanks,
Lou (and Deborah)
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

From kam.lam@alcatel-lucent.com  Thu Sep 29 08:55:04 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CD6221F8E4A for ; Thu, 29 Sep 2011 08:55:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.277
X-Spam-Level: 
X-Spam-Status: No, score=-6.277 tagged_above=-999 required=5 tests=[AWL=0.322,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUOcDA-oYkxc for ; Thu, 29 Sep 2011 08:55:04 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id DE7D421F8CAB for ; Thu, 29 Sep 2011 08:55:03 -0700 (PDT)
Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p8TFvsL0017042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Sep 2011 10:57:54 -0500 (CDT)
Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p8TFvrCX009487 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 29 Sep 2011 10:57:54 -0500
Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB01.ndc.alcatel-lucent.com ([135.3.39.110]) with mapi; Thu, 29 Sep 2011 10:57:53 -0500
From: "Lam, Hing-Kam (Kam)" 
To: Lou Berger , CCAMP 
Date: Thu, 29 Sep 2011 10:56:32 -0500
Thread-Topic: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG documents
Thread-Index: Acx9/DSDg1+VqGM3QmeUu+nDq/cmqAAwRfDw
Message-ID: <7F76AEFB05C38145BABA0D545E3CFFD58007D949@USNAVSXCHMBSA2.ndc.alcatel-lucent.com>
References: <4E834C0D.5030800@labn.net>
In-Reply-To: <4E834C0D.5030800@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-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
Subject: Re: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG	documents
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Sep 2011 15:55:04 -0000

yes/support to both

--Kam

> -----Original Message-----
> From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
> Of Lou Berger
> Sent: Wednesday, September 28, 2011 12:32 PM
> To: CCAMP
> Subject: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG
> documents
>=20
> This message starts a two week poll on making the documents listed
> below
> ccamp working group documents.  Please send a mail to the mailing list
> indicating "yes/support to both" or "no/do not support either".  Of
> course, you may also support one but not the other.  (We will assume
> that you support/object to both if you don't specify.)
>=20
> If indicating no, please state your technical reservations with the
> document.
>=20
> The documents being polled are:
> http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-ospf-g709-07
> http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-evolving-g709-09
>=20
> The poll ends Wednesday October 12.
>=20
> Please also bear in mind that WG adoption does not signify that work is
> complete on the documents or that the technical details are fixed, but
> rather that further development of the documents will take place based
> on WG process.
>=20
> Much thanks,
> Lou (and Deborah)
> _______________________________________________
> CCAMP mailing list
> CCAMP@ietf.org
> https://www.ietf.org/mailman/listinfo/ccamp

From fred.gruman@us.fujitsu.com  Thu Sep 29 09:12:52 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03A9521F8C80 for ; Thu, 29 Sep 2011 09:12:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level: 
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iexWhI29IH4d for ; Thu, 29 Sep 2011 09:12:51 -0700 (PDT)
Received: from fncnmp03.fnc.fujitsu.com (fncnmp03.fnc.fujitsu.com [168.127.0.56]) by ietfa.amsl.com (Postfix) with ESMTP id 7102E21F8C6C for ; Thu, 29 Sep 2011 09:12:51 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.68,462,1312174800"; d="scan'208";a="480021745"
Received: from rchemxp01.fnc.net.local ([168.127.134.111]) by fncnmp01.fnc.fujitsu.com with ESMTP; 29 Sep 2011 11:15:38 -0500
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 29 Sep 2011 11:15:32 -0500
Message-ID: 
In-Reply-To: <4E834C0D.5030800@labn.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [CCAMP] Poll on making G.709 Routing and Signaling drafts WGdocuments
Thread-Index: Acx9/DbpbJvnCRmETiqyaZKXSoy5uQAxqdYg
References: <4E834C0D.5030800@labn.net>
From: "Gruman, Fred" 
To: "Lou Berger" , "CCAMP" 
Subject: Re: [CCAMP] Poll on making G.709 Routing and Signaling drafts WGdocuments
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Sep 2011 16:12:52 -0000

Yes/Support both.

Regards,

Fred Gruman
Fujitsu Network Communications, Inc.



-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf
Of Lou Berger
Sent: Wednesday, September 28, 2011 11:32 AM
To: CCAMP
Subject: [CCAMP] Poll on making G.709 Routing and Signaling drafts
WGdocuments

This message starts a two week poll on making the documents listed below
ccamp working group documents.  Please send a mail to the mailing list
indicating "yes/support to both" or "no/do not support either".  Of
course, you may also support one but not the other.  (We will assume
that you support/object to both if you don't specify.)

If indicating no, please state your technical reservations with the
document.

The documents being polled are:
http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-ospf-g709-07
http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-evolving-g709-09

The poll ends Wednesday October 12.

Please also bear in mind that WG adoption does not signify that work is
complete on the documents or that the technical details are fixed, but
rather that further development of the documents will take place based
on WG process.

Much thanks,
Lou (and Deborah)
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

From gyzhang@sina.com  Thu Sep 29 13:57:59 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0CCF21F8AF9 for ; Thu, 29 Sep 2011 13:57:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level: 
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m+EBiJk1cKmq for ; Thu, 29 Sep 2011 13:57:59 -0700 (PDT)
Received: from mail228-175.sinamail.sina.com.cn (mail228-175.sinamail.sina.com.cn [60.28.228.175]) by ietfa.amsl.com (Postfix) with ESMTP id EC82721F8B95 for ; Thu, 29 Sep 2011 13:57:57 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqoEAKuyhE6sEMk3/3poAEGCTYIYoj+BaYFTAQEBBQEBOzAgBgQJFCMECQIaBTISEYdvp3AIkXCFfTVhBIdwkSiMBQ
Received: from unknown (HELO mail2-55.sinamail.sina.com.cn) ([172.16.201.55]) by irtj11-90.sinamail.sina.com.cn with ESMTP; 30 Sep 2011 05:00:48 +0800
Received: by mail2-55.sinamail.sina.com.cn (Postfix, from userid 99) id 4094438C831; Fri, 30 Sep 2011 05:00:47 +0800 (CST)
Received: from gyzhang@sina.com([75.26.177.16]) by mail2-55.sinamail.sina.com.cn via HTTP;  Fri, 30 Sep 2011 05:00:47 +0800 (CST)
Date: Fri, 30 Sep 2011 05:00:47 +0800 
From: gyzhang@sina.com
To: ccamp@ietf.org, lberger@labn.net
MIME-Version: 1.0
X-Priority: 3
X-MessageID: 1317330047.24.35677
X-OriginaIP: 60.28.2.55
X-Mailer: Sina WebMail 4.0
Content-Type: multipart/alternative; boundary="=-sinamail_alt_d0f3231eaa79733efbc2be984b56c5b6"
Message-Id: <20110929210047.4094438C831@mail2-55.sinamail.sina.com.cn>
Subject: Re: [CCAMP] Poll on making G.709 Routing and Signaling drafts WGdocuments
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 29 Sep 2011 20:57:59 -0000

--=-sinamail_alt_d0f3231eaa79733efbc2be984b56c5b6
Content-Type: text/plain;
	charset=GBK
Content-Transfer-Encoding: base64
Content-Disposition: inline

WWVzLCBzdXBwb3J0IHRvIGJvdGggKGFzIGNvLWF1dGhvciBvZiBzaWduYWxsaW5nIGRyYWZ0KS4N
CiZuYnNwOw0KR3VveWluZw0KJm5ic3A7DQombmJzcDsNCjIwMTEtMDktMjkgDQoNCg0KZ3l6aGFu
ZyANCg0KDQpMb3UgQmVyZ2VyIA0KMjAxMS0wOS0yOCZuYnNwOyAwOTozMjoxMyANCkNDQU1QIA0K
Jm5ic3A7DQpbQ0NBTVBdIFBvbGwgb24gbWFraW5nIEcuNzA5IFJvdXRpbmcgYW5kIFNpZ25hbGlu
ZyBkcmFmdHMgV0dkb2N1bWVudHMgDQoNCg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtzdGFydHMm
bmJzcDthJm5ic3A7dHdvJm5ic3A7d2VlayZuYnNwO3BvbGwmbmJzcDtvbiZuYnNwO21ha2luZyZu
YnNwO3RoZSZuYnNwO2RvY3VtZW50cyZuYnNwO2xpc3RlZCZuYnNwO2JlbG93DQpjY2FtcCZuYnNw
O3dvcmtpbmcmbmJzcDtncm91cCZuYnNwO2RvY3VtZW50cy4mbmJzcDsmbmJzcDtQbGVhc2UmbmJz
cDtzZW5kJm5ic3A7YSZuYnNwO21haWwmbmJzcDt0byZuYnNwO3RoZSZuYnNwO21haWxpbmcmbmJz
cDtsaXN0DQppbmRpY2F0aW5nJm5ic3A7Inllcy9zdXBwb3J0Jm5ic3A7dG8mbmJzcDtib3RoIiZu
YnNwO29yJm5ic3A7Im5vL2RvJm5ic3A7bm90Jm5ic3A7c3VwcG9ydCZuYnNwO2VpdGhlciIuJm5i
c3A7Jm5ic3A7T2YNCmNvdXJzZSwmbmJzcDt5b3UmbmJzcDttYXkmbmJzcDthbHNvJm5ic3A7c3Vw
cG9ydCZuYnNwO29uZSZuYnNwO2J1dCZuYnNwO25vdCZuYnNwO3RoZSZuYnNwO290aGVyLiZuYnNw
OyZuYnNwOyhXZSZuYnNwO3dpbGwmbmJzcDthc3N1bWUNCnRoYXQmbmJzcDt5b3UmbmJzcDtzdXBw
b3J0L29iamVjdCZuYnNwO3RvJm5ic3A7Ym90aCZuYnNwO2lmJm5ic3A7eW91Jm5ic3A7ZG9uJ3Qm
bmJzcDtzcGVjaWZ5LikNCg0KSWYmbmJzcDtpbmRpY2F0aW5nJm5ic3A7bm8sJm5ic3A7cGxlYXNl
Jm5ic3A7c3RhdGUmbmJzcDt5b3VyJm5ic3A7dGVjaG5pY2FsJm5ic3A7cmVzZXJ2YXRpb25zJm5i
c3A7d2l0aCZuYnNwO3RoZQ0KZG9jdW1lbnQuDQoNClRoZSZuYnNwO2RvY3VtZW50cyZuYnNwO2Jl
aW5nJm5ic3A7cG9sbGVkJm5ic3A7YXJlOg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh
ZnQtY2VjY2FyZWxsaS1jY2FtcC1nbXBscy1vc3BmLWc3MDktMDcNCmh0dHA6Ly90b29scy5pZXRm
Lm9yZy9odG1sL2RyYWZ0LXpoYW5nLWNjYW1wLWdtcGxzLWV2b2x2aW5nLWc3MDktMDkNCg0KVGhl
Jm5ic3A7cG9sbCZuYnNwO2VuZHMmbmJzcDtXZWRuZXNkYXkmbmJzcDtPY3RvYmVyJm5ic3A7MTIu
DQoNClBsZWFzZSZuYnNwO2Fsc28mbmJzcDtiZWFyJm5ic3A7aW4mbmJzcDttaW5kJm5ic3A7dGhh
dCZuYnNwO1dHJm5ic3A7YWRvcHRpb24mbmJzcDtkb2VzJm5ic3A7bm90Jm5ic3A7c2lnbmlmeSZu
YnNwO3RoYXQmbmJzcDt3b3JrJm5ic3A7aXMNCmNvbXBsZXRlJm5ic3A7b24mbmJzcDt0aGUmbmJz
cDtkb2N1bWVudHMmbmJzcDtvciZuYnNwO3RoYXQmbmJzcDt0aGUmbmJzcDt0ZWNobmljYWwmbmJz
cDtkZXRhaWxzJm5ic3A7YXJlJm5ic3A7Zml4ZWQsJm5ic3A7YnV0DQpyYXRoZXImbmJzcDt0aGF0
Jm5ic3A7ZnVydGhlciZuYnNwO2RldmVsb3BtZW50Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtkb2N1
bWVudHMmbmJzcDt3aWxsJm5ic3A7dGFrZSZuYnNwO3BsYWNlJm5ic3A7YmFzZWQNCm9uJm5ic3A7
V0cmbmJzcDtwcm9jZXNzLg0KDQpNdWNoJm5ic3A7dGhhbmtzLA0KTG91Jm5ic3A7KGFuZCZuYnNw
O0RlYm9yYWgpDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KQ0NBTVAmbmJzcDttYWlsaW5nJm5ic3A7bGlzdA0KQ0NBTVBAaWV0Zi5vcmcNCmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCiZuYnNwOw==


--=-sinamail_alt_d0f3231eaa79733efbc2be984b56c5b6
Content-Type: text/html; 
	charset=GBK
Content-Transfer-Encoding: base64
Content-Disposition: inline

PERJVj48Rk9OVCBzdHlsZT0iRk9OVC1TSVpFOiAxNnB4IiBjb2xvcj0jMDAwMDgwPlllcywgc3Vw
cG9ydCB0byBib3RoIChhcyBjby1hdXRob3Igb2Ygc2lnbmFsbGluZyBkcmFmdCkuPC9GT05UPjwv
RElWPg0KPERJVj48Rk9OVCBzdHlsZT0iRk9OVC1TSVpFOiAxNnB4IiBjb2xvcj0jMDAwMDgwPjwv
Rk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc3R5bGU9IkZPTlQtU0laRTogMTZweCIgY29s
b3I9IzAwMDA4MD5HdW95aW5nPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBjb2xvcj0jMDAwMDgw
IHNpemU9MiBmYWNlPVZlcmRhbmE+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBjb2xv
cj0jMDAwMDgwIHNpemU9MiBmYWNlPVZlcmRhbmE+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48
Rk9OVCBjb2xvcj0jYzBjMGMwIHNpemU9MiBmYWNlPVZlcmRhbmE+MjAxMS0wOS0yOSA8L0ZPTlQ+
PC9ESVY+PEZPTlQgY29sb3I9IzAwMDA4MCBzaXplPTIgZmFjZT1WZXJkYW5hPg0KPEhSIHN0eWxl
PSJXSURUSDogMTIycHg7IEhFSUdIVDogMnB4IiBhbGlnbj1sZWZ0IFNJWkU9Mj4NCjwvRk9OVD4N
CjxESVY+PEZPTlQgY29sb3I9I2MwYzBjMCBzaXplPTIgZmFjZT1WZXJkYW5hPjxTUEFOPmd5emhh
bmc8L1NQQU4+IDwvRk9OVD48L0RJVj48Rk9OVCBjb2xvcj0jMDAwMDgwIHNpemU9MiBmYWNlPVZl
cmRhbmE+DQo8SFI+DQo8L0ZPTlQ+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+TG91
IEJlcmdlciA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBmYWNlPVZlcmRhbmE+MjAx
MS0wOS0yOCZuYnNwOyAwOTozMjoxMyA8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9MiBm
YWNlPVZlcmRhbmE+Q0NBTVAgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1W
ZXJkYW5hPiZuYnNwOzwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFu
YT5bQ0NBTVBdIFBvbGwgb24gbWFraW5nIEcuNzA5IFJvdXRpbmcgYW5kIFNpZ25hbGluZyBkcmFm
dHMgV0dkb2N1bWVudHMgPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTIgZmFjZT1WZXJk
YW5hPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yIGZhY2U9VmVyZGFuYT4NCjxESVY+
VGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtzdGFydHMmbmJzcDthJm5ic3A7dHdvJm5ic3A7d2VlayZu
YnNwO3BvbGwmbmJzcDtvbiZuYnNwO21ha2luZyZuYnNwO3RoZSZuYnNwO2RvY3VtZW50cyZuYnNw
O2xpc3RlZCZuYnNwO2JlbG93PC9ESVY+DQo8RElWPmNjYW1wJm5ic3A7d29ya2luZyZuYnNwO2dy
b3VwJm5ic3A7ZG9jdW1lbnRzLiZuYnNwOyZuYnNwO1BsZWFzZSZuYnNwO3NlbmQmbmJzcDthJm5i
c3A7bWFpbCZuYnNwO3RvJm5ic3A7dGhlJm5ic3A7bWFpbGluZyZuYnNwO2xpc3Q8L0RJVj4NCjxE
SVY+aW5kaWNhdGluZyZuYnNwOyJ5ZXMvc3VwcG9ydCZuYnNwO3RvJm5ic3A7Ym90aCImbmJzcDtv
ciZuYnNwOyJuby9kbyZuYnNwO25vdCZuYnNwO3N1cHBvcnQmbmJzcDtlaXRoZXIiLiZuYnNwOyZu
YnNwO09mPC9ESVY+DQo8RElWPmNvdXJzZSwmbmJzcDt5b3UmbmJzcDttYXkmbmJzcDthbHNvJm5i
c3A7c3VwcG9ydCZuYnNwO29uZSZuYnNwO2J1dCZuYnNwO25vdCZuYnNwO3RoZSZuYnNwO290aGVy
LiZuYnNwOyZuYnNwOyhXZSZuYnNwO3dpbGwmbmJzcDthc3N1bWU8L0RJVj4NCjxESVY+dGhhdCZu
YnNwO3lvdSZuYnNwO3N1cHBvcnQvb2JqZWN0Jm5ic3A7dG8mbmJzcDtib3RoJm5ic3A7aWYmbmJz
cDt5b3UmbmJzcDtkb24ndCZuYnNwO3NwZWNpZnkuKTwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+
SWYmbmJzcDtpbmRpY2F0aW5nJm5ic3A7bm8sJm5ic3A7cGxlYXNlJm5ic3A7c3RhdGUmbmJzcDt5
b3VyJm5ic3A7dGVjaG5pY2FsJm5ic3A7cmVzZXJ2YXRpb25zJm5ic3A7d2l0aCZuYnNwO3RoZTwv
RElWPg0KPERJVj5kb2N1bWVudC48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPlRoZSZuYnNwO2Rv
Y3VtZW50cyZuYnNwO2JlaW5nJm5ic3A7cG9sbGVkJm5ic3A7YXJlOjwvRElWPg0KPERJVj5odHRw
Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1jZWNjYXJlbGxpLWNjYW1wLWdtcGxzLW9zcGYt
ZzcwOS0wNzwvRElWPg0KPERJVj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGFu
Zy1jY2FtcC1nbXBscy1ldm9sdmluZy1nNzA5LTA5PC9ESVY+DQo8RElWPjwvRElWPg0KPERJVj5U
aGUmbmJzcDtwb2xsJm5ic3A7ZW5kcyZuYnNwO1dlZG5lc2RheSZuYnNwO09jdG9iZXImbmJzcDsx
Mi48L0RJVj4NCjxESVY+PC9ESVY+DQo8RElWPlBsZWFzZSZuYnNwO2Fsc28mbmJzcDtiZWFyJm5i
c3A7aW4mbmJzcDttaW5kJm5ic3A7dGhhdCZuYnNwO1dHJm5ic3A7YWRvcHRpb24mbmJzcDtkb2Vz
Jm5ic3A7bm90Jm5ic3A7c2lnbmlmeSZuYnNwO3RoYXQmbmJzcDt3b3JrJm5ic3A7aXM8L0RJVj4N
CjxESVY+Y29tcGxldGUmbmJzcDtvbiZuYnNwO3RoZSZuYnNwO2RvY3VtZW50cyZuYnNwO29yJm5i
c3A7dGhhdCZuYnNwO3RoZSZuYnNwO3RlY2huaWNhbCZuYnNwO2RldGFpbHMmbmJzcDthcmUmbmJz
cDtmaXhlZCwmbmJzcDtidXQ8L0RJVj4NCjxESVY+cmF0aGVyJm5ic3A7dGhhdCZuYnNwO2Z1cnRo
ZXImbmJzcDtkZXZlbG9wbWVudCZuYnNwO29mJm5ic3A7dGhlJm5ic3A7ZG9jdW1lbnRzJm5ic3A7
d2lsbCZuYnNwO3Rha2UmbmJzcDtwbGFjZSZuYnNwO2Jhc2VkPC9ESVY+DQo8RElWPm9uJm5ic3A7
V0cmbmJzcDtwcm9jZXNzLjwvRElWPg0KPERJVj48L0RJVj4NCjxESVY+TXVjaCZuYnNwO3RoYW5r
cyw8L0RJVj4NCjxESVY+TG91Jm5ic3A7KGFuZCZuYnNwO0RlYm9yYWgpPC9ESVY+DQo8RElWPl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPC9ESVY+DQo8RElW
PkNDQU1QJm5ic3A7bWFpbGluZyZuYnNwO2xpc3Q8L0RJVj4NCjxESVY+Q0NBTVBAaWV0Zi5vcmc8
L0RJVj4NCjxESVY+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcDwv
RElWPg0KPERJVj48L0RJVj48L0ZPTlQ+PC9ESVY+Jm5ic3A7


--=-sinamail_alt_d0f3231eaa79733efbc2be984b56c5b6--

From zhangfatai@huawei.com  Thu Sep 29 19:42:36 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0951C21F850B for ; Thu, 29 Sep 2011 19:42:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.307
X-Spam-Level: 
X-Spam-Status: No, score=-4.307 tagged_above=-999 required=5 tests=[AWL=0.639,  BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcNttxx25+uY for ; Thu, 29 Sep 2011 19:42:33 -0700 (PDT)
Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [119.145.14.66]) by ietfa.amsl.com (Postfix) with ESMTP id 26D9221F8507 for ; Thu, 29 Sep 2011 19:42:31 -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 <0LSB00LDIEBJIY@szxga03-in.huawei.com> for ccamp@ietf.org; Fri, 30 Sep 2011 10:45:20 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSB007LNEBJFU@szxga03-in.huawei.com> for ccamp@ietf.org; Fri, 30 Sep 2011 10:45:19 +0800 (CST)
Received: from szxeml206-edg.china.huawei.com ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA)	with ESMTP id ADZ91216; Fri, 30 Sep 2011 10:44:21 +0800
Received: from SZXEML402-HUB.china.huawei.com (10.82.67.32) by szxeml206-edg.china.huawei.com (172.24.2.58) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 30 Sep 2011 10:44:14 +0800
Received: from SZXEML520-MBX.china.huawei.com ([169.254.1.142]) by szxeml402-hub.china.huawei.com ([10.82.67.32]) with mapi id 14.01.0270.001; Fri, 30 Sep 2011 10:44:13 +0800
Date: Fri, 30 Sep 2011 02:44:13 +0000
From: Zhangfatai 
In-reply-to: 
X-Originating-IP: [172.24.2.40]
To: "Margaria, Cyril (NSN - DE/Munich)" , "ccamp@ietf.org" 
Message-id: 
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_BuyNgPDHLylCiO8HmLJE/w)"
Content-language: zh-CN
Accept-Language: zh-CN, en-US
Thread-topic: =?utf-8?B?IOetlOWkjTogIOetlOWkjTogIOetlOWkjTogW0NDQU1QXSBJLUQgQWN0aW9u?= =?utf-8?B?OiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWdlbmVyYWwtY29uc3RyYWludHMt?= =?utf-8?Q?ospf-te-02.txt?=
Thread-index: AQHMeQhw4fH7IgNgHEuaM0yhaE8MRpVfUxoggAGhYTmAAAbksIABGMsGgAIOXpCAAAelMIAAB0lQgAEHgRg=
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
X-CFilter-Loop: Reflected
References: <20110922090626.6373.58763.idtracker@ietfa.amsl.com>   A   A   A  
Subject: [CCAMP] =?utf-8?b?562U5aSNOiAg562U5aSNOiAg562U5aSNOiAg562U5aSN?= =?utf-8?q?=3A__I-D_Action=3A_draft-ietf-ccamp-gmpls-general-constraints-o?= =?utf-8?q?spf-te-02=2Etxt?=
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Sep 2011 02:42:36 -0000

--Boundary_(ID_BuyNgPDHLylCiO8HmLJE/w)
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: base64

SGkgQ3lyaWwsDQoNCg0KDQpJbnRlcmVzdGluZyBleGFtcGxlLiBUaGUgaGJyaWQgZXhhbXBsZSBp
biBSRkM1MzM5IGlzIFRETStQU0MgKHRoYXQgaXMgY29taW5nIHRvIHVzKSwgaW5zdGVhZCBvZiBU
RE0rRFdETSAoSSB0aGluayB5b3VyIGV4YW1wbGUgaXMgbm90IE9UTiBlcXVpcG1lbnQpLCA6LSkN
Cg0KDQoNCkluIHlvdXIgZXhhbXBsZSwgZm9yIHRoZSBURSBsaW5rIDUsIGl0IHdpbGwvY291bGQg
YWR2ZXJ0aXNlIFdTT04gbGlua3MgK0lBQ0QgYmFzZWQgb24gUkZDNjAwMShJbiB0aGlzIHdheSwg
dGhlcmUgaXMgc3RpbGwgaW1wbGljaXQgcmVsYXRpb25zaGlwIGJldHdlZW4gSVNDRHMgYW5kIGxh
YmVsIHN1Yi1UTFZzKS4NCg0KQ2VydGFpbnRseSwgSSB0aGluayB0aGVyZSBpcyBzdGlsbCBsb2Zz
IG9mIHdvcmsgdG8gYmUgZG9uZSBmb3IgTUxOIGNvbnRyb2wgYmVjYXVzZSBSRkM2MDAxIGlzIG5v
dCBzdWZmaWNpZW50Lg0KDQoNCg0KQW55d2F5LCB5b3VyIGV4YW1wbGUgaXMgYXBwcmVjaWF0ZWQu
DQoNCg0KDQoNCg0KVGhhbmtzDQoNCg0KDQpGYXRhaQ0KDQoNCg0KDQoNCg0KDQpfX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXw0K5Y+R5Lu25Lq6OiBNYXJnYXJpYSwgQ3lyaWwgKE5TTiAt
IERFL011bmljaCkgW2N5cmlsLm1hcmdhcmlhQG5zbi5jb21dDQrlj5HpgIHml7bpl7Q6IDIwMTHl
ubQ55pyIMjnml6UgMTk6MDUNCuWIsDogWmhhbmdmYXRhaTsgY2NhbXBAaWV0Zi5vcmcNCuS4u+mi
mDogUkU6IOetlOWkjTog562U5aSNOiDnrZTlpI06IFtDQ0FNUF0gSS1EIEFjdGlvbjogZHJhZnQt
aWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLWNvbnN0cmFpbnRzLW9zcGYtdGUtMDIudHh0DQoNCkhp
IEZhdGFpLA0KDQpGb3IgbXkgZXhhbXBsZSBJIHRvb2sgdGhlIGV4YW1wbGUgZnJvbSBSRkM1MzM5
IChhbHNvIGZvbGxvd2luZyB0aGUgbG9naWMgb2YgUkZDNDIwMiBzZWN0aW9uIDIuNC42KSwgYWRq
dXN0aW5nIHRoZSBjYXBhYmlsaXRpZXMgYW5kIGV4dGVuZGVkIHRoZSBudW1iZXIgb2YgcG9ydHM6
DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgTmV0d29yayBlbGVtZW50DQogICAgICAg
ICAgICAgICAgICAgICAgICAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLg0KICAgICAgICAg
ICAgICAgICAgICAgICAgOiAgICAgICAgICAgIC0tLS0tLS0tICAgICAgIDoNCiAgICAgICAgICAg
ICAgVERNICAgICAgIDogICAgICAgICAgIHwgIFRETSAgIHwgICAgICA6DQogICAgICAgICAgICBQ
b3J0MS0tLS0tLS0tLS0tLS08LT4tLS18I2EgICAgICB8ICAgICAgOg0KICAgICAgICAgICAgUG9y
dDItLS0tLS0tLS0tLS0tPC0+LS0tfCNiICAgICAgfCAgICAgIDoNCiAgICAgICAgICAgIFBvcnQz
LS0tLS0tLS0tLS0tLTwtPi0tLXwjYyAgICAgIHwgICAgICA6DQogICAgICAgICAgICBQb3J0NC0t
LS0tLS0tLS0tLS08LT4tLS18I2QgICAgICB8ICAgICAgOg0KICAgICAgICAgICAgICAgICAgICAg
ICAgOiAgKy0tPC0+LS0tfCNlICAgICAgfCAgICAgIDoNCiAgICAgICAgICAgICAgICAgICAgICAg
IDogIHwgICAgICAgICAtLS0tLS0tLSAgICAgICA6DQogICAgICAgICAgICAgICAgICAgICAgICA6
ICB8ICAgICAgICAtLS0tLS0tLS0tICAgICAgOg0KICAgICAgICAgICAgICBEV0RNICAgICAgOiAg
Ky0tPC0+LS18I2YgIERXRE0gIHwgICAgIDoNCiAgICAgICAgICAgIFBvcnQ1IC0tLS0tLS0tLS0t
LTwtPi0tfCNnICAgICAgICB8ICAgICA6DQogICAgICAgICAgICAgICAgICAgICAgICA6ICAgICAg
ICAgICAtLS0tLS0tLS0tICAgICAgOg0KICAgICAgICAgICAgICAgICAgICAgICAgOi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uLi4NCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgRmlndXJl
IDFhLiAgSHlicmlkIG5vZGUuDQoNCkZyb20gSVNDRCBwb2ludCBvZiB2aWV3Og0KVEUgbGluayAx
IChQb3J0MSk6DQogICAgIC0gSVNDRCBzdWItVExWOiBURE0gIChPRFUyKQ0KVEUgbGluayAyIChQ
b3J0MSk6DQogICAgIC0gSVNDRCBzdWItVExWOiBURE0gIChPRFUyKQ0K4oCmDQpURS1MaW5rIDUg
KHBvcnQgMikgOg0KICAgICAtIElTQ0QgIzEgc3ViLVRMVjogRFdETQ0KICAgICAtIElTQ0QgIzIg
c3ViLVRMVjogVERNLCBHLjcwOSBPRFVrIChPRFUzKQ0KDQpUaGUgSVNDRCAjMiByZXByZXNlbnQg
dGhlIERXRE0tVERNIGFkanVzdGVtZW50IGNhcGFiaWxpdHkNCkkgYW0gbGVhdmluZyBvdXQgaW4g
dGhpcyB0aHJlYWQgaG93IHRvIGtub3cgdGhlIE9FTyBjYXBhYmlsaXR5IG9mIHBvcnQgI2YvI2Ug
Oy0pDQoNCg0KV2l0aCB0aGUgZm9sbG93aW5nIGNvbm5lY3Rpdml0eSBtYXRyaXggKHdpdGggdGhl
IGZvbGxvd2luZyBjb252ZW50aW9uIDogKHtMaW5rIFNldCBBIzF9LHtMaW5rIHNldCBCIzF9KSwo
e0xpbmsgU2V0IEEjMn0se0xpbmsgc2V0IEIjMn0pLOKApg0KDQpNYXRyaXggIzEgKHtQb3J0IDF9
LCB7UG9ydCA1fSkNCk1hdHJpeCAjMiAoe1BvcnQgMn0sIHtQb3J0IDV9KQ0KTWF0cml4ICMzICh7
UG9ydCAzfSwge1BvcnQgNX0pDQpNYXRyaXggIzQgKHtQb3J0IDR9LCB7UG9ydCA1fSkNCg0KVEUt
TGluayA1IChwb3J0IDIpIDoNCiAgICAgLSBJU0NEICMxIHN1Yi1UTFY6IERXRE0NCiAgICAgLSBJ
U0NEICMyIHN1Yi1UTFY6IFRETSwgRy43MDkgT0RVayAoaGVyZSBPRFUzLCBiZWNhdXNlIG9mIHRo
ZSBwb3J0ICNlKQ0KICAgICAtIFBvcnQgTGFiZWwgcmVzdHJpY3Rpb24gOiBNYXRyaXggIzEsIFJl
c3RyaWN0aW9uVHlwZT1TSU1QTEVfTEFCRUwsIExhYmVsID0gVFMgOjE2LDEyLDgsNCAoY2FuIHdl
IGJlIHN1cmUgb2YgdGhlIGludGVycHJldGF0aW9uID8pDQogICAgIC0gUG9ydCBMYWJlbCByZXN0
cmljdGlvbiA6IE1hdHJpeCAjMiwgUmVzdHJpY3Rpb25UeXBlPVNJTVBMRV9MQUJFTCwgTGFiZWwg
PSBUUyA6MTUsMTEsNywzDQogICAgIC0gUG9ydCBMYWJlbCByZXN0cmljdGlvbiA6IE1hdHJpeCAj
MywgUmVzdHJpY3Rpb25UeXBlPVNJTVBMRV9MQUJFTCwgTGFiZWwgPSBUUyA6MTQsMTAsNiwyDQog
ICAgIC0gUG9ydCBMYWJlbCByZXN0cmljdGlvbiA6IE1hdHJpeCAjMywgUmVzdHJpY3Rpb25UeXBl
PVNJTVBMRV9MQUJFTCwgTGFiZWwgPSBUUyA6MTMsMDksNSwxDQpJIGFtIG5vdCAxMDAlIHN1cmUg
dGhhdCB3ZSBjYW4gYWx3YXlzIGludGVycHJldCB0aGUgbGFiZWwgYXMgT0RVIGxhYmVsLCBSRkM0
MjAyIHNlY3Rpb24gMi40Ljcgb24gaG93IHRvIGludGVycHJldCB0aGUNCkxhYmVsIG9uIGEgVEUt
TGluayB3b3VsZCBpbmRpY2F0ZSB0aGF0IGlmIG9uZSBlbmQgc3VwcG9ydCBURE0gYW5kIHRoZSBv
dGhlciBMU0MsIHRoZSBsYWJlbCBzaG91bGQgcmVwcmVzZW50IGEgbGFtYmRhLA0KYnV0IHRoZSBj
YXNlIHdoZXJlIHRoZXJlIGlzIHNldmVyYWwgSVNDRCBpcyBub3Qgd2VsbCBkZXNjcmliZWQuDQoN
ClRoZSBkcmFmdCBzaG91bGQgZGV0YWlsIHRoZSBydWxlcyBvbiB3aGljaCBsYWJlbCBlbmNvZGlu
ZyB0byB1c2UgaW4gY2FzZSBvZiBjb25uZWN0aXZpdHkgbWF0cml4IGluIHRoYXQgY2FzZS4NCg0K
SW4gdGhhdCBleGFtcGxlIHdlIGhhdmUgZml4ZWQgTVVYIE9EVTMtPk9EVTIgQU5EIGVhY2ggT0RV
MiBpcyBhc3NpZ25lZCB0byBhbiBwb3J0OiB0aGUgcG9ydCBsYWJlbCByZXN0cmljdGlvbiBpcyB1
c2VkLA0KUnVsZXMgZm9yIHBvcnQgbGFiZWwgcmVzdHJpY3Rpb24gc2hvdWxkIGFsbG93IHRvIGlu
dGVycHJldCBjb3JyZWN0bHkgdGhlIGxhYmVsLg0KDQpIb3dldmVyIG9uIGNhc2Ugb2YgRml4ZXMg
TVVYIGFuZCBmbGV4aWJsZSBPRFUyIHRvIHBvcnQgYXNzaWdubWVudCBvbmUgYWxsb3dlZCBwb3Nz
aWJpbGl0eSBpcyB0aGUgZm9sbG93aW5nIDoNCk1hdHJpeCAjMTEgKHtQb3J0IDEsIFBvcnQgMiwg
UG9ydCAzLCBQb3J0IDQsfSwge1BvcnQgNX0pDQoNClRFLUxpbmsgNSAocG9ydCAyKSA6DQogICAg
IC0gSVNDRCAjMSBzdWItVExWOiBEV0RNDQogICAgIC0gSVNDRCAjMiBzdWItVExWOiBURE0sIEcu
NzA5IE9EVWsgKE9EVTMpDQogICAgLSBBdmFpbGFibGUgIExhYmVscyA6IMKrIFRTIDoxNSwxMSw3
LDMgwrssIMKrIFRTIDoxNCwxMCw2LDIgwrssIMKrIFRTIDoxMywwOSw1LDEgwrssIMKrIFRTIDox
NiwxMiw4LDTigJ0NCiAgICAgLSBBdmFpbGFibGUgIExhYmVscyA6IGNoYW5uZWxzIChEV0RNKQ0K
DQpIb3cgdG8gbWFrZSBzdXJlIHRoZSBpbnRlcnByZXRhdGlvbiBpcyBjb3JyZWN0LCBUaGlzIGlz
IGFuIHR5cGljYWwgY2FzZSBjb3ZlcmVkIGJ5IHRoZSBnZW5lcmljIEdNUExTIFJGQ3MsIHNvDQog
SXQgc2hvdWxkICBiZSBjb3ZlcmVkIGluIG15IG9waW5pb24gYnkgdGhlIGdlbmVyaWMgZXh0ZW5z
aW9ucy4NCg0KDQoNCg0KDQpGcm9tOiBleHQgWmhhbmdmYXRhaSBbbWFpbHRvOnpoYW5nZmF0YWlA
aHVhd2VpLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBTZXB0ZW1iZXIgMjksIDIwMTEgMTI6MTkgUE0N
ClRvOiBNYXJnYXJpYSwgQ3lyaWwgKE5TTiAtIERFL011bmljaCk7IGNjYW1wQGlldGYub3JnDQpT
dWJqZWN0OiDnrZTlpI06IOetlOWkjTog562U5aSNOiBbQ0NBTVBdIEktRCBBY3Rpb246IGRyYWZ0
LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC1jb25zdHJhaW50cy1vc3BmLXRlLTAyLnR4dA0KDQoN
CkhpIEN5cmlsLA0KDQoNCg0KVXN1YWxseSwgb25lIFRFIGxpbmsgYWR2ZXJ0aXNlbWVudCAod2l0
aCBzZXJ2ZXJhbCBJU0NEcyBhbmQgbXVsdGlwbGUgbGFiZWwgc3ViLVRMVnMpIGhhcyB0aGUgc2Ft
ZSBTd2l0Y2hpbmcgQ2FwYWJpbGl0eSwgc28gdGhlcmUgaXMgaW1wbGljaXQgcmVsYXRpb25zaGlw
IGJldHdlZW4gdGhlIElTQ0RzIGFuZCBsYWJlbCBzdWItVExWcy4NCg0KDQoNCkkgd291bGQgbGlr
ZSB0byBjb25zaWRlciB5b3VyIGxhc3QgcG9pbnQgd2hlbiBJIHVkcGF0ZSB0aGlzIGRyYWZ0IGlu
IHRoZSBuZXh0IHZlcnNpb24uDQoNCg0KDQpCdXQgSSBoYXZlIGEgcXVlc3Rpb24gb24geW91ciBl
eGFtcGxlLCBkbyB5b3Ugc2VlIHRoYXQgdGhlcmUgaXMgYSBsaW5lIHBvcnQgKG9yIGludGVyZmFj
ZSkgY2FuIHN1cHBvcnQgYm90aCBEV0RNIGFuZCBURE0gaW4gdGhlIHdvcmxkPyBJIHRoaW5rIGlm
IGEgbGluZSBwb3J0IGNhbiBzdXBwb3J0IERXRE0sIHRoZSBXU09OIFRFIGxpbmsgKHdpdGggV1NP
TiByZWxhdGVkIGxhYmVsICh3YXZlbGVuZ3RoKSBpbmZvcm1hdGlvbikgc2hvdWxkIGJlIGFkdmVy
dGlzZWQgZm9yIHRoaXMgbGluZSBwb3J0OyBpZiBhIGxpbmUgcG9ydCBjYW4gc3VwcG9ydCBURE0s
IHRoZW4gdGhlIFRETSBURSBsaW5rIChlLmcuLCBPRFUpIGZvciB0aGlzIGxpbmUgcG9ydCBzaG91
bGQgYmUgYWR2ZXJ0aXNlZC4gRXZlbiB0aG91Z2ggdGhlcmUgd2FzIG9uZSBwb3J0IGNvdWxkIHN1
cHBvcnQgYm90aCBEV0RNIGFuZCBURE0sIEkgdGhpbmsgdXN1YWxseSBpdCBzaG91bGQgYWR2ZXJ0
aXNlIHRoZXNlIHR3byB0eXBlcyBvZiBjYXBhYmlsaXR5IHNlcGFyYXRlbHksIGllLiwgdXNlIHNl
cGVyYXRlIFRFIGxpbmsgYWR2ZXJ0aXNlbWVudHMuIHNvLCBJIHRoaW5rIHRoZXJlIGlzIGltcGxp
Y2l0IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBJU0NEcyBhbmQgbGFiZWwgc3ViLVRMVnMuDQoN
Cg0KDQpFdmVuIHRob3VnaCBJIHRoaW5rIHdlIHNob3VsZCBub3QgdXNlIGEga2luZCBvZiBzcGVj
aWFsIGFuZCBjb21wbGV4IGV4YW1wbGUgdG8gZXhwbGFpbiBzb21ldGhpbmcsIEkgd2lsbCBiZWFy
IHlvdXIgZXhhbXBsZSBpbiBteSBtaW5kIHdoZW4gSSB1cGRhdGUgdGhlIGRyYWZ0IChhcyBJIHNh
aWQgaW4gdGhlIHNlY29uZCBzZW50ZW5jZSBhYm92ZSkuDQoNCg0KDQpUaGFua3MNCg0KDQoNCkZh
dGFpDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCuWPkeS7tuS6
ujogTWFyZ2FyaWEsIEN5cmlsIChOU04gLSBERS9NdW5pY2gpIFtjeXJpbC5tYXJnYXJpYUBuc24u
Y29tXQ0K5Y+R6YCB5pe26Ze0OiAyMDEx5bm0OeaciDI55pelIDE3OjM2DQrliLA6IFpoYW5nZmF0
YWk7IGNjYW1wQGlldGYub3JnDQrkuLvpopg6IFJFOiDnrZTlpI06IOetlOWkjTogW0NDQU1QXSBJ
LUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWdlbmVyYWwtY29uc3RyYWludHMtb3Nw
Zi10ZS0wMi50eHQNCkhpLA0KDQpJZiBJIHVuZGVyc3RhbmQgY29ycmVjdGx5LCB5b3Ugc3RhdGUg
dGhhdCB0aGVyZSBpcyBub3QgZXhwbGljaXQgb3IgaW1wbGljaXQgcmVsYXRpb25zaGlwIGJldHdl
ZW4gdGhlIElTQ0QgYW5kIGxhYmVsIHN1Yi1UTFYsIGNvcnJlY3Q/DQpJIHdvdWxkIGV4cGVjdCBh
IG5ldyBnZW5lcmljIGRyYWZ0IHRvIGJlIGFwcGxpY2FibGUgdG8gYWxsIGFscmVhZHkgZGVmaW5l
ZCBsYWJlbCBmb3JtYXQsIHNvICBpdCBzZWVtcyBtaXNzaW5nIGluIHRoZSBkb2N1bWVudC4NCg0K
Q291bGQgeW91IGNvbnNpZGVyIG15IGxhc3QgcG9pbnQgcmVnYXJkaW5nIHRoZSBleGFtcGxlIG9m
IHN3aXRjaGluZyByZXN0cmljdGlvbiBpbiBHLjcwOSB2MiBhbmQgRFdETSBjb250ZXh0LCBpdCB3
b3VsZCBiZSBoZWxwZnVsDQogdG8gaGF2ZSBzb21lIHN0YXRlbWVudCBldmVuIHRob3VnaCBpdCB3
aWxsIG5vdCBiZSBpbiB0aGUgZG9jdW1lbnQuDQoNCkJlc3QgUmVnYXJkcy4NCg0KDQpGcm9tOiBl
eHQgWmhhbmdmYXRhaSBbbWFpbHRvOnpoYW5nZmF0YWlAaHVhd2VpLmNvbV0NClNlbnQ6IFdlZG5l
c2RheSwgU2VwdGVtYmVyIDI4LCAyMDExIDQ6MzAgQU0NClRvOiBNYXJnYXJpYSwgQ3lyaWwgKE5T
TiAtIERFL011bmljaCk7IGNjYW1wQGlldGYub3JnDQpTdWJqZWN0OiDnrZTlpI06IOetlOWkjTog
W0NDQU1QXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWdlbmVyYWwtY29uc3Ry
YWludHMtb3NwZi10ZS0wMi50eHQNCg0KDQpIaSBDeXJpbCwNCg0KDQoNCkkgYWdyZWUgb24geW91
ciBmaXJzdCBzdWdnZXN0aW9uLg0KDQoNCg0KU2Vjb25kbHksIHRoaXMgZHJhZnQgaXMgZ2VuZXJp
Yywgd2hlbiBpdCBuZWVkcyB0byBhZHZlcnRpc2UgbGFiZWwgaW5mb3JtYXRpb24gZm9yIHNvbWUg
c3BlY2lmaWMgdGVjaCAoZS5nLiwgVERNKSwgdGhlIGRvY3VtZW50IGFib3V0IHNwZWNpZmljIHRl
Y2ggY2FuIHJlZmVyIHRvIHRoaXMgZHJhZnQgYW5kIHNob3VsZCBkZWZpbmUgaG93IHRvIGNvcnJl
bGF0ZSB0aGUgSVNDRHMgYW5kIGxhYmVsIHN1Yi1UTFZzIGlmIHRoZXJlIGlzIG5vIGV4cGxpY2l0
IG9yIGltcGxpY2l0IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZW0gKEkgdGhpbmsgdGhlcmUgYXJl
IGxvdHMgb2YgcG90ZW50aWFsIHNvbHV0aW9ucyB0byBoYW5kbGUgdGhhdCwgaXQgaXMgcXVpdGUg
dGVjaCBzcGVjaWZpYyBzdHVmZikuDQoNCg0KDQoNCg0KRmF0YWkNCg0KDQoNClRoYW5rcw0KDQoN
Cg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQrlj5Hku7bkuro6IE1hcmdh
cmlhLCBDeXJpbCAoTlNOIC0gREUvTXVuaWNoKSBbY3lyaWwubWFyZ2FyaWFAbnNuLmNvbV0NCuWP
kemAgeaXtumXtDogMjAxMeW5tDnmnIgyN+aXpSAxNzozOA0K5YiwOiBaaGFuZ2ZhdGFpOyBjY2Ft
cEBpZXRmLm9yZw0K5Li76aKYOiBSRTog562U5aSNOiBbQ0NBTVBdIEktRCBBY3Rpb246IGRyYWZ0
LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC1jb25zdHJhaW50cy1vc3BmLXRlLTAyLnR4dA0KSGks
DQoNClRoYW5rcyBmb3IgdGhlIGFuc3dlciwNCg0KUGxlYXNlIHNlZSBpbmxpbmUNCg0KDQpGcm9t
OiBleHQgWmhhbmdmYXRhaSBbbWFpbHRvOnpoYW5nZmF0YWlAaHVhd2VpLmNvbV0NClNlbnQ6IFR1
ZXNkYXksIFNlcHRlbWJlciAyNywgMjAxMSAxMToxNyBBTQ0KVG86IE1hcmdhcmlhLCBDeXJpbCAo
TlNOIC0gREUvTXVuaWNoKTsgY2NhbXBAaWV0Zi5vcmcNClN1YmplY3Q6IOetlOWkjTogW0NDQU1Q
XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWdlbmVyYWwtY29uc3RyYWludHMt
b3NwZi10ZS0wMi50eHQNCg0KDQpIaSBDeXJpbCwNCg0KVGhhbmtzIGZvciB5b3VyIGNvbW1ldHMu
DQoNClBsZWFzZSBzZWUgaW4tbGluZSBiZWxvdy4NCg0KDQpGYXRhaQ0KDQpUaGFua3MNCg0KDQoN
Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCuWPkeS7tuS6ujogTWFy
Z2FyaWEsIEN5cmlsIChOU04gLSBERS9NdW5pY2gpIFtjeXJpbC5tYXJnYXJpYUBuc24uY29tXQ0K
5Y+R6YCB5pe26Ze0OiAyMDEx5bm0OeaciDI25pelIDE2OjAzDQrliLA6IFpoYW5nZmF0YWk7IGNj
YW1wQGlldGYub3JnDQrkuLvpopg6IFJFOiBbQ0NBTVBdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYt
Y2NhbXAtZ21wbHMtZ2VuZXJhbC1jb25zdHJhaW50cy1vc3BmLXRlLTAyLnR4dA0KDQpIaSwNCg0K
SSBoYXZlIHRoZSBmb2xsb3dpbmcgY29tbWVudHMvcXVlc3Rpb24gcmVnYXJkaW5nIHRoaXMgcmV2
aXNpb24NCg0KMy4yLiBBdmFpbGFibGUgTGFiZWxzOg0KDQpUaGUgdGV4dCBzdGF0ZSA6IOKAnFRo
ZSBBdmFpbGFibGUgTGFiZWxzIHN1Yi1UTFYgICBtYXkgb2NjdXIgYXQgbW9zdCBvbmNlIHdpdGhp
biB0aGUgbGluayBUTFYu4oCdDQoNCkhvdyB0byBlbmNvZGUgZGlmZmVyZW50IGxhYmVsIGZvcm1h
dCBpbiB0aGF0IGNhc2U/IEkgdGhpbmsgdGhlIGxhYmVsIGZvcm1hdCB3b3VsZCBkZXBlbmQNCm9u
IHRoZSBJU0NELCBhbmQgYXMgd2UgbWlnaHQgaGF2ZSBzZXZlcmFsIElTQ0QsIGhhdmluZyBzZXZl
cmFsIEF2YWlsYWJsZSBMYWJlbCBzdWItVExWIG1ha2Ugc2Vuc2UuDQpUaGlzIGFsc28gYXBwbHkg
dG8gMy4zLiBTaGFyZWQgQmFja3VwIExhYmVscy4NCg0KW0ZhdGFpXSBUaGlzICJtYXkiIHNob3Vs
ZCBiZSAiTUFZIiBhY2NvcmRpbmcgdG8gTG91J3Mgc3VnZ2VzdGlvbiwgc28gaXQgZG9lcyBub3Qg
cHJldmVudCB5b3UgdG8gaGF2ZSBzZXZlcmFsIGF2YWlsYWJsZSBsYWJlbCBzdWItVExWcy4NCg0K
W0N5cmlsXSBTdGF0aW5nIOKAnFRoZSBBdmFpbGFibGUgTGFiZWxzIHN1Yi1UTFYgICBNQVkgIG9j
Y3VyIG1vcmUgdGhhbiBvbmNlIHdpdGhpbiB0aGUgbGluayBUTFYu4oCdICBXb3VsZCBiZSBtb3Jl
IGFjY3VyYXRlIGFuZCBlYXNpZXIgdG8gdW5kZXJzdGFuZC4NCg0KDQoNCkluIGNhc2Ugb2Ygc2V2
ZXJhbCBJU0NEIGFyZSBwcmVzZW50IGZvciBhIGdpdmVuIGFkdmVydGlzZW1lbnQgaG93IHRvIGlu
dGVycHJldCB0aGUgbGFiZWwgZm9ybWF0IGluIHRoZQ0KbGFiZWwtcmVsYXRlZCBzdWItVExWcz8N
Cg0KW0ZhdGFpXSBJdCBpcyBlYXN5IHRvIGFjaGl2ZSB0aGF0LiBlLmcsIGluIFNESCBuZXR3b3Jr
LCBhIG5vZGUgY2FuIGFkdmVydGlzZSBzZXZlcmFsIElTQ0RzIHdpdGggb25lIG9yIG11bHRpcGxl
IGxhYmVsIHN1Yi1UTFZzIChJIGFzc3VtZSAiSUYiIGxhYmVsIGluZm9ybWF0aW9uIGlzIG5lZWRl
ZCB0byBiZSBhZHZlcnRpc2VkIGhlcmUpLCB3aHkgaXQgY2Fubm90IGludGVycHJldCB0aGUgbGFi
ZWxzIGFyZSBTREggbGFiZWxzPw0KDQpbQ3lyaWxdICBJZiB0aGVyZSBpcyAyIElTQ0Qgc3ViLVRM
ViBhbmQgMiBhdmFpbGFibGUgbGFiZWwgc3ViLVRMViwgaG93IHRvIHRlbGwgd2hpY2ggYXZhaWxh
YmxlIGxhYmVsIHN1Yi1UTFYgcmVsYXRlIHRvIHdoaWNoIElTQ0Qgc3ViLVRMVj8NCg0KDQoNCkNv
dWxkIHlvdSBjbGFyaWZ5IHRoaXMgcG9pbnQsIGl0IHdvdWxkIGJlIHVzZWZ1bCBmb3IgaW5zdGFu
Y2UgdG8gY29uc2lkZXIgdGhlIGV4YW1wbGUgb2YgYSBsaW5rIHN1cHBvcnRpbmcgU0RIDQoobm8g
VkM0LXN3aXRjaGluZyksIE9EVSAoRy43MDksIGFzIG9mIFJGQzQzMjgsIGFuZCBmb3IgdGhlIGN1
cnJlbnQgRy43MDkgdjMgbGFiZWwgZm9ybWF0KS4NCg0KDQoNCltGYXRhaV0gIERvIHlvdSBtZWFu
IHRvIGhhdmUgYW4gZXhhbXBsZSBvbiBoeWJyaWQgbm9kZT8gSSB3aWxsIG5vdCB1c2UgYSBjb21w
bGV4IGV4YW1wbGUgdG8gZXhwbGFpbiBhIGtpbmQgb2Ygc2ltcGxlIHRoaW5nIChJdCB3aWxsIGNv
bmZ1c2UgcGVvcGxlKS4NCg0KW0N5cmlsXSBJdCBtYXkgbm90IGJlIHNvIHNpbXBsZSwgSSBoYXZl
IHRyb3VibGUgdG8gaW50ZXJwcmV0IGxhYmVsIHdpdGhvdXQga25vd2luZyB0aGUgSVNDRCBjb25z
aWRlcmVkIGFuZCBJIGRvIG5vdCBzZWUgY2xlYXJseSB0aGUgcmVsYXRpb24gYmV0d2VlbiB0aGUg
dHdvIGluIHRoZSBkb2N1bWVudC4NCg0KVGhlIHRleHQgaXMgdmVyeSBmb2N1c2VkIG9uIFdTT04s
IHdoaWxlIGl0IGlzIGEgdmVyeSBpbnRlcmVzdGluZyBleGFtcGxlLCBoYXZpbmcgb3RoZXIgdGVj
aG5vbG9neSAoT1ROIGZvcg0KZXhhbXBsZSB3b3VsZCBoZWxwIHRvIHNob3cgdGhhdCB0aGUgc29s
dXRpb24gaXMgZ2VuZXJpYy4NCg0KW0ZhdGFpXSBJIHRoaW5rIG9uZSB0eXBpY2FsIGV4YW1wbGUg
aXMgc3VmZmljaWVudCBmb3IgcGVvcGxlIHRvIHVuZGVyc3RhbmQgdGhpbmdzLiBURE0gbmV0d29y
ayBpcyBkaWZmZXJlbnQgZnJvbSBXU09OIG5ldHdvcmsuIEluIFRETSBuZXR3b3JrLCB1c3VhbGx5
IGl0IHdpbGwgbm90IGFkdmVydGlzZSBsYWJlbCBpbmZvcm1hdGlvbiBldmVuIHRob3VnaCBsYWJl
bCBpbmZvcm1hdGlvbiBjb3VsZCBiZSBhZHZlcnRpc2VkLg0KDQpbQ3lyaWxdIFRoZXkgYXJlIGlu
ZGVlZCBkaWZmZXJlbnQsIGJ1dCBmcm9tIGxhYmVsIHBvaW50IG9mIHZpZXcgaXQgc2hvdWxkIG5v
dCBtYWtlIGEgZGlmZmVyZW5jZS4gQSB1c3VhbCB1c2UgY2FzZSBvZiBjb25uZWN0aXZpdHkgbWF0
cml4IHdvdWxkIGJlIGZvciBleGFtcGxlIG9uIGNsaWVudCBjYXJkcyB3aXRoIHN3aXRjaGluZyBy
ZXN0cmljdGlvbiA6IGZpeGVkIE11bHRpcGxleCBhbmQgbGFiZWwgYXNzaWdubWVudCBkdWUgdG8g
dGhlIGZpeGVkIE1VWCAoT0RVMi0+T0RVMSBmb3IgaW5zdGFuY2UpICBvbiBEV0RNIG5vZGUgOg0K
DQp0aGUgcmVzdHJpY3Rpb24gY2FuIGJlIG1vZGVsZWQgYXMgb25lIGNvbm5lY3Rpdml0eSBtYXRy
aXggcGVyIGNsaWVudCBwb3J0LA0KDQogICAgICAgIHRoZSBjbGllbnQgcG9ydCBoYXZlIHRoZW4g
SVNDRCBURE0sDQoNCiAgICAgICAgdGhlIG90aGVyIHBvcnRzIGNhbiBkbyBEV0RNIGFuZCBURE0s
DQoNCiAgICAgICAgZm9yIHRoZSBjb25uZWN0aXZpdHkgbWF0cml4IGNvcnJlc3BvbmRpbmcgdG8g
YSBjbGllbnQgcG9ydCB0aGUgb25seSBPRFUgbGFiZWwgdG8gYmUgYXNzaWduZWQgKGR1ZSB0byBm
aXhlZCBNVVgpIGlzIHNwZWNpZmllZA0KDQoNCg0KRmlyc3QsIGlzIHRoaXMgbW9kZWxpbmcgY29y
cmVjdD8NCg0KU2Vjb25kLCBob3cgdG8gbWFrZSBzdXJlIHRoZSBsYWJlbCByZXN0cmljdGlvbiBh
cmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgT0RVIGxhYmVscz8NCg0KDQoNCkkgdGhpbmsgaXQgaXMg
YWxzbyBpbXBvcnRhbnQgdG8gc2hvdyB0aGF0IHRoZSBleHRlbnNpb25zIGFyZSBhbHNvIHdvcmtp
bmcgb3V0c2lkZSB0aGUgZnJhbWV3b3JrIHRoZXkgd2VyZSBib3JuIChXU09OKS4NCg0KDQoNCkJS
DQoNCg0KQmVzdCBSZWdhcmRzLA0KQ3lyaWwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t
LQ0KPiBGcm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAtYm91bmNlc0Bp
ZXRmLm9yZ10gT24gQmVoYWxmDQo+IE9mIGV4dCBaaGFuZ2ZhdGFpDQo+IFNlbnQ6IFRodXJzZGF5
LCBTZXB0ZW1iZXIgMjIsIDIwMTEgMTE6MTcgQU0NCj4gVG86IGNjYW1wQGlldGYub3JnDQo+IFN1
YmplY3Q6IFJlOiBbQ0NBTVBdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZ2Vu
ZXJhbC0NCj4gY29uc3RyYWludHMtb3NwZi10ZS0wMi50eHQNCj4NCj4gSGkgQ0NBTVBlcnMsDQo+
DQo+IEEgbmV3IHZlcnNpb24gaGFzIGJlZW4gc3VibWl0dGVkIHRvIGFkZHJlc3MgdGhlIGNvbW1l
bnRzIGZyb20gdGhlIFdHDQo+IGRpc2N1c3Npb24uDQo+DQo+IFdlIGFjY2VwdGVkIEFjZWUgYW5k
IFlvdW5nJ3Mgc3VnZ2VzdGlvbiB0byBpbnRyb2R1Y2UgYSBuZXcgdG9wLWxldmVsDQo+IG5vZGUg
VExWIChHZW5lcmljIE5vZGUgQXR0cmlidXRlIFRMVikgdG8gc2ltcGxpZnkgdGhpbmdzIGFuZCBh
IG5ldw0KPiBzZWN0aW9uIChTZWN0aW9uIDUpIHdhcyBhZGRlZCB0byBkZXNjcmliZSBzY2FsYWJp
bGl0eSBpc3N1ZS4NCj4NCj4gTW9yZSBpbmZvcm1hdGlvbiBmcm9tOiBodHRwOi8vd3d3LmlldGYu
b3JnL2lkL2RyYWZ0LWlldGYtY2NhbXAtZ21wbHMtDQo+IGdlbmVyYWwtY29uc3RyYWludHMtb3Nw
Zi10ZS0wMi50eHQNCj4NCj4gUGxlYXNlIGNoZWNrIG91dCBmb3IgZGV0YWlscyBhbmQgY29tbWVu
dHMgYXJlIGFsd2F5cyB3ZWxjb21lLg0KPg0KPg0KPiBUaGFua3MNCj4NCj4gRmF0YWkNCj4NCj4N
Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogY2NhbXAtYm91bmNlc0BpZXRm
Lm9yZyBbbWFpbHRvOmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZg0KPiBPZiBpbnRl
cm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj4gU2VudDogMjAxMeW5tDnmnIgyMuaXpSAxNzowNg0KPiBU
bzogaS1kLWFubm91bmNlQGlldGYub3JnDQo+IENjOiBjY2FtcEBpZXRmLm9yZw0KPiBTdWJqZWN0
OiBbQ0NBTVBdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC0NCj4g
Y29uc3RyYWludHMtb3NwZi10ZS0wMi50eHQNCj4NCj4gQSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMg
YXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzDQo+IGRpcmVjdG9yaWVz
LiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBDb21tb24gQ29udHJvbCBhbmQNCj4g
TWVhc3VyZW1lbnQgUGxhbmUgV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4NCj4NCj4gICAgICAg
VGl0bGUgICAgICAgICAgIDogT1NQRi1URSBFeHRlbnNpb25zIGZvciBHZW5lcmFsIE5ldHdvcmsg
RWxlbWVudA0KPiBDb25zdHJhaW50cw0KPiAgICAgICBBdXRob3IocykgICAgICAgOiBGYXRhaSBa
aGFuZw0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIFlvdW5nIExlZQ0KPiAgICAgICAgICAg
ICAgICAgICAgICAgICAgIEppYW5ydWkgSGFuDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAg
R3JlZyBCZXJuc3RlaW4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICBZdW5iaW4gWHUNCj4g
ICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLWNv
bnN0cmFpbnRzLQ0KPiBvc3BmLXRlLTAyLnR4dA0KPiAgICAgICBQYWdlcyAgICAgICAgICAgOiAx
NA0KPiAgICAgICBEYXRlICAgICAgICAgICAgOiAyMDExLTA5LTIyDQo+DQo+ICAgIEdlbmVyYWxp
emVkIE11bHRpcHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nIGNhbiBiZSB1c2VkIHRvIGNvbnRyb2wg
YQ0KPiAgICB3aWRlIHZhcmlldHkgb2YgdGVjaG5vbG9naWVzIGluY2x1ZGluZyBwYWNrZXQgc3dp
dGNoaW5nIChlLmcuLA0KPiBNUExTKSwNCj4gICAgdGltZS1kaXZpc2lvbiAoZS5nLiwgU09ORVQv
U0RILCBPVE4pLCB3YXZlbGVuZ3RoIChsYW1iZGFzKSwgYW5kDQo+ICAgIHNwYXRpYWwgc3dpdGNo
aW5nIChlLmcuLCBpbmNvbWluZyBwb3J0IG9yIGZpYmVyIHRvIG91dGdvaW5nIHBvcnQgb3INCj4g
ICAgZmliZXIpLiBJbiBzb21lIG9mIHRoZXNlIHRlY2hub2xvZ2llcyBuZXR3b3JrIGVsZW1lbnRz
IGFuZCBsaW5rcyBtYXkNCj4gICAgaW1wb3NlIGFkZGl0aW9uYWwgcm91dGluZyBjb25zdHJhaW50
cyBzdWNoIGFzIGFzeW1tZXRyaWMgc3dpdGNoDQo+ICAgIGNvbm5lY3Rpdml0eSwgbm9uLWxvY2Fs
IGxhYmVsIGFzc2lnbm1lbnQsIGFuZCBsYWJlbCByYW5nZQ0KPiBsaW1pdGF0aW9ucw0KPiAgICBv
biBsaW5rcy4gVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgT1NQRiByb3V0aW5nIHByb3RvY29sIGV4
dGVuc2lvbnMNCj4gdG8NCj4gICAgc3VwcG9ydCB0aGVzZSBraW5kcyBvZiBjb25zdHJhaW50cyB1
bmRlciB0aGUgY29udHJvbCBvZiBHZW5lcmFsaXplZA0KPiAgICBNUExTIChHTVBMUykuDQo+DQo+
DQo+DQo+IEEgVVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlzOg0KPiBodHRwOi8vd3d3Lmll
dGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWdlbmVyYWwtDQo+
IGNvbnN0cmFpbnRzLW9zcGYtdGUtMDIudHh0DQo+DQo+IEludGVybmV0LURyYWZ0cyBhcmUgYWxz
byBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCj4gZnRwOi8vZnRwLmlldGYub3JnL2lu
dGVybmV0LWRyYWZ0cy8NCj4NCj4gVGhpcyBJbnRlcm5ldC1EcmFmdCBjYW4gYmUgcmV0cmlldmVk
IGF0Og0KPiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtY2Nh
bXAtZ21wbHMtZ2VuZXJhbC0NCj4gY29uc3RyYWludHMtb3NwZi10ZS0wMi50eHQNCj4gX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gQ0NBTVAgbWFpbGlu
ZyBsaXN0DQo+IENDQU1QQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v
bGlzdGluZm8vY2NhbXANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX18NCj4gQ0NBTVAgbWFpbGluZyBsaXN0DQo+IENDQU1QQGlldGYub3JnDQo+IGh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXANCg==

--Boundary_(ID_BuyNgPDHLylCiO8HmLJE/w)
Content-type: text/html; charset=utf-8
Content-transfer-encoding: base64

PGh0bWwgZGlyPSJsdHIiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUi
IGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8c3R5bGU+QGZvbnQtZmFjZSB7
DQoJZm9udC1mYW1pbHk6IFNpbVN1bjsNCn0NCkBmb250LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBT
aW1TdW47DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZhbWlseTogQ2FsaWJyaTsNCn0NCkBmb250
LWZhY2Ugew0KCWZvbnQtZmFtaWx5OiBUYWhvbWE7DQp9DQpAZm9udC1mYWNlIHsNCglmb250LWZh
bWlseTogQFNpbVN1bjsNCn0NCkBwYWdlIFdvcmRTZWN0aW9uMSB7bWFyZ2luOiA3Mi4wcHQgNzIu
MHB0IDcyLjBwdCA3Mi4wcHQ7IH0NClAuTXNvTm9ybWFsIHsNCglNQVJHSU46IDBjbSAwY20gMHB0
OyBGT05ULUZBTUlMWTogU2ltU3VuOyBGT05ULVNJWkU6IDEycHQNCn0NCkxJLk1zb05vcm1hbCB7
DQoJTUFSR0lOOiAwY20gMGNtIDBwdDsgRk9OVC1GQU1JTFk6IFNpbVN1bjsgRk9OVC1TSVpFOiAx
MnB0DQp9DQpESVYuTXNvTm9ybWFsIHsNCglNQVJHSU46IDBjbSAwY20gMHB0OyBGT05ULUZBTUlM
WTogU2ltU3VuOyBGT05ULVNJWkU6IDEycHQNCn0NCkE6bGluayB7DQoJQ09MT1I6IGJsdWU7IFRF
WFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLk1zb0h5cGVybGluayB7DQoJQ09MT1I6
IGJsdWU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9DQpBOnZpc2l0ZWQgew0KCUNPTE9S
OiBwdXJwbGU7IFRFWFQtREVDT1JBVElPTjogdW5kZXJsaW5lDQp9DQpTUEFOLk1zb0h5cGVybGlu
a0ZvbGxvd2VkIHsNCglDT0xPUjogcHVycGxlOyBURVhULURFQ09SQVRJT046IHVuZGVybGluZQ0K
fQ0KUC5tc29jaHBkZWZhdWx0IHsNCglNQVJHSU46IDBjbSAwY20gMHB0OyBGT05ULUZBTUlMWTog
U2ltU3VuOyBGT05ULVNJWkU6IDEwcHQNCn0NCkxJLm1zb2NocGRlZmF1bHQgew0KCU1BUkdJTjog
MGNtIDBjbSAwcHQ7IEZPTlQtRkFNSUxZOiBTaW1TdW47IEZPTlQtU0laRTogMTBwdA0KfQ0KRElW
Lm1zb2NocGRlZmF1bHQgew0KCU1BUkdJTjogMGNtIDBjbSAwcHQ7IEZPTlQtRkFNSUxZOiBTaW1T
dW47IEZPTlQtU0laRTogMTBwdA0KfQ0KU1BBTi5lbWFpbHN0eWxlMTggew0KCUZPTlQtRkFNSUxZ
OiAiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOyBDT0xPUjogIzFmNDk3ZA0KfQ0KU1BBTi5lbWFpbHN0
eWxlMjAgew0KCUZPTlQtRkFNSUxZOiAiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOyBDT0xPUjogIzFm
NDk3ZA0KfQ0KU1BBTi5FbWFpbFN0eWxlMjEgew0KCUZPTlQtRkFNSUxZOiAiQ2FsaWJyaSIsInNh
bnMtc2VyaWYiOyBDT0xPUjogIzFmNDk3ZA0KfQ0KLm1zb2NocGRlZmF1bHQgew0KCUZPTlQtU0la
RTogMTBwdA0KfQ0KPC9zdHlsZT48c3R5bGUgaWQ9Im93YVBhcmFTdHlsZSI+UCB7DQoJTUFSR0lO
LVRPUDogMHB4OyBNQVJHSU4tQk9UVE9NOiAwcHgNCn0NCjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9k
eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgZlBTdHlsZT0iMSIgb2Nz
aT0iMCI+DQo8ZGl2IHN0eWxlPSJkaXJlY3Rpb246IGx0cjtmb250LWZhbWlseTogVGFob21hO2Nv
bG9yOiAjMDAwMDAwO2ZvbnQtc2l6ZTogMTBwdDsiPg0KPHA+SGkgQ3lyaWwsPC9wPg0KPHA+Jm5i
c3A7PC9wPg0KPHA+SW50ZXJlc3RpbmcgZXhhbXBsZS4gVGhlIGhicmlkIGV4YW1wbGUgaW4gUkZD
NTMzOSBpcyBURE0mIzQzO1BTQyZuYnNwOyh0aGF0IGlzIGNvbWluZyB0byB1cyksJm5ic3A7aW5z
dGVhZCBvZiZuYnNwO1RETSYjNDM7RFdETSAoSSB0aGluayB5b3VyIGV4YW1wbGUgaXMgbm90IE9U
TiBlcXVpcG1lbnQpLCA6LSk8L3A+DQo8cD4mbmJzcDs8L3A+DQo8cD5JbiB5b3VyIGV4YW1wbGUs
IGZvciB0aGUgVEUgbGluayA1LCBpdCB3aWxsL2NvdWxkIGFkdmVydGlzZSZuYnNwO1dTT04gbGlu
a3MgJiM0MztJQUNEIGJhc2VkIG9uIFJGQzYwMDEoSW4gdGhpcyB3YXksIHRoZXJlIGlzIHN0aWxs
IGltcGxpY2l0Jm5ic3A7cmVsYXRpb25zaGlwIGJldHdlZW4gSVNDRHMgYW5kIGxhYmVsIHN1Yi1U
TFZzKS48L3A+DQo8cD5DZXJ0YWludGx5LCBJIHRoaW5rJm5ic3A7dGhlcmUgaXMgc3RpbGwgbG9m
cyBvZiB3b3JrIHRvIGJlIGRvbmUgZm9yIE1MTiBjb250cm9sIGJlY2F1c2UgUkZDNjAwMSBpcyBu
b3Qgc3VmZmljaWVudC48L3A+DQo8cD4mbmJzcDs8L3A+DQo8cD5Bbnl3YXksIHlvdXIgZXhhbXBs
ZSBpcyBhcHByZWNpYXRlZC48L3A+DQo8cD4mbmJzcDs8L3A+DQo8cD4mbmJzcDs8L3A+DQo8cD5U
aGFua3M8L3A+DQo8cD4mbmJzcDs8L3A+DQo8cD5GYXRhaTwvcD4NCjxwPiZuYnNwOzwvcD4NCjxw
PiZuYnNwOzwvcD4NCjxwPiZuYnNwOzwvcD4NCjxkaXYgc3R5bGU9IkZPTlQtRkFNSUxZOiBUaW1l
cyBOZXcgUm9tYW47IENPTE9SOiAjMDAwMDAwOyBGT05ULVNJWkU6IDE2cHgiPg0KPGhyIHRhYmlu
ZGV4PSItMSI+DQo8ZGl2IHN0eWxlPSJESVJFQ1RJT046IGx0ciIgaWQ9ImRpdlJwRjgwMTgxMSI+
PGZvbnQgY29sb3I9IiMwMDAwMDAiIHNpemU9IjIiIGZhY2U9IlRhaG9tYSI+PGI+5Y+R5Lu25Lq6
OjwvYj4gTWFyZ2FyaWEsIEN5cmlsIChOU04gLSBERS9NdW5pY2gpIFtjeXJpbC5tYXJnYXJpYUBu
c24uY29tXTxicj4NCjxiPuWPkemAgeaXtumXtDo8L2I+IDIwMTHlubQ55pyIMjnml6UgMTk6MDU8
YnI+DQo8Yj7liLA6PC9iPiBaaGFuZ2ZhdGFpOyBjY2FtcEBpZXRmLm9yZzxicj4NCjxiPuS4u+mi
mDo8L2I+IFJFOiDnrZTlpI06IOetlOWkjTog562U5aSNOiBbQ0NBTVBdIEktRCBBY3Rpb246IGRy
YWZ0LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC1jb25zdHJhaW50cy1vc3BmLXRlLTAyLnR4dDxi
cj4NCjwvZm9udD48YnI+DQo8L2Rpdj4NCjxkaXY+PC9kaXY+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0i
V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZB
TUlMWTogJ0NvdXJpZXIgTmV3JzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+SGkg
RmF0YWksDQo8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZP
TlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0
Ij48L3NwYW4+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZP
TlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0
Ij5Gb3IgbXkgZXhhbXBsZSBJIHRvb2sgdGhlIGV4YW1wbGUgZnJvbSBSRkM1MzM5IChhbHNvIGZv
bGxvd2luZyB0aGUgbG9naWMgb2YgUkZDNDIwMiBzZWN0aW9uIDIuNC42KSwgYWRqdXN0aW5nIHRo
ZSBjYXBhYmlsaXRpZXMgYW5kIGV4dGVuZGVkIHRoZSBudW1iZXIgb2YgcG9ydHM6PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJp
ZXIgTmV3JzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+PC9zcGFuPiZuYnNwOzwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJp
ZXIgTmV3JzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE5ldHdvcmsgZWxlbWVudDwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6
ICdDb3VyaWVyIE5ldyc7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVy
IE5ldyc7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyA6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tLS0tLS0tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IDo8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZP
TlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0
Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVERNJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IDombmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7fCZuYnNwOyBURE0mbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyA6PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTog
MTFwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IFBvcnQxLS0tLS0tLS0tLS0tLSZsdDstJmd0Oy0tLXwjYSZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDo8
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZ
OiAnQ291cmllciBOZXcnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0IiBsYW5nPSJG
UiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IFBvcnQyLS0tLS0tLS0tLS0tLSZsdDstJmd0Oy0tLXwjYiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDo8L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAn
Q291cmllciBOZXcnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0IiBsYW5nPSJGUiI+
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IFBvcnQzLS0tLS0tLS0tLS0tLSZsdDstJmd0Oy0tLXwjYyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDo8L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291
cmllciBOZXcnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0IiBsYW5nPSJGUiI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IFBvcnQ0LS0tLS0tLS0tLS0tLSZsdDstJmd0Oy0tLXwjZCZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDo8L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmll
ciBOZXcnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0IiBsYW5nPSJGUiI+Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291
cmllciBOZXcnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij46Jm5ic3A7ICYjNDM7
LS0mbHQ7LSZndDstLS18I2UmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgQ09MT1I6ICMxZjQ5N2Q7
IEZPTlQtU0laRTogMTFwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDombmJzcDsgfCZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLS0tLS0tLSZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgQ09MT1I6
ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDombmJz
cDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtLS0tLS0tLS0t
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDo8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBDT0xPUjog
IzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRFdETSZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6Jm5ic3A7ICYjNDM7LS0mbHQ7LSZndDstLXwjZiZu
YnNwOyBEV0RNJm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5l
dyc7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBQb3J0NSAtLS0t
LS0tLS0tLS0mbHQ7LSZndDstLXwjZyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDo8L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBDT0xP
UjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyAtLS0tLS0tLS0tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDo8L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBO
ZXcnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgOi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4uLi48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBDT0xP
UjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij48L3NwYW4+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBDT0xP
UjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgRmlndXJlIDFhLiZuYnNwOyBIeWJyaWQgbm9kZS48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBO
ZXcnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij48L3NwYW4+Jm5ic3A7PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBO
ZXcnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij5Gcm9tIElTQ0QgcG9pbnQgb2Yg
dmlldzo8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQt
RkFNSUxZOiAnQ291cmllciBOZXcnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij5U
RSBsaW5rIDEgKFBvcnQxKTo8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1T
SVpFOiAxMXB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBJU0NEIHN1Yi1UTFY6IFRETSAm
bmJzcDsoT0RVMikNCjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6
IDExcHQiPlRFIGxpbmsgMiAoUG9ydDEpOjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IENPTE9SOiAjMWY0OTdk
OyBGT05ULVNJWkU6IDExcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIElTQ0Qgc3ViLVRM
VjogVERNICZuYnNwOyhPRFUyKQ0KPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgQ09MT1I6ICMxZjQ5N2Q7IEZP
TlQtU0laRTogMTFwdCI+4oCmPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQt
U0laRTogMTFwdCI+VEUtTGluayA1IChwb3J0IDIpIDoNCjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IENPTE9S
OiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
Oy0gSVNDRCAjMSBzdWItVExWOiBEV0RNDQo8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBDT0xPUjogIzFmNDk3
ZDsgRk9OVC1TSVpFOiAxMXB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstIElTQ0Qg
IzIgc3ViLVRMVjogVERNLCBHLjcwOSBPRFVrIChPRFUzKQ0KPC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgQ09M
T1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+PC9zcGFuPiZuYnNwOzwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgQ09M
T1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+VGhlIElTQ0QgIzIgcmVwcmVzZW50IHRoZSBE
V0RNLVRETSBhZGp1c3RlbWVudCBjYXBhYmlsaXR5PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgQ09MT1I6ICMx
ZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+SSBhbSBsZWF2aW5nIG91dCBpbiB0aGlzIHRocmVhZCBo
b3cgdG8ga25vdyB0aGUgT0VPIGNhcGFiaWxpdHkgb2YgcG9ydCAjZi8jZSA7LSk8L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmll
ciBOZXcnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij48L3NwYW4+Jm5ic3A7PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmll
ciBOZXcnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij48L3NwYW4+Jm5ic3A7PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmll
ciBOZXcnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij5XaXRoIHRoZSBmb2xsb3dp
bmcgY29ubmVjdGl2aXR5IG1hdHJpeCAod2l0aCB0aGUgZm9sbG93aW5nIGNvbnZlbnRpb24gOiAo
e0xpbmsgU2V0IEEjMX0se0xpbmsgc2V0IEIjMX0pLCh7TGluayBTZXQgQSMyfSx7TGluayBzZXQg
QiMyfSks4oCmPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJG
T05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFw
dCI+PC9zcGFuPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJG
T05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFw
dCIgbGFuZz0iRlIiPk1hdHJpeCAjMSAoe1BvcnQgMX0sIHtQb3J0IDV9KQ0KPC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIg
TmV3JzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCIgbGFuZz0iRlIiPk1hdHJpeCAj
MiAoe1BvcnQgMn0sIHtQb3J0IDV9KTwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IENPTE9SOiAjMWY0OTdkOyBG
T05ULVNJWkU6IDExcHQiIGxhbmc9IkZSIj5NYXRyaXggIzMgKHtQb3J0IDN9LCB7UG9ydCA1fSk8
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZ
OiAnQ291cmllciBOZXcnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0IiBsYW5nPSJG
UiI+TWF0cml4ICM0ICh7UG9ydCA0fSwge1BvcnQgNX0pPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgQ09MT1I6
ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCIgbGFuZz0iRlIiPjwvc3Bhbj4mbmJzcDs8L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5l
dyc7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiIGxhbmc9IkZSIj5URS1MaW5rIDUg
KHBvcnQgMikgOg0KPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTog
MTFwdCIgbGFuZz0iRlIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0gSVNDRCAjMSBz
dWItVExWOiBEV0RNDQo8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpF
OiAxMXB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstIElTQ0QgIzIgc3ViLVRMVjog
VERNLCBHLjcwOSBPRFVrIChoZXJlIE9EVTMsIGJlY2F1c2Ugb2YgdGhlIHBvcnQgI2UpPC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0Nv
dXJpZXIgTmV3JzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IC0gUG9ydCBMYWJlbCByZXN0cmljdGlvbiZuYnNwOzogTWF0cml4ICMxLCBS
ZXN0cmljdGlvblR5cGU9U0lNUExFX0xBQkVMLCBMYWJlbCA9IFRTJm5ic3A7OjE2LDEyLDgsNCAo
Y2FuIHdlIGJlIHN1cmUgb2YgdGhlIGludGVycHJldGF0aW9uJm5ic3A7Pyk8L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBO
ZXcnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IENP
TE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiIGxhbmc9IkZSIj4tIFBvcnQgTGFiZWwgcmVz
dHJpY3Rpb24mbmJzcDs6IE1hdHJpeCAjMiwgUmVzdHJpY3Rpb25UeXBlPVNJTVBMRV9MQUJFTCwg
TGFiZWwgPSBUUyZuYnNwOzoxNSwxMSw3LDM8L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBDT0xPUjogIzFmNDk3
ZDsgRk9OVC1TSVpFOiAxMXB0IiBsYW5nPSJGUiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0g
UG9ydCBMYWJlbCByZXN0cmljdGlvbiZuYnNwOzogTWF0cml4ICMzLCBSZXN0cmljdGlvblR5cGU9
U0lNUExFX0xBQkVMLCBMYWJlbCA9IFRTJm5ic3A7OjE0LDEwLDYsMjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7
IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiIGxhbmc9IkZSIj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgLSBQb3J0IExhYmVsIHJlc3RyaWN0aW9uJm5ic3A7OiBNYXRyaXggIzMsIFJl
c3RyaWN0aW9uVHlwZT1TSU1QTEVfTEFCRUwsIExhYmVsID0gVFMmbmJzcDs6MTMsMDksNSwxPC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTog
J0NvdXJpZXIgTmV3JzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCIgbGFuZz0iRlIi
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1J
TFk6ICdDb3VyaWVyIE5ldyc7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiPkkgYW0g
bm90IDEwMCUgc3VyZSB0aGF0IHdlIGNhbiBhbHdheXMgaW50ZXJwcmV0IHRoZSBsYWJlbCBhcyBP
RFUgbGFiZWwsIFJGQzQyMDIgc2VjdGlvbiAyLjQuNyBvbiBob3cgdG8gaW50ZXJwcmV0IHRoZTwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6
ICdDb3VyaWVyIE5ldyc7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiPkxhYmVsIG9u
IGEgVEUtTGluayB3b3VsZCBpbmRpY2F0ZSB0aGF0IGlmIG9uZSBlbmQgc3VwcG9ydCBURE0gYW5k
IHRoZSBvdGhlciBMU0MsIHRoZSBsYWJlbCBzaG91bGQgcmVwcmVzZW50IGEgbGFtYmRhLA0KPC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTog
J0NvdXJpZXIgTmV3JzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+YnV0IHRoZSBj
YXNlIHdoZXJlIHRoZXJlIGlzIHNldmVyYWwgSVNDRCBpcyBub3Qgd2VsbCBkZXNjcmliZWQuPC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTog
J0NvdXJpZXIgTmV3JzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+PC9zcGFuPiZu
YnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTog
J0NvdXJpZXIgTmV3JzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+VGhlIGRyYWZ0
IHNob3VsZCBkZXRhaWwgdGhlIHJ1bGVzIG9uIHdoaWNoIGxhYmVsIGVuY29kaW5nIHRvIHVzZSBp
biBjYXNlIG9mIGNvbm5lY3Rpdml0eSBtYXRyaXggaW4gdGhhdCBjYXNlLjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5l
dyc7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiPjwvc3Bhbj4mbmJzcDs8L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5l
dyc7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiPkluIHRoYXQgZXhhbXBsZSB3ZSBo
YXZlIGZpeGVkIE1VWCBPRFUzLSZndDtPRFUyIEFORCBlYWNoIE9EVTIgaXMgYXNzaWduZWQgdG8g
YW4gcG9ydDogdGhlIHBvcnQgbGFiZWwgcmVzdHJpY3Rpb24gaXMgdXNlZCwNCjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVy
IE5ldyc7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiPlJ1bGVzIGZvciBwb3J0IGxh
YmVsIHJlc3RyaWN0aW9uIHNob3VsZCBhbGxvdyB0byBpbnRlcnByZXQgY29ycmVjdGx5IHRoZSBs
YWJlbC48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQt
RkFNSUxZOiAnQ291cmllciBOZXcnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij48
L3NwYW4+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQt
RkFNSUxZOiAnQ291cmllciBOZXcnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij5I
b3dldmVyIG9uIGNhc2Ugb2YgRml4ZXMgTVVYIGFuZCBmbGV4aWJsZSBPRFUyIHRvIHBvcnQgYXNz
aWdubWVudCBvbmUgYWxsb3dlZCBwb3NzaWJpbGl0eSBpcyB0aGUgZm9sbG93aW5nIDoNCjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdD
b3VyaWVyIE5ldyc7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiIGxhbmc9IkZSIj5N
YXRyaXggIzExICh7UG9ydCAxLCBQb3J0IDIsIFBvcnQgMywgUG9ydCA0LH0sIHtQb3J0IDV9KTwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6
ICdDb3VyaWVyIE5ldyc7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiIGxhbmc9IkZS
Ij48L3NwYW4+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZP
TlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0
IiBsYW5nPSJGUiI+VEUtTGluayA1IChwb3J0IDIpIDoNCjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IENPTE9S
OiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiIGxhbmc9IkZSIj4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDstIElTQ0QgIzEgc3ViLVRMVjogRFdETQ0KPC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgQ09M
T1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCIgbGFuZz0iRlIiPiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOy0gSVNDRCAjMiBzdWItVExWOiBURE0sIEcuNzA5IE9EVWsgKE9EVTMpDQo8
L3NwYW4+PC9wPg0KPHAgc3R5bGU9IlRFWFQtSU5ERU5UOiA1LjI1cHQiIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgQ09MT1I6ICMxZjQ5
N2Q7IEZPTlQtU0laRTogMTFwdCIgbGFuZz0iRlIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0g
QXZhaWxhYmxlICZuYnNwO0xhYmVscyZuYnNwOzogwqsmbmJzcDtUUyZuYnNwOzoxNSwxMSw3LDMm
bmJzcDvCuywgwqsmbmJzcDtUUyZuYnNwOzoxNCwxMCw2LDImbmJzcDvCuywmbmJzcDvCqyZuYnNw
O1RTJm5ic3A7OjEzLDA5LDUsMSZuYnNwO8K7LCZuYnNwO8KrJm5ic3A7VFMmbmJzcDs6MTYsMTIs
OCw04oCdPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJGT05U
LUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCIg
bGFuZz0iRlIiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAtIEF2YWlsYWJsZSAmbmJzcDtMYWJl
bHMmbmJzcDs6IGNoYW5uZWxzIChEV0RNKQ0KPC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NvdXJpZXIgTmV3JzsgQ09MT1I6ICMxZjQ5
N2Q7IEZPTlQtU0laRTogMTFwdCIgbGFuZz0iRlIiPjwvc3Bhbj4mbmJzcDs8L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IENP
TE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6IDExcHQiPkhvdyB0byBtYWtlIHN1cmUgdGhlIGludGVy
cHJldGF0aW9uIGlzIGNvcnJlY3QsIFRoaXMgaXMgYW4gdHlwaWNhbCBjYXNlIGNvdmVyZWQgYnkg
dGhlIGdlbmVyaWMgR01QTFMgUkZDcywgc28NCjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDb3VyaWVyIE5ldyc7IENPTE9SOiAjMWY0
OTdkOyBGT05ULVNJWkU6IDExcHQiPiZuYnNwO0l0IHNob3VsZCZuYnNwOyBiZSBjb3ZlcmVkIGlu
IG15IG9waW5pb24gYnkgdGhlIGdlbmVyaWMgZXh0ZW5zaW9ucy48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBD
T0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij48L3NwYW4+Jm5ic3A7PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBD
T0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij48L3NwYW4+Jm5ic3A7PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBD
T0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij48L3NwYW4+Jm5ic3A7PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ291cmllciBOZXcnOyBD
T0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij48L3NwYW4+Jm5ic3A7PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMt
c2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij48L3NwYW4+Jm5ic3A7PC9w
Pg0KPGRpdiBzdHlsZT0iQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBi
bHVlIDEuNXB0IHNvbGlkOyBQQURESU5HLUJPVFRPTTogMGNtOyBQQURESU5HLUxFRlQ6IDRwdDsg
UEFERElORy1SSUdIVDogMGNtOyBCT1JERVItVE9QOiBtZWRpdW0gbm9uZTsgQk9SREVSLVJJR0hU
OiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDBjbSI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iQk9S
REVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElO
Ry1CT1RUT006IDBjbTsgUEFERElORy1MRUZUOiAwY207IFBBRERJTkctUklHSFQ6IDBjbTsgQk9S
REVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBB
RERJTkctVE9QOiAzcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9IkZP
TlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IEZPTlQtU0laRTogMTBwdCI+RnJvbTo8
L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYn
OyBGT05ULVNJWkU6IDEwcHQiPiBleHQgWmhhbmdmYXRhaSBbbWFpbHRvOnpoYW5nZmF0YWlAaHVh
d2VpLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgU2VwdGVtYmVyIDI5LCAyMDEx
IDEyOjE5IFBNPGJyPg0KPGI+VG86PC9iPiBNYXJnYXJpYSwgQ3lyaWwgKE5TTiAtIERFL011bmlj
aCk7IGNjYW1wQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IDwvc3Bhbj48c3BhbiBzdHls
ZT0iRk9OVC1TSVpFOiAxMHB0IiBsYW5nPSJaSC1DTiI+562U5aSNPC9zcGFuPjxzcGFuIHN0eWxl
PSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPjoN
Cjwvc3Bhbj48c3BhbiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0IiBsYW5nPSJaSC1DTiI+562U5aSN
PC9zcGFuPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBG
T05ULVNJWkU6IDEwcHQiPjoNCjwvc3Bhbj48c3BhbiBzdHlsZT0iRk9OVC1TSVpFOiAxMHB0IiBs
YW5nPSJaSC1DTiI+562U5aSNPC9zcGFuPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9t
YScsJ3NhbnMtc2VyaWYnOyBGT05ULVNJWkU6IDEwcHQiPjogW0NDQU1QXSBJLUQgQWN0aW9uOiBk
cmFmdC1pZXRmLWNjYW1wLWdtcGxzLWdlbmVyYWwtY29uc3RyYWludHMtb3NwZi10ZS0wMi50eHQ8
L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzwv
cD4NCjxkaXY+DQo8cD48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNl
cmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiPkhpIEN5cmlsLDwvc3Bhbj48L3A+
DQo8cD48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09M
T1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiPjwvc3Bhbj4mbmJzcDs8L3A+DQo8cD48c3BhbiBz
dHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNrOyBG
T05ULVNJWkU6IDEwcHQiPlVzdWFsbHksIG9uZSBURSBsaW5rIGFkdmVydGlzZW1lbnQgKHdpdGgg
c2VydmVyYWwgSVNDRHMgYW5kIG11bHRpcGxlIGxhYmVsIHN1Yi1UTFZzKSBoYXMgdGhlIHNhbWUg
U3dpdGNoaW5nIENhcGFiaWxpdHksIHNvIHRoZXJlIGlzIGltcGxpY2l0IHJlbGF0aW9uc2hpcCBi
ZXR3ZWVuIHRoZSBJU0NEcyBhbmQNCiBsYWJlbCBzdWItVExWcy48L3NwYW4+PC9wPg0KPHA+PHNw
YW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9SOiBibGFj
azsgRk9OVC1TSVpFOiAxMHB0Ij48L3NwYW4+Jm5ic3A7PC9wPg0KPHA+PHNwYW4gc3R5bGU9IkZP
TlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9SOiBibGFjazsgRk9OVC1TSVpF
OiAxMHB0Ij5JIHdvdWxkIGxpa2UgdG8gY29uc2lkZXIgeW91ciZuYnNwO2xhc3QgcG9pbnQgd2hl
biBJIHVkcGF0ZSB0aGlzIGRyYWZ0IGluIHRoZSBuZXh0IHZlcnNpb24uDQo8L3NwYW4+PC9wPg0K
PHA+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9S
OiBibGFjazsgRk9OVC1TSVpFOiAxMHB0Ij48L3NwYW4+Jm5ic3A7PC9wPg0KPHA+PHNwYW4gc3R5
bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9SOiBibGFjazsgRk9O
VC1TSVpFOiAxMHB0Ij5CdXQgSSBoYXZlIGEgcXVlc3Rpb24gb24geW91ciBleGFtcGxlLCBkbyB5
b3Ugc2VlIHRoYXQgdGhlcmUgaXMgYSBsaW5lIHBvcnQgKG9yIGludGVyZmFjZSkmbmJzcDtjYW4g
c3VwcG9ydCBib3RoIERXRE0gYW5kIFRETSBpbiB0aGUgd29ybGQ/IEkgdGhpbmsgaWYgYSBsaW5l
IHBvcnQgY2FuIHN1cHBvcnQgRFdETSwNCiB0aGUgV1NPTiBURSBsaW5rICh3aXRoIFdTT04gcmVs
YXRlZCBsYWJlbCAod2F2ZWxlbmd0aCkgaW5mb3JtYXRpb24pJm5ic3A7c2hvdWxkIGJlIGFkdmVy
dGlzZWQgZm9yIHRoaXMgbGluZSBwb3J0OyBpZiBhIGxpbmUgcG9ydCBjYW4gc3VwcG9ydCBURE0s
IHRoZW4gdGhlIFRETSBURSBsaW5rIChlLmcuLCBPRFUpJm5ic3A7Zm9yIHRoaXMgbGluZSBwb3J0
IHNob3VsZCBiZSBhZHZlcnRpc2VkLiBFdmVuIHRob3VnaCB0aGVyZSB3YXMgb25lIHBvcnQgY291
bGQgc3VwcG9ydA0KIGJvdGggRFdETSBhbmQgVERNLCBJIHRoaW5rJm5ic3A7dXN1YWxseSBpdCBz
aG91bGQgYWR2ZXJ0aXNlIHRoZXNlIHR3byB0eXBlcyBvZiBjYXBhYmlsaXR5IHNlcGFyYXRlbHks
IGllLiwgdXNlIHNlcGVyYXRlIFRFIGxpbmsgYWR2ZXJ0aXNlbWVudHMuIHNvLCBJIHRoaW5rIHRo
ZXJlIGlzIGltcGxpY2l0IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBJU0NEcyBhbmQgbGFiZWwg
c3ViLVRMVnMuPC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9t
YScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+PC9zcGFuPiZu
YnNwOzwvcD4NCjxwPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2Vy
aWYnOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+RXZlbiB0aG91Z2ggSSB0aGluayZu
YnNwO3dlIHNob3VsZCBub3QgdXNlIGEga2luZCBvZiBzcGVjaWFsIGFuZCBjb21wbGV4Jm5ic3A7
ZXhhbXBsZSB0byBleHBsYWluIHNvbWV0aGluZywgSSB3aWxsJm5ic3A7YmVhciB5b3VyIGV4YW1w
bGUgaW4gbXkgbWluZCB3aGVuIEkgdXBkYXRlIHRoZSBkcmFmdCAoYXMgSSBzYWlkIGluIHRoZQ0K
IHNlY29uZCBzZW50ZW5jZSBhYm92ZSkuPC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJGT05U
LUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTog
MTBwdCI+PC9zcGFuPiZuYnNwOzwvcD4NCjxwPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1Rh
aG9tYScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+VGhhbmtz
PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMt
c2VyaWYnOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+PC9zcGFuPiZuYnNwOzwvcD4N
CjxwPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBDT0xP
UjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+RmF0YWk8L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5
bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9SOiBibGFjazsgRk9O
VC1TSVpFOiAxMHB0Ij48L3NwYW4+Jm5ic3A7PC9wPg0KPHA+PHNwYW4gc3R5bGU9IkZPTlQtRkFN
SUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0
Ij48L3NwYW4+Jm5ic3A7PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9IlRFWFQtQUxJR046IGNlbnRl
ciIgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciI+PHNwYW4gc3R5bGU9IkZPTlQtRkFN
SUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogYmxhY2siPg0KPGhyIGFsaWdu
PSJjZW50ZXIiIHNpemU9IjIiIHdpZHRoPSIxMDAlIj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXYgaWQ9
ImRpdlJwRjMzNzI2OSI+DQo8cCBzdHlsZT0iTUFSR0lOLUJPVFRPTTogMTJwdCIgY2xhc3M9Ik1z
b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9IkNPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0IiBs
YW5nPSJaSC1DTiI+5Y+R5Lu25Lq6PC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iRk9OVC1GQU1J
TFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQi
Pjo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2Vy
aWYnOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+DQogTWFyZ2FyaWEsIEN5cmlsIChO
U04gLSBERS9NdW5pY2gpIFtjeXJpbC5tYXJnYXJpYUBuc24uY29tXTxicj4NCjwvc3Bhbj48Yj48
c3BhbiBzdHlsZT0iQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9IlpILUNOIj7l
j5HpgIHml7bpl7Q8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9t
YScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+Ojwvc3Bhbj48
L2I+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9S
OiBibGFjazsgRk9OVC1TSVpFOiAxMHB0Ij4NCiAyMDExPC9zcGFuPjxzcGFuIHN0eWxlPSJDT0xP
UjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCIgbGFuZz0iWkgtQ04iPuW5tDwvc3Bhbj48c3BhbiBz
dHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNrOyBG
T05ULVNJWkU6IDEwcHQiPjk8L3NwYW4+PHNwYW4gc3R5bGU9IkNPTE9SOiBibGFjazsgRk9OVC1T
SVpFOiAxMHB0IiBsYW5nPSJaSC1DTiI+5pyIPC9zcGFuPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlM
WTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+
Mjk8L3NwYW4+PHNwYW4gc3R5bGU9IkNPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0IiBsYW5n
PSJaSC1DTiI+5pelPC9zcGFuPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3Nh
bnMtc2VyaWYnOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+DQogMTc6MzY8YnI+DQo8
L3NwYW4+PGI+PHNwYW4gc3R5bGU9IkNPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0IiBsYW5n
PSJaSC1DTiI+5YiwPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhv
bWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiPjo8L3NwYW4+
PC9iPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBDT0xP
UjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+IFpoYW5nZmF0YWk7DQogY2NhbXBAaWV0Zi5vcmc8
YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9IkNPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0
IiBsYW5nPSJaSC1DTiI+5Li76aKYPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iRk9OVC1GQU1J
TFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQi
Pjo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2Vy
aWYnOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+IFJFOg0KPC9zcGFuPjxzcGFuIHN0
eWxlPSJDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCIgbGFuZz0iWkgtQ04iPuetlOWkjTwv
c3Bhbj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09M
T1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiPjoNCjwvc3Bhbj48c3BhbiBzdHlsZT0iQ09MT1I6
IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9IlpILUNOIj7nrZTlpI08L3NwYW4+PHNwYW4g
c3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9SOiBibGFjazsg
Rk9OVC1TSVpFOiAxMHB0Ij46IFtDQ0FNUF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jY2FtcC1n
bXBscy1nZW5lcmFsLWNvbnN0cmFpbnRzLW9zcGYtdGUtMDIudHh0PC9zcGFuPjxzcGFuIHN0eWxl
PSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgQ09MT1I6IGJsYWNrIj48
L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMx
ZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+SGksDQo8L3NwYW4+PHNwYW4gc3R5bGU9IkNPTE9SOiBi
bGFjayI+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJDT0xP
UjogYmxhY2siPjwvc3Bhbj4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdk
OyBGT05ULVNJWkU6IDExcHQiPklmIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHksIHlvdSBzdGF0ZSB0
aGF0IHRoZXJlIGlzIG5vdCBleHBsaWNpdCBvciBpbXBsaWNpdCByZWxhdGlvbnNoaXAgYmV0d2Vl
biB0aGUgSVNDRCBhbmQgbGFiZWwgc3ViLVRMViwgY29ycmVjdD88L3NwYW4+PHNwYW4gc3R5bGU9
IkNPTE9SOiBibGFjayI+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7
IEZPTlQtU0laRTogMTFwdCI+SSB3b3VsZCBleHBlY3QgYSBuZXcgZ2VuZXJpYyBkcmFmdCB0byBi
ZSBhcHBsaWNhYmxlIHRvIGFsbCBhbHJlYWR5IGRlZmluZWQgbGFiZWwgZm9ybWF0LCBzbyAmbmJz
cDtpdCBzZWVtcyBtaXNzaW5nIGluIHRoZSBkb2N1bWVudC48L3NwYW4+PHNwYW4gc3R5bGU9IkNP
TE9SOiBibGFjayI+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJDT0xPUjogYmxhY2siPjwvc3Bhbj4mbmJzcDs8L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAj
MWY0OTdkOyBGT05ULVNJWkU6IDExcHQiPkNvdWxkIHlvdSBjb25zaWRlciBteSBsYXN0IHBvaW50
IHJlZ2FyZGluZyB0aGUgZXhhbXBsZSBvZiBzd2l0Y2hpbmcgcmVzdHJpY3Rpb24gaW4gRy43MDkg
djIgYW5kIERXRE0gY29udGV4dCwgaXQgd291bGQgYmUgaGVscGZ1bA0KPC9zcGFuPjxzcGFuIHN0
eWxlPSJDT0xPUjogYmxhY2siPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iRk9OVC1GQU1JTFk6ICdDYWxpYnJpJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0
OTdkOyBGT05ULVNJWkU6IDExcHQiPiZuYnNwO3RvIGhhdmUgc29tZSBzdGF0ZW1lbnQgZXZlbiB0
aG91Z2ggaXQgd2lsbCBub3QgYmUgaW4gdGhlIGRvY3VtZW50Ljwvc3Bhbj48c3BhbiBzdHlsZT0i
Q09MT1I6IGJsYWNrIj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9IkNPTE9SOiBibGFjayI+PC9zcGFuPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6
ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+QmVzdCBSZWdhcmRzLjwvc3Bhbj48c3BhbiBzdHls
ZT0iQ09MT1I6IGJsYWNrIj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9IkNPTE9SOiBibGFjayI+PC9zcGFuPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJDT0xPUjogYmxhY2siPjwvc3Bhbj4mbmJzcDs8L3A+DQo8ZGl2IHN0
eWxlPSJCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IGJsdWUgMS41cHQg
c29saWQ7IFBBRERJTkctQk9UVE9NOiAwY207IFBBRERJTkctTEVGVDogNHB0OyBQQURESU5HLVJJ
R0hUOiAwY207IEJPUkRFUi1UT1A6IG1lZGl1bSBub25lOyBCT1JERVItUklHSFQ6IG1lZGl1bSBu
b25lOyBQQURESU5HLVRPUDogMGNtIj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJCT1JERVItQk9UVE9N
OiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTog
MGNtOyBQQURESU5HLUxFRlQ6IDBjbTsgUEFERElORy1SSUdIVDogMGNtOyBCT1JERVItVE9QOiAj
YjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6
IDNwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6
ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiPkZy
b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNl
cmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiPiBleHQgWmhhbmdmYXRhaSBbbWFp
bHRvOnpoYW5nZmF0YWlAaHVhd2VpLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXks
IFNlcHRlbWJlciAyOCwgMjAxMSA0OjMwIEFNPGJyPg0KPGI+VG86PC9iPiBNYXJnYXJpYSwgQ3ly
aWwgKE5TTiAtIERFL011bmljaCk7IGNjYW1wQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+
IDwvc3Bhbj48c3BhbiBzdHlsZT0iQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9
IlpILUNOIj7nrZTlpI08L3NwYW4+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywn
c2Fucy1zZXJpZic7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0Ij46DQo8L3NwYW4+PHNw
YW4gc3R5bGU9IkNPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPSJaSC1DTiI+562U
5aSNPC9zcGFuPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYn
OyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+OiBbQ0NBTVBdIEktRCBBY3Rpb246IGRy
YWZ0LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC1jb25zdHJhaW50cy1vc3BmLXRlLTAyLnR4dDwv
c3Bhbj48c3BhbiBzdHlsZT0iQ09MT1I6IGJsYWNrIj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJDT0xPUjogYmxhY2siPjwvc3Bh
bj4mbmJzcDs8L3A+DQo8ZGl2Pg0KPHA+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21h
Jywnc2Fucy1zZXJpZic7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0Ij5IaSBDeXJpbCw8
L3NwYW4+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYn
OyBDT0xPUjogYmxhY2siPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6
ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBibGFjayI+PC9zcGFuPiZuYnNwOzwv
cD4NCjxwPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBD
T0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+SSBhZ3JlZSBvbiB5b3VyIGZpcnN0IHN1Z2dl
c3Rpb24uPC9zcGFuPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbics
J3NlcmlmJzsgQ09MT1I6IGJsYWNrIj48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9IkZPTlQt
RkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogYmxhY2siPjwvc3Bhbj4m
bmJzcDs8L3A+DQo8cD48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNl
cmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiPlNlY29uZGx5LCB0aGlzIGRyYWZ0
IGlzIGdlbmVyaWMsIHdoZW4mbmJzcDtpdCBuZWVkcyB0byBhZHZlcnRpc2UgbGFiZWwgaW5mb3Jt
YXRpb24gZm9yIHNvbWUgc3BlY2lmaWMgdGVjaCAoZS5nLiwgVERNKSwgdGhlIGRvY3VtZW50IGFi
b3V0Jm5ic3A7c3BlY2lmaWMmbmJzcDt0ZWNoIGNhbiZuYnNwO3JlZmVyIHRvIHRoaXMgZHJhZnQg
YW5kDQogc2hvdWxkIGRlZmluZSBob3cgdG8gY29ycmVsYXRlIHRoZSBJU0NEcyBhbmQgbGFiZWwg
c3ViLVRMVnMgaWYgdGhlcmUgaXMgbm8mbmJzcDtleHBsaWNpdCBvciZuYnNwO2ltcGxpY2l0Jm5i
c3A7cmVsYXRpb25zaGlwIGJldHdlZW4gdGhlbSZuYnNwOyhJIHRoaW5rIHRoZXJlIGFyZSBsb3Rz
IG9mIHBvdGVudGlhbCBzb2x1dGlvbnMgdG8gaGFuZGxlIHRoYXQsIGl0IGlzIHF1aXRlIHRlY2gg
c3BlY2lmaWMgc3R1ZmYpLg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVz
IE5ldyBSb21hbicsJ3NlcmlmJzsgQ09MT1I6IGJsYWNrIj48L3NwYW4+PC9wPg0KPHA+PHNwYW4g
c3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogYmxh
Y2siPjwvc3Bhbj4mbmJzcDs8L3A+DQo8cD48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1l
cyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBibGFjayI+PC9zcGFuPiZuYnNwOzwvcD4NCjxw
PjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBDT0xPUjog
YmxhY2s7IEZPTlQtU0laRTogMTBwdCI+RmF0YWk8L3NwYW4+PHNwYW4gc3R5bGU9IkZPTlQtRkFN
SUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogYmxhY2siPjwvc3Bhbj48L3A+
DQo8cD48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7
IENPTE9SOiBibGFjayI+PC9zcGFuPiZuYnNwOzwvcD4NCjxwPjxzcGFuIHN0eWxlPSJGT05ULUZB
TUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBw
dCI+VGhhbmtzPC9zcGFuPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21h
bicsJ3NlcmlmJzsgQ09MT1I6IGJsYWNrIj48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9IkZP
TlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogYmxhY2siPjwvc3Bh
bj4mbmJzcDs8L3A+DQo8cD48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9t
YW4nLCdzZXJpZic7IENPTE9SOiBibGFjayI+PC9zcGFuPiZuYnNwOzwvcD4NCjxkaXY+DQo8ZGl2
IHN0eWxlPSJURVhULUFMSUdOOiBjZW50ZXIiIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50
ZXIiPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsg
Q09MT1I6IGJsYWNrIj4NCjxociBhbGlnbj0iY2VudGVyIiBzaXplPSIyIiB3aWR0aD0iMTAwJSI+
DQo8L3NwYW4+PC9kaXY+DQo8ZGl2IGlkPSJkaXZScEYyNDEyNjgiPg0KPHAgc3R5bGU9Ik1BUkdJ
Ti1CT1RUT006IDEycHQiIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJDT0xPUjog
YmxhY2s7IEZPTlQtU0laRTogMTBwdCIgbGFuZz0iWkgtQ04iPuWPkeS7tuS6ujwvc3Bhbj48L2I+
PGI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9S
OiBibGFjazsgRk9OVC1TSVpFOiAxMHB0Ij46PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iRk9OVC1G
QU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEw
cHQiPg0KIE1hcmdhcmlhLCBDeXJpbCAoTlNOIC0gREUvTXVuaWNoKSBbY3lyaWwubWFyZ2FyaWFA
bnNuLmNvbV08YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9IkNPTE9SOiBibGFjazsgRk9OVC1T
SVpFOiAxMHB0IiBsYW5nPSJaSC1DTiI+5Y+R6YCB5pe26Ze0PC9zcGFuPjwvYj48Yj48c3BhbiBz
dHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNrOyBG
T05ULVNJWkU6IDEwcHQiPjo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1Rh
aG9tYScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+DQogMjAx
MTwvc3Bhbj48c3BhbiBzdHlsZT0iQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9
IlpILUNOIj7lubQ8L3NwYW4+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fu
cy1zZXJpZic7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0Ij45PC9zcGFuPjxzcGFuIHN0
eWxlPSJDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCIgbGFuZz0iWkgtQ04iPuaciDwvc3Bh
bj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6
IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiPjI3PC9zcGFuPjxzcGFuIHN0eWxlPSJDT0xPUjogYmxh
Y2s7IEZPTlQtU0laRTogMTBwdCIgbGFuZz0iWkgtQ04iPuaXpTwvc3Bhbj48c3BhbiBzdHlsZT0i
Rk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJ
WkU6IDEwcHQiPg0KIDE3OjM4PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJDT0xPUjogYmxh
Y2s7IEZPTlQtU0laRTogMTBwdCIgbGFuZz0iWkgtQ04iPuWIsDwvc3Bhbj48L2I+PGI+PHNwYW4g
c3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9SOiBibGFjazsg
Rk9OVC1TSVpFOiAxMHB0Ij46PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdU
YWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiPiBaaGFu
Z2ZhdGFpOw0KIGNjYW1wQGlldGYub3JnPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJDT0xP
UjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCIgbGFuZz0iWkgtQ04iPuS4u+mimDwvc3Bhbj48L2I+
PGI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9S
OiBibGFjazsgRk9OVC1TSVpFOiAxMHB0Ij46PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iRk9OVC1G
QU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEw
cHQiPiBSRToNCjwvc3Bhbj48c3BhbiBzdHlsZT0iQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEw
cHQiIGxhbmc9IlpILUNOIj7nrZTlpI08L3NwYW4+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAn
VGFob21hJywnc2Fucy1zZXJpZic7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0Ij46IFtD
Q0FNUF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLWNvbnN0cmFp
bnRzLW9zcGYtdGUtMDIudHh0PC9zcGFuPjxzcGFuIHN0eWxlPSJDT0xPUjogYmxhY2siPjwvc3Bh
bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3
ZDsgRk9OVC1TSVpFOiAxMXB0Ij5IaSwNCjwvc3Bhbj48c3BhbiBzdHlsZT0iQ09MT1I6IGJsYWNr
Ij48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9IkNPTE9SOiBi
bGFjayI+PC9zcGFuPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZP
TlQtU0laRTogMTFwdCI+VGhhbmtzIGZvciB0aGUgYW5zd2VyLA0KPC9zcGFuPjxzcGFuIHN0eWxl
PSJDT0xPUjogYmxhY2siPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iQ09MT1I6IGJsYWNrIj48L3NwYW4+Jm5ic3A7PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xP
UjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0Ij5QbGVhc2Ugc2VlIGlubGluZTwvc3Bhbj48c3Bh
biBzdHlsZT0iQ09MT1I6IGJsYWNrIj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9IkNPTE9SOiBibGFjayI+PC9zcGFuPiZuYnNwOzwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJDT0xPUjogYmxhY2siPjwvc3Bhbj4mbmJzcDs8L3A+DQo8
ZGl2IHN0eWxlPSJCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IGJsdWUg
MS41cHQgc29saWQ7IFBBRERJTkctQk9UVE9NOiAwY207IFBBRERJTkctTEVGVDogNHB0OyBQQURE
SU5HLVJJR0hUOiAwY207IEJPUkRFUi1UT1A6IG1lZGl1bSBub25lOyBCT1JERVItUklHSFQ6IG1l
ZGl1bSBub25lOyBQQURESU5HLVRPUDogMGNtIj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJCT1JERVIt
Qk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1lZGl1bSBub25lOyBQQURESU5HLUJP
VFRPTTogMGNtOyBQQURESU5HLUxFRlQ6IDBjbTsgUEFERElORy1SSUdIVDogMGNtOyBCT1JERVIt
VE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hUOiBtZWRpdW0gbm9uZTsgUEFERElO
Ry1UT1A6IDNwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iRk9OVC1G
QU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEw
cHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdz
YW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiPiBleHQgWmhhbmdmYXRh
aSBbbWFpbHRvOnpoYW5nZmF0YWlAaHVhd2VpLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVz
ZGF5LCBTZXB0ZW1iZXIgMjcsIDIwMTEgMTE6MTcgQU08YnI+DQo8Yj5Ubzo8L2I+IE1hcmdhcmlh
LCBDeXJpbCAoTlNOIC0gREUvTXVuaWNoKTsgY2NhbXBAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0
OjwvYj4gPC9zcGFuPjxzcGFuIHN0eWxlPSJDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCIg
bGFuZz0iWkgtQ04iPuetlOWkjTwvc3Bhbj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhv
bWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiPjogW0NDQU1Q
XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWdlbmVyYWwtY29uc3RyYWludHMt
b3NwZi10ZS0wMi50eHQ8L3NwYW4+PHNwYW4gc3R5bGU9IkNPTE9SOiBibGFjayI+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iQ09M
T1I6IGJsYWNrIj48L3NwYW4+Jm5ic3A7PC9wPg0KPGRpdj4NCjxwIHN0eWxlPSJNQVJHSU4tQk9U
VE9NOiAxMnB0Ij48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlm
JzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiPkhpIEN5cmlsLDxicj4NCjxicj4NClRo
YW5rcyBmb3IgeW91ciBjb21tZXRzLjxicj4NCjxicj4NClBsZWFzZSBzZWUgaW4tbGluZSBiZWxv
dy48YnI+DQo8YnI+DQo8YnI+DQpGYXRhaTxicj4NCjxicj4NClRoYW5rczxicj4NCjxicj4NCjxi
cj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8
L3NwYW4+PHNwYW4gc3R5bGU9IkNPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPSJa
SC1DTiI+5Y+R5Lu25Lq6PC9zcGFuPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScs
J3NhbnMtc2VyaWYnOyBDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCI+OiBNYXJnYXJpYSwg
Q3lyaWwgKE5TTiAtIERFL011bmljaCkgW2N5cmlsLm1hcmdhcmlhQG5zbi5jb21dPGJyPg0KPC9z
cGFuPjxzcGFuIHN0eWxlPSJDT0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCIgbGFuZz0iWkgt
Q04iPuWPkemAgeaXtumXtDwvc3Bhbj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEn
LCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiPjogMjAxMTwvc3Bh
bj48c3BhbiBzdHlsZT0iQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9IlpILUNO
Ij7lubQ8L3NwYW4+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJp
Zic7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0Ij45PC9zcGFuPjxzcGFuIHN0eWxlPSJD
T0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCIgbGFuZz0iWkgtQ04iPuaciDwvc3Bhbj48c3Bh
biBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNr
OyBGT05ULVNJWkU6IDEwcHQiPjI2PC9zcGFuPjxzcGFuIHN0eWxlPSJDT0xPUjogYmxhY2s7IEZP
TlQtU0laRTogMTBwdCIgbGFuZz0iWkgtQ04iPuaXpTwvc3Bhbj48c3BhbiBzdHlsZT0iRk9OVC1G
QU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEw
cHQiPg0KIDE2OjAzPGJyPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJDT0xPUjogYmxhY2s7IEZPTlQt
U0laRTogMTBwdCIgbGFuZz0iWkgtQ04iPuWIsDwvc3Bhbj48c3BhbiBzdHlsZT0iRk9OVC1GQU1J
TFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQi
PjogWmhhbmdmYXRhaTsgY2NhbXBAaWV0Zi5vcmc8YnI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9IkNP
TE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0IiBsYW5nPSJaSC1DTiI+5Li76aKYPC9zcGFuPjxz
cGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogYmxh
Y2s7IEZPTlQtU0laRTogMTBwdCI+OiBSRTogW0NDQU1QXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRm
LWNjYW1wLWdtcGxzLWdlbmVyYWwtY29uc3RyYWludHMtb3NwZi10ZS0wMi50eHQ8YnI+DQo8YnI+
DQpIaSw8YnI+DQo8YnI+DQpJIGhhdmUgdGhlIGZvbGxvd2luZyBjb21tZW50cy9xdWVzdGlvbiBy
ZWdhcmRpbmcgdGhpcyByZXZpc2lvbjxicj4NCjxicj4NCjMuMi4gQXZhaWxhYmxlIExhYmVsczo8
YnI+DQo8YnI+DQpUaGUgdGV4dCBzdGF0ZSA6IOKAnFRoZSBBdmFpbGFibGUgTGFiZWxzIHN1Yi1U
TFYmbmJzcDsmbmJzcDsgbWF5IG9jY3VyIGF0IG1vc3Qgb25jZSB3aXRoaW4gdGhlIGxpbmsgVExW
LuKAnTxicj4NCjxicj4NCkhvdyB0byBlbmNvZGUgZGlmZmVyZW50IGxhYmVsIGZvcm1hdCBpbiB0
aGF0IGNhc2U/IEkgdGhpbmsgdGhlIGxhYmVsIGZvcm1hdCB3b3VsZCBkZXBlbmQ8YnI+DQpvbiB0
aGUgSVNDRCwgYW5kIGFzIHdlIG1pZ2h0IGhhdmUgc2V2ZXJhbCBJU0NELCBoYXZpbmcgc2V2ZXJh
bCBBdmFpbGFibGUgTGFiZWwgc3ViLVRMViBtYWtlIHNlbnNlLjxicj4NClRoaXMgYWxzbyBhcHBs
eSB0byAzLjMuIFNoYXJlZCBCYWNrdXAgTGFiZWxzLjxicj4NCjxicj4NCjwvc3Bhbj48c3BhbiBz
dHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsdWU7IEZP
TlQtU0laRTogMTBwdCI+W0ZhdGFpXSBUaGlzICZxdW90O21heSZxdW90OyBzaG91bGQgYmUgJnF1
b3Q7TUFZJnF1b3Q7IGFjY29yZGluZyB0byBMb3UncyBzdWdnZXN0aW9uLCBzbyBpdCBkb2VzIG5v
dCBwcmV2ZW50IHlvdSB0byBoYXZlIHNldmVyYWwgYXZhaWxhYmxlIGxhYmVsIHN1Yi1UTFZzLg0K
PC9zcGFuPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3Nlcmlm
JzsgQ09MT1I6IGJsYWNrIj48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZ
OiAnQ2FsaWJyaScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMXB0
Ij5bQ3lyaWxdIFN0YXRpbmcg4oCcVGhlIEF2YWlsYWJsZSBMYWJlbHMgc3ViLVRMViZuYnNwOyZu
YnNwOyBNQVkgJm5ic3A7b2NjdXIgbW9yZSB0aGFuIG9uY2Ugd2l0aGluIHRoZSBsaW5rIFRMVi7i
gJ0gJm5ic3A7V291bGQgYmUgbW9yZSBhY2N1cmF0ZSBhbmQgZWFzaWVyIHRvIHVuZGVyc3RhbmQu
PC9zcGFuPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3Nlcmlm
JzsgQ09MT1I6IGJsYWNrIj48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZ
OiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogYmxhY2siPjwvc3Bhbj4mbmJzcDs8
L3A+DQo8cD48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsg
Q09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiPjxicj4NCkluIGNhc2Ugb2Ygc2V2ZXJhbCBJ
U0NEIGFyZSBwcmVzZW50IGZvciBhIGdpdmVuIGFkdmVydGlzZW1lbnQgaG93IHRvIGludGVycHJl
dCB0aGUgbGFiZWwgZm9ybWF0IGluIHRoZTxicj4NCmxhYmVsLXJlbGF0ZWQgc3ViLVRMVnM/PC9z
cGFuPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsg
Q09MT1I6IGJsYWNrIj48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAn
VGFob21hJywnc2Fucy1zZXJpZic7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0Ij48YnI+
DQo8L3NwYW4+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7
IENPTE9SOiBibHVlOyBGT05ULVNJWkU6IDEwcHQiPltGYXRhaV0gSXQgaXMgZWFzeSB0byBhY2hp
dmUgdGhhdC4gZS5nLCZuYnNwO2luIFNESCBuZXR3b3JrLCBhIG5vZGUgY2FuIGFkdmVydGlzZSBz
ZXZlcmFsIElTQ0RzJm5ic3A7d2l0aCBvbmUgb3IgbXVsdGlwbGUgbGFiZWwgc3ViLVRMVnMgKEkg
YXNzdW1lICZxdW90O0lGJnF1b3Q7IGxhYmVsIGluZm9ybWF0aW9uIGlzIG5lZWRlZCB0bw0KIGJl
IGFkdmVydGlzZWQgaGVyZSksIHdoeSBpdCBjYW5ub3QgaW50ZXJwcmV0IHRoZSBsYWJlbHMgYXJl
IFNESCBsYWJlbHM/PC9zcGFuPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBS
b21hbicsJ3NlcmlmJzsgQ09MT1I6IGJsYWNrIj48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9
IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05U
LVNJWkU6IDEwcHQiPltDeXJpbF0mbmJzcDsgSWYgdGhlcmUgaXMgMiBJU0NEIHN1Yi1UTFYgYW5k
IDIgYXZhaWxhYmxlIGxhYmVsIHN1Yi1UTFYsIGhvdyB0byB0ZWxsIHdoaWNoIGF2YWlsYWJsZSBs
YWJlbCBzdWItVExWIHJlbGF0ZSB0byB3aGljaCBJU0NEIHN1Yi1UTFY/PC9zcGFuPjxzcGFuIHN0
eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgQ09MT1I6IGJsYWNr
Ij48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJv
bWFuJywnc2VyaWYnOyBDT0xPUjogYmxhY2siPjwvc3Bhbj4mbmJzcDs8L3A+DQo8cD48c3BhbiBz
dHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNrOyBG
T05ULVNJWkU6IDEwcHQiPjxicj4NCkNvdWxkIHlvdSBjbGFyaWZ5IHRoaXMgcG9pbnQsIGl0IHdv
dWxkIGJlIHVzZWZ1bCBmb3IgaW5zdGFuY2UgdG8gY29uc2lkZXIgdGhlIGV4YW1wbGUgb2YgYSBs
aW5rIHN1cHBvcnRpbmcgU0RIPGJyPg0KKG5vIFZDNC1zd2l0Y2hpbmcpLCBPRFUgKEcuNzA5LCBh
cyBvZiBSRkM0MzI4LCBhbmQgZm9yIHRoZSBjdXJyZW50IEcuNzA5IHYzIGxhYmVsIGZvcm1hdCku
PC9zcGFuPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3Nlcmlm
JzsgQ09MT1I6IGJsYWNrIj48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZ
OiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogYmxhY2siPjwvc3Bhbj4mbmJzcDs8
L3A+DQo8cD48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsg
Q09MT1I6IGJsdWU7IEZPTlQtU0laRTogMTBwdCI+W0ZhdGFpXSZuYnNwOyBEbyB5b3UgbWVhbiB0
byBoYXZlIGFuIGV4YW1wbGUgb24gaHlicmlkIG5vZGU/IEkgd2lsbCBub3QmbmJzcDt1c2UmbmJz
cDthIGNvbXBsZXgmbmJzcDtleGFtcGxlIHRvIGV4cGxhaW4gYSZuYnNwO2tpbmQgb2Ygc2ltcGxl
IHRoaW5nIChJdCB3aWxsIGNvbmZ1c2UgcGVvcGxlKS4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iRk9O
VC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBibGFjayI+PC9zcGFu
PjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlm
JzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+W0N5cmlsXSBJdCBtYXkgbm90IGJl
IHNvIHNpbXBsZSwgSSBoYXZlIHRyb3VibGUgdG8gaW50ZXJwcmV0IGxhYmVsIHdpdGhvdXQga25v
d2luZyB0aGUgSVNDRCBjb25zaWRlcmVkIGFuZCBJIGRvIG5vdCBzZWUgY2xlYXJseSB0aGUgcmVs
YXRpb24gYmV0d2VlbiB0aGUgdHdvIGluIHRoZSBkb2N1bWVudC48L3NwYW4+PHNwYW4gc3R5bGU9
IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogYmxhY2siPjwv
c3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNl
cmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiPjxicj4NClRoZSB0ZXh0IGlzIHZl
cnkgZm9jdXNlZCBvbiBXU09OLCB3aGlsZSBpdCBpcyBhIHZlcnkgaW50ZXJlc3RpbmcgZXhhbXBs
ZSwgaGF2aW5nIG90aGVyIHRlY2hub2xvZ3kgKE9UTiBmb3I8YnI+DQpleGFtcGxlIHdvdWxkIGhl
bHAgdG8gc2hvdyB0aGF0IHRoZSBzb2x1dGlvbiBpcyBnZW5lcmljLjwvc3Bhbj48c3BhbiBzdHls
ZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBibGFjayI+
PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMt
c2VyaWYnOyBDT0xPUjogYmx1ZTsgRk9OVC1TSVpFOiAxMHB0Ij5bRmF0YWldIEkgdGhpbmsgb25l
IHR5cGljYWwgZXhhbXBsZSBpcyBzdWZmaWNpZW50IGZvciBwZW9wbGUgdG8gdW5kZXJzdGFuZCB0
aGluZ3MuIFRETSBuZXR3b3JrIGlzIGRpZmZlcmVudCBmcm9tIFdTT04gbmV0d29yay4mbmJzcDtJ
biBURE0gbmV0d29yaywgdXN1YWxseSBpdCB3aWxsIG5vdCBhZHZlcnRpc2UgbGFiZWwNCiBpbmZv
cm1hdGlvbiBldmVuIHRob3VnaCBsYWJlbCBpbmZvcm1hdGlvbiBjb3VsZCBiZSBhZHZlcnRpc2Vk
Ljwvc3Bhbj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJp
Zic7IENPTE9SOiBibGFjayI+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlM
WTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpFOiAxMHB0
Ij5bQ3lyaWxdIFRoZXkgYXJlIGluZGVlZCBkaWZmZXJlbnQsIGJ1dCBmcm9tIGxhYmVsIHBvaW50
IG9mIHZpZXcgaXQgc2hvdWxkIG5vdCBtYWtlIGEgZGlmZmVyZW5jZS4gQSB1c3VhbCB1c2UgY2Fz
ZSBvZiBjb25uZWN0aXZpdHkgbWF0cml4IHdvdWxkIGJlIGZvciBleGFtcGxlIG9uIGNsaWVudCBj
YXJkcw0KIHdpdGggc3dpdGNoaW5nIHJlc3RyaWN0aW9uIDogZml4ZWQgTXVsdGlwbGV4IGFuZCBs
YWJlbCBhc3NpZ25tZW50IGR1ZSB0byB0aGUgZml4ZWQgTVVYIChPRFUyLSZndDtPRFUxIGZvciBp
bnN0YW5jZSkgJm5ic3A7b24gRFdETSBub2RlIDo8L3NwYW4+PHNwYW4gc3R5bGU9IkZPTlQtRkFN
SUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogYmxhY2siPjwvc3Bhbj48L3A+
DQo8cCBzdHlsZT0iVEVYVC1JTkRFTlQ6IDMwLjc1cHQ7IE1BUkdJTi1MRUZUOiA1LjI1cHQiPjxz
cGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFm
NDk3ZDsgRk9OVC1TSVpFOiAxMHB0Ij50aGUgcmVzdHJpY3Rpb24gY2FuIGJlIG1vZGVsZWQgYXMg
b25lIGNvbm5lY3Rpdml0eSBtYXRyaXggcGVyIGNsaWVudCBwb3J0LDwvc3Bhbj48c3BhbiBzdHls
ZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBibGFjayI+
PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJNQVJHSU4tTEVGVDogMTAuNXB0Ij48c3BhbiBzdHlsZT0i
Rk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQt
U0laRTogMTBwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO3Ro
ZSBjbGllbnQgcG9ydCBoYXZlIHRoZW4gSVNDRCBURE0sDQo8L3NwYW4+PHNwYW4gc3R5bGU9IkZP
TlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xPUjogYmxhY2siPjwvc3Bh
bj48L3A+DQo8cCBzdHlsZT0iTUFSR0lOLUxFRlQ6IDEwLjVwdCI+PHNwYW4gc3R5bGU9IkZPTlQt
RkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6
IDEwcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO3Ro
ZSBvdGhlciBwb3J0cyBjYW4gZG8gRFdETSBhbmQgVERNLA0KPC9zcGFuPjxzcGFuIHN0eWxlPSJG
T05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3NlcmlmJzsgQ09MT1I6IGJsYWNrIj48L3Nw
YW4+PC9wPg0KPHAgc3R5bGU9Ik1BUkdJTi1MRUZUOiAxMC41cHQiPjxzcGFuIHN0eWxlPSJGT05U
LUZBTUlMWTogJ1RhaG9tYScsJ3NhbnMtc2VyaWYnOyBDT0xPUjogIzFmNDk3ZDsgRk9OVC1TSVpF
OiAxMHB0Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtm
b3IgdGhlIGNvbm5lY3Rpdml0eSBtYXRyaXggY29ycmVzcG9uZGluZyB0byBhIGNsaWVudCBwb3J0
IHRoZSBvbmx5IE9EVSBsYWJlbCB0byBiZSBhc3NpZ25lZCAoZHVlIHRvIGZpeGVkIE1VWCkgaXMg
c3BlY2lmaWVkDQo8L3NwYW4+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJv
bWFuJywnc2VyaWYnOyBDT0xPUjogYmxhY2siPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0i
Rk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBibGFjayI+PC9z
cGFuPiZuYnNwOzwvcD4NCjxwPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdz
YW5zLXNlcmlmJzsgQ09MT1I6ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+Rmlyc3QsIGlzIHRo
aXMgbW9kZWxpbmcgY29ycmVjdD8NCjwvc3Bhbj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdU
aW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBibGFjayI+PC9zcGFuPjwvcD4NCjxwPjxz
cGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6ICMx
ZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+U2Vjb25kLCBob3cgdG8gbWFrZSBzdXJlIHRoZSBsYWJl
bCByZXN0cmljdGlvbiBhcmUgdG8gYmUgaW50ZXJwcmV0ZWQgYXMgT0RVIGxhYmVscz88L3NwYW4+
PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGltZXMgTmV3IFJvbWFuJywnc2VyaWYnOyBDT0xP
UjogYmxhY2siPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1l
cyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBibGFjayI+PC9zcGFuPiZuYnNwOzwvcD4NCjxw
PjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ0NhbGlicmknLCdzYW5zLXNlcmlmJzsgQ09MT1I6
ICMxZjQ5N2Q7IEZPTlQtU0laRTogMTFwdCI+SSB0aGluayBpdCBpcyBhbHNvIGltcG9ydGFudCB0
byBzaG93IHRoYXQgdGhlIGV4dGVuc2lvbnMgYXJlIGFsc28gd29ya2luZyBvdXRzaWRlIHRoZSBm
cmFtZXdvcmsgdGhleSB3ZXJlIGJvcm4gKFdTT04pLjwvc3Bhbj48c3BhbiBzdHlsZT0iRk9OVC1G
QU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7IENPTE9SOiBibGFjayI+PC9zcGFuPjwv
cD4NCjxwPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21hbicsJ3Nlcmlm
JzsgQ09MT1I6IGJsYWNrIj48L3NwYW4+Jm5ic3A7PC9wPg0KPHA+PHNwYW4gc3R5bGU9IkZPTlQt
RkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9SOiAjMWY0OTdkOyBGT05ULVNJWkU6
IDEwcHQiPkJSPC9zcGFuPjxzcGFuIHN0eWxlPSJGT05ULUZBTUlMWTogJ1RpbWVzIE5ldyBSb21h
bicsJ3NlcmlmJzsgQ09MT1I6IGJsYWNrIj48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9IkZP
TlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJpZic7IENPTE9SOiBibGFjazsgRk9OVC1TSVpF
OiAxMHB0Ij48YnI+DQo8YnI+DQpCZXN0IFJlZ2FyZHMsPGJyPg0KQ3lyaWw8YnI+DQo8YnI+DQom
Z3Q7IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KJmd0OyBGcm9tOiBjY2FtcC1ib3Vu
Y2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmPGJy
Pg0KJmd0OyBPZiBleHQgWmhhbmdmYXRhaTxicj4NCiZndDsgU2VudDogVGh1cnNkYXksIFNlcHRl
bWJlciAyMiwgMjAxMSAxMToxNyBBTTxicj4NCiZndDsgVG86IGNjYW1wQGlldGYub3JnPGJyPg0K
Jmd0OyBTdWJqZWN0OiBSZTogW0NDQU1QXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNjYW1wLWdt
cGxzLWdlbmVyYWwtPGJyPg0KJmd0OyBjb25zdHJhaW50cy1vc3BmLXRlLTAyLnR4dDxicj4NCiZn
dDs8YnI+DQomZ3Q7IEhpIENDQU1QZXJzLDxicj4NCiZndDs8YnI+DQomZ3Q7IEEgbmV3IHZlcnNp
b24gaGFzIGJlZW4gc3VibWl0dGVkIHRvIGFkZHJlc3MgdGhlIGNvbW1lbnRzIGZyb20gdGhlIFdH
PGJyPg0KJmd0OyBkaXNjdXNzaW9uLjxicj4NCiZndDs8YnI+DQomZ3Q7IFdlIGFjY2VwdGVkIEFj
ZWUgYW5kIFlvdW5nJ3Mgc3VnZ2VzdGlvbiB0byBpbnRyb2R1Y2UgYSBuZXcgdG9wLWxldmVsPGJy
Pg0KJmd0OyBub2RlIFRMViAoR2VuZXJpYyBOb2RlIEF0dHJpYnV0ZSBUTFYpIHRvIHNpbXBsaWZ5
IHRoaW5ncyBhbmQgYSBuZXc8YnI+DQomZ3Q7IHNlY3Rpb24gKFNlY3Rpb24gNSkgd2FzIGFkZGVk
IHRvIGRlc2NyaWJlIHNjYWxhYmlsaXR5IGlzc3VlLjxicj4NCiZndDs8YnI+DQomZ3Q7IE1vcmUg
aW5mb3JtYXRpb24gZnJvbTogaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRmLWNjYW1w
LWdtcGxzLTxicj4NCiZndDsgZ2VuZXJhbC1jb25zdHJhaW50cy1vc3BmLXRlLTAyLnR4dDxicj4N
CiZndDs8YnI+DQomZ3Q7IFBsZWFzZSBjaGVjayBvdXQgZm9yIGRldGFpbHMgYW5kIGNvbW1lbnRz
IGFyZSBhbHdheXMgd2VsY29tZS48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhhbmtz
PGJyPg0KJmd0Ozxicj4NCiZndDsgRmF0YWk8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsg
LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQomZ3Q7IEZyb206IGNjYW1wLWJvdW5jZXNA
aWV0Zi5vcmcgW21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGY8YnI+DQom
Z3Q7IE9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxicj4NCiZndDsgU2VudDogMjAxMTwvc3Bh
bj48c3BhbiBzdHlsZT0iQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEwcHQiIGxhbmc9IlpILUNO
Ij7lubQ8L3NwYW4+PHNwYW4gc3R5bGU9IkZPTlQtRkFNSUxZOiAnVGFob21hJywnc2Fucy1zZXJp
Zic7IENPTE9SOiBibGFjazsgRk9OVC1TSVpFOiAxMHB0Ij45PC9zcGFuPjxzcGFuIHN0eWxlPSJD
T0xPUjogYmxhY2s7IEZPTlQtU0laRTogMTBwdCIgbGFuZz0iWkgtQ04iPuaciDwvc3Bhbj48c3Bh
biBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNr
OyBGT05ULVNJWkU6IDEwcHQiPjIyPC9zcGFuPjxzcGFuIHN0eWxlPSJDT0xPUjogYmxhY2s7IEZP
TlQtU0laRTogMTBwdCIgbGFuZz0iWkgtQ04iPuaXpTwvc3Bhbj48c3BhbiBzdHlsZT0iRk9OVC1G
QU1JTFk6ICdUYWhvbWEnLCdzYW5zLXNlcmlmJzsgQ09MT1I6IGJsYWNrOyBGT05ULVNJWkU6IDEw
cHQiPg0KIDE3OjA2PGJyPg0KJmd0OyBUbzogaS1kLWFubm91bmNlQGlldGYub3JnPGJyPg0KJmd0
OyBDYzogY2NhbXBAaWV0Zi5vcmc8YnI+DQomZ3Q7IFN1YmplY3Q6IFtDQ0FNUF0gSS1EIEFjdGlv
bjogZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLTxicj4NCiZndDsgY29uc3RyYWludHMt
b3NwZi10ZS0wMi50eHQ8YnI+DQomZ3Q7PGJyPg0KJmd0OyBBIE5ldyBJbnRlcm5ldC1EcmFmdCBp
cyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHM8YnI+DQomZ3Q7IGRp
cmVjdG9yaWVzLiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBDb21tb24gQ29udHJv
bCBhbmQ8YnI+DQomZ3Q7IE1lYXN1cmVtZW50IFBsYW5lIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElF
VEYuPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgVGl0bGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgOiBPU1BGLVRFIEV4dGVuc2lvbnMgZm9yIEdlbmVyYWwgTmV0d29yayBFbGVt
ZW50PGJyPg0KJmd0OyBDb25zdHJhaW50czxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsgQXV0aG9yKHMpJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7IDogRmF0YWkgWmhhbmc8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IFlvdW5nIExlZTxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgSmlhbnJ1aSBIYW48YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEdyZWcgQmVybnN0ZWluPGJyPg0KJmd0OyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBZdW5iaW4gWHU8YnI+DQomZ3Q7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZpbGVuYW1lJm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5l
cmFsLWNvbnN0cmFpbnRzLTxicj4NCiZndDsgb3NwZi10ZS0wMi50eHQ8YnI+DQomZ3Q7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBhZ2VzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogMTQ8YnI+DQomZ3Q7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERhdGUmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiAyMDExLTA5
LTIyPGJyPg0KJmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgR2VuZXJhbGl6ZWQgTXVs
dGlwcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcgY2FuIGJlIHVzZWQgdG8gY29udHJvbCBhPGJyPg0K
Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyB3aWRlIHZhcmlldHkgb2YgdGVjaG5vbG9naWVzIGluY2x1
ZGluZyBwYWNrZXQgc3dpdGNoaW5nIChlLmcuLDxicj4NCiZndDsgTVBMUyksPGJyPg0KJmd0OyZu
YnNwOyZuYnNwOyZuYnNwOyB0aW1lLWRpdmlzaW9uIChlLmcuLCBTT05FVC9TREgsIE9UTiksIHdh
dmVsZW5ndGggKGxhbWJkYXMpLCBhbmQ8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHNwYXRp
YWwgc3dpdGNoaW5nIChlLmcuLCBpbmNvbWluZyBwb3J0IG9yIGZpYmVyIHRvIG91dGdvaW5nIHBv
cnQgb3I8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZpYmVyKS4gSW4gc29tZSBvZiB0aGVz
ZSB0ZWNobm9sb2dpZXMgbmV0d29yayBlbGVtZW50cyBhbmQgbGlua3MgbWF5PGJyPg0KJmd0OyZu
YnNwOyZuYnNwOyZuYnNwOyBpbXBvc2UgYWRkaXRpb25hbCByb3V0aW5nIGNvbnN0cmFpbnRzIHN1
Y2ggYXMgYXN5bW1ldHJpYyBzd2l0Y2g8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNvbm5l
Y3Rpdml0eSwgbm9uLWxvY2FsIGxhYmVsIGFzc2lnbm1lbnQsIGFuZCBsYWJlbCByYW5nZTxicj4N
CiZndDsgbGltaXRhdGlvbnM8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IG9uIGxpbmtzLiBU
aGlzIGRvY3VtZW50IGRlc2NyaWJlcyBPU1BGIHJvdXRpbmcgcHJvdG9jb2wgZXh0ZW5zaW9uczxi
cj4NCiZndDsgdG88YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN1cHBvcnQgdGhlc2Uga2lu
ZHMgb2YgY29uc3RyYWludHMgdW5kZXIgdGhlIGNvbnRyb2wgb2YgR2VuZXJhbGl6ZWQ8YnI+DQom
Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1QTFMgKEdNUExTKS48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi
cj4NCiZndDs8YnI+DQomZ3Q7IEEgVVJMIGZvciB0aGlzIEludGVybmV0LURyYWZ0IGlzOjxicj4N
CiZndDsgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1jY2Ft
cC1nbXBscy1nZW5lcmFsLTxicj4NCiZndDsgY29uc3RyYWludHMtb3NwZi10ZS0wMi50eHQ8YnI+
DQomZ3Q7PGJyPg0KJmd0OyBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFu
b255bW91cyBGVFAgYXQ6PGJyPg0KJmd0OyBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh
ZnRzLzxicj4NCiZndDs8YnI+DQomZ3Q7IFRoaXMgSW50ZXJuZXQtRHJhZnQgY2FuIGJlIHJldHJp
ZXZlZCBhdDo8YnI+DQomZ3Q7IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJh
ZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLTxicj4NCiZndDsgY29uc3RyYWludHMtb3NwZi10
ZS0wMi50eHQ8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fPGJyPg0KJmd0OyBDQ0FNUCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IENDQU1QQGll
dGYub3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nj
YW1wPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fXzxicj4NCiZndDsgQ0NBTVAgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBDQ0FNUEBpZXRmLm9y
Zzxicj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcDwv
c3Bhbj48c3BhbiBzdHlsZT0iRk9OVC1GQU1JTFk6ICdUaW1lcyBOZXcgUm9tYW4nLCdzZXJpZic7
IENPTE9SOiBibGFjayI+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s
Pg0K

--Boundary_(ID_BuyNgPDHLylCiO8HmLJE/w)--

From cyril.margaria@nsn.com  Fri Sep 30 01:43:12 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7770321F8B59 for ; Fri, 30 Sep 2011 01:43:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.277
X-Spam-Level: 
X-Spam-Status: No, score=-5.277 tagged_above=-999 required=5 tests=[AWL=-0.331, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zx8oDe-HZyRf for ; Fri, 30 Sep 2011 01:43:10 -0700 (PDT)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id E92B721F8B57 for ; Fri, 30 Sep 2011 01:43:08 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p8U8jjeB017403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 30 Sep 2011 10:45:45 +0200
Received: from DEMUEXC047.nsn-intra.net ([10.159.32.93]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p8U8je8f012507; Fri, 30 Sep 2011 10:45:45 +0200
Received: from DEMUEXC012.nsn-intra.net ([10.150.128.23]) by DEMUEXC047.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675);  Fri, 30 Sep 2011 10:45:37 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC7F4D.5308DA1B"
Date: Fri, 30 Sep 2011 10:45:30 +0200
Message-ID: 
In-Reply-To: A
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: =?utf-8?B?IOetlOWkjTogIOetlOWkjTogIOetlOWkjTogIOetlOWkjTogW0NDQU1QXSBJLUQg?= =?utf-8?B?QWN0aW9uOiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWc=?= =?utf-8?B?ZW5lcmFsLWNvbnN0cmFpbnRzLW9zcGYtdGUtMDIudHg=?= =?utf-8?B?dA==?=
Thread-Index: AQHMeQhw4fH7IgNgHEuaM0yhaE8MRpVfUxoggAGhYTmAAAbksIABGMsGgAIOXpCAAAelMIAAB0lQgAEHgRiAAGgc0A==
References: <20110922090626.6373.58763.idtracker@ietfa.amsl.com>   A   A   A   A
From: "Margaria, Cyril (NSN - DE/Munich)" 
To: "ext Zhangfatai" , 
X-OriginalArrivalTime: 30 Sep 2011 08:45:37.0892 (UTC) FILETIME=[539D2A40:01CC7F4D]
Subject: Re: [CCAMP] =?utf-8?b?562U5aSNOiAg562U5aSNOiAg562U5aSNOiAg562U5aSN?= =?utf-8?q?=3A__I-D_Action=3A_draft-ietf-ccamp-gmpls-general-constr?= =?utf-8?q?aints-ospf-te-02=2Etxt?=
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Sep 2011 08:43:12 -0000

This is a multi-part message in MIME format.

------_=_NextPart_001_01CC7F4D.5308DA1B
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: base64

IA0KDQpIaSwgDQoNCiANCg0KTXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgaHlicmlkIG5vZGUgaXMg
dGhlIGZvbGxvd2luZyA6IHRoZSBwb3J0cyAjYiBhbmQgI2MgYXJlIFRETSBwb3J0cyAsIHBvcnQg
I2IgdGVybWluYXRlIHRoZSBWQzQgdHJhaWwgYW5kIHByb3ZpZGUgYSBQU0MgQWNjZXNzIHBvaW50
Lg0KDQogDQoNClRoZSBleGFtcGxlIEkgc2hvd24gaXMgYSBub2RlIHdpdGggYSBQWEMgLiBwb3J0
ICNlIGluIFRETSBpcyBhIGNvbG9yZWQgT1RVMyBwb3J0LCBzbyBJIHdvdWxkIGJlIGludGVyZXN0
ZWQgdG8ga25vdyB3aGF0IG1ha2VzIHlvdSB0aGluayB0aGUgZXhhbXBsZSBjaG9vc2VuIGlzDQoN
Cm5vdCBPVE4gZXF1aXBtZW50PyBUaGUgcGh5c2ljYWwgbGluayBkb2VzIG5vdCBzdXBwb3J0IGJv
dGggc3dpdGNoaW5nLCBidXQgdGhlIEdNUExTIGxpbmsgaW50ZXJmYWNlIGNhbiwgYXMgZXhwbGFp
bmVkIGluIFJGQzQzOTcgc2VjdGlvbiAzLjYuMiwgdGhpcyBjYW4gbWl4IHRoZSB0cmFpbCB0ZXJt
aW5hdGlvbiBhbmQgYWRhcHRhdGlvbiBhbmQgc2VydmVyIGxheWVyIGNvbm5lY3Rpb24gcG9pbnQs
IHdoaWNoIGlzIGV4YWN0bHkgdGhlIGNvbmNlcHQgaWxsdXN0cmF0ZWQgaW4gUkZDNTMzOSBhbmQg
bXkgZXhhbXBsZS4NCg0KIA0KDQpJIGNvdWxkIGFsc28gdGFrZSB0aGUgRmlndXJlIDMgb2YgZHJh
ZnQtaWV0Zi1jY2FtcC1yd2EtaW5mby0xMiwgaW50ZXJuYWwgcG9ydCAxIDIgMyA0IG9mIHRoZSBS
T0FETSBjYW4gYmUgY29ubmVjdGVkIGludGVybmFsIHRvIGFuIE9UVTMgLT4gT0RVMyAtPiBPRFUy
IC0+IE9UVTIgcG9ydHMsIA0KDQpVc2luZyBSRkM2MDAxIGlzIHBvc3NpYmxlIGJ1dCBub3QgbWFu
ZGF0b3J5LCB0aGUgbmV3IHNvbHV0aW9uIHNob3VsZCBhbHNvIHdvcmsgd2l0aCBhbmQgd2l0aG91
dCBzdXBwb3J0IG9mIFJGQzYwMDEgKG9yIG1hbmRhdGUgc3VwcG9ydCBvZiBSRkM2MDAxKSANCg0K
IA0KDQpJIGFtIHN0aWxsIG1pc3NpbmcgcnVsZXMgb24gaG93IHRvIGludGVycHJldCB0aGUgbGFi
ZWwgZm9ybWF0IGluIHRoZSBleGFtcGxlcyBJIHByb3ZpZGVkLCBJdCB3b3VsZCBiZSBlcXVhbGx5
IGludGVyZXN0aW5nIHRvIGFkZCB0aGUgdGhpcmQgZXhhbXBsZSB5b3UgbWVudGlvbmVkICh3aXRo
IElBQ0QpIA0KDQogDQoNClRoZSBleGFtcGxlcyBJIG1lbnRpb25lZCBjb21lIGZvciBleGlzdGlu
ZyBub2RlIGFyY2hpdGVjdHVyZSB3aGVyZSB0aGUgZ2VuZXJhbCBjb25zdHJhaW50cyBhcmUgdmVy
eSB1c2VmdWwsIGJ1dCBzb21lIHBvaW50cyBzdGlsbCAgcmVtYWlucyB0byBiZSBjbGFyaWZpZWQu
DQoNCiANCg0KVGhhdCBzYWlkLCB0aGVyZSBpcyBzZXZlcmFsIHBvdGVudGlhbCBzb2x1dGlvbiB0
aGF0IGNvdWxkIGJlIGNvbnNpZGVyZWQgYW5kIGJlIGdlbmVyaWMgOiANCg0KLSAgICAgICAgICBF
eHBsaWNpdGx5IHNjb3BlIHRoZSBsYWJlbHMgYnkgaGF2aW5nIChzd2l0Y2hpbmcgdHlwZSwgZW5j
b2RpbmcpICBmb3IgcG9ydCBsYWJlbCByZXN0cmljdGlvbiwgYXZhaWxhYmxlIGxhYmVscywgc2hh
cmVkIGxhYmVscywgYSBjb3JyZXNwb25kaW5nIElTQ0Qgb3IgSUFDRCBNVVNUIGJlIHByZXNlbnQN
Cg0KLSAgICAgICAgT25seSBhbGxvdyBvbmUgSVNDRCAoSXQgd2lsbCBiZSBhIGJpZyByZXN0cmlj
dGlvbikgYW5kIGV4dGVuZCBJQUNEIChtYXliZSB1c2luZyBBZGp1c3RtZW50IENhcGFiaWxpdHkt
c3BlY2lmaWMgaW5mb3JtYXRpb24gKSANCi0gICAgID8NCg0KIA0KDQpCUiANCg0KQ3lyaWwNCg0K
IA0KDQogDQoNCkZyb206IGV4dCBaaGFuZ2ZhdGFpIFttYWlsdG86emhhbmdmYXRhaUBodWF3ZWku
Y29tXSANClNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDMwLCAyMDExIDQ6NDQgQU0NClRvOiBNYXJn
YXJpYSwgQ3lyaWwgKE5TTiAtIERFL011bmljaCk7IGNjYW1wQGlldGYub3JnDQpTdWJqZWN0OiDn
rZTlpI06IOetlOWkjTog562U5aSNOiDnrZTlpI06IFtDQ0FNUF0gSS1EIEFjdGlvbjogZHJhZnQt
aWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLWNvbnN0cmFpbnRzLW9zcGYtdGUtMDIudHh0DQoNCiAN
Cg0KSGkgQ3lyaWwsDQoNCiANCg0KSW50ZXJlc3RpbmcgZXhhbXBsZS4gVGhlIGhicmlkIGV4YW1w
bGUgaW4gUkZDNTMzOSBpcyBURE0rUFNDICh0aGF0IGlzIGNvbWluZyB0byB1cyksIGluc3RlYWQg
b2YgVERNK0RXRE0gKEkgdGhpbmsgeW91ciBleGFtcGxlIGlzIG5vdCBPVE4gZXF1aXBtZW50KSwg
Oi0pDQoNCiANCg0KSW4geW91ciBleGFtcGxlLCBmb3IgdGhlIFRFIGxpbmsgNSwgaXQgd2lsbC9j
b3VsZCBhZHZlcnRpc2UgV1NPTiBsaW5rcyArSUFDRCBiYXNlZCBvbiBSRkM2MDAxKEluIHRoaXMg
d2F5LCB0aGVyZSBpcyBzdGlsbCBpbXBsaWNpdCByZWxhdGlvbnNoaXAgYmV0d2VlbiBJU0NEcyBh
bmQgbGFiZWwgc3ViLVRMVnMpLg0KDQpDZXJ0YWludGx5LCBJIHRoaW5rIHRoZXJlIGlzIHN0aWxs
IGxvZnMgb2Ygd29yayB0byBiZSBkb25lIGZvciBNTE4gY29udHJvbCBiZWNhdXNlIFJGQzYwMDEg
aXMgbm90IHN1ZmZpY2llbnQuDQoNCiANCg0KQW55d2F5LCB5b3VyIGV4YW1wbGUgaXMgYXBwcmVj
aWF0ZWQuDQoNCiANCg0KIA0KDQpUaGFua3MNCg0KIA0KDQpGYXRhaQ0KDQogDQoNCiANCg0KIA0K
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQrlj5Hku7bkuro6IE1hcmdhcmlh
LCBDeXJpbCAoTlNOIC0gREUvTXVuaWNoKSBbY3lyaWwubWFyZ2FyaWFAbnNuLmNvbV0NCuWPkemA
geaXtumXtDogMjAxMeW5tDnmnIgyOeaXpSAxOTowNQ0K5YiwOiBaaGFuZ2ZhdGFpOyBjY2FtcEBp
ZXRmLm9yZw0K5Li76aKYOiBSRTog562U5aSNOiDnrZTlpI06IOetlOWkjTogW0NDQU1QXSBJLUQg
QWN0aW9uOiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWdlbmVyYWwtY29uc3RyYWludHMtb3NwZi10
ZS0wMi50eHQNCg0KSGkgRmF0YWksIA0KDQogDQoNCkZvciBteSBleGFtcGxlIEkgdG9vayB0aGUg
ZXhhbXBsZSBmcm9tIFJGQzUzMzkgKGFsc28gZm9sbG93aW5nIHRoZSBsb2dpYyBvZiBSRkM0MjAy
IHNlY3Rpb24gMi40LjYpLCBhZGp1c3RpbmcgdGhlIGNhcGFiaWxpdGllcyBhbmQgZXh0ZW5kZWQg
dGhlIG51bWJlciBvZiBwb3J0czoNCg0KIA0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg
IE5ldHdvcmsgZWxlbWVudA0KDQogICAgICAgICAgICAgICAgICAgICAgICAuLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLg0KDQogICAgICAgICAgICAgICAgICAgICAgICA6ICAgICAgICAgICAg
LS0tLS0tLS0gICAgICAgOg0KDQogICAgICAgICAgICAgIFRETSAgICAgICA6ICAgICAgICAgICB8
ICBURE0gICB8ICAgICAgOg0KDQogICAgICAgICAgICBQb3J0MS0tLS0tLS0tLS0tLS08LT4tLS18
I2EgICAgICB8ICAgICAgOg0KDQogICAgICAgICAgICBQb3J0Mi0tLS0tLS0tLS0tLS08LT4tLS18
I2IgICAgICB8ICAgICAgOg0KDQogICAgICAgICAgICBQb3J0My0tLS0tLS0tLS0tLS08LT4tLS18
I2MgICAgICB8ICAgICAgOg0KDQogICAgICAgICAgICBQb3J0NC0tLS0tLS0tLS0tLS08LT4tLS18
I2QgICAgICB8ICAgICAgOg0KDQogICAgICAgICAgICAgICAgICAgICAgICA6ICArLS08LT4tLS18
I2UgICAgICB8ICAgICAgOg0KDQogICAgICAgICAgICAgICAgICAgICAgICA6ICB8ICAgICAgICAg
LS0tLS0tLS0gICAgICAgOg0KDQogICAgICAgICAgICAgICAgICAgICAgICA6ICB8ICAgICAgICAt
LS0tLS0tLS0tICAgICAgOg0KDQogICAgICAgICAgICAgIERXRE0gICAgICA6ICArLS08LT4tLXwj
ZiAgRFdETSAgfCAgICAgOg0KDQogICAgICAgICAgICBQb3J0NSAtLS0tLS0tLS0tLS08LT4tLXwj
ZyAgICAgICAgfCAgICAgOg0KDQogICAgICAgICAgICAgICAgICAgICAgICA6ICAgICAgICAgICAt
LS0tLS0tLS0tICAgICAgOg0KDQogICAgICAgICAgICAgICAgICAgICAgICA6Li4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLg0KDQogDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgIEZpZ3Vy
ZSAxYS4gIEh5YnJpZCBub2RlLg0KDQogDQoNCkZyb20gSVNDRCBwb2ludCBvZiB2aWV3Og0KDQpU
RSBsaW5rIDEgKFBvcnQxKToNCg0KICAgICAtIElTQ0Qgc3ViLVRMVjogVERNICAoT0RVMikgDQoN
ClRFIGxpbmsgMiAoUG9ydDEpOg0KDQogICAgIC0gSVNDRCBzdWItVExWOiBURE0gIChPRFUyKSAN
Cg0K4oCmDQoNClRFLUxpbmsgNSAocG9ydCAyKSA6IA0KDQogICAgIC0gSVNDRCAjMSBzdWItVExW
OiBEV0RNIA0KDQogICAgIC0gSVNDRCAjMiBzdWItVExWOiBURE0sIEcuNzA5IE9EVWsgKE9EVTMp
IA0KDQogDQoNClRoZSBJU0NEICMyIHJlcHJlc2VudCB0aGUgRFdETS1URE0gYWRqdXN0ZW1lbnQg
Y2FwYWJpbGl0eQ0KDQpJIGFtIGxlYXZpbmcgb3V0IGluIHRoaXMgdGhyZWFkIGhvdyB0byBrbm93
IHRoZSBPRU8gY2FwYWJpbGl0eSBvZiBwb3J0ICNmLyNlIDstKQ0KDQogDQoNCiANCg0KV2l0aCB0
aGUgZm9sbG93aW5nIGNvbm5lY3Rpdml0eSBtYXRyaXggKHdpdGggdGhlIGZvbGxvd2luZyBjb252
ZW50aW9uIDogKHtMaW5rIFNldCBBIzF9LHtMaW5rIHNldCBCIzF9KSwoe0xpbmsgU2V0IEEjMn0s
e0xpbmsgc2V0IEIjMn0pLOKApg0KDQogDQoNCk1hdHJpeCAjMSAoe1BvcnQgMX0sIHtQb3J0IDV9
KSANCg0KTWF0cml4ICMyICh7UG9ydCAyfSwge1BvcnQgNX0pDQoNCk1hdHJpeCAjMyAoe1BvcnQg
M30sIHtQb3J0IDV9KQ0KDQpNYXRyaXggIzQgKHtQb3J0IDR9LCB7UG9ydCA1fSkNCg0KIA0KDQpU
RS1MaW5rIDUgKHBvcnQgMikgOiANCg0KICAgICAtIElTQ0QgIzEgc3ViLVRMVjogRFdETSANCg0K
ICAgICAtIElTQ0QgIzIgc3ViLVRMVjogVERNLCBHLjcwOSBPRFVrIChoZXJlIE9EVTMsIGJlY2F1
c2Ugb2YgdGhlIHBvcnQgI2UpDQoNCiAgICAgLSBQb3J0IExhYmVsIHJlc3RyaWN0aW9uIDogTWF0
cml4ICMxLCBSZXN0cmljdGlvblR5cGU9U0lNUExFX0xBQkVMLCBMYWJlbCA9IFRTIDoxNiwxMiw4
LDQgKGNhbiB3ZSBiZSBzdXJlIG9mIHRoZSBpbnRlcnByZXRhdGlvbiA/KQ0KDQogICAgIC0gUG9y
dCBMYWJlbCByZXN0cmljdGlvbiA6IE1hdHJpeCAjMiwgUmVzdHJpY3Rpb25UeXBlPVNJTVBMRV9M
QUJFTCwgTGFiZWwgPSBUUyA6MTUsMTEsNywzDQoNCiAgICAgLSBQb3J0IExhYmVsIHJlc3RyaWN0
aW9uIDogTWF0cml4ICMzLCBSZXN0cmljdGlvblR5cGU9U0lNUExFX0xBQkVMLCBMYWJlbCA9IFRT
IDoxNCwxMCw2LDINCg0KICAgICAtIFBvcnQgTGFiZWwgcmVzdHJpY3Rpb24gOiBNYXRyaXggIzMs
IFJlc3RyaWN0aW9uVHlwZT1TSU1QTEVfTEFCRUwsIExhYmVsID0gVFMgOjEzLDA5LDUsMQ0KDQpJ
IGFtIG5vdCAxMDAlIHN1cmUgdGhhdCB3ZSBjYW4gYWx3YXlzIGludGVycHJldCB0aGUgbGFiZWwg
YXMgT0RVIGxhYmVsLCBSRkM0MjAyIHNlY3Rpb24gMi40Ljcgb24gaG93IHRvIGludGVycHJldCB0
aGUNCg0KTGFiZWwgb24gYSBURS1MaW5rIHdvdWxkIGluZGljYXRlIHRoYXQgaWYgb25lIGVuZCBz
dXBwb3J0IFRETSBhbmQgdGhlIG90aGVyIExTQywgdGhlIGxhYmVsIHNob3VsZCByZXByZXNlbnQg
YSBsYW1iZGEsIA0KDQpidXQgdGhlIGNhc2Ugd2hlcmUgdGhlcmUgaXMgc2V2ZXJhbCBJU0NEIGlz
IG5vdCB3ZWxsIGRlc2NyaWJlZC4NCg0KIA0KDQpUaGUgZHJhZnQgc2hvdWxkIGRldGFpbCB0aGUg
cnVsZXMgb24gd2hpY2ggbGFiZWwgZW5jb2RpbmcgdG8gdXNlIGluIGNhc2Ugb2YgY29ubmVjdGl2
aXR5IG1hdHJpeCBpbiB0aGF0IGNhc2UuDQoNCiANCg0KSW4gdGhhdCBleGFtcGxlIHdlIGhhdmUg
Zml4ZWQgTVVYIE9EVTMtPk9EVTIgQU5EIGVhY2ggT0RVMiBpcyBhc3NpZ25lZCB0byBhbiBwb3J0
OiB0aGUgcG9ydCBsYWJlbCByZXN0cmljdGlvbiBpcyB1c2VkLCANCg0KUnVsZXMgZm9yIHBvcnQg
bGFiZWwgcmVzdHJpY3Rpb24gc2hvdWxkIGFsbG93IHRvIGludGVycHJldCBjb3JyZWN0bHkgdGhl
IGxhYmVsLg0KDQogDQoNCkhvd2V2ZXIgb24gY2FzZSBvZiBGaXhlcyBNVVggYW5kIGZsZXhpYmxl
IE9EVTIgdG8gcG9ydCBhc3NpZ25tZW50IG9uZSBhbGxvd2VkIHBvc3NpYmlsaXR5IGlzIHRoZSBm
b2xsb3dpbmcgOiANCg0KTWF0cml4ICMxMSAoe1BvcnQgMSwgUG9ydCAyLCBQb3J0IDMsIFBvcnQg
NCx9LCB7UG9ydCA1fSkNCg0KIA0KDQpURS1MaW5rIDUgKHBvcnQgMikgOiANCg0KICAgICAtIElT
Q0QgIzEgc3ViLVRMVjogRFdETSANCg0KICAgICAtIElTQ0QgIzIgc3ViLVRMVjogVERNLCBHLjcw
OSBPRFVrIChPRFUzKSANCg0KICAgIC0gQXZhaWxhYmxlICBMYWJlbHMgOiDCqyBUUyA6MTUsMTEs
NywzIMK7LCDCqyBUUyA6MTQsMTAsNiwyIMK7LCDCqyBUUyA6MTMsMDksNSwxIMK7LCDCqyBUUyA6
MTYsMTIsOCw04oCdDQoNCiAgICAgLSBBdmFpbGFibGUgIExhYmVscyA6IGNoYW5uZWxzIChEV0RN
KSANCg0KIA0KDQpIb3cgdG8gbWFrZSBzdXJlIHRoZSBpbnRlcnByZXRhdGlvbiBpcyBjb3JyZWN0
LCBUaGlzIGlzIGFuIHR5cGljYWwgY2FzZSBjb3ZlcmVkIGJ5IHRoZSBnZW5lcmljIEdNUExTIFJG
Q3MsIHNvIA0KDQogSXQgc2hvdWxkICBiZSBjb3ZlcmVkIGluIG15IG9waW5pb24gYnkgdGhlIGdl
bmVyaWMgZXh0ZW5zaW9ucy4NCg0KIA0KDQogDQoNCiANCg0KIA0KDQogDQoNCkZyb206IGV4dCBa
aGFuZ2ZhdGFpIFttYWlsdG86emhhbmdmYXRhaUBodWF3ZWkuY29tXSANClNlbnQ6IFRodXJzZGF5
LCBTZXB0ZW1iZXIgMjksIDIwMTEgMTI6MTkgUE0NClRvOiBNYXJnYXJpYSwgQ3lyaWwgKE5TTiAt
IERFL011bmljaCk7IGNjYW1wQGlldGYub3JnDQpTdWJqZWN0OiDnrZTlpI06IOetlOWkjTog562U
5aSNOiBbQ0NBTVBdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC1j
b25zdHJhaW50cy1vc3BmLXRlLTAyLnR4dA0KDQogDQoNCkhpIEN5cmlsLA0KDQogDQoNClVzdWFs
bHksIG9uZSBURSBsaW5rIGFkdmVydGlzZW1lbnQgKHdpdGggc2VydmVyYWwgSVNDRHMgYW5kIG11
bHRpcGxlIGxhYmVsIHN1Yi1UTFZzKSBoYXMgdGhlIHNhbWUgU3dpdGNoaW5nIENhcGFiaWxpdHks
IHNvIHRoZXJlIGlzIGltcGxpY2l0IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRoZSBJU0NEcyBhbmQg
bGFiZWwgc3ViLVRMVnMuDQoNCiANCg0KSSB3b3VsZCBsaWtlIHRvIGNvbnNpZGVyIHlvdXIgbGFz
dCBwb2ludCB3aGVuIEkgdWRwYXRlIHRoaXMgZHJhZnQgaW4gdGhlIG5leHQgdmVyc2lvbi4gDQoN
CiANCg0KQnV0IEkgaGF2ZSBhIHF1ZXN0aW9uIG9uIHlvdXIgZXhhbXBsZSwgZG8geW91IHNlZSB0
aGF0IHRoZXJlIGlzIGEgbGluZSBwb3J0IChvciBpbnRlcmZhY2UpIGNhbiBzdXBwb3J0IGJvdGgg
RFdETSBhbmQgVERNIGluIHRoZSB3b3JsZD8gSSB0aGluayBpZiBhIGxpbmUgcG9ydCBjYW4gc3Vw
cG9ydCBEV0RNLCB0aGUgV1NPTiBURSBsaW5rICh3aXRoIFdTT04gcmVsYXRlZCBsYWJlbCAod2F2
ZWxlbmd0aCkgaW5mb3JtYXRpb24pIHNob3VsZCBiZSBhZHZlcnRpc2VkIGZvciB0aGlzIGxpbmUg
cG9ydDsgaWYgYSBsaW5lIHBvcnQgY2FuIHN1cHBvcnQgVERNLCB0aGVuIHRoZSBURE0gVEUgbGlu
ayAoZS5nLiwgT0RVKSBmb3IgdGhpcyBsaW5lIHBvcnQgc2hvdWxkIGJlIGFkdmVydGlzZWQuIEV2
ZW4gdGhvdWdoIHRoZXJlIHdhcyBvbmUgcG9ydCBjb3VsZCBzdXBwb3J0IGJvdGggRFdETSBhbmQg
VERNLCBJIHRoaW5rIHVzdWFsbHkgaXQgc2hvdWxkIGFkdmVydGlzZSB0aGVzZSB0d28gdHlwZXMg
b2YgY2FwYWJpbGl0eSBzZXBhcmF0ZWx5LCBpZS4sIHVzZSBzZXBlcmF0ZSBURSBsaW5rIGFkdmVy
dGlzZW1lbnRzLiBzbywgSSB0aGluayB0aGVyZSBpcyBpbXBsaWNpdCByZWxhdGlvbnNoaXAgYmV0
d2VlbiB0aGUgSVNDRHMgYW5kIGxhYmVsIHN1Yi1UTFZzLg0KDQogDQoNCkV2ZW4gdGhvdWdoIEkg
dGhpbmsgd2Ugc2hvdWxkIG5vdCB1c2UgYSBraW5kIG9mIHNwZWNpYWwgYW5kIGNvbXBsZXggZXhh
bXBsZSB0byBleHBsYWluIHNvbWV0aGluZywgSSB3aWxsIGJlYXIgeW91ciBleGFtcGxlIGluIG15
IG1pbmQgd2hlbiBJIHVwZGF0ZSB0aGUgZHJhZnQgKGFzIEkgc2FpZCBpbiB0aGUgc2Vjb25kIHNl
bnRlbmNlIGFib3ZlKS4NCg0KIA0KDQpUaGFua3MNCg0KIA0KDQpGYXRhaQ0KDQogDQoNCiANCg0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0K5Y+R5Lu25Lq6OiBNYXJnYXJpYSwg
Q3lyaWwgKE5TTiAtIERFL011bmljaCkgW2N5cmlsLm1hcmdhcmlhQG5zbi5jb21dDQrlj5HpgIHm
l7bpl7Q6IDIwMTHlubQ55pyIMjnml6UgMTc6MzYNCuWIsDogWmhhbmdmYXRhaTsgY2NhbXBAaWV0
Zi5vcmcNCuS4u+mimDogUkU6IOetlOWkjTog562U5aSNOiBbQ0NBTVBdIEktRCBBY3Rpb246IGRy
YWZ0LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC1jb25zdHJhaW50cy1vc3BmLXRlLTAyLnR4dA0K
DQpIaSwgDQoNCiANCg0KSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgeW91IHN0YXRlIHRoYXQg
dGhlcmUgaXMgbm90IGV4cGxpY2l0IG9yIGltcGxpY2l0IHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHRo
ZSBJU0NEIGFuZCBsYWJlbCBzdWItVExWLCBjb3JyZWN0Pw0KDQpJIHdvdWxkIGV4cGVjdCBhIG5l
dyBnZW5lcmljIGRyYWZ0IHRvIGJlIGFwcGxpY2FibGUgdG8gYWxsIGFscmVhZHkgZGVmaW5lZCBs
YWJlbCBmb3JtYXQsIHNvICBpdCBzZWVtcyBtaXNzaW5nIGluIHRoZSBkb2N1bWVudC4NCg0KIA0K
DQpDb3VsZCB5b3UgY29uc2lkZXIgbXkgbGFzdCBwb2ludCByZWdhcmRpbmcgdGhlIGV4YW1wbGUg
b2Ygc3dpdGNoaW5nIHJlc3RyaWN0aW9uIGluIEcuNzA5IHYyIGFuZCBEV0RNIGNvbnRleHQsIGl0
IHdvdWxkIGJlIGhlbHBmdWwgDQoNCiB0byBoYXZlIHNvbWUgc3RhdGVtZW50IGV2ZW4gdGhvdWdo
IGl0IHdpbGwgbm90IGJlIGluIHRoZSBkb2N1bWVudC4NCg0KIA0KDQpCZXN0IFJlZ2FyZHMuDQoN
CiANCg0KIA0KDQpGcm9tOiBleHQgWmhhbmdmYXRhaSBbbWFpbHRvOnpoYW5nZmF0YWlAaHVhd2Vp
LmNvbV0gDQpTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAyOCwgMjAxMSA0OjMwIEFNDQpUbzog
TWFyZ2FyaWEsIEN5cmlsIChOU04gLSBERS9NdW5pY2gpOyBjY2FtcEBpZXRmLm9yZw0KU3ViamVj
dDog562U5aSNOiDnrZTlpI06IFtDQ0FNUF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jY2FtcC1n
bXBscy1nZW5lcmFsLWNvbnN0cmFpbnRzLW9zcGYtdGUtMDIudHh0DQoNCiANCg0KSGkgQ3lyaWws
DQoNCiANCg0KSSBhZ3JlZSBvbiB5b3VyIGZpcnN0IHN1Z2dlc3Rpb24uDQoNCiANCg0KU2Vjb25k
bHksIHRoaXMgZHJhZnQgaXMgZ2VuZXJpYywgd2hlbiBpdCBuZWVkcyB0byBhZHZlcnRpc2UgbGFi
ZWwgaW5mb3JtYXRpb24gZm9yIHNvbWUgc3BlY2lmaWMgdGVjaCAoZS5nLiwgVERNKSwgdGhlIGRv
Y3VtZW50IGFib3V0IHNwZWNpZmljIHRlY2ggY2FuIHJlZmVyIHRvIHRoaXMgZHJhZnQgYW5kIHNo
b3VsZCBkZWZpbmUgaG93IHRvIGNvcnJlbGF0ZSB0aGUgSVNDRHMgYW5kIGxhYmVsIHN1Yi1UTFZz
IGlmIHRoZXJlIGlzIG5vIGV4cGxpY2l0IG9yIGltcGxpY2l0IHJlbGF0aW9uc2hpcCBiZXR3ZWVu
IHRoZW0gKEkgdGhpbmsgdGhlcmUgYXJlIGxvdHMgb2YgcG90ZW50aWFsIHNvbHV0aW9ucyB0byBo
YW5kbGUgdGhhdCwgaXQgaXMgcXVpdGUgdGVjaCBzcGVjaWZpYyBzdHVmZikuIA0KDQogDQoNCiAN
Cg0KRmF0YWkNCg0KIA0KDQpUaGFua3MNCg0KIA0KDQogDQoNCl9fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fDQoNCuWPkeS7tuS6ujogTWFyZ2FyaWEsIEN5cmlsIChOU04gLSBERS9NdW5p
Y2gpIFtjeXJpbC5tYXJnYXJpYUBuc24uY29tXQ0K5Y+R6YCB5pe26Ze0OiAyMDEx5bm0OeaciDI3
5pelIDE3OjM4DQrliLA6IFpoYW5nZmF0YWk7IGNjYW1wQGlldGYub3JnDQrkuLvpopg6IFJFOiDn
rZTlpI06IFtDQ0FNUF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFs
LWNvbnN0cmFpbnRzLW9zcGYtdGUtMDIudHh0DQoNCkhpLCANCg0KIA0KDQpUaGFua3MgZm9yIHRo
ZSBhbnN3ZXIsIA0KDQogDQoNClBsZWFzZSBzZWUgaW5saW5lDQoNCiANCg0KIA0KDQpGcm9tOiBl
eHQgWmhhbmdmYXRhaSBbbWFpbHRvOnpoYW5nZmF0YWlAaHVhd2VpLmNvbV0gDQpTZW50OiBUdWVz
ZGF5LCBTZXB0ZW1iZXIgMjcsIDIwMTEgMTE6MTcgQU0NClRvOiBNYXJnYXJpYSwgQ3lyaWwgKE5T
TiAtIERFL011bmljaCk7IGNjYW1wQGlldGYub3JnDQpTdWJqZWN0OiDnrZTlpI06IFtDQ0FNUF0g
SS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLWNvbnN0cmFpbnRzLW9z
cGYtdGUtMDIudHh0DQoNCiANCg0KSGkgQ3lyaWwsDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZXRz
Lg0KDQpQbGVhc2Ugc2VlIGluLWxpbmUgYmVsb3cuDQoNCg0KRmF0YWkNCg0KVGhhbmtzDQoNCg0K
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQrlj5Hku7bkuro6IE1h
cmdhcmlhLCBDeXJpbCAoTlNOIC0gREUvTXVuaWNoKSBbY3lyaWwubWFyZ2FyaWFAbnNuLmNvbV0N
CuWPkemAgeaXtumXtDogMjAxMeW5tDnmnIgyNuaXpSAxNjowMw0K5YiwOiBaaGFuZ2ZhdGFpOyBj
Y2FtcEBpZXRmLm9yZw0K5Li76aKYOiBSRTogW0NDQU1QXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRm
LWNjYW1wLWdtcGxzLWdlbmVyYWwtY29uc3RyYWludHMtb3NwZi10ZS0wMi50eHQNCg0KSGksDQoN
CkkgaGF2ZSB0aGUgZm9sbG93aW5nIGNvbW1lbnRzL3F1ZXN0aW9uIHJlZ2FyZGluZyB0aGlzIHJl
dmlzaW9uDQoNCjMuMi4gQXZhaWxhYmxlIExhYmVsczoNCg0KVGhlIHRleHQgc3RhdGUgOiDigJxU
aGUgQXZhaWxhYmxlIExhYmVscyBzdWItVExWICAgbWF5IG9jY3VyIGF0IG1vc3Qgb25jZSB3aXRo
aW4gdGhlIGxpbmsgVExWLuKAnQ0KDQpIb3cgdG8gZW5jb2RlIGRpZmZlcmVudCBsYWJlbCBmb3Jt
YXQgaW4gdGhhdCBjYXNlPyBJIHRoaW5rIHRoZSBsYWJlbCBmb3JtYXQgd291bGQgZGVwZW5kDQpv
biB0aGUgSVNDRCwgYW5kIGFzIHdlIG1pZ2h0IGhhdmUgc2V2ZXJhbCBJU0NELCBoYXZpbmcgc2V2
ZXJhbCBBdmFpbGFibGUgTGFiZWwgc3ViLVRMViBtYWtlIHNlbnNlLg0KVGhpcyBhbHNvIGFwcGx5
IHRvIDMuMy4gU2hhcmVkIEJhY2t1cCBMYWJlbHMuDQoNCltGYXRhaV0gVGhpcyAibWF5IiBzaG91
bGQgYmUgIk1BWSIgYWNjb3JkaW5nIHRvIExvdSdzIHN1Z2dlc3Rpb24sIHNvIGl0IGRvZXMgbm90
IHByZXZlbnQgeW91IHRvIGhhdmUgc2V2ZXJhbCBhdmFpbGFibGUgbGFiZWwgc3ViLVRMVnMuIA0K
DQpbQ3lyaWxdIFN0YXRpbmcg4oCcVGhlIEF2YWlsYWJsZSBMYWJlbHMgc3ViLVRMViAgIE1BWSAg
b2NjdXIgbW9yZSB0aGFuIG9uY2Ugd2l0aGluIHRoZSBsaW5rIFRMVi7igJ0gIFdvdWxkIGJlIG1v
cmUgYWNjdXJhdGUgYW5kIGVhc2llciB0byB1bmRlcnN0YW5kLg0KDQogDQoNCg0KSW4gY2FzZSBv
ZiBzZXZlcmFsIElTQ0QgYXJlIHByZXNlbnQgZm9yIGEgZ2l2ZW4gYWR2ZXJ0aXNlbWVudCBob3cg
dG8gaW50ZXJwcmV0IHRoZSBsYWJlbCBmb3JtYXQgaW4gdGhlDQpsYWJlbC1yZWxhdGVkIHN1Yi1U
TFZzPw0KDQoNCltGYXRhaV0gSXQgaXMgZWFzeSB0byBhY2hpdmUgdGhhdC4gZS5nLCBpbiBTREgg
bmV0d29yaywgYSBub2RlIGNhbiBhZHZlcnRpc2Ugc2V2ZXJhbCBJU0NEcyB3aXRoIG9uZSBvciBt
dWx0aXBsZSBsYWJlbCBzdWItVExWcyAoSSBhc3N1bWUgIklGIiBsYWJlbCBpbmZvcm1hdGlvbiBp
cyBuZWVkZWQgdG8gYmUgYWR2ZXJ0aXNlZCBoZXJlKSwgd2h5IGl0IGNhbm5vdCBpbnRlcnByZXQg
dGhlIGxhYmVscyBhcmUgU0RIIGxhYmVscz8NCg0KW0N5cmlsXSAgSWYgdGhlcmUgaXMgMiBJU0NE
IHN1Yi1UTFYgYW5kIDIgYXZhaWxhYmxlIGxhYmVsIHN1Yi1UTFYsIGhvdyB0byB0ZWxsIHdoaWNo
IGF2YWlsYWJsZSBsYWJlbCBzdWItVExWIHJlbGF0ZSB0byB3aGljaCBJU0NEIHN1Yi1UTFY/DQoN
CiANCg0KDQpDb3VsZCB5b3UgY2xhcmlmeSB0aGlzIHBvaW50LCBpdCB3b3VsZCBiZSB1c2VmdWwg
Zm9yIGluc3RhbmNlIHRvIGNvbnNpZGVyIHRoZSBleGFtcGxlIG9mIGEgbGluayBzdXBwb3J0aW5n
IFNESA0KKG5vIFZDNC1zd2l0Y2hpbmcpLCBPRFUgKEcuNzA5LCBhcyBvZiBSRkM0MzI4LCBhbmQg
Zm9yIHRoZSBjdXJyZW50IEcuNzA5IHYzIGxhYmVsIGZvcm1hdCkuDQoNCiANCg0KW0ZhdGFpXSAg
RG8geW91IG1lYW4gdG8gaGF2ZSBhbiBleGFtcGxlIG9uIGh5YnJpZCBub2RlPyBJIHdpbGwgbm90
IHVzZSBhIGNvbXBsZXggZXhhbXBsZSB0byBleHBsYWluIGEga2luZCBvZiBzaW1wbGUgdGhpbmcg
KEl0IHdpbGwgY29uZnVzZSBwZW9wbGUpLiANCg0KW0N5cmlsXSBJdCBtYXkgbm90IGJlIHNvIHNp
bXBsZSwgSSBoYXZlIHRyb3VibGUgdG8gaW50ZXJwcmV0IGxhYmVsIHdpdGhvdXQga25vd2luZyB0
aGUgSVNDRCBjb25zaWRlcmVkIGFuZCBJIGRvIG5vdCBzZWUgY2xlYXJseSB0aGUgcmVsYXRpb24g
YmV0d2VlbiB0aGUgdHdvIGluIHRoZSBkb2N1bWVudC4NCg0KDQpUaGUgdGV4dCBpcyB2ZXJ5IGZv
Y3VzZWQgb24gV1NPTiwgd2hpbGUgaXQgaXMgYSB2ZXJ5IGludGVyZXN0aW5nIGV4YW1wbGUsIGhh
dmluZyBvdGhlciB0ZWNobm9sb2d5IChPVE4gZm9yDQpleGFtcGxlIHdvdWxkIGhlbHAgdG8gc2hv
dyB0aGF0IHRoZSBzb2x1dGlvbiBpcyBnZW5lcmljLg0KDQpbRmF0YWldIEkgdGhpbmsgb25lIHR5
cGljYWwgZXhhbXBsZSBpcyBzdWZmaWNpZW50IGZvciBwZW9wbGUgdG8gdW5kZXJzdGFuZCB0aGlu
Z3MuIFRETSBuZXR3b3JrIGlzIGRpZmZlcmVudCBmcm9tIFdTT04gbmV0d29yay4gSW4gVERNIG5l
dHdvcmssIHVzdWFsbHkgaXQgd2lsbCBub3QgYWR2ZXJ0aXNlIGxhYmVsIGluZm9ybWF0aW9uIGV2
ZW4gdGhvdWdoIGxhYmVsIGluZm9ybWF0aW9uIGNvdWxkIGJlIGFkdmVydGlzZWQuDQoNCltDeXJp
bF0gVGhleSBhcmUgaW5kZWVkIGRpZmZlcmVudCwgYnV0IGZyb20gbGFiZWwgcG9pbnQgb2Ygdmll
dyBpdCBzaG91bGQgbm90IG1ha2UgYSBkaWZmZXJlbmNlLiBBIHVzdWFsIHVzZSBjYXNlIG9mIGNv
bm5lY3Rpdml0eSBtYXRyaXggd291bGQgYmUgZm9yIGV4YW1wbGUgb24gY2xpZW50IGNhcmRzIHdp
dGggc3dpdGNoaW5nIHJlc3RyaWN0aW9uIDogZml4ZWQgTXVsdGlwbGV4IGFuZCBsYWJlbCBhc3Np
Z25tZW50IGR1ZSB0byB0aGUgZml4ZWQgTVVYIChPRFUyLT5PRFUxIGZvciBpbnN0YW5jZSkgIG9u
IERXRE0gbm9kZSA6DQoNCnRoZSByZXN0cmljdGlvbiBjYW4gYmUgbW9kZWxlZCBhcyBvbmUgY29u
bmVjdGl2aXR5IG1hdHJpeCBwZXIgY2xpZW50IHBvcnQsDQoNCiAgICAgICAgdGhlIGNsaWVudCBw
b3J0IGhhdmUgdGhlbiBJU0NEIFRETSwgDQoNCiAgICAgICAgdGhlIG90aGVyIHBvcnRzIGNhbiBk
byBEV0RNIGFuZCBURE0sIA0KDQogICAgICAgIGZvciB0aGUgY29ubmVjdGl2aXR5IG1hdHJpeCBj
b3JyZXNwb25kaW5nIHRvIGEgY2xpZW50IHBvcnQgdGhlIG9ubHkgT0RVIGxhYmVsIHRvIGJlIGFz
c2lnbmVkIChkdWUgdG8gZml4ZWQgTVVYKSBpcyBzcGVjaWZpZWQgDQoNCiANCg0KRmlyc3QsIGlz
IHRoaXMgbW9kZWxpbmcgY29ycmVjdD8gDQoNClNlY29uZCwgaG93IHRvIG1ha2Ugc3VyZSB0aGUg
bGFiZWwgcmVzdHJpY3Rpb24gYXJlIHRvIGJlIGludGVycHJldGVkIGFzIE9EVSBsYWJlbHM/DQoN
CiANCg0KSSB0aGluayBpdCBpcyBhbHNvIGltcG9ydGFudCB0byBzaG93IHRoYXQgdGhlIGV4dGVu
c2lvbnMgYXJlIGFsc28gd29ya2luZyBvdXRzaWRlIHRoZSBmcmFtZXdvcmsgdGhleSB3ZXJlIGJv
cm4gKFdTT04pLg0KDQogDQoNCkJSDQoNCg0KDQpCZXN0IFJlZ2FyZHMsDQpDeXJpbA0KDQo+IC0t
LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IGNjYW1wLWJvdW5jZXNAaWV0Zi5vcmcg
W21haWx0bzpjY2FtcC1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYNCj4gT2YgZXh0IFpoYW5n
ZmF0YWkNCj4gU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAyMiwgMjAxMSAxMToxNyBBTQ0KPiBU
bzogY2NhbXBAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtDQ0FNUF0gSS1EIEFjdGlvbjogZHJh
ZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLQ0KPiBjb25zdHJhaW50cy1vc3BmLXRlLTAyLnR4
dA0KPg0KPiBIaSBDQ0FNUGVycywNCj4NCj4gQSBuZXcgdmVyc2lvbiBoYXMgYmVlbiBzdWJtaXR0
ZWQgdG8gYWRkcmVzcyB0aGUgY29tbWVudHMgZnJvbSB0aGUgV0cNCj4gZGlzY3Vzc2lvbi4NCj4N
Cj4gV2UgYWNjZXB0ZWQgQWNlZSBhbmQgWW91bmcncyBzdWdnZXN0aW9uIHRvIGludHJvZHVjZSBh
IG5ldyB0b3AtbGV2ZWwNCj4gbm9kZSBUTFYgKEdlbmVyaWMgTm9kZSBBdHRyaWJ1dGUgVExWKSB0
byBzaW1wbGlmeSB0aGluZ3MgYW5kIGEgbmV3DQo+IHNlY3Rpb24gKFNlY3Rpb24gNSkgd2FzIGFk
ZGVkIHRvIGRlc2NyaWJlIHNjYWxhYmlsaXR5IGlzc3VlLg0KPg0KPiBNb3JlIGluZm9ybWF0aW9u
IGZyb206IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy0NCj4g
Z2VuZXJhbC1jb25zdHJhaW50cy1vc3BmLXRlLTAyLnR4dA0KPg0KPiBQbGVhc2UgY2hlY2sgb3V0
IGZvciBkZXRhaWxzIGFuZCBjb21tZW50cyBhcmUgYWx3YXlzIHdlbGNvbWUuDQo+DQo+DQo+IFRo
YW5rcw0KPg0KPiBGYXRhaQ0KPg0KPg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG
cm9tOiBjY2FtcC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Y2NhbXAtYm91bmNlc0BpZXRmLm9y
Z10gT24gQmVoYWxmDQo+IE9mIGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KPiBTZW50OiAyMDEx
5bm0OeaciDIy5pelIDE3OjA2DQo+IFRvOiBpLWQtYW5ub3VuY2VAaWV0Zi5vcmcNCj4gQ2M6IGNj
YW1wQGlldGYub3JnDQo+IFN1YmplY3Q6IFtDQ0FNUF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1j
Y2FtcC1nbXBscy1nZW5lcmFsLQ0KPiBjb25zdHJhaW50cy1vc3BmLXRlLTAyLnR4dA0KPg0KPiBB
IE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5l
dC1EcmFmdHMNCj4gZGlyZWN0b3JpZXMuIFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhl
IENvbW1vbiBDb250cm9sIGFuZA0KPiBNZWFzdXJlbWVudCBQbGFuZSBXb3JraW5nIEdyb3VwIG9m
IHRoZSBJRVRGLg0KPg0KPiAgICAgICBUaXRsZSAgICAgICAgICAgOiBPU1BGLVRFIEV4dGVuc2lv
bnMgZm9yIEdlbmVyYWwgTmV0d29yayBFbGVtZW50DQo+IENvbnN0cmFpbnRzDQo+ICAgICAgIEF1
dGhvcihzKSAgICAgICA6IEZhdGFpIFpoYW5nDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAg
WW91bmcgTGVlDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgSmlhbnJ1aSBIYW4NCj4gICAg
ICAgICAgICAgICAgICAgICAgICAgICBHcmVnIEJlcm5zdGVpbg0KPiAgICAgICAgICAgICAgICAg
ICAgICAgICAgIFl1bmJpbiBYdQ0KPiAgICAgICBGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRm
LWNjYW1wLWdtcGxzLWdlbmVyYWwtY29uc3RyYWludHMtDQo+IG9zcGYtdGUtMDIudHh0DQo+ICAg
ICAgIFBhZ2VzICAgICAgICAgICA6IDE0DQo+ICAgICAgIERhdGUgICAgICAgICAgICA6IDIwMTEt
MDktMjINCj4NCj4gICAgR2VuZXJhbGl6ZWQgTXVsdGlwcm90b2NvbCBMYWJlbCBTd2l0Y2hpbmcg
Y2FuIGJlIHVzZWQgdG8gY29udHJvbCBhDQo+ICAgIHdpZGUgdmFyaWV0eSBvZiB0ZWNobm9sb2dp
ZXMgaW5jbHVkaW5nIHBhY2tldCBzd2l0Y2hpbmcgKGUuZy4sDQo+IE1QTFMpLA0KPiAgICB0aW1l
LWRpdmlzaW9uIChlLmcuLCBTT05FVC9TREgsIE9UTiksIHdhdmVsZW5ndGggKGxhbWJkYXMpLCBh
bmQNCj4gICAgc3BhdGlhbCBzd2l0Y2hpbmcgKGUuZy4sIGluY29taW5nIHBvcnQgb3IgZmliZXIg
dG8gb3V0Z29pbmcgcG9ydCBvcg0KPiAgICBmaWJlcikuIEluIHNvbWUgb2YgdGhlc2UgdGVjaG5v
bG9naWVzIG5ldHdvcmsgZWxlbWVudHMgYW5kIGxpbmtzIG1heQ0KPiAgICBpbXBvc2UgYWRkaXRp
b25hbCByb3V0aW5nIGNvbnN0cmFpbnRzIHN1Y2ggYXMgYXN5bW1ldHJpYyBzd2l0Y2gNCj4gICAg
Y29ubmVjdGl2aXR5LCBub24tbG9jYWwgbGFiZWwgYXNzaWdubWVudCwgYW5kIGxhYmVsIHJhbmdl
DQo+IGxpbWl0YXRpb25zDQo+ICAgIG9uIGxpbmtzLiBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBP
U1BGIHJvdXRpbmcgcHJvdG9jb2wgZXh0ZW5zaW9ucw0KPiB0bw0KPiAgICBzdXBwb3J0IHRoZXNl
IGtpbmRzIG9mIGNvbnN0cmFpbnRzIHVuZGVyIHRoZSBjb250cm9sIG9mIEdlbmVyYWxpemVkDQo+
ICAgIE1QTFMgKEdNUExTKS4NCj4NCj4NCj4NCj4gQSBVUkwgZm9yIHRoaXMgSW50ZXJuZXQtRHJh
ZnQgaXM6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYt
Y2NhbXAtZ21wbHMtZ2VuZXJhbC0NCj4gY29uc3RyYWludHMtb3NwZi10ZS0wMi50eHQNCj4NCj4g
SW50ZXJuZXQtRHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Og0K
PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPg0KPiBUaGlzIEludGVybmV0
LURyYWZ0IGNhbiBiZSByZXRyaWV2ZWQgYXQ6DQo+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5l
dC1kcmFmdHMvZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFsLQ0KPiBjb25zdHJhaW50cy1v
c3BmLXRlLTAyLnR4dA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fXw0KPiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4gQ0NBTVBAaWV0Zi5vcmcNCj4gaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcA0KPiBfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBDQ0FNUCBtYWlsaW5nIGxpc3QNCj4g
Q0NBTVBAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9j
Y2FtcA0KDQo=

------_=_NextPart_001_01CC7F4D.5308DA1B
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o
dG1sNDAiPjxoZWFkPjxtZXRhIGh0dHAtZXF1aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQv
aHRtbDsgY2hhcnNldD11dGYtOCI+PG1ldGEgbmFtZT1HZW5lcmF0b3IgY29udGVudD0iTWljcm9z
b2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPjwhLS1baWYgIW1zb10+PHN0eWxlIGlkPW93
YVBhcmFTdHlsZT52XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQpvXDoqIHtiZWhh
dmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQp3XDoqIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1M
KTt9DQouc2hhcGUge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCjwvc3R5bGU+PCFbZW5k
aWZdLS0+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7
Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0K
QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEg
MSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiOw0KCXBhbm9z
ZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6TWlu
Z0xpVTsNCglwYW5vc2UtMToyIDIgMyA5IDAgMCAwIDAgMCAwO30NCkBmb250LWZhY2UNCgl7Zm9u
dC1mYW1pbHk6TWluZ0xpVTsNCglwYW5vc2UtMToyIDIgMyA5IDAgMCAwIDAgMCAwO30NCkBmb250
LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz
IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDEx
IDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdvdGhp
YyI7DQoJcGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250
LWZhbWlseToiTVMgVUkgR290aGljIjsNCglwYW5vc2UtMToyIDExIDYgMCA3IDIgNSA4IDIgNDt9
DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIFVJIEdvdGhpYyI7DQoJcGFub3NlLTE6
MiAxMSA2IDAgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBTaW1T
dW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250
LWZhbWlseToiXEBNaW5nTGlVIjsNCglwYW5vc2UtMToyIDIgMyA5IDAgMCAwIDAgMCAwO30NCi8q
IFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNv
Tm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6
ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6U2ltU3VuO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp
bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0
aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7
bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246
dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1hcmdpbjowY207DQoJ
bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6
IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5
Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNt
Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt
aWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdy
YXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFy
Z2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCglt
YXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox
Mi4wcHQ7DQoJZm9udC1mYW1pbHk6U2ltU3VuO30NCnAubXNvY2hwZGVmYXVsdCwgbGkubXNvY2hw
ZGVmYXVsdCwgZGl2Lm1zb2NocGRlZmF1bHQNCgl7bXNvLXN0eWxlLW5hbWU6bXNvY2hwZGVmYXVs
dDsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAu
MHB0Ow0KCWZvbnQtZmFtaWx5OlNpbVN1bjt9DQpzcGFuLmVtYWlsc3R5bGUxOA0KCXttc28tc3R5
bGUtbmFtZTplbWFpbHN0eWxlMTg7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm
IjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uZW1haWxzdHlsZTIwDQoJe21zby1zdHlsZS1uYW1l
OmVtYWlsc3R5bGUyMDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNv
bG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5lbWFpbHN0eWxlMjENCgl7bXNvLXN0eWxlLW5hbWU6ZW1haWxz
dHlsZTIxOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFG
NDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBs
eTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7
fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVm
b3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r
OiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQouTXNv
Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu
MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn
aW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn
ZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNv
LWxpc3QtaWQ6MTgwOTk3NzYzMTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10
ZW1wbGF0ZS1pZHM6LTEwNDk4Mjk3NDQgNjk4NjY4NTM0IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4
Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0
IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs
LXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv
c2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6NTQuMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7
DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28tZmFyZWFzdC1mb250
LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i
O30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ
bXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt
bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2luLWxlZnQ6OTAuMHB0Ow0KCXRleHQtaW5kZW50
Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpvbA0KCXttYXJnaW4tYm90
dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYg
Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i
MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86
c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi
IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+PC9oZWFkPjxib2R5IGxhbmc9
RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT48ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT48cCBj
bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SGksIDxv
OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0
OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu
IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp
ZiI7Y29sb3I6IzFGNDk3RCc+TXkgdW5kZXJzdGFuZGluZyBvZiB0aGUgaHlicmlkIG5vZGUgaXMg
dGhlIGZvbGxvd2luZyA6IHRoZSBwb3J0cyAjYiBhbmQgI2MgYXJlIFRETSBwb3J0cyAsIHBvcnQg
I2IgdGVybWluYXRlIHRoZSBWQzQgdHJhaWwgYW5kIHByb3ZpZGUgYSBQU0MgQWNjZXNzIHBvaW50
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjoj
MUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz
cGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z
ZXJpZiI7Y29sb3I6IzFGNDk3RCc+VGhlIGV4YW1wbGUgSSBzaG93biBpcyBhIG5vZGUgd2l0aCBh
IFBYQyAuIHBvcnQgI2UgaW4gVERNIGlzIGEgY29sb3JlZCBPVFUzIHBvcnQsIHNvIEkgd291bGQg
YmUgaW50ZXJlc3RlZCB0byBrbm93IHdoYXQgbWFrZXMgeW91IHRoaW5rIHRoZSBleGFtcGxlIGNo
b29zZW4gaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0
eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7
Y29sb3I6IzFGNDk3RCc+bm90IE9UTiBlcXVpcG1lbnQ/IFRoZSBwaHlzaWNhbCBsaW5rIGRvZXMg
bm90IHN1cHBvcnQgYm90aCBzd2l0Y2hpbmcsIGJ1dCB0aGUgR01QTFMgbGluayBpbnRlcmZhY2Ug
Y2FuLCBhcyBleHBsYWluZWQgaW4gUkZDNDM5NyBzZWN0aW9uIDMuNi4yLCB0aGlzIGNhbiBtaXgg
dGhlIHRyYWlsIHRlcm1pbmF0aW9uIGFuZCBhZGFwdGF0aW9uIGFuZCBzZXJ2ZXIgbGF5ZXIgY29u
bmVjdGlvbiBwb2ludCwgd2hpY2ggaXMgZXhhY3RseSB0aGUgY29uY2VwdCBpbGx1c3RyYXRlZCBp
biBSRkM1MzM5IGFuZCBteSBleGFtcGxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N
c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli
cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQt
ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+SSBjb3VsZCBhbHNv
IHRha2UgdGhlIEZpZ3VyZSAzIG9mIGRyYWZ0LWlldGYtY2NhbXAtcndhLWluZm8tMTIsIGludGVy
bmFsIHBvcnQgMSAyIDMgNCBvZiB0aGUgUk9BRE0gY2FuIGJlIGNvbm5lY3RlZCBpbnRlcm5hbCB0
byBhbiBPVFUzIC0mZ3Q7IE9EVTMgLSZndDsgT0RVMiAtJmd0OyBPVFUyIHBvcnRzLCA8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+
VXNpbmcgUkZDNjAwMSBpcyBwb3NzaWJsZSBidXQgbm90IG1hbmRhdG9yeSwgdGhlIG5ldyBzb2x1
dGlvbiBzaG91bGQgYWxzbyB3b3JrIHdpdGggYW5kIHdpdGhvdXQgc3VwcG9ydCBvZiBSRkM2MDAx
IChvciBtYW5kYXRlIHN1cHBvcnQgb2YgUkZDNjAwMSkgPG86cD48L286cD48L3NwYW4+PC9wPjxw
IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JIGFt
IHN0aWxsIG1pc3NpbmcgcnVsZXMgb24gaG93IHRvIGludGVycHJldCB0aGUgbGFiZWwgZm9ybWF0
IGluIHRoZSBleGFtcGxlcyBJIHByb3ZpZGVkLCBJdCB3b3VsZCBiZSBlcXVhbGx5IGludGVyZXN0
aW5nIHRvIGFkZCB0aGUgdGhpcmQgZXhhbXBsZSB5b3UgbWVudGlvbmVkICh3aXRoIElBQ0QpIDxv
OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0
OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu
IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp
ZiI7Y29sb3I6IzFGNDk3RCc+VGhlIGV4YW1wbGVzIEkgbWVudGlvbmVkIGNvbWUgZm9yIGV4aXN0
aW5nIG5vZGUgYXJjaGl0ZWN0dXJlIHdoZXJlIHRoZSBnZW5lcmFsIGNvbnN0cmFpbnRzIGFyZSB2
ZXJ5IHVzZWZ1bCwgYnV0IHNvbWUgcG9pbnRzIHN0aWxsIMKgcmVtYWlucyB0byBiZSBjbGFyaWZp
ZWQuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9y
OiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+
PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z
LXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGF0IHNhaWQsIHRoZXJlIGlzIHNldmVyYWwgcG90ZW50
aWFsIHNvbHV0aW9uIHRoYXQgY291bGQgYmUgY29uc2lkZXJlZCBhbmQgYmUgZ2VuZXJpYyA6IDxv
OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29MaXN0UGFyYWdyYXBoIHN0eWxlPSdtYXJn
aW4tbGVmdDo1NC4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZv
MSc+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48c3BhbiBzdHls
ZT0nbXNvLWxpc3Q6SWdub3JlJz4tPHNwYW4gc3R5bGU9J2ZvbnQ6Ny4wcHQgIlRpbWVzIE5ldyBS
b21hbiInPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyA8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdE
Jz5FeHBsaWNpdGx5IHNjb3BlIHRoZSBsYWJlbHMgYnkgaGF2aW5nIChzd2l0Y2hpbmcgdHlwZSwg
ZW5jb2RpbmcpIMKgZm9yIHBvcnQgbGFiZWwgcmVzdHJpY3Rpb24sIGF2YWlsYWJsZSBsYWJlbHMs
IHNoYXJlZCBsYWJlbHMsIGEgY29ycmVzcG9uZGluZyBJU0NEIG9yIElBQ0QgTVVTVCBiZSBwcmVz
ZW50PG86cD48L286cD48L3NwYW4+PC9wPjxwcmUgc3R5bGU9J21hcmdpbi1sZWZ0OjU0LjBwdDt0
ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xJz48IVtpZiAhc3VwcG9y
dExpc3RzXT48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+
PHNwYW4gc3R5bGU9J21zby1saXN0Oklnbm9yZSc+LTxzcGFuIHN0eWxlPSdmb250OjcuMHB0ICJU
aW1lcyBOZXcgUm9tYW4iJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvc3Bhbj48
L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+wqDCoMKgT25seSBhbGxvdyBv
bmUgSVNDRCAoSXQgd2lsbCBiZSBhIGJpZyByZXN0cmljdGlvbikgYW5kIGV4dGVuZCBJQUNEICht
YXliZSB1c2luZyBBZGp1c3RtZW50IENhcGFiaWxpdHktc3BlY2lmaWMgaW5mb3JtYXRpb24gKSA8
L3NwYW4+PG86cD48L286cD48L3ByZT48cHJlIHN0eWxlPSdtYXJnaW4tbGVmdDo1NC4wcHQ7dGV4
dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSc+PCFbaWYgIXN1cHBvcnRM
aXN0c10+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiInPjxz
cGFuIHN0eWxlPSdtc28tbGlzdDpJZ25vcmUnPi08c3BhbiBzdHlsZT0nZm9udDo3LjBwdCAiVGlt
ZXMgTmV3IFJvbWFuIic+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48L3NwYW4+PC9z
cGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi
Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPj88L3NwYW4+PG86cD48L286cD48
L3ByZT48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNw
OzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3
RCc+QlIgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls
ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv
bG9yOiMxRjQ5N0QnPkN5cmlsPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h
bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh
bnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBj
bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAx
LjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Jz48ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpu
b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g
MGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g
c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi
Jz4gZXh0IFpoYW5nZmF0YWkgW21haWx0bzp6aGFuZ2ZhdGFpQGh1YXdlaS5jb21dIDxicj48Yj5T
ZW50OjwvYj4gRnJpZGF5LCBTZXB0ZW1iZXIgMzAsIDIwMTEgNDo0NCBBTTxicj48Yj5Ubzo8L2I+
IE1hcmdhcmlhLCBDeXJpbCAoTlNOIC0gREUvTXVuaWNoKTsgY2NhbXBAaWV0Zi5vcmc8YnI+PGI+
U3ViamVjdDo8L2I+IDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseToiTVMgVUkgR290aGljIiwic2Fucy1zZXJpZiInPuetlDwvc3Bhbj48c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpNaW5nTGlVJz7lpI08L3NwYW4+PHNwYW4gc3R5
bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz46
IDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiTVMgVUkg
R290aGljIiwic2Fucy1zZXJpZiInPuetlDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseTpNaW5nTGlVJz7lpI08L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz46IDwvc3Bhbj48c3Bh
biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiTVMgVUkgR290aGljIiwic2Fu
cy1zZXJpZiInPuetlDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseTpNaW5nTGlVJz7lpI08L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz46IDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiTVMgVUkgR290aGljIiwic2Fucy1zZXJpZiInPuet
lDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpNaW5nTGlV
Jz7lpI08L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRh
aG9tYSIsInNhbnMtc2VyaWYiJz46IFtDQ0FNUF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jY2Ft
cC1nbXBscy1nZW5lcmFsLWNvbnN0cmFpbnRzLW9zcGYtdGUtMDIudHh0PG86cD48L286cD48L3Nw
YW4+PC9wPjwvZGl2PjwvZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwv
cD48ZGl2PjxwPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhv
bWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+SGkgQ3lyaWwsPG86cD48L286cD48L3NwYW4+
PC9wPjxwPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEi
LCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxw
PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z
LXNlcmlmIjtjb2xvcjpibGFjayc+SW50ZXJlc3RpbmcgZXhhbXBsZS4gVGhlIGhicmlkIGV4YW1w
bGUgaW4gUkZDNTMzOSBpcyBURE0rUFNDJm5ic3A7KHRoYXQgaXMgY29taW5nIHRvIHVzKSwmbmJz
cDtpbnN0ZWFkIG9mJm5ic3A7VERNK0RXRE0gKEkgdGhpbmsgeW91ciBleGFtcGxlIGlzIG5vdCBP
VE4gZXF1aXBtZW50KSwgOi0pPG86cD48L286cD48L3NwYW4+PC9wPjxwPjxzcGFuIHN0eWxlPSdm
b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpi
bGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxwPjxzcGFuIHN0eWxlPSdmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+
SW4geW91ciBleGFtcGxlLCBmb3IgdGhlIFRFIGxpbmsgNSwgaXQgd2lsbC9jb3VsZCBhZHZlcnRp
c2UmbmJzcDtXU09OIGxpbmtzICtJQUNEIGJhc2VkIG9uIFJGQzYwMDEoSW4gdGhpcyB3YXksIHRo
ZXJlIGlzIHN0aWxsIGltcGxpY2l0Jm5ic3A7cmVsYXRpb25zaGlwIGJldHdlZW4gSVNDRHMgYW5k
IGxhYmVsIHN1Yi1UTFZzKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHA+PHNwYW4gc3R5bGU9J2Zv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJs
YWNrJz5DZXJ0YWludGx5LCBJIHRoaW5rJm5ic3A7dGhlcmUgaXMgc3RpbGwgbG9mcyBvZiB3b3Jr
IHRvIGJlIGRvbmUgZm9yIE1MTiBjb250cm9sIGJlY2F1c2UgUkZDNjAwMSBpcyBub3Qgc3VmZmlj
aWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHA+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4mbmJzcDs8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHA+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5Bbnl3YXksIHlvdXIg
ZXhhbXBsZSBpcyBhcHByZWNpYXRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHA+PHNwYW4gc3R5
bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2Nv
bG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHA+PHNwYW4gc3R5bGU9J2Zv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJs
YWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHA+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5U
aGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHA+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4mbmJzcDs8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHA+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5GYXRhaTxvOnA+PC9v
OnA+PC9zcGFuPjwvcD48cD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls
eToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9z
cGFuPjwvcD48cD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFo
b21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv
cD48cD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwi
c2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2
PjxkaXYgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50
ZXInPjxzcGFuIHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO2Nv
bG9yOmJsYWNrJz48aHIgc2l6ZT0yIHdpZHRoPSIxMDAlIiBhbGlnbj1jZW50ZXI+PC9zcGFuPjwv
ZGl2PjxkaXYgaWQ9ZGl2UnBGODAxODExPjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2lu
LWJvdHRvbToxMi4wcHQnPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt
aWx5Ok1pbmdMaVU7Y29sb3I6YmxhY2snPuWPkeS7tuS6ujwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5
bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2Nv
bG9yOmJsYWNrJz46PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiBNYXJnYXJpYSwgQ3ly
aWwgKE5TTiAtIERFL011bmljaCkgW2N5cmlsLm1hcmdhcmlhQG5zbi5jb21dPGJyPjwvc3Bhbj48
Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpNaW5nTGlVO2NvbG9y
OmJsYWNrJz7lj5HpgIHml7bpl7Q8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+Ojwv
c3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9t
YSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4gMjAxMTwvc3Bhbj48c3BhbiBzdHlsZT0nZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiTVMgVUkgR290aGljIiwic2Fucy1zZXJpZiI7Y29s
b3I6YmxhY2snPuW5tDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjk8L3NwYW4+PHNwYW4gc3R5
bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6Ik1TIFVJIEdvdGhpYyIsInNhbnMtc2Vy
aWYiO2NvbG9yOmJsYWNrJz7mnIg8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4yOTwvc3Bhbj48
c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiTVMgVUkgR290aGljIiwi
c2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPuaXpTwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiAx
OTowNTxicj48L3NwYW4+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6Ik1TIFVJIEdvdGhpYyIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz7liLA8L3NwYW4+PC9i
PjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz
YW5zLXNlcmlmIjtjb2xvcjpibGFjayc+Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6
ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4g
WmhhbmdmYXRhaTsgY2NhbXBAaWV0Zi5vcmc8YnI+PC9zcGFuPjxiPjxzcGFuIHN0eWxlPSdmb250
LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJNUyBVSSBHb3RoaWMiLCJzYW5zLXNlcmlmIjtjb2xv
cjpibGFjayc+5Li7PC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTpNaW5nTGlVO2NvbG9yOmJsYWNrJz7popg8L3NwYW4+PC9iPjxiPjxzcGFuIHN0
eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtj
b2xvcjpibGFjayc+Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4gUkU6IDwvc3Bhbj48
c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiTVMgVUkgR290aGljIiwi
c2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPuetlDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseTpNaW5nTGlVO2NvbG9yOmJsYWNrJz7lpI08L3NwYW4+PHNwYW4g
c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi
O2NvbG9yOmJsYWNrJz46IDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseToiTVMgVUkgR290aGljIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPuetlDwvc3Bh
bj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpNaW5nTGlVO2NvbG9y
OmJsYWNrJz7lpI08L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p
bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz46IDwvc3Bhbj48c3BhbiBzdHls
ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiTVMgVUkgR290aGljIiwic2Fucy1zZXJp
ZiI7Y29sb3I6YmxhY2snPuetlDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm
b250LWZhbWlseTpNaW5nTGlVO2NvbG9yOmJsYWNrJz7lpI08L3NwYW4+PHNwYW4gc3R5bGU9J2Zv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJs
YWNrJz46IFtDQ0FNUF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5lcmFs
LWNvbnN0cmFpbnRzLW9zcGYtdGUtMDIudHh0PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LWZhbWls
eToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOiMxRjQ5N0QnPkhp
IEZhdGFpLCA8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7
PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOiMxRjQ5N0QnPkZv
ciBteSBleGFtcGxlIEkgdG9vayB0aGUgZXhhbXBsZSBmcm9tIFJGQzUzMzkgKGFsc28gZm9sbG93
aW5nIHRoZSBsb2dpYyBvZiBSRkM0MjAyIHNlY3Rpb24gMi40LjYpLCBhZGp1c3RpbmcgdGhlIGNh
cGFiaWxpdGllcyBhbmQgZXh0ZW5kZWQgdGhlIG51bWJlciBvZiBwb3J0czo8L3NwYW4+PHNwYW4g
c3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y
bWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w
PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseToiQ291cmllciBOZXciO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBOZXR3b3JrIGVsZW1lbnQ8L3NwYW4+PHNw
YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv
Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVy
IE5ldyI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4uLi4uPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48
L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl
OjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyA6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0tLS0tLS0tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IDo8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IFRETSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6Jm5i
c3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
O3wmbmJzcDsgVERNJm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
Ojwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48
cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjojMUY0OTdEJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUG9ydDEtLS0tLS0tLS0t
LS0tJmx0Oy0mZ3Q7LS0tfCNhJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOjwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn
PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1GUiBz
dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOiMx
RjQ5N0QnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyBQb3J0Mi0tLS0tLS0tLS0tLS0mbHQ7LSZndDstLS18I2ImbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6
PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxw
IGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUZSIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2Zv
bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBvcnQzLS0t
LS0tLS0tLS0tLSZsdDstJmd0Oy0tLXwjYyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDo8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9y
OmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxh
bmc9RlIgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtj
b2xvcjojMUY0OTdEJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUG9ydDQtLS0tLS0tLS0tLS0tJmx0Oy0mZ3Q7LS0tfCNk
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgOjwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFu
PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1GUiBzdHlsZT0nZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyA8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjojMUY0OTdEJz46Jm5ic3A7ICstLSZsdDstJmd0Oy0t
LXwjZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IDo8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IDombmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyAtLS0tLS0tLSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6
PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxw
IGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eToiQ291cmllciBOZXciO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6
Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLS0tLS0t
LS0tLSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6PC9zcGFuPjxzcGFuIHN0eWxlPSdj
b2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh
biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9y
OiMxRjQ5N0QnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBEV0RNJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7IDombmJzcDsgKy0tJmx0Oy0mZ3Q7LS18I2YmbmJzcDsgRFdETSZuYnNwOyB8Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDo8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6IzFGNDk3RCc+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IFBvcnQ1IC0tLS0tLS0tLS0tLSZsdDstJmd0Oy0tfCNnJm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOjwvc3Bh
bj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz
cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNv
dXJpZXIgTmV3Ijtjb2xvcjojMUY0OTdEJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAt
LS0tLS0tLS0tJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDo8L3NwYW4+PHNwYW4gc3R5
bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFs
PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7
Y29sb3I6IzFGNDk3RCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDouLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48
L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZu
YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9
J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjojMUY0OTdE
Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRmlndXJlIDFhLiZu
YnNwOyBIeWJyaWQgbm9kZS48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj
ayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz
dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOiMx
RjQ5N0QnPkZyb20gSVNDRCBwb2ludCBvZiB2aWV3Ojwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6
YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5
bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjojMUY0
OTdEJz5URSBsaW5rIDEgKFBvcnQxKTo8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6IzFGNDk3RCc+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gSVNDRCBzdWItVExWOiBURE0gJm5ic3A7KE9EVTIpIDwv
c3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj
bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
IkNvdXJpZXIgTmV3Ijtjb2xvcjojMUY0OTdEJz5URSBsaW5rIDIgKFBvcnQxKTo8L3NwYW4+PHNw
YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNv
Tm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVy
IE5ldyI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gSVNDRCBzdWIt
VExWOiBURE0gJm5ic3A7KE9EVTIpIDwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjojMUY0OTdEJz7igKY8
L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg
Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiJDb3VyaWVyIE5ldyI7Y29sb3I6IzFGNDk3RCc+VEUtTGluayA1IChwb3J0IDIpIDogPC9zcGFu
PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz
PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291
cmllciBOZXciO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy0g
SVNDRCAjMSBzdWItVExWOiBEV0RNIDwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjojMUY0OTdEJz4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstIElTQ0QgIzIgc3ViLVRMVjogVERNLCBHLjcwOSBP
RFVrIChPRFUzKSA8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5i
c3A7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOiMxRjQ5N0Qn
PlRoZSBJU0NEICMyIHJlcHJlc2VudCB0aGUgRFdETS1URE0gYWRqdXN0ZW1lbnQgY2FwYWJpbGl0
eTwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48
cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjojMUY0OTdEJz5JIGFtIGxlYXZpbmcgb3V0IGluIHRoaXMg
dGhyZWFkIGhvdyB0byBrbm93IHRoZSBPRU8gY2FwYWJpbGl0eSBvZiBwb3J0ICNmLyNlIDstKTwv
c3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj
bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+
Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls
ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOiMxRjQ5
N0QnPldpdGggdGhlIGZvbGxvd2luZyBjb25uZWN0aXZpdHkgbWF0cml4ICh3aXRoIHRoZSBmb2xs
b3dpbmcgY29udmVudGlvbiA6ICh7TGluayBTZXQgQSMxfSx7TGluayBzZXQgQiMxfSksKHtMaW5r
IFNldCBBIzJ9LHtMaW5rIHNldCBCIzJ9KSzigKY8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJs
YWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl
PSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v
cm1hbD48c3BhbiBsYW5nPUZSIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD
b3VyaWVyIE5ldyI7Y29sb3I6IzFGNDk3RCc+TWF0cml4ICMxICh7UG9ydCAxfSwge1BvcnQgNX0p
IDwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48
cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1GUiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOiMxRjQ5N0QnPk1hdHJpeCAjMiAoe1BvcnQg
Mn0sIHtQb3J0IDV9KTwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1GUiBzdHlsZT0nZm9udC1z
aXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOiMxRjQ5N0QnPk1hdHJp
eCAjMyAoe1BvcnQgM30sIHtQb3J0IDV9KTwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn
PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1GUiBz
dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOiMx
RjQ5N0QnPk1hdHJpeCAjNCAoe1BvcnQgNH0sIHtQb3J0IDV9KTwvc3Bhbj48c3BhbiBzdHlsZT0n
Y29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw
YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh
c3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RlIgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m
YW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjojMUY0OTdEJz5URS1MaW5rIDUgKHBvcnQgMikgOiA8
L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg
Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RlIgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjojMUY0OTdEJz4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDstIElTQ0QgIzEgc3ViLVRMVjogRFdETSA8L3NwYW4+PHNwYW4gc3R5bGU9J2Nv
bG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu
IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29sb3I6
IzFGNDk3RCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LSBJU0NEICMyIHN1Yi1UTFY6
IFRETSwgRy43MDkgT0RVayAoaGVyZSBPRFUzLCBiZWNhdXNlIG9mIHRoZSBwb3J0ICNlKTwvc3Bh
bj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz
cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNv
dXJpZXIgTmV3Ijtjb2xvcjojMUY0OTdEJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBQb3J0
IExhYmVsIHJlc3RyaWN0aW9uJm5ic3A7OiBNYXRyaXggIzEsIFJlc3RyaWN0aW9uVHlwZT1TSU1Q
TEVfTEFCRUwsIExhYmVsID0gVFMmbmJzcDs6MTYsMTIsOCw0IChjYW4gd2UgYmUgc3VyZSBvZiB0
aGUgaW50ZXJwcmV0YXRpb24mbmJzcDs/KTwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn
PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv
bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjojMUY0OTdEJz4m
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjxzcGFuIGxhbmc9RlIgc3R5bGU9J2ZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjojMUY0OTdEJz4tIFBv
cnQgTGFiZWwgcmVzdHJpY3Rpb24mbmJzcDs6IE1hdHJpeCAjMiwgUmVzdHJpY3Rpb25UeXBlPVNJ
TVBMRV9MQUJFTCwgTGFiZWwgPSBUUyZuYnNwOzoxNSwxMSw3LDM8L3NwYW4+PHNwYW4gc3R5bGU9
J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxz
cGFuIGxhbmc9RlIgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIg
TmV3Ijtjb2xvcjojMUY0OTdEJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgLSBQb3J0IExhYmVs
IHJlc3RyaWN0aW9uJm5ic3A7OiBNYXRyaXggIzMsIFJlc3RyaWN0aW9uVHlwZT1TSU1QTEVfTEFC
RUwsIExhYmVsID0gVFMmbmJzcDs6MTQsMTAsNiwyPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpi
bGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5n
PUZSIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7Y29s
b3I6IzFGNDk3RCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gUG9ydCBMYWJlbCByZXN0cmlj
dGlvbiZuYnNwOzogTWF0cml4ICMzLCBSZXN0cmljdGlvblR5cGU9U0lNUExFX0xBQkVMLCBMYWJl
bCA9IFRTJm5ic3A7OjEzLDA5LDUsMTwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjojMUY0OTdEJz5JIGFt
IG5vdCAxMDAlIHN1cmUgdGhhdCB3ZSBjYW4gYWx3YXlzIGludGVycHJldCB0aGUgbGFiZWwgYXMg
T0RVIGxhYmVsLCBSRkM0MjAyIHNlY3Rpb24gMi40Ljcgb24gaG93IHRvIGludGVycHJldCB0aGU8
L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg
Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiJDb3VyaWVyIE5ldyI7Y29sb3I6IzFGNDk3RCc+TGFiZWwgb24gYSBURS1MaW5rIHdvdWxkIGlu
ZGljYXRlIHRoYXQgaWYgb25lIGVuZCBzdXBwb3J0IFRETSBhbmQgdGhlIG90aGVyIExTQywgdGhl
IGxhYmVsIHNob3VsZCByZXByZXNlbnQgYSBsYW1iZGEsIDwvc3Bhbj48c3BhbiBzdHlsZT0nY29s
b3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g
c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjoj
MUY0OTdEJz5idXQgdGhlIGNhc2Ugd2hlcmUgdGhlcmUgaXMgc2V2ZXJhbCBJU0NEIGlzIG5vdCB3
ZWxsIGRlc2NyaWJlZC48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+
Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls
ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOiMxRjQ5
N0QnPlRoZSBkcmFmdCBzaG91bGQgZGV0YWlsIHRoZSBydWxlcyBvbiB3aGljaCBsYWJlbCBlbmNv
ZGluZyB0byB1c2UgaW4gY2FzZSBvZiBjb25uZWN0aXZpdHkgbWF0cml4IGluIHRoYXQgY2FzZS48
L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAg
Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286
cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOiMxRjQ5N0QnPkluIHRoYXQgZXhh
bXBsZSB3ZSBoYXZlIGZpeGVkIE1VWCBPRFUzLSZndDtPRFUyIEFORCBlYWNoIE9EVTIgaXMgYXNz
aWduZWQgdG8gYW4gcG9ydDogdGhlIHBvcnQgbGFiZWwgcmVzdHJpY3Rpb24gaXMgdXNlZCwgPC9z
cGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNs
YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi
Q291cmllciBOZXciO2NvbG9yOiMxRjQ5N0QnPlJ1bGVzIGZvciBwb3J0IGxhYmVsIHJlc3RyaWN0
aW9uIHNob3VsZCBhbGxvdyB0byBpbnRlcnByZXQgY29ycmVjdGx5IHRoZSBsYWJlbC48L3NwYW4+
PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9
TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3Nw
YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOiMxRjQ5N0QnPkhvd2V2ZXIgb24gY2FzZSBv
ZiBGaXhlcyBNVVggYW5kIGZsZXhpYmxlIE9EVTIgdG8gcG9ydCBhc3NpZ25tZW50IG9uZSBhbGxv
d2VkIHBvc3NpYmlsaXR5IGlzIHRoZSBmb2xsb3dpbmcgOiA8L3NwYW4+PHNwYW4gc3R5bGU9J2Nv
bG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu
IGxhbmc9RlIgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3
Ijtjb2xvcjojMUY0OTdEJz5NYXRyaXggIzExICh7UG9ydCAxLCBQb3J0IDIsIFBvcnQgMywgUG9y
dCA0LH0sIHtQb3J0IDV9KTwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr
Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxh
bmc9RlIgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtj
b2xvcjojMUY0OTdEJz5URS1MaW5rIDUgKHBvcnQgMikgOiA8L3NwYW4+PHNwYW4gc3R5bGU9J2Nv
bG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu
IGxhbmc9RlIgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3
Ijtjb2xvcjojMUY0OTdEJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstIElTQ0QgIzEg
c3ViLVRMVjogRFdETSA8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RlIgc3R5bGU9J2ZvbnQt
c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijtjb2xvcjojMUY0OTdEJz4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstIElTQ0QgIzIgc3ViLVRMVjogVERNLCBHLjcwOSBP
RFVrIChPRFUzKSA8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWluZGVudDo1LjI1cHQnPjxz
cGFuIGxhbmc9RlIgc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNvdXJpZXIg
TmV3Ijtjb2xvcjojMUY0OTdEJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstIEF2YWlsYWJsZSAm
bmJzcDtMYWJlbHMmbmJzcDs6IMKrJm5ic3A7VFMmbmJzcDs6MTUsMTEsNywzJm5ic3A7wrssIMKr
Jm5ic3A7VFMmbmJzcDs6MTQsMTAsNiwyJm5ic3A7wrssJm5ic3A7wqsmbmJzcDtUUyZuYnNwOzox
MywwOSw1LDEmbmJzcDvCuywmbmJzcDvCqyZuYnNwO1RTJm5ic3A7OjE2LDEyLDgsNOKAnTwvc3Bh
bj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz
cz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1GUiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh
bWlseToiQ291cmllciBOZXciO2NvbG9yOiMxRjQ5N0QnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyAtIEF2YWlsYWJsZSAmbmJzcDtMYWJlbHMmbmJzcDs6IGNoYW5uZWxzIChEV0RNKSA8L3NwYW4+
PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9
TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3Nw
YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9yOiMxRjQ5N0QnPkhvdyB0byBtYWtlIHN1cmUg
dGhlIGludGVycHJldGF0aW9uIGlzIGNvcnJlY3QsIFRoaXMgaXMgYW4gdHlwaWNhbCBjYXNlIGNv
dmVyZWQgYnkgdGhlIGdlbmVyaWMgR01QTFMgUkZDcywgc28gPC9zcGFuPjxzcGFuIHN0eWxlPSdj
b2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh
biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ291cmllciBOZXciO2NvbG9y
OiMxRjQ5N0QnPiZuYnNwO0l0IHNob3VsZCZuYnNwOyBiZSBjb3ZlcmVkIGluIG15IG9waW5pb24g
YnkgdGhlIGdlbmVyaWMgZXh0ZW5zaW9ucy48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNr
Jz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdj
b2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h
bD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48
cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj
ayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz
dHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxl
PSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBj
bSAwY20gNC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp
ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20nPjxwIGNsYXNzPU1zb05v
cm1hbD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21h
Iiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6
YmxhY2snPiBleHQgWmhhbmdmYXRhaSBbbWFpbHRvOnpoYW5nZmF0YWlAaHVhd2VpLmNvbV0gPGJy
PjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgU2VwdGVtYmVyIDI5LCAyMDExIDEyOjE5IFBNPGJyPjxi
PlRvOjwvYj4gTWFyZ2FyaWEsIEN5cmlsIChOU04gLSBERS9NdW5pY2gpOyBjY2FtcEBpZXRmLm9y
Zzxicj48Yj5TdWJqZWN0OjwvYj4gPC9zcGFuPjxzcGFuIGxhbmc9WkgtQ04gc3R5bGU9J2ZvbnQt
c2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2snPuetlOWkjTwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2sn
PjogPC9zcGFuPjxzcGFuIGxhbmc9WkgtQ04gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6
YmxhY2snPuetlOWkjTwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjogPC9zcGFuPjxzcGFuIGxh
bmc9WkgtQ04gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2snPuetlOWkjTwvc3Bh
bj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fu
cy1zZXJpZiI7Y29sb3I6YmxhY2snPjogW0NDQU1QXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNj
YW1wLWdtcGxzLWdlbmVyYWwtY29uc3RyYWludHMtb3NwZi10ZS0wMi50eHQ8L3NwYW4+PHNwYW4g
c3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+PHAg
Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286
cD48L3NwYW4+PC9wPjxkaXY+PHA+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz5IaSBDeXJpbCw8L3NwYW4+
PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHA+PHNwYW4g
c3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHA+PHNwYW4g
c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi
O2NvbG9yOmJsYWNrJz5Vc3VhbGx5LCBvbmUgVEUgbGluayBhZHZlcnRpc2VtZW50ICh3aXRoIHNl
cnZlcmFsIElTQ0RzIGFuZCBtdWx0aXBsZSBsYWJlbCBzdWItVExWcykgaGFzIHRoZSBzYW1lIFN3
aXRjaGluZyBDYXBhYmlsaXR5LCBzbyB0aGVyZSBpcyBpbXBsaWNpdCByZWxhdGlvbnNoaXAgYmV0
d2VlbiB0aGUgSVNDRHMgYW5kIGxhYmVsIHN1Yi1UTFZzLjwvc3Bhbj48c3BhbiBzdHlsZT0nY29s
b3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cD48c3BhbiBzdHlsZT0nY29sb3I6Ymxh
Y2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cD48c3BhbiBzdHlsZT0nZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPkkg
d291bGQgbGlrZSB0byBjb25zaWRlciB5b3VyJm5ic3A7bGFzdCBwb2ludCB3aGVuIEkgdWRwYXRl
IHRoaXMgZHJhZnQgaW4gdGhlIG5leHQgdmVyc2lvbi4gPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xv
cjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj
ayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxwPjxzcGFuIHN0eWxlPSdmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+QnV0
IEkgaGF2ZSBhIHF1ZXN0aW9uIG9uIHlvdXIgZXhhbXBsZSwgZG8geW91IHNlZSB0aGF0IHRoZXJl
IGlzIGEgbGluZSBwb3J0IChvciBpbnRlcmZhY2UpJm5ic3A7Y2FuIHN1cHBvcnQgYm90aCBEV0RN
IGFuZCBURE0gaW4gdGhlIHdvcmxkPyBJIHRoaW5rIGlmIGEgbGluZSBwb3J0IGNhbiBzdXBwb3J0
IERXRE0sIHRoZSBXU09OIFRFIGxpbmsgKHdpdGggV1NPTiByZWxhdGVkIGxhYmVsICh3YXZlbGVu
Z3RoKSBpbmZvcm1hdGlvbikmbmJzcDtzaG91bGQgYmUgYWR2ZXJ0aXNlZCBmb3IgdGhpcyBsaW5l
IHBvcnQ7IGlmIGEgbGluZSBwb3J0IGNhbiBzdXBwb3J0IFRETSwgdGhlbiB0aGUgVERNIFRFIGxp
bmsgKGUuZy4sIE9EVSkmbmJzcDtmb3IgdGhpcyBsaW5lIHBvcnQgc2hvdWxkIGJlIGFkdmVydGlz
ZWQuIEV2ZW4gdGhvdWdoIHRoZXJlIHdhcyBvbmUgcG9ydCBjb3VsZCBzdXBwb3J0IGJvdGggRFdE
TSBhbmQgVERNLCBJIHRoaW5rJm5ic3A7dXN1YWxseSBpdCBzaG91bGQgYWR2ZXJ0aXNlIHRoZXNl
IHR3byB0eXBlcyBvZiBjYXBhYmlsaXR5IHNlcGFyYXRlbHksIGllLiwgdXNlIHNlcGVyYXRlIFRF
IGxpbmsgYWR2ZXJ0aXNlbWVudHMuIHNvLCBJIHRoaW5rIHRoZXJlIGlzIGltcGxpY2l0IHJlbGF0
aW9uc2hpcCBiZXR3ZWVuIHRoZSBJU0NEcyBhbmQgbGFiZWwgc3ViLVRMVnMuPC9zcGFuPjxzcGFu
IHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwPjxzcGFuIHN0eWxl
PSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxwPjxzcGFuIHN0eWxl
PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xv
cjpibGFjayc+RXZlbiB0aG91Z2ggSSB0aGluayZuYnNwO3dlIHNob3VsZCBub3QgdXNlIGEga2lu
ZCBvZiBzcGVjaWFsIGFuZCBjb21wbGV4Jm5ic3A7ZXhhbXBsZSB0byBleHBsYWluIHNvbWV0aGlu
ZywgSSB3aWxsJm5ic3A7YmVhciB5b3VyIGV4YW1wbGUgaW4gbXkgbWluZCB3aGVuIEkgdXBkYXRl
IHRoZSBkcmFmdCAoYXMgSSBzYWlkIGluIHRoZSBzZWNvbmQgc2VudGVuY2UgYWJvdmUpLjwvc3Bh
bj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cD48c3Bh
biBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cD48c3Bh
biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp
ZiI7Y29sb3I6YmxhY2snPlRoYW5rczwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD48cD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxv
OnA+PC9vOnA+PC9zcGFuPjwvcD48cD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPkZhdGFpPC9zcGFuPjxz
cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwPjxzcGFuIHN0
eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxwPjxzcGFuIHN0
eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxkaXY+PGRpdiBj
bGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxlPSd0ZXh0LWFsaWduOmNlbnRlcic+PHNw
YW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7Y29sb3I6Ymxh
Y2snPjxociBzaXplPTIgd2lkdGg9IjEwMCUiIGFsaWduPWNlbnRlcj48L3NwYW4+PC9kaXY+PGRp
diBpZD1kaXZScEYzMzcyNjk+PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9t
OjEyLjBwdCc+PGI+PHNwYW4gbGFuZz1aSC1DTiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtjb2xv
cjpibGFjayc+5Y+R5Lu25Lq6PC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjo8L3Nw
YW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEi
LCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+IE1hcmdhcmlhLCBDeXJpbCAoTlNOIC0gREUvTXVu
aWNoKSBbY3lyaWwubWFyZ2FyaWFAbnNuLmNvbV08YnI+PC9zcGFuPjxiPjxzcGFuIGxhbmc9Wkgt
Q04gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2snPuWPkemAgeaXtumXtDwvc3Bh
bj48L2I+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9t
YSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz46PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymxh
Y2snPiAyMDExPC9zcGFuPjxzcGFuIGxhbmc9WkgtQ04gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7
Y29sb3I6YmxhY2snPuW5tDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjk8L3NwYW4+PHNwYW4g
bGFuZz1aSC1DTiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayc+5pyIPC9zcGFu
PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z
LXNlcmlmIjtjb2xvcjpibGFjayc+Mjk8L3NwYW4+PHNwYW4gbGFuZz1aSC1DTiBzdHlsZT0nZm9u
dC1zaXplOjEwLjBwdDtjb2xvcjpibGFjayc+5pelPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+
IDE3OjM2PGJyPjwvc3Bhbj48Yj48c3BhbiBsYW5nPVpILUNOIHN0eWxlPSdmb250LXNpemU6MTAu
MHB0O2NvbG9yOmJsYWNrJz7liLA8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+Ojwv
c3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9t
YSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4gWmhhbmdmYXRhaTsgY2NhbXBAaWV0Zi5vcmc8
YnI+PC9zcGFuPjxiPjxzcGFuIGxhbmc9WkgtQ04gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Y29s
b3I6YmxhY2snPuS4u+mimDwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz46PC9zcGFu
PjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwi
c2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiBSRTogPC9zcGFuPjxzcGFuIGxhbmc9WkgtQ04gc3R5
bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2snPuetlOWkjTwvc3Bhbj48c3BhbiBzdHls
ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29s
b3I6YmxhY2snPjogPC9zcGFuPjxzcGFuIGxhbmc9WkgtQ04gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w
cHQ7Y29sb3I6YmxhY2snPuetlOWkjTwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw
dDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjogW0NDQU1Q
XSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWdlbmVyYWwtY29uc3RyYWludHMt
b3NwZi10ZS0wMi50eHQ8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+PC9kaXY+PGRpdj48ZGl2PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls
ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2Nv
bG9yOiMxRjQ5N0QnPkhpLCA8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFj
ayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz
dHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi
O2NvbG9yOiMxRjQ5N0QnPklmIEkgdW5kZXJzdGFuZCBjb3JyZWN0bHksIHlvdSBzdGF0ZSB0aGF0
IHRoZXJlIGlzIG5vdCBleHBsaWNpdCBvciBpbXBsaWNpdCByZWxhdGlvbnNoaXAgYmV0d2VlbiB0
aGUgSVNDRCBhbmQgbGFiZWwgc3ViLVRMViwgY29ycmVjdD88L3NwYW4+PHNwYW4gc3R5bGU9J2Nv
bG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu
IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp
ZiI7Y29sb3I6IzFGNDk3RCc+SSB3b3VsZCBleHBlY3QgYSBuZXcgZ2VuZXJpYyBkcmFmdCB0byBi
ZSBhcHBsaWNhYmxlIHRvIGFsbCBhbHJlYWR5IGRlZmluZWQgbGFiZWwgZm9ybWF0LCBzbyAmbmJz
cDtpdCBzZWVtcyBtaXNzaW5nIGluIHRoZSBkb2N1bWVudC48L3NwYW4+PHNwYW4gc3R5bGU9J2Nv
bG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu
IHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz
PU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2Fs
aWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkNvdWxkIHlvdSBjb25zaWRlciBteSBs
YXN0IHBvaW50IHJlZ2FyZGluZyB0aGUgZXhhbXBsZSBvZiBzd2l0Y2hpbmcgcmVzdHJpY3Rpb24g
aW4gRy43MDkgdjIgYW5kIERXRE0gY29udGV4dCwgaXQgd291bGQgYmUgaGVscGZ1bCA8L3NwYW4+
PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9
TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp
YnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7dG8gaGF2ZSBzb21lIHN0YXRl
bWVudCBldmVuIHRob3VnaCBpdCB3aWxsIG5vdCBiZSBpbiB0aGUgZG9jdW1lbnQuPC9zcGFuPjxz
cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z
b05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu
PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5CZXN0IFJlZ2Fy
ZHMuPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9w
PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+
PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJs
YWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7
Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Jz48
ZGl2PjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBw
dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtJz48cCBjbGFzcz1Nc29Ob3JtYWw+PGI+PHNwYW4g
c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi
O2NvbG9yOmJsYWNrJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4gZXh0IFpo
YW5nZmF0YWkgW21haWx0bzp6aGFuZ2ZhdGFpQGh1YXdlaS5jb21dIDxicj48Yj5TZW50OjwvYj4g
V2VkbmVzZGF5LCBTZXB0ZW1iZXIgMjgsIDIwMTEgNDozMCBBTTxicj48Yj5Ubzo8L2I+IE1hcmdh
cmlhLCBDeXJpbCAoTlNOIC0gREUvTXVuaWNoKTsgY2NhbXBAaWV0Zi5vcmc8YnI+PGI+U3ViamVj
dDo8L2I+IDwvc3Bhbj48c3BhbiBsYW5nPVpILUNOIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Nv
bG9yOmJsYWNrJz7nrZTlpI08L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz46IDwvc3Bhbj48c3Bh
biBsYW5nPVpILUNOIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrJz7nrZTlpI08
L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIs
InNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz46IFtDQ0FNUF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0
Zi1jY2FtcC1nbXBscy1nZW5lcmFsLWNvbnN0cmFpbnRzLW9zcGYtdGUtMDIudHh0PC9zcGFuPjxz
cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjwvZGl2
PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+
PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxwPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+SGkgQ3lyaWwsPC9z
cGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwPjxz
cGFuIHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxwPjxz
cGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNl
cmlmIjtjb2xvcjpibGFjayc+SSBhZ3JlZSBvbiB5b3VyIGZpcnN0IHN1Z2dlc3Rpb24uPC9zcGFu
PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwPjxzcGFu
IHN0eWxlPSdjb2xvcjpibGFjayc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxwPjxzcGFu
IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm
Ijtjb2xvcjpibGFjayc+U2Vjb25kbHksIHRoaXMgZHJhZnQgaXMgZ2VuZXJpYywgd2hlbiZuYnNw
O2l0IG5lZWRzIHRvIGFkdmVydGlzZSBsYWJlbCBpbmZvcm1hdGlvbiBmb3Igc29tZSBzcGVjaWZp
YyB0ZWNoIChlLmcuLCBURE0pLCB0aGUgZG9jdW1lbnQgYWJvdXQmbmJzcDtzcGVjaWZpYyZuYnNw
O3RlY2ggY2FuJm5ic3A7cmVmZXIgdG8gdGhpcyBkcmFmdCBhbmQgc2hvdWxkIGRlZmluZSBob3cg
dG8gY29ycmVsYXRlIHRoZSBJU0NEcyBhbmQgbGFiZWwgc3ViLVRMVnMgaWYgdGhlcmUgaXMgbm8m
bmJzcDtleHBsaWNpdCBvciZuYnNwO2ltcGxpY2l0Jm5ic3A7cmVsYXRpb25zaGlwIGJldHdlZW4g
dGhlbSZuYnNwOyhJIHRoaW5rIHRoZXJlIGFyZSBsb3RzIG9mIHBvdGVudGlhbCBzb2x1dGlvbnMg
dG8gaGFuZGxlIHRoYXQsIGl0IGlzIHF1aXRlIHRlY2ggc3BlY2lmaWMgc3R1ZmYpLiA8L3NwYW4+
PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHA+PHNwYW4g
c3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHA+PHNwYW4g
c3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHA+PHNwYW4g
c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi
O2NvbG9yOmJsYWNrJz5GYXRhaTwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD48cD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+
PC9vOnA+PC9zcGFuPjwvcD48cD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZh
bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPlRoYW5rczwvc3Bhbj48c3Bh
biBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cD48c3BhbiBzdHls
ZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cD48c3BhbiBzdHls
ZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2PjxkaXYgY2xh
c3M9TXNvTm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxzcGFu
IHN0eWxlPSdmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO2NvbG9yOmJsYWNr
Jz48aHIgc2l6ZT0yIHdpZHRoPSIxMDAlIiBhbGlnbj1jZW50ZXI+PC9zcGFuPjwvZGl2PjxkaXYg
aWQ9ZGl2UnBGMjQxMjY4PjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbTox
Mi4wcHQnPjxiPjxzcGFuIGxhbmc9WkgtQ04gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6
YmxhY2snPuWPkeS7tuS6ujwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w
cHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz46PC9zcGFu
PjwvYj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwi
c2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiBNYXJnYXJpYSwgQ3lyaWwgKE5TTiAtIERFL011bmlj
aCkgW2N5cmlsLm1hcmdhcmlhQG5zbi5jb21dPGJyPjwvc3Bhbj48Yj48c3BhbiBsYW5nPVpILUNO
IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrJz7lj5HpgIHml7bpl7Q8L3NwYW4+
PC9iPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEi
LCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9J2ZvbnQt
c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNr
Jz4gMjAxMTwvc3Bhbj48c3BhbiBsYW5nPVpILUNOIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Nv
bG9yOmJsYWNrJz7lubQ8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m
YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz45PC9zcGFuPjxzcGFuIGxh
bmc9WkgtQ04gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2snPuaciDwvc3Bhbj48
c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z
ZXJpZiI7Y29sb3I6YmxhY2snPjI3PC9zcGFuPjxzcGFuIGxhbmc9WkgtQ04gc3R5bGU9J2ZvbnQt
c2l6ZToxMC4wcHQ7Y29sb3I6YmxhY2snPuaXpTwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPiAx
NzozODxicj48L3NwYW4+PGI+PHNwYW4gbGFuZz1aSC1DTiBzdHlsZT0nZm9udC1zaXplOjEwLjBw
dDtjb2xvcjpibGFjayc+5YiwPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw
LjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjo8L3Nw
YW4+PC9iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEi
LCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+IFpoYW5nZmF0YWk7IGNjYW1wQGlldGYub3JnPGJy
Pjwvc3Bhbj48Yj48c3BhbiBsYW5nPVpILUNOIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2NvbG9y
OmJsYWNrJz7kuLvpopg8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0
O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+Ojwvc3Bhbj48
L2I+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh
bnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4gUkU6IDwvc3Bhbj48c3BhbiBsYW5nPVpILUNOIHN0eWxl
PSdmb250LXNpemU6MTAuMHB0O2NvbG9yOmJsYWNrJz7nrZTlpI08L3NwYW4+PHNwYW4gc3R5bGU9
J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9y
OmJsYWNrJz46IFtDQ0FNUF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0Zi1jY2FtcC1nbXBscy1nZW5l
cmFsLWNvbnN0cmFpbnRzLW9zcGYtdGUtMDIudHh0PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpi
bGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjwvZGl2PjxkaXY+PGRpdj48cCBjbGFzcz1Nc29O
b3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmki
LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5IaSwgPC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xv
cjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBz
dHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N
c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli
cmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5UaGFua3MgZm9yIHRoZSBhbnN3ZXIsIDwv
c3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj
bGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+UGxl
YXNlIHNlZSBpbmxpbmU8L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+
Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls
ZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48ZGl2IHN0eWxlPSdi
b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAw
Y20gNC4wcHQnPjxkaXY+PGRpdiBzdHlsZT0nYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAj
QjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20nPjxwIGNsYXNzPU1zb05vcm1h
bD48Yj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwi
c2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0nZm9u
dC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6Ymxh
Y2snPiBleHQgWmhhbmdmYXRhaSBbbWFpbHRvOnpoYW5nZmF0YWlAaHVhd2VpLmNvbV0gPGJyPjxi
PlNlbnQ6PC9iPiBUdWVzZGF5LCBTZXB0ZW1iZXIgMjcsIDIwMTEgMTE6MTcgQU08YnI+PGI+VG86
PC9iPiBNYXJnYXJpYSwgQ3lyaWwgKE5TTiAtIERFL011bmljaCk7IGNjYW1wQGlldGYub3JnPGJy
PjxiPlN1YmplY3Q6PC9iPiA8L3NwYW4+PHNwYW4gbGFuZz1aSC1DTiBzdHlsZT0nZm9udC1zaXpl
OjEwLjBwdDtjb2xvcjpibGFjayc+562U5aSNPC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+OiBb
Q0NBTVBdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC1jb25zdHJh
aW50cy1vc3BmLXRlLTAyLnR4dDwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+
PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5
bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PGRpdj48cCBzdHls
ZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+SGkgQ3lyaWwsPGJy
Pjxicj5UaGFua3MgZm9yIHlvdXIgY29tbWV0cy48YnI+PGJyPlBsZWFzZSBzZWUgaW4tbGluZSBi
ZWxvdy48YnI+PGJyPjxicj5GYXRhaTxicj48YnI+VGhhbmtzPGJyPjxicj48YnI+PGJyPl9fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+PC9zcGFuPjxzcGFuIGxhbmc9
WkgtQ04gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6TWluZ0xpVTtjb2xvcjpi
bGFjayc+5Y+R5Lu25Lq6PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+OiBNYXJnYXJpYSwgQ3ly
aWwgKE5TTiAtIERFL011bmljaCkgW2N5cmlsLm1hcmdhcmlhQG5zbi5jb21dPGJyPjwvc3Bhbj48
c3BhbiBsYW5nPVpILUNOIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Ok1pbmdM
aVU7Y29sb3I6YmxhY2snPuWPkemAgeaXtumXtDwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXpl
OjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6YmxhY2snPjog
MjAxMTwvc3Bhbj48c3BhbiBsYW5nPVpILUNOIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt
ZmFtaWx5OiJNUyBHb3RoaWMiO2NvbG9yOmJsYWNrJz7lubQ8L3NwYW4+PHNwYW4gc3R5bGU9J2Zv
bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJs
YWNrJz45PC9zcGFuPjxzcGFuIGxhbmc9WkgtQ04gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u
dC1mYW1pbHk6Ik1TIEdvdGhpYyI7Y29sb3I6YmxhY2snPuaciDwvc3Bhbj48c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6
YmxhY2snPjI2PC9zcGFuPjxzcGFuIGxhbmc9WkgtQ04gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7
Zm9udC1mYW1pbHk6Ik1TIEdvdGhpYyI7Y29sb3I6YmxhY2snPuaXpTwvc3Bhbj48c3BhbiBzdHls
ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29s
b3I6YmxhY2snPiAxNjowMzxicj48L3NwYW4+PHNwYW4gbGFuZz1aSC1DTiBzdHlsZT0nZm9udC1z
aXplOjEwLjBwdDtmb250LWZhbWlseToiTVMgR290aGljIjtjb2xvcjpibGFjayc+5YiwPC9zcGFu
PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z
LXNlcmlmIjtjb2xvcjpibGFjayc+OiBaaGFuZ2ZhdGFpOyBjY2FtcEBpZXRmLm9yZzxicj48L3Nw
YW4+PHNwYW4gbGFuZz1aSC1DTiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToi
TVMgR290aGljIjtjb2xvcjpibGFjayc+5Li7PC9zcGFuPjxzcGFuIGxhbmc9WkgtQ04gc3R5bGU9
J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6TWluZ0xpVTtjb2xvcjpibGFjayc+6aKYPC9z
cGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz
YW5zLXNlcmlmIjtjb2xvcjpibGFjayc+OiBSRTogW0NDQU1QXSBJLUQgQWN0aW9uOiBkcmFmdC1p
ZXRmLWNjYW1wLWdtcGxzLWdlbmVyYWwtY29uc3RyYWludHMtb3NwZi10ZS0wMi50eHQ8YnI+PGJy
PkhpLDxicj48YnI+SSBoYXZlIHRoZSBmb2xsb3dpbmcgY29tbWVudHMvcXVlc3Rpb24gcmVnYXJk
aW5nIHRoaXMgcmV2aXNpb248YnI+PGJyPjMuMi4gQXZhaWxhYmxlIExhYmVsczo8YnI+PGJyPlRo
ZSB0ZXh0IHN0YXRlIDog4oCcVGhlIEF2YWlsYWJsZSBMYWJlbHMgc3ViLVRMViZuYnNwOyZuYnNw
OyBtYXkgb2NjdXIgYXQgbW9zdCBvbmNlIHdpdGhpbiB0aGUgbGluayBUTFYu4oCdPGJyPjxicj5I
b3cgdG8gZW5jb2RlIGRpZmZlcmVudCBsYWJlbCBmb3JtYXQgaW4gdGhhdCBjYXNlPyBJIHRoaW5r
IHRoZSBsYWJlbCBmb3JtYXQgd291bGQgZGVwZW5kPGJyPm9uIHRoZSBJU0NELCBhbmQgYXMgd2Ug
bWlnaHQgaGF2ZSBzZXZlcmFsIElTQ0QsIGhhdmluZyBzZXZlcmFsIEF2YWlsYWJsZSBMYWJlbCBz
dWItVExWIG1ha2Ugc2Vuc2UuPGJyPlRoaXMgYWxzbyBhcHBseSB0byAzLjMuIFNoYXJlZCBCYWNr
dXAgTGFiZWxzLjxicj48YnI+PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv
bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibHVlJz5bRmF0YWldIFRoaXMg
JnF1b3Q7bWF5JnF1b3Q7IHNob3VsZCBiZSAmcXVvdDtNQVkmcXVvdDsgYWNjb3JkaW5nIHRvIExv
dSdzIHN1Z2dlc3Rpb24sIHNvIGl0IGRvZXMgbm90IHByZXZlbnQgeW91IHRvIGhhdmUgc2V2ZXJh
bCBhdmFpbGFibGUgbGFiZWwgc3ViLVRMVnMuIDwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6Ymxh
Y2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPltDeXJp
bF0gU3RhdGluZyDigJxUaGUgQXZhaWxhYmxlIExhYmVscyBzdWItVExWJm5ic3A7Jm5ic3A7IE1B
WSAmbmJzcDtvY2N1ciBtb3JlIHRoYW4gb25jZSB3aXRoaW4gdGhlIGxpbmsgVExWLuKAnSAmbmJz
cDtXb3VsZCBiZSBtb3JlIGFjY3VyYXRlIGFuZCBlYXNpZXIgdG8gdW5kZXJzdGFuZC48L3NwYW4+
PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHA+PHNwYW4g
c3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHA+PHNwYW4g
c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYi
O2NvbG9yOmJsYWNrJz48YnI+SW4gY2FzZSBvZiBzZXZlcmFsIElTQ0QgYXJlIHByZXNlbnQgZm9y
IGEgZ2l2ZW4gYWR2ZXJ0aXNlbWVudCBob3cgdG8gaW50ZXJwcmV0IHRoZSBsYWJlbCBmb3JtYXQg
aW4gdGhlPGJyPmxhYmVsLXJlbGF0ZWQgc3ViLVRMVnM/PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xv
cjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwPjxzcGFuIHN0eWxlPSdmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+PGJy
Pjwvc3Bhbj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21h
Iiwic2Fucy1zZXJpZiI7Y29sb3I6Ymx1ZSc+W0ZhdGFpXSBJdCBpcyBlYXN5IHRvIGFjaGl2ZSB0
aGF0LiBlLmcsJm5ic3A7aW4gU0RIIG5ldHdvcmssIGEgbm9kZSBjYW4gYWR2ZXJ0aXNlIHNldmVy
YWwgSVNDRHMmbmJzcDt3aXRoIG9uZSBvciBtdWx0aXBsZSBsYWJlbCBzdWItVExWcyAoSSBhc3N1
bWUgJnF1b3Q7SUYmcXVvdDsgbGFiZWwgaW5mb3JtYXRpb24gaXMgbmVlZGVkIHRvIGJlIGFkdmVy
dGlzZWQgaGVyZSksIHdoeSBpdCBjYW5ub3QgaW50ZXJwcmV0IHRoZSBsYWJlbHMgYXJlIFNESCBs
YWJlbHM/PC9zcGFuPjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+
PC9wPjxwPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEi
LCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5bQ3lyaWxdJm5ic3A7IElmIHRoZXJlIGlzIDIg
SVNDRCBzdWItVExWIGFuZCAyIGF2YWlsYWJsZSBsYWJlbCBzdWItVExWLCBob3cgdG8gdGVsbCB3
aGljaCBhdmFpbGFibGUgbGFiZWwgc3ViLVRMViByZWxhdGUgdG8gd2hpY2ggSVNDRCBzdWItVExW
Pzwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48
cD48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48
cD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fu
cy1zZXJpZiI7Y29sb3I6YmxhY2snPjxicj5Db3VsZCB5b3UgY2xhcmlmeSB0aGlzIHBvaW50LCBp
dCB3b3VsZCBiZSB1c2VmdWwgZm9yIGluc3RhbmNlIHRvIGNvbnNpZGVyIHRoZSBleGFtcGxlIG9m
IGEgbGluayBzdXBwb3J0aW5nIFNESDxicj4obm8gVkM0LXN3aXRjaGluZyksIE9EVSAoRy43MDks
IGFzIG9mIFJGQzQzMjgsIGFuZCBmb3IgdGhlIGN1cnJlbnQgRy43MDkgdjMgbGFiZWwgZm9ybWF0
KS48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+
PHA+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
PHA+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRhaG9tYSIsInNh
bnMtc2VyaWYiO2NvbG9yOmJsdWUnPltGYXRhaV0mbmJzcDsgRG8geW91IG1lYW4gdG8gaGF2ZSBh
biBleGFtcGxlIG9uIGh5YnJpZCBub2RlPyBJIHdpbGwgbm90Jm5ic3A7dXNlJm5ic3A7YSBjb21w
bGV4Jm5ic3A7ZXhhbXBsZSB0byBleHBsYWluIGEmbmJzcDtraW5kIG9mIHNpbXBsZSB0aGluZyAo
SXQgd2lsbCBjb25mdXNlIHBlb3BsZSkuIDwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2sn
PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPltDeXJpbF0g
SXQgbWF5IG5vdCBiZSBzbyBzaW1wbGUsIEkgaGF2ZSB0cm91YmxlIHRvIGludGVycHJldCBsYWJl
bCB3aXRob3V0IGtub3dpbmcgdGhlIElTQ0QgY29uc2lkZXJlZCBhbmQgSSBkbyBub3Qgc2VlIGNs
ZWFybHkgdGhlIHJlbGF0aW9uIGJldHdlZW4gdGhlIHR3byBpbiB0aGUgZG9jdW1lbnQuPC9zcGFu
PjxzcGFuIHN0eWxlPSdjb2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwPjxzcGFu
IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm
Ijtjb2xvcjpibGFjayc+PGJyPlRoZSB0ZXh0IGlzIHZlcnkgZm9jdXNlZCBvbiBXU09OLCB3aGls
ZSBpdCBpcyBhIHZlcnkgaW50ZXJlc3RpbmcgZXhhbXBsZSwgaGF2aW5nIG90aGVyIHRlY2hub2xv
Z3kgKE9UTiBmb3I8YnI+ZXhhbXBsZSB3b3VsZCBoZWxwIHRvIHNob3cgdGhhdCB0aGUgc29sdXRp
b24gaXMgZ2VuZXJpYy48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+PHA+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsdWUnPltGYXRhaV0gSSB0aGluayBvbmUgdHlw
aWNhbCBleGFtcGxlIGlzIHN1ZmZpY2llbnQgZm9yIHBlb3BsZSB0byB1bmRlcnN0YW5kIHRoaW5n
cy4gVERNIG5ldHdvcmsgaXMgZGlmZmVyZW50IGZyb20gV1NPTiBuZXR3b3JrLiZuYnNwO0luIFRE
TSBuZXR3b3JrLCB1c3VhbGx5IGl0IHdpbGwgbm90IGFkdmVydGlzZSBsYWJlbCBpbmZvcm1hdGlv
biBldmVuIHRob3VnaCBsYWJlbCBpbmZvcm1hdGlvbiBjb3VsZCBiZSBhZHZlcnRpc2VkLjwvc3Bh
bj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cD48c3Bh
biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJp
ZiI7Y29sb3I6IzFGNDk3RCc+W0N5cmlsXSBUaGV5IGFyZSBpbmRlZWQgZGlmZmVyZW50LCBidXQg
ZnJvbSBsYWJlbCBwb2ludCBvZiB2aWV3IGl0IHNob3VsZCBub3QgbWFrZSBhIGRpZmZlcmVuY2Uu
IEEgdXN1YWwgdXNlIGNhc2Ugb2YgY29ubmVjdGl2aXR5IG1hdHJpeCB3b3VsZCBiZSBmb3IgZXhh
bXBsZSBvbiBjbGllbnQgY2FyZHMgd2l0aCBzd2l0Y2hpbmcgcmVzdHJpY3Rpb24gOiBmaXhlZCBN
dWx0aXBsZXggYW5kIGxhYmVsIGFzc2lnbm1lbnQgZHVlIHRvIHRoZSBmaXhlZCBNVVggKE9EVTIt
Jmd0O09EVTEgZm9yIGluc3RhbmNlKSAmbmJzcDtvbiBEV0RNIG5vZGUgOjwvc3Bhbj48c3BhbiBz
dHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBzdHlsZT0nbWFyZ2lu
LWxlZnQ6NS4yNXB0O3RleHQtaW5kZW50OjMwLjc1cHQnPjxzcGFuIHN0eWxlPSdmb250LXNpemU6
MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz50
aGUgcmVzdHJpY3Rpb24gY2FuIGJlIG1vZGVsZWQgYXMgb25lIGNvbm5lY3Rpdml0eSBtYXRyaXgg
cGVyIGNsaWVudCBwb3J0LDwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD48cCBzdHlsZT0nbWFyZ2luLWxlZnQ6MTAuNXB0Jz48c3BhbiBzdHlsZT0n
Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6
IzFGNDk3RCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwO3RoZSBj
bGllbnQgcG9ydCBoYXZlIHRoZW4gSVNDRCBURE0sIDwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6
YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBzdHlsZT0nbWFyZ2luLWxlZnQ6MTAuNXB0
Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiVGFob21hIiwic2Fu
cy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7dGhlIG90aGVyIHBvcnRzIGNhbiBkbyBEV0RNIGFuZCBURE0sIDwvc3Bh
bj48c3BhbiBzdHlsZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBzdHls
ZT0nbWFyZ2luLWxlZnQ6MTAuNXB0Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250
LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7Y29sb3I6IzFGNDk3RCc+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Zm9yIHRoZSBjb25uZWN0aXZpdHkg
bWF0cml4IGNvcnJlc3BvbmRpbmcgdG8gYSBjbGllbnQgcG9ydCB0aGUgb25seSBPRFUgbGFiZWwg
dG8gYmUgYXNzaWduZWQgKGR1ZSB0byBmaXhlZCBNVVgpIGlzIHNwZWNpZmllZCA8L3NwYW4+PHNw
YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHA+PHNwYW4gc3R5
bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHA+PHNwYW4gc3R5
bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj
b2xvcjojMUY0OTdEJz5GaXJzdCwgaXMgdGhpcyBtb2RlbGluZyBjb3JyZWN0PyA8L3NwYW4+PHNw
YW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHA+PHNwYW4gc3R5
bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtj
b2xvcjojMUY0OTdEJz5TZWNvbmQsIGhvdyB0byBtYWtlIHN1cmUgdGhlIGxhYmVsIHJlc3RyaWN0
aW9uIGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcyBPRFUgbGFiZWxzPzwvc3Bhbj48c3BhbiBzdHls
ZT0nY29sb3I6YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cD48c3BhbiBzdHlsZT0nY29s
b3I6YmxhY2snPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cD48c3BhbiBzdHlsZT0nZm9u
dC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMx
RjQ5N0QnPkkgdGhpbmsgaXQgaXMgYWxzbyBpbXBvcnRhbnQgdG8gc2hvdyB0aGF0IHRoZSBleHRl
bnNpb25zIGFyZSBhbHNvIHdvcmtpbmcgb3V0c2lkZSB0aGUgZnJhbWV3b3JrIHRoZXkgd2VyZSBi
b3JuIChXU09OKS48L3NwYW4+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+PHA+PHNwYW4gc3R5bGU9J2NvbG9yOmJsYWNrJz4mbmJzcDs8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+PHA+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRh
aG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkJSPC9zcGFuPjxzcGFuIHN0eWxlPSdj
b2xvcjpibGFjayc+PG86cD48L286cD48L3NwYW4+PC9wPjxwPjxzcGFuIHN0eWxlPSdmb250LXNp
emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+
PGJyPjxicj5CZXN0IFJlZ2FyZHMsPGJyPkN5cmlsPGJyPjxicj4mZ3Q7IC0tLS0tT3JpZ2luYWwg
TWVzc2FnZS0tLS0tPGJyPiZndDsgRnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv
OmNjYW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZjxicj4mZ3Q7IE9mIGV4dCBaaGFuZ2Zh
dGFpPGJyPiZndDsgU2VudDogVGh1cnNkYXksIFNlcHRlbWJlciAyMiwgMjAxMSAxMToxNyBBTTxi
cj4mZ3Q7IFRvOiBjY2FtcEBpZXRmLm9yZzxicj4mZ3Q7IFN1YmplY3Q6IFJlOiBbQ0NBTVBdIEkt
RCBBY3Rpb246IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC08YnI+Jmd0OyBjb25zdHJh
aW50cy1vc3BmLXRlLTAyLnR4dDxicj4mZ3Q7PGJyPiZndDsgSGkgQ0NBTVBlcnMsPGJyPiZndDs8
YnI+Jmd0OyBBIG5ldyB2ZXJzaW9uIGhhcyBiZWVuIHN1Ym1pdHRlZCB0byBhZGRyZXNzIHRoZSBj
b21tZW50cyBmcm9tIHRoZSBXRzxicj4mZ3Q7IGRpc2N1c3Npb24uPGJyPiZndDs8YnI+Jmd0OyBX
ZSBhY2NlcHRlZCBBY2VlIGFuZCBZb3VuZydzIHN1Z2dlc3Rpb24gdG8gaW50cm9kdWNlIGEgbmV3
IHRvcC1sZXZlbDxicj4mZ3Q7IG5vZGUgVExWIChHZW5lcmljIE5vZGUgQXR0cmlidXRlIFRMVikg
dG8gc2ltcGxpZnkgdGhpbmdzIGFuZCBhIG5ldzxicj4mZ3Q7IHNlY3Rpb24gKFNlY3Rpb24gNSkg
d2FzIGFkZGVkIHRvIGRlc2NyaWJlIHNjYWxhYmlsaXR5IGlzc3VlLjxicj4mZ3Q7PGJyPiZndDsg
TW9yZSBpbmZvcm1hdGlvbiBmcm9tOiBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYt
Y2NhbXAtZ21wbHMtPGJyPiZndDsgZ2VuZXJhbC1jb25zdHJhaW50cy1vc3BmLXRlLTAyLnR4dDxi
cj4mZ3Q7PGJyPiZndDsgUGxlYXNlIGNoZWNrIG91dCBmb3IgZGV0YWlscyBhbmQgY29tbWVudHMg
YXJlIGFsd2F5cyB3ZWxjb21lLjxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0OyBUaGFua3M8YnI+Jmd0
Ozxicj4mZ3Q7IEZhdGFpPGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7IC0tLS0tT3JpZ2luYWwgTWVz
c2FnZS0tLS0tPGJyPiZndDsgRnJvbTogY2NhbXAtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmNj
YW1wLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZjxicj4mZ3Q7IE9mIGludGVybmV0LWRyYWZ0
c0BpZXRmLm9yZzxicj4mZ3Q7IFNlbnQ6IDIwMTE8L3NwYW4+PHNwYW4gbGFuZz1aSC1DTiBzdHls
ZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseToiTVMgR290aGljIjtjb2xvcjpibGFjayc+
5bm0PC9zcGFuPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhv
bWEiLCJzYW5zLXNlcmlmIjtjb2xvcjpibGFjayc+OTwvc3Bhbj48c3BhbiBsYW5nPVpILUNOIHN0
eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiO2NvbG9yOmJsYWNr
Jz7mnIg8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6IlRh
aG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4yMjwvc3Bhbj48c3BhbiBsYW5nPVpILUNO
IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJNUyBHb3RoaWMiO2NvbG9yOmJs
YWNrJz7ml6U8L3NwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6
IlRhaG9tYSIsInNhbnMtc2VyaWYiO2NvbG9yOmJsYWNrJz4gMTc6MDY8YnI+Jmd0OyBUbzogaS1k
LWFubm91bmNlQGlldGYub3JnPGJyPiZndDsgQ2M6IGNjYW1wQGlldGYub3JnPGJyPiZndDsgU3Vi
amVjdDogW0NDQU1QXSBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWNjYW1wLWdtcGxzLWdlbmVyYWwt
PGJyPiZndDsgY29uc3RyYWludHMtb3NwZi10ZS0wMi50eHQ8YnI+Jmd0Ozxicj4mZ3Q7IEEgTmV3
IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURy
YWZ0czxicj4mZ3Q7IGRpcmVjdG9yaWVzLiBUaGlzIGRyYWZ0IGlzIGEgd29yayBpdGVtIG9mIHRo
ZSBDb21tb24gQ29udHJvbCBhbmQ8YnI+Jmd0OyBNZWFzdXJlbWVudCBQbGFuZSBXb3JraW5nIEdy
b3VwIG9mIHRoZSBJRVRGLjxicj4mZ3Q7PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgVGl0bGUmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgOiBPU1BGLVRFIEV4dGVuc2lvbnMgZm9yIEdlbmVyYWwgTmV0
d29yayBFbGVtZW50PGJyPiZndDsgQ29uc3RyYWludHM8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyBBdXRob3IocykmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgOiBGYXRhaSBaaGFuZzxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7IFlvdW5nIExlZTxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IEppYW5ydWkgSGFuPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgR3JlZyBCZXJuc3RlaW48YnI+Jmd0OyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBZdW5iaW4gWHU8YnI+Jmd0OyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBGaWxlbmFtZSZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IGRyYWZ0LWlldGYtY2NhbXAtZ21wbHMtZ2VuZXJhbC1j
b25zdHJhaW50cy08YnI+Jmd0OyBvc3BmLXRlLTAyLnR4dDxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBhZ2VzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogMTQ8YnI+Jmd0OyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBEYXRlJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogMjAxMS0wOS0yMjxicj4mZ3Q7
PGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgR2VuZXJhbGl6ZWQgTXVsdGlwcm90b2NvbCBMYWJl
bCBTd2l0Y2hpbmcgY2FuIGJlIHVzZWQgdG8gY29udHJvbCBhPGJyPiZndDsmbmJzcDsmbmJzcDsm
bmJzcDsgd2lkZSB2YXJpZXR5IG9mIHRlY2hub2xvZ2llcyBpbmNsdWRpbmcgcGFja2V0IHN3aXRj
aGluZyAoZS5nLiw8YnI+Jmd0OyBNUExTKSw8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyB0aW1l
LWRpdmlzaW9uIChlLmcuLCBTT05FVC9TREgsIE9UTiksIHdhdmVsZW5ndGggKGxhbWJkYXMpLCBh
bmQ8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBzcGF0aWFsIHN3aXRjaGluZyAoZS5nLiwgaW5j
b21pbmcgcG9ydCBvciBmaWJlciB0byBvdXRnb2luZyBwb3J0IG9yPGJyPiZndDsmbmJzcDsmbmJz
cDsmbmJzcDsgZmliZXIpLiBJbiBzb21lIG9mIHRoZXNlIHRlY2hub2xvZ2llcyBuZXR3b3JrIGVs
ZW1lbnRzIGFuZCBsaW5rcyBtYXk8YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBpbXBvc2UgYWRk
aXRpb25hbCByb3V0aW5nIGNvbnN0cmFpbnRzIHN1Y2ggYXMgYXN5bW1ldHJpYyBzd2l0Y2g8YnI+
Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBjb25uZWN0aXZpdHksIG5vbi1sb2NhbCBsYWJlbCBhc3Np
Z25tZW50LCBhbmQgbGFiZWwgcmFuZ2U8YnI+Jmd0OyBsaW1pdGF0aW9uczxicj4mZ3Q7Jm5ic3A7
Jm5ic3A7Jm5ic3A7IG9uIGxpbmtzLiBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBPU1BGIHJvdXRp
bmcgcHJvdG9jb2wgZXh0ZW5zaW9uczxicj4mZ3Q7IHRvPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJz
cDsgc3VwcG9ydCB0aGVzZSBraW5kcyBvZiBjb25zdHJhaW50cyB1bmRlciB0aGUgY29udHJvbCBv
ZiBHZW5lcmFsaXplZDxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1QTFMgKEdNUExTKS48YnI+
Jmd0Ozxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0OyBBIFVSTCBmb3IgdGhpcyBJbnRlcm5ldC1EcmFm
dCBpczo8YnI+Jmd0OyBodHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1p
ZXRmLWNjYW1wLWdtcGxzLWdlbmVyYWwtPGJyPiZndDsgY29uc3RyYWludHMtb3NwZi10ZS0wMi50
eHQ8YnI+Jmd0Ozxicj4mZ3Q7IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkg
YW5vbnltb3VzIEZUUCBhdDo8YnI+Jmd0OyBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJh
ZnRzLzxicj4mZ3Q7PGJyPiZndDsgVGhpcyBJbnRlcm5ldC1EcmFmdCBjYW4gYmUgcmV0cmlldmVk
IGF0Ojxicj4mZ3Q7IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0
Zi1jY2FtcC1nbXBscy1nZW5lcmFsLTxicj4mZ3Q7IGNvbnN0cmFpbnRzLW9zcGYtdGUtMDIudHh0
PGJyPiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188
YnI+Jmd0OyBDQ0FNUCBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyBDQ0FNUEBpZXRmLm9yZzxicj4mZ3Q7
IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY2NhbXA8YnI+Jmd0OyBfX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4mZ3Q7IENDQU1Q
IG1haWxpbmcgbGlzdDxicj4mZ3Q7IENDQU1QQGlldGYub3JnPGJyPiZndDsgaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jY2FtcDwvc3Bhbj48c3BhbiBzdHlsZT0nY29sb3I6
YmxhY2snPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rp
dj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48
L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2JvZHk+PC9odG1sPg==

------_=_NextPart_001_01CC7F4D.5308DA1B--

From loa@pi.nu  Fri Sep 30 06:47:12 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7770421F8678; Fri, 30 Sep 2011 06:47:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.654
X-Spam-Level: 
X-Spam-Status: No, score=-102.654 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhywisqcPRVU; Fri, 30 Sep 2011 06:47:12 -0700 (PDT)
Received: from mail.pi.nu (mail.pi.nu [194.71.127.148]) by ietfa.amsl.com (Postfix) with ESMTP id 5101321F8610; Fri, 30 Sep 2011 06:47:11 -0700 (PDT)
Received: from [192.168.1.64] (81-236-221-144-no93.tbcn.telia.com [81.236.221.144]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: loa@pi.nu) by mail.pi.nu (Postfix) with ESMTPSA id A5F1A2A8002; Fri, 30 Sep 2011 15:50:02 +0200 (CEST)
Message-ID: <4E85C90A.5090705@pi.nu>
Date: Fri, 30 Sep 2011 15:50:02 +0200
From: Loa Andersson 
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20110922 Thunderbird/7.0
MIME-Version: 1.0
To: "mpls@ietf.org" 
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: CCAMP , pwe3@ietf.org, "rtg-ads@tools.ietf.org" 
Subject: [CCAMP] first set of mpls-tp documents completed
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Sep 2011 13:47:12 -0000

Working Group(s),

late yesterday we passed an important Milestone; I did not realize
it until some time after it happened, maybe since the milstone
is not even documented in the WG charter.

The working group chairs and our responsible AD have for some time
worked with what we have called "the first set of MPLS-TP documents".

That set includes includes 20 documents and we have had more than
40 editors/authors active.

The set has two defining criteria:

- it should be implementable
- it should cover what ITU-T needs to reference in their MPLS-TP
   Recommendations

What happened last night was that , more less as part of a normal
business day, we requested publication of the last document on that set!
This completes the working groups effort with these documents; chairs,
document shepherds and authors may have to assist the IESG and the
RFC Editor in their job, but the working group job is done!

We also have further MPLS-TP documents to progress, so while recognizing
the mile stone, it is easy to find new documents to review and comment
on; please do so!

I'd like to take take this opportunity, and I'm sure that my co-chairs 
and ADs join me, to congratulate and thank the working groups, the 40+ 
authors, everyone that reviewed and commented on the documents.

We have done a good job and made progress!

/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 pierre.peloso@alcatel-lucent.com  Fri Sep 30 07:36:29 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA95A21F8BE5 for ; Fri, 30 Sep 2011 07:36:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.767
X-Spam-Level: 
X-Spam-Status: No, score=-5.767 tagged_above=-999 required=5 tests=[AWL=0.482,  BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWxjGgS3l90h for ; Fri, 30 Sep 2011 07:36:28 -0700 (PDT)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 789A821F8B8C for ; Fri, 30 Sep 2011 07:36:27 -0700 (PDT)
Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p8UEcpvY028778 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 30 Sep 2011 16:39:10 +0200
Received: from FRMRSSXCHMBSA1.dc-m.alcatel-lucent.com ([135.120.45.34]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 30 Sep 2011 16:39:03 +0200
From: "PELOSO, PIERRE (PIERRE)" 
To: Leeyoung , "ccamp@ietf.org" 
Date: Fri, 30 Sep 2011 16:39:02 +0200
Thread-Topic: [CCAMP] I-D	Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
Thread-Index: AQHMfO94tnV8wbm4z0mVmmskErrIZJVhuEzAgAQ4/3A=
Message-ID: 
References: <20110915194751.1118.92540.idtracker@ietfa.amsl.com> <7AEB3D6833318045B4AE71C2C87E8E171816B709@DFWEML501-MBX.china.huawei.com>  <7AEB3D6833318045B4AE71C2C87E8E171817CE25@DFWEML501-MBX.china.huawei.com>
In-Reply-To: <7AEB3D6833318045B4AE71C2C87E8E171817CE25@DFWEML501-MBX.china.huawei.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
acceptlanguage: fr-FR, en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80
Subject: Re: [CCAMP] I-D	Action:	draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Sep 2011 14:36:29 -0000

Hi Young,=20

I understand the content of your answer, but I'm not satisfied with it.
My concern deals with providing a unique reading/interpretation of the OSPF=
-TE extensions.
We would like to make sure that any implementation complying to the drafts =
would provide the same LSAs when applied to the same network.
With this perspective in mind, we wish to get drafts with sufficient docume=
ntation to make sure the LSA design process to be depicted, by design rules=
.

Hence the content of your answer leaving me the "opportunity to do as I wis=
h", is not pleasing me, I would rather have strict rules, and discussions w=
ith the WG on the design of those.
That is why a first design rule, we could agree on is: to gather the Resour=
ce Block Information TLVs inside a dedicated LSA, possibly with a dedicated=
 top-level TLV (which in my mind allows to enforce this design rule).

Regards,

- Pierre

-----Message d'origine-----
De : Leeyoung [mailto:leeyoung@huawei.com]=20
Envoy=E9 : mercredi 28 septembre 2011 00:06
=C0 : PELOSO, PIERRE (PIERRE); ccamp@ietf.org
Objet : RE: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-=
ospf-06.txt

Hi Pierre,=20

Please see-inline for my reply to your first point.=20

Regards,
Young

-----Original Message-----
From: PELOSO, PIERRE (PIERRE) [mailto:pierre.peloso@alcatel-lucent.com]
Sent: Tuesday, September 27, 2011 3:28 AM
To: Leeyoung; ccamp@ietf.org
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility=
-ospf-06.txt

Hi Young, and CCAMPers,

I was off the mailing lists for the last two weeks and being back I notice =
a lot of exchanges, which I'm very glad of.
I've also noticed many drafts have been updated.
Concerning this specific draft-ietf-ccamp-wson-signal-compatibility-ospf-06=
, I wanted to comment section 3.
Back in Quebec, I expressed my point of view (shared with Cyril, Julien and=
 Giovanni) that current drafts were lacking guidance regarding the way to d=
esign LSAs that were to depict an WSON node with OEOs.
This section 3 provides additional material to help designing the LSA.
I would like to know whether authors are willing to pursue further in this =
direction, which is to my mind a real corner stone, that would help everyon=
e agree on a solution.
A first point could concern the Resource Block Information (reminder:  ::=3D ([]   ):
     We all agree that these information are static, that we should not rep=
licate this TLV whatever the number not the layout of OEO boards of a given=
 type.
Then, we could dedicate a specific independant flooding entity. This would =
be defined once for all, and that would not leave room to different interpr=
etations.
What about this first point?

YOUNG>> If I understand you correctly, what you are saying is since the Res=
ource Block Info sub-TLV is very static in nature, advertisement of this su=
b-TLV should be treated differently from the rest of static-TLVs (which may=
 change over time). Is this what you are saying?

If my interpretation of your comment is correct,=20

- The current mechanism allows what you want: Please see the first paragrap=
h in Section 3.2
   "In the highly unlikely event that a WSON sub-TLV by itself would
   result in an LSA exceeding the MTU, all five WSON specific sub-TLVs
   in this document provide mechanisms that allow them to be subdivided
   into smaller sub-TLVs that can be sent in separate OSPF TE LSAs."

According to this clause, you can separate the Resource Block Info Sub-TLV =
as the sole entry defined in the Optical Node property TLV in a separate TE=
 LSA from the rest if you will. Nothing prevents this particular way of pac=
kaging. (Isn't this what you meant "a specific independent flooding entity"=
?)=20

- Please let me know if this explanation satisfies you. Thanks --- Young

Regards,

Pierre

-----Message d'origine-----
De : ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] De la part de L=
eeyoung Envoy=E9 : jeudi 15 septembre 2011 21:59 =C0 : ccamp@ietf.org Objet=
 : Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-=
06.txt

Hi all,

After 05 version publication, Acee provided a number of valuable comments a=
nd suggestions. This revision (06) reflects those changes. Please note the =
following updates:

- Change the title of the draft to "GMPLS OSPF Enhancement..." from "OSPF E=
nhancement..." to make sure the changes apply to the GMPLS OSPF rather than=
 the base OSPF.=20

- Add specific OSPF procedures on how sub-TLVs are packaged per [RFC3630] a=
nd editorial change including avoiding "multiple instances of TE LSA" to "m=
ultiple TE LSAs".=20

Your comments are always appreciated. Thanks.

Best Regards.
Young


-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of i=
nternet-drafts@ietf.org
Sent: Thursday, September 15, 2011 2:48 PM
To: i-d-announce@ietf.org
Cc: ccamp@ietf.org
Subject: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-osp=
f-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Common Control and Measurement Plane =
Working Group of the IETF.

	Title           : GMPLS OSPF Enhancement for Signal and Network Element Co=
mpatibility for Wavelength Switched Optical Networks
	Author(s)       : Young Lee
                          Greg M. Bernstein
	Filename        : draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
	Pages           : 14
	Date            : 2011-09-15

   This document provides GMPLS OSPF routing enhancements to support
   signal compatibility constraints associated with WSON network
   elements. These routing enhancements are required in common optical
   or hybrid electro-optical networks where not all of the optical
   signals in the network are compatible with all network elements
   participating in the network.

   This compatibility constraint model is applicable to common optical
   or hybrid electro optical systems such as OEO switches, regenerators,
   and wavelength converters since such systems can be limited to
   processing only certain types of WSON signals.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compatibil=
ity-ospf-06.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compatibili=
ty-ospf-06.txt
_______________________________________________
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 db3546@att.com  Fri Sep 30 08:14:14 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F395521F8C68 for ; Fri, 30 Sep 2011 08:14:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level: 
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32ar2LDQC2OX for ; Fri, 30 Sep 2011 08:14:13 -0700 (PDT)
Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 5695821F8C65 for ; Fri, 30 Sep 2011 08:14:13 -0700 (PDT)
X-Env-Sender: db3546@att.com
X-Msg-Ref: server-15.tower-120.messagelabs.com!1317395825!41018910!1
X-Originating-IP: [144.160.20.145]
X-StarScan-Version: 6.3.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 26982 invoked from network); 30 Sep 2011 15:17:06 -0000
Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-15.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Sep 2011 15:17:06 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p8UFHWh6027565 for ; Fri, 30 Sep 2011 11:17:32 -0400
Received: from MISOUT7MSGHUB9A.ITServices.sbc.com (misout7msghub9a.itservices.sbc.com [144.151.223.62]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p8UFHTnD027481 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 30 Sep 2011 11:17:30 -0400
Received: from MISOUT7MSGUSR9O.ITServices.sbc.com ([169.254.6.215]) by MISOUT7MSGHUB9A.ITServices.sbc.com ([144.151.223.62]) with mapi id 14.01.0289.001; Fri, 30 Sep 2011 11:17:01 -0400
From: "BRUNGARD, DEBORAH A" 
To: "ccamp@ietf.org" 
Thread-Topic: WG Last Call on draft-ietf-ccamp-assoc-info
Thread-Index: Acx/hADaRIcLxxImR96723Q2pUfC/Q==
Date: Fri, 30 Sep 2011 15:17:01 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.16.234.231]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [CCAMP] WG Last Call on draft-ietf-ccamp-assoc-info
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Sep 2011 15:14:14 -0000

All,

This starts a two-week working group last call on draft-ietf-ccamp-assoc-in=
fo.

This working group last call ends Oct. 14th. Please send your comments to t=
he CCAMP mailing list.

Deborah (and Lou)


From Jonathan.Hardwick@metaswitch.com  Fri Sep 30 09:12:36 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5443F21F8C4C for ; Fri, 30 Sep 2011 09:12:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.739
X-Spam-Level: 
X-Spam-Status: No, score=-2.739 tagged_above=-999 required=5 tests=[AWL=-0.140, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q89fgYM7hQAr for ; Fri, 30 Sep 2011 09:12:35 -0700 (PDT)
Received: from enficsets2.metaswitch.com (enficsets2.metaswitch.com [192.91.191.39]) by ietfa.amsl.com (Postfix) with ESMTP id 9A03C21F8C48 for ; Fri, 30 Sep 2011 09:12:35 -0700 (PDT)
Received: from ENFIRHMBX1.datcon.co.uk (172.18.74.36) by enficsets2.metaswitch.com (172.18.4.22) with Microsoft SMTP Server (TLS) id 14.1.339.1; Fri, 30 Sep 2011 17:15:28 +0100
Received: from ENFICSMBX1.datcon.co.uk ([fe80::d5d5:c683:a3be:3a19]) by ENFIRHMBX1.datcon.co.uk ([fe80::b06d:4d13:5f63:3715%19]) with mapi id 14.01.0323.003; Fri, 30 Sep 2011 17:15:29 +0100
From: Jonathan Hardwick 
To: labn - Lou Berger , CCAMP 
Thread-Topic: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG documents
Thread-Index: AQHMffwxGv+NlgVKTk+tKHLOesdgg5VmG/dw
Date: Fri, 30 Sep 2011 16:15:28 +0000
Message-ID: <09CE6C3BE5E1EA40B987BF5F25D8DDBA208DF136@ENFICSMBX1.datcon.co.uk>
References: <4E834C0D.5030800@labn.net>
In-Reply-To: <4E834C0D.5030800@labn.net>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [172.18.72.13]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG	documents
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Sep 2011 16:12:36 -0000

Yes - support both.

-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of L=
ou Berger
Sent: 28 September 2011 17:32
To: CCAMP
Subject: [CCAMP] Poll on making G.709 Routing and Signaling drafts WG docum=
ents

This message starts a two week poll on making the documents listed below
ccamp working group documents.  Please send a mail to the mailing list
indicating "yes/support to both" or "no/do not support either".  Of
course, you may also support one but not the other.  (We will assume
that you support/object to both if you don't specify.)

If indicating no, please state your technical reservations with the
document.

The documents being polled are:
http://tools.ietf.org/html/draft-ceccarelli-ccamp-gmpls-ospf-g709-07
http://tools.ietf.org/html/draft-zhang-ccamp-gmpls-evolving-g709-09

The poll ends Wednesday October 12.

Please also bear in mind that WG adoption does not signify that work is
complete on the documents or that the technical details are fixed, but
rather that further development of the documents will take place based
on WG process.

Much thanks,
Lou (and Deborah)
_______________________________________________
CCAMP mailing list
CCAMP@ietf.org
https://www.ietf.org/mailman/listinfo/ccamp

From leeyoung@huawei.com  Fri Sep 30 14:13:19 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1F921F8B6D for ; Fri, 30 Sep 2011 14:13:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.561
X-Spam-Level: 
X-Spam-Status: No, score=-6.561 tagged_above=-999 required=5 tests=[AWL=0.038,  BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dkZ3H40DqlkN for ; Fri, 30 Sep 2011 14:13:18 -0700 (PDT)
Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6B121F8B6B for ; Fri, 30 Sep 2011 14:13:18 -0700 (PDT)
Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSC00KUNTR06R@usaga02-in.huawei.com> for ccamp@ietf.org; Fri, 30 Sep 2011 16:16:12 -0500 (CDT)
Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug  8 2006)) with ESMTPS id <0LSC00KSYTQSDJ@usaga02-in.huawei.com> for ccamp@ietf.org; Fri, 30 Sep 2011 16:16:12 -0500 (CDT)
Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 30 Sep 2011 14:16:02 -0700
Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by dfweml403-hub.china.huawei.com ([10.193.5.151]) with mapi id 14.01.0270.001; Fri, 30 Sep 2011 14:16:00 -0700
Date: Fri, 30 Sep 2011 21:16:00 +0000
From: Leeyoung 
In-reply-to: 
X-Originating-IP: [10.47.150.202]
To: "PELOSO, PIERRE (PIERRE)" , "ccamp@ietf.org" 
Message-id: <7AEB3D6833318045B4AE71C2C87E8E171817E6BF@DFWEML501-MBX.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-language: en-US
Content-transfer-encoding: quoted-printable
Accept-Language: en-US, zh-CN
Thread-topic: [CCAMP] I-D	Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
Thread-index: AQHMfO94tnV8wbm4z0mVmmskErrIZJVhuEzAgAQ4/3CAAHRdUA==
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: <20110915194751.1118.92540.idtracker@ietfa.amsl.com> <7AEB3D6833318045B4AE71C2C87E8E171816B709@DFWEML501-MBX.china.huawei.com>  <7AEB3D6833318045B4AE71C2C87E8E171817CE25@DFWEML501-MBX.china.huawei.com> 
Subject: Re: [CCAMP] I-D	Action:	draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Sep 2011 21:13:19 -0000

Hi Pierre,

I got your point. Let me ask you this question. In the current GMPLS OSPF T=
E Link TLV are defined under Opaque TE LSA with the following attributes:

- TE Metric
- max B/W
- max reservable b/w
- unreserved b/w
- Admin Group
- Link Protection Type
- SRLG
- ISCD
- etc.

And these are a mixture of static and dynamic information and yet they are =
assembled together as one TE Link TLV. For instance the ISCD is quite simil=
ar to Resource Block Info in that it does not change often unless there are=
 new elements added in the node or configuration changes and yet it is pack=
aged together with other dynamic information.=20

Why?=20

There are many ways to keep static/unchanged information from being flooded=
. Only the Link Type and Link ID which are mandatory in the TE Link TLV per=
 RFC3630. All other sub-TLV are optional and may occur at most once (when t=
here are enough changes from the previous period that deserve an update) an=
d need not be included in the TE Link TLV when there is no need for updatin=
g.=20

I really don't see the need for a separate top-level TLV and/or a separate =
LSA for the Resource Block information.=20

Regards,
Young



-----Original Message-----
From: PELOSO, PIERRE (PIERRE) [mailto:pierre.peloso@alcatel-lucent.com]=20
Sent: Friday, September 30, 2011 9:39 AM
To: Leeyoung; ccamp@ietf.org
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility=
-ospf-06.txt

Hi Young,=20

I understand the content of your answer, but I'm not satisfied with it.
My concern deals with providing a unique reading/interpretation of the OSPF=
-TE extensions.
We would like to make sure that any implementation complying to the drafts =
would provide the same LSAs when applied to the same network.
With this perspective in mind, we wish to get drafts with sufficient docume=
ntation to make sure the LSA design process to be depicted, by design rules=
.

Hence the content of your answer leaving me the "opportunity to do as I wis=
h", is not pleasing me, I would rather have strict rules, and discussions w=
ith the WG on the design of those.
That is why a first design rule, we could agree on is: to gather the Resour=
ce Block Information TLVs inside a dedicated LSA, possibly with a dedicated=
 top-level TLV (which in my mind allows to enforce this design rule).

Regards,

- Pierre

-----Message d'origine-----
De : Leeyoung [mailto:leeyoung@huawei.com]=20
Envoy=E9 : mercredi 28 septembre 2011 00:06
=C0 : PELOSO, PIERRE (PIERRE); ccamp@ietf.org
Objet : RE: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-=
ospf-06.txt

Hi Pierre,=20

Please see-inline for my reply to your first point.=20

Regards,
Young

-----Original Message-----
From: PELOSO, PIERRE (PIERRE) [mailto:pierre.peloso@alcatel-lucent.com]
Sent: Tuesday, September 27, 2011 3:28 AM
To: Leeyoung; ccamp@ietf.org
Subject: RE: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility=
-ospf-06.txt

Hi Young, and CCAMPers,

I was off the mailing lists for the last two weeks and being back I notice =
a lot of exchanges, which I'm very glad of.
I've also noticed many drafts have been updated.
Concerning this specific draft-ietf-ccamp-wson-signal-compatibility-ospf-06=
, I wanted to comment section 3.
Back in Quebec, I expressed my point of view (shared with Cyril, Julien and=
 Giovanni) that current drafts were lacking guidance regarding the way to d=
esign LSAs that were to depict an WSON node with OEOs.
This section 3 provides additional material to help designing the LSA.
I would like to know whether authors are willing to pursue further in this =
direction, which is to my mind a real corner stone, that would help everyon=
e agree on a solution.
A first point could concern the Resource Block Information (reminder:  ::=3D ([]   ):
     We all agree that these information are static, that we should not rep=
licate this TLV whatever the number not the layout of OEO boards of a given=
 type.
Then, we could dedicate a specific independant flooding entity. This would =
be defined once for all, and that would not leave room to different interpr=
etations.
What about this first point?

YOUNG>> If I understand you correctly, what you are saying is since the Res=
ource Block Info sub-TLV is very static in nature, advertisement of this su=
b-TLV should be treated differently from the rest of static-TLVs (which may=
 change over time). Is this what you are saying?

If my interpretation of your comment is correct,=20

- The current mechanism allows what you want: Please see the first paragrap=
h in Section 3.2
   "In the highly unlikely event that a WSON sub-TLV by itself would
   result in an LSA exceeding the MTU, all five WSON specific sub-TLVs
   in this document provide mechanisms that allow them to be subdivided
   into smaller sub-TLVs that can be sent in separate OSPF TE LSAs."

According to this clause, you can separate the Resource Block Info Sub-TLV =
as the sole entry defined in the Optical Node property TLV in a separate TE=
 LSA from the rest if you will. Nothing prevents this particular way of pac=
kaging. (Isn't this what you meant "a specific independent flooding entity"=
?)=20

- Please let me know if this explanation satisfies you. Thanks --- Young

Regards,

Pierre

-----Message d'origine-----
De : ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] De la part de L=
eeyoung Envoy=E9 : jeudi 15 septembre 2011 21:59 =C0 : ccamp@ietf.org Objet=
 : Re: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-ospf-=
06.txt

Hi all,

After 05 version publication, Acee provided a number of valuable comments a=
nd suggestions. This revision (06) reflects those changes. Please note the =
following updates:

- Change the title of the draft to "GMPLS OSPF Enhancement..." from "OSPF E=
nhancement..." to make sure the changes apply to the GMPLS OSPF rather than=
 the base OSPF.=20

- Add specific OSPF procedures on how sub-TLVs are packaged per [RFC3630] a=
nd editorial change including avoiding "multiple instances of TE LSA" to "m=
ultiple TE LSAs".=20

Your comments are always appreciated. Thanks.

Best Regards.
Young


-----Original Message-----
From: ccamp-bounces@ietf.org [mailto:ccamp-bounces@ietf.org] On Behalf Of i=
nternet-drafts@ietf.org
Sent: Thursday, September 15, 2011 2:48 PM
To: i-d-announce@ietf.org
Cc: ccamp@ietf.org
Subject: [CCAMP] I-D Action: draft-ietf-ccamp-wson-signal-compatibility-osp=
f-06.txt

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies. This draft is a work item of the Common Control and Measurement Plane =
Working Group of the IETF.

	Title           : GMPLS OSPF Enhancement for Signal and Network Element Co=
mpatibility for Wavelength Switched Optical Networks
	Author(s)       : Young Lee
                          Greg M. Bernstein
	Filename        : draft-ietf-ccamp-wson-signal-compatibility-ospf-06.txt
	Pages           : 14
	Date            : 2011-09-15

   This document provides GMPLS OSPF routing enhancements to support
   signal compatibility constraints associated with WSON network
   elements. These routing enhancements are required in common optical
   or hybrid electro-optical networks where not all of the optical
   signals in the network are compatible with all network elements
   participating in the network.

   This compatibility constraint model is applicable to common optical
   or hybrid electro optical systems such as OEO switches, regenerators,
   and wavelength converters since such systems can be limited to
   processing only certain types of WSON signals.



A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compatibil=
ity-ospf-06.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-ccamp-wson-signal-compatibili=
ty-ospf-06.txt
_______________________________________________
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 leeyoung@huawei.com  Fri Sep 30 15:19:12 2011
Return-Path: 
X-Original-To: ccamp@ietfa.amsl.com
Delivered-To: ccamp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB6BB21F86A0 for ; Fri, 30 Sep 2011 15:19:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.029
X-Spam-Level: 
X-Spam-Status: No, score=-5.029 tagged_above=-999 required=5 tests=[AWL=-1.495, BAYES_00=-2.599, FRT_LOLITA1=1.865, J_CHICKENPOX_36=0.6, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P+l0fDB0M1-k for ; Fri, 30 Sep 2011 15:19:11 -0700 (PDT)
Received: from usaga02-in.huawei.com (usaga02-in.huawei.com [206.16.17.70]) by ietfa.amsl.com (Postfix) with ESMTP id 97F4621F84C1 for ; Fri, 30 Sep 2011 15:19:11 -0700 (PDT)
Received: from huawei.com (localhost [127.0.0.1]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LSC00K2ZWST6R@usaga02-in.huawei.com> for ccamp@ietf.org; Fri, 30 Sep 2011 17:22:06 -0500 (CDT)
Received: from dfweml201-edg.china.huawei.com ([172.18.4.104]) by usaga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug  8 2006)) with ESMTPS id <0LSC00KI0WSTDJ@usaga02-in.huawei.com> for ccamp@ietf.org; Fri, 30 Sep 2011 17:22:05 -0500 (CDT)
Received: from DFWEML404-HUB.china.huawei.com (10.193.5.203) by dfweml201-edg.china.huawei.com (172.18.9.107) with Microsoft SMTP Server (TLS) id 14.1.270.1; Fri, 30 Sep 2011 15:21:58 -0700
Received: from DFWEML501-MBX.china.huawei.com ([fe80::c52a:9e19:87eb:4531]) by dfweml404-hub.china.huawei.com ([10.193.5.203]) with mapi id 14.01.0270.001; Fri, 30 Sep 2011 15:21:56 -0700
Date: Fri, 30 Sep 2011 22:21:56 +0000
From: Leeyoung 
In-reply-to: 
X-Originating-IP: [10.47.150.202]
To: "Margaria, Cyril (NSN - DE/Munich)" , "ccamp@ietf.org" 
Message-id: <7AEB3D6833318045B4AE71C2C87E8E171817E6FC@DFWEML501-MBX.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-language: en-US
Content-transfer-encoding: 7BIT
Accept-Language: en-US, zh-CN
Thread-topic: [CCAMP] FW:  I-D Action: draft-ietf-ccamp-rwa-wson-encode-12
Thread-index: AQHMfoddI8UZc4rSmkKiUNV/WUrhf5Vme6yQ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
References: <7AEB3D6833318045B4AE71C2C87E8E17181669D3@DFWEML501-MBX.china.huawei.com>  A <7AEB3D6833318045B4AE71C2C87E8E171817E09A@DFWEML501-MBX.china.huawei.com> 
Subject: Re: [CCAMP] FW:  I-D Action: draft-ietf-ccamp-rwa-wson-encode-12
X-BeenThere: ccamp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for the CCAMP working group 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 30 Sep 2011 22:19:12 -0000

Hi Cyril,

Regarding your point #3, the main motivation for bitmap representation of label (wavelength) was based on standard/well-defined/global contiguous ID. That is, once you know the lowest level of wavelength grid in the label/wavelength set, you can derive the rest easily based on the "globally" identifiable wavelength grid (per RFC6205 and G.694.1/2). 

Here the RB ID is local and arbitrary and as such I have a little hesitation to expand the Action field for bit map representation. If we define RB ID ={1,2,3,..N}, then it would be able to extract, for instance, the next RB ID after 1 is obviously 2. But we don't know if such is the case always. The operator can give any scheme for RB ID and it is strictly a local matter so assuming "monotonous increase" (as the example) may not work. 

What do you think? 

We still have point #2 (32 bits vs 16 bits) open --- I haven't seen enough implementers input on this point yet. 

I concur with you on point #6 (in your response to Pierre), is there any issue left on point #6? 

Best Regards,
Young

-----Original Message-----
From: Margaria, Cyril (NSN - DE/Munich) [mailto:cyril.margaria@nsn.com] 
Sent: Thursday, September 29, 2011 4:08 AM
To: Leeyoung; ccamp@ietf.org
Subject: RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-wson-encode-12

Hi Young, 

For point 1,4,5,7 its ok.
I updated the title BTW 

I clarified some points inline. 

Best Regards
Cyril

> -----Original Message-----
> From: ext Leeyoung [mailto:leeyoung@huawei.com]
> Sent: Wednesday, September 28, 2011 11:47 PM
> To: Margaria, Cyril (NSN - DE/Munich); ccamp@ietf.org
> Subject: RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-info-12.txt
> 
> Hi Cyril,
> 
> Thanks for your review and suggestions. It looks like there are two
> issues pending: Point #2 and #3.
> We can close the rest of the points you raised with the action
> specified in-line. Please let me know otherwise.
> 
> Thanks.
> 
> Young
> 
> 
> -----Original Message-----
> From: Margaria, Cyril (NSN - DE/Munich)
[mailto:cyril.margaria@nsn.com]
> Sent: Monday, September 26, 2011 10:59 AM
> To: Leeyoung; ccamp@ietf.org
> Subject: RE: [CCAMP] FW: I-D Action: draft-ietf-ccamp-rwa-info-12.txt
> 
> 
> Hi,
> I have the following comments on  draft-ietf-ccamp-rwa-wson-encode-12
> after it being updated and in light of the WG discussions:




> 2) section 3.1. Resource Block Set Field:
> RB Identifier: as stated in section "3. Resources, Blocks, Sets, and
> the
> Resource Pool", Resources and Resource Blocks are related to interface
> cards.
> 
> GMPLS implementations are using 32-bit unnumbered interface IDs to
> identify GMPLS links and also the corresponding physical resources.
> OEO devices and, in the context of this document, resource or resource
> group can also be identified by 32-bit unnumbered interface IDs.
> 
>  From an implementation point of view, having 16-bit resource block
IDs
> have several drawbacks because of the following points:
>   a) Mapping exists between physical resource and unnumbered interface
> IDs, this mapping is generally known by management system,
>       introducing a different ID space is not optimal (new mapping
> needed);
>   b) Those OEOs might be used as links in a multi-node model, thus
> being
> identified by a 32-bit unnumbered interface IDs, introducing another
> space is also not optimal.
> 
> Therefore, it would be better if the resource block IDs were 32-bit
> interface IDs (to be unique within the node, not because they are
> representing links in this document).
> 
> YOUNG>> The only motivation why we used 16 bits for RB ID is to reduce
> the space. And I think this is an internal link so it is not the real
> interface per se and thus there is no need to keep track of the state
> of RB ID like other legitimate interfaces. I don't think there is a
> substantial implementation issue here whether we use 16 bits or 32
> bits, but if there is a strong support to use 32 bit ID over 16 bit
ID,
> I am fine with this. Lou and Deborah, do you have any suggestion on
> this issue? Or other implementers?

CYRIL>> The most bothering point of having 16 bit is for management
system
 that needs to learn a new mapping between control plane resources and 
 management plane resource. Having 32 bit ids make this more transparent
to 
 management applications. 

> 
> 
> 3) section 3.1. Resource Block Set Field Why not define a bit set
> action, similar to the label set?
> 
> YOUNG>> Are you referring the Label Set encoding as follows from
draft-
> ietf-ccamp-general-constraint-encode-05.txt
> 
>   0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      | Action|    Num Labels         |          Length               |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |                          Base Label                           |
>      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>      |     Additional fields as necessary per action                 |
> 
> 
> The current Resource Block Set Field is encoded as follows:
> 
>   0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |    Action     |E|C| Reserved  |        Length
|
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |     RB Identifier 1           |        RB Identifier 2
|
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       :                               :
:
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |     RB Identifier n-1         |        RB Identifier n
|
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> YOUNG>> Can you be specific about your suggestion? Are you concerned
> about label being 32 bit vs RB identifier being 16 bits? --- then this
> is basically related to your point #2.

CYRIL>> No, this is independent to the length of the RB identifier

> If you have other concerns,
> please spell them out (e.g., action field (4 bits vs 8 bits), etc..)
> The Num Labels field is necessary when we are indicating bit maps
> (Action = 4), which Is not needed for Resource Block Set; E bit is not
> necessary when we adopt 32 bit RB ID, but C bit is needed to indicate
> the connectivity nature of Resource Pool Accessibility.
> 
> YOUNG>> Would the following encoding is what you are envisioning? If
> not, please suggest in detail.
> 
>   0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       | Action|C|                     |        Length
|
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                         RB Identifier 1
|
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       :                               :
:
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                         RB Identifier n
|
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


My suggestion is to add the following text and format : 
Action : 
  1 - Reserved
  3 - Reserved	
  4 - Bitmap Set

When Action is 4 (bitmap set) the format of the Resource block set is
the following (with 16 bit ids):
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Action = 4 |E|C| Reserved  |        Length                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     base RB Identifier        |Bit Map(Lowest numerical RB Id)|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                               :                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Bit Map(Highest numerical RB Id)                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Each bit in the bit map represents a
   particular RB Id with a value of 1/0 indicating whether the RB id is
   in the set or not. Bit position zero represents the lowest RB Id and
   corresponds to the base RB identifier, while each succeeding bit
position
   represents the next RB identifier in numerical order. 

For example 

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Action = 4 |E|C| Reserved  |        Length                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     base RB Identifier =10    |1|0|1|1|0|0|0|0|1|0|1|1|0|1|0|1|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|0|0|0|1|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|0|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Correspond to the following set of RB ids:
10,12,13,18,20,21,23,25,30

With 32 bits ids : 
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Action = 4 |E|C| Reserved  |        Length                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     base RB Identifier                                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Bit Map Word #1 (Lowest numerical RB Id)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      :                               :                               :
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Bit Map Word #N(Highest numerical RB Id)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The previous example will be : 
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Action = 4 |E|C| Reserved  |        Length                 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     base RB Identifier =10                                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|0|1|1|0|0|0|0|1|0|1|1|0|1|0|1|0|0|0|0|1|0|0|0|0|0|0|0|0|0|0|0|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

General constraints encoding introduce a bitmap set for a set of IDs 
for efficiency, this can apply to each encoding representing a set of
ids where you
can define a group/calculate ID = baseID + n.
 
> 
> 
> 6) section 5.1. Resource Block Information Sub-TLV
> 
> Having an Input Modulation Type List sub-sub-TLV containing a list of
> modulation formats (with an input-output bit) and an Output Modulation
> Type List sub-sub-TLV containing a list of modulation formats (with an
> input-output bit) seems redundant because the bit I already indicates
> if
> it is an output or input modulation format.
> 
> Having a single Modulation Type List sub-sub-TLV is providing the same
> information with an efficient encoding, a single sub-sub-TLV type
> should
> be used.
> 
> Same reasoning apply to the FEC Type List Sub-Sub-TLV.
> 
> YOUNG>> I guess what you are suggesting is as follows:
> 
>     0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                     RB Set Field
|
>       :
:
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |I|E|                      Reserved
|
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |           Modulation Type List Sub-Sub-TLV  (opt)
|
>       :
:
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |           FEC Type List Sub-Sub-TLV    (opt)
|
>       :
:
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |         Input Client Signal Type Sub-Sub-TLV      (opt)
|
>       :
:
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |         Input Bit Rate Range List  Sub-Sub-TLV (opt)
|
>       :
:
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |         Processing Capabilities List Sub-Sub-TLV (opt)
|
>       :
:
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
> YOUNG>> If that's what you suggested, that is fine with me. If that is
> that case, I will revise with this figure in the revision. (Closure)

This is what I mean, the logic of "if no egress FEC/Modulation is
present, 
this is implicitly the same as the ingress FEC/Modulation".  

This proposal do not change the format of the FEC and Modulation.