From owner-ccamp@ops.ietf.org Sat Apr 01 23:02:46 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FPtna-00072E-R5 for ccamp-archive@ietf.org; Sat, 01 Apr 2006 23:02:46 -0500 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FPtd9-0000cd-PV for ccamp-archive@ietf.org; Sat, 01 Apr 2006 22:51:59 -0500 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FPt8v-0008Uo-9Y for ccamp-archive@ietf.org; Sat, 01 Apr 2006 22:20:46 -0500 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FPt03-000688-1g for ccamp-data@psg.com; Sun, 02 Apr 2006 03:11:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [64.208.49.56] (helo=smail3.alcatel.fr) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FPt02-00067t-5Q for ccamp@ops.ietf.org; Sun, 02 Apr 2006 03:11:34 +0000 Received: from frmail30.netfr.alcatel.fr (frmail30.netfr.alcatel.fr [155.132.182.163]) by smail3.alcatel.fr (ALCANET/NETFR) with ESMTP id k323BU9Y025865; Sun, 2 Apr 2006 05:11:30 +0200 Received: from [172.17.242.128] ([172.17.242.128]) by frmail30.netfr.alcatel.fr (Lotus Domino Release 5.0.9a) with ESMTP id 2006040205112864:1266 ; Sun, 2 Apr 2006 05:11:28 +0200 Message-ID: <442F40E4.3090709@alcatel.fr> Date: Sun, 02 Apr 2006 05:11:32 +0200 From: Emmanuel.Dotaro@alcatel.fr Reply-To: Emmanuel.Dotaro@alcatel.fr Organization: Alcatel CTO/R&I User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: Progressing docs References: <20060331100203.G31807@kummer.juniper.net> In-Reply-To: <20060331100203.G31807@kummer.juniper.net> X-MIMETrack: Itemize by SMTP Server on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 04/02/2006 05:11:28, Serialize by Router on FRMAIL30/FR/ALCATEL(Release 5.0.9a |January 7, 2002) at 04/02/2006 05:11:30, Serialize complete at 04/02/2006 05:11:30 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: -1.1 (-) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a yes to all Kireeti Kompella wrote: > Hi All, > > This is to double-check support *on the list* for the following I-Ds > to go to WG docs: > > a) MPLS-GMPLS interworking > draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt > b) "hierarchy bis" > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > c) Call Support > draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt > d) Ethernet TSpec > draft-dimitri-mef-ethernet-traffic-parameters-00.txt > e) OSPF-TE MIB > draft-otani-ccamp-gmpls-ospf-mib-02.txt > > Please say for each if you think it should/should not become a WG doc. > > My previous email was in error: the "excellent" support was for the > migration doc. Just to be clear, we'll double-check all these docs. > > Kireeti. > ------- > > From owner-ccamp@ops.ietf.org Sun Apr 02 15:44:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQ8V1-0006vz-52 for ccamp-archive@ietf.org; Sun, 02 Apr 2006 15:44:35 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQ8Ux-0006Dz-Gn for ccamp-archive@ietf.org; Sun, 02 Apr 2006 15:44:35 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQ8Oy-00032d-Dx for ccamp-data@psg.com; Sun, 02 Apr 2006 19:38:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQ8Ox-00032B-9z for ccamp@ops.ietf.org; Sun, 02 Apr 2006 19:38:19 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k32JcFud015433; Sun, 2 Apr 2006 21:38:15 +0200 In-Reply-To: <20060331100203.G31807@kummer.juniper.net> To: Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: Re: Progressing docs MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Sun, 2 Apr 2006 21:37:53 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 04/02/2006 21:38:14, Serialize complete at 04/02/2006 21:38:14 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 > Hi All, > > This is to double-check support *on the list* for the following I-Ds > to go to WG docs: > > a) MPLS-GMPLS interworking > draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt yes > b) "hierarchy bis" > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt abstain > c) Call Support > draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt yes > d) Ethernet TSpec > draft-dimitri-mef-ethernet-traffic-parameters-00.txt yes > e) OSPF-TE MIB > draft-otani-ccamp-gmpls-ospf-mib-02.txt yes > Please say for each if you think it should/should not become a WG doc. > > My previous email was in error: the "excellent" support was for the > migration doc. Just to be clear, we'll double-check all these docs. From owner-ccamp@ops.ietf.org Sun Apr 02 18:09:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQAlA-0004KT-Jg for ccamp-archive@ietf.org; Sun, 02 Apr 2006 18:09:24 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQAl9-0004ZU-1O for ccamp-archive@ietf.org; Sun, 02 Apr 2006 18:09:24 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQAhN-000BYH-7F for ccamp-data@psg.com; Sun, 02 Apr 2006 22:05:29 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.49] (helo=mail2.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQAhL-000BY2-Ne for ccamp@ops.ietf.org; Sun, 02 Apr 2006 22:05:27 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1FQAhG-0002KC-00 for ccamp@ops.ietf.org; Sun, 02 Apr 2006 23:05:22 +0100 Received: from Puppy ([217.158.132.85] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 2 Apr 2006 23:05:55 +0100 Message-ID: <045201c656a1$930ddb00$1e849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Document status of draft-ietf-ccamp-gmpls-addressing Date: Sun, 2 Apr 2006 22:56:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 02 Apr 2006 22:05:56.0390 (UTC) FILETIME=[9DCE3C60:01C656A1] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Hi, Having spoken to the ADs, we are agreed that this draft is Standards Track. We will move forward on that basis. Thanks. Adrian From owner-ccamp@ops.ietf.org Mon Apr 03 00:25:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQGdZ-0001jX-TI for ccamp-archive@ietf.org; Mon, 03 Apr 2006 00:25:57 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQGdY-0003jV-5g for ccamp-archive@ietf.org; Mon, 03 Apr 2006 00:25:57 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQGOa-0003Ik-J9 for ccamp-data@psg.com; Mon, 03 Apr 2006 04:10:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [129.60.39.102] (helo=tama5.ecl.ntt.co.jp) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQGOZ-0003IW-4i for ccamp@ops.ietf.org; Mon, 03 Apr 2006 04:10:27 +0000 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k334AJVT015882; Mon, 3 Apr 2006 13:10:19 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k334AI5E009443; Mon, 3 Apr 2006 13:10:18 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k334AHij015731; Mon, 3 Apr 2006 13:10:17 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k334AHVP011777; Mon, 3 Apr 2006 13:10:17 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k334AGxa018547; Mon, 3 Apr 2006 13:10:17 +0900 (JST) Received: from imf.m.ecl.ntt.co.jp (imf.m.ecl.ntt.co.jp [129.60.5.230]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k334AGbX018544; Mon, 3 Apr 2006 13:10:16 +0900 (JST) Received: from TAKEDA_PANA.lab.ntt.co.jp ([129.60.80.92]) by imf.m.ecl.ntt.co.jp (8.13.4/8.13.4) with ESMTP id k334AF4k006539; Mon, 3 Apr 2006 13:10:16 +0900 (JST) Message-Id: <5.1.1.9.2.20060403130841.06acfe88@imf.m.ecl.ntt.co.jp> X-Sender: tt043@imf.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr3 Date: Mon, 03 Apr 2006 13:10:37 +0900 To: Kireeti Kompella , ccamp@ops.ietf.org From: Tomonori TAKEDA Subject: Re: Progressing docs In-Reply-To: <20060331100203.G31807@kummer.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Yes to all Tomonori At 10:12 06/03/31 -0800, Kireeti Kompella wrote: >Hi All, > >This is to double-check support *on the list* for the following I-Ds to go >to WG docs: > >a) MPLS-GMPLS interworking > draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt >b) "hierarchy bis" > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt >c) Call Support > draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt >d) Ethernet TSpec > draft-dimitri-mef-ethernet-traffic-parameters-00.txt >e) OSPF-TE MIB > draft-otani-ccamp-gmpls-ospf-mib-02.txt > >Please say for each if you think it should/should not become a WG doc. > >My previous email was in error: the "excellent" support was for the >migration doc. Just to be clear, we'll double-check all these docs. > >Kireeti. >------- From owner-ccamp@ops.ietf.org Mon Apr 03 05:54:00 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQLl2-0001Ph-0u for ccamp-archive@ietf.org; Mon, 03 Apr 2006 05:54:00 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQLky-0001G9-Fl for ccamp-archive@ietf.org; Mon, 03 Apr 2006 05:54:00 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQLbV-000L3c-Nz for ccamp-data@psg.com; Mon, 03 Apr 2006 09:44:09 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [129.60.39.102] (helo=tama5.ecl.ntt.co.jp) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQLbU-000L3N-Fb for ccamp@ops.ietf.org; Mon, 03 Apr 2006 09:44:08 +0000 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k339i5Wi021621; Mon, 3 Apr 2006 18:44:05 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k339i4Q3006287; Mon, 3 Apr 2006 18:44:04 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k339i4aB002210; Mon, 3 Apr 2006 18:44:04 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k339i3qu011352; Mon, 3 Apr 2006 18:44:03 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k339i3rF011903; Mon, 3 Apr 2006 18:44:03 +0900 (JST) Received: from imc.m.ecl.ntt.co.jp (imc.m.ecl.ntt.co.jp [129.60.5.227]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k339i3hY011898; Mon, 3 Apr 2006 18:44:03 +0900 (JST) Received: from [127.0.0.1] ([129.60.80.125]) by imc.m.ecl.ntt.co.jp (8.13.4/8.13.4) with ESMTP id k339hrvx025751; Mon, 3 Apr 2006 18:44:02 +0900 (JST) Message-ID: <4430EE57.7030709@lab.ntt.co.jp> Date: Mon, 03 Apr 2006 18:43:51 +0900 From: Kohei Shiomoto User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.11) Gecko/20050728 X-Accept-Language: ja, en-us, en MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: Progressing docs References: <20060331100203.G31807@kummer.juniper.net> In-Reply-To: <20060331100203.G31807@kummer.juniper.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Yes to all Kohei Kireeti Kompella wrote: > Hi All, > > This is to double-check support *on the list* for the following I-Ds to > go to WG docs: > > a) MPLS-GMPLS interworking > draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt > b) "hierarchy bis" > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > c) Call Support > draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt > d) Ethernet TSpec > draft-dimitri-mef-ethernet-traffic-parameters-00.txt > e) OSPF-TE MIB > draft-otani-ccamp-gmpls-ospf-mib-02.txt > > Please say for each if you think it should/should not become a WG doc. > > My previous email was in error: the "excellent" support was for the > migration doc. Just to be clear, we'll double-check all these docs. > > Kireeti. > ------- > > > From owner-ccamp@ops.ietf.org Mon Apr 03 10:18:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQPt3-0001Oh-Dr for ccamp-archive@ietf.org; Mon, 03 Apr 2006 10:18:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQPt2-0004gL-3t for ccamp-archive@ietf.org; Mon, 03 Apr 2006 10:18:33 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQPhp-000AvJ-JU for ccamp-data@psg.com; Mon, 03 Apr 2006 14:06:57 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.1 Received: from [205.177.121.2] (helo=ns1.cpanel.btnaccess.com) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQPho-000Auf-J1 for ccamp@ops.ietf.org; Mon, 03 Apr 2006 14:06:56 +0000 Received: from [65.213.193.47] (helo=Isovaio08) by ns1.cpanel.btnaccess.com with esmtpa (Exim 4.52) id 1FQPhm-0003wA-9b; Mon, 03 Apr 2006 10:06:54 -0400 From: "Rajiv Papneja" To: "'Kireeti Kompella'" , Subject: RE: Progressing docs Date: Mon, 3 Apr 2006 10:06:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcZU72LpaYMR3/UUQMaHCfxQYT0+PACOGiKg X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 In-Reply-To: <20060331100203.G31807@kummer.juniper.net> X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ns1.cpanel.btnaccess.com X-AntiAbuse: Original Domain - ops.ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - isocore.com X-Source: X-Source-Args: X-Source-Dir: Sender: owner-ccamp@ops.ietf.org Precedence: bulk Message-Id: X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Yes to all. /R > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Friday, March 31, 2006 1:13 PM > To: ccamp@ops.ietf.org > Subject: Progressing docs > > Hi All, > > This is to double-check support *on the list* for the following I-Ds > to go to WG docs: > > a) MPLS-GMPLS interworking > draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt > b) "hierarchy bis" > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > c) Call Support > draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt > d) Ethernet TSpec > draft-dimitri-mef-ethernet-traffic-parameters-00.txt > e) OSPF-TE MIB > draft-otani-ccamp-gmpls-ospf-mib-02.txt > > Please say for each if you think it should/should not become a WG doc. > > My previous email was in error: the "excellent" support was for the > migration doc. Just to be clear, we'll double-check all these docs. > > Kireeti. > ------- > > From owner-ccamp@ops.ietf.org Mon Apr 03 10:26:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQQ13-0006mF-Bq for ccamp-archive@ietf.org; Mon, 03 Apr 2006 10:26:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQQ11-0004p3-VZ for ccamp-archive@ietf.org; Mon, 03 Apr 2006 10:26:49 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQPqk-000BZa-BL for ccamp-data@psg.com; Mon, 03 Apr 2006 14:16:10 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [70.158.43.219] (helo=jera.movaz.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQPqh-000BZF-7g for ccamp@ops.ietf.org; Mon, 03 Apr 2006 14:16:07 +0000 Received: from ib (unknown [172.16.24.125]) by jera.movaz.com (Postfix) with SMTP id 549141B510; Mon, 3 Apr 2006 10:13:27 -0400 (EDT) Message-ID: <00a501c65729$202e78f0$7d1810ac@movaz.com> From: "Igor Bryskin" To: "Kireeti Kompella" , References: <20060331100203.G31807@kummer.juniper.net> Subject: Re: Progressing docs Date: Mon, 3 Apr 2006 10:15:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Yes to all. Igor ----- Original Message ----- From: "Kireeti Kompella" To: Sent: Friday, March 31, 2006 2:12 PM Subject: Progressing docs > Hi All, > > This is to double-check support *on the list* for the following I-Ds > to go to WG docs: > > a) MPLS-GMPLS interworking > draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt > b) "hierarchy bis" > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > c) Call Support > draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt > d) Ethernet TSpec > draft-dimitri-mef-ethernet-traffic-parameters-00.txt > e) OSPF-TE MIB > draft-otani-ccamp-gmpls-ospf-mib-02.txt > > Please say for each if you think it should/should not become a WG doc. > > My previous email was in error: the "excellent" support was for the > migration doc. Just to be clear, we'll double-check all these docs. > > Kireeti. > ------- > From owner-ccamp@ops.ietf.org Mon Apr 03 11:25:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQQvz-0000wv-Un for ccamp-archive@ietf.org; Mon, 03 Apr 2006 11:25:39 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQQvz-00077U-EC for ccamp-archive@ietf.org; Mon, 03 Apr 2006 11:25:39 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQQmH-000FpL-AU for ccamp-data@psg.com; Mon, 03 Apr 2006 15:15:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [129.60.39.102] (helo=tama5.ecl.ntt.co.jp) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQQmG-000Fow-0l for ccamp@ops.ietf.org; Mon, 03 Apr 2006 15:15:36 +0000 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k33FFYd6005557 for ; Tue, 4 Apr 2006 00:15:34 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k33FFX35005872 for ; Tue, 4 Apr 2006 00:15:33 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k33FFXcD022725 for ; Tue, 4 Apr 2006 00:15:33 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k33FFWGv029304 for ; Tue, 4 Apr 2006 00:15:33 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k33FFWJt011711 for ; Tue, 4 Apr 2006 00:15:32 +0900 (JST) Received: from imb.m.ecl.ntt.co.jp (imb.m.ecl.ntt.co.jp [129.60.5.226]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k33FFWYC011708 for ; Tue, 4 Apr 2006 00:15:32 +0900 (JST) Received: from FM-9C7FCECE6469.lab.ntt.co.jp ([129.60.15.201]) by imb.m.ecl.ntt.co.jp (8.13.4/8.13.4) with ESMTP id k33FFU3U020930 for ; Tue, 4 Apr 2006 00:15:31 +0900 (JST) Message-Id: <6.0.0.20.2.20060404002315.04ba56a0@imb.m.ecl.ntt.co.jp> X-Sender: ii004@imb.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 6J Date: Tue, 04 Apr 2006 00:23:43 +0900 To: From: "inoue.ichiro@lab.ntt.co.jp" Subject: Re: Progressing docs In-Reply-To: <00a501c65729$202e78f0$7d1810ac@movaz.com> References: <20060331100203.G31807@kummer.juniper.net> <00a501c65729$202e78f0$7d1810ac@movaz.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Hi, Yes to all. Ichiro At 23:15 06/04/03, Igor Bryskin wrote: >Yes to all. > >Igor > >----- Original Message ----- >From: "Kireeti Kompella" >To: >Sent: Friday, March 31, 2006 2:12 PM >Subject: Progressing docs > > >> Hi All, >> >> This is to double-check support *on the list* for the following I-Ds >> to go to WG docs: >> >> a) MPLS-GMPLS interworking >> draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt >> b) "hierarchy bis" >> draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt >> c) Call Support >> draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt >> d) Ethernet TSpec >> draft-dimitri-mef-ethernet-traffic-parameters-00.txt >> e) OSPF-TE MIB >> draft-otani-ccamp-gmpls-ospf-mib-02.txt >> >> Please say for each if you think it should/should not become a WG doc. >> >> My previous email was in error: the "excellent" support was for the >> migration doc. Just to be clear, we'll double-check all these docs. >> >> Kireeti. >> ------- >> From owner-ccamp@ops.ietf.org Mon Apr 03 11:40:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQRAR-0000an-CP for ccamp-archive@ietf.org; Mon, 03 Apr 2006 11:40:35 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQRAP-0007gC-2E for ccamp-archive@ietf.org; Mon, 03 Apr 2006 11:40:35 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQQyu-000Gx3-TT for ccamp-data@psg.com; Mon, 03 Apr 2006 15:28:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [57.66.76.5] (helo=huawei.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQQyt-000Gwo-7S for ccamp@ops.ietf.org; Mon, 03 Apr 2006 15:28:39 +0000 Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IX5009FBJMX8G@lhrga01-in.huawei.com> for ccamp@ops.ietf.org; Mon, 03 Apr 2006 16:13:45 +0100 (BST) Received: from IBM4307EA0CEF3 ([217.167.116.208]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IX500FMZJMXAS@lhrga01-in.huawei.com> for ccamp@ops.ietf.org; Mon, 03 Apr 2006 16:13:45 +0100 (BST) Date: Mon, 03 Apr 2006 23:28:31 +0800 From: Tina TSOU Subject: Re: Progressing docs To: ccamp@ops.ietf.org Message-id: <00a901c65733$43f9c9b0$d074a7d9@IBM4307EA0CEF3> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20060331100203.G31807@kummer.juniper.net> <00a501c65729$202e78f0$7d1810ac@movaz.com> <6.0.0.20.2.20060404002315.04ba56a0@imb.m.ecl.ntt.co.jp> Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Hi, Yes to all. Tina ----- Original Message ----- From: To: Sent: Monday, April 03, 2006 11:23 PM Subject: Re: Progressing docs > Hi, > > Yes to all. > > Ichiro > > At 23:15 06/04/03, Igor Bryskin wrote: > >Yes to all. > > > >Igor > > > >----- Original Message ----- > >From: "Kireeti Kompella" > >To: > >Sent: Friday, March 31, 2006 2:12 PM > >Subject: Progressing docs > > > > > >> Hi All, > >> > >> This is to double-check support *on the list* for the following I-Ds > >> to go to WG docs: > >> > >> a) MPLS-GMPLS interworking > >> draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt > >> b) "hierarchy bis" > >> draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > >> c) Call Support > >> draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt > >> d) Ethernet TSpec > >> draft-dimitri-mef-ethernet-traffic-parameters-00.txt > >> e) OSPF-TE MIB > >> draft-otani-ccamp-gmpls-ospf-mib-02.txt > >> > >> Please say for each if you think it should/should not become a WG doc. > >> > >> My previous email was in error: the "excellent" support was for the > >> migration doc. Just to be clear, we'll double-check all these docs. > >> > >> Kireeti. > >> ------- > >> > > > From owner-ccamp@ops.ietf.org Mon Apr 03 17:46:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQWsU-0000vS-7I for ccamp-archive@ietf.org; Mon, 03 Apr 2006 17:46:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQWsS-0006yT-S3 for ccamp-archive@ietf.org; Mon, 03 Apr 2006 17:46:26 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQWnb-000INq-7M for ccamp-data@psg.com; Mon, 03 Apr 2006 21:41:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQWna-000INf-JP for ccamp@ops.ietf.org; Mon, 03 Apr 2006 21:41:22 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 03 Apr 2006 14:41:22 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,159,1141632000"; d="scan'208"; a="25088213:sNHT22414060" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k33LfLWc011536; Mon, 3 Apr 2006 17:41:21 -0400 (EDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 3 Apr 2006 17:41:21 -0400 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 Subject: RE: Progressing docs Date: Mon, 3 Apr 2006 17:41:20 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Progressing docs Thread-Index: AcZU7s/GVDIPvcfVRnq3QcZV/BCHrgCT61Vg From: "Zafar Ali \(zali\)" To: "Kireeti Kompella" , X-OriginalArrivalTime: 03 Apr 2006 21:41:21.0491 (UTC) FILETIME=[591C4230:01C65767] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Kireeti Kompella > Sent: Friday, March 31, 2006 1:13 PM > To: ccamp@ops.ietf.org > Subject: Progressing docs >=20 > Hi All, >=20 > This is to double-check support *on the list* for the=20 > following I-Ds to go to WG docs: >=20 > a) MPLS-GMPLS interworking > draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt Yes, but I have some comments about the ID merger, that I am discussing w/ Authors off-line.=20 > b) "hierarchy bis" > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt Yes,=20 > c) Call Support > draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt Yes,=20 > d) Ethernet TSpec > draft-dimitri-mef-ethernet-traffic-parameters-00.txt Yes,=20 > e) OSPF-TE MIB > draft-otani-ccamp-gmpls-ospf-mib-02.txt >=20 Yes,=20 > Please say for each if you think it should/should not become a WG doc. >=20 > My previous email was in error: the "excellent" support was=20 > for the migration doc. Just to be clear, we'll double-check=20 > all these docs. >=20 > Kireeti. > ------- >=20 From owner-ccamp@ops.ietf.org Mon Apr 03 18:19:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQXOS-0000kq-7W for ccamp-archive@ietf.org; Mon, 03 Apr 2006 18:19:28 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQXOP-0000du-Rv for ccamp-archive@ietf.org; Mon, 03 Apr 2006 18:19:28 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQXKp-000KkO-0n for ccamp-data@psg.com; Mon, 03 Apr 2006 22:15:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,MIME_BASE64_NO_NAME,SPF_PASS autolearn=no version=3.1.1 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQXKn-000Kk8-2j for ccamp@ops.ietf.org; Mon, 03 Apr 2006 22:15:41 +0000 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 03 Apr 2006 18:15:41 -0400 X-IronPort-AV: i="4.03,159,1141621200"; d="scan'208"; a="85613408:sNHT32039208" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k33MFSVW021906; Mon, 3 Apr 2006 18:15:40 -0400 (EDT) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 3 Apr 2006 18:15:33 -0400 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 Subject: RE: Progressing docs Date: Mon, 3 Apr 2006 18:15:25 -0400 Message-ID: <3C292CE901FC634693F24FB2DDC4D332014EEE6C@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Progressing docs Thread-Index: AcZU7s+Ny4wVPvycRI+YwaQ5yqkm/gCfRsZQ From: "Rich Bradford \(rbradfor\)" To: "Kireeti Kompella" , X-OriginalArrivalTime: 03 Apr 2006 22:15:33.0470 (UTC) FILETIME=[202F67E0:01C6576C] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBvd25lci1jY2FtcEBvcHMuaWV0 Zi5vcmcgW21haWx0bzpvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBL aXJlZXRpIEtvbXBlbGxhDQo+IFNlbnQ6IEZyaWRheSwgTWFyY2ggMzEsIDIwMDYgMToxMyBQTQ0K PiBUbzogY2NhbXBAb3BzLmlldGYub3JnDQo+IFN1YmplY3Q6IFByb2dyZXNzaW5nIGRvY3MNCj4g DQo+IEhpIEFsbCwNCj4gDQo+IFRoaXMgaXMgdG8gZG91YmxlLWNoZWNrIHN1cHBvcnQgKm9uIHRo ZSBsaXN0KiBmb3IgdGhlIGZvbGxvd2luZyBJLURzDQo+IHRvIGdvIHRvIFdHIGRvY3M6DQo+IA0K PiBhKSBNUExTLUdNUExTIGludGVyd29ya2luZw0KPiAgCWRyYWZ0LXNoaW9tb3RvLWNjYW1wLW1w bHMtZ21wbHMtaW50ZXJ3b3JrLWZtd2stMDEudHh0DQpZZXMuDQo+IGIpICJoaWVyYXJjaHkgYmlz Ig0KPiAgCWRyYWZ0LXNoaW9tb3RvLWNjYW1wLWxzcC1oaWVyYXJjaHktYmlzLTAxLnR4dA0KQWJz dGFpbi4NCj4gYykgQ2FsbCBTdXBwb3J0DQo+ICAJZHJhZnQtcGFwYWRpbWl0cmlvdS1jY2FtcC1n bXBscy1yc3ZwLXRlLWNhbGwtMDAudHh0DQpZZXMNCj4gZCkgRXRoZXJuZXQgVFNwZWMNCj4gIAlk cmFmdC1kaW1pdHJpLW1lZi1ldGhlcm5ldC10cmFmZmljLXBhcmFtZXRlcnMtMDAudHh0DQpZZXMN Cj4gZSkgT1NQRi1URSBNSUINCj4gIAlkcmFmdC1vdGFuaS1jY2FtcC1nbXBscy1vc3BmLW1pYi0w Mi50eHQNClllcw0KPiANCj4gUGxlYXNlIHNheSBmb3IgZWFjaCBpZiB5b3UgdGhpbmsgaXQgc2hv dWxkL3Nob3VsZCBub3QgYmVjb21lIGEgV0cgZG9jLg0KPiANCj4gTXkgcHJldmlvdXMgZW1haWwg d2FzIGluIGVycm9yOiB0aGUgImV4Y2VsbGVudCIgc3VwcG9ydCB3YXMgZm9yIHRoZQ0KPiBtaWdy YXRpb24gZG9jLiAgSnVzdCB0byBiZSBjbGVhciwgd2UnbGwgZG91YmxlLWNoZWNrIGFsbCB0aGVz ZSBkb2NzLg0KPiANCj4gS2lyZWV0aS4NCj4gLS0tLS0tLQ0K From owner-ccamp@ops.ietf.org Tue Apr 04 09:34:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQlg3-0005e8-8C for ccamp-archive@ietf.org; Tue, 04 Apr 2006 09:34:35 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQlg1-0005no-Fd for ccamp-archive@ietf.org; Tue, 04 Apr 2006 09:34:35 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQlSi-000Czi-Mj for ccamp-data@psg.com; Tue, 04 Apr 2006 13:20:48 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [129.60.39.102] (helo=tama5.ecl.ntt.co.jp) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQlSh-000CyD-CI for ccamp@ops.ietf.org; Tue, 04 Apr 2006 13:20:47 +0000 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k34DKjuL010559; Tue, 4 Apr 2006 22:20:45 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k34DKird021406; Tue, 4 Apr 2006 22:20:44 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k34DKhfu017210; Tue, 4 Apr 2006 22:20:43 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (eclscan3.m.ecl.ntt.co.jp [129.60.5.69]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k34DKh6Y000013; Tue, 4 Apr 2006 22:20:43 +0900 (JST) Received: from eclscan3.m.ecl.ntt.co.jp (localhost [127.0.0.1]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k34DKgEO023258; Tue, 4 Apr 2006 22:20:42 +0900 (JST) Received: from imb.m.ecl.ntt.co.jp (imb.m.ecl.ntt.co.jp [129.60.5.226]) by eclscan3.m.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k34DKgID023255; Tue, 4 Apr 2006 22:20:42 +0900 (JST) Received: from [192.168.1.3] ([129.60.15.201]) by imb.m.ecl.ntt.co.jp (8.13.4/8.13.4) with ESMTP id k34DKgnt014299; Tue, 4 Apr 2006 22:20:42 +0900 (JST) Date: Tue, 04 Apr 2006 22:20:39 +0900 From: Eiji Oki To: Kireeti Kompella Subject: Re: Progressing docs Cc: ccamp@ops.ietf.org In-Reply-To: <20060331100203.G31807@kummer.juniper.net> References: <20060331100203.G31807@kummer.juniper.net> Message-Id: <20060404222015.061E.OKI.EIJI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Becky! ver. 2.21.03 [ja] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Hi, Yes to all. Eiji On Fri, 31 Mar 2006 10:12:31 -0800 (PST) Kireeti Kompella wrote: > Hi All, > > This is to double-check support *on the list* for the following I-Ds > to go to WG docs: > > a) MPLS-GMPLS interworking > draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt > b) "hierarchy bis" > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > c) Call Support > draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt > d) Ethernet TSpec > draft-dimitri-mef-ethernet-traffic-parameters-00.txt > e) OSPF-TE MIB > draft-otani-ccamp-gmpls-ospf-mib-02.txt > > Please say for each if you think it should/should not become a WG doc. > > My previous email was in error: the "excellent" support was for the > migration doc. Just to be clear, we'll double-check all these docs. > > Kireeti. > ------- From owner-ccamp@ops.ietf.org Tue Apr 04 09:42:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQlo3-0002JB-SK for ccamp-archive@ietf.org; Tue, 04 Apr 2006 09:42:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQlo2-00060s-GR for ccamp-archive@ietf.org; Tue, 04 Apr 2006 09:42:51 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQlhG-000EFK-Lm for ccamp-data@psg.com; Tue, 04 Apr 2006 13:35:50 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [47.129.242.56] (helo=zcars04e.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQlhF-000ECT-K6 for ccamp@ops.ietf.org; Tue, 04 Apr 2006 13:35:49 +0000 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k34DVEQ10477 for ; Tue, 4 Apr 2006 09:31:14 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Progressing docs Date: Tue, 4 Apr 2006 09:35:43 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA407A42F61@zrtphxm2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Progressing docs Thread-Index: AcZU75e7R3rhRC1UQqS2ltsAJSecCQC/PwIA From: "Don Fedyk" To: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Hi Kireeti Yes to all, Don=20 > -----Original Message----- > Hi All, >=20 > This is to double-check support *on the list* for the following I-Ds=20 > to go to WG docs: >=20 > a) MPLS-GMPLS interworking > draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt > b) "hierarchy bis" > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > c) Call Support > draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt > d) Ethernet TSpec > draft-dimitri-mef-ethernet-traffic-parameters-00.txt > e) OSPF-TE MIB > draft-otani-ccamp-gmpls-ospf-mib-02.txt >=20 > Please say for each if you think it should/should not become a WG doc. >=20 > My previous email was in error: the "excellent" support was for the=20 > migration doc. Just to be clear, we'll double-check all these docs. >=20 > Kireeti. > ------- >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Tue Apr 04 17:53:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FQtNP-0006ne-Vs for ccamp-archive@ietf.org; Tue, 04 Apr 2006 17:47:51 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FQtKr-0002Op-KS for ccamp-archive@ietf.org; Tue, 04 Apr 2006 17:45:14 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQtCU-0007NJ-NH for ccamp-data@psg.com; Tue, 04 Apr 2006 21:36:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FQtCU-0007N4-05 for ccamp@ops.ietf.org; Tue, 04 Apr 2006 21:36:34 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k34LaX1Z076589 for ; Tue, 4 Apr 2006 14:36:33 -0700 (PDT) (envelope-from arthi@juniper.net) Received: from zircon.juniper.net (zircon.juniper.net [172.17.28.113]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k34LaW538617; Tue, 4 Apr 2006 14:36:32 -0700 (PDT) (envelope-from arthi@juniper.net) Date: Tue, 4 Apr 2006 14:36:32 -0700 (PDT) From: Arthi Ayyangar To: Kireeti Kompella cc: ccamp@ops.ietf.org Subject: Re: Progressing docs In-Reply-To: <20060331100203.G31807@kummer.juniper.net> Message-ID: <20060404143421.M63242@zircon.juniper.net> References: <20060331100203.G31807@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 > a) MPLS-GMPLS interworking > draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt ----> yes. > b) "hierarchy bis" > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt ----> yes. > c) Call Support > draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt ----> yes. > d) Ethernet TSpec > draft-dimitri-mef-ethernet-traffic-parameters-00.txt ---> yes. > e) OSPF-TE MIB > draft-otani-ccamp-gmpls-ospf-mib-02.txt -----> yes. thanks, -arthi > Please say for each if you think it should/should not become a WG doc. > > My previous email was in error: the "excellent" support was for the migration > doc. Just to be clear, we'll double-check all these docs. > > Kireeti. > ------- > From owner-ccamp@ops.ietf.org Wed Apr 05 02:24:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR1Rc-0004si-96 for ccamp-archive@ietf.org; Wed, 05 Apr 2006 02:24:44 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR1O0-00062x-Be for ccamp-archive@ietf.org; Wed, 05 Apr 2006 02:21:02 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FR1Ee-0001Tp-QE for ccamp-data@psg.com; Wed, 05 Apr 2006 06:11:20 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [207.17.137.119] (helo=borg.juniper.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FR1Ee-0001Tc-5N for ccamp@ops.ietf.org; Wed, 05 Apr 2006 06:11:20 +0000 Received: from unknown (HELO alpha.jnpr.net) ([172.24.18.126]) by borg.juniper.net with ESMTP; 04 Apr 2006 23:11:20 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.03,165,1141632000"; d="scan'208"; a="541097423:sNHT31539264" Received: from EmailHK1.jnpr.net ([172.27.128.41]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 4 Apr 2006 23:11:19 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: Progressing docs X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Wed, 5 Apr 2006 14:10:34 +0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Progressing docs Thread-Index: AcZU7tT8tShOz/PcRSWdm7b+2VC2bADiNFBW From: "Hidet Sugiyama" To: "Kireeti Kompella" , X-OriginalArrivalTime: 05 Apr 2006 06:11:19.0607 (UTC) FILETIME=[C16BFC70:01C65877] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Yes to all. -hidet ________________________________ From: owner-ccamp@ops.ietf.org $BBeM}(J Kireeti Kompella Sent: 2006/04/01 ($BEZ(J) 3:12 To: ccamp@ops.ietf.org Subject: Progressing docs Hi All, This is to double-check support *on the list* for the following I-Ds to go to WG docs: a) MPLS-GMPLS interworking draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt b) "hierarchy bis" draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt c) Call Support draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt d) Ethernet TSpec draft-dimitri-mef-ethernet-traffic-parameters-00.txt e) OSPF-TE MIB draft-otani-ccamp-gmpls-ospf-mib-02.txt Please say for each if you think it should/should not become a WG doc. My previous email was in error: the "excellent" support was for the migration doc. Just to be clear, we'll double-check all these docs. Kireeti. ------- From owner-ccamp@ops.ietf.org Wed Apr 05 06:55:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR5fq-0006tQ-I8 for ccamp-archive@ietf.org; Wed, 05 Apr 2006 06:55:42 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR5fo-0008IN-94 for ccamp-archive@ietf.org; Wed, 05 Apr 2006 06:55:42 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FR5VH-0000UD-HD for ccamp-data@psg.com; Wed, 05 Apr 2006 10:44:47 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1 Received: from [195.101.245.16] (helo=p-mail2.rd.francetelecom.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FR5VF-0000Tp-Qf for ccamp@ops.ietf.org; Wed, 05 Apr 2006 10:44:46 +0000 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 12:44:28 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Progressing docs Date: Wed, 5 Apr 2006 12:44:48 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Progressing docs Thread-Index: AcZU7zIwfdowxGaTSAOns2lu7cJQOQDrpqBw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Kireeti Kompella" , X-OriginalArrivalTime: 05 Apr 2006 10:44:28.0730 (UTC) FILETIME=[EA19B1A0:01C6589D] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Hi Kireeti, I support these 5 Ids as WG docs. Regards, JL=20 > -----Message d'origine----- > De : owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] De la part de Kireeti Kompella > Envoy=E9 : vendredi 31 mars 2006 20:13 > =C0 : ccamp@ops.ietf.org > Objet : Progressing docs >=20 > Hi All, >=20 > This is to double-check support *on the list* for the=20 > following I-Ds to go to WG docs: >=20 > a) MPLS-GMPLS interworking > draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt > b) "hierarchy bis" > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > c) Call Support > draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt > d) Ethernet TSpec > draft-dimitri-mef-ethernet-traffic-parameters-00.txt > e) OSPF-TE MIB > draft-otani-ccamp-gmpls-ospf-mib-02.txt >=20 > Please say for each if you think it should/should not become a WG doc. >=20 > My previous email was in error: the "excellent" support was=20 > for the migration doc. Just to be clear, we'll double-check=20 > all these docs. >=20 > Kireeti. > ------- >=20 >=20 From owner-ccamp@ops.ietf.org Wed Apr 05 07:16:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR5zx-0008QK-Dx for ccamp-archive@ietf.org; Wed, 05 Apr 2006 07:16:29 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR5zw-0001Zm-Tu for ccamp-archive@ietf.org; Wed, 05 Apr 2006 07:16:29 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FR5uJ-0003Cy-LY for ccamp-data@psg.com; Wed, 05 Apr 2006 11:10:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.49] (helo=mail2.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FR5uH-0003C9-JV for ccamp@ops.ietf.org; Wed, 05 Apr 2006 11:10:38 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1FR5uE-0005f2-00 for ccamp@ops.ietf.org; Wed, 05 Apr 2006 12:10:34 +0100 Received: from Puppy ([217.158.132.217] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Apr 2006 12:11:00 +0100 Message-ID: <000e01c658a1$933f0e80$d9849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'Kireeti Kompella'" , "Bill Fenner" , "Ross Callon" , "Scott Bradner" Subject: Proposed liaison to ITU-T on new RFCs Date: Wed, 5 Apr 2006 12:10:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 05 Apr 2006 11:11:01.0656 (UTC) FILETIME=[9F8EE980:01C658A1] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 2bf730a014b318fd3efd65b39b48818c In the spirit of continued communication with Study Group 15 of the ITU-T we need to send information about our recently published RFCs. The following is a draft liaison that I would like to send in time for their interim meeting in Kobe, Japan later this month. Comments please. Thanks, Adrian ===== To: ITU-T Study Group 15 From: IETF CCAMP working group Cc: IETF Routing Area Directors For: Information Subject: Recently published IETF RFCs relevant to GMPLS, Optical Transport Networks, and Packet Transport Networks The IETF's CCAMP working group is pleased to inform Study Group 15 of the ITU-T of the publication of several new RFCs that are relevant to the work that you are doing with optical and packet transport networks. Several of these RFCs received useful review and input from Study Group 15 participants for which CCAMP would like to express its thanks. RFC 4257 http://www.ietf.org/rfc/rfc4257.txt Title Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks Abstract Generalized Multi-Protocol Label Switching (GMPLS) is a suite of protocol extensions to MPLS to make it generally applicable, to include, for example, control of non packet-based switching, and particularly, optical switching. One consideration is to use GMPLS protocols to upgrade the control plane of optical transport networks. This document illustrates this process by describing those extensions to GMPLS protocols that are aimed at controlling Synchronous Digital Hierarchy (SDH) or Synchronous Optical Networking (SONET) networks. SDH/SONET networks make good examples of this process for a variety of reasons. This document highlights extensions to GMPLS-related routing protocols to disseminate information needed in transport path computation and network operations, together with (G)MPLS protocol extensions required for the provisioning of transport circuits. New capabilities that an GMPLS control plane would bring to SDH/SONET networks, such as new restoration methods and multi-layer circuit establishment, are also discussed. RFC 4258 http://www.ietf.org/rfc/rfc4258.txt Title Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON) Abstract The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting Time Division Multiplexing (TDM) connections including Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) and Optical Transport Networks (OTNs). This document concentrates on the routing requirements placed on the GMPLS suite of protocols in order to support the capabilities and functionalities of an Automatically Switched Optical Network (ASON) as defined by the ITU-T. RFC 4327 http://www.ietf.org/rfc/rfc4327.txt Title Link Management Protocol (LMP) Management Information Base (MIB) Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling the Link Management Protocol (LMP). RFC 4328 http://www.ietf.org/rfc/rfc4328.txt Title Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control Abstract This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling documents. It describes the technology- specific information needed to extend GMPLS signaling to control Optical Transport Networks (OTN); it also includes the so-called pre-OTN developments. RFC 4394 http://www.ietf.org/rfc/rfc4394.txt Title A Transport Network View of the Link Management Protocol (LMP) Abstract The Link Management Protocol (LMP) has been developed as part of the Generalized MPLS (GMPLS) protocol suite to manage Traffic Engineering (TE) resources and links. The GMPLS control plane (routing and signaling) uses TE links for establishing Label Switched Paths (LSPs). This memo describes the relationship of the LMP procedures to 'discovery' as defined in the International Telecommunication Union (ITU-T), and ongoing ITU-T work. This document provides an overview of LMP in the context of the ITU-T Automatically Switched Optical Networks (ASON) and transport network terminology and relates it to the ITU-T discovery work to promote a common understanding for progressing the work of IETF and ITU-T. RFC 4397 http://www.ietf.org/rfc/rfc4397.txt Title A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture Abstract Generalized Multiprotocol Label Switching (GMPLS) has been developed by the IETF to facilitate the establishment of Label Switched Paths (LSPs) in a variety of data plane technologies and across several architectural models. The ITU-T has specified an architecture for the control of Automatically Switched Optical Networks (ASON). This document provides a lexicography for the interpretation of GMPLS terminology within the context of the ASON architecture. It is important to note that GMPLS is applicable in a wider set of contexts than just ASON. The definitions presented in this document do not provide exclusive or complete interpretations of GMPLS concepts. This document simply allows the GMPLS terms to be applied within the ASON context. RFC 4426 http://www.ietf.org/rfc/rfc4426.txt Title Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification Abstract This document presents a functional description of the protocol extensions needed to support Generalized Multi-Protocol Label Switching (GMPLS)-based recovery (i.e., protection and restoration). Protocol specific formats and mechanisms will be described in companion documents. RFC 4427 http://www.ietf.org/rfc/rfc4427.txt Title Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) Abstract This document defines a common terminology for Generalized Multi- Protocol Label Switching (GMPLS)-based recovery mechanisms (i.e., protection and restoration). The terminology is independent of the underlying transport technologies covered by GMPLS. RFC 4428 http://www.ietf.org/rfc/rfc4428.txt Title Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) Abstract This document provides an analysis grid to evaluate, compare, and contrast the Generalized Multi-Protocol Label Switching (GMPLS) protocol suite capabilities with the recovery mechanisms currently proposed at the IETF CCAMP Working Group. A detailed analysis of each of the recovery phases is provided using the terminology defined in RFC 4427. This document focuses on transport plane survivability and recovery issues and not on control plane resilience and related aspects. All IETF RFCs can be downloaded for free from http://www.ietf.org/rfc.html The current work plan and progress status of the CCAMP working group can be viewed at http://www.ietf.org/html.charters/ccamp-charter.html The CCAMP working group welcomes questions and discussion about all of its work from individuals or organisations. The CCAMP mailing list is open to anyone. Details of subscription can be found on the CCAMP charter page. Regards, Adrian Farrel and Kireeti Kompella CCAMP working group chairs From owner-ccamp@ops.ietf.org Wed Apr 05 07:35:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR6IJ-0004r4-Ka for ccamp-archive@ietf.org; Wed, 05 Apr 2006 07:35:27 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR6II-0002Ak-CF for ccamp-archive@ietf.org; Wed, 05 Apr 2006 07:35:27 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FR6DF-0005B4-KA for ccamp-data@psg.com; Wed, 05 Apr 2006 11:30:13 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_00, RCVD_IN_WHOIS_INVALID autolearn=no version=3.1.1 Received: from [61.144.161.55] (helo=huawei.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FR6DE-00057x-5A for ccamp@ops.ietf.org; Wed, 05 Apr 2006 11:30:12 +0000 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IX800IU2YX7ID@szxga03-in.huawei.com> for ccamp@ops.ietf.org; Wed, 05 Apr 2006 19:36:43 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IX80099WYWBE5@szxga03-in.huawei.com> for ccamp@ops.ietf.org; Wed, 05 Apr 2006 19:36:43 +0800 (CST) Received: from l37133 ([10.70.76.208]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IX800F3HWM97L@szxml01-in.huawei.com>; Wed, 05 Apr 2006 18:46:57 +0800 (CST) Date: Wed, 05 Apr 2006 18:29:40 +0800 From: Dan Li Subject: Re: Progressing docs To: Kireeti Kompella , ccamp@ops.ietf.org Message-id: <00f001c6589b$d89f6de0$d04c460a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20060331100203.G31807@kummer.juniper.net> Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 See below. - Dan ----- Original Message ----- From: "Kireeti Kompella" To: Sent: Saturday, April 01, 2006 2:12 AM Subject: Progressing docs > Hi All, > > This is to double-check support *on the list* for the following I-Ds > to go to WG docs: > > a) MPLS-GMPLS interworking > draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt Yes > b) "hierarchy bis" > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt Yes > c) Call Support > draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt Yes > d) Ethernet TSpec > draft-dimitri-mef-ethernet-traffic-parameters-00.txt Yes > e) OSPF-TE MIB > draft-otani-ccamp-gmpls-ospf-mib-02.txt Yes > > Please say for each if you think it should/should not become a WG doc. > > My previous email was in error: the "excellent" support was for the > migration doc. Just to be clear, we'll double-check all these docs. > > Kireeti. > ------- > From owner-ccamp@ops.ietf.org Wed Apr 05 07:39:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR6M9-0006yN-Pf for ccamp-archive@ietf.org; Wed, 05 Apr 2006 07:39:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR6M9-0002Fb-3t for ccamp-archive@ietf.org; Wed, 05 Apr 2006 07:39:25 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FR6G8-0005VQ-S9 for ccamp-data@psg.com; Wed, 05 Apr 2006 11:33:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_WHOIS autolearn=no version=3.1.1 Received: from [216.82.241.195] (helo=mail121.messagelabs.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FR6G7-0005V9-Hg for ccamp@ops.ietf.org; Wed, 05 Apr 2006 11:33:11 +0000 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-14.tower-121.messagelabs.com!1144236612!8856068!28 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 27286 invoked from network); 5 Apr 2006 11:33:10 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-14.tower-121.messagelabs.com with SMTP; 5 Apr 2006 11:33:10 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 4426C9FE0014E636; Wed, 5 Apr 2006 07:33:10 -0400 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 Subject: RE: Proposed liaison to ITU-T on new RFCs Date: Wed, 5 Apr 2006 06:33:09 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC75FE@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <000e01c658a1$933f0e80$d9849ed9@Puppy> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Proposed liaison to ITU-T on new RFCs Thread-Index: AcZYoa6irtEFpxN7RfmnjUbfVL5dcwAAr8Hg From: "Ash, Gerald R \(Jerry\), ALABS" To: "Adrian Farrel" , Cc: "Ash, Gerald R \(Jerry\), ALABS" , "Kireeti Kompella" , "Bill Fenner" , "Ross Callon" , "Scott Bradner" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 501044f827b673024f6a4cb1d46e67d2 I like your subtle (hint, hint) approach. Jerry=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Wednesday, April 05, 2006 7:11 AM To: ccamp@ops.ietf.org Cc: 'Kireeti Kompella'; Bill Fenner; Ross Callon; Scott Bradner Subject: Proposed liaison to ITU-T on new RFCs In the spirit of continued communication with Study Group 15 of the ITU-T we need to send information about our recently published RFCs. The following is a draft liaison that I would like to send in time for their interim meeting in Kobe, Japan later this month. Comments please. Thanks, Adrian =3D=3D=3D=3D=3D To: ITU-T Study Group 15 From: IETF CCAMP working group Cc: IETF Routing Area Directors For: Information Subject: Recently published IETF RFCs relevant to GMPLS, Optical Transport Networks, and Packet Transport Networks The IETF's CCAMP working group is pleased to inform Study Group 15 of the ITU-T of the publication of several new RFCs that are relevant to the work that you are doing with optical and packet transport networks. Several of these RFCs received useful review and input from Study Group 15 participants for which CCAMP would like to express its thanks. RFC 4257 http://www.ietf.org/rfc/rfc4257.txt Title Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks Abstract Generalized Multi-Protocol Label Switching (GMPLS) is a suite of protocol extensions to MPLS to make it generally applicable, to include, for example, control of non packet-based switching, and particularly, optical switching. One consideration is to use GMPLS protocols to upgrade the control plane of optical transport networks. This document illustrates this process by describing those extensions to GMPLS protocols that are aimed at controlling Synchronous Digital Hierarchy (SDH) or Synchronous Optical Networking (SONET) networks. SDH/SONET networks make good examples of this process for a variety of reasons. This document highlights extensions to GMPLS-related routing protocols to disseminate information needed in transport path computation and network operations, together with (G)MPLS protocol extensions required for the provisioning of transport circuits. New capabilities that an GMPLS control plane would bring to SDH/SONET networks, such as new restoration methods and multi-layer circuit establishment, are also discussed. RFC 4258 http://www.ietf.org/rfc/rfc4258.txt Title Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON) Abstract The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting Time Division Multiplexing (TDM) connections including Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) and Optical Transport Networks (OTNs). This document concentrates on the routing requirements placed on the GMPLS suite of protocols in order to support the capabilities and functionalities of an Automatically Switched Optical Network (ASON) as defined by the ITU-T. RFC 4327 http://www.ietf.org/rfc/rfc4327.txt Title Link Management Protocol (LMP) Management Information Base (MIB) Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling the Link Management Protocol (LMP). RFC 4328 http://www.ietf.org/rfc/rfc4328.txt Title Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control Abstract This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling documents. It describes the technology- specific information needed to extend GMPLS signaling to control Optical Transport Networks (OTN); it also includes the so-called pre-OTN developments. RFC 4394 http://www.ietf.org/rfc/rfc4394.txt Title A Transport Network View of the Link Management Protocol (LMP) Abstract The Link Management Protocol (LMP) has been developed as part of the Generalized MPLS (GMPLS) protocol suite to manage Traffic Engineering (TE) resources and links. The GMPLS control plane (routing and signaling) uses TE links for establishing Label Switched Paths (LSPs). This memo describes the relationship of the LMP procedures to 'discovery' as defined in the International Telecommunication Union (ITU-T), and ongoing ITU-T work. This document provides an overview of LMP in the context of the ITU-T Automatically Switched Optical Networks (ASON) and transport network terminology and relates it to the ITU-T discovery work to promote a common understanding for progressing the work of IETF and ITU-T. RFC 4397 http://www.ietf.org/rfc/rfc4397.txt Title A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture Abstract Generalized Multiprotocol Label Switching (GMPLS) has been developed by the IETF to facilitate the establishment of Label Switched Paths (LSPs) in a variety of data plane technologies and across several architectural models. The ITU-T has specified an architecture for the control of Automatically Switched Optical Networks (ASON). This document provides a lexicography for the interpretation of GMPLS terminology within the context of the ASON architecture. It is important to note that GMPLS is applicable in a wider set of contexts than just ASON. The definitions presented in this document do not provide exclusive or complete interpretations of GMPLS concepts. This document simply allows the GMPLS terms to be applied within the ASON context. RFC 4426 http://www.ietf.org/rfc/rfc4426.txt Title Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification Abstract This document presents a functional description of the protocol extensions needed to support Generalized Multi-Protocol Label Switching (GMPLS)-based recovery (i.e., protection and restoration). Protocol specific formats and mechanisms will be described in companion documents. RFC 4427 http://www.ietf.org/rfc/rfc4427.txt Title Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) Abstract This document defines a common terminology for Generalized Multi- Protocol Label Switching (GMPLS)-based recovery mechanisms (i.e., protection and restoration). The terminology is independent of the underlying transport technologies covered by GMPLS. RFC 4428 http://www.ietf.org/rfc/rfc4428.txt Title Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) Abstract This document provides an analysis grid to evaluate, compare, and contrast the Generalized Multi-Protocol Label Switching (GMPLS) protocol suite capabilities with the recovery mechanisms currently proposed at the IETF CCAMP Working Group. A detailed analysis of each of the recovery phases is provided using the terminology defined in RFC 4427. This document focuses on transport plane survivability and recovery issues and not on control plane resilience and related aspects. All IETF RFCs can be downloaded for free from http://www.ietf.org/rfc.html The current work plan and progress status of the CCAMP working group can be viewed at http://www.ietf.org/html.charters/ccamp-charter.html The CCAMP working group welcomes questions and discussion about all of its work from individuals or organisations. The CCAMP mailing list is open to anyone. Details of subscription can be found on the CCAMP charter page. Regards, Adrian Farrel and Kireeti Kompella CCAMP working group chairs From owner-ccamp@ops.ietf.org Wed Apr 05 09:47:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR8MD-0000Mg-LK for ccamp-archive@ietf.org; Wed, 05 Apr 2006 09:47:37 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR8MB-000702-Ao for ccamp-archive@ietf.org; Wed, 05 Apr 2006 09:47:37 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FR8G4-000IUO-Ix for ccamp-data@psg.com; Wed, 05 Apr 2006 13:41:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_WHOIS autolearn=no version=3.1.1 Received: from [216.82.241.195] (helo=mail121.messagelabs.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FR8G1-000ITx-Qo for ccamp@ops.ietf.org; Wed, 05 Apr 2006 13:41:14 +0000 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-6.tower-121.messagelabs.com!1144244320!8082356!33 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 28240 invoked from network); 5 Apr 2006 13:41:12 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-6.tower-121.messagelabs.com with SMTP; 5 Apr 2006 13:41:12 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 4426C9FE00153906; Wed, 5 Apr 2006 09:41:12 -0400 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 Subject: RE: draft-ietf-ccamp-crankback-05.txt ready for AD review Date: Wed, 5 Apr 2006 08:41:11 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC75FF@KCCLUST06EVS1.ugd.att.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-ccamp-crankback-05.txt ready for AD review Thread-Index: AcVg+ChMB9VbsGXTR6ieEfHbAVxUvT3vXWXQ From: "Ash, Gerald R \(Jerry\), ALABS" To: , Cc: "Ash, Gerald R \(Jerry\), ALABS" , , Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 The crankback draft http://www.ietf.org/internet-drafts/draft-ietf-ccamp-crankback-05.txt has been in AD review (publication requested) for more than 10 months. Can we have a status? 6 other drafts are in the CCAMP AD-review queue also, but not as long: https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dsearch_list&= s earch_job_owner=3D0&search_group_acronym=3Dccamp&search_status_id=3D&sear= ch_cu r_state=3D&sub_state_id=3D6&search_filename=3D&search_rfcnumber=3D&search= _area_a cronym=3D&search_button=3DSEARCH. Thanks, Jerry -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Wednesday, May 25, 2005 3:04 AM To: zinin@psg.com Cc: ccamp@ops.ietf.org; iesg-secretary@ietf.org; fenner@research.att.com; adrian@olddog.co.uk Subject: draft-ietf-ccamp-crankback-05.txt ready for AD review Hi Alex,=20 draft-ietf-ccamp-crankback-05.txt is ready for AD review and progression through the process.=20 It is targeted at Standards Track.=20 The I-D has been through WG last call and has been liaised to ITU-T SG15.=20 Updates have been made in response to comments made in both forums.=20 I am happy with these updates, but note that I am also the editor of this=20 document.=20 Cheers,=20 Adrian From owner-ccamp@ops.ietf.org Wed Apr 05 09:54:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FR8Sl-0001Z4-CJ for ccamp-archive@ietf.org; Wed, 05 Apr 2006 09:54:23 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FR8Sk-00076Z-2f for ccamp-archive@ietf.org; Wed, 05 Apr 2006 09:54:23 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FR8Lk-000JIL-47 for ccamp-data@psg.com; Wed, 05 Apr 2006 13:47:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00, UNPARSEABLE_RELAY autolearn=ham version=3.1.1 Received: from [129.60.39.102] (helo=tama5.ecl.ntt.co.jp) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FR8Li-000JI9-Ry for ccamp@ops.ietf.org; Wed, 05 Apr 2006 13:47:07 +0000 Received: from vcs3.rdh.ecl.ntt.co.jp (vcs3.rdh.ecl.ntt.co.jp [129.60.39.110]) by tama5.ecl.ntt.co.jp (8.13.6/8.13.6) with ESMTP id k35Dl4qm001574; Wed, 5 Apr 2006 22:47:04 +0900 (JST) Received: from mfs3.rdh.ecl.ntt.co.jp (mfs3.rdh.ecl.ntt.co.jp [129.60.39.112]) by vcs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k35Dl3Jc026518; Wed, 5 Apr 2006 22:47:03 +0900 (JST) Received: from nttmail3.ecl.ntt.co.jp ([129.60.39.100]) by mfs3.rdh.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k35Dl24q007317; Wed, 5 Apr 2006 22:47:02 +0900 (JST) Received: from dmailsv1.y.ecl.ntt.co.jp (dmailsv1.y.ecl.ntt.co.jp [129.60.53.14]) by nttmail3.ecl.ntt.co.jp (8.12.11/8.12.11) with ESMTP id k35Dl2lV009183; Wed, 5 Apr 2006 22:47:02 +0900 (JST) Received: from mailsv04.y.ecl.ntt.co.jp by dmailsv1.y.ecl.ntt.co.jp (8.13.6/dmailsv-1.5) with ESMTP id k35Dl11A007003; Wed, 5 Apr 2006 22:47:01 +0900 (JST) Received: from localhost by mailsv04.y.ecl.ntt.co.jp (8.13.6/Lab-1.5a) with ESMTP id k35Dl1vs002385; Wed, 5 Apr 2006 22:47:01 +0900 (JST) Message-Id: <5.1.1.9.2.20060405224611.04286a88@mailsv4.y.ecl.ntt.co.jp> X-Sender: wi002@mailsv4.y.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Version 5.1-Jr3 Date: Wed, 05 Apr 2006 22:47:12 +0900 To: Kireeti Kompella , ccamp@ops.ietf.org From: Wataru Imajuku Subject: Re: Progressing docs In-Reply-To: <20060331100203.G31807@kummer.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Hi, Kiretti and Adrian Yes to all Wataru >Hi All, > >This is to double-check support *on the list* for the following I-Ds to go >to WG docs: > >a) MPLS-GMPLS interworking > draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt >b) "hierarchy bis" > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt >c) Call Support > draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt >d) Ethernet TSpec > draft-dimitri-mef-ethernet-traffic-parameters-00.txt >e) OSPF-TE MIB > draft-otani-ccamp-gmpls-ospf-mib-02.txt > >Please say for each if you think it should/should not become a WG doc. > >My previous email was in error: the "excellent" support was for the >migration doc. Just to be clear, we'll double-check all these docs. > >Kireeti. >------- > --------------------------------- Wataru Imajuku @NTT Network Innovation Labs. TEL +81-46-859-4315 FAX +81-46-859-5541 From owner-ccamp@ops.ietf.org Wed Apr 05 18:26:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRGSa-00054O-8E for ccamp-archive@ietf.org; Wed, 05 Apr 2006 18:26:44 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRGSZ-0000oz-ED for ccamp-archive@ietf.org; Wed, 05 Apr 2006 18:26:44 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRGMA-000IZm-P1 for ccamp-data@psg.com; Wed, 05 Apr 2006 22:20:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_50_60,HTML_MESSAGE,MIME_BASE64_NO_NAME, SPF_PASS autolearn=no version=3.1.1 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRGM9-000IZY-FG for ccamp@ops.ietf.org; Wed, 05 Apr 2006 22:20:05 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 05 Apr 2006 15:20:04 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,91,1144047600"; d="scan'208,217"; a="25277432:sNHT60084766" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k35MK3Wc004332; Wed, 5 Apr 2006 18:20:03 -0400 (EDT) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 5 Apr 2006 18:20:03 -0400 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_01C658FF.1571E0A3" Subject: Comparison of Encryption vs. Path Key Solutions for the CPS ID. Date: Wed, 5 Apr 2006 18:19:54 -0400 Message-ID: <3C292CE901FC634693F24FB2DDC4D332014EF5CB@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comparison of Encryption vs. Path Key Solutions for the CPS ID. Thread-Index: AcZYoa17yPX/wRg0S0Wcwz2H4PidHgAXKKKQ From: "Rich Bradford \(rbradfor\)" To: , X-OriginalArrivalTime: 05 Apr 2006 22:20:03.0008 (UTC) FILETIME=[15AB2400:01C658FF] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7f3fa64b9851a63d7f3174ef64114da7 This is a multi-part message in MIME format. ------_=_NextPart_001_01C658FF.1571E0A3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksDQoNCkFzIHN1Z2dlc3RlZCBpbiBEYWxsYXMsIEnigJl2ZSBkZXNjcmliZWQgc29tZSBvZiB0 aGUgdHJhZGVvZmZzIGJldHdlZW4gdGhlIHR3byBzb2x1dGlvbnMgZGVzY3JpYmVkIGluIGRyYWZ0 LXJicmFkZm9yLWNjYW1wLWNvbmZpZGVudGlhbC1zZWdtZW50LTAwLnR4dC4NCg0KLS0gUmljaA0K DQogDQoNClRoZSBDb25maWRlbnRpYWwgUGF0aCBTZWdtZW50IChDUFMpIElEIHByb3ZpZGVzIHR3 byB2ZXJ5IGRpZmZlcmVudCBidXQgZXF1YWxseSB2YWxpZCBzb2x1dGlvbnMsIHRoZSBQYXRoIEtl eSBTdWJvYmplY3QgKFBLUykgc29sdXRpb24gYW5kIHRoZSBQcml2YXRlIFJvdXRlIFN1Ym9iamVj dCAoUFJTKSBzb2x1dGlvbi4gVGhpcyBub3RlIGV4YW1pbmVzIGEgbnVtYmVyIG9mIHRoZSBhZHZh bnRhZ2VzIGFuZCBkaXNhZHZhbnRhZ2VzIG9mIGVhY2ggc29sdXRpb24uIA0KDQogDQoNCkluIHNo b3J0OiBUaGUgUEtTIHNvbHV0aW9uIGFsbG93cyBhIFBDRSB0byBoaWRlIHRoZSBDUFMgZm9yIGFu IEFTIGJ5IHNhdmluZyBpdCBpbiBhIGRhdGFiYXNlIGFuZCByZXBsYWNpbmcgaXQgd2l0aCBhIGtl eSBpbiB0aGUgRVJPLiBEdXJpbmcgdGhlIExTUCBzZXR1cCwgdGhlIGluZ3Jlc3MgTFNSIGZvciB0 aGF0IEFTIG11c3QgcXVlcnkgdGhlIFBDRSBmb3IgYW4gZXhwYW5zaW9uLg0KDQpUaGUgUFJTIHNv bHV0aW9uIGFsbG93cyBhIENQUyBmb3IgYW4gQVMgdG8gYmUgaGlkZGVuIGJ5IGVuY3J5cHRpbmcg aXQsIHdoaWNoIG1heSBiZSBkb25lIGJ5IGEgUENFIG9yIGJ5IHRoZSBIZWFkLUVuZCBMU1IuIER1 cmluZyB0aGUgTFNQIHNldHVwLCB0aGUgaW5ncmVzcyBMU1IgZm9yIHRoYXQgQVMgbXVzdCB1c2Ug YSBkZWNyeXB0aW9uIGtleSB0byBvYnRhaW4gdGhlIGV4cGFuc2lvbiAoaW1wbHlpbmcgYW4gZWFy bGllciBleGNoYW5nZSBvciBjb25maWd1cmF0aW9uKS4gDQoNCiANCg0KVGhlIG1ham9yIGRpZmZl cmVuY2VzIGJldHdlZW4gdGhlIG1lY2hhbmlzbXMgaW52b2x2ZSAoMSkgYWRkaXRpb25hbCBjb250 cm9sIG1lc3NhZ2VzLCAoMikgcGVyZm9ybWFuY2UgaXNzdWVzIGV4cGFuZGluZyB0aG9zZSBvYmpl Y3RzLCAoMykgdGhlIGFkZGl0aW9uIG9mIHN0YXRlIHRvIHRoZSBQQ0UsICg0KSB0aGUgc29sdXRp b24gc2NvcGUgKGkuZS4gYXBwbGljYWJpbGl0eSB0byB2YXJpb3VzIHRvcG9sb2dpZXMgb2YgZWFj aCBzb2x1dGlvbi4pLCBhbmQgKDUpIHRoZSBzaXplIG9mIG9iamVjdHMgYWRkZWQgdG8gZXhpc3Rp bmcgbWVzc2FnZXMuDQoNCiANCg0KKDEpIEFkZGl0aW9uYWwgQ29udHJvbCBNZXNzYWdlIE92ZXJo ZWFkOg0KDQpUaGUgUEtTIHNvbHV0aW9uIHJlcXVpcmVzIGEgbWVjaGFuaXNtIHRvIGV4cGFuZCB0 aGUgUGF0aCBLZXkgdXBvbiByZWNlaXB0IG9mIHRoZSBMU1Agc2V0dXAgcmVxdWVzdC4gU2luY2Ug dGhlIFBDRSB3aGljaCBjYWxjdWxhdGVkIHRoZSBQYXRoIEtleSBtaWdodCBub3QgcmVzaWRlIGlu IHRoZSBlbnRyeSBib3VuZGFyeSBMU1IsIHRoZSBMU1IgbXVzdCByZXF1ZXN0IHRoZSBleHBhbnNp b24gZnJvbSB0aGUgUENFLCByZXF1aXJpbmcgYW4gYWRkaXRpb25hbCBtZXNzYWdlIGV4Y2hhbmdl IGJlZm9yZSBMU1Agc2V0dXAgY2FuIHByb2NlZWQuIFRoZSBQYXRoIEVuY3J5cHRpb24gc29sdXRp b24gZG9lcyBub3QgcmVxdWlyZSB0aGlzIGV4dHJhIGV4Y2hhbmdlIGJldHdlZW4gdGhlIFBDRSBh bmQgdGhlIGluZ3Jlc3Mgbm9kZSBmb3IgZXZlcnkgTFNQLiBSYXRoZXIsIHRoZSBkZWNyeXB0aW9u IGtleSBuZWVkcyB0byBiZSBleGNoYW5nZWQgb25seSB3aGVuIGl0IGlzIGNoYW5nZWQuIFRoZSBy ZXN1bHQgaXMgYWRkaXRpb25hbCBkZWxheSBkdXJpbmcgZXZlcnkgTFNQIHNldHVwIGZvciB0aGUg UEtTIHNvbHV0aW9uIGJ1dCBubyBhZGRpdGlvbmFsIGRlbGF5IGZvciB0aGUgUFJTIHNvbHV0aW9u Lg0KDQogDQoNCiANCg0KKDIpIFBDRSBhbmQgTFNSIFBlcmZvcm1hbmNlOg0KDQpUaGUgUEtTIHNv bHV0aW9uIG11c3QgbWFpbnRhaW4gYSAodGVtcG9yYXJ5KSBkYXRhYmFzZSBvZiBrZXlzIGFkZGlu ZyBvdmVyaGVhZCB0byB0aGUgUENFLiBUaGUgUFJTIHNvbHV0aW9uIHJlcXVpcmVzIHRoZSBlbmNy eXB0aW9uIG9mIHRoZSBDUFMgaW4gdGhlIFBDRSBhbmQgZGVjcnlwdGlvbiBvZiB0aGUgQ1BTIGlu IHRoZSBMU1IsIHdoaWNoIGNvdWxkIGJlIENQVSBpbnRlbnNpdmUuIE5vdGUgdGhhdCBpbiBjYXNl IG9mIGEgYnVyc3Qgb2YgcmVxdWVzdHMsIGVuY3J5cHRpb24gb2YgbGFyZ2UgbnVtYmVyIG9mIENQ UyBtYXkgaGF2ZSBhbiBpbXBhY3Qgb24gdGhlIFBDRSByZXNwb25zZSB0aW1lLg0KDQogDQoNCigz KSBBZGRpdGlvbiBvZiBTdGF0ZSBpbiB0aGUgUENFOg0KDQpUaGUgUEtTIHNvbHV0aW9uIHJlcXVp cmVzIHRoZSBhZGRpdGlvbiBvZiBwYXRoLXNwZWNpZmljIHN0YXRlIGFuZCBtYWludGVuYW5jZSBv ZiBhIGRhdGFiYXNlIGluIHRoZSBQQ0UuIFRoZSBQUlMgc29sdXRpb24gcmVxdWlyZXMgbm8gYWRk aXRpb25hbCBzdGF0ZS4NCg0KIA0KDQogDQoNCig0KSBTb2x1dGlvbiBTY29wZToNCg0KVGhlIFBL UyBhbmQgUFJTIHNvbHV0aW9ucyBib3RoIHdvcmsgd2VsbCBpbiBjb25qdW5jdGlvbiB3aXRoIGEg UENFIHRvIGVuY29kZSBhbmQgZGVjb2RlIHRoZSBDUFMuIEhvd2V2ZXIgdGhlIFBLUyBwcm92aWRl cyBubyBkaXJlY3Qgc29sdXRpb24gd2l0aG91dCBhIFBDRS4gVGhpcyBwcmV2ZW50cyB0aGUgUEtT IHNvbHV0aW9uIGZvciB3b3JraW5nIGluIHRoZSBjYXNlIHdoZXJlIEEncyBuZXR3b3JrIHN0cmFk ZGxlcyBCJ3MgbmV0d29yayBhbmQgd2hlcmUgQSB3YW50cyB0byB1c2UgYW4gRVJPIGZvciBhIHNl Z21lbnQgb2YgdGhlIExTUCBhY3Jvc3MgdGhlIGludGVydmVuaW5nIG5ldHdvcmssIGUuZy4gKG5l dEEpLShuZXRCKS0obmV0QSkuIEluIGFkZGl0aW9uLCB0aGUgUFJTIGNvdWxkIGJlIHVzZWQgdG8g cmVjb3JkIGEgQ1BTIGV2ZW4gaWYgdGhlIHBhdGggKGFuZCB0aGVyZWZvcmUgdGhlIHJldHVybmVk IFJSTykgY3Jvc3NlcyBtdWx0aXBsZSBib3VuZGFyaWVzLiBGaW5hbGx5LCBhIFBSUyBzb2x1dGlv biBjb3VsZCBiZSBhZGFwdGVkIHRvIHJldHVybiBhY3R1YWwgZmFpbHVyZSBsb2NhdGlvbnMgaW4g UEVSUnMgYW5kL29yIFBBVEhURUFScywgd2hpbGUga2VlcGluZyB0aGUgZmFpbHVyZSBsb2NhdGlv biBjb25maWRlbnRpYWwgZnJvbSBMU1JzIHdpdGhvdXQgYSBkZWNyeXB0aW9uIGtleS4gQ3VycmVu dGx5IHByaXZhY3kgb2YgdGhpcyBzb3VyY2UgaXMgbWFpbnRhaW5lZCBieSByZXR1cm5pbmcgdGhl IGFkZHJlc3Mgb2YgYm9yZGVyIG5vZGVzLCB3aGljaCBjYW4gYmUgdmVyeSBtaXNsZWFkaW5nLg0K DQogDQoNCig1KSBNZXNzYWdlIE9iamVjdCBPdmVyaGVhZDoNCg0KVGhlIFBLUyBzb2x1dGlvbiBw cm92aWRlcyBhIHZlcnkgY29tcGFjdCBrZXkgb3IgdG9rZW4gdG8gaWRlbnRpZnkgYSBwYXRoIHNl Z21lbnQsIHdoaWNoIGdlbmVyYWxseSBhbGxvd3MgZm9yIHNtYWxsZXIgRVJPcyB0byBiZSByZXR1 cm5lZCBieSB0aGUgUENFIGFuZCB0byBiZSByZXF1ZXN0ZWQgaW4gdGhlIHJlc3VsdGluZyBQQVRI IG1lc3NhZ2UuIEEgUFJTIHdoaWNoIGNvbnRhaW5zIGEgQ1BTIG11c3QgZ2VuZXJhbGx5IGJlIGF0 IGxlYXN0IGFzIGxhcmdlIGFzIHRoZSB1bmVuY3J5cHRlZCBQQVRIIHRocm91Z2ggdGhlIEFTIGFu ZCBtYXkgYmUgc2lnbmlmaWNhbnRseSBsYXJnZXIgaWYgaXQgaXMgZGVzaXJhYmxlIHRvIGhpZGUg dGhlIG51bWJlciBvZiBob3BzIHdpdGhpbiB0aGUgbmV0d29yayBmcm9tIGV4dGVybmFsIHZpZXcg YnkgcGFkZGluZyB0aGUgUFJTLiBUaGUgcmVzdWx0IGlzIHBvdGVudGlhbGx5IGxhcmdlciBQQVRI IChhbmQgUENFUCkgbWVzc2FnZXMgZm9yIHRoZSBQUlMgc29sdXRpb24uDQoNCiANCg0KIA0KDQpQ bGVhc2Ugbm90ZSB0aGF0IHRoZSB0cmFkZW9mZnMgbGlzdGVkIGhlcmUgYXJlIGZvciB0aGUgY3Vy cmVudCBJLUQuIFNvbWUgb2YgdGhlIHNob3J0Y29taW5ncyBvZiBlYWNoIGFwcHJvYWNoIGNvdWxk IGJlIG1pdGlnYXRlZCBieSBpbXBsZW1lbnRhdGlvbi1zcGVjaWZpYyBvcHRpbWl6YXRpb25zLiBG b3IgZXhhbXBsZSwgYSBQQ0UgY291bGQgY2hvb3NlIHRvIHNpZ25hbCB0aGUgQ1BTIGV4cGFuc2lv biB0byB0aGUgZW50cnkgYm91bmRhcnkgTFNSLCBzaGlmdGluZyB0aGUgYnVyZGVuIG9mIG1haW50 YWluaW5nIHRoZSBQS1Mgc3RhdGUgdG8gdGhlIExTUiBhbmQgZWxpbWluYXRpbmcgdGhlIHBlcmZv cm1hbmNlIGhpdCBkdXJpbmcgTFNQIHNldHVwLiBBIHNpbWlsYXIgZXhjaGFuZ2UgY291bGQgYmUg cGVyZm9ybWVkIGZvciB0aGUgUFJTIGNhc2UsIGVsaW1pbmF0aW5nIHRoZSBuZWVkIGZvciBhIHNl cGFyYXRlIGtleSBleGNoYW5nZS4gVGhlc2UgZXhhbXBsZXMgb2YgZXh0ZW5zaW9ucyBhcmUgYmV5 b25kIHRoZSBzY29wZSBvZiB0aGUgSUQsIGJ1dCBtaWdodCBiZSB1c2VmdWwgd2hlbiB3ZWlnaGlu ZyB0aGUgcHJvcyBhbmQgY29ucyBvZiB0aGUgdHdvIHNvbHV0aW9ucy4NCg0KIA0KDQogDQoNCg== ------_=_NextPart_001_01C658FF.1571E0A3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPg0KPGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZp Y2U6b2ZmaWNlIiB4bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3Jk IiB4bWxuczpzdDE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncyIg eG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KDQo8aGVhZD4NCg0KPG1l dGEgbmFtZT1HZW5lcmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTEgKGZpbHRlcmVkIG1l ZGl1bSkiPg0KPG86U21hcnRUYWdUeXBlIG5hbWVzcGFjZXVyaT0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIg0KIG5hbWU9IkNpdHkiLz4NCjxvOlNtYXJ0VGFnVHlw ZSBuYW1lc3BhY2V1cmk9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFn cyINCiBuYW1lPSJwbGFjZSIvPg0KPCEtLVtpZiAhbXNvXT4NCjxzdHlsZT4NCnN0MVw6KntiZWhh dmlvcjp1cmwoI2RlZmF1bHQjaWVvb3VpKSB9DQo8L3N0eWxlPg0KPCFbZW5kaWZdLS0+DQo8c3R5 bGU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIE1pbmNobyI7DQoJcGFub3NlLTE6MCAwIDAgMCAw IDAgMCAwIDAgMDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGku TXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biI7fQ0KaDENCgl7bWFyZ2luLXRvcDoxMi4wcHQ7DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJn aW4tYm90dG9tOjMuMHB0Ow0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCXBhZ2UtYnJlYWstYWZ0ZXI6YXZvaWQ7DQoJbXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzE7DQoJ Zm9udC1zaXplOjE2LjBwdDsNCglmb250LWZhbWlseTpBcmlhbDt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe2NvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7Y29sb3I6cHVycGxlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4 dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5D aGFwdGVyLCBsaS5DaGFwdGVyLCBkaXYuQ2hhcHRlcg0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmNlbnRlcjsNCglwYWdlLWJyZWFrLWJlZm9yZTph bHdheXM7DQoJZm9udC1zaXplOjE2LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0K CWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMjVpbiAxLjBpbiAxLjI1aW47fQ0KZGl2LlNlY3Rpb24xDQoJe3Bh Z2U6U2VjdGlvbjE7fQ0KIC8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCiBAbGlzdCBsMA0KCXttc28t bGlzdC1pZDo2ODg5NDE0NjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1w bGF0ZS1pZHM6MTQ4MzQ2NjggNTA2NDg4NjY0IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3 Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxl dmVsMQ0KCXttc28tbGV2ZWwtc3R5bGUtbGluazoiSGVhZGluZyAxIjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0 b206MGluO30NCi0tPg0KPC9zdHlsZT4NCg0KPC9oZWFkPg0KDQo8Ym9keSBsYW5nPUVOLVVTIGxp bms9Ymx1ZSB2bGluaz1wdXJwbGU+DQoNCjxkaXYgY2xhc3M9U2VjdGlvbjE+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHls ZT0nZm9udC1zaXplOg0KMTIuMHB0Jz5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+QXMgc3VnZ2VzdGVkIGluIDxzdDE6Q2l0 eSB3OnN0PSJvbiI+PHN0MTpwbGFjZSB3OnN0PSJvbiI+RGFsbGFzPC9zdDE6cGxhY2U+PC9zdDE6 Q2l0eT4sDQpJ4oCZdmUgZGVzY3JpYmVkIHNvbWUgb2YgdGhlIHRyYWRlb2ZmcyBiZXR3ZWVuIHRo ZSB0d28gc29sdXRpb25zIGRlc2NyaWJlZA0KaW4gZHJhZnQtcmJyYWRmb3ItY2NhbXAtY29uZmlk ZW50aWFsLXNlZ21lbnQtMDAudHh0LjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4tLSBSaWNoPG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz5U aGUgQ29uZmlkZW50aWFsIFBhdGggU2VnbWVudCAoQ1BTKSBJRCBwcm92aWRlcyB0d28gdmVyeSBk aWZmZXJlbnQgYnV0DQplcXVhbGx5IHZhbGlkIHNvbHV0aW9ucywgdGhlIFBhdGggS2V5IFN1Ym9i amVjdCAoUEtTKSBzb2x1dGlvbiBhbmQgdGhlIFByaXZhdGUNClJvdXRlIFN1Ym9iamVjdCAoUFJT KSBzb2x1dGlvbi4gVGhpcyBub3RlIGV4YW1pbmVzIGEgbnVtYmVyIG9mIHRoZSBhZHZhbnRhZ2Vz DQphbmQgZGlzYWR2YW50YWdlcyBvZiBlYWNoIHNvbHV0aW9uLiA8bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9 MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQn PkluIHNob3J0OiBUaGUgUEtTIHNvbHV0aW9uIGFsbG93cyBhIFBDRSB0byBoaWRlIHRoZSBDUFMg Zm9yIGFuIEFTIGJ5DQpzYXZpbmcgaXQgaW4gYSBkYXRhYmFzZSBhbmQgcmVwbGFjaW5nIGl0IHdp dGggYSBrZXkgaW4gdGhlIEVSTy4gRHVyaW5nIHRoZSBMU1ANCnNldHVwLCB0aGUgaW5ncmVzcyBM U1IgZm9yIHRoYXQgQVMgbXVzdCBxdWVyeSB0aGUgUENFIGZvciBhbiBleHBhbnNpb24uPG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9 MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQn PlRoZSBQUlMgc29sdXRpb24gYWxsb3dzIGEgQ1BTIGZvciBhbiBBUyB0byBiZSBoaWRkZW4gYnkg ZW5jcnlwdGluZyBpdCwNCndoaWNoIG1heSBiZSBkb25lIGJ5IGEgUENFIG9yIGJ5IHRoZSBIZWFk LUVuZCBMU1IuIER1cmluZyB0aGUgTFNQIHNldHVwLCB0aGUNCmluZ3Jlc3MgTFNSIGZvciB0aGF0 IEFTIG11c3QgdXNlIGEgZGVjcnlwdGlvbiBrZXkgdG8gb2J0YWluIHRoZSBleHBhbnNpb24NCihp bXBseWluZyBhbiBlYXJsaWVyIGV4Y2hhbmdlIG9yIGNvbmZpZ3VyYXRpb24pLiA8bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxm b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 DQoxMi4wcHQnPlRoZSBtYWpvciBkaWZmZXJlbmNlcyBiZXR3ZWVuIHRoZSBtZWNoYW5pc21zIGlu dm9sdmUgKDEpIGFkZGl0aW9uYWwNCmNvbnRyb2wgbWVzc2FnZXMsICgyKSBwZXJmb3JtYW5jZSBp c3N1ZXMgZXhwYW5kaW5nIHRob3NlIG9iamVjdHMsICgzKSB0aGUNCmFkZGl0aW9uIG9mIHN0YXRl IHRvIHRoZSBQQ0UsICg0KSB0aGUgc29sdXRpb24gc2NvcGUgKGkuZS4gYXBwbGljYWJpbGl0eSB0 bw0KdmFyaW91cyB0b3BvbG9naWVzIG9mIGVhY2ggc29sdXRpb24uKSwgYW5kICg1KSB0aGUgc2l6 ZSBvZiBvYmplY3RzIGFkZGVkIHRvDQpleGlzdGluZyBtZXNzYWdlcy48bzpwPjwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNp emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4w cHQnPigxKSBBZGRpdGlvbmFsIENvbnRyb2wgTWVzc2FnZSBPdmVyaGVhZDo8bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+VGhlIFBL UyBzb2x1dGlvbiByZXF1aXJlcyBhIG1lY2hhbmlzbSB0byBleHBhbmQgdGhlIFBhdGggS2V5IHVw b24NCnJlY2VpcHQgb2YgdGhlIExTUCBzZXR1cCByZXF1ZXN0LiBTaW5jZSB0aGUgUENFIHdoaWNo IGNhbGN1bGF0ZWQgdGhlIFBhdGggS2V5DQptaWdodCBub3QgcmVzaWRlIGluIHRoZSBlbnRyeSBi b3VuZGFyeSBMU1IsIHRoZSBMU1IgbXVzdCByZXF1ZXN0IHRoZSBleHBhbnNpb24NCmZyb20gdGhl IFBDRSwgcmVxdWlyaW5nIGFuIGFkZGl0aW9uYWwgbWVzc2FnZSBleGNoYW5nZSBiZWZvcmUgTFNQ IHNldHVwIGNhbg0KcHJvY2VlZC4gVGhlIFBhdGggRW5jcnlwdGlvbiBzb2x1dGlvbiBkb2VzIG5v dCByZXF1aXJlIHRoaXMgZXh0cmEgZXhjaGFuZ2UNCmJldHdlZW4gdGhlIFBDRSBhbmQgdGhlIGlu Z3Jlc3Mgbm9kZSBmb3IgZXZlcnkgTFNQLiBSYXRoZXIsIHRoZSBkZWNyeXB0aW9uIGtleQ0KbmVl ZHMgdG8gYmUgZXhjaGFuZ2VkIG9ubHkgd2hlbiBpdCBpcyBjaGFuZ2VkLiBUaGUgcmVzdWx0IGlz IGFkZGl0aW9uYWwgZGVsYXkNCmR1cmluZyBldmVyeSBMU1Agc2V0dXAgZm9yIHRoZSBQS1Mgc29s dXRpb24gYnV0IG5vIGFkZGl0aW9uYWwgZGVsYXkgZm9yIHRoZSBQUlMNCnNvbHV0aW9uLjxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXpl PTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0 Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu IHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPigyKSBQQ0UgYW5kIExTUiBQZXJmb3JtYW5jZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQg c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEy LjBwdCc+VGhlIFBLUyBzb2x1dGlvbiBtdXN0IG1haW50YWluIGEgKHRlbXBvcmFyeSkgZGF0YWJh c2Ugb2Yga2V5cyBhZGRpbmcNCm92ZXJoZWFkIHRvIHRoZSBQQ0UuIFRoZSBQUlMgc29sdXRpb24g cmVxdWlyZXMgdGhlIGVuY3J5cHRpb24gb2YgdGhlIENQUyBpbiB0aGUNClBDRSBhbmQgZGVjcnlw dGlvbiBvZiB0aGUgQ1BTIGluIHRoZSBMU1IsIHdoaWNoIGNvdWxkIGJlIENQVSBpbnRlbnNpdmUu IE5vdGUNCnRoYXQgaW4gY2FzZSBvZiBhIGJ1cnN0IG9mIHJlcXVlc3RzLCBlbmNyeXB0aW9uIG9m IGxhcmdlIG51bWJlciBvZiBDUFMgbWF5IGhhdmUNCmFuIGltcGFjdCBvbiB0aGUgUENFIHJlc3Bv bnNlIHRpbWUuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6DQoxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4oMykgQWRkaXRpb24gb2YgU3RhdGUgaW4gdGhl IFBDRTo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToNCjEyLjBwdCc+VGhlIFBLUyBzb2x1dGlvbiByZXF1aXJlcyB0aGUgYWRkaXRpb24gb2YgcGF0 aC1zcGVjaWZpYyBzdGF0ZSBhbmQNCm1haW50ZW5hbmNlIG9mIGEgZGF0YWJhc2UgaW4gdGhlIFBD RS4gVGhlIFBSUyBzb2x1dGlvbiByZXF1aXJlcyBubyBhZGRpdGlvbmFsDQpzdGF0ZS48bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0z IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNp emU6DQoxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBz dHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4oNCkgU29sdXRpb24gU2NvcGU6PG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPlRoZSBQ S1MgYW5kIFBSUyBzb2x1dGlvbnMgYm90aCB3b3JrIHdlbGwgaW4gY29uanVuY3Rpb24gd2l0aCBh IFBDRSB0bw0KZW5jb2RlIGFuZCBkZWNvZGUgdGhlIENQUy4gSG93ZXZlciB0aGUgUEtTIHByb3Zp ZGVzIG5vIGRpcmVjdCBzb2x1dGlvbiB3aXRob3V0DQphIFBDRS4gVGhpcyBwcmV2ZW50cyB0aGUg UEtTIHNvbHV0aW9uIGZvciB3b3JraW5nIGluIHRoZSBjYXNlIHdoZXJlIEEncyBuZXR3b3JrDQpz dHJhZGRsZXMgQidzIG5ldHdvcmsgYW5kIHdoZXJlIEEgd2FudHMgdG8gdXNlIGFuIEVSTyBmb3Ig YSBzZWdtZW50IG9mIHRoZSBMU1ANCmFjcm9zcyB0aGUgaW50ZXJ2ZW5pbmcgbmV0d29yaywgZS5n LiAobmV0QSktKG5ldEIpLShuZXRBKS4gSW4gYWRkaXRpb24sIHRoZSBQUlMNCmNvdWxkIGJlIHVz ZWQgdG8gcmVjb3JkIGEgQ1BTIGV2ZW4gaWYgdGhlIHBhdGggKGFuZCB0aGVyZWZvcmUgdGhlIHJl dHVybmVkIFJSTykNCmNyb3NzZXMgbXVsdGlwbGUgYm91bmRhcmllcy4gRmluYWxseSwgYSBQUlMg c29sdXRpb24gY291bGQgYmUgYWRhcHRlZCB0byByZXR1cm4NCmFjdHVhbCBmYWlsdXJlIGxvY2F0 aW9ucyBpbiBQRVJScyBhbmQvb3IgUEFUSFRFQVJzLCB3aGlsZSBrZWVwaW5nIHRoZSBmYWlsdXJl DQpsb2NhdGlvbiBjb25maWRlbnRpYWwgZnJvbSBMU1JzIHdpdGhvdXQgYSBkZWNyeXB0aW9uIGtl eS4gQ3VycmVudGx5IHByaXZhY3kgb2YNCnRoaXMgc291cmNlIGlzIG1haW50YWluZWQgYnkgcmV0 dXJuaW5nIHRoZSBhZGRyZXNzIG9mIGJvcmRlciBub2Rlcywgd2hpY2ggY2FuDQpiZSB2ZXJ5IG1p c2xlYWRpbmcuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6DQoxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4oNSkgTWVzc2FnZSBPYmplY3QgT3ZlcmhlYWQ6 PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250 IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQox Mi4wcHQnPlRoZSBQS1Mgc29sdXRpb24gcHJvdmlkZXMgYSB2ZXJ5IGNvbXBhY3Qga2V5IG9yIHRv a2VuIHRvIGlkZW50aWZ5IGENCnBhdGggc2VnbWVudCwgd2hpY2ggZ2VuZXJhbGx5IGFsbG93cyBm b3Igc21hbGxlciBFUk9zIHRvIGJlIHJldHVybmVkIGJ5IHRoZSBQQ0UNCmFuZCB0byBiZSByZXF1 ZXN0ZWQgaW4gdGhlIHJlc3VsdGluZyBQQVRIIG1lc3NhZ2UuIEEgUFJTIHdoaWNoIGNvbnRhaW5z IGEgQ1BTDQptdXN0IGdlbmVyYWxseSBiZSBhdCBsZWFzdCBhcyBsYXJnZSBhcyB0aGUgdW5lbmNy eXB0ZWQgUEFUSCB0aHJvdWdoIHRoZSBBUyBhbmQgbWF5DQpiZSBzaWduaWZpY2FudGx5IGxhcmdl ciBpZiBpdCBpcyBkZXNpcmFibGUgdG8gaGlkZSB0aGUgbnVtYmVyIG9mIGhvcHMgd2l0aGluDQp0 aGUgbmV0d29yayBmcm9tIGV4dGVybmFsIHZpZXcgYnkgcGFkZGluZyB0aGUgUFJTLiBUaGUgcmVz dWx0IGlzIHBvdGVudGlhbGx5DQpsYXJnZXIgUEFUSCAoYW5kIFBDRVApIG1lc3NhZ2VzIGZvciB0 aGUgUFJTIHNvbHV0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHls ZT0nZm9udC1zaXplOg0KMTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPlBsZWFzZSBu b3RlIHRoYXQgdGhlIHRyYWRlb2ZmcyBsaXN0ZWQgaGVyZSBhcmUgZm9yIHRoZSBjdXJyZW50IEkt RC4NClNvbWUgb2YgdGhlIHNob3J0Y29taW5ncyBvZiBlYWNoIGFwcHJvYWNoIGNvdWxkIGJlIG1p dGlnYXRlZCBieQ0KaW1wbGVtZW50YXRpb24tc3BlY2lmaWMgb3B0aW1pemF0aW9ucy4gRm9yIGV4 YW1wbGUsIGEgUENFIGNvdWxkIGNob29zZSB0bw0Kc2lnbmFsIHRoZSBDUFMgZXhwYW5zaW9uIHRv IHRoZSBlbnRyeSBib3VuZGFyeSBMU1IsIHNoaWZ0aW5nIHRoZSBidXJkZW4gb2YNCm1haW50YWlu aW5nIHRoZSBQS1Mgc3RhdGUgdG8gdGhlIExTUiBhbmQgZWxpbWluYXRpbmcgdGhlIHBlcmZvcm1h bmNlIGhpdCBkdXJpbmcNCkxTUCBzZXR1cC4gQSBzaW1pbGFyIGV4Y2hhbmdlIGNvdWxkIGJlIHBl cmZvcm1lZCBmb3IgdGhlIFBSUyBjYXNlLCBlbGltaW5hdGluZw0KdGhlIG5lZWQgZm9yIGEgc2Vw YXJhdGUga2V5IGV4Y2hhbmdlLiBUaGVzZSBleGFtcGxlcyBvZiBleHRlbnNpb25zIGFyZSBiZXlv bmQNCnRoZSBzY29wZSBvZiB0aGUgSUQsIGJ1dCBtaWdodCBiZSB1c2VmdWwgd2hlbiB3ZWlnaGlu ZyB0aGUgcHJvcyBhbmQgY29ucyBvZiB0aGUNCnR3byBzb2x1dGlvbnMuPG86cD48L286cD48L3Nw YW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPsKgPG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9 MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8L2JvZHk+ DQoNCjwvaHRtbD4NCg== ------_=_NextPart_001_01C658FF.1571E0A3-- From owner-ccamp@ops.ietf.org Thu Apr 06 08:59:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRU5a-0000wR-RF for ccamp-archive@ietf.org; Thu, 06 Apr 2006 08:59:54 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRU5a-0007Nn-0r for ccamp-archive@ietf.org; Thu, 06 Apr 2006 08:59:54 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRTyI-000CyR-2q for ccamp-data@psg.com; Thu, 06 Apr 2006 12:52:22 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_50_60,HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.1 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRTyG-000Cy2-Ky for ccamp@ops.ietf.org; Thu, 06 Apr 2006 12:52:21 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 06 Apr 2006 08:52:20 -0400 X-IronPort-AV: i="4.04,93,1144036800"; d="scan'208,217"; a="85855309:sNHT56985632" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k36CqJWc028200; Thu, 6 Apr 2006 08:52:19 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Apr 2006 08:52:19 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 6 Apr 2006 08:52:18 -0400 In-Reply-To: <3C292CE901FC634693F24FB2DDC4D332014EF5CB@xmb-rtp-20d.amer.cisco.com> References: <3C292CE901FC634693F24FB2DDC4D332014EF5CB@xmb-rtp-20d.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: multipart/alternative; boundary=Apple-Mail-121-664462459 Message-Id: Cc: , From: JP Vasseur Subject: Re: [Pce] Comparison of Encryption vs. Path Key Solutions for the CPS ID. Date: Thu, 6 Apr 2006 08:51:43 -0400 To: Rich Bradford ((rbradfor)) X-Mailer: Apple Mail (2.746.3) X-OriginalArrivalTime: 06 Apr 2006 12:52:18.0233 (UTC) FILETIME=[EFE4BA90:01C65978] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: fac892abe0c719c7bb99f6e7c710cdae --Apple-Mail-121-664462459 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Hi, Thanks for the summary Rich. PCE WG members: thanks to provide your feedback on whether: (1) You think that there is a need for such solution, (2) You would prefer one solution (which one and why ?) (3) You think that there is a need for both Thanks. JP. On Apr 5, 2006, at 6:19 PM, Rich Bradford ((rbradfor)) wrote: > Hi, > > As suggested in Dallas, I=92ve described some of the tradeoffs =20 > between the two solutions described in draft-rbradfor-ccamp-=20 > confidential-segment-00.txt. > > -- Rich > > > > The Confidential Path Segment (CPS) ID provides two very different =20 > but equally valid solutions, the Path Key Subobject (PKS) solution =20 > and the Private Route Subobject (PRS) solution. This note examines =20 > a number of the advantages and disadvantages of each solution. > > > > In short: The PKS solution allows a PCE to hide the CPS for an AS =20 > by saving it in a database and replacing it with a key in the ERO. =20 > During the LSP setup, the ingress LSR for that AS must query the =20 > PCE for an expansion. > > The PRS solution allows a CPS for an AS to be hidden by encrypting =20 > it, which may be done by a PCE or by the Head-End LSR. During the =20 > LSP setup, the ingress LSR for that AS must use a decryption key to =20= > obtain the expansion (implying an earlier exchange or configuration). > > > > The major differences between the mechanisms involve (1) additional =20= > control messages, (2) performance issues expanding those objects, =20 > (3) the addition of state to the PCE, (4) the solution scope (i.e. =20 > applicability to various topologies of each solution.), and (5) the =20= > size of objects added to existing messages. > > > > (1) Additional Control Message Overhead: > > The PKS solution requires a mechanism to expand the Path Key upon =20 > receipt of the LSP setup request. Since the PCE which calculated =20 > the Path Key might not reside in the entry boundary LSR, the LSR =20 > must request the expansion from the PCE, requiring an additional =20 > message exchange before LSP setup can proceed. The Path Encryption =20 > solution does not require this extra exchange between the PCE and =20 > the ingress node for every LSP. Rather, the decryption key needs to =20= > be exchanged only when it is changed. The result is additional =20 > delay during every LSP setup for the PKS solution but no additional =20= > delay for the PRS solution. > > > > > > (2) PCE and LSR Performance: > > The PKS solution must maintain a (temporary) database of keys =20 > adding overhead to the PCE. The PRS solution requires the =20 > encryption of the CPS in the PCE and decryption of the CPS in the =20 > LSR, which could be CPU intensive. Note that in case of a burst of =20 > requests, encryption of large number of CPS may have an impact on =20 > the PCE response time. > > > > (3) Addition of State in the PCE: > > The PKS solution requires the addition of path-specific state and =20 > maintenance of a database in the PCE. The PRS solution requires no =20 > additional state. > > > > > > (4) Solution Scope: > > The PKS and PRS solutions both work well in conjunction with a PCE =20 > to encode and decode the CPS. However the PKS provides no direct =20 > solution without a PCE. This prevents the PKS solution for working =20 > in the case where A's network straddles B's network and where A =20 > wants to use an ERO for a segment of the LSP across the intervening =20= > network, e.g. (netA)-(netB)-(netA). In addition, the PRS could be =20 > used to record a CPS even if the path (and therefore the returned =20 > RRO) crosses multiple boundaries. Finally, a PRS solution could be =20 > adapted to return actual failure locations in PERRs and/or =20 > PATHTEARs, while keeping the failure location confidential from =20 > LSRs without a decryption key. Currently privacy of this source is =20 > maintained by returning the address of border nodes, which can be =20 > very misleading. > > > > (5) Message Object Overhead: > > The PKS solution provides a very compact key or token to identify a =20= > path segment, which generally allows for smaller EROs to be =20 > returned by the PCE and to be requested in the resulting PATH =20 > message. A PRS which contains a CPS must generally be at least as =20 > large as the unencrypted PATH through the AS and may be =20 > significantly larger if it is desirable to hide the number of hops =20 > within the network from external view by padding the PRS. The =20 > result is potentially larger PATH (and PCEP) messages for the PRS =20 > solution. > > > > > > Please note that the tradeoffs listed here are for the current I-D. =20= > Some of the shortcomings of each approach could be mitigated by =20 > implementation-specific optimizations. For example, a PCE could =20 > choose to signal the CPS expansion to the entry boundary LSR, =20 > shifting the burden of maintaining the PKS state to the LSR and =20 > eliminating the performance hit during LSP setup. A similar =20 > exchange could be performed for the PRS case, eliminating the need =20 > for a separate key exchange. These examples of extensions are =20 > beyond the scope of the ID, but might be useful when weighing the =20 > pros and cons of the two solutions. > > > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-121-664462459 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 Hi,

Thanks for the summary = Rich.

PCE WG = members: thanks to provide your feedback on whether:
(1) You = think that there is a need for such solution,
(2) You = would prefer one solution (which one and why ?)
(3) You = think that there is a need for both

Thanks.

JP.

On Apr 5, 2006, = at 6:19 PM, Rich Bradford ((rbradfor)) wrote:

=

Hi,

As = suggested in Dallas, I=92ve described some of the = tradeoffs between the two solutions described in = draft-rbradfor-ccamp-confidential-segment-00.txt.=

-- = Rich

=A0

The Confidential Path Segment (CPS) ID provides two very = different but equally valid solutions, the Path Key Subobject (PKS) = solution and the Private Route Subobject (PRS) solution. This note = examines a number of the advantages and disadvantages of each solution. =

=A0

In = short: The PKS solution allows a PCE to hide the CPS for an AS by saving = it in a database and replacing it with a key in the ERO. During the LSP = setup, the ingress LSR for that AS must query the PCE for an = expansion.

The PRS solution allows a CPS for an AS to be hidden by = encrypting it, which may be done by a PCE or by the Head-End LSR. During = the LSP setup, the ingress LSR for that AS must use a decryption key to = obtain the expansion (implying an earlier exchange or configuration). =

=A0

The major differences between the mechanisms involve (1) = additional control messages, (2) performance issues expanding those = objects, (3) the addition of state to the PCE, (4) the solution scope = (i.e. applicability to various topologies of each solution.), and (5) = the size of objects added to existing = messages.

=A0

(1) Additional Control Message = Overhead:

The PKS solution requires a mechanism to expand the Path Key = upon receipt of the LSP setup request. Since the PCE which calculated = the Path Key might not reside in the entry boundary LSR, the LSR must = request the expansion from the PCE, requiring an additional message = exchange before LSP setup can proceed. The Path Encryption solution does = not require this extra exchange between the PCE and the ingress node for = every LSP. Rather, the decryption key needs to be exchanged only when it = is changed. The result is additional delay during every LSP setup for = the PKS solution but no additional delay for the PRS = solution.

=A0

=A0

(2) PCE and LSR Performance:

The PKS solution must maintain a (temporary) = database of keys adding overhead to the PCE. The PRS solution requires = the encryption of the CPS in the PCE and decryption of the CPS in the = LSR, which could be CPU intensive. Note that in case of a burst of = requests, encryption of large number of CPS may have an impact on the = PCE response time.

=A0

(3) Addition of State in the = PCE:

The PKS = solution requires the addition of path-specific state and maintenance of = a database in the PCE. The PRS solution requires no additional = state.

=A0

=A0

(4) Solution Scope:

The PKS and PRS solutions both work well in = conjunction with a PCE to encode and decode the CPS. However the PKS = provides no direct solution without a PCE. This prevents the PKS = solution for working in the case where A's network straddles B's network = and where A wants to use an ERO for a segment of the LSP across the = intervening network, e.g. (netA)-(netB)-(netA). In addition, the PRS = could be used to record a CPS even if the path (and therefore the = returned RRO) crosses multiple boundaries. Finally, a PRS solution could = be adapted to return actual failure locations in PERRs and/or PATHTEARs, = while keeping the failure location confidential from LSRs without a = decryption key. Currently privacy of this source is maintained by = returning the address of border nodes, which can be very = misleading.

=A0

(5) Message Object Overhead:

The PKS solution provides a very compact key = or token to identify a path segment, which generally allows for smaller = EROs to be returned by the PCE and to be requested in the resulting PATH = message. A PRS which contains a CPS must generally be at least as large = as the unencrypted PATH through the AS and may be significantly larger = if it is desirable to hide the number of hops within the network from = external view by padding the PRS. The result is potentially larger PATH = (and PCEP) messages for the PRS solution.

=A0

=A0

Please note that the tradeoffs listed here = are for the current I-D. Some of the shortcomings of each approach could = be mitigated by implementation-specific optimizations. For example, a = PCE could choose to signal the CPS expansion to the entry boundary LSR, = shifting the burden of maintaining the PKS state to the LSR and = eliminating the performance hit during LSP setup. A similar exchange = could be performed for the PRS case, eliminating the need for a separate = key exchange. These examples of extensions are beyond the scope of the = ID, but might be useful when weighing the pros and cons of the two = solutions.

=A0

=A0

=
Pce mailing list
=

= --Apple-Mail-121-664462459-- From owner-ccamp@ops.ietf.org Thu Apr 06 09:06:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRUC7-0003At-Qr for ccamp-archive@ietf.org; Thu, 06 Apr 2006 09:06:39 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRUC6-0007fg-6j for ccamp-archive@ietf.org; Thu, 06 Apr 2006 09:06:39 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRU88-000DxD-0M for ccamp-data@psg.com; Thu, 06 Apr 2006 13:02:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,UNPARSEABLE_RELAY autolearn=ham version=3.1.1 Received: from [210.163.32.69] (helo=mgw2.noc.ntt.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRU86-000Dwv-Po for ccamp@ops.ietf.org; Thu, 06 Apr 2006 13:02:31 +0000 Received: from mop3.noc.ntt.com by mgw2.noc.ntt.com (NTT-Com MailSV) with ESMTP id k36D2S4S014221; Thu, 6 Apr 2006 22:02:28 +0900 (JST) Received: from mip1.noc.ntt.com (mvi1.noc.ntt.com) by mop3.noc.ntt.com (NTT-Com MailSV) with ESMTP id <0IXA00M4NXK4QZ@ntt.com>; Thu, 06 Apr 2006 22:02:28 +0900 (JST) Date: Thu, 06 Apr 2006 22:02:27 +0900 From: "Yuichi Ikejiri" Subject: Re: Progressing docs In-reply-to: <20060331100203.G31807@kummer.juniper.net> To: "Kireeti Kompella" Cc: ccamp@ops.ietf.org Message-id: <20060406200558.58D0.Y.IKEJIRI@ntt.com> MIME-version: 1.0 X-Mailer: Becky! ver. 2.21.01 [ja] Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit References: <20060331100203.G31807@kummer.juniper.net> Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Hi, Yes to all to facilitate further discussion of each draft. Thanks, Yuichi On Fri, 31 Mar 2006 10:12:31 -0800 (PST) "Kireeti Kompella" wrote: > Hi All, > > This is to double-check support *on the list* for the following I-Ds > to go to WG docs: > > a) MPLS-GMPLS interworking > draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt > b) "hierarchy bis" > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > c) Call Support > draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt > d) Ethernet TSpec > draft-dimitri-mef-ethernet-traffic-parameters-00.txt > e) OSPF-TE MIB > draft-otani-ccamp-gmpls-ospf-mib-02.txt > > Please say for each if you think it should/should not become a WG doc. > > My previous email was in error: the "excellent" support was for the > migration doc. Just to be clear, we'll double-check all these docs. > > Kireeti. > ------- From ewqq@yahoo.co.jp Thu Apr 06 12:39:07 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRXVj-0005zA-31 for ccamp-archive@ietf.org; Thu, 06 Apr 2006 12:39:07 -0400 Received: from [218.24.126.229] (helo=ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FRXVg-0007BN-7X for ccamp-archive@ietf.org; Thu, 06 Apr 2006 12:39:07 -0400 To: From: =?iso-2022-jp?B?VFJT?= Subject: =?iso-2022-jp?B?GyRCTDVOQSRHMEI/NCEqGyhC?= MIME-Version: 1.0 Reply-To: Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.6 (++++) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 $B=P2q$$7O$N%P%$%V%k!*(B $B=P2q$$$N6b%a%@%j%9%HC#%j%K%e%"%k!#(B http://wxxo.com/golden/ $B<+M3Nx0&$rE0DlJ,@O(B $BLd!K(B laibalaiba88@126.com From owner-ccamp@ops.ietf.org Fri Apr 07 11:27:54 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FRssM-0002ak-JK for ccamp-archive@ietf.org; Fri, 07 Apr 2006 11:27:54 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FRssL-0000LS-NY for ccamp-archive@ietf.org; Fri, 07 Apr 2006 11:27:54 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRsku-000IHe-VB for ccamp-data@psg.com; Fri, 07 Apr 2006 15:20:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.49] (helo=mail2.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FRskt-000IGL-2M for ccamp@ops.ietf.org; Fri, 07 Apr 2006 15:20:11 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1FRskm-0002Ek-00 for ccamp@ops.ietf.org; Fri, 07 Apr 2006 16:20:06 +0100 Received: from Puppy ([217.158.132.224] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 7 Apr 2006 16:20:35 +0100 Message-ID: <04c701c65a56$c73e8b50$bf849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: References: <014001c65334$94f903b0$6400a8c0@Puppy> Subject: Calling implementors: ERO implementation survey Date: Fri, 7 Apr 2006 16:17:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 07 Apr 2006 15:20:36.0343 (UTC) FILETIME=[D1FE5070:01C65A56] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Hi, I have had some responses to this request. In case the information so far is unrepresentative, I'd really appreciate it if you could take 5 minutes to send me a private response. Thanks. Adrian ----- Original Message ----- From: "Adrian Farrel" To: Sent: Tuesday, March 28, 2006 8:12 PM Subject: ERO implementation survey > In Dallas, during discussion of draft-ietf-ccamp-gmpls-addressing-03, we > determined that implementations must support any form of ERO that is > legitimately sent by any other implementation. At the same time there is a > desire to reduce the number of options if this is possible. Lastly, there > was some confusion about what the RFCs actually allow you to do, and > rather than debate this as though we were lawyers, it may be more > profitable to look at what current implementations do. > > Obviously we can do further work on this if/when RFCs 3209, 3471 and 3473 > go to Draft Standard. > > To move things forward, I would like to do an informal and *confidential* > survey of current implementations. > > Please respond to each question below with, Yes / No / NA > NA would largely apply where the implementation is found on a NE where the > technology makes the ERO option inappropriate. > > Send your responses to me and not to the mailing lists (unless you fancy > the publicity). > > Thanks, > Adrian > > 1. EROs built for use on Path messages > For each hop in the path, which of the following options does your > implementation utilise? > This question applies to EROs that your implementations construct, NOT to > EROs that you forward. > > a. IP Address with non-full prefix length specifying a group of nodes > > b. AS number > > c. TE Router ID > > d. Incoming TE link ID > > e. Outgoing TE link ID > > f. Outgoing TE link ID followed by one or two Label subobjects > > g. Outgoing TE link ID followed by Component Interface ID subobject > > h. Outgoing TE link ID followed by Component Interface ID subobject > and one or two Label subobjects > > i. TE Router ID and Outgoing TE link ID > > j. TE Router ID and Outgoing TE link ID followed by one or two > Label subobjects > > k. TE Router ID and Outgoing TE link ID followed by Component > Interface ID subobject > > l. TE Router ID and Outgoing TE link ID followed by Component > Interface ID subobject and one or two Label subobjects > > m. Incoming TE link ID and Outgoing TE link ID > > n. Incoming TE link ID and Outgoing TE link ID followed by one or two > Label subobjects > > o. Incoming TE link ID and Outgoing TE link ID followed by Component > Interface ID subobject > > p. Incoming TE link ID and Outgoing TE link ID followed by Component > Interface ID subobject and one or two Label subobjects > > q. Incoming TE link ID, TE Router ID, and Outgoing TE link ID > > r. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by one or two Label subobjects > > s. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by Component Interface ID subobject > > t. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by Component Interface ID subobject and one or two Label subobjects > > 2. EROs received from the previous hop on Path messages > Which *top* subobjects in the ERO does your implementation support > receiving? > This question applies to ERO subobjects that your implementations must > handle, NOT to ERO subobjects that you forward. > > a. IP Address with non-full prefix length specifying a group of nodes > > b. AS number > > c. TE Router ID > > d. Incoming TE link ID > > e. Outgoing TE link ID > > f. Outgoing TE link ID followed by one or two Label subobjects > > g. Outgoing TE link ID followed by Component Interface ID subobject > > h. Outgoing TE link ID followed by Component Interface ID subobject > and one or two Label subobjects > > i. TE Router ID and Outgoing TE link ID > > j. TE Router ID and Outgoing TE link ID followed by one or two > Label subobjects > > k. TE Router ID and Outgoing TE link ID followed by Component > Interface ID subobject > > l. TE Router ID and Outgoing TE link ID followed by Component > Interface ID subobject and one or two Label subobjects > > m. Incoming TE link ID and Outgoing TE link ID > > n. Incoming TE link ID and Outgoing TE link ID followed by one or two > Label subobjects > > o. Incoming TE link ID and Outgoing TE link ID followed by Component > Interface ID subobject > > p. Incoming TE link ID and Outgoing TE link ID followed by Component > Interface ID subobject and one or two Label subobjects > > q. Incoming TE link ID, TE Router ID, and Outgoing TE link ID > > r. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by one or two Label subobjects > > s. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by Component Interface ID subobject > > t. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by Component Interface ID subobject and one or two Label subobjects > > > > From gschweizer@freddyflintoff.com Sat Apr 08 08:03:51 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSCAR-0000mt-1K for ccamp-archive@ietf.org; Sat, 08 Apr 2006 08:03:51 -0400 Received: from [218.61.149.251] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FSCAM-0001KQ-Uy for ccamp-archive@ietf.org; Sat, 08 Apr 2006 08:03:51 -0400 Message-ID: <000001c65b2e$b29e9b80$0100007f@localhost> From: "Myles Collins" To: Subject: Photoshop, Windows, Office Date: Sat, 08 Apr 2006 20:06:05 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C65B2E.B29E9B80" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 3.7 (+++) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C65B2E.B29E9B80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Special Offer Adobe Video Collection Adobe Premiere 1.5 Professional Adobe After Effects 6.5 Professional Adobe Audition 1.5 Adobe Encore DVD 1.5 $149.95 More Info >> Microsoft 2 in 1 MS Windows XP Pro MS Office 2003 Pro $99.95 More Info >> Microsoft + Adobe 3 in 1 MS Windows XP Pro MS Office 2003 Pro Adobe Acrobat 7.0 Professional $149.95 More Info >> Bestsellers Microsoft Office Professional Edition 2003 Rating: 6 reviews Retail price: $550.00 You save: $480.05 (87%) Our price: $69.95 [Add to cart] Microsoft Windows XP Professional Rating: 8 reviews Retail price: $200.00 You save: $150.05 (75%) Our price: $49.95 [Add to cart] Adobe Photoshop CS2 V 9.0 Rating: 3 reviews Retail price: $599.00 You save: $529.05 (88%) Our price: $69.95 [Add to cart] ------=_NextPart_000_0001_01C65B2E.B29E9B80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DS
Special Offer
Adobe Video Collection
  • Adobe Premiere 1.5 Professional
  • Adobe After Effects 6.5 Professional
  • Adobe Audition 1.5
  • Adobe Encore DVD 1.5
$149.95    
More Info >>
Microsoft 2 in 1
  • MS Windows XP Pro
  • MS Office 2003 Pro




$99.95    
More Info >>
Microsoft + Adobe 3 in 1
  • MS Windows XP Pro
  • MS Office 2003 Pro
  • Adobe Acrobat 7.0 Professional


$149.95    
More Info >>
Bestsellers
3D"" Microsoft Office Professional Edition 2003
Rating: 6 reviews
Retail price: $550.00
You save: $480.05 (87%)
Our price: $69.95		  

Add to cart

3D"" Microsoft Windows XP Professional
Rating: 8 reviews
Retail price: $200.00
You save: $150.05 (75%)
Our price: $49.95		  

Add to cart

3D"" Adobe Photoshop CS2 V 9.0
Rating: 3 reviews
Retail price: $599.00
You save: $529.05 (88%)
Our price: $69.95		  

Add to cart

------=_NextPart_000_0001_01C65B2E.B29E9B80-- From qinwang@LLOYDSTSQIN.COM Sat Apr 08 13:05:30 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSGsM-0003xr-DA; Sat, 08 Apr 2006 13:05:30 -0400 Received: from [72.34.40.200] (helo=vps.solid-hosting.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSGsK-0002sj-Mm; Sat, 08 Apr 2006 13:05:30 -0400 Received: from royal by vps.solid-hosting.net with local (Exim 4.52) id 1FSFAh-0006Fc-VW; Sat, 08 Apr 2006 11:16:20 -0400 Received: from 62.163.35.61 ([62.163.35.61]) (SquirrelMail authenticated user gulfgroup@royalcargoservices.com) by 72.34.40.201 with HTTP; Sat, 8 Apr 2006 11:16:19 -0400 (EDT) Message-ID: <2569.62.163.35.61.1144509379.squirrel@72.34.40.201> Date: Sat, 8 Apr 2006 11:16:19 -0400 (EDT) Subject: Business project/ Representative From: "Mr.Q Wang" Reply-To: qinwanginfo@emanssv.com User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - vps.solid-hosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [32163 32162] / [47 12] X-AntiAbuse: Sender Address Domain - LLOYDSTSQIN.COM X-Source: X-Source-Args: X-Source-Dir: X-Spam-Score: 4.7 (++++) X-Scan-Signature: b8f3559805f7873076212d6f63ee803e Business project/ Representative Qin Wang Lloyds TSB Pacific Limited Hong Kong Branch Two Exchange Square Central, Hong Kong Tel/Fax: +852-301-57932 http://www.lloydstsb.com.hk Thank you for giving me your time, it is of great importance for you to take care and understand every word which I have written down below; please be patient and read my email. I am a staff of Lloyds TSB Group Plc here in Hong Kong attached in Private Banking Services. I am contacting you concerning a customer and an investment placed under our banks management; as a matter of fact it was 3 years ago. I would respectfully request that you keep the contents of this mail private and also to kindly respect the integrity of the information you come by as a result of this email. I contacted you independently of our investigation and no one is informed of this communication; I would like to intimate you with certain facts that I believe would be of interest to you.In 2000, the subject matter; Ref: FI/TSB/957/048/0532 came to our bank to engage in business discussions with our Private Banking Services Department. He informed us that he had a financial portfolio of 11.37 million United States Dollars, which he wished to have us turn over (invest) on his behalf. I was the officer assigned to his case; I made numerous suggestions in line with my duties as the de-facto chief operations officer of the Private Banking Services Department, especially given the volume of funds he wished to put into our bank. We met on numerous occasions prior to any investments being placed, and however I encouraged him to consider various growth funds with prime ratings. The favored route in my advice to customers is to start by assessing data on 600 traditional stocks and bond managers and 200 managers of alternative investments. Based on my advice, we spun the money around various opportunities and made attractive margins for our first months of operation, the accrued profit with interest included, stood at this point at over 13.2 million United States Dollars, this margin was not the full potential of the fund but he desired low risk guaranteed returns on investments. In mid 2001, he asked that the money be liquidated because he needed to make an urgent investment requiring cash payments in Europe. He directed that I liquidate the funds and had it deposited with a firm in Europe. I informed him that our bank would have to make special arrangements to have this done and in order not to circumvent due process, the bank would have to make a 9.5 % deduction from the funds to cater for banking and statutory charges. He complained about the charges but later came around when I explained to him the complexities of the task he was asking of us. Cash movement across borders has become especially strict since the incidents of 9/11. I contacted my affiliate in Europe and had the funds available in mainland Europe, I undertook all the processes and made sure I followed his precise instructions to the letter and had the funds deposited in a security consultancy firm, the firm is a specialist private firm that accepts deposits from high net worth individuals and blue chip corporations that handle valuable products or undertake transactions that need immediate access to cash. This small and highly private organization is familiar especially to the highly placed and well-connected organizations. In line with instructions, the money was deposited; he told me he wanted the money there in anticipation of his arrival from Norway later that week. This was the last communication we had, this transpired around February 25th 2002. In June last year, we got a call from the security firm informing us of the inactivity of that particular portfolio. This was an astounding position as far as I was concerned, given the fact that I managed the private banking sector I was the only one who knew about the deposit, and I could not understand why he had not come forward to claim his deposit.I made futile efforts to locate him I immediately passed the task of locating him to the internal investigations department of our bank. Four days later, information started to trickle in, that he was apparently dead, a person who suited his description was declared dead of a heart attack in Cannes, South of France; we were soon enough able to gather more information and the cause of death was confirmed. The bank immediately launched an investigation into possible surviving next of kin to alert about the situation and also to come forward to claim his estate. If you are familiar with private banking affairs, those who patronize our services usually prefer anonymity, but also some levels of detachment from conventional processes. In his bio-data form, he listed no next of kin. In the field of private banking, opening an account with us means no one will know of its existence, accounts are rarely held under a name; depositors use numbers and codes to make the accounts anonymous. This bank also gives the choice to depositors of having their mail sent to them or held at the bank itself, ensuring that there are no traces of the account and as I said, rarely do they nominate next of kin. Private banking clients apart from not nominating next of kin also usually in most cases leave wills in our care, in this case; he died in testate. In line with our internal processes for account holders who have passed away, we instituted our own investigations in good faith to determine who should have right to claim the estate, this investigation for several months were futile. We have scanned every continent and used our private investigation affiliate companies to get to the root of the problem. It is this investigation that resulted in my decision to obtain your contact details and contact you, being as a foreigner or rather non-Asian, as a potential benefactor of the estate even if you are in no way affiliated with this individual (the deceased).My official capacity dictates that I am the only party to supervise the investigation and the only party to receive the results of the investigation. What this means, with you being a foreigner, I have considered the fact that our dear late fellow died with no known or identifiable family member. This leaves me as the only person with the full picture of what the prevailing situation is in relation to the deposit and the late beneficiary of the deposit. According to practice, the firm will by the end of this financial year broadcast a request for statements of claim to our bank, failing to receive viable claims they will most probably revert the deposit back to our bank. This will result in the money entering our bank's accounting system and the portfolio will be out of my hands and out of the Private Banking Services Department. This will not happen if I have my way.What I wish to relate to you might be a smack of unethical practice but I want you to understand something; it is only an outsider to the banking world who finds the internal politics of the banking world aberrational. The world of private banking especially is fraught with huge rewards for those who occupy certain offices and oversee certain portfolios; you should have begun by now to put together the general direction of what I propose. There is USD$ 11,991,674 deposited, I alone have the deposit details and they will release the deposit to no one unless I instruct them to do so.I alone know of the existence of this deposit for as far as the finance firm is concerned, the transaction with our deceased customer concluded when I sent the funds to the firm, all outstanding interactions in relation to the file are just customer services and due process. The finance firm has no single idea of what's the history or nature of the deposit, they are simply awaiting instructions to release the deposit to any party that comes forward, and this is the situation. This bank has spent great amounts of money trying to track the family of the deceased; they have investigated for months and have found no family but however the investigation has come to an end. My proposal; I am prepared to place you in a position to instruct the finance firm to release the deposit to you as the closest surviving relation. Upon receipt of the deposit, I am prepared to share the money with you in half and no more; that is: I will simply nominate you as the next of kin and have them release the deposit to you; afterwards we share the proceeds 50/50.I would have gone ahead to ask the funds be released to me, but that would have drawn a straight line to me and my involvement in claiming the deposit, but on the other hand, you as a indifferent foreigner would easily pass as the beneficiary with the rights to claim, I assure you that I could have the deposit released to you in a few days. I will simply inform our bank of the final closing of the file relating to the customer, I will then officially communicate with the finance company and instruct them to release the deposit to you; with these two things: all is done. The alternative would be for us to have the firm direct the funds to another bank with you as account holder, this way there will be no need for you to think of receiving the money from the firm. We can fine-tune this based on our interactions, I am aware of the consequences of this proposal and I ask that if you find no interest in this project that you should discard this mail. I ask also, that you do not be vindictive or destructive, if my offer is of no appeal to you, delete this message and forget I ever contacted you; please not destroy my career because you do not approve of my proposal. You may not know this but people like me who have made tidy sums out of comparable situations run the whole private banking sector, I am not a criminal and what I do, I do not find against good conscience, this may be hard for you to understand, but the dynamics of my industry dictates that I make this move. Such opportunities only come ones' way once in a lifetime. I cannot let this chance pass me by and I hope you understand, because for once I found myself in total control and face to face with my destiny. These chances won't pass me by, I ask that you do not destroy my chance, if you will not work with me please let me know, and hence move on with my life, but do not destroy me; I am a family man and this is an occasion to provide them with new opportunities. There is a reward for this project and it is a task well worth undertaking, I have evaluated the risks and the only risk I have here is from you refusing to work with me and alerting my bank; I am the only one who knows of this situation, good fortune will bless you and plant you into the center of relevance in my life, let’s share the blessing. If you find yourself interested to work with me, please contact me specifically, through this email account (qinwanginfo@emanssv.com), if you give me positive signals, I will initiate this process towards a conclusion. It is necessary to inform you that under no condition should you contact me via official channels; I will simply deny knowing you and about this project. I repeat, I do not want you contacting me through our official lines neither do I want you contacting me through my official email account. Contact me only through this email address above; I do not want any direct link between you and me. My official lines are not secure lines as they are periodically monitored to assess our level of customer care in line with our Total Quality Management policy, please observe this instruction religiously. Please, again, note I am a family man; I happily married with two kids, I send you this mail not without a measure of fear as to what the consequences might be, but I know within me that nothing ventured is nothing gained and that success and riches never come easy or on a platter of gold, this is the one truth I have learned from my private banking clients; do not betray my confidence. If we can be of one accord, I shall have the pleasure of meeting you after this task has been completed plan a meeting, soon. I await your response. Yours Sincerely, Qin. From owner-ccamp@ops.ietf.org Mon Apr 10 04:07:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSrPz-0007Ee-Dr for ccamp-archive@ietf.org; Mon, 10 Apr 2006 04:06:39 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSrDx-0004Er-C7 for ccamp-archive@ietf.org; Mon, 10 Apr 2006 03:54:14 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FSr3z-0004wV-Jg for ccamp-data@psg.com; Mon, 10 Apr 2006 07:43:55 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, HTML_MESSAGE autolearn=ham version=3.1.1 Received: from [134.226.1.156] (helo=imx2.tcd.ie) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FSr3y-0004w1-2X for ccamp@ops.ietf.org; Mon, 10 Apr 2006 07:43:54 +0000 Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id D22EC6808C for ; Mon, 10 Apr 2006 08:43:52 +0100 (IST) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A06E7BC3520; Mon, 10 Apr 2006 08:43:52 +0100 Received: from PC (ntrg023.cs.tcd.ie [134.226.55.23]) by imx2.tcd.ie (Postfix) with ESMTP id C05FF6808C for ; Mon, 10 Apr 2006 08:43:52 +0100 (IST) From: "Marco Ruffini" To: Subject: GMPLS dynamics vs. issues with optical amplifiers Date: Mon, 10 Apr 2006 08:43:45 +0100 Message-ID: <000801c65c72$81d7f9c0$1737e286@PC> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C65C7A.E39C61C0" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal X-AntiVirus-Status: MessageID = A16E7BC3520 X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.56.3 VDF=8.1142) Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 6907f330301e69261fa73bed91449a20 This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C65C7A.E39C61C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, I'm a PhD student on optical network and I'm following the development of the GMPLS work. I had a recent discussion with people working on the optical transport network who where telling me their concern about creating dynamical path over trails including optical amplifiers. They say that cross-talk and gain fluctuation effects may limit the capability of fast allocating new wavelengths over those trials. I just wanted to know what is your opinion about this and if is there some working group within the IETF already trying to challenge this problem. Thank you for your attention Best Regards, Marco Ruffini. CTVR, University of Dublin, Trinity College, Dublin 2, Ireland. Phone: +353-1-608 8441 ------=_NextPart_000_0009_01C65C7A.E39C61C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

I’m a PhD student on optical network and = I’m following the development of the GMPLS work.

I had a recent discussion with people working = on the optical transport network who where telling me their concern about = creating dynamical path over trails including optical = amplifiers.

They say that cross-talk and gain fluctuation = effects may limit the capability of fast allocating new wavelengths over those = trials.

 

I just wanted to know what is your opinion = about this and if is there some working group within the IETF already trying to = challenge this problem.

 

Thank you for your attention

 

Best Regards,

Marco Ruffini.

 

CTVR,

University of = Dublin, Trinity = College,

Dublin = 2,

Ireland.

Phone: +353-1-608 8441

 

------=_NextPart_000_0009_01C65C7A.E39C61C0-- From owner-ccamp@ops.ietf.org Mon Apr 10 04:17:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSraJ-0001RK-Ug for ccamp-archive@ietf.org; Mon, 10 Apr 2006 04:17:19 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSraG-0006Hy-FI for ccamp-archive@ietf.org; Mon, 10 Apr 2006 04:17:19 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FSrRI-0006aH-Jh for ccamp-data@psg.com; Mon, 10 Apr 2006 08:08:00 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_POST,FORGED_RCVD_HELO,SPF_PASS autolearn=no version=3.1.1 Received: from [213.46.243.15] (helo=amsfep11-int.chello.nl) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FSrRC-0006Zq-A3 for ccamp@ops.ietf.org; Mon, 10 Apr 2006 08:07:57 +0000 Received: from [192.168.1.3] (really [24.132.27.149]) by amsfep11-int.chello.nl (InterMail vM.6.01.05.04 201-2131-123-105-20051025) with ESMTP id <20060410080747.VUQJ13880.amsfep11-int.chello.nl@[192.168.1.3]>; Mon, 10 Apr 2006 10:07:47 +0200 Message-ID: <443A1252.5040903@chello.nl> Date: Mon, 10 Apr 2006 10:07:46 +0200 From: Huub van Helvoort User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Marco Ruffini CC: ccamp@ops.ietf.org Subject: Re: GMPLS dynamics vs. issues with optical amplifiers References: <000801c65c72$81d7f9c0$1737e286@PC> In-Reply-To: <000801c65c72$81d7f9c0$1737e286@PC> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Hello Marco, You wrote: > I’m a PhD student on optical network and I’m following the > development of the GMPLS work. > > I had a recent discussion with people working on the optical > transport network who where telling me their concern about creating > dynamical path over trails including optical amplifiers. > > They say that cross-talk and gain fluctuation effects may limit the > capability of fast allocating new wavelengths over those trials. Cross-talk and gain are physical properties and not related to bandwidth management like GMPLS. IMO the concern is unjustified. > I just wanted to know what is your opinion about this and if is there > some working group within the IETF already trying to challenge this > problem. IMO for the physical properties you should turn to the ITU-T. Cheers, Huub. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... From owner-ccamp@ops.ietf.org Mon Apr 10 10:16:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSxCC-0005Wh-Km for ccamp-archive@ietf.org; Mon, 10 Apr 2006 10:16:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSxCB-00039y-7Y for ccamp-archive@ietf.org; Mon, 10 Apr 2006 10:16:48 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FSx3Y-000B5F-V8 for ccamp-data@psg.com; Mon, 10 Apr 2006 14:07:52 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.49] (helo=mail2.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FSx3X-000B54-C8 for ccamp@ops.ietf.org; Mon, 10 Apr 2006 14:07:51 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1FSx3S-0006U8-00 for ccamp@ops.ietf.org; Mon, 10 Apr 2006 15:07:46 +0100 Received: from Puppy ([217.158.132.118] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 10 Apr 2006 15:08:18 +0100 Message-ID: <07b301c65ca8$2c46b3d0$bf849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Huub van Helvoort" , "Marco Ruffini" Cc: References: <000801c65c72$81d7f9c0$1737e286@PC> <443A1252.5040903@chello.nl> Subject: Re: GMPLS dynamics vs. issues with optical amplifiers Date: Mon, 10 Apr 2006 15:07:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 10 Apr 2006 14:08:19.0109 (UTC) FILETIME=[380A2D50:01C65CA8] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Hi Marco, I think that Huub may over-simplify the question with his response. The issues of cross-talk, amplification, etc. do impact on the selection of lambdas to carry services of different lengths through the network, and can become extremely important where transparent optical devices (for example, PXCs) are used. Suitable planning tools are available to make such decisions in real time, but provisioning may be slower than "instant" because of the need to tune power levels etc. We should note that in lambda networks we are probably talking about building transport connections. In general, such connections do not need to be provisioned instantly and have relatively high latency. So a lot depends on what you mean by "fast allocating." With respect to what the IETF would or would not work on, we should observe the following: - The IETF does not generally do algorithms So the mechanism of computing suitable paths and choosing lambdas is out of scope. You would need to contact a specialist computation / NMS company for this sort of thing. - There is (as far as I can see) no immediate impact on signaling. Once a path and a lambda have been selected, we already have the tools to establish the connections. - There *might* be a future requirement to signal certain constraints, but we would need to see the requirements clearly stated. - There is probably a need to enhance the advertisement of some key physical attributes of optical links and nodes in the IGPs. At the moment, however, this information appears to be gathered through inventory systems and there has been very little consideration of this requirement. - As Huub says, the IETF does not work on defining physical properties of optical links, nor on specifying the interactions between such properties. Regards, Adrian ----- Original Message ----- From: "Huub van Helvoort" To: "Marco Ruffini" Cc: Sent: Monday, April 10, 2006 9:07 AM Subject: Re: GMPLS dynamics vs. issues with optical amplifiers > Hello Marco, > > You wrote: > > > I’m a PhD student on optical network and I’m following the > > development of the GMPLS work. > > > > I had a recent discussion with people working on the optical > > transport network who where telling me their concern about creating > > dynamical path over trails including optical amplifiers. > > > > They say that cross-talk and gain fluctuation effects may limit the > > capability of fast allocating new wavelengths over those trials. > > Cross-talk and gain are physical properties and not related > to bandwidth management like GMPLS. > > IMO the concern is unjustified. > > > I just wanted to know what is your opinion about this and if is there > > some working group within the IETF already trying to challenge this > > problem. > > IMO for the physical properties you should turn to the ITU-T. > > Cheers, Huub. > > -- > ================================================================ > http://members.chello.nl/hhelvoort/ > ================================================================ > Always remember that you are unique...just like everyone else... > > > From owner-ccamp@ops.ietf.org Mon Apr 10 10:23:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSxIu-00006l-FT for ccamp-archive@ietf.org; Mon, 10 Apr 2006 10:23:44 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSxIu-0003P7-1d for ccamp-archive@ietf.org; Mon, 10 Apr 2006 10:23:44 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FSx9D-000BPI-Ue for ccamp-data@psg.com; Mon, 10 Apr 2006 14:13:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_WHOIS autolearn=no version=3.1.1 Received: from [85.158.136.19] (helo=mail124.messagelabs.com) by psg.com with smtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FSx9C-000BP5-HM for ccamp@ops.ietf.org; Mon, 10 Apr 2006 14:13:42 +0000 X-VirusChecked: Checked X-Env-Sender: gash@att.com X-Msg-Ref: server-13.tower-124.messagelabs.com!1144678420!6599579!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [134.24.146.4] Received: (qmail 9777 invoked from network); 10 Apr 2006 14:13:40 -0000 Received: from unknown (HELO attrh3i.attrh.att.com) (134.24.146.4) by server-13.tower-124.messagelabs.com with SMTP; 10 Apr 2006 14:13:40 -0000 Received: from kcclust06evs1.ugd.att.com (135.38.164.88) by attrh3i.attrh.att.com (7.2.052) id 4426C9FE001EB64F; Mon, 10 Apr 2006 10:13:39 -0400 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 Subject: RE: GMPLS dynamics vs. issues with optical amplifiers Date: Mon, 10 Apr 2006 09:13:39 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7618@KCCLUST06EVS1.ugd.att.com> In-Reply-To: <07b301c65ca8$2c46b3d0$bf849ed9@Puppy> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: GMPLS dynamics vs. issues with optical amplifiers Thread-Index: AcZcqHp/UC+zxd5rSHG8jGIgWWRt0gAAFftQ From: "Ash, Gerald R \(Jerry\), ALABS" To: "Adrian Farrel" , "Huub van Helvoort" , "Marco Ruffini" Cc: "Ash, Gerald R \(Jerry\), ALABS" , Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Furthermore RFC 4054 http://www.ietf.org/rfc/rfc4054.txt deals with some of these issues. -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Monday, April 10, 2006 10:08 AM To: Huub van Helvoort; Marco Ruffini Cc: ccamp@ops.ietf.org Subject: Re: GMPLS dynamics vs. issues with optical amplifiers Hi Marco, I think that Huub may over-simplify the question with his response. The issues of cross-talk, amplification, etc. do impact on the selection of lambdas to carry services of different lengths through the network, and can become extremely important where transparent optical devices (for example, PXCs) are used. Suitable planning tools are available to make such decisions in real time, but provisioning may be slower than "instant" because of the need to tune power levels etc. We should note that in lambda networks we are probably talking about building transport connections. In general, such connections do not need to be provisioned instantly and have relatively high latency. So a lot depends on what you mean by "fast allocating." With respect to what the IETF would or would not work on, we should observe the following: - The IETF does not generally do algorithms So the mechanism of computing suitable paths and choosing lambdas is out of scope. You would need to contact a specialist computation / NMS company for this sort of thing. - There is (as far as I can see) no immediate impact on signaling. Once a path and a lambda have been selected, we already have the tools to establish the connections. - There *might* be a future requirement to signal certain constraints, but we would need to see the requirements clearly stated. - There is probably a need to enhance the advertisement of some key physical attributes of optical links and nodes in the IGPs. At the moment, however, this information appears to be gathered through inventory systems and there has been very little consideration of this requirement. - As Huub says, the IETF does not work on defining physical properties of optical links, nor on specifying the interactions between such properties. Regards, Adrian ----- Original Message -----=20 From: "Huub van Helvoort" To: "Marco Ruffini" Cc: Sent: Monday, April 10, 2006 9:07 AM Subject: Re: GMPLS dynamics vs. issues with optical amplifiers > Hello Marco, > > You wrote: > > > I'm a PhD student on optical network and I'm following the > > development of the GMPLS work. > > > > I had a recent discussion with people working on the optical > > transport network who where telling me their concern about creating > > dynamical path over trails including optical amplifiers. > > > > They say that cross-talk and gain fluctuation effects may limit the > > capability of fast allocating new wavelengths over those trials. > > Cross-talk and gain are physical properties and not related > to bandwidth management like GMPLS. > > IMO the concern is unjustified. > > > I just wanted to know what is your opinion about this and if is there > > some working group within the IETF already trying to challenge this > > problem. > > IMO for the physical properties you should turn to the ITU-T. > > Cheers, Huub. > > --=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > http://members.chello.nl/hhelvoort/ > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Always remember that you are unique...just like everyone else... > > > From owner-ccamp@ops.ietf.org Mon Apr 10 11:01:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSxtI-0002vE-8b for ccamp-archive@ietf.org; Mon, 10 Apr 2006 11:01:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSxtF-0005Dq-OK for ccamp-archive@ietf.org; Mon, 10 Apr 2006 11:01:20 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FSxmR-000DqP-Jb for ccamp-data@psg.com; Mon, 10 Apr 2006 14:54:15 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [193.205.80.99] (helo=sssup.it) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FSxmO-000Dq3-TU for ccamp@ops.ietf.org; Mon, 10 Apr 2006 14:54:13 +0000 Received: from [193.205.81.2] (HELO Platini) by sssup.it (CommuniGate Pro SMTP 4.1.8) with ESMTP id 21267353; Mon, 10 Apr 2006 16:52:08 +0200 Message-ID: <014001c65cae$a0075da0$ad021e0a@Platini> From: "Filippo Cugini" To: "Adrian Farrel" , "Marco Ruffini" Cc: References: <000801c65c72$81d7f9c0$1737e286@PC> <443A1252.5040903@chello.nl> <07b301c65ca8$2c46b3d0$bf849ed9@Puppy> Subject: Re: GMPLS dynamics vs. issues with optical amplifiers Date: Mon, 10 Apr 2006 16:54:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Hi all, IMO the issue will have to be faced soon. Transparent network elements such as ROADM and PXC are beginning to be deployed in optical transport networks. However, the current GMPLS does not provide any functionality to keep track of the signal quality degradation. Thus, transparent mesh networks must be statically designed, during the network planning, to guarantee that even the most impaired connection (e.g., the longest path) is acceptable. Otherwise, because of the current GMPLS limits, connections can successfully be set up even if they do not comply with physical parameters constraints. However, the worst case design approach heavily limits the size of the transparent networks. Filippo ----- Original Message ----- From: "Adrian Farrel" > [..] > - There *might* be a future requirement to signal certain > constraints, but we would need to see the requirements clearly > stated. > - There is probably a need to enhance the advertisement of > some key physical attributes of optical links and nodes in > the IGPs. At the moment, however, this information > appears to be gathered through inventory systems and > there has been very little consideration of this requirement. From owner-ccamp@ops.ietf.org Mon Apr 10 11:13:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSy5F-00055g-JY for ccamp-archive@ietf.org; Mon, 10 Apr 2006 11:13:41 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSy5F-0005xb-AO for ccamp-archive@ietf.org; Mon, 10 Apr 2006 11:13:41 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FSxxO-000Ef8-SK for ccamp-data@psg.com; Mon, 10 Apr 2006 15:05:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [47.129.242.56] (helo=zcars04e.nortel.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FSxxN-000Eec-IA for ccamp@ops.ietf.org; Mon, 10 Apr 2006 15:05:33 +0000 Received: from zrtphxm2.corp.nortel.com (zrtphxm2.corp.nortel.com [47.140.202.51]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id k3AF0kj26638; Mon, 10 Apr 2006 11:00:46 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: GMPLS dynamics vs. issues with optical amplifiers Date: Mon, 10 Apr 2006 11:05:17 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA407BBCFCB@zrtphxm2> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: GMPLS dynamics vs. issues with optical amplifiers Thread-Index: AcZcrrWGBTlG3fKmS2qryqs/nS+5JQAABLvg From: "Don Fedyk" To: "Filippo Cugini" , "Adrian Farrel" , "Marco Ruffini" Cc: Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Hi all About a year ago we started to collect requirements for towards this area in a draft. Our current thinking is that the optical/photonic networks will have fairly proprietary ways of dealing with the non-linear properties but that the interface to GMPLS can be summarized as a fairly generic network interface with a simple metric and a blocking capability. We only got as far a the requirements. The draft is in in need of a refresh I will try to do that shortly. I have to contact some other people who were interested in the area.=20 If you cannot find a copy of the draft I will send it to you.=20 draft-ashwood-ccamp-gmpls-constraint-reqts-00 Regards, Don=20 =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Filippo Cugini >=20 >=20 > Hi all, >=20 > IMO the issue will have to be faced soon. Transparent network=20 > elements such=20 > as ROADM and PXC are beginning to be deployed in optical=20 > transport networks. However, the current GMPLS does not=20 > provide any functionality to keep track=20 > of the signal quality degradation. Thus, transparent mesh=20 > networks must be=20 > statically designed, during the network planning, to=20 > guarantee that even the=20 > most impaired connection (e.g., the longest path) is=20 > acceptable. Otherwise,=20 > because of the current GMPLS limits, connections can=20 > successfully be set up=20 > even if they do not comply with physical parameters=20 > constraints. However, the worst case design approach heavily=20 > limits the size of the=20 > transparent networks. >=20 > Filippo >=20 >=20 > ----- Original Message -----=20 > From: "Adrian Farrel" > > [..] > > - There *might* be a future requirement to signal certain > > constraints, but we would need to see the requirements clearly > > stated. > > - There is probably a need to enhance the advertisement of > > some key physical attributes of optical links and nodes in > > the IGPs. At the moment, however, this information > > appears to be gathered through inventory systems and > > there has been very little consideration of this requirement. >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Mon Apr 10 11:21:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSyCw-0001Hz-CM for ccamp-archive@ietf.org; Mon, 10 Apr 2006 11:21:38 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSyCv-0006NX-3b for ccamp-archive@ietf.org; Mon, 10 Apr 2006 11:21:38 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FSy7F-000FSK-1J for ccamp-data@psg.com; Mon, 10 Apr 2006 15:15:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FSy7E-000FS6-Cd for ccamp@ops.ietf.org; Mon, 10 Apr 2006 15:15:44 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k3AFFh1Z046054 for ; Mon, 10 Apr 2006 08:15:43 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k3AFFh522242 for ; Mon, 10 Apr 2006 08:15:43 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id k3AFFh7v068981 for ; Mon, 10 Apr 2006 08:15:43 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id k3AFFh8I068978 for ; Mon, 10 Apr 2006 08:15:43 -0700 (PDT) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Mon, 10 Apr 2006 08:15:42 -0700 (PDT) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: Re: Progressing docs In-Reply-To: <20060331100203.G31807@kummer.juniper.net> Message-ID: <20060410081007.G68964@kummer.juniper.net> References: <20060331100203.G31807@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f On Fri, 31 Mar 2006, Kireeti Kompella wrote: > This is to double-check support *on the list* for the following I-Ds to go to > WG docs: > > a) MPLS-GMPLS interworking > draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt > b) "hierarchy bis" > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > c) Call Support > draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt > d) Ethernet TSpec > draft-dimitri-mef-ethernet-traffic-parameters-00.txt > e) OSPF-TE MIB > draft-otani-ccamp-gmpls-ospf-mib-02.txt > > Please say for each if you think it should/should not become a WG doc. Thanks, all, for your responses. All of the above have support. Authors/editors, please resubmit your docs as WG docs: draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-00.txt draft-ietf-ccamp-lsp-hierarchy-bis-00.txt draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt draft-ietf-mef-ethernet-traffic-parameters-00.txt draft-ietf-ccamp-gmpls-ospf-mib-00.txt Please make sure that the formating complies and that there are no non-ascii characters in your doc. Hierarchy-bis: please change the title as agreed. Thanks again, Kireeti. ------- From owner-ccamp@ops.ietf.org Mon Apr 10 11:52:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSyf7-0002Vy-7Z for ccamp-archive@ietf.org; Mon, 10 Apr 2006 11:50:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSySs-000732-4J for ccamp-archive@ietf.org; Mon, 10 Apr 2006 11:38:06 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FSyM6-000Gbh-Tj for ccamp-data@psg.com; Mon, 10 Apr 2006 15:31:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [207.17.137.64] (helo=colo-dns-ext2.juniper.net) by psg.com with esmtps (TLSv1:DES-CBC3-SHA:168) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FSyM6-000GbW-DG for ccamp@ops.ietf.org; Mon, 10 Apr 2006 15:31:06 +0000 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id k3AFV51Z046304; Mon, 10 Apr 2006 08:31:05 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from kummer.juniper.net (kummer.juniper.net [172.17.12.90]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k3AFV5525191; Mon, 10 Apr 2006 08:31:05 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from kummer.juniper.net (localhost [127.0.0.1]) by kummer.juniper.net (8.12.8p1/8.12.3) with ESMTP id k3AFV17v069038; Mon, 10 Apr 2006 08:31:01 -0700 (PDT) (envelope-from kireeti@juniper.net) Received: from localhost (kireeti@localhost) by kummer.juniper.net (8.12.8p1/8.12.3/Submit) with ESMTP id k3AFV0OO069035; Mon, 10 Apr 2006 08:31:00 -0700 (PDT) X-Authentication-Warning: kummer.juniper.net: kireeti owned process doing -bs Date: Mon, 10 Apr 2006 08:31:00 -0700 (PDT) From: Kireeti Kompella To: Marco Ruffini cc: ccamp@ops.ietf.org Subject: Re: GMPLS dynamics vs. issues with optical amplifiers In-Reply-To: <000801c65c72$81d7f9c0$1737e286@PC> Message-ID: <20060410081618.F68964@kummer.juniper.net> References: <000801c65c72$81d7f9c0$1737e286@PC> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Hi Marco, On Mon, 10 Apr 2006, Marco Ruffini wrote: > I'm a PhD student on optical network and I'm following the development of > the GMPLS work. > > I had a recent discussion with people working on the optical transport > network who where telling me their concern about creating dynamical path > over trails including optical amplifiers. > > They say that cross-talk and gain fluctuation effects may limit the > capability of fast allocating new wavelengths over those trials. We've talked on and off about these in CCAMP, and there have been drafts to describe some of the various optical impairments to consider. In the GMPLS structure defined so far, there are link attributes (such as metrics and bandwidth), and typically, these can be combined simply to get a functioning path. Thus, for metrics, the combining function is summation, and for bandwidth, the function is "min". To accommodate attributes that are not carried as TE extensions today, we may have to add node attributes (say for dB loss across a mirror complex). We may also have to linearize impairments, or define how they are composed across links and nodes; this is not always easy to do. You say "fast allocating new wavelengths". I would have thought that the issue is not how fast the allocation is, but whether the allocation and ultimately, the optical LSP setup, is successful taking into account optics and physics. Kireeti. ------- From owner-ccamp@ops.ietf.org Mon Apr 10 12:00:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSyoS-0007B6-2c for ccamp-archive@ietf.org; Mon, 10 Apr 2006 12:00:24 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSyoP-0007kj-9O for ccamp-archive@ietf.org; Mon, 10 Apr 2006 12:00:24 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FSyjk-000IKY-1f for ccamp-data@psg.com; Mon, 10 Apr 2006 15:55:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE autolearn=no version=3.1.1 Received: from [192.240.0.5] (helo=fujitsu0.fujitsu.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FSyjj-000IK5-2X for ccamp@ops.ietf.org; Mon, 10 Apr 2006 15:55:31 +0000 Received: from fujitsu0.fujitsu.com (localhost [127.0.0.1]) by fujitsu0.fujitsu.com (8.13.6/8.13.6) with ESMTP id k3AFtDHR009933; Mon, 10 Apr 2006 08:55:13 -0700 (PDT) Received: from fujitsui.fna.fujitsu.com ([133.164.253.1]) by fujitsu0.fujitsu.com (8.13.6/8.13.6) with ESMTP id k3AFt7Ti009855; Mon, 10 Apr 2006 08:55:07 -0700 (PDT) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsui.fna.fujitsu.com (8.13.5/8.13.5) with ESMTP id k3AFt6Zn003800; Mon, 10 Apr 2006 08:55:06 -0700 (PDT) Received: from PHOENIX (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6/8.11.6) with ESMTP id k3AFt5O16710; Mon, 10 Apr 2006 08:55:05 -0700 (PDT) From: "Richard Rabbat" To: "'Don Fedyk'" , "'Filippo Cugini'" , "'Adrian Farrel'" , "'Marco Ruffini'" Cc: Subject: RE: GMPLS dynamics vs. issues with optical amplifiers Date: Mon, 10 Apr 2006 08:55:00 -0700 Message-ID: <012b01c65cb7$1f907810$353ba485@PHOENIX> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <34B3EAA5B3066A42914D28C5ECF5FEA407BBCFCB@zrtphxm2> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Importance: Normal Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Hi, There are pros and cons to advertising optical information including = lambda availability and optical impairements. GMPLS is not supposed to replace advanced path computation tools. Actually, an entity such as the PCE = would be a perfect piece in the architecture of a lambda network as it is = expected to provide advanced computation capabilities beyond CSPF. Actually, we've been looking at some interop scenarii where we are = clearly in need for standardization and mentioned one such scenario in=20 http://www.ietf.org/internet-drafts/draft-shiba-ccamp-gmpls-lambda-labels= -01 .txt I think it's time to do a proper analysis of what support already = exists, what is still needed and work on extensions (if needed) to support the = new generation of ROADM and PXC devices where interop is required. A few vendors who build ROADMs and PXCs, as well as SPs deploying them = have expressed interest in this topic when we discussed the 1st version at = CCAMP. I think it's time to sit down and take a stab at it so we have an interesting draft to discuss in Montreal. Send me email if you have some cycles to spare on this topic. Richard. =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Don Fedyk > Sent: Monday, April 10, 2006 8:05 AM > To: Filippo Cugini; Adrian Farrel; Marco Ruffini > Cc: ccamp@ops.ietf.org > Subject: RE: GMPLS dynamics vs. issues with optical amplifiers >=20 >=20 > Hi all >=20 > About a year ago we started to collect requirements for towards this > area in a draft. Our current thinking is that the optical/photonic > networks will have fairly proprietary ways of dealing with the > non-linear properties but that the interface to GMPLS can be=20 > summarized > as a fairly generic network interface with a simple metric and a > blocking capability. We only got as far a the requirements. The draft > is in in need of a refresh I will try to do that shortly. I have to > contact some other people who were interested in the area.=20 >=20 > If you cannot find a copy of the draft I will send it to you.=20 >=20 > draft-ashwood-ccamp-gmpls-constraint-reqts-00 >=20 > Regards, > Don=20 >=20 > =20 >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org=20 > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Filippo Cugini > >=20 > >=20 > > Hi all, > >=20 > > IMO the issue will have to be faced soon. Transparent network=20 > > elements such=20 > > as ROADM and PXC are beginning to be deployed in optical=20 > > transport networks. However, the current GMPLS does not=20 > > provide any functionality to keep track=20 > > of the signal quality degradation. Thus, transparent mesh=20 > > networks must be=20 > > statically designed, during the network planning, to=20 > > guarantee that even the=20 > > most impaired connection (e.g., the longest path) is=20 > > acceptable. Otherwise,=20 > > because of the current GMPLS limits, connections can=20 > > successfully be set up=20 > > even if they do not comply with physical parameters=20 > > constraints. However, the worst case design approach heavily=20 > > limits the size of the=20 > > transparent networks. > >=20 > > Filippo > >=20 > >=20 > > ----- Original Message -----=20 > > From: "Adrian Farrel" > > > [..] > > > - There *might* be a future requirement to signal certain > > > constraints, but we would need to see the requirements clearly > > > stated. > > > - There is probably a need to enhance the advertisement of > > > some key physical attributes of optical links and nodes in > > > the IGPs. At the moment, however, this information > > > appears to be gathered through inventory systems and > > > there has been very little consideration of this requirement. > >=20 > >=20 > >=20 >=20 >=20 From owner-ccamp@ops.ietf.org Mon Apr 10 12:02:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSyqS-0007g4-NL for ccamp-archive@ietf.org; Mon, 10 Apr 2006 12:02:28 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSyqQ-0007rj-7a for ccamp-archive@ietf.org; Mon, 10 Apr 2006 12:02:28 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FSyju-000IMH-En for ccamp-data@psg.com; Mon, 10 Apr 2006 15:55:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [130.237.32.140] (helo=mx1.kth.se) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FSyjt-000IM5-0Y for ccamp@ops.ietf.org; Mon, 10 Apr 2006 15:55:41 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by mx1.kth.se (Postfix) with ESMTP id EDEB4140A53; Mon, 10 Apr 2006 17:55:39 +0200 (CEST) Received: from mx1.kth.se ([127.0.0.1]) by localhost (mx1.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 01497-01-80; Mon, 10 Apr 2006 17:55:38 +0200 (CEST) Received: from mail1.imit.kth.se (mail1.imit.kth.se [130.237.212.19]) by mx1.kth.se (Postfix) with ESMTP id 2A454140806; Mon, 10 Apr 2006 17:55:38 +0200 (CEST) Received: from vinni.wan.it.kth.seit.kth.se (itwan251-228.wan.it.kth.se [130.237.251.228]) by mail1.imit.kth.se (Postfix) with ESMTP id 14D295FA03; Mon, 10 Apr 2006 17:55:38 +0200 (CEST) To: "Huub van Helvoort" , "Marco Ruffini" Cc: ccamp@ops.ietf.org Subject: Re: GMPLS dynamics vs. issues with optical amplifiers References: <000801c65c72$81d7f9c0$1737e286@PC> <443A1252.5040903@chello.nl> Message-ID: Date: Mon, 10 Apr 2006 17:55:37 +0200 From: "Americo F. Muchanga" Organization: KTH Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit In-Reply-To: <443A1252.5040903@chello.nl> User-Agent: Opera M2/8.51 (Win32, build 7712) X-Virus-Scanned: by amavisd-new at kth.se Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Huub, It is true that GMPLS addresses bandwidth management as one of the primary concerns but GMPLS as such thus include information that is aimed at enabling end notes to establish and end-to-end light path. This being the case, the constraints regarding the quality of that path from physical properties perspective is crucial to be taken in consideration. Otherwise we might need to maintain a secondary system just to deal with these effects. So it is justified to start this discussion to see if GMPLS could be extended to also carry that information. rgds, americo./ On Mon, 10 Apr 2006 10:07:46 +0200, Huub van Helvoort wrote: > Hello Marco, > > You wrote: > >> I’m a PhD student on optical network and I’m following the >> development of the GMPLS work. >> I had a recent discussion with people working on the optical >> transport network who where telling me their concern about creating >> dynamical path over trails including optical amplifiers. >> They say that cross-talk and gain fluctuation effects may limit the >> capability of fast allocating new wavelengths over those trials. > > Cross-talk and gain are physical properties and not related > to bandwidth management like GMPLS. > > IMO the concern is unjustified. > >> I just wanted to know what is your opinion about this and if is there >> some working group within the IETF already trying to challenge this >> problem. > > IMO for the physical properties you should turn to the ITU-T. > > Cheers, Huub. > -- Americo F. Muchanga Telecommunications Systems Lab (TSLAB/KTH) School of Information and Communication Technology The Royal Institute of Technology KTH Stockholm, Sweden From owner-ccamp@ops.ietf.org Mon Apr 10 12:19:43 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FSz79-0003iT-6t for ccamp-archive@ietf.org; Mon, 10 Apr 2006 12:19:43 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FSz78-0008JT-RM for ccamp-archive@ietf.org; Mon, 10 Apr 2006 12:19:43 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FSz08-000JUz-AZ for ccamp-data@psg.com; Mon, 10 Apr 2006 16:12:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [134.226.1.156] (helo=imx2.tcd.ie) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FSz06-000JUl-RC for ccamp@ops.ietf.org; Mon, 10 Apr 2006 16:12:27 +0000 Received: from Vams.imx2 (imx2.tcd.ie [134.226.1.156]) by imx2.tcd.ie (Postfix) with SMTP id ECBCD6802B; Mon, 10 Apr 2006 17:12:25 +0100 (IST) Received: from imx2.tcd.ie ([134.226.1.156]) by imx2.tcd.ie ([134.226.1.156]) with SMTP (gateway) id A0172EE9F56; Mon, 10 Apr 2006 17:12:25 +0100 Received: from PC (ntrg023.cs.tcd.ie [134.226.55.23]) by imx2.tcd.ie (Postfix) with ESMTP id E76216802B; Mon, 10 Apr 2006 17:12:25 +0100 (IST) From: "Marco Ruffini" To: "'Kireeti Kompella'" Cc: Subject: RE: GMPLS dynamics vs. issues with optical amplifiers Date: Mon, 10 Apr 2006 17:12:20 +0100 Message-ID: <002701c65cb9$8b38abd0$1737e286@PC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Importance: Normal In-Reply-To: <20060410081618.F68964@kummer.juniper.net> X-AntiVirus-Status: MessageID = A1172EE9F56 X-AntiVirus-Status: Host: imx2.tcd.ie X-AntiVirus-Status: Action Taken: X-AntiVirus-Status: NONE X-AntiVirus-Status: Checked by TCD Vexira. (version=1.56.3 VDF=8.1143) Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Hi, My understanding is that supposing that the optical path can be = physically allocated (e.g. none of the optical trails included in the path get = blocked for physical constraint reasons), there must be an adaptation in the operative parameters of the optical amplifiers to avoid that the setup = of a new wavelength could disturb the signals brought by the other = wavelengths in the same fiber. So on one hand GMPLS should consider if there is any blocking physical constraint that may impair the allocating of a new wavelength on a = specified path. On the other hand it should be considered how long it would take to the transport layer to adapt all the physical parameter in the path to = include a new wavelength on the fiber without disturbing the existing signals (I imagine this could be quite a lengthy process if more amplifiers are cascaded, like in a long haul system for example). This issue I think = would put a lower limit to the reconfiguration-time of new optical paths. =20 Marco -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net]=20 Sent: 10 April 2006 16:31 To: Marco Ruffini Cc: ccamp@ops.ietf.org Subject: Re: GMPLS dynamics vs. issues with optical amplifiers=20 Hi Marco, On Mon, 10 Apr 2006, Marco Ruffini wrote: > I'm a PhD student on optical network and I'm following the development = of > the GMPLS work. > > I had a recent discussion with people working on the optical transport > network who where telling me their concern about creating dynamical = path > over trails including optical amplifiers. > > They say that cross-talk and gain fluctuation effects may limit the > capability of fast allocating new wavelengths over those trials. We've talked on and off about these in CCAMP, and there have been=20 drafts to describe some of the various optical impairments to consider. In the GMPLS structure defined so far, there are link attributes (such=20 as metrics and bandwidth), and typically, these can be combined simply=20 to get a functioning path. Thus, for metrics, the combining function=20 is summation, and for bandwidth, the function is "min". To accommodate attributes that are not carried as TE extensions today,=20 we may have to add node attributes (say for dB loss across a mirror=20 complex). We may also have to linearize impairments, or define how=20 they are composed across links and nodes; this is not always easy to do. You say "fast allocating new wavelengths". I would have thought that=20 the issue is not how fast the allocation is, but whether the=20 allocation and ultimately, the optical LSP setup, is successful taking=20 into account optics and physics. Kireeti. ------- From ewqq@yahoo.co.jp Mon Apr 10 17:19:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FT3n9-0005oE-PX for ccamp-archive@ietf.org; Mon, 10 Apr 2006 17:19:23 -0400 Received: from [218.24.126.49] (helo=ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FT3n7-0004aX-9I for ccamp-archive@ietf.org; Mon, 10 Apr 2006 17:19:23 -0400 To: From: =?iso-2022-jp?B?VFJT?= Subject: =?iso-2022-jp?B?GyRCP2gkSiQqNzskNSRzQyMkTj82JGtJcSQkGyhC?= MIME-Version: 1.0 Reply-To: Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 4.3 (++++) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed "$B0{$`(B"$BBG$D(B"$BGc$&(B"$B!&!&!&8=Be$O%W%i%9(B"$B?2$k(B"$BM7$V(B $BCK$N%(%s%?!<%F%$%a%s%H(B http://play-boy-host.com/katsuxing/ $BLd!K(B menmen.kezkassette@laposte.net From das@yahoo.co.jp Tue Apr 11 07:36:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTHAl-0005kn-4H for ccamp-archive@ietf.org; Tue, 11 Apr 2006 07:36:39 -0400 Received: from [221.200.153.182] (helo=ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FTHAj-0005gu-Sc for ccamp-archive@ietf.org; Tue, 11 Apr 2006 07:36:39 -0400 To: From: =?iso-2022-jp?B?QVNE?= Subject: =?iso-2022-jp?B?GyRCP2gkSiQqNzskNSRzQyMkTj82JGtJcSQkGyhC?= MIME-Version: 1.0 Reply-To: Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 3.2 (+++) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed "$B0{$`(B"$BBG$D(B"$BGc$&(B"$B!&!&!&8=Be$O%W%i%9(B"$B?2$k(B"$BM7$V(B $BCK$N%(%s%?!<%F%$%a%s%H(B http://play-boy-host.com/katsuxing/ $BLd!K(B menmen.kezkassette@laposte.net From owner-ccamp@ops.ietf.org Tue Apr 11 16:45:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTPjh-0002W6-PV for ccamp-archive@ietf.org; Tue, 11 Apr 2006 16:45:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTPjf-0002Gq-1r for ccamp-archive@ietf.org; Tue, 11 Apr 2006 16:45:17 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTPa1-000GNR-CF for ccamp-data@psg.com; Tue, 11 Apr 2006 20:35:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.48] (helo=mail1.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTPZz-000GNE-5C for ccamp@ops.ietf.org; Tue, 11 Apr 2006 20:35:15 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1FTPaJ-0006rS-00 for ccamp@ops.ietf.org; Tue, 11 Apr 2006 21:35:35 +0100 Received: from Puppy ([217.158.132.10] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 11 Apr 2006 21:35:43 +0100 Message-ID: <0dcd01c65da7$771a6d20$bf849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: MPLS WG has a liaison on T-MPLS Date: Tue, 11 Apr 2006 21:35:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 11 Apr 2006 20:35:43.0781 (UTC) FILETIME=[815B6550:01C65DA7] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610 Hi, It's been pointed out to me that some folk in CCAMP might not be following the MPLS mailing list too closely. The MPLS working group has received the liaison below from the ITU-T with respect to three Recommendations that have been produced on "Transport MPLS" known as T-MPLS. T-MPLS appears to be the use of some of the facilities of an MPLS data plane in order to construct a packet-based transport network. Although no work on the control plane has been started, we may see this a prime candidate for GMPLS since the GMPLS protocol family is tuned for transport networks and supports MPLS packet data planes. Your review input on these documents is welcomed and should, in the first instance, be sent to the MPLS working group who are putting together a coordinated response. Cheers, Adrian ----- Original Message ----- From: "Greg Jones (ITU-T SG 15)" To: "George Swallow" ; "Loa Andersson" Cc: ; ; ; ; ; ; ; ; ; ; Sent: Sunday, April 02, 2006 8:59 PM Subject: [mpls] New Liaison Statement, "T-MPLS Consented Recommendations" > > Title: T-MPLS Consented Recommendations > Submission Date: 2006-04-02 > URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=207 > Please reply by 2006-04-17 > > From: Greg Jones(ITU-T SG 15) > To: IETF MPLS WG, CC: MFA Forum(George Swallow , Loa Andersson ) > Cc: info@mfaforum.org > maeda@ansl.ntt.co.jp > sjtrowbridge@lucent.com > rcallon@juniper.net > fenner@research.att.com > sob@harvard.edu > sbrim@cisco.com > mpls@lists.ietf.org > Reponse Contact: tsbsg15@itu.int > Technical Contact: Ghani.Abbas@marconi.com > mark.jones@sprint.com > betts01@nortel.com > Purpose: For action > Body: We apologize for not having sent a liaison regarding three consented Recommendations related to > T-MPLS. The intent of these Recommendations is not to change MPLS but rather to identify a > subset of existing MPLS necessary and sufficient to provide connection-oriented packet transport. > The approach to the work was to make a profile of the MPLS data plane functionalities defined in > IETF RFCs using the description of MPLS provided in G.8110 (which was approved last year). > The intended application of this profile is to provide a connection-oriented packet transport > network. > The focus of the three new recommendations is on the data plane aspects of T-MPLS. Control plane > aspects are currently for further study and the work on this subject is starting. > According to our work methodology the T-MPLS definitions are split into the three main > Recommendations that have been consented in February 2006: > * G.8110.1 dealing with the T-MPLS Architecture > * G.8112 dealing with T-MPLS interface specification > * G.8121 dealing with T-MPLS equipment functional specification > A brief high-level introduction of the essential features and selected options for Transport MPLS > can be found in section 6/G.8110.1. > The objective of the work done by ITU-T SG15 was to define a way to use MPLS as a connection- > oriented packet-based transport solution for packet aware transport networks that can support both > packet and circuit (e.g. SDH, OTH or WDM) switching technologies under a common operation, > control and management paradigm. For this purpose T-MPLS deploys the MPLS frame format, > Client to MPLS mapping and MPLS to MPLS multiplexing and complements this with transport > network OAM (Y.1711), nested connection monitoring requiring the labels to be present up to the > final node in the network, protection switching (Y.1720/G.8131), transport network based control > and management planes, maintaining frame ordering and a restricted number of classes of > service/queues. > * MPLS has many applications and it is desirable to identify a subset of MPLS technology that > provides the necessary and sufficient functionality for transport applications. > We have indicated below some of the options we have selected :- > * In IETF RFCs the usage of PHP is optional. We decided not to use it in order to simplify OAM > procedures > * In IETF RFCs the usage of merging is optional. We decided not to use it in order to simplify > OAM procedures and also because the relative lower number of LSPs to be supported is not > considered a major scaling issue > * The usage of ECMP is optional. We decided not to use it in order to simplify OAM procedures > * Leaving labels 16-31 for further study was seen as a no change because the label allocation on a > link is defined in IETF RFCs as a local matter for any MPLS device. > We are not expecting that the current version of the specification is going to create any > interoperability issue. We envisage two possible cases of interoperability: > 1. Interoperability between a T-MPLS box and an existing full-featured and fully configurable > MPLS box can be solved by configuring the MPLS box to use the same options selected by T- > MPLS (T-MPLS being a profile of MPLS this should be possible). In this case the link between > the two boxes is a T-MPLS link and in the scope of our Recommendations. > 2. Interoperability between a transport platform supporting T-MPLS and an existing MPLS box > that uses a different option selection than T-MPLS, should be solved by the transport platform. > In this case the link between the transport platform and the MPLS box is not a T-MPLS link and > therefore it is outside the scope of T-MPLS recommendations. We are looking for cooperation > with IETF to develop the detailed specification of this case. > Please find attached the text of the consented Recommendations. Please note that some minor > modifications may be made to these draft Recommendations as a result of comments made during > the approval process > We will appreciate your comments and suggestions in relation to the initial scope of T-MPLS as a > packet transport network technology. > We are planning to review your comments during the next meeting that is planned in Kobe (Japan) > on 22-27 April 2006. Results of the comments will be included into our future work (e.g. corrigenda > or amendments) on T-MPLS Recommendations. Amendments of T-MPLS Recommendations are > already in our plan for the next SG15 plenary meeting in November 2006.We are looking forward > for future cooperation with you in T-MPLS data plane and control plane evolution. > > Attachments: Consented Text of G.8110.1, G.8112, G.8121 > Attachment(s): > Consented Text of G.8110.1 (https://datatracker.ietf.org/documents/LIAISON/file288.zip) > Consented Text of G.8112 (https://datatracker.ietf.org/documents/LIAISON/file289.zip) > Consented Text of G.8121 (https://datatracker.ietf.org/documents/LIAISON/file290.zip) > > > > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > > From owner-ccamp@ops.ietf.org Tue Apr 11 18:55:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTRlP-0004rU-Ey for ccamp-archive@ietf.org; Tue, 11 Apr 2006 18:55:11 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTRlO-0008BC-4X for ccamp-archive@ietf.org; Tue, 11 Apr 2006 18:55:11 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTRgV-000PT7-2V for ccamp-data@psg.com; Tue, 11 Apr 2006 22:50:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.53.84] (helo=willow.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTRgU-000PRs-9B for ccamp@ops.ietf.org; Tue, 11 Apr 2006 22:50:06 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k3BMo29W007400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Apr 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FTRgP-0007Eq-VR; Tue, 11 Apr 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-lsr-mib-12.txt Message-Id: Date: Tue, 11 Apr 2006 18:50:01 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base Author(s) : T. Nadeau, A. Farrel Filename : draft-ietf-ccamp-gmpls-lsr-mib-12.txt Pages : 42 Date : 2006-4-11 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor a Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-lsr-mib-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-11155238.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-lsr-mib-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-11155238.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Tue Apr 11 18:55:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTRlT-0004rv-9W for ccamp-archive@ietf.org; Tue, 11 Apr 2006 18:55:15 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTRlS-0008BM-Tu for ccamp-archive@ietf.org; Tue, 11 Apr 2006 18:55:15 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTRgW-000PTM-0o for ccamp-data@psg.com; Tue, 11 Apr 2006 22:50:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.53.70] (helo=oak.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTRgV-000PSL-96 for ccamp@ops.ietf.org; Tue, 11 Apr 2006 22:50:07 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k3BMo2BX024802 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Apr 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FTRgP-0007Eg-UA; Tue, 11 Apr 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-tc-mib-10.txt Message-Id: Date: Tue, 11 Apr 2006 18:50:01 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management Author(s) : T. Nadeau, A. Farrel Filename : draft-ietf-ccamp-gmpls-tc-mib-10.txt Pages : 9 Date : 2006-4-11 This document defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Generalized Multiprotocol Label Switching (GMPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in GMPLS related MIB modules that would otherwise define their own representations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-tc-mib-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-11154635.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-tc-mib-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-11154635.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Wed Apr 12 05:39:49 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTbpF-0005Yu-IC for ccamp-archive@ietf.org; Wed, 12 Apr 2006 05:39:49 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTbpF-0006AX-29 for ccamp-archive@ietf.org; Wed, 12 Apr 2006 05:39:49 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTbgI-0003lM-Hq for ccamp-data@psg.com; Wed, 12 Apr 2006 09:30:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [209.173.57.70] (helo=pine.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTbgG-0003l9-Os for ccamp@ops.ietf.org; Wed, 12 Apr 2006 09:30:33 +0000 Received: from ietf.org (stiedprweb1.va.neustar.com [10.91.34.42]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k3C9TxvP026321 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 12 Apr 2006 09:30:02 GMT Received: from mirror by ietf.org with local (Exim 4.43) id 1FTbfj-0000jK-Tg; Wed, 12 Apr 2006 05:29:59 -0400 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: Greg Jones Cc: Kam Lam , Malcolm Betts , Stephen Trowbridge , Scott Bradner , Ross Callon , Bill Fenner , Kireeti Kompella , CCAMP Mailing List , Adrian Farrel , Adrian Farrel , statements@ietf.org From: Adrian Farrel(IETF CCAMP WG) Subject: New Liaison Statement, "Recently published IETF RFCs relevant to GMPLS, Optical Transport Networks, and Packet Transport Networks" Message-Id: Date: Wed, 12 Apr 2006 05:29:59 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 Title: Recently published IETF RFCs relevant to GMPLS, Optical Transport Networks, and Packet Transport Networks Submission Date: 2006-04-12 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=213 From: Adrian Farrel(IETF CCAMP WG) To: ITU-T SG15(Greg Jones ) Cc: Kam Lam Malcolm Betts Stephen Trowbridge Scott Bradner Ross Callon Bill Fenner Kireeti Kompella CCAMP Mailing List Reponse Contact: Adrian Farrel Technical Contact: Adrian Farrel Purpose: For information Body: Recently published IETF RFCs relevant to GMPLS, Optical Transport Networks, and Packet Transport Networks The IETF's CCAMP working group is pleased to inform Study Group 15 of the ITU-T of the publication of several new RFCs that are relevant to the work that you are doing with optical and packet transport networks. Several of these RFCs received useful review and input from Study Group 15 participants for which CCAMP would like to express its thanks. RFC 4257 http://www.ietf.org/rfc/rfc4257.txt Title Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks Abstract Generalized Multi-Protocol Label Switching (GMPLS) is a suite of protocol extensions to MPLS to make it generally applicable, to include, for example, control of non packet-based switching, and particularly, optical switching. One consideration is to use GMPLS protocols to upgrade the control plane of optical transport networks. This document illustrates this process by describing those extensions to GMPLS protocols that are aimed at controlling Synchronous Digital Hierarchy (SDH) or Synchronous Optical Networking (SONET) networks. SDH/SONET networks make good examples of this process for a variety of reasons. This document highlights extensions to GMPLS-related routing protocols to disseminate information needed in transport path computation and network operations, together with (G)MPLS protocol extensions required for the provisioning of transport circuits. New capabilities that an GMPLS control plane would bring to SDH/SONET networks, such as new restoration methods and multi-layer circuit establishment, are also discussed. RFC 4258 http://www.ietf.org/rfc/rfc4258.txt Title Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON) Abstract The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting Time Division Multiplexing (TDM) connections including Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) and Optical Transport Networks (OTNs). This document concentrates on the routing requirements placed on the GMPLS suite of protocols in order to support the capabilities and functionalities of an Automatically Switched Optical Network (ASON) as defined by the ITU-T. RFC 4327 http://www.ietf.org/rfc/rfc4327.txt Title Link Management Protocol (LMP) Management Information Base (MIB) Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling the Link Management Protocol (LMP). RFC 4328 http://www.ietf.org/rfc/rfc4328.txt Title Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control Abstract This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling documents. It describes the technology- specific information needed to extend GMPLS signaling to control Optical Transport Networks (OTN); it also includes the so-called pre-OTN developments. RFC 4394 http://www.ietf.org/rfc/rfc4394.txt Title A Transport Network View of the Link Management Protocol (LMP) Abstract The Link Management Protocol (LMP) has been developed as part of the Generalized MPLS (GMPLS) protocol suite to manage Traffic Engineering (TE) resources and links. The GMPLS control plane (routing and signaling) uses TE links for establishing Label Switched Paths (LSPs). This memo describes the relationship of the LMP procedures to 'discovery' as defined in the International Telecommunication Union (ITU-T), and ongoing ITU-T work. This document provides an overview of LMP in the context of the ITU-T Automatically Switched Optical Networks (ASON) and transport network terminology and relates it to the ITU-T discovery work to promote a common understanding for progressing the work of IETF and ITU-T. RFC 4397 http://www.ietf.org/rfc/rfc4397.txt Title A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture Abstract Generalized Multiprotocol Label Switching (GMPLS) has been developed by the IETF to facilitate the establishment of Label Switched Paths (LSPs) in a variety of data plane technologies and across several architectural models. The ITU-T has specified an architecture for the control of Automatically Switched Optical Networks (ASON). This document provides a lexicography for the interpretation of GMPLS terminology within the context of the ASON architecture. It is important to note that GMPLS is applicable in a wider set of contexts than just ASON. The definitions presented in this document do not provide exclusive or complete interpretations of GMPLS concepts. This document simply allows the GMPLS terms to be applied within the ASON context. RFC 4426 http://www.ietf.org/rfc/rfc4426.txt Title Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification Abstract This document presents a functional description of the protocol extensions needed to support Generalized Multi-Protocol Label Switching (GMPLS)-based recovery (i.e., protection and restoration). Protocol specific formats and mechanisms will be described in companion documents. RFC 4427 http://www.ietf.org/rfc/rfc4427.txt Title Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) Abstract This document defines a common terminology for Generalized Multi- Protocol Label Switching (GMPLS)-based recovery mechanisms (i.e., protection and restoration). The terminology is independent of the underlying transport technologies covered by GMPLS. RFC 4428 http://www.ietf.org/rfc/rfc4428.txt Title Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) Abstract This document provides an analysis grid to evaluate, compare, and contrast the Generalized Multi-Protocol Label Switching (GMPLS) protocol suite capabilities with the recovery mechanisms currently proposed at the IETF CCAMP Working Group. A detailed analysis of each of the recovery phases is provided using the terminology defined in RFC 4427. This document focuses on transport plane survivability and recovery issues and not on control plane resilience and related aspects. All IETF RFCs can be downloaded for free from http://www.ietf.org/rfc.html The current work plan and progress status of the CCAMP working group can be viewed at http://www.ietf.org/html.charters/ccamp-charter.html The CCAMP working group welcomes questions and discussion about all of its work from individuals or organisations. The CCAMP mailing list is open to anyone. Details of subscription can be found on the CCAMP charter page. Regards, Adrian Farrel and Kireeti Kompella CCAMP working group chairs Attachment(s): No document has been attached From owner-ccamp@ops.ietf.org Wed Apr 12 05:55:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTc4M-0004I5-8B for ccamp-archive@ietf.org; Wed, 12 Apr 2006 05:55:26 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTc4M-0006ZH-0H for ccamp-archive@ietf.org; Wed, 12 Apr 2006 05:55:26 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTc0T-000523-16 for ccamp-data@psg.com; Wed, 12 Apr 2006 09:51:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [128.87.251.114] (helo=smtpmast05.marconi.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTc0P-00051n-RV for ccamp@ops.ietf.org; Wed, 12 Apr 2006 09:51:22 +0000 Received: from cvdgwy02.uk.marconicomms.com (cvis27.uk.marconicomms.com [128.87.251.110]) by smtpmast05.marconi.com (8.12.11.20060308/8.12.11) with ESMTP id k3C9p9iD000618 for ; Wed, 12 Apr 2006 10:51:15 +0100 (BST) (envelope-from Diego.Caviglia@marconi.com) Sensitivity: Subject: T-MPLS comments To: ccamp@ops.ietf.org X-Mailer: Lotus Notes Release 5.0.12 February 13, 2003 Message-ID: From: "Diego Caviglia" Date: Wed, 12 Apr 2006 11:50:44 +0200 X-MIMETrack: Serialize by Router on CVDGWY02/S/EXT/MC1(Release 5.0.13a |April 8, 2004) at 12/04/2006 10:51:14 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 A couple of quick comment to the T-MPLS specs. G.8110.1 "Bidirectional LSPs are supported by associating two unidirectional LSPs in the data plane" [dc] This sentence seems to exclude the possibility to have a simmetric bi-directional LSP. If GMPLS is used as a control plane for T-MPLS should be good to include the possibility to have simmetric bidirectional LSPs given that GMPLS support the set-up of that kind of circuits. Moreover having a single 5-tuple identifiyng a bidirectional LSP simplify the maintenence of bi-dicectional circuits. "Both global and per interface label space are supported" [dc] RFC 3031 defines the two kind of label scope as: 1 per-interface label space 2 per-platform label space. I think that the definition of 3031 should be also used in G.8110.1, given that the term global is misleading. Regards Diego From owner-ccamp@ops.ietf.org Wed Apr 12 11:10:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTgzY-0001QG-AG for ccamp-archive@ietf.org; Wed, 12 Apr 2006 11:10:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTgzY-0000zZ-1R for ccamp-archive@ietf.org; Wed, 12 Apr 2006 11:10:48 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTgmi-000Ogf-1U for ccamp-data@psg.com; Wed, 12 Apr 2006 14:57:32 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [193.10.152.67] (helo=oberon.imc.kth.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTgmf-000OgQ-2Y for ccamp@ops.ietf.org; Wed, 12 Apr 2006 14:57:30 +0000 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.13.1/8.13.1) with ESMTP id k3CElUqo032027 for ; Wed, 12 Apr 2006 16:47:30 +0200 Received: from [127.0.0.1] ([172.16.2.231]) by mail1.imc.kth.se; Wed, 12 Apr 2006 16:56:38 +0200 Message-ID: <443D1523.1050400@pi.se> Date: Wed, 12 Apr 2006 16:56:35 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Greg Jones CC: statements@ietf.org, Stephen Trowbridge , Ghani Abbas , Mark Jones , Malcolm Betts , Yoichi Maeda , Ross Callon , Bill Fenner , Scott Bradner , George Swallow , MPLS mailing list , CCAMP mailing list Subject: Response to your liaison on T-MPLS Consented Recommendations Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca To: ITU-T Study Group 15 Greg Jones greg.jones@itu.int Cc: IETF statements@ietf.org Stephen Trowbridge sjtrowbridge@lucent.com Ghani Abbas Ghani.Abbas@marconi.com Mark Jones mark.jones@sprint.com Malcolm Betts betts01@nortel.com Yoichi Maeda maeda@ansl.ntt.co.jp Ross Callon rcallon@juniper.net Bill Fenner fenner@research.att.com Scott Bradner sob@harvard.edu George Swallow swallow@cisco.com MPLS mailing list mpls@lists.ietf.org CCAMP mailing list ccamp@ops.ietf.org From: IETF MPLS Working Group Response contact: Loa Andersson loa@pi.se Technical contact: Loa Andersson loa@pi.se Purpose: Response Subject: Response to your liaison on T-MPLS Consented Recommendations Thank you for liaising G.8110.1, G.8112 and G.8121 on April 2, and requesting a response by April 17. It will not be possible for the MPLS Working Group to do a comprehensive review in this short time. Our mode of operation normally gives a two week period to review (working group last call) for well-known and well-discussed documents. Since this topic is mostly new to the working group, it is our estimate that we will need a four week period. We, therefore, intend to send our comments to SG15 by May 17. We sincerely hope that it will be possible for you to accommodate this late response, and take our comments into your process. Loa Andersson and George Swallow IETF MPLS Working Group Co-Chairs -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se From owner-ccamp@ops.ietf.org Wed Apr 12 12:20:05 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTi4b-0001Db-P7 for ccamp-archive@ietf.org; Wed, 12 Apr 2006 12:20:05 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTi4a-0003Yd-D2 for ccamp-archive@ietf.org; Wed, 12 Apr 2006 12:20:05 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FThy0-0003mu-AE for ccamp-data@psg.com; Wed, 12 Apr 2006 16:13:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.49] (helo=mail2.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FThxy-0003mg-U5 for ccamp@ops.ietf.org; Wed, 12 Apr 2006 16:13:15 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1FThxu-0004fZ-00 for ccamp@ops.ietf.org; Wed, 12 Apr 2006 17:13:10 +0100 Received: from Puppy ([217.158.132.162] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 12 Apr 2006 17:13:46 +0100 Message-ID: <103d01c65e4c$0a2992e0$bf849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Draft minutes uploaded Date: Wed, 12 Apr 2006 17:05:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 12 Apr 2006 16:13:47.0046 (UTC) FILETIME=[13DDB460:01C65E4C] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Hi, Minutes from Dallas are at http://www3.ietf.org/proceedings/06mar/minutes/ccamp.html Please review and comment. Adrian From owner-ccamp@ops.ietf.org Wed Apr 12 16:17:32 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTlSA-0000KJ-Ob for ccamp-archive@ietf.org; Wed, 12 Apr 2006 15:56:39 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTlS8-00042R-VF for ccamp-archive@ietf.org; Wed, 12 Apr 2006 15:56:37 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTlLw-000Hu3-Sq for ccamp-data@psg.com; Wed, 12 Apr 2006 19:50:12 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.53.70] (helo=oak.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FTlLo-000Hrp-0I for ccamp@ops.ietf.org; Wed, 12 Apr 2006 19:50:04 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k3CJo2BX029537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 12 Apr 2006 19:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FTlLm-0002gG-3A; Wed, 12 Apr 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-14.txt Message-Id: Date: Wed, 12 Apr 2006 15:50:02 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base Author(s) : T. Nadeau, A. Farrel Filename : draft-ietf-ccamp-gmpls-te-mib-14.txt Pages : 60 Date : 2006-4-12 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Generalized Multiprotocol Label Switching (GMPLS) based traffic engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib-14.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-te-mib-14.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-te-mib-14.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-12112455.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-te-mib-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-te-mib-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-12112455.I-D@ietf.org> --OtherAccess-- --NextPart-- From opto168@led168.cn Thu Apr 13 02:47:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FTvbt-00007l-J3 for ccamp-archive@ietf.org; Thu, 13 Apr 2006 02:47:21 -0400 Received: from [218.18.23.1] (helo=led168.cn) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FTvba-0000aR-C5 for ccamp-archive@ietf.org; Thu, 13 Apr 2006 02:47:21 -0400 From: "opto" Subject: =?GB2312?B?16jStcn6svq3ornitv68q7ncMTQ6NDY6NDk=?= To: ccamp-archive@ietf.org Content-Type: text/plain;charset="GB2312" Content-Transfer-Encoding: 8bit Reply-To: optods8@led168.cn Date: Thu, 13 Apr 2006 14:46:55 +0800 X-Priority: 3 X-Mailer: FoxMail 4.0 beta 2 [cn] X-Spam-Score: 2.3 (++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 2006-04-13 ÄúºÃ! LED·â×°ÐÐÒµ¼¸ºõ¶¼ÊÇ͸Ã÷µÄÁË,ÏÖÔÚÆ´µÄÊDzúÆ·ÖÊÁ¿,²úÆ·ÖÊÁ¿¿¿ÈýÒªËØ: Ò»¸öÊÇоƬµÄÖÊÁ¿,Õâ¸ö¿¿µÄÊDzɹºµÄÑÛ¹â,¼°Ó빩»õÉ̵ĹØϵÈçºÎ, ¶þ¸öÊÇÉú²ú¹ý³ÌÖеĹÜÀí,·Ç³£µÄÖØÒª,Èç¹ûÁ¼Æ·ÂÊ´ïµ½99.99%,˵Ã÷Éú²ú³öÀ´µÄ²úÆ··Ç³£µÄºÃ.Á¼ÂÊ´ïµ½80%µÄ,²âÊÔ¹ý²»´í,Ò²²»¸ÒÒª,ÉúŽñÌìºÃ,Ã÷Ìì¾Íµ¹! Èý¸öÊÇÔ­²ÄÁÏÅä¼þµÄÑ¡¹º£¬½ºË®ÈçºÎ£¿Ö§¼ÜÈçºÎ£¿ºÃµÄÔ­²ÄÁÏÒ²¾ö¶¨Á˲úÆ·ºÃµÄÖÊÁ¿ ÎÒÃǹ«Ë¾Òª²»¾Í²»×ö,Òª×ö,¾ÍÒ»¶¨Òª×öÆ·ÅÆLED·â×°¹«Ë¾.ÓÐЩ¹«Ë¾Âô1¿éÇ®µÄLED,ÓõÄÊǼ¸·ÖÇ®µÄоƬ×öµÄ,ÎÒÃǾø¶Ô²»»áÕâÑù×Ó×ö.Ïà¶Ô¼Û¸ñ,Ïà¶Ô²úÆ·! ÎÒÃǹ«Ë¾µÄ°×¹â×öµÃÌرðºÃ£¬É«ÌرðµÄ´¿£¬ Ò»¸öÊÇоƬ£¬½ºË®¼°Ö§¼Ü²ÄÁÏÓõĺ㬠¶þ¸öÊÇ·â×°¹ý³ÌÖеÄϸÖ³̶ȷdz£µÄÑϽ÷£¡ÓÐЩ¹«Ë¾³ÆÓ«¹â·ÛÓõijӾ«Ï¸µ½0.01¿Ë£¬¶øÎÒ˾ÓõÄÊÇ0.001¿ËÀ´³ÆµÄ£¬ ²¢ÇÒ£¬ÓÐרÈËά»¤£¬ÆÕͨÈ˲»ÄÜËæ±ãÅö´¥£¬Í¬Ê±£¬Ã¿´Î³ÆÁ¿Ê±¶¼Òª¼ìÑé³Ó³ÆµÄ׼ȷÐÔÈçºÎ£¬ÕâÊÇ×ö°×¹âµÄ×î¹Ø¼üÖ®´¦¡£ ͬʱ£¬»¹Óкܶà¹Ø¼üÖ®´¦£¬ÎÒÃǹ«Ë¾¶¼×öµÃºÜºÃ£¬±ÈÈçµ÷ºÃµÄÓ«¹â·ÛʲôʱºòÒ»¶¨ÒªÓÃÍ꣬ÕⶼÊǺܽ²¾¿µÄ¡£ ÓÉÓÚÎÒÃǹ«Ë¾×¨ÃÅÑо¿Õâ¸ö°×¹âºÜ¾ÃÁË£¬Òò´Ë£¬¶ÔÓÚ×ö°×¹âLEDÌرðµÄרҵ£¬×ö³öÀ´µÄÉ«ÌرðµÄ´¿£¬²¢ÇÒ£¬Îȶ¨ÐÔ¼°ÊÙÃüÒ²·Ç³£µÄ°ô£¡ ÓÐÐèÇóÕßÇ뾡¿ìÁªÏµÎÒ¡£ ÁªÏµÈË: ÕÅÏÈÉú 13380343090 e-mail: szled168@yahoo.com.cn Web address: http:// www.led168.cn (ÈçÓдòÈÅÖ®´¦,¾´ÇëÔ­ÁÂ!Çë»ØÐŵ½szled168@yahoo.com.cnÈ¡Ïû,лл!) 22905 From owner-ccamp@ops.ietf.org Fri Apr 14 15:58:06 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUUQg-00011t-TT for ccamp-archive@ietf.org; Fri, 14 Apr 2006 15:58:06 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUUQg-0006cN-HX for ccamp-archive@ietf.org; Fri, 14 Apr 2006 15:58:06 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUUIu-000CGc-8z for ccamp-data@psg.com; Fri, 14 Apr 2006 19:50:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.57.70] (helo=pine.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUUIt-000CFm-Fj for ccamp@ops.ietf.org; Fri, 14 Apr 2006 19:50:03 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k3EJo1vP000887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 14 Apr 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FUUIr-0004gT-Jp; Fri, 14 Apr 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ospf-mib-00.txt Message-Id: Date: Fri, 14 Apr 2006 15:50:01 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Extensions to the OSPF Management Information Base in support of GMPLS Author(s) : T. Otani, et al. Filename : draft-ietf-ccamp-gmpls-ospf-mib-00.txt Pages : Date : 2006-4-14 This memo defines the Management Information Base (MIB) objects in order to manage OSPF routing information with extension in support of Multi-protocol label switching (MPLS) as well as Generalized MPLS (GMPLS) for use with network management protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ospf-mib-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-ospf-mib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-ospf-mib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-14144538.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-ospf-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ospf-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-14144538.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Fri Apr 14 18:09:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUWTa-0007rF-Mb for ccamp-archive@ietf.org; Fri, 14 Apr 2006 18:09:14 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUWTZ-0002NE-EE for ccamp-archive@ietf.org; Fri, 14 Apr 2006 18:09:14 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUWPY-000IwK-K5 for ccamp-data@psg.com; Fri, 14 Apr 2006 22:05:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.49] (helo=mail2.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUWPX-000IvZ-31 for ccamp@ops.ietf.org; Fri, 14 Apr 2006 22:05:03 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1FUWPS-0003Jq-00 for ccamp@ops.ietf.org; Fri, 14 Apr 2006 23:04:58 +0100 Received: from Puppy ([217.158.132.56] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Apr 2006 23:05:35 +0100 Message-ID: <157101c6600f$87b1f300$bf849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Thomas D. Nadeau" Subject: GMPLS MIB updates Date: Fri, 14 Apr 2006 23:03:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 14 Apr 2006 22:05:36.0234 (UTC) FILETIME=[8EBFACA0:01C6600F] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Hi, The three recent updates posted by Tom complete (we believe) the revisions from MIB Doctor review. the changes were many, but completely editorial. You may want to have a skim to see what you think, but we do not see the need for a further WG last call. Thanks, Adrian From owner-ccamp@ops.ietf.org Fri Apr 14 18:19:40 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUWdg-0005RC-21 for ccamp-archive@ietf.org; Fri, 14 Apr 2006 18:19:40 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FUWde-0002cz-PV for ccamp-archive@ietf.org; Fri, 14 Apr 2006 18:19:40 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUWZ3-000JTT-U4 for ccamp-data@psg.com; Fri, 14 Apr 2006 22:14:53 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.49] (helo=mail2.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FUWZ3-000JTH-8x for ccamp@ops.ietf.org; Fri, 14 Apr 2006 22:14:53 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1FUWYy-0003cK-00 for ccamp@ops.ietf.org; Fri, 14 Apr 2006 23:14:48 +0100 Received: from Puppy ([217.158.132.56] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 14 Apr 2006 23:15:25 +0100 Message-ID: <15a101c66010$e75e2d90$bf849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: , "Tomohiro Otani" , "Thomas D. Nadeau" , "'Kireeti Kompella'" , "Acee Lindem" , Subject: New OSPF MIB module for TE and GMPLS Date: Fri, 14 Apr 2006 23:14:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 14 Apr 2006 22:15:26.0437 (UTC) FILETIME=[EE898150:01C66010] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Hi, As originators of the GMPLS extensions for OSPF (RFC4203) the CCAMP working group has a responsibility to develop a MIB module for the management and modelling of these extensions. At the same time, we observed that there is currently no MIB module for the TE extensions described in RFC3630. We have started a work item in draft-ietf-ccamp-gmpls-ospf-mib-00.txt to provide this support and we would welcome ongoing review and input from the OSPF working group. Comments on the CCAMP mailing list or direct to the authors or chairs. If there is a strong feeling that the work should be in the OSPF working group we are open to negotiation. In particular, I notice that draft-ietf-ospf-mib-update-10.txt is still in progress, Thanks, Adrian From das@yahoo.co.jp Sat Apr 15 00:53:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FUcnF-0006Vw-TH for ccamp-archive@ietf.org; Sat, 15 Apr 2006 00:53:57 -0400 Received: from [221.200.153.245] (helo=ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FUcnE-0007Qs-NF for ccamp-archive@ietf.org; Sat, 15 Apr 2006 00:53:57 -0400 To: From: =?iso-2022-jp?B?QVNE?= Subject: =?iso-2022-jp?B?GyRCOGYwRkZiGyhC?= MIME-Version: 1.0 Reply-To: Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.7 (++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea $BB?J,$*5$$KF~$jD:$1$k$H;W$$$^$9!#(B http://qq817.com/af09176/ $BLd!K(B ann_ann_lovely@yahoo.co.jp From enyajb123@njdyfdc.com Mon Apr 17 06:41:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVRAx-0008Ol-5a for ccamp-archive@ietf.org; Mon, 17 Apr 2006 06:41:47 -0400 Received: from host199-35.pool8256.interbusiness.it ([82.56.35.199] helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FVRAr-0006CN-6D for ccamp-archive@ietf.org; Mon, 17 Apr 2006 06:41:43 -0400 Message-ID: <000001c66236$22e7a400$0100007f@localhost> From: "Isaac Nelson" To: Subject: Fast Track Degree Program Date: Mon, 17 Apr 2006 12:41:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1251" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.1 (++++) X-Scan-Signature: d6b246023072368de71562c0ab503126 NO ONE is turned down. According to the U.S. Census Bureau, with the following degrees, here's how much you can expect to make in your lifetime: High School Diploma: $1,100,000 Bachelor's Degree: $2,100,000 Master's Degree: $2,500,000 Doctorate: $4,400,000 You Need a Better Degree, and we can Help! Obtain degrees from Prestigious non-accredited Universities based on you life experience. NO ONE is turned down. Call Now 7 days a week. "1-718-504-5376" From owner-ccamp@ops.ietf.org Mon Apr 17 18:56:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVcdt-0003aO-Rj for ccamp-archive@ietf.org; Mon, 17 Apr 2006 18:56:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVcdt-0002bl-Fa for ccamp-archive@ietf.org; Mon, 17 Apr 2006 18:56:25 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVcXo-000KOf-LH for ccamp-data@psg.com; Mon, 17 Apr 2006 22:50:08 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.53.84] (helo=willow.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVcXo-000KOR-0y for ccamp@ops.ietf.org; Mon, 17 Apr 2006 22:50:08 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k3HMo29W004317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 17 Apr 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FVcXi-0005Ha-3D; Mon, 17 Apr 2006 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt Message-Id: Date: Mon, 17 Apr 2006 18:50:02 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in support of Calls Author(s) : D. Papadimitriou, A. Farrel Filename : draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt Pages : 27 Date : 2006-4-17 In certain networking topologies it may be advantageous to maintain associations between endpoints and key transit points to support an instance of a service. Such associations are known as Calls. A Call does not provide the actual connectivity for transmitting user traffic, but only builds a relationship by which subsequent connections may be made. In Generalized MPLS (GMPLS) such connections are known as Label Switched Paths (LSPs). This document specifies how GMPLS RSVP-TE signaling may be used and extended to support Calls. These mechanisms provide full and logical Call/Connection separation. The mechanisms proposed in this document are applicable to any environment (including multi-area), and for any type of interface: packet, layer-2, time-division multiplexed, lambda or fiber switching. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-17155457.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-17155457.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Tue Apr 18 04:15:41 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FVlN7-0003Vf-BU for ccamp-archive@ietf.org; Tue, 18 Apr 2006 04:15:41 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FVlN6-0006ma-22 for ccamp-archive@ietf.org; Tue, 18 Apr 2006 04:15:41 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVlAY-0009PN-E1 for ccamp-data@psg.com; Tue, 18 Apr 2006 08:02:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00 autolearn=ham version=3.1.1 Received: from [193.10.152.67] (helo=oberon.imc.kth.se) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FVlAW-0009Ok-FY for ccamp@ops.ietf.org; Tue, 18 Apr 2006 08:02:40 +0000 Received: from mail1.imc.kth.se (mail1.imc.kth.se [193.10.152.140]) by oberon.imc.kth.se (8.13.1/8.13.1) with ESMTP id k3I7qSb3014104 for ; Tue, 18 Apr 2006 09:52:28 +0200 Received: from [127.0.0.1] ([172.16.2.224]) by mail1.imc.kth.se; Tue, 18 Apr 2006 10:01:40 +0200 Message-ID: <44449CE2.8040104@pi.se> Date: Tue, 18 Apr 2006 10:01:38 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: mpls@ietf.org, ccamp Subject: mpls wg comments on T-MPLS - schedule Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Working Group(s), (after agreement with the ccamp co-chairs this is sent to the ccamp list also) after discussion with representatives for SG15 and Q12/15 we've some tentative procedure to get our comments on Transport-MPLS into the ITU process. EoB today (Tuesday April 18th) we will give them a list of areas where we have concerns (copy to the mpls mailing list). "End of Business day" will be understood as 11.59PM here in Stockholm (corresponds to approx. 6PM in Boston). We will abstract the list from comments sent to the mpls mailling list. On Friday (April 21st) we will send them a more consolidated list, they have a meeting in Kobe the following week. However, the formal working group comments will be sent to them May 17th. Please send (furthher) comments on G.8110.1 (https://datatracker.ietf.org/documents/LIAISON/file288.zip) G.8112 (https://datatracker.ietf.org/documents/LIAISON/file289.zip) G.8121 (https://datatracker.ietf.org/documents/LIAISON/file290.zip) to the mpls working group mailing list. /Loa and George -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se From owner-ccamp@ops.ietf.org Wed Apr 19 20:28:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWN1z-0004HM-6f for ccamp-archive@ietf.org; Wed, 19 Apr 2006 20:28:23 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWN1y-0001Wy-PE for ccamp-archive@ietf.org; Wed, 19 Apr 2006 20:28:23 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FWMuw-000J7p-5t for ccamp-data@psg.com; Thu, 20 Apr 2006 00:21:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.3 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, HOT_NASTY autolearn=ham version=3.1.1 Received: from [80.68.34.49] (helo=mail2.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FWMuu-000J7c-KK for CCamp@ops.ietf.org; Thu, 20 Apr 2006 00:21:04 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail2.noc.data.net.uk with esmtp (Exim 3.36 #1) id 1FWMuo-00020Q-00 for CCamp@ops.ietf.org; Thu, 20 Apr 2006 01:20:58 +0100 Received: from Puppy ([125.200.105.80] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 20 Apr 2006 01:21:32 +0100 Message-ID: <064b01c66410$559a7cc0$2101fe0a@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: IESG Statement: Normative and Informative References Date: Thu, 20 Apr 2006 01:18:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-OriginalArrivalTime: 20 Apr 2006 00:21:32.0578 (UTC) FILETIME=[605FC020:01C66410] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.6 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Hi, Good advice from the IESG on how to classify your references in I-Ds. Adrian ----- Original Message ----- From: "IESG Secretary" To: "IETF Announcement list" Sent: Wednesday, April 19, 2006 2:50 PM Subject: IESG Statement: Normative and Informative References > Normative and Informative References > > Nearly all RFCs contain citations to other documents, and these are > listed in a References section near the end of the RFC. There are many > styles for references, and the RFCs have one of their own. Please > follow the reference style used in recent RFCs. Please note that for > documents that have been assigned an STD or BCP number, the number must > be included in the reference. > > Within an RFC, references to other documents fall into two general > categories: "normative" and "informative". Normative references specify > documents that must be read to understand or implement the technology > in the new RFC, or whose technology must be present for the technology > in the new RFC to work. An informative reference is not normative; > rather, it only provides additional information. For example, an > informative reference might provide background or historical > information. Informative references are not required to implement the > technology in the RFC. > > Note 1: Even references that are relevant only for optional features > must be classified as normative if they meet the above conditions for > normative references. > > Note 2: It is not considered necessary to cite basic specifications > that may be safely assumed to be known to practitioners (for example, > RFC 791 need not be cited in every specification that mentions IPv4). > > Note 3: The normative/informative distinction is relevant in > any document that amounts to a technical specification, even > if its intended status is Experimental or Informational. > > Note 4: Normative references in RFCs cannot be to "work in progress" > documents such as Internet Drafts. Drafts with such references will > not be published as RFCs until the references are also published. > > The distinction between normative and informative references is often > important. The IETF standards process according to RFC 2026 and RFC 3967, > and the RFC Editor publication process, both need to know whether a > reference to a work in progress is normative. An RFC cannot be published > until all of the documents that it lists as normative references have been > published. In practice, this often results in the simultaneous publication > of a group of interrelated RFCs. > > For these reasons, the IESG and the RFC Editor have established > guidelines that will request separate reference lists for normative > and informative references in Internet Drafts and RFCs. For example, > if both types are present, there would be two reference subsections, > numbered s.1 and s.2 for example: > > s.1. Normative References > > xxx > ... > xxx > > s.2. Informative References > > xxx > ... > xxx > > Of course, if there is only one type of reference, only one > section is needed. > > The IESG > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > > From owner-ccamp@ops.ietf.org Thu Apr 20 01:35:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWRpJ-0002dg-UJ for ccamp-archive@ietf.org; Thu, 20 Apr 2006 01:35:37 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWRpH-0000BK-CI for ccamp-archive@ietf.org; Thu, 20 Apr 2006 01:35:35 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FWRcD-00078D-9l for ccamp-data@psg.com; Thu, 20 Apr 2006 05:22:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,DNS_FROM_RFC_ABUSE,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.86.89.69] (helo=elasmtp-mealy.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FWRcC-00077z-7p for ccamp@ops.ietf.org; Thu, 20 Apr 2006 05:22:04 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=dfeW4A+f6OwpgyuxF6NLRzGEPMxhxcQ4JrUiSuHlRuZ5RdETfY4SlojUW2mCBhmf; h=Received:Message-ID:From:To:Cc:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [67.100.203.57] (helo=jlucianilaptop) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1FWRc9-0005U3-CZ; Thu, 20 Apr 2006 01:22:01 -0400 Message-ID: <008101c66411$ed40b3e0$0500a8c0@jlucianilaptop> From: To: , "Adrian Farrel" , Cc: , , Subject: MIB Dr. Review for draft-ietf-ccamp-gmpls-lsr-mib-12.txt Date: Wed, 19 Apr 2006 20:32:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e2654aace38e817a6fcad48700c5cc444d6b33122699149cfe979350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.100.203.57 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Tom and Adrian, Thanks for the great update. A few minor comments. Thanks, Joan *Compiles cleanly with smicngPRO and smilint. 1) The expiration Date which appears as a page header is incorrect: Nadeau and Farrel Expires April 2006 [Page 2] 2) gmplsInterfaceSignalingCaps OBJECT-TYPE REFERENCE "1. Generalized MPLS Signaling - CR-LDP Extensions, RFC 3472. 2. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473." DEFVAL { { rsvpGmpls } } The above references have updates (e.g. see ccamp Charter page) and so think these updating RFCs should also be included here and in the Normative Reference section: RFC 3472 is updated by RFC 4201 RFC 3473 is updated by RFC 4003,RFC 4201, and RFC 4420 Please be sure to update these RFCs in other REFERENCE clauses also. 3) The DESCRIPTION clause of gmplsInterfaceEntry says"...A conceptual row in this table may also be created via SNMP SET commands or automatically by the LSR to supplement a conceptual row in the mplsInterfaceTable where the interface is not capable of GMPLS but where the other objects carried in this row provide useful additional information for an MPLS interface." As I mentioned previously, I think you need to call out these MPLS objects (i.e. the objects which do not require GMPLS but are in the GMPLS-LSR-STD-MIB module) in a separate conformance group, but as I look at this MIB, it appears that all the objects seem to apply to MPLS, if this is accurate, then please update the DESCRIPTION clauses of the ALL conformance groups to indicate that these objects also apply to MPLS. As an example: gmplsInterfaceGroup OBJECT-GROUP OBJECTS { gmplsInterfaceSignalingCaps, gmplsInterfaceRsvpHelloPeriod } STATUS current DESCRIPTION "Collection of objects needed for GMPLS interface configuration and performance information." ::= { gmplsLsrGroups 1 } Should be changed to: "Collection of objects which provide additional information for an MPLS interface and are needed for GMPLS interface configuration and performance information." 4) Typo: gmplsLsrModuleReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance requirement for implementations that only provide read-only support for GMPLS-LSR-STD-MIB. Such devices can then be monitored but cannot be configured using this MIB modules." Last part of the last sentence: "...configured using this MIB module." 5) GMPLS-LABEL-STD-MIB DESCRIPTION: "... This MIB module contains managed object definitions for labels within GMPLS systems as defined in: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, Berger, L. (Editor), RFC 3471, January 2003." RFC 3471 is updated by RFC 4201,RFC 4328 Please add these other RFCs and be sure to add them to the Normative Reference Section. 6) Typo: gmplsLabelTable DESCRIPTION: "... Labels in the tables in other MIB modules may be referred to using row pointer into this table." Should be "using a row pointer" 7) Typo: gmplsLabelTable DESCRIPTION: "...a set of resources in the data plane. Practial examples are" s/Practial/Practical 8) ReadOnly Compliance: OBJECT gmplsLabelRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Support for notInService, createAndWait and notReady is not required." Would change the DESCRIPTION to: "Write access is not required, and active is the only status that needs to be supported." 9) Full Compliance: OBJECT gmplsLabelRowStatus SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notReady is not required." Would remove this. Based on the gmplsLabelRowStatus object's DESCRIPTION believe you should allow createAndWait and also Agent could/should be able to report notReady. 10) NIT: Would remove the (for example, wavelength labels) because I was expecting to see the example carried though and list the groups for wavelength labels. Also, need to add gmplsLabelWavebandGroup to the list of groups. Updates appear below: DESCRIPTION "Necessary, but not sufficient, set of objects to implement label table support. In addition, depending on the type of labels supported, the following other groups defined below are mandatory: gmplsLabelPacketGroup and/or gmplsLabelPortWavelengthGroup and/or gmplsLabelFreeformGroup and/or gmplsLabelSonetSdhGroup and/or gmplsLabelWavebandGroup." 11) Just a reminder to update Normative References as discussed above: RFC 3471 is updated by RFC 4201,RFC 4328 RFC 3472 is updated by RFC 4201 RFC 3473 is updated by RFC 4003,RFC 4201, and RFC 4420 end. From owner-ccamp@ops.ietf.org Thu Apr 20 11:35:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWbBW-00015d-Kd for ccamp-archive@ietf.org; Thu, 20 Apr 2006 11:35:10 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWbBU-000670-BW for ccamp-archive@ietf.org; Thu, 20 Apr 2006 11:35:10 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FWawV-000K6f-Mw for ccamp-data@psg.com; Thu, 20 Apr 2006 15:19:39 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [209.173.53.84] (helo=willow.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FWawU-000K6R-Su for ccamp@ops.ietf.org; Thu, 20 Apr 2006 15:19:39 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k3KFJa9W009188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 20 Apr 2006 15:19:36 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FWawS-0002d2-8T; Thu, 20 Apr 2006 11:19:36 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Subject: Last Call: 'Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control' to Proposed Standard (draft-ietf-ccamp-rfc3946bis) Reply-to: iesg@ietf.org CC: Message-Id: Date: Thu, 20 Apr 2006 11:19:36 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 The IESG has received a request from the Common Control and Measurement Plane WG to consider the following document: - 'Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control ' 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 any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-05-04. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rfc3946bis-01.txt From owner-ccamp@ops.ietf.org Thu Apr 20 17:25:48 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWgeq-0005lI-Sd for ccamp-archive@ietf.org; Thu, 20 Apr 2006 17:25:48 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWgeq-0007ri-DZ for ccamp-archive@ietf.org; Thu, 20 Apr 2006 17:25:48 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FWgUl-000Isx-JF for ccamp-data@psg.com; Thu, 20 Apr 2006 21:15:23 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FWgUk-000Isj-IW for ccamp@ops.ietf.org; Thu, 20 Apr 2006 21:15:22 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 20 Apr 2006 14:15:22 -0700 X-IronPort-AV: i="4.04,141,1144047600"; d="scan'208"; a="1797184138:sNHT38688320" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k3KLFKVI001425; Thu, 20 Apr 2006 14:15:21 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Apr 2006 17:15:20 -0400 Received: from [10.83.15.50] ([10.83.15.50]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 20 Apr 2006 17:15:20 -0400 In-Reply-To: <008101c66411$ed40b3e0$0500a8c0@jlucianilaptop> References: <008101c66411$ed40b3e0$0500a8c0@jlucianilaptop> Mime-Version: 1.0 (Apple Message framework v749.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Adrian Farrel , ccamp@ops.ietf.org, Wijnen Bert , "Dan Romascanu (E-mail)" , Kireeti Kompella Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: MIB Dr. Review for draft-ietf-ccamp-gmpls-lsr-mib-12.txt Date: Thu, 20 Apr 2006 17:15:31 -0400 To: Cucchiara Joan X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 20 Apr 2006 21:15:20.0088 (UTC) FILETIME=[8776D180:01C664BF] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa Thanks again. Really just 2 quick questions below for clarification and we can ship this one. --Tom > > Tom and Adrian, > > Thanks for the great update. A few minor comments. > > Thanks, > Joan > > > *Compiles cleanly with smicngPRO and smilint. Yes! > 1) The expiration Date which appears as a page > header is incorrect: > > Nadeau and Farrel Expires April 2006 [Page 2] Fixed. > 2) gmplsInterfaceSignalingCaps OBJECT-TYPE > > REFERENCE > "1. Generalized MPLS Signaling - CR-LDP Extensions, RFC 3472. > 2. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473." > DEFVAL { { rsvpGmpls } } > > The above references have updates (e.g. see ccamp Charter page) > and so think these updating RFCs should also be included > here and in the Normative Reference section: > > RFC 3472 is updated by RFC 4201 > RFC 3473 is updated by RFC 4003,RFC 4201, and RFC 4420 > > Please be sure to update these RFCs in other REFERENCE > clauses also. Fixed remainder in this module and in the gmpls-te mib too. There were no references in the tc mib. > 3) The DESCRIPTION clause of gmplsInterfaceEntry > says"...A conceptual row in this table may also be created via SNMP > SET commands or automatically by the LSR to supplement a > conceptual row in the mplsInterfaceTable where the interface > is not capable of GMPLS but where the other objects carried > in this row provide useful additional information for an > MPLS interface." > > As I mentioned previously, I think you need to call out > these MPLS objects (i.e. the objects which do not require > GMPLS but are in the GMPLS-LSR-STD-MIB module) > in a separate conformance group, but as I look at this > MIB, it appears that all the objects seem to apply to > MPLS, if this is accurate, then please update the > DESCRIPTION clauses of the ALL conformance groups to > indicate that these objects also apply to MPLS. > > As an example: > > gmplsInterfaceGroup OBJECT-GROUP > OBJECTS { > gmplsInterfaceSignalingCaps, > gmplsInterfaceRsvpHelloPeriod > } > STATUS current > DESCRIPTION > "Collection of objects needed for GMPLS interface configuration > and performance information." > ::= { gmplsLsrGroups 1 } > > Should be changed to: > > "Collection of objects which provide additional information for > an MPLS interface and are needed for GMPLS interface configuration > and performance information." Yes, they are all required. So do you think this statement that calls out all objects is sufficient? A similar change then can be made for the in/out-segment tables: gmplsInSegmentGroup OBJECT-GROUP OBJECTS { gmplsInSegmentDirection, gmplsInSegmentExtraParamsPtr } STATUS current DESCRIPTION "Collection of objects which provide additional information for an MPLS in-segment and are needed for GMPLS in-segment configuration and performance information." ::= { gmplsLsrGroups 2 } gmplsOutSegmentGroup OBJECT-GROUP OBJECTS { gmplsOutSegmentDirection, gmplsOutSegmentTTLDecrement, gmplsOutSegmentExtraParamsPtr } STATUS current DESCRIPTION "Collection of objects which provide additional information for an MPLS out-segment and are needed for GMPLS out-segment configuration and performance information." ::= { gmplsLsrGroups 3 } > 4) Typo: > > gmplsLsrModuleReadOnlyCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "Compliance requirement for implementations that only provide > read-only support for GMPLS-LSR-STD-MIB. Such devices can then > be monitored but cannot be configured using this MIB modules." > > Last part of the last sentence: > > "...configured using this MIB module." Got it. > 5) GMPLS-LABEL-STD-MIB > > DESCRIPTION: > "... > This MIB module contains managed object definitions for labels > within GMPLS systems as defined in: > Generalized Multi-Protocol Label Switching (GMPLS) Signaling > Functional Description, Berger, L. (Editor), RFC 3471, > January 2003." > > > RFC 3471 is updated by RFC 4201,RFC 4328 > > Please add these other RFCs and be sure to add them > to the Normative Reference Section. Done. > 6) Typo: > > gmplsLabelTable > DESCRIPTION: > > "... Labels in the tables in other MIB modules may be referred > to using row pointer into this table." > > Should be "using a row pointer" > > 7) Typo: > > gmplsLabelTable > DESCRIPTION: > > > "...a set of resources in the data plane. Practial examples are" > > s/Practial/Practical Done. > 8) ReadOnly Compliance: > > OBJECT gmplsLabelRowStatus > SYNTAX RowStatus { active(1) } > MIN-ACCESS read-only > DESCRIPTION > "Support for notInService, createAndWait and notReady is not > required." > > > Would change the DESCRIPTION to: > "Write access is not required, and active is the only status > that > needs to be supported." One minor change: "Write access is not required, and active(1) is the only status that needs to be supported." > 9) Full Compliance: > > OBJECT gmplsLabelRowStatus > SYNTAX RowStatus { active(1), notInService(2) } > WRITE-SYNTAX RowStatus { active(1), notInService(2), > createAndGo(4), destroy(6) } > DESCRIPTION > "Support for createAndWait and notReady is not required." > > > Would remove this. The description or the entire object? > Based on the > gmplsLabelRowStatus object's DESCRIPTION > believe you should allow createAndWait and also > Agent could/should be able to report notReady. > > > 10) NIT: > > Would remove the (for example, wavelength labels) because > I was expecting to see the example carried though and list > the groups for wavelength labels. > > > Also, need to add gmplsLabelWavebandGroup to the > list of groups. > > Updates appear below: > > DESCRIPTION > "Necessary, but not sufficient, set of objects to implement > label > table support. In addition, depending on the type of labels > supported, the following other > groups defined below are mandatory: > gmplsLabelPacketGroup and/or > gmplsLabelPortWavelengthGroup and/or > gmplsLabelFreeformGroup and/or > gmplsLabelSonetSdhGroup and/or > gmplsLabelWavebandGroup." > OK. > 11) Just a reminder to update Normative References > as discussed above: > RFC 3471 is updated by RFC 4201,RFC 4328 > RFC 3472 is updated by RFC 4201 > RFC 3473 is updated by RFC 4003,RFC 4201, and RFC 4420 > > end. Done. --Tom From owner-ccamp@ops.ietf.org Thu Apr 20 19:13:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWiLJ-0007rc-34 for ccamp-archive@ietf.org; Thu, 20 Apr 2006 19:13:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWiLI-00071Y-AP for ccamp-archive@ietf.org; Thu, 20 Apr 2006 19:13:44 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FWiGz-000On2-I0 for ccamp-data@psg.com; Thu, 20 Apr 2006 23:09:17 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,DNS_FROM_RFC_ABUSE,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.86.89.69] (helo=elasmtp-mealy.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FWiGy-000Omp-Ea for ccamp@ops.ietf.org; Thu, 20 Apr 2006 23:09:16 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=hUT5XTjIzxxxB2jfn00hwGW0NForheW8lJo5gpXIv3mFZ5LwoDmhox7D4Mvb4Iva; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [67.100.203.116] (helo=jlucianilaptop) by elasmtp-mealy.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1FWiGv-0007fs-EY; Thu, 20 Apr 2006 19:09:14 -0400 Message-ID: <00e101c664a6$fa27d120$0500a8c0@jlucianilaptop> From: To: "Thomas D. Nadeau" Cc: "Adrian Farrel" , , "Wijnen Bert" , "Dan Romascanu (E-mail)" , "Kireeti Kompella" References: <008101c66411$ed40b3e0$0500a8c0@jlucianilaptop> Subject: Re: MIB Dr. Review for draft-ietf-ccamp-gmpls-lsr-mib-12.txt Date: Thu, 20 Apr 2006 14:19:34 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e26545a8ce637b12117b4125650c8c103a5e7773bb16c9ad91485350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.100.203.116 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: fe105289edd72640d9f392da880eefa2 Replies inline. ----- Original Message ----- From: Thomas D. Nadeau To: Cucchiara Joan Cc: Adrian Farrel ; ; Wijnen Bert ; Dan Romascanu (E-mail) ; Kireeti Kompella Sent: Thursday, April 20, 2006 5:15 PM Subject: Re: MIB Dr. Review for draft-ietf-ccamp-gmpls-lsr-mib-12.txt > > Thanks again. Really just 2 quick questions below > for clarification and we can ship this one. > > --Tom > > > > > Tom and Adrian, > > > > Thanks for the great update. A few minor comments. > > > > Thanks, > > Joan > > > > > > *Compiles cleanly with smicngPRO and smilint. > > Yes! > > > 1) The expiration Date which appears as a page > > header is incorrect: > > > > Nadeau and Farrel Expires April 2006 [Page 2] > > Fixed. > > > 2) gmplsInterfaceSignalingCaps OBJECT-TYPE > > > > REFERENCE > > "1. Generalized MPLS Signaling - CR-LDP Extensions, RFC 3472. > > 2. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473." > > DEFVAL { { rsvpGmpls } } > > > > The above references have updates (e.g. see ccamp Charter page) > > and so think these updating RFCs should also be included > > here and in the Normative Reference section: > > > > RFC 3472 is updated by RFC 4201 > > RFC 3473 is updated by RFC 4003,RFC 4201, and RFC 4420 > > > > Please be sure to update these RFCs in other REFERENCE > > clauses also. > > Fixed remainder in this module and in the gmpls-te mib > too. There were no references in the tc mib. > > > 3) The DESCRIPTION clause of gmplsInterfaceEntry > > says"...A conceptual row in this table may also be created via SNMP > > SET commands or automatically by the LSR to supplement a > > conceptual row in the mplsInterfaceTable where the interface > > is not capable of GMPLS but where the other objects carried > > in this row provide useful additional information for an > > MPLS interface." > > > > As I mentioned previously, I think you need to call out > > these MPLS objects (i.e. the objects which do not require > > GMPLS but are in the GMPLS-LSR-STD-MIB module) > > in a separate conformance group, but as I look at this > > MIB, it appears that all the objects seem to apply to > > MPLS, if this is accurate, then please update the > > DESCRIPTION clauses of the ALL conformance groups to > > indicate that these objects also apply to MPLS. > > > > As an example: > > > > gmplsInterfaceGroup OBJECT-GROUP > > OBJECTS { > > gmplsInterfaceSignalingCaps, > > gmplsInterfaceRsvpHelloPeriod > > } > > STATUS current > > DESCRIPTION > > "Collection of objects needed for GMPLS interface configuration > > and performance information." > > ::= { gmplsLsrGroups 1 } > > > > Should be changed to: > > > > "Collection of objects which provide additional information for > > an MPLS interface and are needed for GMPLS interface configuration > > and performance information." > > Yes, they are all required. So do you think this statement > that calls out all objects is sufficient? A similar change then > can be made for the in/out-segment tables: > Yes, adding these statements is sufficient, because it now clarifies that all these objects apply to MPLS. As we discussed early in the review process, believe that email needs to be sent to the MPLS working group to notify them of these objects since they apply to MPLS also. I realize email was sent to MPLS wg on earlier versions but would be good notify the MPLS wg again so they can see the final version of these MIB docs. > gmplsInSegmentGroup OBJECT-GROUP > OBJECTS { > gmplsInSegmentDirection, > gmplsInSegmentExtraParamsPtr > } > STATUS current > DESCRIPTION > "Collection of objects which provide additional > information for an MPLS in-segment and are needed > for GMPLS in-segment configuration and performance > information." > ::= { gmplsLsrGroups 2 } > > gmplsOutSegmentGroup OBJECT-GROUP > OBJECTS { > gmplsOutSegmentDirection, > gmplsOutSegmentTTLDecrement, > gmplsOutSegmentExtraParamsPtr > } > STATUS current > DESCRIPTION > "Collection of objects which provide additional > information for an MPLS out-segment and are needed > for GMPLS out-segment configuration and performance > information." > ::= { gmplsLsrGroups 3 } > > > > 4) Typo: > > > > gmplsLsrModuleReadOnlyCompliance MODULE-COMPLIANCE > > STATUS current > > DESCRIPTION > > "Compliance requirement for implementations that only provide > > read-only support for GMPLS-LSR-STD-MIB. Such devices can then > > be monitored but cannot be configured using this MIB modules." > > > > Last part of the last sentence: > > > > "...configured using this MIB module." > > Got it. > > > 5) GMPLS-LABEL-STD-MIB > > > > DESCRIPTION: > > "... > > This MIB module contains managed object definitions for labels > > within GMPLS systems as defined in: > > Generalized Multi-Protocol Label Switching (GMPLS) Signaling > > Functional Description, Berger, L. (Editor), RFC 3471, > > January 2003." > > > > > > RFC 3471 is updated by RFC 4201,RFC 4328 > > > > Please add these other RFCs and be sure to add them > > to the Normative Reference Section. > > Done. > > > 6) Typo: > > > > gmplsLabelTable > > DESCRIPTION: > > > > "... Labels in the tables in other MIB modules may be referred > > to using row pointer into this table." > > > > Should be "using a row pointer" > > > > 7) Typo: > > > > gmplsLabelTable > > DESCRIPTION: > > > > > > "...a set of resources in the data plane. Practial examples are" > > > > s/Practial/Practical > > > Done. > > > 8) ReadOnly Compliance: > > > > OBJECT gmplsLabelRowStatus > > SYNTAX RowStatus { active(1) } > > MIN-ACCESS read-only > > DESCRIPTION > > "Support for notInService, createAndWait and notReady is not > > required." > > > > > > Would change the DESCRIPTION to: > > "Write access is not required, and active is the only status > > that > > needs to be supported." > > One minor change: > > "Write access is not required, and active(1) is > the only status that needs to be supported." > > > 9) Full Compliance: > > > > OBJECT gmplsLabelRowStatus > > SYNTAX RowStatus { active(1), notInService(2) } > > WRITE-SYNTAX RowStatus { active(1), notInService(2), > > createAndGo(4), destroy(6) } > > DESCRIPTION > > "Support for createAndWait and notReady is not required." > > > > > > Would remove this. > > The description or the entire object? The entire object. If you allow createAndWait and notReady then there is no need to special case this object in the conformance statements. Thanks, -Joan > > > Based on the > > gmplsLabelRowStatus object's DESCRIPTION > > believe you should allow createAndWait and also > > Agent could/should be able to report notReady. > > > > > > 10) NIT: > > > > Would remove the (for example, wavelength labels) because > > I was expecting to see the example carried though and list > > the groups for wavelength labels. > > > > > > Also, need to add gmplsLabelWavebandGroup to the > > list of groups. > > > > Updates appear below: > > > > DESCRIPTION > > "Necessary, but not sufficient, set of objects to implement > > label > > table support. In addition, depending on the type of labels > > supported, the following other > > groups defined below are mandatory: > > gmplsLabelPacketGroup and/or > > gmplsLabelPortWavelengthGroup and/or > > gmplsLabelFreeformGroup and/or > > gmplsLabelSonetSdhGroup and/or > > gmplsLabelWavebandGroup." > > > > OK. > > > 11) Just a reminder to update Normative References > > as discussed above: > > RFC 3471 is updated by RFC 4201,RFC 4328 > > RFC 3472 is updated by RFC 4201 > > RFC 3473 is updated by RFC 4003,RFC 4201, and RFC 4420 > > > > end. > > Done. > > --Tom > From owner-ccamp@ops.ietf.org Fri Apr 21 01:29:45 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWoDB-0004tp-37 for ccamp-archive@ietf.org; Fri, 21 Apr 2006 01:29:45 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWoD8-0000Bg-Is for ccamp-archive@ietf.org; Fri, 21 Apr 2006 01:29:45 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FWo6N-000Ha7-HP for ccamp-data@psg.com; Fri, 21 Apr 2006 05:22:43 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,DNS_FROM_RFC_ABUSE,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.86.89.68] (helo=smtpauth08.mail.atl.earthlink.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FWo6M-000HZv-FW for ccamp@ops.ietf.org; Fri, 21 Apr 2006 05:22:42 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=T2txv7wXsIJRgYWXU8Bi+RLjpqs/xrFOIpkNMR/cBFDpXaSzBmXojwdAq5cc4YNq; h=Received:Message-ID:From:To:Cc:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [67.100.203.116] (helo=jlucianilaptop) by smtpauth08.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1FWo6I-0005XD-5C; Fri, 21 Apr 2006 01:22:38 -0400 Message-ID: <001901c664db$2e1ff6e0$0500a8c0@jlucianilaptop> From: To: , "Adrian Farrel" , Cc: , , Subject: MIB Dr. Review for draft-ietf-ccamp-gmpls-te-mib-14.txt Date: Thu, 20 Apr 2006 20:33:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e265458e6d1a9a786322c2b5d65f6bdc541054e508857176a6fc1350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.100.203.116 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Hello Tom and Adrian, Here are a few comments on draft-ietf-ccamp-gmpls-te-mib-14.txt. Thank you for the great updates. Thanks, -Joan Compiles with both smicngPRO and smilint. 1) There is a disconnect in the numbers under the under gmplsTeGroup, was this intentional, if so, please explain, otherwise, please correct it. 1.3.6.1.2.1.10.166.555.3.1 gmplsTeGroups [GMPLS-TE-STD-MIB]: oid-value-assignment 1.3.6.1.2.1.10.166.555.3.1.1 gmplsTunnelGroup [GMPLS-TE-STD-MIB]: object-group 1.3.6.1.2.1.10.166.555.3.1.2 gmplsTunnelSignaledGroup [GMPLS-TE-STD-MIB]: object-group 1.3.6.1.2.1.10.166.555.3.1.3 gmplsTunnelScalarGroup [GMPLS-TE-STD-MIB]: object-group 1.3.6.1.2.1.10.166.555.3.1.6 gmplsTunnelOptionalGroup [GMPLS-TE-STD-MIB]: object-group 1.3.6.1.2.1.10.166.555.3.1.7 gmplsTeNotificationGroup [GMPLS-TE-STD-MIB]: notification-group 2) Expiration date in the page header is incorrect Nadeau and Farrel Expires April 2006 [Page 1] 3) 1.1. Migration Strategy "The gmplsTunnelLSPEncoding may be set to tunnelLspNotGmpls to allow an MPLS-TE LSP tunnel to benefit from the additional objects and tables of GMPLS-LSR-STD-MIB without supporting the GMPLS protocols. Think you mean, GMPLS-TE-STD-MIB in the latter part of the above sentence. 4) 1.1. Migration Strategy "Textual conventions are defined in [RFC3811] and [GMPLSTCMIB]." There aren't any TCs from GMPLSTCMIB, but there are from the IANA-GMPLS-TC-MIB, so perhaps adding IANA-GMPLS-TC-MIB to this statement would be appropriate. 5) (NIT) 2. Terminology "These segment and cross-connect objects are defined in the MPLS Label Switch Router MIB (MPLS-LSR-STD-MIB) [RFC3813], but see also the GMPLS Label Switch Router MIB (GMPLS-LSR-STD-MIB) [GMPLSLSRMIB] for..." Please be sure to use "Label Switching Router" (and not Label Switch Router). 6) Typos: gmplsTunnelLinkProtection This glag is set to indicate that the LSP should not use any link layer protection. s/glag/flag shared This flage is set to indicate that a shared link layer s/flage/flag 7) gmplsTunnelErrorEntry OBJECT-TYPE The use of the term "discontinuity" implies that the counters suffered a discontinuity,but the situation you are describing is that another error occurred. Please rephrase this to something like: "Note that systems which read the objects in this table one at a time should read gmplsTunnelErrorLastTime prior to the first object and after reading the last object of this table to ensure that no additional errors occurred." 8) gmplsTunnelUnnumIf does not appear in the ReadOnly Conformance. 9) I am still unclear about what objects can be supported within MPLS only. Was expecting to see this clarified in the conformance statements. There does seem to be more of a division here than in the GMPLS-LSR-STD-MIB. Could some clarification be made to this point? 10) IANA-GMPLS-TC-MIB Would remove parts of the DESCRIPTION clauses which refer to the GMPLS-TE-STD-MIB module. The reason is that these TCs may eventually be used in other MIB modules and since this particular module will be controlled by IANA, these sort of statements don't appear in IANA MIB Modules as far as I know. "This data type is used as the syntax of the gmplsTunnelLSPEncoding object in the definition of GMPLS-TE-STD-MIB's gmplsTunnelTable." "This data type is used as the syntax of the gmplsTunnelSwitchingType object in the definition of GMPLS-TE-STD-MIB's gmplsTunnelTable." "This data type is used as the syntax of the gmplsTunnelGPid object in the definition of GMPLS-TE-STD-MIB's gmplsTunnelTable." "This data type is used as the syntax of the gmplsTunnelAdminStatusFlags object in the definition of GMPLS-TE-STD-MIB's gmplsTunnelTable." -- the end -- From owner-ccamp@ops.ietf.org Fri Apr 21 01:47:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWoUK-0003mB-B7 for ccamp-archive@ietf.org; Fri, 21 Apr 2006 01:47:28 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWoUK-0000ip-9i for ccamp-archive@ietf.org; Fri, 21 Apr 2006 01:47:28 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FWoUI-00034J-SD for ccamp-archive@ietf.org; Fri, 21 Apr 2006 01:47:28 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FWoQE-000IZ0-2i for ccamp-data@psg.com; Fri, 21 Apr 2006 05:43:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,DNS_FROM_RFC_ABUSE,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.86.89.68] (helo=smtpauth08.mail.atl.earthlink.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FWoQD-000IYn-Jh for ccamp@ops.ietf.org; Fri, 21 Apr 2006 05:43:13 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=lfp+zGkZPVJm0iSmPowYU8stgp1mhNIVihkvr9btzbgDa7k8MWvdIOU0yTWcczF/; h=Received:Message-ID:From:To:Cc:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [67.100.203.116] (helo=jlucianilaptop) by smtpauth08.mail.atl.earthlink.net with asmtp (Exim 4.34) id 1FWoQA-0007qN-A4; Fri, 21 Apr 2006 01:43:10 -0400 Message-ID: <005101c664de$0c8b2240$0500a8c0@jlucianilaptop> From: To: , "Adrian Farrel" , Cc: , , Subject: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-10.txt Date: Thu, 20 Apr 2006 20:53:46 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e265458e6d1a9a786322cade27ab350820bd93553614b9f64653b350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 67.100.203.116 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Tom and Adrian, One minor comments, which is the expiration date in the header needs updating. Otherwise, this document looks good. -Joan From owner-ccamp@ops.ietf.org Fri Apr 21 10:51:42 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWwz0-0003O6-Hu for ccamp-archive@ietf.org; Fri, 21 Apr 2006 10:51:42 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWwyz-0004ZS-9A for ccamp-archive@ietf.org; Fri, 21 Apr 2006 10:51:42 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FWwqI-000OTN-Ii for ccamp-data@psg.com; Fri, 21 Apr 2006 14:42:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FWwqH-000OSz-Tv for ccamp@ops.ietf.org; Fri, 21 Apr 2006 14:42:42 +0000 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 21 Apr 2006 10:42:41 -0400 X-IronPort-AV: i="4.04,145,1144036800"; d="scan'208"; a="86922842:sNHT92541384" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3LEgevF016893; Fri, 21 Apr 2006 10:42:40 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Apr 2006 10:42:40 -0400 Received: from [10.83.15.50] ([10.83.15.50]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 21 Apr 2006 10:42:39 -0400 In-Reply-To: <005101c664de$0c8b2240$0500a8c0@jlucianilaptop> References: <005101c664de$0c8b2240$0500a8c0@jlucianilaptop> Mime-Version: 1.0 (Apple Message framework v749.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Cc: "Adrian Farrel" , , , , Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-10.txt Date: Fri, 21 Apr 2006 10:42:50 -0400 To: "" X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 21 Apr 2006 14:42:39.0812 (UTC) FILETIME=[D6DBC040:01C66551] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cool. I have updated this based on your review of the GMPLS LSR MIB yesterday. --Tom > Tom and Adrian, > > One minor comments, which is the > expiration date in the header needs > updating. Otherwise, this document > looks good. > > -Joan From owner-ccamp@ops.ietf.org Fri Apr 21 12:57:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWywf-0002qu-S7 for ccamp-archive@ietf.org; Fri, 21 Apr 2006 12:57:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWywc-0002Mu-Sm for ccamp-archive@ietf.org; Fri, 21 Apr 2006 12:57:25 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FWyrA-0006lr-OF for ccamp-data@psg.com; Fri, 21 Apr 2006 16:51:44 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_50_60,HTML_MESSAGE autolearn=no version=3.1.1 Received: from [195.101.245.15] (helo=p-mail1.rd.francetelecom.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FWyr7-0006jS-VM for ccamp@ops.ietf.org; Fri, 21 Apr 2006 16:51:42 +0000 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Apr 2006 18:51:08 +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_01C66563.C8AC21C9" Subject: RE: [Pce] Comparison of Encryption vs. Path Key Solutions for the CPSID. Date: Fri, 21 Apr 2006 18:51:05 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Comparison of Encryption vs. Path Key Solutions for the CPSID. Thread-Index: AcZZeTyqrqoHE6qtR3mCIGZZDDyHhAL5Ddwg From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "JP Vasseur" , "Rich Bradford" Cc: , X-OriginalArrivalTime: 21 Apr 2006 16:51:08.0082 (UTC) FILETIME=[C9586920:01C66563] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 90f8d7cac99eccf384c4cdc57475e98c This is a multi-part message in MIME format. ------_=_NextPart_001_01C66563.C8AC21C9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi JP, Richard =20 Please see inline, ________________________________ De : JP Vasseur [mailto:jvasseur@cisco.com]=20 Envoy=E9 : jeudi 6 avril 2006 14:52 =C0 : Rich Bradford Cc : ccamp@ops.ietf.org; pce@ietf.org Objet : Re: [Pce] Comparison of Encryption vs. Path Key Solutions for = the CPSID. =09 =09 Hi,=20 Thanks for the summary Rich. PCE WG members: thanks to provide your feedback on whether: (1) You think that there is a need for such solution,=20 =20 Yes definitely, confidentiality is a key requirements in an = inter-provider context. =20 (2) You would prefer one solution (which one and why ?)=20 =20 (3) You think that there is a need for both=20 =20 Answer to (2) and (3): It seems to me that we should end-up with a single solution so as to = ease interworking. =09 IMO in an inter-AS MPLS-TE environment without PCEs, the paths will be = loose anyway, so there will not be any confidentiality issue.=20 If have some concerns regarding the cost of encryption, particularly = for large paths (we need to think about future P2MP applications with a = large number of hops...). By the way, encryption approaches are really = vulnerable to DoS attacks. Hence I would strongly favor the PKS solution. The optimization = suggested, which consists of sending the computed path segment to the = LSR in an unsolicited manner, just after the computation, sounds = relevant and should be further investigated. =20 Best Regards, =20 JL =20 =20 =20 =09 =09 Thanks. JP. On Apr 5, 2006, at 6:19 PM, Rich Bradford ((rbradfor)) wrote: Hi, As suggested in Dallas, I've described some of the tradeoffs between = the two solutions described in = draft-rbradfor-ccamp-confidential-segment-00.txt. -- Rich =09 The Confidential Path Segment (CPS) ID provides two very different but = equally valid solutions, the Path Key Subobject (PKS) solution and the = Private Route Subobject (PRS) solution. This note examines a number of = the advantages and disadvantages of each solution.=20 =09 In short: The PKS solution allows a PCE to hide the CPS for an AS by = saving it in a database and replacing it with a key in the ERO. During = the LSP setup, the ingress LSR for that AS must query the PCE for an = expansion. The PRS solution allows a CPS for an AS to be hidden by encrypting it, = which may be done by a PCE or by the Head-End LSR. During the LSP setup, = the ingress LSR for that AS must use a decryption key to obtain the = expansion (implying an earlier exchange or configuration).=20 =09 The major differences between the mechanisms involve (1) additional = control messages, (2) performance issues expanding those objects, (3) = the addition of state to the PCE, (4) the solution scope (i.e. = applicability to various topologies of each solution.), and (5) the size = of objects added to existing messages. =09 (1) Additional Control Message Overhead: The PKS solution requires a mechanism to expand the Path Key upon = receipt of the LSP setup request. Since the PCE which calculated the = Path Key might not reside in the entry boundary LSR, the LSR must = request the expansion from the PCE, requiring an additional message = exchange before LSP setup can proceed. The Path Encryption solution does = not require this extra exchange between the PCE and the ingress node for = every LSP. Rather, the decryption key needs to be exchanged only when it = is changed. The result is additional delay during every LSP setup for = the PKS solution but no additional delay for the PRS solution. =09 =09 (2) PCE and LSR Performance: The PKS solution must maintain a (temporary) database of keys adding = overhead to the PCE. The PRS solution requires the encryption of the CPS = in the PCE and decryption of the CPS in the LSR, which could be CPU = intensive. Note that in case of a burst of requests, encryption of large = number of CPS may have an impact on the PCE response time. =09 (3) Addition of State in the PCE: The PKS solution requires the addition of path-specific state and = maintenance of a database in the PCE. The PRS solution requires no = additional state. =09 =09 (4) Solution Scope: The PKS and PRS solutions both work well in conjunction with a PCE to = encode and decode the CPS. However the PKS provides no direct solution = without a PCE. This prevents the PKS solution for working in the case = where A's network straddles B's network and where A wants to use an ERO = for a segment of the LSP across the intervening network, e.g. = (netA)-(netB)-(netA). In addition, the PRS could be used to record a CPS = even if the path (and therefore the returned RRO) crosses multiple = boundaries. Finally, a PRS solution could be adapted to return actual = failure locations in PERRs and/or PATHTEARs, while keeping the failure = location confidential from LSRs without a decryption key. Currently = privacy of this source is maintained by returning the address of border = nodes, which can be very misleading. =09 (5) Message Object Overhead: The PKS solution provides a very compact key or token to identify a = path segment, which generally allows for smaller EROs to be returned by = the PCE and to be requested in the resulting PATH message. A PRS which = contains a CPS must generally be at least as large as the unencrypted = PATH through the AS and may be significantly larger if it is desirable = to hide the number of hops within the network from external view by = padding the PRS. The result is potentially larger PATH (and PCEP) = messages for the PRS solution. =09 =09 Please note that the tradeoffs listed here are for the current I-D. = Some of the shortcomings of each approach could be mitigated by = implementation-specific optimizations. For example, a PCE could choose = to signal the CPS expansion to the entry boundary LSR, shifting the = burden of maintaining the PKS state to the LSR and eliminating the = performance hit during LSP setup. A similar exchange could be performed = for the PRS case, eliminating the need for a separate key exchange. = These examples of extensions are beyond the scope of the ID, but might = be useful when weighing the pros and cons of the two solutions. =09 =09 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------_=_NextPart_001_01C66563.C8AC21C9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi JP, Richard
 
Please see inline,

De : JP Vasseur=20 [mailto:jvasseur@cisco.com]
Envoy=E9 : jeudi 6 avril = 2006=20 14:52
=C0 : Rich Bradford
Cc : = ccamp@ops.ietf.org;=20 pce@ietf.org
Objet : Re: [Pce] Comparison of Encryption = vs.=20 Path Key Solutions for the CPSID.

Hi,

Thanks for the summary Rich.

PCE WG members: thanks to provide your feedback on whether:
(1) You think=20 that there is a need for such solution, 
 
Yes=20 definitely, confidentiality is a key requirements in an inter-provider = context.
 
(2) You would=20 prefer one solution (which one and why ?) 
 
(3) You think=20 that there is a need for both 
 
Answer to (2) and=20 (3):
It seems to me=20 that we should end-up with a single solution so as to ease=20 interworking.
IMO in an inter-AS MPLS-TE environment without PCEs, the = paths=20 will be loose anyway, so there will not be any = confidentiality=20 issue.
If have some=20 concerns regarding the cost of encryption, particularly for large = paths=20 (we need to think about future P2MP applications with a large number = of=20 hops...). By the way, encryption approaches are really vulnerable to = DoS=20 attacks.
Hence I would strongly favor the PKS solution. The = optimization=20 suggested, which consists of sending the computed path segment to = the LSR=20 in an unsolicited manner, just after the computation, sounds = relevant and=20 should be further investigated.
 
Best=20 Regards,
 
JL
 
 
 
Thanks.

JP.

On Apr 5, 2006, at 6:19 PM, Rich Bradford ((rbradfor)) = wrote:

Hi,

As suggested in Dallas, I=92ve described some of = the=20 tradeoffs between the two solutions described in=20 = draft-rbradfor-ccamp-confidential-segment-00.txt.

-- Rich

The Confidential Path Segment (CPS) ID = provides two=20 very different but equally valid solutions, the Path Key Subobject = (PKS)=20 solution and the Private Route Subobject (PRS) solution. This note = examines=20 a number of the advantages and disadvantages of each solution.=20

In short: The PKS solution allows a PCE to = hide the=20 CPS for an AS by saving it in a database and replacing it with a key = in the=20 ERO. During the LSP setup, the ingress LSR for that AS must query = the PCE=20 for an expansion.

The PRS solution allows a CPS for an AS to = be hidden=20 by encrypting it, which may be done by a PCE or by the Head-End LSR. = During=20 the LSP setup, the ingress LSR for that AS must use a decryption key = to=20 obtain the expansion (implying an earlier exchange or = configuration).=20

The major differences between the = mechanisms involve=20 (1) additional control messages, (2) performance issues expanding = those=20 objects, (3) the addition of state to the PCE, (4) the solution = scope (i.e.=20 applicability to various topologies of each solution.), and (5) the = size of=20 objects added to existing messages.

(1) Additional Control Message=20 Overhead:

The PKS solution requires a mechanism to = expand the=20 Path Key upon receipt of the LSP setup request. Since the PCE which=20 calculated the Path Key might not reside in the entry boundary LSR, = the LSR=20 must request the expansion from the PCE, requiring an additional = message=20 exchange before LSP setup can proceed. The Path Encryption solution = does not=20 require this extra exchange between the PCE and the ingress node for = every=20 LSP. Rather, the decryption key needs to be exchanged only when it = is=20 changed. The result is additional delay during every LSP setup for = the PKS=20 solution but no additional delay for the PRS=20 solution.

(2) PCE and LSR=20 Performance:

The PKS solution must maintain a = (temporary)=20 database of keys adding overhead to the PCE. The PRS solution = requires the=20 encryption of the CPS in the PCE and decryption of the CPS in the = LSR, which=20 could be CPU intensive. Note that in case of a burst of requests, = encryption=20 of large number of CPS may have an impact on the PCE response=20 time.

(3) Addition of State in the=20 PCE:

The PKS solution requires the addition of=20 path-specific state and maintenance of a database in the PCE. The = PRS=20 solution requires no additional state.

(4) Solution = Scope:

The PKS and PRS solutions both work well = in=20 conjunction with a PCE to encode and decode the CPS. However the PKS = provides no direct solution without a PCE. This prevents the PKS = solution=20 for working in the case where A's network straddles B's network and = where A=20 wants to use an ERO for a segment of the LSP across the intervening = network,=20 e.g. (netA)-(netB)-(netA). In addition, the PRS could be used to = record a=20 CPS even if the path (and therefore the returned RRO) crosses = multiple=20 boundaries. Finally, a PRS solution could be adapted to return = actual=20 failure locations in PERRs and/or PATHTEARs, while keeping the = failure=20 location confidential from LSRs without a decryption key. Currently = privacy=20 of this source is maintained by returning the address of border = nodes, which=20 can be very misleading.

(5) Message Object=20 Overhead:

The PKS solution provides a very compact = key or=20 token to identify a path segment, which generally allows for smaller = EROs to=20 be returned by the PCE and to be requested in the resulting PATH = message. A=20 PRS which contains a CPS must generally be at least as large as the=20 unencrypted PATH through the AS and may be significantly larger if = it is=20 desirable to hide the number of hops within the network from = external view=20 by padding the PRS. The result is potentially larger PATH (and PCEP) = messages for the PRS solution.

Please note that the tradeoffs listed here = are for=20 the current I-D. Some of the shortcomings of each approach could be=20 mitigated by implementation-specific optimizations. For example, a = PCE could=20 choose to signal the CPS expansion to the entry boundary LSR, = shifting the=20 burden of maintaining the PKS state to the LSR and eliminating the=20 performance hit during LSP setup. A similar exchange could be = performed for=20 the PRS case, eliminating the need for a separate key exchange. = These=20 examples of extensions are beyond the scope of the ID, but might be = useful=20 when weighing the pros and cons of the two=20 solutions.

 _______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org= /mailman/listinfo/pce

= ------_=_NextPart_001_01C66563.C8AC21C9-- From owner-ccamp@ops.ietf.org Fri Apr 21 18:57:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX4Z5-0007yN-IG for ccamp-archive@ietf.org; Fri, 21 Apr 2006 18:57:27 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX4Z3-0005jT-TB for ccamp-archive@ietf.org; Fri, 21 Apr 2006 18:57:27 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FX4S8-0004wA-Ib for ccamp-data@psg.com; Fri, 21 Apr 2006 22:50:16 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.57.84] (helo=cypress.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FX4Rx-0004uc-SF for ccamp@ops.ietf.org; Fri, 21 Apr 2006 22:50:06 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k3LMo10e018222 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Apr 2006 22:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FX4Rt-0007XT-Hk; Fri, 21 Apr 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-lsp-hierarchy-bis-00.txt Message-Id: Date: Fri, 21 Apr 2006 18:50:01 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Procedures for Dynamically Signaled Hierarchical Label Switched Paths Author(s) : K. Shiomoto, et al. Filename : draft-ietf-ccamp-lsp-hierarchy-bis-00.txt Pages : 17 Date : 2006-4-21 This document addresses topics related to hierarchical and stitched Generalized Multiprotocol Label Switching (GMPLS) Label Switched Paths (LSPs). It describes extensions to allow an egress to identify that a bi-directional LSP will be used as a dynamically signaled Forwarding Adjacency LSP (FA-LSP) or Routing Adjacency (RA). In addition, the document also addresses the issue of how to indicate that an LSP should be advertised as a traffic engineering (TE) link into a different instance of the IGP and how to identify the instance that should be used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-hierarchy-bis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-lsp-hierarchy-bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-lsp-hierarchy-bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-21150234.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-lsp-hierarchy-bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-lsp-hierarchy-bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-21150234.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Fri Apr 21 18:58:17 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FX4Zt-00085o-NR for ccamp-archive@ietf.org; Fri, 21 Apr 2006 18:58:17 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FX4Zs-0005s7-Ai for ccamp-archive@ietf.org; Fri, 21 Apr 2006 18:58:17 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FX4Ry-0004v6-FW for ccamp-data@psg.com; Fri, 21 Apr 2006 22:50:06 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.53.70] (helo=oak.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FX4Rx-0004uT-Ew for ccamp@ops.ietf.org; Fri, 21 Apr 2006 22:50:05 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k3LMo1BX010555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 21 Apr 2006 22:50:02 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FX4Rt-0007XY-IU; Fri, 21 Apr 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-00.txt Message-Id: Date: Fri, 21 Apr 2006 18:50:01 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Framework for IP/MPLS-GMPLS interworking in support of IP/MPLS to GMPLS migration Author(s) : K. Shiomoto, et al. Filename : draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-00.txt Pages : 24 Date : 2006-4-21 The migration from Multiprotocol Label Switching (MPLS) to Generalized MPLS (GMPLS) is the process of evolving an MPLS traffic engineered (TE) control plane to a GMPLS control plane. An appropriate migration strategy can be selected based on various factors including the service provider's network deployment plan, customer demand, available network equipment implementation, operational policy, etc. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-21150533.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-21150533.I-D@ietf.org> --OtherAccess-- --NextPart-- From drxnlteo@alber-filderstadt.de Sat Apr 22 02:27:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXBaP-0000qy-KT for ccamp-archive@ietf.org; Sat, 22 Apr 2006 02:27:17 -0400 Received: from 84-16-251-252.internetserviceteam.com ([84.16.251.252] helo=mail.hosting.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FXBMO-00039a-8E for ccamp-archive@ietf.org; Sat, 22 Apr 2006 02:12:55 -0400 Received: from localhost by win2003-farrtx2 with SpamAssassin (2.64 2004-01-11); Sat, 22 Apr 2006 09:42:20 +0330 From: "Tim & Maynard" To: "Ella" , , , , , , , Subject: *****SPAM***** Robert bought in the piIIz in here Date: Fri, 21 Apr 2006 23:37:21 -0800 Message-Id: <0f8a01c665d3$ae4f8670$e6381cd0@PEJWL> X-Spam-Flag: YES X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on win2003-farrtx2 X-Spam-Level: ******* X-Spam-Status: Yes, hits=7.8 required=7.0 tests=HTML_20_30,HTML_MESSAGE, SORTED_RECIPS,SUSPICIOUS_RECIPS autolearn=no version=2.64 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------=_4449C944.704E0000" X-Spam-Score: 9.3 (+++++++++) X-Spam-Flag: YES X-Scan-Signature: ce2737a971e141e0457c8c1bf182367f This is a multi-part message in MIME format. ------------=_4449C944.704E0000 Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: 8bit Spam detection software, running on the system "win2003-farrtx2", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or block similar future email. If you have any questions, see customer-service@swsoft.com for details. Content preview: Hi Ella, Robert bought in the piIIz in here http://bestproofonline.com/?3f3l their Darrel Drew can't blackmail Ella fraternity and, the throughput transcribe are as truman Ella MERGE_GROUP_13 own batt MERGE_GROUP_13 I delaney metalloid on transition. [...] Content analysis details: (7.8 points, 7.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 HTML_MESSAGE BODY: HTML included in message 0.5 HTML_20_30 BODY: Message is 20% to 30% HTML 3.0 SUSPICIOUS_RECIPS Similar addresses in recipient list 4.3 SORTED_RECIPS Recipient list is sorted by address The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. ------------=_4449C944.704E0000 Content-Type: message/rfc822; x-spam-type=original Content-Description: original message before SpamAssassin Content-Disposition: attachment Content-Transfer-Encoding: 8bit Received: from spd-weser-ems.de ([125.241.100.4]) by mail.hosting.com (Merak 8.3.8) with SMTP id AKI34309; Sat, 22 Apr 2006 09:42:09 +0330 Message-ID: <0f8a01c665d3$ae4f8670$e6381cd0@PEJWL> From: "Tim & Maynard" To: "Ella" , , , , , , , Subject: Robert bought in the piIIz in here Date: Fri, 21 Apr 2006 23:37:21 -0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0F87_01C66599.01F0AE70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 This is a multi-part message in MIME format. ------=_NextPart_000_0F87_01C66599.01F0AE70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ella, Robert bought in the piIIz in here http://bestproofonline.com/?3f3l their Darrel Drew can't blackmail Ella fraternity and, the throughput transcribe are as truman Ella MERGE_GROUP_13 own batt MERGE_GROUP_13 I delaney metalloid on transition. ------=_NextPart_000_0F87_01C66599.01F0AE70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 3D""
Sonntag Karin Faust rein dadurch Ella Bruchlinie wie, = sehen berichten Biologie lieben von Einzelkontakt Ella von aufteilen er = diagonaldominant Atem Edelstahl du etw. anglotzen. wie, zu = Allwellenantenne besch=E4ftigen auf rein aus einer M=FCcke einen Elefanten = machen Ella zum Das =F6ffnet den Forderungen aller anderen T=FCr und Tor. = auch Anrufwiederholung Bermudasturmvogel Antiabtreibungskampagne toll = CCITTInternationaler Ausschuss f=FCr den Telegrafen- und = Fernsprechdienstlieblich Thomas Sellin zu Fahrunterbrechungen Ella = Gelbsteiss-Mistelfresser lieben, Sonntag Abbild bewilligte was er etw. = beschmutzen Ella was Brennkammer viel frevlerisch ausquetschen Geldmittel = Donnerstag doppelbrechend . wer, Liebe abgeschnallt formal und inhaltlich = Liebe Samstag Diamantschleifen Ella fein Berufskrankheit Ihre bitweise = Dickdarmerkrankung Begebenheit von Endstationim Carlo Klindt sehen = freigestellt Ella abgeschnallt das, ihren Erfassungsbild Drossellerche zu = nett Gabelbein Ella allzu Bewerbung Liebe Drossellerche er/sie/es ist = gediehen in abgehend. von, an frevlerisch Formteiladapter Samstag Liebe = Fahlbrauen-Blattsp=E4her Ella wenn gerillt Ihre Ausleihgeb=FChr = Einsch=E4tzung gerillt rein Endstation ------=_NextPart_000_0F87_01C66599.01F0AE70 Content-Type: image/gif; Content-Transfer-Encoding: base64 Content-ID: R0lGODlhowJrAYcAAAAAAE1NTVJSUllhcWtra2RsfHx8ez1yllNNjU1OqlBumVJyrGVYu3Jwk3Vt rGp0yjaSzlCGrnaCl2mOvEub0lyH9Fij13KL12qQ9Gur2nWv44pbE5psF51vIaNyFaZ5J9g3ANtL AN1zGtRuOeNuDuV9Jdd3SOF7UoB51KaDF7WKMouKeLuUQryhWsOZO8WiPumPAOuGKeyKMuyTOvKL KvOOM/WSLveXOO+uAP2kPM6STN2KZNKsT8yoaseueMewZM+yctKubN26Ytq6eeGATeWEWuiTSOmS WfaLX/edQ+iRbuS9TOC8WP2nR/urU/2xTv6zWOmje/65Z/69dPLWBfz7At/Ccd7YYOjJWvXNbuvl U+fic4mJiZmWjJeXmIyPqpahuqGelaacs6elmqiop6iot66xubGspbezq7i4t4qU04Wc45Gt2Y6w 7aSe6Le0z6i68L/EvZfC5LnE06bJ5qnD+K3R67PK57bG9bjT6bvV/MO7tPGdhe2khu2um+2yium0 l/OmifWrlPCyifGxmvK7p8q60sO84drBksfFuuDFhOTJkOjShujWmPzHhfXImubKpePPtOXVqevc t/PJrPTHtPrTqffVvO/rssjHx8nK1s7Qxc7R19PNxdfVytbW1srI5sHO98fZ6sfV+NHM6NjW6NPb 99fj7Nnj+uTcy+He1PrOw/fVxPfb0eriyufl2fjky/jk1vjyyvj01+Tk5Ojr9+7w5Oz0+/fs5vfq 9fb06v7+/gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAAAAP8ALAAAAACjAmsB AAj/AHcJHKiL1qeDCBMqXMiwocOHECNKnEixYkRatHQN3MiRY0GLIEOKHEmyZEOMGjuqJGjQpMuX MGNaRLmyZkuZOHPqhKmqpsCdQIMKteiT49CjSJN+KrpRqdOnMpkOhEq1qsiVtaxq3SoxZc2sXMOK RegV69izXMuqBIu27VNVam0lpJVLrdS7ePPq3cu378pbHxHSqilXcF2/iBMrXsx4I+CbnwavLHyQ rt3GmDNrXvx4LuG5hzeLHk36bmfBA3MhVHWrtOvXsDneUoWwdcdbq23H3s078+zaKnEfZN27uHHE vw/qdpz7uPPnUpN/sm2Qk2To2LN3bNmzI+3I2sOH/+eu8vt18eiPk/deOb174+R1cTr4vn7vg5zU Cl9qv/9r/Poh5N+ApAEom4AEJpgZgC2dp+CDiDXIkYQQVugXhQNhaOGGeGm4i4cchmhTZd/VIuKJ PukyHEclouhiRyp+0t1ALb5o4y4xzihQjTe6mCOCPb74yXxG0RekkEQ2ZeSRKA7J31RLMimik0A6 FwAAKgEQwC4AYLnRlVtu50WXAXhxXZdodmlAHB2BKV6Vu8DJW5crpWnnLldmuSWddt7ZJwBrtqkl dnDKmR0nXJBJhld0fjnoRo12FOkniWrphS3uFRplcZEO1Ginnv7JZ5+BcuQmpF1eRwuazi2EnRkA ZP/CUSYAmMGllwJxgiYnHJHxJ3+iAsDmQLp2yat2mj7JKa4cBbsLrLJuRKuto4p665/D5rordMmm 56udAUjWabEAHCsQqKFqC66D2XXrHLqfMhuqtcFmuwu55l4b7S60orubq9DpAgABHBEAgEadjumr FxutGsCxtBgw8Lny+krwQAoDwDCymxoam7+3riTwxQMZjLC8oIJq8UYZb9xqx5tit6qwAkUMKMUs A7AwqnV6afCwuSTqcnjuHgevlyCny/NGK2Oss8ao3iyQxEn/p1B2iaoKABc4e7plnk7nSwsX4sob std4mv2ysnHGvBvISWed4dZdK2333YOCvXaRbGP/N6a9Y5cN6dfMwo00ANcJrDa3MPc9p9nxFpUy 5IUTjuqYno65OGwAQ6crGQP5emykn+8i+kBXXlY3jr4aQKzOppfLMdsew2Z4TaULdPrZd/POutT3 wr77cUVrZ3JNpAsv++pLa06G40Q3/tzRzEuKMrO6tP466MN3SSuvnsRatWudQwd2Lo/yPuZSq7pc dbBPrv8h1O1Kb/Tizgp0fvqTNytq/ABgH/2IZ7/wvA9X8mtf7+xGNS0tKlMFNA71fJel6/3KaQJ0 38GgNibFra12vfEVm9IAu64JLEy7OB7v7nStNJnBKycs2cHqRzu3fQx/1tIdzUgIOuZNzk4vJEj6 /1RonOJl54ACiaFAVHg7YmmuS9B7jhF7M8Hx/dCFMBziDENGgK8RbHylKd9zVkUwg53JS/2yU7SY mKauceJKrhtIGtO0LylGkIo49AkZU4i43vXvXnCU1p/qeJ87YudKuUAeGgdZvUZSamLomeLjrNfI pSntjcDjFyNDBitfUWtzVktIeCTWtK41ME1xHFO+zjapLrnslGiKI+NqGMXXNLEmpISkD683FVcO BJZq2puSammcvzWMbKb8UxybmDpLRo+WzyHiLtAXJivy8ie+nJoycfYJNC0FjAW6mnbIVUc6jcxU M3QYxOIQuYGwM4A40qX+tmhHaN6vZ0UhpzMp2P+pdy7lnI5SXSj5hp6ZRYsWBuNayACKuhk2sXUp gRXJnklQ54zJAJKx2cas6b+N+DOeE03bySh2uA/a8H68nFavYqVDOxFgE8xL1JZUyjSWzrKiEvwT Sfvkv2v6UV4y1aStakrIfxkSO99KU7hwRtPQsTSHjcrFlexEzCIedTe0mKpSy8bTfYIqqE3Voawa NaaNgpJ84tSOr3qYLok5aFWypIXmCJCGferiSl5w64QySUB75rSr+XMqW3fZ0Y3cVWN6bRhfjepX 8XCCagF4IM4SOzfXQRVX2ZsqF6pq1cYaJ3sGc+AZu/pTj+CVsjW7WaNoFS1wjkaMUtqQJGMLodn/ 0lZBtr0tgWCrW9xetbcDyi1w7SPc4b6Ht8btT3GTG8nfMheCnn0ucdMqXeU6t7oUHSZ2/bPc7dYT hN4l1HXDW0+ckre50T0vDcGr3s6at700fC98b6rd+c7OYxjJr373y9/++ve/AA6wgAdM4AIbuL+1 uMxsD8zgBjv4wRCOMEYSrJIFS/jCGM6whgNM4Y5YeMMgDrGIGdxhvslJFyW2r2ZQbJcpsljFonnx e0+cYhg3Rsb1hVLfcGzjG9e4baKcUI9HY4vlAFm+7BoyY4o845glWcmKYXKOf+JkKGtGyjqGE5at 3BgHGXHLXF6Ml+8I5jAnZsyeLbOZL2TiTT15/818QfN73wxnvch5yh+qs5ibzDY66/kuaIaTn//M lDvrWMiEZjOeBZ1oRR8az4Nu9EoC7WZJx5nPiLZ0XgxN5T5r2s6YbtinN91mT48a0KHO0KlRvehK r7rQqa7Zq2E9TEbPWo+xzvOtbZLrSK+a00cW9a4nXepMD9vYwX60qiEUC1hY4tmWuEQsOARsW/sI R7rQiEDFU21XHxvZYvR1eG5RC1Sc4hSiSHceRHFuUZi7Fka2T7dNTaBYPEIKR7iBDWhggxvcwAlT eAQuKjRvZENIF7CAxSQksQhFDGEIQAiCxIMwBERAIhKpsMW24dPrb2+n2MIe0C1EkQc62CEPd//I g8pVbgc6uFwOMD/5KEwk744PCBaDSEIMdi4DGtCgBjYI+g1y0IRBTFtBBQ95gnQxC1lIohGKsIIQ mMCDqlf9BTxwgdZVwHWus6AFPkAELLST9GV73OydtnZ/RGFyUdSCFrWwRS3iXotT1B3dJM8DzNkg Bzq4Pd7ZKbus+xMLR8igBCKggQz8PfQk3KAGjB+6Exxx9AEJXtcEQrgkGHEFLAjB81hYwhKYQPWr v+D0WneBClSfAg984AMtkMTGX3N5cY+a0vSuzy1afgqNy/33dz+38NlN/DzYQQ5s0IAdRAH4Mdq8 PrBwgghKsPOfN6EJN0iC44fO/RwkIQdPYAX/gWqfeUwwIgvoTz8W1j/1JfCg9FjHug5YwALVd/0D HvAAB1rgCue3Ovex1RqzVxy4Z3DocQsmR3dyZ3fC14DEp27qpnJ3IAcaoAFyYArc9nzuAQtJgHg0 EAM9x30zkAROkASLx31NkAMqCAXi5x/k1x+4MAnnpwXplwVYYINYQHo6aHU8cHqoV39dpwKvh38b oAKypx4a2BuJpBGA0YS6ABi54IRQ6IRR+IRWCBi7QIWAYYUJlmB14YT+l2Xe5h4IaAd0B3cNiG7t tm6ikHKiYAd30HLH13dykAF2aAfjkYTiAQtGIAIisHM2UANAlwPZ5wRQIAOQ530qSHQpCAWT/+CC eiges2B+WbAFWUCD6neDn7eDpXd1WvcC9Ed/Qfh6HcABH4AJSPh/BlgaUFhkLPaFLJZggNGFVgiL sqgLVSiLsDiFXBiLvdiEtmALiRQbBah0B0gHefB2wddueJd3LOdydECHMDeNFmiHFoCHgReJ2TEL fVgCJSADMQB0kNcENUADN9AENhAD36eCKbiITwAFA1dzqmiM4iELjTCDNZh+VoAF+zh1QvB+PPgC OnB6LNABHfABLMB1HyCEH9AB+tcCs8Bx84h2pZELtjBhvzeLtchitwCLVUiFV4iLG6mFtbiFUPiK T1gXbyeMsFGMFDluJ/d2aZhuzngH0DiNOP+JkxVYgdZoAaeQjRM5eOkRBX5IfT/3c/7meDngBE4g iET3lIx4fU/wCP3xgukhC/hYiemnBeuHg/uYg51odQKpAwapAgdpfylAihzAAUYokcrWaauYGSj2 Cvkld7gojBp5i7sokrx4klI4koD5kSEpgIRpha7hkkKJHiU3k82octEYjTlJgZI5AROQARpghz1p AXIAlG+ZbIkZHrAgA39IfYgodNl3jk0wA9nnfdeXgq0plS34HlZZj5aolbWJiTfIj//IAjxgBVUn BC6wkC/QAqDIAVvXAQo5hA7JAR6gCG4Jl5DmGm+nCqWgX3SHkn1ZkoOJC7fohU7Ynb8YmH7/OU3j SRqIiXniwXYOSJPOCJl7Z4E7SYEZEAETEAEKgJkWkJ/5qQHNxxuzGR6DMH2kiYiPx31JMAVQUAPt 2Jrs2ARP8KBNMAX9KTPaCB2NgH6WWJu1aYM2SH/EyQL/yATBqZBZZ5b2h5xCyJDL6QFD8Jye+aK2 xxeUQQuqUJe1gAu3gKMcmW3ZCZKziJe1uAtx55G9aJHfeYU4goWFaZ4g95LYgQpywG7NmHdw+HIw B588aYcVGAEHYAFcGgH6mZ8UkJ+oQKFBiZ7aMQsz4I08x29JmX1PIAVAh5quSXRP0ARO8KDvOHay WaHOgQkYqpX5eAVZIAQq8AJMIARC0AKl/4eQPbh6L/B6J7qQQ/h6a/kBLUqAfqoYuUAL81EZkQF8 vlgLdJmLdCmMKEGFtMiRKjmqO+qF4dkaiZRItmGRo3GeMfoatxCl7RaBNumebUCBO4mf9GkB9XkA EcClY2oBFNCsY1qm0PGf2fEI01d9iAh5KDgFQwcFNuAET9ma7wgFDwoFUOAIExqG0NmZueoaunB+ WqkFGVqDPKACvUl6/xgEj8oDLRCcLxCcH6B6LGCKKdqQpegBKeCcmnqm69ohmbAJnxoZ+YVidlkL nRoHnCCMKJYJmUALt7AJcVCFIAukWOiqsEqLGjmeTKhtAtGEooGr6MF7eLdyLReZO5mlyf96AAfQ rDhLAV/qrBQAARSQATSHri+qdtpxBH8oA0oriHNKiE8wBQr6BOOYghBKruQarlIQj+khrdABqFrg CPGaj0ygAj9QqKT3m1XnAjygA0LYr2aZkCpQhAxpqWvZlgnbmUaLGbbACRqrCZ5QGfk1pL9XEJyg Cl1YGHShHIVxpB2ZpL5oka+Yl3xpmFiYhUmUhbi4GS4bHqYgB435q1ZKjcl3mdaIrD/brFxquj77 sxCQAefakptaHLEQAyKwtILYb0PnfU5QoN9HgobYBOIavFYbpxHpHlz7HI1wg1sQtuknBCzABGZL elj3jz3IAwWZema5eh/AlpVaigf5A7L/4KJGtLBSQQuZEAca+6k1aqPBmAtv5wmlMLEHIXe0cZF+ W5cYcZFeSKMQ24X7JXc0yrFBSqs4IhsDuBebmx27mgfo5pihi3xXKqyXCaYWgKzM6qwRALSry7py 8Lq0F7u9cQneaAOO53iCSIJQMAN4eo5SIAUROgUw3MIyLAXv2MJ8urUgvBvtapsain5YwAJlq4OK +rxXV3WvZ72q15AfsAGUqpbMyQKSkIp4O4aYgRtpEAfoqwmdMB/UaZ2/56mfIIzBOB+J+wlZ4Ql8 u7G10AmZ8AltHHeakAmcsAkbK3eeIMcaexB9mxF/mRqWm6Sa26Sf+Rxw2MAl554RLJnJ/5cBxwqm FHAAGtysF7y6EAC0ecCZ6ZrJaIodluCNOWAEMfBzggi8SUADpAxwSRChUtkEUpCnMSwFUyAF4Wu8 ORwbsoB+YJuP6NeDWbCP9jq98TevHwCKACuEHICcH5CWy4mcVnDAgaywMZYJaXDF6CvHgmGjtHCR m2DGAFwZMSJ3MpJgFzkkGLEJGTG/1XHOmpDNbmy4tLDNHvnHAigQs/rMYgiAzlELcrBuKIfIfKcB /3yl80mfylrBObusG+ysEKABQ0u044se1FoCqRmO2icDT+AEJHwDULCU2EeuKAy8VivDWSAFN1xQ tQwbsIChy7uhhfoCQhC9VOfSRRyp9P+3kPZ3f/jXkMyZAkBQvOJ7R+RbFLWQCWaABtScx4CrXwCs CWHczZEBFhY5H3i5t2G8klmRvvMLFsI4JL9XuB0JpNPkEZbrwaBWa1TsHCVHcja5d5JZgcI6uhmg AJVZwY4cAQjtsxpsAUCLjWY6xfgMHdSqjjMQyv5mA45QglJAdFCA0YbYykzJyi0cvFLgCLLcp9Ac HpQoqJeIfoxaqGBJvWIpzDodhMnpxCkAvg4N1C0bB2dgBtOMxXlsHkr9CdsMdxfJCZ3AzhfbIHDH 29lMC3GgCbTRxtnMCflRC6qwsZ1auNfJsgVsuSqrGQn8HAgogdGIpfHJk/Vph8nK3Tn/G6YJPaY/ qwE/iclFe9aA7Y03MNgGmqDnmH2LjcJSYANWu9EPKgXlOgWUZ9l+HZfG4bXMW6i96Xk6SHXUG39D qAJwi9NqabAt8Iip7VlB7ROfEAdmUNTTfL5IHRmlQJfVab5y/LeckAjWYRCaYMfzEQdhTMYGUR0Q ywmegBEwDneqsM5yt82iqqRh/YSWO4yYMd3OcQr7XHJXqt0TQIFsUJ/1GQEaYNDJyqX6Gd75uddk /cGXHR4iHAM2MAPYWtgjmMpJsNiGaLUwLK5xGsswPAVZ4NMmfeXZkdm6zAMvvYlnG5b96gL1d9MK yZDM6eAQXuX2rMl5uxi54LFk0NrT/3zFWD0cH16jQ5IGrp0Gwi3jG4sR0lzp9wux5gvbGkvpGOHG +UXc+YuxtzjPz50ZQH4cE0jkwmqZjHzkdSgBlWmfdjgBpmvr4j3JkiymC93Q0XrSsBELg+1zMhCI p9maACfmYT7meUquIg3DjsDmGejm2HHLmu3DLdDLYAmQhhp/qFfMo9jgHvDgzsyk1M4YwG3hZHDo GA7bfrsamj4cMqJf844RqsDiLZ7UfBsZHL6+/Jtfmo6RQ6qdHQnorHbP/h0bCPhyo0u6pHvk3E2f yGqNdm26us6sYQoBFiAK097f9BgwOleOgYi77JgELXyOig3L+F3DaZ7mAsffgo7ezv8xC+5qiZio qJ5d4PPKmz3oAndO2ipaihyQAg9+uRE+Z5pLBli87mRQBmjg2hoe4g9Lnf7+6S3e4tX5HY6eEFQf wPaOER/uX9X5exa5qiMr3YK8ycWhz9TIk5eZn7Y+ARowAfe55GKKs3aN8XqvnxkAtHTQ5h7vpNAx Bd9omiiIpy1MgogPBTPcwmnuCJD/COXun8DuGrNwobr8jzmfqPNKrz34g1sX7mvpAWSLimRX+VLx CWRgBkQdBkwP6VhczVps3FvcEN8B7xNRuLiv9YIRGVVPi7RY9mhv1n/dG2wvwa6eAROfrGwQ18hK wVEeptKfnxkw3r7e1zFf/M8BC4P/ja1KqX14GsuKz/iw3PLlr+aQX9KAn/0J3xu6AKhbqe090Ms6 +AIKbno+H/oMPvoqEASVZ94A8UngLoIEBX4qSJBWQoYNHT7cRSuMlzhxyFwkUwaNmTQVM33UtCkk J06bOHniJDDlQZYtXb5c+VKgqlKqPtHCScuWrVq4aum6RUsXRKJFFyZ0yfBoUaZNi9aSI0fD1AwZ JljIECFCVQUZNGSlYEFsBrFlzZatagFChlNO3b4lutTgQKR0C8qFmxeulBgxatS4cSNHkiaFp0xJ IkWKEylTGh+GPMWRZEdD9V7Oi/cgw80J8WIG3VAWoyyls2DJYoXHDyE8eKhQwcI1/48XL1zocOEC NuwPHzpw8JCCBaJZoY071Gx3LkLPxxvSIsOFTCYzZMZcNHOGY5yOcT5+z0QyvEiTnVae/xQTPcr0 LE/GfEnr5k2ctXgCtUUrl/PmdVkq5Q+0W6T6Ki0FIrBggq000KoqssjSAKsHsRqLQrIooCCPAANM jrmCOrtrQ/4ukSGGGW5IYrAcCmMMiiacKEwKRx6LLAtHbrxExA075Ey5iHQMTRdMTEONCdR4aIEF FlyY7QUdanNByd1S6O0D4FLgIRLLgMSMR/8AFFGX6Lwgg7uLwrgojY3S6Kgj8N78LqTxxnsPJU46 +cQTTVBCybz09PRkk/DME+kTk/9mokUVnPL7qRacdOwQRIW4hItABzOg4ACtFKDwqgfTmhDUT6ui AAI7KA3Nyw99/AzVt6bwK7AUCWviCcWcgAJGyQ6bbAobIbPEVeNUXQ5MYd+SRZLTsGCWCSGenS1a 23LTbbcPUuCggw9cEMIVgrY8tilid5H0Rx3j4CLd6SyyTgwysuOITXkr8i6TeuEETxOQ4uQkk5D2 1Pejfv0N781+U0qJppxy0eWm/USMlNVwi8pjqgK9skBTTcmS8FKPRb1ULTlumRiucctttWSIYGlC hsACW9EwKZKw1QnIen3s1+JUNrlHD4vtj2eiZpGlESuYbZYJpZlo0slpd1PBNw7/UlChB0i2JFlo iE6WGNJ00/UijUzSsA6j6tI4Q161uxvbXjjvdRtufOd+UxM/E6bFPoFSHtZnlLVmaMAMLHVQq44/ RvzjUkcGnCmufza3cYgsSaKGJAQr7IkmHMsBCimgiGwyKbKADBbJxfU59aBPT0hIRoTAYgmll4iW Nh6orTbqDzz4gIUXFDGd9a1VXxVyvo0zw4CvyeQuDY7eRaMM6M1Yc216vWtz7Ovj9qj7jyoyxLvr xff+vZz6pSVriP3u+vRaLLbYK/k/LvAr+xFXSwP1hTcW6OL7519BLtEyFDWBZjbLlRSaADrKHEYx NmJFAIf3JQqGSIK7uIXrhiCE/9nxgHa2w521gqOCFiACFuC64KQq6D8V6khMylseGdBQL3qNzXoc oV681tYRHXKnIm0S27zY5EMftqmGH6EPLewVB8jtiH3G4x8q5MCGNmiAQPC7lP2ossX7RQgCcqhF CldHLh/9TYwEsYQTajAYFkHBjZNhzK4c85gcnXGM5TJjCmcxCaO1Rlq2sY21PhCbFihiEig84+MA uKMxwHB5XggD9dgGEkFlopJLXOIQgahJIarNI92Jwxu+Uy9NCKQUn1BFv5yHBk6gKmJQ5N8tREEH qUwRfrfEpVeokpYv7k+MihyjHhFjwFq50XOO8JxiFAOFLFgiFnYEIB7bl0JdFP/NCn6EUm6gFpsX /GARrkCkHYFpQS7RwgsGcOQju+AFSJqtekMcXw3l+T232QuU9DwiPn+YnTRxIpwceuIiTydLAkmF Dbi8ZVUuhikKgJEgvpTgOFsITUssJmbGbIwUbEVHaD6HeCyM3BlnAYtGKGIIrtGB76LUghYAARGT OGFHPbpCMsKSUraIjvLSyQUvgG15PAUqO4XqhTGQ6ToYQWpSkYqmsh0VTWQiA5meipE0HI8/rxRo ybLGMJLpIhe1uEP9ELpFj5UqA3T4Sd52Yp9cZDCDGNzFP8Ml0ZBCUxeXmKPnkgmZR1xCron8aE2z KkFdjBQTkFiESYegiEU0AhP/sNiZTGf6P5pa1Tm6yAQZ0Pk1znK2p0EFahd4KtrP9tQLpB0tT027 TnaydqjsLCo7J0IGNKXhE7Y4FlaDGa6uZtA+9smbTmgxSzak5SxnwVCpKKCBUtrEuaXIyaLYChSv ao2ulr1gLC7xiEfc6BGWYEXwJBvNMk6zo7NA7yxikV5d/FWm1w2XLcZ2EaF2VrRcEC1qTata16r2 tK/9L4BlC0mitvOoYvtEGOca0N0KK4NtxY+jopso+QhEE5qgAxuK66CriOUqbKBDJvjEEkXRohSv yAlPbAFht6oMvuPFBSwoYQlIcLfG34UpLsZ7x/La1K7qhYUrJjHkIUPWFu4V/2dg8zixnHxCE2Qz m3Y2Ej0p53DKHLmy89SUQyxr+Z3W845AcOtiBpOTZw9+sC7UGtzoKgqVMvFES+RDE1WcIroq9oku fvJg6yrZvGfEBSsowV1C33jQ37WEK3S84xfbsbCvEPIkJAEJSlNaEpGQhCtcEVlG+9nHQtPzotZs H57oBLgqNjWq1fzbnaiV1a9W8Z4Bp1szA24ovaXunn2i4vzk5871Ee59VqxnYrdYeI0+oy5gEQlK UGISlLjEJSwRbWlTe9qXkMXD3uvpwbKuvXsk8pAlIelJlzsSReb0tmm65B2323Flnqi75f0QZIsx FrCARSvuHYv18tvf//43kv+Pze0GC6+wsZAFvl0R5CAvXNOuSMUkUgFxV8RC4ANf95/nvfF4J6Xg HHd3vUG+cZGPXN4lN3m7aR3vlIec4LVuucpfzvKYjxflNe/oyuuKc8nenOeAzfinf57zme986En2 D7uPjnTKNp3mS0+hz6HOP6lPnXU6x67VG1d1rW+96FnvutC4Hnaxw9voZD/d2NFeMrWvfcFB77bb eabzMcv96kWvu90lR9e8633WePd72s1+9sAfyxa+lGYTwV54ER2+6IRnPKocD/e4Rx5Iky9eueKK ecujKhcrbkjiG6ILzneeS5/XttMFyxDSQ9T0IkJ96Hs8+tK/HvagHzwG1Tz/Yd733ve/B37whT98 4hff+MSv/epV/9DdH9/5z4d+9KUv/eSLviEZnH72tb997hu/+rO/fvO7P37ylx/63/+P7YVnffWf jv3tb9z74a81j88fcPK3v8rwn/+J7Z//x6q//ysZ/xNAVCHAAuSSA0RAHQnABXQVBXTAAIHACHSO CaRA42jAC2RA8NPABOTADtxAyNE8EOSPDCTBCvzAEyzBFFTB47DAFnQLE4RBzHjBGWSKGrRBosDB HHwIGeTBt9jBH3w8IQRCFiTCGGyJI7yMIFRCJjxCJyRCH1RCHTTCKSwKKBRCLPxBKXQOAACAhvBC /vDCL0yIMEw5LeQSMzyO/zFkCDWEJjTUGjcEQzKECDYsQzpcvyoEOTlsQzzsKC50ijGkQzPkQz68 DDUkRD8kCEEsiESEC0MUETjsw0VUxECsRL1ARDIsxEHkxEwEQD2cGEFkRKaAREokCk/chVKkP1AM DVG0Q2FRxU1sxE7kxP5LwlYcxDnUxTWsRFlcxF10C1VcQRH0kS7UxEskRWR8xF5URFRERFMUFknk xbeIRWU0RGHkGWl8CGwUkWoERkf8xVRUxki8RdDwxUx8xVEUx1dcx2NkQ3C8Q10URXGkx3akRDtU RxQkxiaaxnq0R1NMxHQUSHYcxXmEx1lESH9MyAdkxZKRw3ycx3usRYmUyP8vPEjW0UaHcMMwDEha tMiNJEh1FMlmnEhf/MT0M8eRhEZwZMlj3EVnJMmX9MhJ9MeLDI2MpEiZfEeXrMeWlMmE3MSINEkD bMhQvESfpMlzLMlxzMaixMU7ZMee5EmlXMmpJEmhjMlwAcSmwMqqrMqC5Ml2DEubpEponEV89Eim LMJ9BBKIBMt4lMq3rEm5lMpvDMuFJEq2FJ6HlEt0hMeu9MoAwkmaNMuKDEy/tMrDzMq6JMxoLMd+ REqyTEzGpEy8DEyFREqFlECnzAuVrMzMBMrJhEm7LMzS9EC9ZB2QVMzVZMzRFEzOxAzVDE3WjEzR XEzJtEWUjM3ZbM2xpM3/sbxLs5xMzBzOZxzGwAoQ2TzIzLTNy8RN5zRNIBnMQ8TD2vxN5wxO94NN 6oTL6+xN7zTJv4zO0xzBzhRI4RxJ1xRL9IxOz1xHzYzI9/zH46Sp5PRDwDxLv+TN9ZxL00TF+XRF SplOTLzP9ERM9ETL/cxD1EzD6izQBKXM+JTQ8yRM/axItbzJx7TCphjQDuxQDfzQC9zKDVW98iRR hwhRCkzRCBzRE11RB3zRBYxRBGxREp3RArxRAczR/6tRuxvK00TOyPtRhmTQzhvSvAxSIV1Mx9RN rgxJbtzGB3VQKE3GAI1SYNRIDL3C7YTKKdXSPgRJKi0KVyzFI7VMDOTS//zsUuoM0y89RTKtwyXF UhdMUzW1U/McSDeNUyvN0jltTDRt0jFtTjyFS9A0Dmw00/GECya0zmVkTWNMRj/tTn1M0kj9Tke9 VEgVVEk90wwtUmocVExV0ENlykTVTE810U2tzMtszEY1yDY9SinNz4n8R6wUU+UDKQJl1V1NSqvc SS+NVTCdSQR1x46kwTot1Oy0yWT9So6E1StdU8MkVmnNx0VFVmY91WXly2b9SGCF1judUDu1VT1d jlSN0qX8yT7lTVcdzj9d10H9T2v9VFBF116N03f1Tk5lV+wE1Ep10nrFVnW91EbVV3gtTnIdQnod 1VXNyYENVXcFz4NF1f9itERenU8s3VeH/VZqtU26rFYOvdZHjVaB1dhM/VPAbEmPjUp59deKZdiL bVWDtVj47EtfhVCYZdn61NWX/Vh7LdllpVkITdmb7Vmn6FF8ncMyddCIFdlJzdihLFqI0EJDbdiT ldmXJU6mjdlbpbyUtNii3dafzc7CfNoljdobDNmmrVp1LdvxVM6rddqVNVoNVVWqBdq31dq7XVqx bUT/dFNGfVheLcuMxdirNU5T3dJ5dVK1fU5sJdyY1dpU9NtjVdzFNVnBNdzAxcu2DUfElVq6FdQ2 ZVtmFF1wPVi5DdqOpFW37FY9dULWZUa/NVCk5c85HdfVfVKcXcuWfdP/0vXZLrXQTI1Pq0VLCr3Y X0VYkDLX0PXS0c1S32VOsJXSYsXdMNXduQ3UoePaBeXdPUxe/tnRcNleCQpf8f1ejATdmjvbN0xb MVpfySpfSnlfmYpf+UXdHTvaKaxf+Nvf9utf9cvfJmzfHPxf2yvg1wvgJxxgGzxg02vgzkvgKFzg GXxgy6vgyIvgLJxgGLxgxuvgwsvgLdzgFvzgwCthvwthHjxhvVthu2thuUthAh5hFXxht6vhtYth Bp7hE7xhtOthssthCt5hEvzhsCvirgtiDh5iEDxirWtiqzPBShCBEACBKrbiK8biLNbiLebiLvbi L95iEVgFV7kEEQDj/xAQYxQ1QimmYjB24zeG4zju4jRGlTI+YzoeQjaW4z3m4z4O4zGuYzP+YjQG 5DyeYj9G5ESOYzzmEjseZEbOvGI8AkWm5Eqe40IO5Dc+Atn71Em25E8GZUhuZEEG401+PE8G5VRW ZFEGEkcuZU5GTlRW5VnmY1bWEVf+YlNOOh+hBFr25T225VYm5S+OoK4liF7+5WR242C+5WH24mIu UV5W5mn2YmYWEVx+5qJDZmrmZiy25g3B5i6G5nL1EWfuZmoOAUpQGUpo4y8WgaIz53NW5nRe53au ZniW53Om55Jh52XG53zm5n2emH4G43feZcixZ4BO5kEQmkFw4xAouv+EVmhfZmiecegzjuiJnuaK VpmLHuSM1uiFbuiHNjtLroRFw4VCAGOCUGZdVhlckOUuLjqTRmmV/mKWTmaXLhmYduOZruSTJoiU XuldaGmt4emhjmbIoemgtmkvxulf1umJOeqbPmiGqORWaIhWoOpkDoE6EppLkGgt9mlFxmqG0Gqn Jupf7mrAAWukVl4fueqs3mq19mqeaWuqTmqrpuSyToizlum09uW11pq7RutIVmpFLgSCsOnE3oWm 3uKnpuWoVpmYfmxjBmxEZuzFVmy0zmnJoWyxtmxKzuwqHu2/7uzG+ewsHmvM3mwQKG0uhuxZluyS SW0sLmlF1jHHTmz/XKhigiCEodAFPuhtoh4KJQABJYgrSxYBvtaaWIhn2w5t3G7sK97t4f7tuBJu EGDp4j7u5K7k5ZYc58brtz7sRM5t6t4F3tbuXbju4B5uEOBu5NYF5WZuoRHvwiZvvTbv6bbi6l7v 9s7u7d4F45Zv+g7v577i207k2F7v4U4I9WZprFbpxPZrRZ7tyR5vXNVwSmZwnG4ICCdqCXftXajw RL5w2s5w+ePwy37v9X7w9xZxCrfkE5+Y2rbi1fbjDk/rD4fx6ZbxSqbxcLFxByfn8kZkHR9urSYE DyfqxI4FEHgmx0bkEHim04mFsE7w6F5wFm/w9VZyJh/xJ4/ySqZy/9a5cvzW8HJZcdXecRIHgSVv 8zCHcv5W5DK3ciy/cS0/ci5n8i+Pcyefcyn3YzsPbzwn8ppSc0VG8i7vcpZGbqJmcD8O8nDRhSHH 8T5e9KcG80dndAs3OEvX8xzn8zhvcUdn6Ujv40k/lkpHcxVX9FFv8UYnak5HdT5WdWFh9b82bP1G ZB2rhCuuhPSOdTAHgdwW9krm6NPx6MrO64SgZF8H9mPXdFI3dvWm5GSXnGUH7WYviGffhV+34mAH 8Txv8Wq3ZGxvHG1nc26v9TiG9nCXdsAmdnNHdv5Rd+jedWdHbIIA99Ke9haPoKFgBTKvcjM39Evn Y8bu99b+9y4P+P9dGHhKJvQ71/X81vdEVnjSZnh5J/WHj/g6L3iKh+1Q7+OMH3H+bnic9niC558z H/l87/a9luthJ3U4Z+/vLopNEICd33kySIieL4gz2Hku2Pk0KIg02HkCIHpkRHAXt/iYJ+uZZ3Ri t3lCwHmi0HmeFwCfLwigJwihFwCiFwCjJwikFwClFwCmr/g0h2uZN2tyL/W0rvqrh4is53muJwiv 3wWwF3uy3wWzR3u1f/mnb/c4rm83p/kWn3tKNui61/qt/3nI//qhL/qjT/qlh4imV3DEruksh/tp 53JJLwouINOFSAMvJICHGkPSBwABMIgxPP1StHGEL/nOh3tZz/P/0E/10S/9v0d91fdC1nd9coH9 +519kvfjQrD9xJ/6wo9jGmd9UTT938eg1ffC4f+E4pf9tXd10V7+5qd53bd13nfF6QeA1K/+4L/+ 1/fC2EfG44d556dmHbN2Rf6Dokj788//898FAmj/swSIXQAG2tolYCABXQMF7Gro0OEfEBInUny4 6xNGixg/WaTo8SPIkCJHTsS1CxfJlB7/WGx5EACBlzB3ERiYxuFAAAIJGkSoEADDlg0jitSY8eHG jiqXMhVpEmVTkiyFOnwZMycBmjZxDtwJoKDVn0GFEg1plCPSow6jso36tK3IqVR7wpSZtSaAmw1z egXrc+HcsiDP/yZ9CPcwSZOFEH+sNHeX2IZkFup66TAN4Jy0JnflrFcopZFnRxtmbJqi4tMTHc+N vIuzgMpdG2IG6nUzX89zQxdNi9Zh4bWqT6cezpqqa9iyddLOPBB3561UeZv1TVr4cMbFVR8Xmpyy 5ea2NXPWqXu6aN/BG2Zn3LBVe1iPdwZ9ycmrQ7w38XLRrJU5VbCkB5xaDa23S3uIvRfffIDRdR9f Den3X3/P/feYgL0R+JuBBSKYIFwLZiffYw7ah5+EW/HnH14YDtghhxd5CGKIu8A3YoO2PYjif/sN VCEAtFw4V4bVbXggjUmyZdJctcGE1S63OHhLeLTkNBAZDYVHFf9URsJ4HXtKiqkSk1Q5iddMUupI 5WxWXpklXY91OZh1dWI3Jp4glSnUmVCqGRSbzLmZE5xbCjXnR2DKGGOejX60Z0t9IhTllFVeCUCh s3H54qJIOvopCPPJlFNQnHHBFYBXnroXAKvOxemBnoLaqKiX6mgqqqi2ypWrVMHqoayz4lnrpaX+ mCurx7Laq1C/xhissGISe6Wxuyarq6vKvqohjNBGm+Rjywlg146sjhWAg6ze95izin47bGsvjQvl ieY6hK6O6s7Xrp1hvqtkuPKSWy9996a707rbermou/8CHO9CAw+UcLr4joXwvtx2OqPDSUJqUbp8 Rfiati+lcQv/VwXNhahHinrb8XAfPxRyVyPjqqVNKLOq8qYax8oxzAnKzNVYImt6M10npywnvxsq FXR7Q9t7rc0l57z0ys6+vFQVUIcUy1xuZrULJ84BSPDIDd2iy3yxNP1laW117fVHYFMldkNlj6cp 2pqqzfZjbvsMLNBszU03RXYLhTfZZlc1MbIOrd322wzHbTjiHineEuN6MzRy3wD+TfngGzHKFgxU VEEFDB+pPlHqq+MAu+pUkABS7LZPVAXvvS9FyVy6DZpQTihvknba/X2GXukNR5V76x69LlHus4PQ O/Yf5X67RNjz/nvwWw3/EwDGI++38vNRR6fT/X74fO3RUzQ9/wjV07469x5tv7v34FMlPFbIZz6/ JS8v6qvc1kgCPf5lr361yx9F9te9/h0GeP8TXwCLt4vjERB9BnzM+hKlnsItBQfekx8ITDg3GHhv dizsne4iiD3dkcB7hyPJIOYyqisl61Ku+tPM/CaUQSCQhCpRYe9QqEKJIJF3s7PhDes3w9vVkIIp ySFVdhghW2kLiJGjChGb5z62NLEKSvxeClsoRRhCcI28o6ENl4JFoWhxNly0FqXyxSMwFvF0TSlj 616YPUHiT39TBEEVGwiXObrkjj1UleQOlrYhas2IKVEdC1lIBYmQQHVoNGEgVwcCTErRehMhJQtd WAVTMuUIc//h4licRKiHVKhXBxPKEfr4NKZg0oyiRKQn5wZKRKLxlKyTnhlLqcyouJIqsLyMreDU kFoG8WK41OXlltJLTXIymExMZhVHmcxUIjOUqmTlUpoplGeK50201FbBHpNLMbbvTtr0JTfJOb9x rrKcytSnadTZEnbuQpZYeice4zmXeS7MdJYkyfeiyLsXfpN/1zvcLy3avU2aMH5MEcF8HJILnVmE DNIM6WZCKgJs2lMlEfXIRIsJu4ymEYUT3B1HV7c6m44EpCHdxUiFYtKfNiSl81kpPeHW0pS8lCIx jaIUN1lMml4Up2n06FJ8GtKgtmSoRDXqY5DaUML5kSlN/Sb/Vqe6SadiNKdYPYxW58PVkp50PmCd i1jZ162HjqSjyTzl7WRKvX6iUrCF7VowJ7qUEGyOqI59rENiEQKW+ospfkWh7gTb0fwBdJ+hROwJ F9tYyJI2pJKl7Pssq1PMBjaKmxXnZ/1J0cT+NSWMLS1uf3rapFpuqSS57EQACds1yvZ7tOVpU26b 2+VSZbdjNd0uVfvGNgq2k1W4XRldG8dhclOOdLwjeMN7R2tChCQu42tf2QhTie40uLWlSHZrGlWm MPJx4r2veMk7FPO6L4Hpne5613vM+MJ3u/xcq0rqizP8MpigFhGMXnur1MpKt5DcFSWB3du/CyN4 kd9tMIhJ/0UVCIvwSOiFaEcDPBHryg8HqnMxVGEM448IdiQCZS6Od8HQ5zrPcClmq/Z+WcMOe0TG 9NOoSm6c4+XuOMI/K2tUVknVGnfXyDF+8ZFvms4lL7nJJZ6whFMb5R8DOYVYvvIqs1xVxCiZy6X1 cstGCGWVvK5rgi0mi0NCVZjmFMm2vYSbl3uJyaKWLXVes0ZdrNHOigTDGIWqSEIA6EDjdtD8rSeY DW1nRGtZ0Vp2KpH5nEY/k0TSlK40oXnr35Ac+nsmJPX1Qg3qUX8aLqY+NWktXck5pwSU153y4Ujp 3taZEJ3DLHYaz9mUNuN6PnCOM6bDTEZfDlnFyK7yewtM7P9+XrufrWw2ZJ9dkf6eGCS+rnaZu53T bRs7mcjuNjpJwmxwU0XcEzkvr39LbUcr+9jeHnayA87otsyb3i2xt0QIU+6PJFKx6TaweqvaRDhi r40kEcFoDd6SWFj8y2FeNUganm00ijx6qqNu1yZORe91XCQY13jbWj7uaIOc4aEtc8nTGHFXH1Lk MgfJy2E+F46nBN/RVUnOfa5zAEu85yw3TdCFLhSiX3qv+VbgWzVKW2E6MX+f7Pr9jslMqddbJUbP 5lIWqGIHtrfWnQY79bK+ZbIf3OzkvvpI1F5mtotd5zjwOtdXyVm5J5nudS/63Y+uEr3rXYV/TzTc +Y5cghv/3iIIT7icLZLqKGcOJLeuvK6r/nEPbb4pkM7c5w0fetSW3qyd/0jq6b56VZMeLqdHXOzJ PvvnHiivr2fMEQBn+MuDIK6jj5Hvf3+Y4Fdexyox/pMtknzlE1z4dCc+9MkqfeoH1Ppkx77CP0HS XYSQ+20RROVJHJJV4Hv85Td/VNBvePWDhP13dz/8ESN/utP/I/anOUbgX/7Bxf6RXf95xP/BCC1g hPcR3wDCngVJHSW0HkjcWC4cyAJ+QgM+IFuEQAQK3QQW3kNcoIdk4AZyYHJ9IMyFYEpYIAYyoOWh YArSHQvKm0WQ4CdkoJBYxCWIAAXK4EeIwKSt4PRRRAiI/0ACFhVG7KBD6GBL9OAPAiFFCKEEFuFE HGES7oITPsQWPgQUSuHFDaHGUYIVSgQWcs4SWkQXOsQXgqHLiaHBkWGpISEa5qAubMT4NZ8e7iFR bYT33WEA8qEgDuJc+KFFAKL4EaIiLqIhPgQi5uEiRmLlGeIaSqIlSl0GxogS5uAldiImHsgmMqEn jmKzZeLipCEppuKpmSJQbYQqQKIqxiJp5UImel9D4OAryqIu4hYtNuINuiIs7qIwzkUvwmBL4GIw DqMyjmAtOoQtcMJG0IIuJOMyyuLaZCInUsUzRuM0VqM3XqPpiKJFbOMSdqM3LiM4RuNckKMdUuM5 kmI6ov+iM0KjQ9WjPd4jPuajPu4jP/ajP/4jQO4jz2gjPQakQR4kQiakQi6kPQ6kULAjQ0akRE4k RQakQ7YERFakRm4kR0bkRVpdR4akSI5kPebiT5EkSqbkSJpkSKmkS77kRLLkfMAkTdakQcpkS+gC NtokT/akKtBCLUCWTvYkUfokUArlThalUqbkTwblYw3lUkYlUx7lO1alVV4lVmalVm4lV3alV34l WIalWI4lWZalWZ4lWqalWq4lW7alW74lXMblkkGlVNZlSNKCNCKlXe4lR+KlLc4HXfKlYEakX+rl YB7mQhbmYyAmY06kYzUmZC7kY0YmZRrkZFYmZvYjVdT/QmZ2Zj/+5UNwpmeOJj6CpkOIJmmmpumY ZkOgpmqqpvfZQjjmAmvKJaXFYzY+5GzWpm26GW6K40PIZjTSZm/C3G+u424Wp8Ydp9oAo3LS3S2o Ah4KxS0453NKXXROZ0tUJ0bg5HXSW3YG4nZa53cup3QGIMqcJ3CWp8FloCoIhXqyJ9m5J3zKo3xq HH22RHzeJ8y55yuCIn+CG0ZwgvdxpyYGaLMNaIECKIKemoJahIE2qMYNKCdUooSuon1qYYZeKKVV ooVyqJt56IaCKJdl4nk6JYlSGiC+50OcaIqe2opahIu+aKDFaItiBIrS6FzWo45S2idAo6L0KI79 6LN4/4iQMheRBumR5taPFqQgoss6BcBDoIuUBpEzMYcQ7USyMOGgDGL0DaKVBEAuTGmQkGmVckUm gIzo7AKVciEAiCmZrmfzfekgtmkQlWlRbdGlEMDy2JEj7USaWikf0qkkfkKFBIAXOCQnGMBAGACH +EeeCpGddiKP8qEZAECgOkQmAIAZOITeAEDCaOk6YemaimpOZOqmZukkah8hxgEeeQEAxMFDfGqo DkQAWJ/f0OpDuKqrwKqsKiKh7qGuogqq6qmt/Kqp/qmt4mqpGl6wKuKn5kQAMOGlXkqnJkux5mpO hGqhOpQgKsTY5AcACB+sToYXCOpAkWq6JosBOASjqv+qs7IqIdYER3zCTDxEuQLAuaKKLYlOvu6r uNbrvQKrvPLhv95puzbEu6qrpr4pV7DKK8ETvJLds85rrN5if+yrmwRqqu5gTiTsLiwsvmKKvnpi pfJhf3BpQjkslD7sqEKsmrIKrOIErDZrvBbpgephmOoCuogjy4rOQMDqbxCQlLZsE74pz+IpweIs If5sEM3sXtQszLpsskas0FKtHlbsIFpIQ/xEQ/jqrmKKzKaK1OJE0dosIZ6ssIqtZICqp4rtZFCM zfrpugKq23oCpk4sxRbsIFYrp1pE2WRJ3D5sAJyppgQuyXCr314rI/Jt8yHu4LLKpt4H3qbq1O6C q4L/LN1eKZsaLtpKndYKYs2SgSbWhPWBq+Tebd4CCOS67SWq7R62bC44rENcrZUALLxurqAOhEKc K6x6rSCGrh7WRLjWLgBwxO0+rL3uq6bYbslaBPFaovBKnfPi7riW7O/6qa1kqvbaCsQu7+XOqeMq 4sIGABkIX5b6ae/uQvYCSPVSqrcO4mTIKmZIk0KcqemGr8umr7oSQNFmhd6C7vjyYU2cadfSrlYA zmzAqpDMxv2Kq/cVsPQOMNk9cIoosE74L5sCMKnayrTCLHjBLAOL6h5OLx9yQs0OBFrwL8RqcABw 8AHj77i+bvwKopXchdKm6qUEau4y7O7qxKVORqcG/7DQmTDdLe5D6PCV8DCAvLCoKvGpPgQSR6IR GxwUDwQT70IQ/63uQsalJmwXx2xDODERTygFM2J/jI3R4sTYdMUWDzFzXDGm0jB0ESKjTkbxLuyV gPHcMkf+ihTtdoW9qjAJl/AZG97O9qy7chEfv221KiwjH+2tKnLjMi0f6vHHfm9OcEQYV20hi3Hj PPKgHrIeoguzfu3FNizz6sQgH6+oYnKj0jGDVt6nZirqkinb9DAqG8AO0gKjrvK1fLL4WrLFCuzY zG7xsukMe1BX3LLBAA69XsTApi0pG5wzj/EydzAIr6mrtrEP1+00TdKqEnMkToYBAM6ljs3GNkTH bv+zul6zMvPmOM9y5aXNpjJu26apsgoKvlzJB4sqrAJz8Faz0LkqwILtPZfUHPtN0upEQj/EZKSp QRsvsnopQYPbQztERAP083bvDruz9xZyQw80OS9iLvTzJmu0rTDuAne0Q/8tRM9xt9YxIU7GSTGq OFpJu+6zQ+gCGeCF+TLhbGxqFpO0klZemDpiz+K0GgLATq+p5TK1m/IyAkMGJVt0SRueVB/tU7Oz THt0o3JvB4e0EFnuKGe1Ivo0vnBBjCxqo9ZqHH+1Tmx1noJsJdPzkj5WFef1TF40XxeiX/+1UMCu YEPWXhd2Sxw2YifeYpMWYTd2SwY2ZCv2ZEt2Yz//NmQvpmUvNmVf9mYjNmZnNlV0Nmd/dmGTNmjX sGhHNlqv9mCbtmCj9mmrNhfipW3fNm7ntm7vNm/3tm//NnAHt3APd27Xwl9qLXEnt3IvN3M3t3Pj pXG/dms/N3VXt3Vf929Hd2IPMHZ3t3d/93Jrd/jlpHgXti6UN5iB4nnLM42u93ZntXsvdnwztiOi 91/Pt4lpopwKti3k4bPu91/399lx4WoLOH03YYH7N20buGiLY7AyeGY7ON9COGRLeElTeGNbOAa6 thYOeFFxuIUrCoALdoi7z4j/tYaXIIh7eIe7dolH24nz9YuDWYzndYrHSI0v6YyHWY4f6Y5vuIuz /3iPC+mNq+GKH3iLr/aPq3iQI/mQ92iRE3iTAyCOHzmVG/mUpzeTK/l4SzmXOzk6oow7kuKSV/ke TiPbdKOaRwnboMyaT46bs7mcwzlkTE6bo3mUQEbzlTmWf3l+93ks6kIstAIrEHolrEKhS80o8rmX q2ItoAIqmMIpRLopmEIpmAKk18KYRyKjI7jh6WQGekIm/KQqSGepq4IneMIrfEKqs/onbIJ0pnqq q0IneAKqewKr37quf0Kp57qpe8ImjDqGt6eQW7nVATopCrogCEIg8EGzF4ESRHsUQELGLXqxw+Oj T3qmQzoqPDq3Q3qln8Kmg+m1S915vwInqIIt6P8Cu3ctu6+7LrzCu8u7LtiCLbjCvL+Cvat7vNvC LLwCLsA7vQN8v+OCvsf7K6QCq3PCK+QosYP5Lq7N5Og5mo/7Ika5p6diKxQCswdCIPSBEvABH4T8 DihBEewAIFT7JXb6h3viLUT6t8c8t2O6zJOCKVi8zpa7xt0hLfAMqL97z9sCLvT7ur/CwNu7Lvw7 wr/CLOy70eu70euCKuh7KtjCK3iC1av61UP9K6jCJsRBKQgdyye5KtqCNAIO2kNGvQ97J2J8y4+i Lmw8xw8CH/RBFEh7FNy9EuzADpyAEkRCLI79k5MdzXs7uMc8zdO8zFc6ziOyztMbz6d5u0++vtv/ u9WrQr0fvC2kAtc/vcHL++eDftdH/dN3PdYn/NRvgit0/dTbgiegwSb05+N7Ii0Kn+13bdeafeB3 ecZ3Ii6swipYAiGIfLQXQRQQgfFLe7TvQBGcACCwNx8K/iXWguLDPMxXOvZnP/ZbP6WDwim0/ezj 2gLa+y6sO+6v/drbO9Rb/dpX/ubL+9RXvtEPvb6vvi1g/uobvSuoQiqUeip4AkCkSuVpU6pNnWyp OpNJ1y6HDyFGlDiRIq2InzBezAjRIkWPH0GGDEnLlsOGEE821HVLpaqSImHGlPmw40OMNz9FrDmT Z8+HsWC1qhRIyRElR3fwMVGED1IlUZTsMHEC/9BJn1d57tx1U2NOjljBgkSFqhYqU2ZNpR1lalTb tmzXrmWb9mxdU3PC5q3Yle9XvR9pcbJla6eukrpevdJleLDhV7YeQx6cOLFhVY8pS868+VUqV6pU uRoocFOiTp32eFL1KU2mvx61coUom+Zr2zpfelTJcvFiWlpv642N02vt4H9xtYpVqenRokqKRFlK 9KhRpFOrHn89vLhD2g6Ba5dZyy5ct6NChUKfXn36turfylULSjxW7n2Ni6/1uPCu3oMbqywyyCjD zBXGZvFkMFcmu4zAAim7rDPVQDPIk04u3CORV1RJo7vg7ptto/zqA4ukiaxSqTfGcNEllfBKnP+J u+92gTFGkZLDZZXqnDsquhOUIAQq56Da4QQTdqDkRvvw825E8JaMiTyzzmuPvVDwuDLLK9dzay5T QBklyphCtOnJGktU5bfc/HMIQP8Ss8UxAB/EzBZcMKtssjjxBC3OVDhMBTJVAH3Fkwsx9CQRNNDY kJY42LytTCc/tHHMjwj7SCX/VmTsMQUvlbErGi0NNaJYcMGlqR2K2EGHIlp96ik+dtjhiFp3eMpI E5SIxVQym9zqzFIvveUst9jDI0tlmW3WWSy3bM/LOWr5FbZgSa2PMNBQpNOxbxOyLDIIdfGkMwlf cWVcQEOjLBWXDE30NEQT2WMPNDS0ZZMPbZv/VNhKrRVJFxtT5JS3Owm0pROrAt5LRJx0atgjXFAN 5IgiTJgq4xOK6BHjjEGOLiodTABEYsCwHfbkh1AJEz1nnYWDWZnxoBlmZbF0S5QyVibx32CJBeuT NSX6T5UxFNvTlj2QTogyT9DYBLFU4rjXNAohhMyTMzzRxc9OFt1jE0IPOm1RfNG4rJNbtPM3254l oiUXFE3ilNPF5NSMQ357nlFluH/CpRIklMj4VsIvPopwE0boGAlYmVoVSV8B95nGt0++RZRQDrlZ 5s9rhqMOm0G/+UpR3jAFbrf/Ps6WTwybSE7EEjFAlV3iTCiMFTzZRWtVEllhk10UDYOMsV9p/5GW Ai9TBQ0DOtnFz0TCQOPQwT4xuxNGraZl6LZTBrhyh2qJtO42d/uPsQdtYWh8NB/GHO5cYmFFkKNG QLIQVi4pZMjCR1AIXeRiFVEoAhIKQRSpmKAQ74OfmT4kv4aB6Q40s1LNMFizOmSwdMzaILOwFMJD 4KVv4YuYdnKhJvMNbDGfGMMKGpI7VYShC6/AnSowhIYuDEYVnugCGhZzGf/ggiQS6kQYDGCRHh6t C7Twmg1xqIo41AsNaajiKz5xu+OwTnzjc6JuHqKilayPMupSBSfe57cuwi05lXDOkfhAuV3gwg+P G4HJHsKKIgiCFXxAwgKjwLDVmdAvJwPF6P/gAIdQsKENo2ADzeDwyA3WgQ3KemTo2NA5PFBSdGwY BbPoUAa2rYyLJzzOLWzhiVFCZHaf8OEZODUoT4zhDCVxhSfe1YUxwOkTYXCNLRZ1OzwZyhapSEQX wuAQHJ7BAHvwnRX3lIhEWBENZ7Ce98D3MKA5kFgruhuAMFOhV7ivcmo0JdxawQpC9GgEvYIILgqB hD4wLBZKaEUhnFOEEewAFmkkpM+sdYs7HAIObUgkHNRwATjoYYNwuIAbGIqHC6jhDmpQ1ujU0AZo wWENatADlj4nyhJqk6QAfc3AapIS/6RShySxyKA2Uc1U4O5QwXOm1xTSOxyOwZmv8xNB0LD/y3J5 ggtdGBjwqteQTyQiE9ZkFBkSsZpsQnCb47PF3CKiUhXxhjEkidBAXrEvL46qdXBbxVCIdIITVCKr rcBFRFhRiB05Z4GX8GdJKXXOgN2CoAYtqEMT0IY61KENF6iDYTd5gTYkdLAIdegk6/AANughdIkE Q7VI+U8oaWcwHdHqwF7RBVhm4navoAXwgiq1VG6thv7poYeWdgZfulZCA9nDDqUXvDRITzVjCENJ PFG1NJxhD2cgrlS3qNkHAs6zRTNJp/6zp86MxhN8k5g5C2nWQvjxf7x6K0j2J4iOXYeBd6UqXpcb MFTMIZJtcEMb1rCANSRgDXB4AH0X8ICC/zIAD21YQM3WMIHFTmCTAlaDGhAZSTCgYqTndfBmXZeL lzSEJb4jTO1UoQs0uCaspTnDGLqGmFnuwYa6WOoZEmFiaeYCtKoxF2q6kBNP7IELaJBeJ2IaY+Kl IQ174DEaoHqm7Sg3aKYqDGNOYlrfyEl6GdZXYip0qE5okblkXePKdFGI+/VIKSZg60dasYodEc45 GcNjOYm8slq8gQ1uWEN9HzDYibZhAjIrLGENC99NIlgPHO0vRBFah/e6QQ1fYHBm0SvBfsXubr05 bRdWgMpGGSYOY2NaIvIW1Ki28NJw8gQuUNlDF8O4d6hZARpu8QqwBe92YaOmcTNR3anmFf+9RQ6V RTaVkFHSIsS72IQTbZE24p0BMaCR8q/HGr+yYlnLSmhOmXcgR4kIrhV+7JFURgAJ89L6wem1Vi3m 4AY2rAG+Bq1vHerbhjY8Er4FJfd7E2znRBqUkWtgwxcW3GBu79vbJzVxpwij4qRmQkOu6eErbhti H1bId5vYQxhSnJBGSfhQqsHQbTmhi5gmVVGmdqKPf8yoM6QhEdbNSymzO0iULMY/J7LIJkqSiDg4 ZNIJweVppJZsCCpaYrqohCCaQisgFWUEhPDIKuIKnR4dgXEN1Dm/eW4qW8wBDON+M7mvjnWrMxK+ XO86ub2e9TdfwAHU0vfPai0elsDOwnT/cngYVKOhD89NFRsfDNhutwlY0mIPcRiDjRMi2zsVpOKk 1oXMUcyhTHRiBVzQeI+pWUXiknbWaO+2rS+lFZVmeCsmxl7ewuCShOAQbDB/+r+i3jAtKzAp1FlK KyYilAKSma4ZczqaE73sgIkCDAe+wNV///s1CF/sxR978IX/+wlM4AulWOV10yweyaxvUJkYQxcW hkWClMQg1x/M3w1TXDkhfg/O+3AaBhbrwutQxvZKw5QTMQYDdM2KxbXmcBfiCcyLKvdXHmlKbOEW XirVcuITBmMrDAX9FMNQEAXZcG/ndO9kVk8q+IBWfMQE+mDa5GrLxou87Or0LicCf4UW/95gAnxv +FDwAoJv+FQQ+VLwBV3wAlBAAcyAFp6vYVDOpF5jMsgoMTZhBXZrU/SPeKiH2GzBt0QsEZyIiqyn XrqGCDFEmrZmDAIQbOxFbD5hExQDNXzMuF4tETwBs0Ak+tBsU7wJ4HrDJQwQF+BlEzouqkCQOPRq ZYZCEAinKahDCY7kAx+iEsQMKU7gDo1kn77rAaFOBE1FFzQB31qwBTHgAh6xEVkQ+RqxETFg+B7g AhQADDTBfAImByHsOEArTyhD5gaIUFRNCYnHXrqGIBSEUG4HeOrlE1rkIcAGx7YnEfQuEaTHXkxD bE4Cau6FUaqJDEZONcQDFPvtZNhkU//qhqvWBxcIxNguRBfh0BBRDxEDphUCIeiiACpiRZ+UwCpa gRC48Y/GqxtdxQT+QJDOLgT97xPn4AscQAUTqhJVMBLxcR8j8QEWQAG+YA72L0aUcSBnYmAgY5gY EJdS6SCkqRPepTTGxpi00BXNpTSkEDNqyjSkSUPqZWwWRZrqJaqskGlErppgzSWSkQwBB5XqRoyi azIeJMqqUWwSQQxVDgLjsee6sSlgZTqO4kiiwK1WQRDOykdyRVZ2gAhMgA+xER7nMGB0oRbM4Ask YAL2ER8roAW38gK6Uh/9ESDNQBVuEPr6LyptQxoRRiAG4iBqymxE0hrBECNFEiM9Uhf/3S8u6+UK 41JD7uUvjQttUNK4ziAOKG8lzzLlBskMoZH6NAM0RA3HFmUThicOIUYx6bAC0fEEEqhjokCtCIEQ iiAQVoEPYOU5omMpecUd3/FMUu9XbuETqrIAFuAeuVIFH0AfszITw1IsPwEnEa3bXlMvWGJ5eogy V00v9bLv8GUvO7IjG4UJr1Aw8cVq/tJe/s647M+4aIk7eeoTyKnyoBIzV+aq0MdgDMNTZpIaCWIk M8EgbwS7dFBiVMXZDChIRMY5KlAJgK4oTqApCCcKFkhJuIklsewTqK4BECACJiATL8BBHxQ3McBB KTQsEUACApLtntI1tfEvvMZcUqkv/6HTL69wGPGl/rgnRYnR/YixOlt0OwnzwwKTMMeAllKjE+BT JgrSgQTQbtSHTtZT1BRFmkgOjbYtG3fyZNxoVSyQKDyTcDqGY06TrohgBALJgdJrPOdzr1RBE2YT ARRgASL0AXgTNx+UTB8gAv7xQr/ADOZAQzc0gjr0L3gtw8KKikzUqQZzTwfTmpzKT/X0T63ow4yR UM+gUD9sDIyxRhV1DxYvE0xuyBJzSyVGTniDJfIGnCKEQ25OMu3F9I6UOJJUYnJBvJrjPw2oCPrA cf5TrZQgEMYL2/gJS7OUQ0e1YWpBE+ZRAgoAAXw1TBcgWBkgWINVARTAVxGgACQADP/MQBOAs8om NRS1xZWa52x8K1FrlAzCgJbIoEYP1Vv9tFu5tZoUFVBltDu3tVuN51rDoF2NcQ+i8BpLZEexFNfw xjDUclOp8TSsMA3EqkCV7VYbRlU6xgKhYwcEgVf00I9OIA9lFfZolV7H5xa8FAy+wCoL4FiR9QCM FQEOwFcHQAGU9WKZVRPKMicPUWB3MAtVY18UJQ7ioBgJFV0XlZa8tVuBjJZy1hjTYFHF9cPWNUar SEPmpRMyIQ44IUezwkArJxdw7arkhIiYp4fa0mw+NVJPRj6ltXJiYVWdzdlOoA/4AEhYxUlrr3FY gValVUu3dmXYghRE4RDeAAzo9mL/JWABJEACGkBv+Zb56BYM3mAOQGFwRQFghXNOb+N1MgEMIwM0 3HATpkjmigsNYpYMyHVFrQj/AhMljRHIqojkHLXuIPVQsmea4gBHWVM8bRUt4WZgMPVOvArK2NMu o+YTsMpwKWU4T4aOYCUpVwU6AkFAr2ME2kna6pVpJcZY6EIuBncO2KAMwAB68a1u6fYNrFdw44It SqEUCjdOqyrzTutoF/dopwjkIu+pnup8UbKa2JcwW7TH4qDHyBdm0yB+DVNpr0JisZSFEMa0OIQm 23Mvx+ZkoVUnWbd1C8FIWgVXciVVj4RxiOAPClFt9Tdz7AIt5uMu3iAP3mCE7qAM//DgDeBAFMKE LtICLVBhe7037awFIWmhfGB4MGJ4hmXYFmi4Fl7YhnUYh3dYh11Kh1lsBJE3jYDttAil4i6kNDzy e9S2Vi+TUtFpnYqAKTPmYxhnOiC2idd2dckTNlHhFM5iLMYijM1icNFiFFDhDtICFMS4jcWYjE+h gFP2gLVlPzBibE7rtIZmNSAzizCCj/sYNLIIMglZTQrZkE2rj4cmdeujgmmVMLLIOC+k4g6CMlXh WXEXSem4cgRHEIbkVnLlDyphgrXYib/3ZGqhLFSZLFi5lcdClU2BPMiYLGKZlVOZLMiDgIU4WpdR W2hhX6B2wpAMMfJGMYg5wxAjd/8EJZkT0pgfQy2ZmSSGiXQNcEwcWW0h2Y+P04/Ns5SdWHc5+ay0 zJOjoBAqIRYY+Xh5GX9t4xZuoRbeOZXhGZfhOZXj2Z7l+Z312Z3hmZ/dmZ9R1vL4jZ1l5ETcZDBY LD1npzG+xVPuNXcWI08AhJglIyHuxEEuQxo5hBM6AZOTa529GSWej8Ju15u1tpfHJzkKYaVDkxAC QRAC4Q8AARBYoaSb+JoD6p/deRf2Waf/uVr+mafZZqiJmqiFOqDZFqUl5Yt6w0fTE29m56lJQqEb g6EJY6GnGkCcaHnmxKIJA9iyh6BFAqcdSMKuygzvphYGyKStbJN7JhbSiRXkmhX/VuESkO6sKqES 5Mp4I3aIA8ohfJpt+nmnefqoj5qwg3qVdHmXD1dl9aKb3RGtoavRVmqym1p9GiKqJ7oxSAJIa6Sa 59WvrcqjC8aGS/mkxTpGdKFFciFVXPu1XTsWZDud5VigbTu1TwkkFvshdjtrRfuk2EaQRonlzlOr ivu5jluy0UdF7sY/Enol/EOtQxuktTiINeUlabs1n7ht9ze52wR9bFqdG9utQ7q8TZmFzfukwqiw C6aRf7tnspsi4tssDbiL0zu9yfq+zTu/9Tuk+bu/T7ut7RvAA5y6CVy///vA+9rAFXy/BRyKGzyT kxq3I9ya37vCLfOUMVyLUXvD//37wj1cuzU8xMV7jgecxLUbnFGcvk0cwlccB0H8xa0lwWV8xh+c u2vctxk8x5Gai12cxzMvxoE8Sk7aE4f8E5XLyI+csVvcTZZcxNFLyZ88yAM2bqa8YQJQuZT6yksk y3l5y7lc+m4wqcE8zF1nzOUwq7zczG9EwsKbzA2jt9n8L9xcIuB8zee8Pupcy+M8z2Nkz6tcIorz Nwi90A390BE90RV90Rm90R390SE90g0dz8db0FFK0jE90zV90zmd0ym9yXn70jt91Em91E3d0T/d tmkEsEX91F391WE901NdVP0ccMi81gPm1nH9V3R910OF1n1dYno92KNk2In9Rv+M/dhLBNiV3VSS vdm149mhPTikfdptg9mtfUmqPdv1Ytu5PSy8/duxAtvFXTzCvdx74tzRfSbUfd1jgtzd/dp9PN5v o93pHSTs/d49At71Hdznvd/zIt8BXssH/ir4veDT/d8R3icEfuEbHuEPfuFl4uELnuIH3uIBPuIl HiYwvt87Xt8//t41fuNDIuTp3eQdAgAAgCdUns1R/r5b3iNiXtvT3FRU/uYhYua5/OVjQufrw+fV 9txvHudlfuWLXiKAvieGfuh73uibPtoV/jiYXiaSvkSqPuWdHtlrPlRi/uqvnOcnguixfkm8fnzy 3evLPuyzPizSHunXPiTanuH/o/42Zv7tKwft7d7ct/5S6t7o+/7vAf8hlj7nxX7wxV7Y5/7ndT7u 84LxV8beCz/ysV7yJz/wK3/lDz8ifH7qd6Hll97zMd/viX7wOz/z5V5OsVYvkp7zQb/0BT/yAd/p W7/0F5/1KZ/mt5vvZV/03V7zed/1gR/ou/73Hb8+wN73gT/4bV/5Y//1+975dx/nTX9M2p3yh3/s lR/7rz/7ub/31f7yk5/0Xx/7u9/gE/818B78t3/8uX/4pZ/44V/78x7qc39Mnj/8OR//p379SX/7 i1/vAeLTroEDPxkkiDChwoUMGwIAsOshQYkRIVYc+DBjQooTLVL8aBEhSIwe/0M2PIky5S6DAhGy VLlQY0eSNC/aHHkzI06cCjmSlOmTo8+KQEPqHAoz4UuXB5M63WiyY1GRJYWWrMkzJ9arWp96Vcqy 6dexUGd2tUq1J9eda6OSfUtwaVyxcJ1KRHs26tG0W2sSZeu37le5BekmlWkWcN6+Zbuq5ZsVL2PJ ggmvNCw4plvFfnVObgsZ9OLMMMNiJq2Sp+KhQj+7tomarGXLsTXvHR2UK2zcorPWTjn7dEqkq3uL jvj6cWLdsHMzbl43eMvffJGPDsz7efbr1BWant795O3Onv8aRTzefPLwpQ3TZo+3eGjs8rezbyj9 69Hz8cs39w/gcY1J5ZtGrP8FWJVbg7knXG3+qbcbSLlZhZ5eiEH4l1n3zRXWhh5q9uF9+YXY30+U QThegAQaF6J3DIIHn4ItzojaiDR2h9SNsX2n44Y59viWjUBWN2SRHIIFY3g/Gskkfi82mdmSUD7F 45RWFimkkVJeuWGWXH75oZdgjhlelWSeWeaTaK75m5hsvimbmnDOGaRpdH5InIzduXlnnyfx6Sdp ebYIaKAObqYnaWZ69eCDTx245WH76TmoQ4kuCON7hsZWaZdyMnqho3ZZGClMk1KKqHiXelWobSaJ amqoCK4a636WKsdQqSgtOup6kr7KXF2RdgpijZ/+Cqyuav2YHlmn3jpgsZX/HSupr7XOJ+iqxOKa WauNcVbtf9/SGq6q3J6Lqaa9OrZcrsBuZeCEzJLKn2Tl3QZre5k2CC24sWIHsGDDpgrttPsmCap2 CmuYV7zJzgsVhfYWRTG5C3nr7sK+DXggvHfJKyOk9Z5HoIkJOsXroyWOm3G720FcbH2qWezkwW/5 y+7Cu6kn64VEZmiyhvcOrSxTNju7Mrbcyizgzy4zzfBYGEfsstJUl/xafehmzWLAwNkJF85AS/ty 01Hja9zQWEtN7bUaB5uziU+b7TXUjhXt4tE3051vhF2LvTPan6ktd5x6Jxz32C1jazfMK3JNuOIq pYz4xpIT2TjcgWW+tM8o/7cdruWwWj63tfQRzlbkfe8K+rqie84w5zvH/jfc8hqOJNI6rz677KQ7 V3bnRVOeWtdWY167zn5z3RnAeBudu+6Jj6556dwhz3zvD2MafeVm//5u8LNvnjx02uMOvevf216+ 7J1n39r5SRFf/O3K5dhohc81ezbRE094uc8d7l/Xi5vvjBct97GPe+nTT88U9Dr7XYd/p6sYyQr3 kwDOr3WWkuDxMKg4Fd0tXyJL0AVD+DG80W9Tz7PS1KjiwarB8IQinBnsAuc/GvZMg18b4KacBqcX BqqFWALbD9fWJyHSiYhMUiKaeIcmJ8IJilxa4RH9JMUn3nBNWbzimLroxf8vWTGMcwIjGV3IwTMG MY1qZNMY2xhFNsLxTGacYxF9aMc3vTGPYpQjH6voxz+iEY+CJNMeCwmlOiKSUIFcpJEU6UgPHTKS Q4IkJdljyUvuqZGavNEkO0mjTIJyR5wcZYhEacpuGTGVTUIlK+Hiylei70iybOIqawmkWOKSSqXc ZZt66UtSdiiYPdIlMXvYvWPOyJjKrJm6mpkmQkIzmsmcpqekac1fDjMhlRBBCEAAznCKc5zkLKc5 z4nOdKrTnCJYxX0uIYJ1hqCdFwNmNhlIS256c5387Kc//5lOerIHnvIUaDXf081vAnShDG1oOQ3a HYKqc57uzBttjuDQjGr/dKEQDY9E13mEvFVzIAndqElPys6KejSeE+1oYXyIUZTKdKYupc5H1RnS g2ImpjPt6UZr+pubpjOnRrMMJXyK1IwC1aYsXScrdJokniZ1qv5camyEik6i5vOlCTkqVb/KT6vW BqvnfGoDuYoQr4J1recU61Wbqk6zcsgycGWrXcEZAkrMiBIKVacIoNrVuwo2nG5FDVnNKVe0bnUX dR0sWPO6174GFLAIaaxjqQrZFvE1rEiyjGQv+9VB3GgQ/AwBZQliWdAiNbMh2uw6/3rWy8Dos6pN qmhpRFp5nnYgtK2tT287o9xOtLOGQWklcDEQXBRinQMBq1ZbhAuponO3/7vorW9nCtwWCTedpo2t ZYyL3F0ol7m7cK6OostP6oI3uctVZ3O/+twQoZe8cy2uSVuhkFa4t7yYvUSPLmHdcar3pMdlL3nN e6P57nex371vfvf71RD4V0cApq9iL8zfjeI3IfpN53unKuH/BlicxIWRSQsxkPaieBftPeeHkxrf GUnXnAPW8IM9nOGkhpjCIw5njTO6YhWnGMfwHdKMy/ljhwYZnEuebo6RGuMWHZmcJU6ISZHbYhCg GBfgHAghdLELXfChy+UFsxJAoIQwo1QEG+5RLFJLYu/aV6NNbrKLn+zTKIdoygKWs4k3imVxbpnM Xw7zmEHQXDOjWc0nZf/zkN68YAw3WKOBDuegEb2LQouZzCBQdJp1seY26wjSOK7vnzX6Yk5jGiFc xjQI8LtcFHfYpHqWcqRlW80rs1jQ4iU0mDftak8z2qSOBhKpnczgOWc01a5eNUFa3VxYa3kXs95o rfd86yyZlNnvVQi0yyttWaP02h/is4+LqmyHcpu/A9EvIbpdXhTHAgSx2LVJQ1DvIsWix0lu6LrJ zGpOh5va4zaSuQEu6XT7G8/wdje8pz3vemc5o/g20r5LnfBTL5vh7Cb4uzsOcXrbe6MV1ze/0a1x dXNc1c1ubprLy2yHkvtDujh4vxn6b0w7HOTyFvnEHVryR5882SlfOJX/Qa5qlzc35g2duYdqjnFc x3bbK292y8v7cqtbm0lQR/ZLJ51R5FZCnJXotdUfDgIsm92k2R3SdpHsZytvNOcffnjWmc5Qp2+o 63cmutwpvYuxh7Ps3z63qtXearY36e1H9ztCdC14cBKe5WhHPErbDiTG99nUfwcySZk85LMj/alg ZsVJg25yr0t9sZAnu9nrjnTLnxTzPdJ8nB1PkBN/ftr2hr2qSb8L09873xYf8c0XumLBN9n3zQa+ 8ElO/NT3/esKb6io2234pPP345luNEo2IYDwh58MCBk/Qc4Qfi6EPw0ESUP4CaB+PcHZ2avHsO4D D/reZxjtzj999IWu/3ra5mAcln1XB07cRwjedxLgJ34CQH4EYX4DgX4CoH4CwH4D4X4CAH8CIH8B eCwndX0ER3lIh4AK2BAMKH4POBARuAsTWIEXuAsZuIEdOH2yBXZ0Fl7jVYBot2oFdxJcMCm0EIMP QQADcQsZAYQAIAAFkRFpsEXmdnwLFYKzxnzvVYLE9n0N6IDlt4USmH7r137vF38NMX9RiHw5mGVV uH94t1DXloRHIYROCABFuAtH+BBJuIQr0YRP6IEDhFKFgIZxln2wh2cyhxJvqBNxSIRGiIQPkYef sIdLAoUo13mqhVyJt1F/gBIcOIecOIe7QAAPAYMOYwu7wIkEoAuO2P8Qf9CHuXZSgGhgO4h0PXhS bhiEQ/iJddiISsiEosiHNSiAvnWJKKWJJ3GKnliEoQgAo5hCpXiKqciLDMGKwPiB1zWMJ1WMDXGM GZGMoigVROGMRAiNebgQ00hjlPh41jhyG1V2DTGOA0EGjqgLnNh+qpgRtBCPEpGPMKgQagV3uMeG d3WNJpWNDLGNi6iMzAgRGRGOc/iO0tiKU6eOP+dQ7cgQD5mPAjCPHCGHS3iP+QgR+9gQ/th4GVeJ oFVpJmWRC4GR8kiPGGiPD4GPGiGSDEGSm0d9RedY2IdSsIASqmiKD8EJREEQCQmKd3iPR5kosBCR rDeRxnUSLamEGxn/Eh1JFDOpj95ok01pf77Fkyflk6qSh5w4lIhhlMr4hkKojCfBlNToh14pgmD5 k9FIlkQ5EGeJlDKplGzZhzd4XScVXgwhh3PIjboYjbfwkrRwFA/4kgyBiSVZf5F5XV9pUmFpKWMp lHaplOyHlkm5lg3RlucIkIX4l4DXEIOpjJ9oh3mImBShmDrBmFLymDgZmX5ZmqYpmNxYmKtphIm5 mCsom31Zfbepctq4H3mYj1zwjSainCTRnA3BlZJJnIB5Eqi5m0DZmhbxmhkRm4kym7dnkuk4nXNn jMcJj3e4nH/xnOh5EtFpm+O5UJtonruQnOmpE+sJAM/JEMKpk/AJ/1BRyYnhV5h1SRLkGABASRJD 2Z5u6Yr+WZwGOZ/1mUHM2RH6uRDuOZwO2k8A6ojIGJQAoKAVYaAIWhEhup8MKpEainPuGKAeSqAi ShAHGo0JihL8eZIq2k+BqRnk6DAEIaEfmga30BGl2BDfeW6jiaMrepEtOqCZWaAxSqJOCp0o6pRJ +k86qhY8mkI+yp5AKqQkQaSOiaH9aaXohKVQoaULyRE/yolBOqQnYaQIZ4MZqk5VoKH/hxCvSYec EJMh8aI+cwtgdhLzRqVdWaY5KpbfiBhsKopfWhFhuhBxSn/BCFB26qB4ShB6OhB8youI8adDEago QaiiGZ65x1CW6v+fmDoQmroLnOqRHPGpURGqg2qj4ulPMEAFVUAFMEBOuRpOuKqrOPCruUoFwkpO wEoFJBBOVcCszcpPesUQIrmdqJgRQroJO0QQQMiPC3GT4FmbdJpOqAqfqroLrOqqmhmrCTGrDTGq /1iqAWlOyMqr4CSvw6qrynqsxIqvINCsztpQ0LoQ0sqN0AgA1oqtA6GtKNGtR/qupJlO9QpOJIAD zGqsIICs+ypOF7us/SquAAWwCiGw4litu3CtAJSty6iwtWqq/jSx/Tqv4NSyMMuxwgoDMztONdus yQoCJMCxHXtOtAeck2IySEgQvJmeDGF7ckqp/QSxFquv9qqz+Xr/rxvbrw71sQkRsg45siWbLAiR sCexsEpbjSzLsbxKArnarMqKs8watb/arzrLsxzrUED7obZiHkTLiDOqmUg7pjeaTi3brGaLthRr sW+LsYWbs8oat1XbUHTriWizH89ptBPaEEk7qbcEULlaszVLBRE7uDJrtswKAhPLq5w7TppbuDRb BRXbT3o2KeQ4mNzptV0KoycxiUj6T4DLrKVruIjLtoe7tlO7uP7KUI77LHfbpZO7twthuWZoTppb Baabq2qrqyCAujXLutYbvanLvVvnLkcBu/uhgruQhPpJogtxuw2budHLvp2LvTu7utrLu9l7vfH7 vt7rKhkRvr95/7L5SRXkyBDpO6dkek6i27G7K7o3W70Tu7HjlMD82rkTS6wv61cwkQuOihBkML4o gY8pUYZxZ6v8BL3Su73vW7/0W8L2G7/4uyw6sb+wObv+2xEAjL59G8LrZMDihLo827kPXL3i5MMR rKu6SsEcZcEY7KMbfBIdjBIfjLv+lMPh5KsOjKo/3MDgtMBDvKtKdcQBq8QNwcQn4cQ56bfoJMHb K8XK+sAy27b0usJSnMJ2Ori7W1rkSiMXV6jSCcV2Kq5BzK9V3LlADMijq8VFDFCwlRIX7MVJEcZk aMMr209n/LJnm7jyi7inG8fa67JAZ8czgsek+q0EbE6SvKzFGv+s4FS/HZvKmhy4nNwkn+yuA1zG ZlzJgkzFWxxOlHy4uiu6pFu4gbxOtPe4p0LMxezCEPnI8EpOpIzKmbzKOuzMZevKTALLkLm0/AS4 cDu4OsvLHdvNhMy7wFy8CzHMxmzOr4vMefyef1vJPSus3yxO3+zLpju35HzO93wqNEwQ5gjKvNJQ q2vFWOyz9LyzqLvMuYoDU2zL/KR3G2JzIAzJkVzJ8tyz40TR4ZxRwozPG33M5Rh119xPAC3EGD26 CK3Q4ZTQq3vSAp1RDX0fD/3ElSrBf0zSKZ3SB63SPrvGbdgkME3GN6xOvsrHB2ypCX3FlGzI5JTF VyxPEzYkFZb/zA5bpzNd0jkNsybtsza90n/c0j390WPbT0LN1T6s0+Ks1ELM1Ay1Y089dOr7T2It ugq90xCMTkvN0kDn1EAC1W65zudEulXAw1Qss6obyAa9zNs7se+swtk7VAaXbWAtwnzM1Q5s1nRd wGh91w211nrd1qE8y6PMvoFdvyNNyNnry4ld2t1riEVycJf7lmRbs4E9z1nMq6gdz4gdv6h9v6tt ZI+9Tco8TsOLxkctzfDcy70r3IcbUJ28IbGg3NYM2ev017KN24pd228Muqmt29idd4791a/dT8LN u5usu1F73JWc3BolAsx9H87t2w0a3tJMya1c3vh63r8Lv/36/9z/tN6Ptt/e6s8A1bRMDbFznMAJ 3LI4sK8DztC9/d4pGt/k3bv1zdIUnt5Kxd7s4d7fDd9MO8FQ+7IJvq8ITrEL/uEsfCOt7dodzk9N S8m4TMirO+JFXeIgTmsO/t2edapJutkzstdRvVBNK+IoXeN3PeT0euIa5dK/oeLU1WMFzON57eNP vuKxReXl5LPw2eMt8uN8bRjzd6jndASCSiMqjsgNe+VKHeUiZmGeXVlhDlBjriNmTl1gDufkJOcp /lolhsFhe+fmJAg3ws/opFIZh8F2/ufhlOdlvud+1ueJ3k+BTiODfk6FHsqPDunrJOkzQunmZOks QQsGQeYDof/ikM5aH+JajY0QuWAZof4Jo+7nmR5Om94inV5Oha4Ln8AJqpAQrj7qu1DqiX7qHpLq WZUQrG4Yvp4Qwf7nw74hxS7mxw7qBiGECQFPaQ7nIiDl7EEJYE5RCuHq1Z6p1L7sss5dV/vsVP5c 4d7r5G7t+2TuD7Xt4dHt3OVS7J6n7o4Q1x7v8t5a3n7vLJHrBoHE91QbAp8QA/8JSMzv/T5O2v7v 9m7psgWpYcYSBW/wxvLqCX/xGb9JnyCE+O7xseHqCCPyI08arl4KC3HyKC8YJc/y+u7yL78UyP4J qoDxM+8UuVDyvz4QNs/rOg8XqoDwCgH0OS/0KsHzRS/tBoHV80k/Fksv6oJqC5wA6rqA9FCPEIFa 8iDfEFV/9Vmv9UaoC10v7goB9tSO9WOPElwfFmefEGkP8mvP9g3h9qAe91b/HXvP933v938P+IEv +INP+IVf+BWP9npv+IvP+I3v+I8P+XuP+Hkf+ZVv+ZeP+Y0/+Qgh95nv+Z8P+pa/+aFP+qVv+oD/ 9JNz+qvP+qWf+j3U+rEv+5H/+qwz+7eP+4Vf+yzZ9bnv+7+vCrRQC09R9r9v/MAv/MTf+8fP/Kwf /MOfFMXf/NPv/Mlf99eP/dkv9AEBADs=== ------=_NextPart_000_0F87_01C66599.01F0AE70-- . ------------=_4449C944.704E0000-- From plowshear@wanttobefit.com Sat Apr 22 14:21:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FXMjL-0008JQ-RU for ccamp-archive@ietf.org; Sat, 22 Apr 2006 14:21:15 -0400 Received: from [59.61.79.114] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FXMjL-0006VP-3g for ccamp-archive@ietf.org; Sat, 22 Apr 2006 14:21:15 -0400 Message-ID: <000001c66664$2202a800$0100007f@localhost> From: "Gustavo Coleman" To: Subject: Corel Draw Date: Sun, 23 Apr 2006 02:18:43 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C66664.2202A800" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.2 (++) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C66664.2202A800 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Special Offer Adobe Video Collection Adobe Premiere 1.5 Professional Adobe After Effects 6.5 Professional Adobe Audition 1.5 Adobe Encore DVD 1.5 $149.95 More Info >> Microsoft 2 in 1 MS Windows XP Pro MS Office 2003 Pro $99.95 More Info >> Microsoft + Adobe 3 in 1 MS Windows XP Pro MS Office 2003 Pro Adobe Acrobat 7.0 Professional $149.95 More Info >> Bestsellers Microsoft Office Professional Edition 2003 Rating: 6 reviews Retail price: $550.00 You save: $480.05 (87%) Our price: $69.95 [Add to cart] Microsoft Windows XP Professional Rating: 8 reviews Retail price: $200.00 You save: $150.05 (75%) Our price: $49.95 [Add to cart] Adobe Photoshop CS2 V 9.0 Rating: 3 reviews Retail price: $599.00 You save: $529.05 (88%) Our price: $69.95 [Add to cart] ------=_NextPart_000_0001_01C66664.2202A800 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DS
Special Offer
Adobe Video Collection
  • Adobe Premiere 1.5 Professional
  • Adobe After Effects 6.5 Professional
  • Adobe Audition 1.5
  • Adobe Encore DVD 1.5
$149.95    
More Info >>
Microsoft 2 in 1
  • MS Windows XP Pro
  • MS Office 2003 Pro




$99.95    
More Info >>
Microsoft + Adobe 3 in 1
  • MS Windows XP Pro
  • MS Office 2003 Pro
  • Adobe Acrobat 7.0 Professional


$149.95    
More Info >>
Bestsellers
3D"" Microsoft Office Professional Edition 2003
Rating: 6 reviews
Retail price: $550.00
You save: $480.05 (87%)
Our price: $69.95		  

Add to cart

3D"" Microsoft Windows XP Professional
Rating: 8 reviews
Retail price: $200.00
You save: $150.05 (75%)
Our price: $49.95		  

Add to cart

3D"" Adobe Photoshop CS2 V 9.0
Rating: 3 reviews
Retail price: $599.00
You save: $529.05 (88%)
Our price: $69.95		  

Add to cart

------=_NextPart_000_0001_01C66664.2202A800-- From owner-ccamp@ops.ietf.org Mon Apr 24 10:46:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY2KX-0003FY-Hj for ccamp-archive@ietf.org; Mon, 24 Apr 2006 10:46:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY2KX-00088E-7j for ccamp-archive@ietf.org; Mon, 24 Apr 2006 10:46:25 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FY2B8-0009iw-Mr for ccamp-data@psg.com; Mon, 24 Apr 2006 14:36:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.1.1 Received: from [64.233.166.183] (helo=pproxy.gmail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FY2B8-0009id-1U for ccamp@ops.ietf.org; Mon, 24 Apr 2006 14:36:42 +0000 Received: by pproxy.gmail.com with SMTP id c59so1313957pyc for ; Mon, 24 Apr 2006 07:36:41 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=OHn99AIwXYjns7oalXBAwLADWQrMg7WzyqtsxLLMfU0/5pYvuPWy6hZiTX9aM3ych3IUcdOKWv5CmN3wBXEXkwSAp5d7//ePOqvF1E3Y8byDS+24lfdoCpfReKhyun+wY5Mpsg4mfXk0F5PSdnqZpg5myP3dc3K+vm+xt5dDUhE= Received: by 10.35.107.20 with SMTP id j20mr2628141pym; Mon, 24 Apr 2006 07:36:41 -0700 (PDT) Received: by 10.35.26.7 with HTTP; Mon, 24 Apr 2006 07:36:41 -0700 (PDT) Message-ID: Date: Mon, 24 Apr 2006 19:36:41 +0500 From: "Fahad Dogar" To: ccamp@ops.ietf.org Subject: GMPLS support for Ethernet switching MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Hi all, I have few questions related to the draft on GMPLS support for Ethernet switching by D.Papadimitriou et al.: i) The draft discusses that connection oriented ethernet is suitable for metro and core networks where ethernet is used for transport. I am not too clear on the architecture in which ethernet LSPs would be used. Are we considering point to point type ethernet connections between switches/routers i.e. where the bandwidth is not shared. Example: Two peer routers connected through an ethernet interface, so effectively complete bandwidth is available. Or are we talking about multiple switches in a GMPLS enabled cloud that are part of the SAME LAN and bandwidth is shared. I am not sure how bandwidth reservations would be done in this sceneario. ii) Please correct me if I am wrong but it seems that the traffic engineering benefits of GMPLS support for Ethernet are also available in Ethernet over MPLS. (I am considering that connection oriented Ethernet is used in metro/core networks only). However, by providing GMPLS support for Ethernet we are able to do away with IP/MPLS layer and thus we can have an all Ethernet network (with only ethernet switches). Is this the primary reason for using GMPLS support for Ethernet rather than Ethernet over MPLS? Can someone comment on this? iii) The draft discusses various options for ethernet label, all of which seem to require modification in the forwarding plane of Ethernet? Is this something that can implemented easily i.e. change in forwarding plane? Why can't we consider MAC address or VLAN tag as the label? Thanks in advance, Fahad From owner-ccamp@ops.ietf.org Mon Apr 24 14:17:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY5cY-0002nZ-82 for ccamp-archive@ietf.org; Mon, 24 Apr 2006 14:17:14 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY5cW-0000q4-TQ for ccamp-archive@ietf.org; Mon, 24 Apr 2006 14:17:14 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FY5SE-000MPu-CU for ccamp-data@psg.com; Mon, 24 Apr 2006 18:06:34 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_MESSAGE,MIME_BASE64_NO_NAME,SPF_PASS autolearn=no version=3.1.1 Received: from [171.71.176.78] (helo=test-iport-3.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FY5SB-000MPG-6f for ccamp@ops.ietf.org; Mon, 24 Apr 2006 18:06:32 +0000 Received: from sj-core-2.cisco.com ([171.71.177.254]) by test-iport-3.cisco.com with ESMTP; 24 Apr 2006 11:06:31 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3OI6RhE005986; Mon, 24 Apr 2006 11:06:30 -0700 (PDT) Received: from xmb-rtp-20d.amer.cisco.com ([64.102.31.51]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 24 Apr 2006 14:06:25 -0400 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_01C667C9.BF3F36CD" Subject: RE: [Pce] Comparison of Encryption vs. Path Key Solutions for the CPSID. Date: Mon, 24 Apr 2006 14:06:01 -0400 Message-ID: <3C292CE901FC634693F24FB2DDC4D33201601C11@xmb-rtp-20d.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Comparison of Encryption vs. Path Key Solutions for the CPSID. Thread-Index: AcZZeTyqrqoHE6qtR3mCIGZZDDyHhAL5DdwgAJosi6A= From: "Rich Bradford \(rbradfor\)" To: "LE ROUX Jean-Louis RD-CORE-LAN" , "Jean Philippe Vasseur \(jvasseur\)" Cc: , X-OriginalArrivalTime: 24 Apr 2006 18:06:25.0669 (UTC) FILETIME=[CD46BB50:01C667C9] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 9d7e8d783239e9f0c425c823a9c950ff This is a multi-part message in MIME format. ------_=_NextPart_001_01C667C9.BF3F36CD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SkwsDQoNClRoYW5rcyBmb3IgdGhlIHJlcGx5LiBJdOKAmXMgYWx3YXlzIGRpZmZpY3VsdCB0byBj aG9vc2UgYmV0d2VlbiBtdWx0aXBsZSBzb2x1dGlvbnMgd2hlbiB0aGVyZSBhcmUgc28gbWFueSB0 cmFkZW9mZnMgYmV0d2VlbiB0aGUgc29sdXRpb25zLiAgDQoNCiANCg0KUmVnYXJkaW5nIHRoZSBv cHRpbWl6YXRpb24gd2hlcmUgdGhlIFBDRSBzZW5kcyB0aGUgTFNSIHRoZSB1bnNvbGljaXRlZCBj b21wdXRlZCBwYXRoIHNlZ21lbnQuICBJdCB3YXMgYSBkaWZmaWN1bHQgY2hvaWNlIHdoZXRoZXIg b3Igbm90IHRvIGluY2x1ZGUgYSBkZXNjcmlwdGlvbiBvZiB0aGlzIGluIHRoZSBvcmlnaW5hbCBk cmFmdCwgc2luY2UgaXQgaXMgbW9yZSBjb21wbGV4LiBXaGljaCBhc3BlY3Qgb2YgdGhlIG9wdGlt aXphdGlvbiBzZWVtZWQgbW9zdCBpbXBvcnRhbnQ/IFdhcyBpdCB0aGF0IGl04oCZcyBtb3JlIGVm ZmljaWVudCBkdXJpbmcgTFNQIHNldHVwIG9yIGJlY2F1c2UgaXQgY291bGQgYmUgdXNlZCB0byBz aGlmdCB0aGUgYnVyZGVuIG9mIG1haW50YWluaW5nIHN0YXRlIGZyb20gdGhlIFBDRSB0byB0aGUg TFNSPw0KDQpUaGFua3Mgb25jZSBhZ2FpbiBmb3IgeW91ciBvcGluaW9uLiANCg0KQmVzdCBSZWdh cmRzLA0KDQogIFJpY2gNCg0KIA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K DQpGcm9tOiBMRSBST1VYIEplYW4tTG91aXMgUkQtQ09SRS1MQU4gW21haWx0bzpqZWFubG91aXMu bGVyb3V4QGZyYW5jZXRlbGVjb20uY29tXSANClNlbnQ6IEZyaWRheSwgQXByaWwgMjEsIDIwMDYg MTI6NTEgUE0NClRvOiBKZWFuIFBoaWxpcHBlIFZhc3NldXIgKGp2YXNzZXVyKTsgUmljaCBCcmFk Zm9yZCAocmJyYWRmb3IpDQpDYzogY2NhbXBAb3BzLmlldGYub3JnOyBwY2VAaWV0Zi5vcmcNClN1 YmplY3Q6IFJFOiBbUGNlXSBDb21wYXJpc29uIG9mIEVuY3J5cHRpb24gdnMuIFBhdGggS2V5IFNv bHV0aW9ucyBmb3IgdGhlIENQU0lELg0KDQogDQoNCkhpIEpQLCBSaWNoYXJkDQoNCiANCg0KUGxl YXNlIHNlZSBpbmxpbmUsDQoNCgkgDQoNCgkNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQoNCg0KCURlIDogSlAgVmFzc2V1ciBbbWFpbHRvOmp2YXNzZXVyQGNpc2NvLmNvbV0gDQoJ RW52b3nDqSA6IGpldWRpIDYgYXZyaWwgMjAwNiAxNDo1Mg0KCcOAIDogUmljaCBCcmFkZm9yZA0K CUNjIDogY2NhbXBAb3BzLmlldGYub3JnOyBwY2VAaWV0Zi5vcmcNCglPYmpldCA6IFJlOiBbUGNl XSBDb21wYXJpc29uIG9mIEVuY3J5cHRpb24gdnMuIFBhdGggS2V5IFNvbHV0aW9ucyBmb3IgdGhl IENQU0lELg0KDQoJSGksIA0KDQoJIA0KDQoJVGhhbmtzIGZvciB0aGUgc3VtbWFyeSBSaWNoLg0K DQoJIA0KDQoJUENFIFdHIG1lbWJlcnM6IHRoYW5rcyB0byBwcm92aWRlIHlvdXIgZmVlZGJhY2sg b24gd2hldGhlcjoNCg0KCSgxKSBZb3UgdGhpbmsgdGhhdCB0aGVyZSBpcyBhIG5lZWQgZm9yIHN1 Y2ggc29sdXRpb24sIA0KDQoJIA0KDQoJWWVzIGRlZmluaXRlbHksIGNvbmZpZGVudGlhbGl0eSBp cyBhIGtleSByZXF1aXJlbWVudHMgaW4gYW4gaW50ZXItcHJvdmlkZXIgY29udGV4dC4NCg0KCSAN Cg0KCSgyKSBZb3Ugd291bGQgcHJlZmVyIG9uZSBzb2x1dGlvbiAod2hpY2ggb25lIGFuZCB3aHkg PykgDQoNCgkgDQoNCgkoMykgWW91IHRoaW5rIHRoYXQgdGhlcmUgaXMgYSBuZWVkIGZvciBib3Ro IA0KDQoJIA0KDQoJQW5zd2VyIHRvICgyKSBhbmQgKDMpOg0KDQoJSXQgc2VlbXMgdG8gbWUgdGhh dCB3ZSBzaG91bGQgZW5kLXVwIHdpdGggYSBzaW5nbGUgc29sdXRpb24gc28gYXMgdG8gZWFzZSBp bnRlcndvcmtpbmcuDQoNCglJTU8gaW4gYW4gaW50ZXItQVMgTVBMUy1URSBlbnZpcm9ubWVudCB3 aXRob3V0IFBDRXMsIHRoZSBwYXRocyB3aWxsIGJlIGxvb3NlIGFueXdheSwgc28gdGhlcmUgd2ls bCBub3QgYmUgYW55IGNvbmZpZGVudGlhbGl0eSBpc3N1ZS4gDQoNCglJZiBoYXZlIHNvbWUgY29u Y2VybnMgcmVnYXJkaW5nIHRoZSBjb3N0IG9mIGVuY3J5cHRpb24sIHBhcnRpY3VsYXJseSBmb3Ig bGFyZ2UgcGF0aHMgKHdlIG5lZWQgdG8gdGhpbmsgYWJvdXQgZnV0dXJlIFAyTVAgYXBwbGljYXRp b25zIHdpdGggYSBsYXJnZSBudW1iZXIgb2YgaG9wcy4uLikuIEJ5IHRoZSB3YXksIGVuY3J5cHRp b24gYXBwcm9hY2hlcyBhcmUgcmVhbGx5IHZ1bG5lcmFibGUgdG8gRG9TIGF0dGFja3MuDQoNCglI ZW5jZSBJIHdvdWxkIHN0cm9uZ2x5IGZhdm9yIHRoZSBQS1Mgc29sdXRpb24uIFRoZSBvcHRpbWl6 YXRpb24gc3VnZ2VzdGVkLCB3aGljaCBjb25zaXN0cyBvZiBzZW5kaW5nIHRoZSBjb21wdXRlZCBw YXRoIHNlZ21lbnQgdG8gdGhlIExTUiBpbiBhbiB1bnNvbGljaXRlZCBtYW5uZXIsIGp1c3QgYWZ0 ZXIgdGhlIGNvbXB1dGF0aW9uLCBzb3VuZHMgcmVsZXZhbnQgYW5kIHNob3VsZCBiZSBmdXJ0aGVy IGludmVzdGlnYXRlZC4NCg0KCSANCg0KCUJlc3QgUmVnYXJkcywNCg0KCSANCg0KCUpMDQoNCgkg DQoNCgkgDQoNCgkgDQoNCgkgDQoNCglUaGFua3MuDQoNCgkgDQoNCglKUC4NCg0KCSANCg0KCU9u IEFwciA1LCAyMDA2LCBhdCA2OjE5IFBNLCBSaWNoIEJyYWRmb3JkICgocmJyYWRmb3IpKSB3cm90 ZToNCg0KCQ0KCQ0KCQ0KDQoJSGksDQoNCglBcyBzdWdnZXN0ZWQgaW4gRGFsbGFzLCBJ4oCZdmUg ZGVzY3JpYmVkIHNvbWUgb2YgdGhlIHRyYWRlb2ZmcyBiZXR3ZWVuIHRoZSB0d28gc29sdXRpb25z IGRlc2NyaWJlZCBpbiBkcmFmdC1yYnJhZGZvci1jY2FtcC1jb25maWRlbnRpYWwtc2VnbWVudC0w MC50eHQuDQoNCgktLSBSaWNoDQoNCglUaGUgQ29uZmlkZW50aWFsIFBhdGggU2VnbWVudCAoQ1BT KSBJRCBwcm92aWRlcyB0d28gdmVyeSBkaWZmZXJlbnQgYnV0IGVxdWFsbHkgdmFsaWQgc29sdXRp b25zLCB0aGUgUGF0aCBLZXkgU3Vib2JqZWN0IChQS1MpIHNvbHV0aW9uIGFuZCB0aGUgUHJpdmF0 ZSBSb3V0ZSBTdWJvYmplY3QgKFBSUykgc29sdXRpb24uIFRoaXMgbm90ZSBleGFtaW5lcyBhIG51 bWJlciBvZiB0aGUgYWR2YW50YWdlcyBhbmQgZGlzYWR2YW50YWdlcyBvZiBlYWNoIHNvbHV0aW9u LiANCg0KCUluIHNob3J0OiBUaGUgUEtTIHNvbHV0aW9uIGFsbG93cyBhIFBDRSB0byBoaWRlIHRo ZSBDUFMgZm9yIGFuIEFTIGJ5IHNhdmluZyBpdCBpbiBhIGRhdGFiYXNlIGFuZCByZXBsYWNpbmcg aXQgd2l0aCBhIGtleSBpbiB0aGUgRVJPLiBEdXJpbmcgdGhlIExTUCBzZXR1cCwgdGhlIGluZ3Jl c3MgTFNSIGZvciB0aGF0IEFTIG11c3QgcXVlcnkgdGhlIFBDRSBmb3IgYW4gZXhwYW5zaW9uLg0K DQoJVGhlIFBSUyBzb2x1dGlvbiBhbGxvd3MgYSBDUFMgZm9yIGFuIEFTIHRvIGJlIGhpZGRlbiBi eSBlbmNyeXB0aW5nIGl0LCB3aGljaCBtYXkgYmUgZG9uZSBieSBhIFBDRSBvciBieSB0aGUgSGVh ZC1FbmQgTFNSLiBEdXJpbmcgdGhlIExTUCBzZXR1cCwgdGhlIGluZ3Jlc3MgTFNSIGZvciB0aGF0 IEFTIG11c3QgdXNlIGEgZGVjcnlwdGlvbiBrZXkgdG8gb2J0YWluIHRoZSBleHBhbnNpb24gKGlt cGx5aW5nIGFuIGVhcmxpZXIgZXhjaGFuZ2Ugb3IgY29uZmlndXJhdGlvbikuIA0KDQoJVGhlIG1h am9yIGRpZmZlcmVuY2VzIGJldHdlZW4gdGhlIG1lY2hhbmlzbXMgaW52b2x2ZSAoMSkgYWRkaXRp b25hbCBjb250cm9sIG1lc3NhZ2VzLCAoMikgcGVyZm9ybWFuY2UgaXNzdWVzIGV4cGFuZGluZyB0 aG9zZSBvYmplY3RzLCAoMykgdGhlIGFkZGl0aW9uIG9mIHN0YXRlIHRvIHRoZSBQQ0UsICg0KSB0 aGUgc29sdXRpb24gc2NvcGUgKGkuZS4gYXBwbGljYWJpbGl0eSB0byB2YXJpb3VzIHRvcG9sb2dp ZXMgb2YgZWFjaCBzb2x1dGlvbi4pLCBhbmQgKDUpIHRoZSBzaXplIG9mIG9iamVjdHMgYWRkZWQg dG8gZXhpc3RpbmcgbWVzc2FnZXMuDQoNCgkoMSkgQWRkaXRpb25hbCBDb250cm9sIE1lc3NhZ2Ug T3ZlcmhlYWQ6DQoNCglUaGUgUEtTIHNvbHV0aW9uIHJlcXVpcmVzIGEgbWVjaGFuaXNtIHRvIGV4 cGFuZCB0aGUgUGF0aCBLZXkgdXBvbiByZWNlaXB0IG9mIHRoZSBMU1Agc2V0dXAgcmVxdWVzdC4g U2luY2UgdGhlIFBDRSB3aGljaCBjYWxjdWxhdGVkIHRoZSBQYXRoIEtleSBtaWdodCBub3QgcmVz aWRlIGluIHRoZSBlbnRyeSBib3VuZGFyeSBMU1IsIHRoZSBMU1IgbXVzdCByZXF1ZXN0IHRoZSBl eHBhbnNpb24gZnJvbSB0aGUgUENFLCByZXF1aXJpbmcgYW4gYWRkaXRpb25hbCBtZXNzYWdlIGV4 Y2hhbmdlIGJlZm9yZSBMU1Agc2V0dXAgY2FuIHByb2NlZWQuIFRoZSBQYXRoIEVuY3J5cHRpb24g c29sdXRpb24gZG9lcyBub3QgcmVxdWlyZSB0aGlzIGV4dHJhIGV4Y2hhbmdlIGJldHdlZW4gdGhl IFBDRSBhbmQgdGhlIGluZ3Jlc3Mgbm9kZSBmb3IgZXZlcnkgTFNQLiBSYXRoZXIsIHRoZSBkZWNy eXB0aW9uIGtleSBuZWVkcyB0byBiZSBleGNoYW5nZWQgb25seSB3aGVuIGl0IGlzIGNoYW5nZWQu IFRoZSByZXN1bHQgaXMgYWRkaXRpb25hbCBkZWxheSBkdXJpbmcgZXZlcnkgTFNQIHNldHVwIGZv ciB0aGUgUEtTIHNvbHV0aW9uIGJ1dCBubyBhZGRpdGlvbmFsIGRlbGF5IGZvciB0aGUgUFJTIHNv bHV0aW9uLg0KDQoJKDIpIFBDRSBhbmQgTFNSIFBlcmZvcm1hbmNlOg0KDQoJVGhlIFBLUyBzb2x1 dGlvbiBtdXN0IG1haW50YWluIGEgKHRlbXBvcmFyeSkgZGF0YWJhc2Ugb2Yga2V5cyBhZGRpbmcg b3ZlcmhlYWQgdG8gdGhlIFBDRS4gVGhlIFBSUyBzb2x1dGlvbiByZXF1aXJlcyB0aGUgZW5jcnlw dGlvbiBvZiB0aGUgQ1BTIGluIHRoZSBQQ0UgYW5kIGRlY3J5cHRpb24gb2YgdGhlIENQUyBpbiB0 aGUgTFNSLCB3aGljaCBjb3VsZCBiZSBDUFUgaW50ZW5zaXZlLiBOb3RlIHRoYXQgaW4gY2FzZSBv ZiBhIGJ1cnN0IG9mIHJlcXVlc3RzLCBlbmNyeXB0aW9uIG9mIGxhcmdlIG51bWJlciBvZiBDUFMg bWF5IGhhdmUgYW4gaW1wYWN0IG9uIHRoZSBQQ0UgcmVzcG9uc2UgdGltZS4NCg0KCSgzKSBBZGRp dGlvbiBvZiBTdGF0ZSBpbiB0aGUgUENFOg0KDQoJVGhlIFBLUyBzb2x1dGlvbiByZXF1aXJlcyB0 aGUgYWRkaXRpb24gb2YgcGF0aC1zcGVjaWZpYyBzdGF0ZSBhbmQgbWFpbnRlbmFuY2Ugb2YgYSBk YXRhYmFzZSBpbiB0aGUgUENFLiBUaGUgUFJTIHNvbHV0aW9uIHJlcXVpcmVzIG5vIGFkZGl0aW9u YWwgc3RhdGUuDQoNCgkoNCkgU29sdXRpb24gU2NvcGU6DQoNCglUaGUgUEtTIGFuZCBQUlMgc29s dXRpb25zIGJvdGggd29yayB3ZWxsIGluIGNvbmp1bmN0aW9uIHdpdGggYSBQQ0UgdG8gZW5jb2Rl IGFuZCBkZWNvZGUgdGhlIENQUy4gSG93ZXZlciB0aGUgUEtTIHByb3ZpZGVzIG5vIGRpcmVjdCBz b2x1dGlvbiB3aXRob3V0IGEgUENFLiBUaGlzIHByZXZlbnRzIHRoZSBQS1Mgc29sdXRpb24gZm9y IHdvcmtpbmcgaW4gdGhlIGNhc2Ugd2hlcmUgQSdzIG5ldHdvcmsgc3RyYWRkbGVzIEIncyBuZXR3 b3JrIGFuZCB3aGVyZSBBIHdhbnRzIHRvIHVzZSBhbiBFUk8gZm9yIGEgc2VnbWVudCBvZiB0aGUg TFNQIGFjcm9zcyB0aGUgaW50ZXJ2ZW5pbmcgbmV0d29yaywgZS5nLiAobmV0QSktKG5ldEIpLShu ZXRBKS4gSW4gYWRkaXRpb24sIHRoZSBQUlMgY291bGQgYmUgdXNlZCB0byByZWNvcmQgYSBDUFMg ZXZlbiBpZiB0aGUgcGF0aCAoYW5kIHRoZXJlZm9yZSB0aGUgcmV0dXJuZWQgUlJPKSBjcm9zc2Vz IG11bHRpcGxlIGJvdW5kYXJpZXMuIEZpbmFsbHksIGEgUFJTIHNvbHV0aW9uIGNvdWxkIGJlIGFk YXB0ZWQgdG8gcmV0dXJuIGFjdHVhbCBmYWlsdXJlIGxvY2F0aW9ucyBpbiBQRVJScyBhbmQvb3Ig UEFUSFRFQVJzLCB3aGlsZSBrZWVwaW5nIHRoZSBmYWlsdXJlIGxvY2F0aW9uIGNvbmZpZGVudGlh bCBmcm9tIExTUnMgd2l0aG91dCBhIGRlY3J5cHRpb24ga2V5LiBDdXJyZW50bHkgcHJpdmFjeSBv ZiB0aGlzIHNvdXJjZSBpcyBtYWludGFpbmVkIGJ5IHJldHVybmluZyB0aGUgYWRkcmVzcyBvZiBi b3JkZXIgbm9kZXMsIHdoaWNoIGNhbiBiZSB2ZXJ5IG1pc2xlYWRpbmcuDQoNCgkoNSkgTWVzc2Fn ZSBPYmplY3QgT3ZlcmhlYWQ6DQoNCglUaGUgUEtTIHNvbHV0aW9uIHByb3ZpZGVzIGEgdmVyeSBj b21wYWN0IGtleSBvciB0b2tlbiB0byBpZGVudGlmeSBhIHBhdGggc2VnbWVudCwgd2hpY2ggZ2Vu ZXJhbGx5IGFsbG93cyBmb3Igc21hbGxlciBFUk9zIHRvIGJlIHJldHVybmVkIGJ5IHRoZSBQQ0Ug YW5kIHRvIGJlIHJlcXVlc3RlZCBpbiB0aGUgcmVzdWx0aW5nIFBBVEggbWVzc2FnZS4gQSBQUlMg d2hpY2ggY29udGFpbnMgYSBDUFMgbXVzdCBnZW5lcmFsbHkgYmUgYXQgbGVhc3QgYXMgbGFyZ2Ug YXMgdGhlIHVuZW5jcnlwdGVkIFBBVEggdGhyb3VnaCB0aGUgQVMgYW5kIG1heSBiZSBzaWduaWZp Y2FudGx5IGxhcmdlciBpZiBpdCBpcyBkZXNpcmFibGUgdG8gaGlkZSB0aGUgbnVtYmVyIG9mIGhv cHMgd2l0aGluIHRoZSBuZXR3b3JrIGZyb20gZXh0ZXJuYWwgdmlldyBieSBwYWRkaW5nIHRoZSBQ UlMuIFRoZSByZXN1bHQgaXMgcG90ZW50aWFsbHkgbGFyZ2VyIFBBVEggKGFuZCBQQ0VQKSBtZXNz YWdlcyBmb3IgdGhlIFBSUyBzb2x1dGlvbi4NCg0KCVBsZWFzZSBub3RlIHRoYXQgdGhlIHRyYWRl b2ZmcyBsaXN0ZWQgaGVyZSBhcmUgZm9yIHRoZSBjdXJyZW50IEktRC4gU29tZSBvZiB0aGUgc2hv cnRjb21pbmdzIG9mIGVhY2ggYXBwcm9hY2ggY291bGQgYmUgbWl0aWdhdGVkIGJ5IGltcGxlbWVu dGF0aW9uLXNwZWNpZmljIG9wdGltaXphdGlvbnMuIEZvciBleGFtcGxlLCBhIFBDRSBjb3VsZCBj aG9vc2UgdG8gc2lnbmFsIHRoZSBDUFMgZXhwYW5zaW9uIHRvIHRoZSBlbnRyeSBib3VuZGFyeSBM U1IsIHNoaWZ0aW5nIHRoZSBidXJkZW4gb2YgbWFpbnRhaW5pbmcgdGhlIFBLUyBzdGF0ZSB0byB0 aGUgTFNSIGFuZCBlbGltaW5hdGluZyB0aGUgcGVyZm9ybWFuY2UgaGl0IGR1cmluZyBMU1Agc2V0 dXAuIEEgc2ltaWxhciBleGNoYW5nZSBjb3VsZCBiZSBwZXJmb3JtZWQgZm9yIHRoZSBQUlMgY2Fz ZSwgZWxpbWluYXRpbmcgdGhlIG5lZWQgZm9yIGEgc2VwYXJhdGUga2V5IGV4Y2hhbmdlLiBUaGVz ZSBleGFtcGxlcyBvZiBleHRlbnNpb25zIGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoZSBJRCwg YnV0IG1pZ2h0IGJlIHVzZWZ1bCB3aGVuIHdlaWdoaW5nIHRoZSBwcm9zIGFuZCBjb25zIG9mIHRo ZSB0d28gc29sdXRpb25zLg0KDQoJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCg0KCVBjZSBtYWlsaW5nIGxpc3QNCg0KCVBjZUBsaXN0cy5pZXRmLm9yZw0K DQoJaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNlDQoNCgkgDQoNCg== ------_=_NextPart_001_01C667C9.BF3F36CD Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6c3QxPSJ1cm46c2NoZW1hcy1taWNy b3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT1HZW5lcmF0b3IgY29u dGVudD0iTWljcm9zb2Z0IFdvcmQgMTEgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtpZiAhbXNv XT4NCjxzdHlsZT4NCnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9cOioge2Jl aGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNW TUwpO30NCi5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHlsZT4NCjwh W2VuZGlmXS0tPjxvOlNtYXJ0VGFnVHlwZQ0KIG5hbWVzcGFjZXVyaT0idXJuOnNjaGVtYXMtbWlj cm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIiBuYW1lPSJhZGRyZXNzIi8+DQo8bzpTbWFydFRh Z1R5cGUgbmFtZXNwYWNldXJpPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFy dHRhZ3MiDQogbmFtZT0icGxhY2UiLz4NCjxvOlNtYXJ0VGFnVHlwZSBuYW1lc3BhY2V1cmk9InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncyINCiBuYW1lPSJDaXR5Ii8+ DQo8bzpTbWFydFRhZ1R5cGUgbmFtZXNwYWNldXJpPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29t Om9mZmljZTpzbWFydHRhZ3MiDQogbmFtZT0iU3RyZWV0Ii8+DQo8IS0tW2lmICFtc29dPg0KPHN0 eWxlPg0Kc3QxXDoqe2JlaGF2aW9yOnVybCgjZGVmYXVsdCNpZW9vdWkpIH0NCjwvc3R5bGU+DQo8 IVtlbmRpZl0tLT4NCjxzdHlsZT4NCjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQg MiA1IDggMyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0x OjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMg TWluY2hvIjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCiAvKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpoMQ0KCXttYXJnaW4tdG9wOjEyLjBw dDsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206My4wcHQ7DQoJbWFyZ2luLWxl ZnQ6LjVpbjsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJcGFnZS1icmVhay1hZnRlcjphdm9pZDsN Cgltc28tbGlzdDpsMCBsZXZlbDEgbGZvMTsNCglmb250LXNpemU6MTYuMHB0Ow0KCWZvbnQtZmFt aWx5OkFyaWFsO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7Y29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5D aGFwdGVyLCBsaS5DaGFwdGVyLCBkaXYuQ2hhcHRlcg0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmNlbnRlcjsNCglwYWdlLWJyZWFrLWJlZm9yZTph bHdheXM7DQoJZm9udC1zaXplOjE2LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0K CWZvbnQtd2VpZ2h0OmJvbGQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6QXJpYWw7DQoJY29sb3I6Ymx1ZTsNCglmb250 LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5v bmUgbm9uZTt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4yNWluIDEuMGluIDEuMjVpbjt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9u MTt9DQogLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KIEBsaXN0IGwwDQoJe21zby1saXN0LWlkOjY4 ODk0MTQ2Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczox NDgzNDY2OCA1MDY0ODg2NjQgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2 OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21z by1sZXZlbC1zdHlsZS1saW5rOiJIZWFkaW5nIDEiOw0KCW1zby1sZXZlbC10YWItc3RvcDouNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0K LS0+DQo8L3N0eWxlPg0KDQo8L2hlYWQ+DQoNCjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZs aW5rPWJsdWUgc3R5bGU9J1dPUkQtV1JBUDogYnJlYWstd29yZDtraHRtbC1uYnNwLW1vZGU6IHNw YWNlOw0Ka2h0bWwtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2UnPg0KDQo8ZGl2IGNsYXNz PVNlY3Rpb24xPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUg ZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0O2ZvbnQtZmFtaWx5OkFy aWFsO2NvbG9yOmJsdWUnPkpMLDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1pbmRlbnQ6Ni4wcHQnPjxmb250IHNpemU9MyBjb2xv cj1ibHVlDQpmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OkFyaWFsO2NvbG9yOmJsdWUnPlRoYW5rcw0KZm9yIHRoZSByZXBseS4gSXTigJlzIGFsd2F5 cyBkaWZmaWN1bHQgdG8gY2hvb3NlIGJldHdlZW4gbXVsdGlwbGUgc29sdXRpb25zIHdoZW4NCnRo ZXJlIGFyZSBzbyBtYW55IHRyYWRlb2ZmcyBiZXR3ZWVuIHRoZSBzb2x1dGlvbnMuwqAgPG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0 LWluZGVudDo2LjBwdCc+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUNCmZhY2U9QXJpYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6Ymx1ZSc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSd0ZXh0LWluZGVudDo2LjBwdCc+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUNCmZhY2U9QXJp YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6 Ymx1ZSc+UmVnYXJkaW5nDQp0aGUgb3B0aW1pemF0aW9uIHdoZXJlIHRoZSBQQ0Ugc2VuZHMgdGhl IExTUiB0aGUgdW5zb2xpY2l0ZWQgY29tcHV0ZWQgcGF0aA0Kc2VnbWVudC4gwqBJdCB3YXMgYSBk aWZmaWN1bHQgY2hvaWNlIHdoZXRoZXIgb3Igbm90IHRvIGluY2x1ZGUgYSBkZXNjcmlwdGlvbiBv Zg0KdGhpcyBpbiB0aGUgb3JpZ2luYWwgZHJhZnQsIHNpbmNlIGl0IGlzIG1vcmUgY29tcGxleC4g V2hpY2ggYXNwZWN0IG9mIHRoZQ0Kb3B0aW1pemF0aW9uIHNlZW1lZCBtb3N0IGltcG9ydGFudD8g V2FzIGl0IHRoYXQgaXTigJlzIG1vcmUgZWZmaWNpZW50IGR1cmluZyBMU1ANCnNldHVwIG9yIGJl Y2F1c2UgaXQgY291bGQgYmUgdXNlZCB0byBzaGlmdCB0aGUgYnVyZGVuIG9mIG1haW50YWluaW5n IHN0YXRlIGZyb20NCnRoZSBQQ0UgdG8gdGhlIExTUj88bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtaW5kZW50OjYuMHB0Jz48Zm9u dCBzaXplPTMgY29sb3I9Ymx1ZQ0KZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibHVlJz5UaGFua3MNCm9uY2UgYWdhaW4gZm9y IHlvdXIgb3Bpbmlvbi4gPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWluZGVudDo2LjBwdCc+PGZvbnQgc2l6ZT0zIGNvbG9yPWJs dWUNCmZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 QXJpYWw7Y29sb3I6Ymx1ZSc+QmVzdA0KUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtaW5kZW50OjYuMHB0Jz48Zm9u dCBzaXplPTMgY29sb3I9Ymx1ZQ0KZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibHVlJz7CoCBSaWNoPG86cD48L286cD48L3Nw YW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBjb2xvcj1i bHVlIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdDtmb250LWZhbWls eTpBcmlhbDtjb2xvcjpibHVlJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K DQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQnPg0KDQo8ZGl2Pg0KDQo8ZGl2IGNsYXNzPU1zb05vcm1h bCBhbGlnbj1jZW50ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyJz48Zm9udCBzaXplPTMNCmZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPg0KDQo8 aHIgc2l6ZT0yIHdpZHRoPSIxMDAlIiBhbGlnbj1jZW50ZXIgdGFiaW5kZXg9LTE+DQoNCjwvc3Bh bj48L2ZvbnQ+PC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Yj48Zm9udCBzaXplPTIgZmFj ZT1UYWhvbWE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpUYWhv bWE7Zm9udC13ZWlnaHQ6Ym9sZCc+RnJvbTo8L3NwYW4+PC9mb250PjwvYj48Zm9udCBzaXplPTIN CmZhY2U9VGFob21hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlRh aG9tYSc+IDxzdDE6U3RyZWV0DQp3OnN0PSJvbiI+PHN0MTphZGRyZXNzIHc6c3Q9Im9uIj5MRSBS T1VYIEplYW4tTG91aXMgUkQ8L3N0MTphZGRyZXNzPjwvc3QxOlN0cmVldD4tQ09SRS1MQU4NCltt YWlsdG86amVhbmxvdWlzLmxlcm91eEBmcmFuY2V0ZWxlY29tLmNvbV0gPGJyPg0KPGI+PHNwYW4g c3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPlNlbnQ6PC9zcGFuPjwvYj4gRnJpZGF5LCBBcHJpbCAy MSwgMjAwNiAxMjo1MQ0KUE08YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+ VG86PC9zcGFuPjwvYj4gSmVhbiBQaGlsaXBwZSBWYXNzZXVyDQooanZhc3NldXIpOyBSaWNoIEJy YWRmb3JkIChyYnJhZGZvcik8YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+ Q2M6PC9zcGFuPjwvYj4gY2NhbXBAb3BzLmlldGYub3JnOw0KcGNlQGlldGYub3JnPGJyPg0KPGI+ PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPlN1YmplY3Q6PC9zcGFuPjwvYj4gUkU6IFtQ Y2VdIENvbXBhcmlzb24gb2YNCkVuY3J5cHRpb24gdnMuIFBhdGggS2V5IFNvbHV0aW9ucyBmb3Ig dGhlIENQU0lELjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250 PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9 QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtj b2xvcjpibHVlJz5IaSBKUCwgUmljaGFyZDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUg ZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFy aWFsO2NvbG9yOmJsdWUnPlBsZWFzZSBzZWUgaW5saW5lLDwvc3Bhbj48L2ZvbnQ+PG86cD48L286 cD48L3A+DQoNCjxibG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7DQptYXJnaW4tbGVmdDozLjc1 cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQn Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9mb250PjwvcD4NCg0KPGRpdiBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxl PSd0ZXh0LWFsaWduOmNlbnRlcic+PGZvbnQgc2l6ZT0zDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxzcGFuIGxhbmc9RlIgc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPg0KDQo8aHIgc2l6ZT0yIHdp ZHRoPSIxMDAlIiBhbGlnbj1jZW50ZXIgdGFiSW5kZXg9LTE+DQoNCjwvc3Bhbj48L2ZvbnQ+PC9k aXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxi Pjxmb250IHNpemU9MiBmYWNlPVRhaG9tYT48c3Bhbg0KbGFuZz1GUiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpUYWhvbWE7Zm9udC13ZWlnaHQ6Ym9sZCc+RGUmbmJzcDs6PC9z cGFuPjwvZm9udD48L2I+PGZvbnQNCnNpemU9MiBmYWNlPVRhaG9tYT48c3BhbiBsYW5nPUZSIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlRhaG9tYSc+DQpKUCBWYXNzZXVyIFtt YWlsdG86anZhc3NldXJAY2lzY28uY29tXSA8YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWln aHQ6Ym9sZCc+RW52b3nDqSZuYnNwOzo8L3NwYW4+PC9iPiBqZXVkaSA2IGF2cmlsIDIwMDYNCjE0 OjUyPGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPsOAJm5ic3A7Ojwvc3Bh bj48L2I+IFJpY2ggQnJhZGZvcmQ8YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9s ZCc+Q2MmbmJzcDs6PC9zcGFuPjwvYj4gY2NhbXBAb3BzLmlldGYub3JnOw0KcGNlQGlldGYub3Jn PGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPk9iamV0Jm5ic3A7Ojwvc3Bh bj48L2I+IFJlOiBbUGNlXSBDb21wYXJpc29uDQpvZiBFbmNyeXB0aW9uIHZzLiBQYXRoIEtleSBT b2x1dGlvbnMgZm9yIHRoZSBDUFNJRC48L3NwYW4+PC9mb250PjxzcGFuIGxhbmc9RlI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+SGksIDxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1z aXplOg0KMTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rp dj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPlRoYW5rcyBmb3Ig dGhlIHN1bW1hcnkgUmljaC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4N Cg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToNCjEyLjBwdCc+UENFIFdHIG1lbWJlcnM6IHRoYW5rcyB0byBwcm92aWRlIHlvdXIg ZmVlZGJhY2sgb24gd2hldGhlcjo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rp dj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPigxKSBZb3UgdGhp bmsgdGhhdCB0aGVyZSBpcyBhIG5lZWQgZm9yIHN1Y2ggc29sdXRpb24sPC9zcGFuPjwvZm9udD48 Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDsNCmNvbG9yOmJsdWUnPiZuYnNwOzwvc3Bhbj48L2Zv bnQ+PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToNCjEyLjBwdCc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9k aXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1 ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6 QXJpYWw7Y29sb3I6Ymx1ZSc+WWVzIGRlZmluaXRlbHksIGNvbmZpZGVudGlhbGl0eSBpcyBhIGtl eQ0KcmVxdWlyZW1lbnRzIGluIGFuIGludGVyLXByb3ZpZGVyIGNvbnRleHQuPC9zcGFuPjwvZm9u dD48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1z aXplOg0KMTIuMHB0Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rp dj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPigyKSBZb3Ugd291 bGQgcHJlZmVyIG9uZSBzb2x1dGlvbiAod2hpY2ggb25lIGFuZCB3aHkgPyk8L3NwYW4+PC9mb250 Pjxmb250DQpzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsOw0KY29sb3I6Ymx1ZSc+Jm5ic3A7PC9zcGFuPjwv Zm9udD48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOg0KMTIuMHB0Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8 L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPigzKSBZb3Ug dGhpbmsgdGhhdCB0aGVyZSBpcyBhIG5lZWQgZm9yIGJvdGg8L3NwYW4+PC9mb250Pjxmb250IHNp emU9Mg0KY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OkFyaWFsOw0KY29sb3I6Ymx1ZSc+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpw PjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9u dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0K MTIuMHB0Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0K PGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9 QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtj b2xvcjpibHVlJz5BbnN3ZXIgdG8gKDIpIGFuZCAoMyk6PC9zcGFuPjwvZm9udD48bzpwPjwvbzpw PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXpl PTIgY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7 Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6Ymx1ZSc+SXQgc2VlbXMgdG8gbWUgdGhhdCB3ZSBzaG91 bGQgZW5kLXVwIHdpdGgNCmEgc2luZ2xlIHNvbHV0aW9uIHNvIGFzIHRvJm5ic3A7ZWFzZSBpbnRl cndvcmtpbmcuPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+ DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBm YWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJp YWw7Y29sb3I6Ymx1ZSc+SU1PJm5ic3A7aW4gYW4gaW50ZXItQVMgTVBMUy1URQ0KZW52aXJvbm1l bnQgd2l0aG91dCBQQ0VzLCB0aGUgcGF0aHMgd2lsbCBiZSBsb29zZSBhbnl3YXksJm5ic3A7c28N CnRoZXJlJm5ic3A7d2lsbCBub3QgYmUmbmJzcDthbnkgY29uZmlkZW50aWFsaXR5IGlzc3VlLiA8 L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9QXJpYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibHVlJz5JZiBo YXZlIHNvbWUgY29uY2VybnMmbmJzcDtyZWdhcmRpbmcgdGhlDQpjb3N0IG9mIGVuY3J5cHRpb24s IHBhcnRpY3VsYXJseSBmb3IgbGFyZ2UgcGF0aHMgKHdlIG5lZWQgdG8gdGhpbmsgYWJvdXQgZnV0 dXJlDQpQMk1QIGFwcGxpY2F0aW9ucyB3aXRoIGEgbGFyZ2UgbnVtYmVyIG9mIGhvcHMuLi4pLiBC eSB0aGUgd2F5LCBlbmNyeXB0aW9uDQphcHByb2FjaGVzIGFyZSByZWFsbHkgdnVsbmVyYWJsZSB0 byBEb1MgYXR0YWNrcy48L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0K PGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9 QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtj b2xvcjpibHVlJz5IZW5jZSBJJm5ic3A7d291bGQgc3Ryb25nbHkgZmF2b3IgdGhlIFBLUw0Kc29s dXRpb24uIFRoZSBvcHRpbWl6YXRpb24gc3VnZ2VzdGVkLCZuYnNwO3doaWNoIGNvbnNpc3RzIG9m IHNlbmRpbmcgdGhlDQpjb21wdXRlZCBwYXRoIHNlZ21lbnQgdG8gdGhlIExTUiBpbiBhbiB1bnNv bGljaXRlZCBtYW5uZXIsIGp1c3QgYWZ0ZXIgdGhlDQpjb21wdXRhdGlvbiwmbmJzcDtzb3VuZHMg cmVsZXZhbnQgYW5kIHNob3VsZCBiZSBmdXJ0aGVyIGludmVzdGlnYXRlZC48L3NwYW4+PC9mb250 PjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNp emU6DQoxMi4wcHQnPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2 Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUg ZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFy aWFsO2NvbG9yOmJsdWUnPkJlc3QgUmVnYXJkcyw8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9w Pg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT1BcmlhbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOmJsdWUn PkpMPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8 ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1z aXplOg0KMTIuMHB0Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rp dj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4N Cg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz5UaGFu a3MuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNp emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4w cHQnPkpQLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBz dHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz5PbiBBcHIgNSwgMjAwNiwgYXQgNjoxOSBQTSwgUmlj aCBCcmFkZm9yZCAoKHJicmFkZm9yKSkgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz48YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvJz48Zm9udA0Kc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMi4wcHQnPjxPOlNNQVJUVEFHVFlQRSBuYW1lPSJDaXR5IiBuYW1lc3BhY2V1 cmk9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncyI+PE86U01BUlRU QUdUWVBFIG5hbWU9InBsYWNlIiBuYW1lc3BhY2V1cmk9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1j b206b2ZmaWNlOnNtYXJ0dGFncyI+SGksPE86UD48L086UD48bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48Zm9udA0Kc2l6ZT0zIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPkFzIHN1Z2dlc3RlZCBp biA8U1QxOkNJVFkgdTE6c3Q9Im9uIj48U1QxOlBMQUNFIHUxOnN0PSJvbiI+PHN0MTpDaXR5DQp3 OnN0PSJvbiI+PHN0MTpwbGFjZSB3OnN0PSJvbiI+RGFsbGFzPC9TVDE6UExBQ0U+PC9TVDE6Q0lU WT48L3N0MTpwbGFjZT48L3N0MTpDaXR5PiwNCknigJl2ZSBkZXNjcmliZWQgc29tZSBvZiB0aGUg dHJhZGVvZmZzIGJldHdlZW4gdGhlIHR3byBzb2x1dGlvbnMgZGVzY3JpYmVkIGluDQpkcmFmdC1y YnJhZGZvci1jY2FtcC1jb25maWRlbnRpYWwtc2VnbWVudC0wMC50eHQuPE86UD48L086UD48bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48Zm9udA0K c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4w cHQnPi0tIFJpY2g8TzpQPjwvTzpQPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPjxmb250DQpzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PE86UD48L086UD5UaGUNCkNvbmZpZGVudGlh bCBQYXRoIFNlZ21lbnQgKENQUykgSUQgcHJvdmlkZXMgdHdvIHZlcnkgZGlmZmVyZW50IGJ1dCBl cXVhbGx5DQp2YWxpZCBzb2x1dGlvbnMsIHRoZSBQYXRoIEtleSBTdWJvYmplY3QgKFBLUykgc29s dXRpb24gYW5kIHRoZSBQcml2YXRlIFJvdXRlDQpTdWJvYmplY3QgKFBSUykgc29sdXRpb24uIFRo aXMgbm90ZSBleGFtaW5lcyBhIG51bWJlciBvZiB0aGUgYWR2YW50YWdlcyBhbmQNCmRpc2FkdmFu dGFnZXMgb2YgZWFjaCBzb2x1dGlvbi4gPE86UD48L086UD48bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48Zm9udA0Kc2l6ZT0zIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxPOlA+PC9POlA+SW4N CnNob3J0OiBUaGUgUEtTIHNvbHV0aW9uIGFsbG93cyBhIFBDRSB0byBoaWRlIHRoZSBDUFMgZm9y IGFuIEFTIGJ5IHNhdmluZyBpdCBpbg0KYSBkYXRhYmFzZSBhbmQgcmVwbGFjaW5nIGl0IHdpdGgg YSBrZXkgaW4gdGhlIEVSTy4gRHVyaW5nIHRoZSBMU1Agc2V0dXAsIHRoZQ0KaW5ncmVzcyBMU1Ig Zm9yIHRoYXQgQVMgbXVzdCBxdWVyeSB0aGUgUENFIGZvciBhbiBleHBhbnNpb24uPE86UD48L086 UD48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48 Zm9udA0Kc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMi4wcHQnPlRoZSBQUlMgc29sdXRpb24NCmFsbG93cyBhIENQUyBmb3IgYW4gQVMgdG8gYmUg aGlkZGVuIGJ5IGVuY3J5cHRpbmcgaXQsIHdoaWNoIG1heSBiZSBkb25lIGJ5IGENClBDRSBvciBi eSB0aGUgSGVhZC1FbmQgTFNSLiBEdXJpbmcgdGhlIExTUCBzZXR1cCwgdGhlIGluZ3Jlc3MgTFNS IGZvciB0aGF0IEFTDQptdXN0IHVzZSBhIGRlY3J5cHRpb24ga2V5IHRvIG9idGFpbiB0aGUgZXhw YW5zaW9uIChpbXBseWluZyBhbiBlYXJsaWVyIGV4Y2hhbmdlDQpvciBjb25maWd1cmF0aW9uKS4g PE86UD48L086UD48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvJz48Zm9udA0Kc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMi4wcHQnPjxPOlA+PC9POlA+VGhlDQptYWpvciBkaWZmZXJlbmNlcyBiZXR3 ZWVuIHRoZSBtZWNoYW5pc21zIGludm9sdmUgKDEpIGFkZGl0aW9uYWwgY29udHJvbA0KbWVzc2Fn ZXMsICgyKSBwZXJmb3JtYW5jZSBpc3N1ZXMgZXhwYW5kaW5nIHRob3NlIG9iamVjdHMsICgzKSB0 aGUgYWRkaXRpb24gb2YNCnN0YXRlIHRvIHRoZSBQQ0UsICg0KSB0aGUgc29sdXRpb24gc2NvcGUg KGkuZS4gYXBwbGljYWJpbGl0eSB0byB2YXJpb3VzDQp0b3BvbG9naWVzIG9mIGVhY2ggc29sdXRp b24uKSwgYW5kICg1KSB0aGUgc2l6ZSBvZiBvYmplY3RzIGFkZGVkIHRvIGV4aXN0aW5nDQptZXNz YWdlcy48TzpQPjwvTzpQPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8nPjxmb250DQpzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PE86UD48L086UD4oMSkNCkFkZGl0aW9uYWwgQ29udHJv bCBNZXNzYWdlIE92ZXJoZWFkOjxPOlA+PC9POlA+PG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PGZvbnQNCnNpemU9MyBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz5UaGUgUEtTIHNvbHV0aW9uDQpy ZXF1aXJlcyBhIG1lY2hhbmlzbSB0byBleHBhbmQgdGhlIFBhdGggS2V5IHVwb24gcmVjZWlwdCBv ZiB0aGUgTFNQIHNldHVwDQpyZXF1ZXN0LiBTaW5jZSB0aGUgUENFIHdoaWNoIGNhbGN1bGF0ZWQg dGhlIFBhdGggS2V5IG1pZ2h0IG5vdCByZXNpZGUgaW4gdGhlDQplbnRyeSBib3VuZGFyeSBMU1Is IHRoZSBMU1IgbXVzdCByZXF1ZXN0IHRoZSBleHBhbnNpb24gZnJvbSB0aGUgUENFLCByZXF1aXJp bmcNCmFuIGFkZGl0aW9uYWwgbWVzc2FnZSBleGNoYW5nZSBiZWZvcmUgTFNQIHNldHVwIGNhbiBw cm9jZWVkLiBUaGUgUGF0aA0KRW5jcnlwdGlvbiBzb2x1dGlvbiBkb2VzIG5vdCByZXF1aXJlIHRo aXMgZXh0cmEgZXhjaGFuZ2UgYmV0d2VlbiB0aGUgUENFIGFuZA0KdGhlIGluZ3Jlc3Mgbm9kZSBm b3IgZXZlcnkgTFNQLiBSYXRoZXIsIHRoZSBkZWNyeXB0aW9uIGtleSBuZWVkcyB0byBiZQ0KZXhj aGFuZ2VkIG9ubHkgd2hlbiBpdCBpcyBjaGFuZ2VkLiBUaGUgcmVzdWx0IGlzIGFkZGl0aW9uYWwg ZGVsYXkgZHVyaW5nIGV2ZXJ5DQpMU1Agc2V0dXAgZm9yIHRoZSBQS1Mgc29sdXRpb24gYnV0IG5v IGFkZGl0aW9uYWwgZGVsYXkgZm9yIHRoZSBQUlMgc29sdXRpb24uPE86UD48L086UD48bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48Zm9udA0Kc2l6 ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQn PjxPOlA+PC9POlA+PE86UD48L086UD4oMikNClBDRSBhbmQgTFNSIFBlcmZvcm1hbmNlOjxPOlA+ PC9POlA+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byc+PGZvbnQNCnNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTIuMHB0Jz5UaGUgUEtTIHNvbHV0aW9uDQptdXN0IG1haW50YWluIGEgKHRlbXBvcmFy eSkgZGF0YWJhc2Ugb2Yga2V5cyBhZGRpbmcgb3ZlcmhlYWQgdG8gdGhlIFBDRS4gVGhlDQpQUlMg c29sdXRpb24gcmVxdWlyZXMgdGhlIGVuY3J5cHRpb24gb2YgdGhlIENQUyBpbiB0aGUgUENFIGFu ZCBkZWNyeXB0aW9uIG9mDQp0aGUgQ1BTIGluIHRoZSBMU1IsIHdoaWNoIGNvdWxkIGJlIENQVSBp bnRlbnNpdmUuIE5vdGUgdGhhdCBpbiBjYXNlIG9mIGEgYnVyc3QNCm9mIHJlcXVlc3RzLCBlbmNy eXB0aW9uIG9mIGxhcmdlIG51bWJlciBvZiBDUFMgbWF5IGhhdmUgYW4gaW1wYWN0IG9uIHRoZSBQ Q0UNCnJlc3BvbnNlIHRpbWUuPE86UD48L086UD48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48Zm9udA0Kc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxPOlA+PC9POlA+KDMpDQpBZGRp dGlvbiBvZiBTdGF0ZSBpbiB0aGUgUENFOjxPOlA+PC9POlA+PG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PGZvbnQNCnNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz5UaGUgUEtTIHNvbHV0 aW9uDQpyZXF1aXJlcyB0aGUgYWRkaXRpb24gb2YgcGF0aC1zcGVjaWZpYyBzdGF0ZSBhbmQgbWFp bnRlbmFuY2Ugb2YgYSBkYXRhYmFzZSBpbg0KdGhlIFBDRS4gVGhlIFBSUyBzb2x1dGlvbiByZXF1 aXJlcyBubyBhZGRpdGlvbmFsIHN0YXRlLjxPOlA+PC9POlA+PG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PGZvbnQNCnNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48TzpQPjwvTzpQPjxP OlA+PC9POlA+KDQpDQpTb2x1dGlvbiBTY29wZTo8TzpQPjwvTzpQPjxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxmb250DQpzaXplPTMgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+VGhlIFBLUyBh bmQgUFJTDQpzb2x1dGlvbnMgYm90aCB3b3JrIHdlbGwgaW4gY29uanVuY3Rpb24gd2l0aCBhIFBD RSB0byBlbmNvZGUgYW5kIGRlY29kZSB0aGUNCkNQUy4gSG93ZXZlciB0aGUgUEtTIHByb3ZpZGVz IG5vIGRpcmVjdCBzb2x1dGlvbiB3aXRob3V0IGEgUENFLiBUaGlzIHByZXZlbnRzDQp0aGUgUEtT IHNvbHV0aW9uIGZvciB3b3JraW5nIGluIHRoZSBjYXNlIHdoZXJlIEEncyBuZXR3b3JrIHN0cmFk ZGxlcyBCJ3MNCm5ldHdvcmsgYW5kIHdoZXJlIEEgd2FudHMgdG8gdXNlIGFuIEVSTyBmb3IgYSBz ZWdtZW50IG9mIHRoZSBMU1AgYWNyb3NzIHRoZQ0KaW50ZXJ2ZW5pbmcgbmV0d29yaywgZS5nLiAo bmV0QSktKG5ldEIpLShuZXRBKS4gSW4gYWRkaXRpb24sIHRoZSBQUlMgY291bGQgYmUNCnVzZWQg dG8gcmVjb3JkIGEgQ1BTIGV2ZW4gaWYgdGhlIHBhdGggKGFuZCB0aGVyZWZvcmUgdGhlIHJldHVy bmVkIFJSTykgY3Jvc3Nlcw0KbXVsdGlwbGUgYm91bmRhcmllcy4gRmluYWxseSwgYSBQUlMgc29s dXRpb24gY291bGQgYmUgYWRhcHRlZCB0byByZXR1cm4gYWN0dWFsDQpmYWlsdXJlIGxvY2F0aW9u cyBpbiBQRVJScyBhbmQvb3IgUEFUSFRFQVJzLCB3aGlsZSBrZWVwaW5nIHRoZSBmYWlsdXJlIGxv Y2F0aW9uDQpjb25maWRlbnRpYWwgZnJvbSBMU1JzIHdpdGhvdXQgYSBkZWNyeXB0aW9uIGtleS4g Q3VycmVudGx5IHByaXZhY3kgb2YgdGhpcw0Kc291cmNlIGlzIG1haW50YWluZWQgYnkgcmV0dXJu aW5nIHRoZSBhZGRyZXNzIG9mIGJvcmRlciBub2Rlcywgd2hpY2ggY2FuIGJlDQp2ZXJ5IG1pc2xl YWRpbmcuPE86UD48L086UD48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvJz48Zm9udA0Kc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxPOlA+PC9POlA+KDUpDQpNZXNzYWdlIE9iamVjdCBP dmVyaGVhZDo8TzpQPjwvTzpQPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8nPjxmb250DQpzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+VGhlIFBLUyBzb2x1dGlvbg0KcHJvdmlkZXMgYSB2 ZXJ5IGNvbXBhY3Qga2V5IG9yIHRva2VuIHRvIGlkZW50aWZ5IGEgcGF0aCBzZWdtZW50LCB3aGlj aA0KZ2VuZXJhbGx5IGFsbG93cyBmb3Igc21hbGxlciBFUk9zIHRvIGJlIHJldHVybmVkIGJ5IHRo ZSBQQ0UgYW5kIHRvIGJlIHJlcXVlc3RlZA0KaW4gdGhlIHJlc3VsdGluZyBQQVRIIG1lc3NhZ2Uu IEEgUFJTIHdoaWNoIGNvbnRhaW5zIGEgQ1BTIG11c3QgZ2VuZXJhbGx5IGJlIGF0DQpsZWFzdCBh cyBsYXJnZSBhcyB0aGUgdW5lbmNyeXB0ZWQgUEFUSCB0aHJvdWdoIHRoZSBBUyBhbmQgbWF5IGJl IHNpZ25pZmljYW50bHkNCmxhcmdlciBpZiBpdCBpcyBkZXNpcmFibGUgdG8gaGlkZSB0aGUgbnVt YmVyIG9mIGhvcHMgd2l0aGluIHRoZSBuZXR3b3JrIGZyb20NCmV4dGVybmFsIHZpZXcgYnkgcGFk ZGluZyB0aGUgUFJTLiBUaGUgcmVzdWx0IGlzIHBvdGVudGlhbGx5IGxhcmdlciBQQVRIIChhbmQN ClBDRVApIG1lc3NhZ2VzIGZvciB0aGUgUFJTIHNvbHV0aW9uLjxPOlA+PC9POlA+PG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PGZvbnQNCnNpemU9 MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48 TzpQPjwvTzpQPjxPOlA+PC9POlA+UGxlYXNlDQpub3RlIHRoYXQgdGhlIHRyYWRlb2ZmcyBsaXN0 ZWQgaGVyZSBhcmUgZm9yIHRoZSBjdXJyZW50IEktRC4gU29tZSBvZiB0aGUNCnNob3J0Y29taW5n cyBvZiBlYWNoIGFwcHJvYWNoIGNvdWxkIGJlIG1pdGlnYXRlZCBieSBpbXBsZW1lbnRhdGlvbi1z cGVjaWZpYw0Kb3B0aW1pemF0aW9ucy4gRm9yIGV4YW1wbGUsIGEgUENFIGNvdWxkIGNob29zZSB0 byBzaWduYWwgdGhlIENQUyBleHBhbnNpb24gdG8NCnRoZSBlbnRyeSBib3VuZGFyeSBMU1IsIHNo aWZ0aW5nIHRoZSBidXJkZW4gb2YgbWFpbnRhaW5pbmcgdGhlIFBLUyBzdGF0ZSB0byB0aGUNCkxT UiBhbmQgZWxpbWluYXRpbmcgdGhlIHBlcmZvcm1hbmNlIGhpdCBkdXJpbmcgTFNQIHNldHVwLiBB IHNpbWlsYXIgZXhjaGFuZ2UNCmNvdWxkIGJlIHBlcmZvcm1lZCBmb3IgdGhlIFBSUyBjYXNlLCBl bGltaW5hdGluZyB0aGUgbmVlZCBmb3IgYSBzZXBhcmF0ZSBrZXkNCmV4Y2hhbmdlLiBUaGVzZSBl eGFtcGxlcyBvZiBleHRlbnNpb25zIGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoZSBJRCwgYnV0 DQptaWdodCBiZSB1c2VmdWwgd2hlbiB3ZWlnaGluZyB0aGUgcHJvcyBhbmQgY29ucyBvZiB0aGUg dHdvIHNvbHV0aW9ucy48TzpQPjwvTzpQPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoN CjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PE86UD48 L086UD48TzpQPjwvTzpQPjwvTzpTTUFSVFRBR1RZUEU+PC9POlNNQVJUVEFHVFlQRT5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZv bnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToN CjEyLjBwdCc+UGNlIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoN CjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PGEgaHJl Zj0ibWFpbHRvOlBjZUBsaXN0cy5pZXRmLm9yZyI+UGNlQGxpc3RzLmlldGYub3JnPC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PGEgaHJlZj0iaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcGNlIj5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9w Y2U8L2E+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjwvYmxvY2txdW90ZT4NCg0KPC9kaXY+DQoNCjwvZGl2 Pg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4NCg== ------_=_NextPart_001_01C667C9.BF3F36CD-- From owner-ccamp@ops.ietf.org Mon Apr 24 15:57:57 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FY7C1-00072B-Sj for ccamp-archive@ietf.org; Mon, 24 Apr 2006 15:57:57 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FY7C1-000778-Il for ccamp-archive@ietf.org; Mon, 24 Apr 2006 15:57:57 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FY74R-0001y4-Jk for ccamp-data@psg.com; Mon, 24 Apr 2006 19:50:07 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.53.70] (helo=oak.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FY74O-0001xA-Cx for ccamp@ops.ietf.org; Mon, 24 Apr 2006 19:50:04 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by oak.neustar.com (8.12.8/8.12.8) with ESMTP id k3OJo1BX016038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Apr 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FY74L-0002aE-Rp; Mon, 24 Apr 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-ethernet-traffic-parameters-00.txt Message-Id: Date: Mon, 24 Apr 2006 15:50:01 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : MEF Ethernet Traffic Parameters Author(s) : D. Papadimitriou Filename : draft-ietf-ccamp-ethernet-traffic-parameters-00.txt Pages : 9 Date : 2006-4-24 This document described the Metro Ethernet Forum (MEF) - specific Ethernet Traffic Parameters as described in MEF.10 when using Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet-traffic-parameters-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-ethernet-traffic-parameters-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-ethernet-traffic-parameters-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-24145011.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-ethernet-traffic-parameters-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-ethernet-traffic-parameters-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-24145011.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Mon Apr 24 19:29:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYAUy-0007Pl-Ml for ccamp-archive@ietf.org; Mon, 24 Apr 2006 19:29:44 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYAUv-0001tT-7j for ccamp-archive@ietf.org; Mon, 24 Apr 2006 19:29:44 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYAPU-000Ctp-8q for ccamp-data@psg.com; Mon, 24 Apr 2006 23:24:04 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.48] (helo=mail1.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYAPR-000Ctc-Hp for ccamp@ops.ietf.org; Mon, 24 Apr 2006 23:24:01 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1FYAPp-000308-00 for ccamp@ops.ietf.org; Tue, 25 Apr 2006 00:24:25 +0100 Received: from youref3aa80866 ([125.200.105.80] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Apr 2006 00:24:35 +0100 Message-ID: <017201c667f7$1f6bcf60$0e11a8c0@youref3aa80866> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Fahad Dogar" , References: Subject: Re: GMPLS support for Ethernet switching Date: Mon, 24 Apr 2006 23:58:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 24 Apr 2006 23:24:36.0062 (UTC) FILETIME=[400987E0:01C667F6] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Hi, Thanks for raising these questions, and I hope Dimitri et al. will respond. However, the discussion should take place on the GELS mailing list. Thanks, Adrian ----- Original Message ----- From: "Fahad Dogar" To: Sent: Monday, April 24, 2006 3:36 PM Subject: GMPLS support for Ethernet switching Hi all, I have few questions related to the draft on GMPLS support for Ethernet switching by D.Papadimitriou et al.: i) The draft discusses that connection oriented ethernet is suitable for metro and core networks where ethernet is used for transport. I am not too clear on the architecture in which ethernet LSPs would be used. Are we considering point to point type ethernet connections between switches/routers i.e. where the bandwidth is not shared. Example: Two peer routers connected through an ethernet interface, so effectively complete bandwidth is available. Or are we talking about multiple switches in a GMPLS enabled cloud that are part of the SAME LAN and bandwidth is shared. I am not sure how bandwidth reservations would be done in this sceneario. ii) Please correct me if I am wrong but it seems that the traffic engineering benefits of GMPLS support for Ethernet are also available in Ethernet over MPLS. (I am considering that connection oriented Ethernet is used in metro/core networks only). However, by providing GMPLS support for Ethernet we are able to do away with IP/MPLS layer and thus we can have an all Ethernet network (with only ethernet switches). Is this the primary reason for using GMPLS support for Ethernet rather than Ethernet over MPLS? Can someone comment on this? iii) The draft discusses various options for ethernet label, all of which seem to require modification in the forwarding plane of Ethernet? Is this something that can implemented easily i.e. change in forwarding plane? Why can't we consider MAC address or VLAN tag as the label? Thanks in advance, Fahad From owner-ccamp@ops.ietf.org Mon Apr 24 20:30:35 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYBRr-0003IH-Na for ccamp-archive@ietf.org; Mon, 24 Apr 2006 20:30:35 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYBRr-0003kJ-9J for ccamp-archive@ietf.org; Mon, 24 Apr 2006 20:30:35 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYBM8-000FhL-6m for ccamp-data@psg.com; Tue, 25 Apr 2006 00:24:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [62.23.212.165] (helo=smail.alcatel.fr) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYBM6-000Fgc-TE for ccamp@ops.ietf.org; Tue, 25 Apr 2006 00:24:39 +0000 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (8.13.4/8.13.4/Debian-3sarge1) with ESMTP id k3P0OaHN013410; Tue, 25 Apr 2006 02:24:36 +0200 In-Reply-To: To: "Fahad Dogar" Cc: ccamp@ops.ietf.org, gels@rtg.ietf.org Subject: Re: GMPLS support for Ethernet switching MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Tue, 25 Apr 2006 02:24:30 +0200 X-MIMETrack: Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.12HF868 | May 16, 2005) at 04/25/2006 02:24:36, Serialize complete at 04/25/2006 02:24:36 Content-Type: text/plain; charset="US-ASCII" X-Scanned-By: MIMEDefang 2.51 on 155.132.180.81 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 hi - see in-line (i put gels mailing list in cc.) "Fahad Dogar" Sent by: owner-ccamp@ops.ietf.org 24/04/2006 16:36 To: ccamp@ops.ietf.org cc: Subject: GMPLS support for Ethernet switching Hi all, I have few questions related to the draft on GMPLS support for Ethernet switching by D.Papadimitriou et al.: i) The draft discusses that connection oriented ethernet is suitable for metro and core networks where ethernet is used for transport. I am not too clear on the architecture in which ethernet LSPs would be used. Are we considering point to point type ethernet connections between switches/routers i.e. where the bandwidth is not shared. Example: Two peer routers connected through an ethernet interface, so effectively complete bandwidth is available. [dp] this would be either a port based ethernet LSP, supported today in RFC 3473/3471 no specific issue or a frame based ethernet LSP this is where different labeling techniques have been proposed; Or are we talking about multiple switches in a GMPLS enabled cloud that are part of the SAME LAN and bandwidth is shared. I am not sure how bandwidth reservations would be done in this sceneario. [dp] we are not talking about LAN environments ii) Please correct me if I am wrong but it seems that the traffic engineering benefits of GMPLS support for Ethernet are also available in Ethernet over MPLS. (I am considering that connection oriented Ethernet is used in metro/core networks only). However, by providing GMPLS support for Ethernet we are able to do away with IP/MPLS layer and thus we can have an all Ethernet network (with only ethernet switches). Is this the primary reason for using GMPLS support for Ethernet rather than Ethernet over MPLS? Can someone comment on this? [dp] this approach intends to deliver source routed TE label switched path establishment (through control plane upgrade) for metro/aggregation and core Ethernet networks iii) The draft discusses various options for ethernet label, all of which seem to require modification in the forwarding plane of Ethernet? Is this something that can implemented easily i.e. change in forwarding plane? Why can't we consider MAC address or VLAN tag as the label? [dp] this question has been lengthily debated on the GELS mailing list, (i refer you there as well as to last meeting discussion material) [dp] in brief, and as of today, SVID labels (using SVID translation) and MAC+SVID label (using SVL switches) are two feasible techniques for the .1ad environments Thanks in advance, Fahad From owner-ccamp@ops.ietf.org Tue Apr 25 00:46:18 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYFRK-0001gF-O1 for ccamp-archive@ietf.org; Tue, 25 Apr 2006 00:46:18 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYFRK-00085d-8c for ccamp-archive@ietf.org; Tue, 25 Apr 2006 00:46:18 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYFEC-000356-WD for ccamp-data@psg.com; Tue, 25 Apr 2006 04:32:45 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYFEC-00034t-1A for ccamp@ops.ietf.org; Tue, 25 Apr 2006 04:32:44 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 24 Apr 2006 21:32:35 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,153,1144047600"; d="scan'208"; a="26605887:sNHT26486780" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3P4WUTL013443; Tue, 25 Apr 2006 00:32:31 -0400 (EDT) Received: from xmb-rtp-203.amer.cisco.com ([64.102.31.20]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Apr 2006 00:32:30 -0400 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 Subject: RE: GMPLS dynamics vs. issues with optical amplifiers Date: Tue, 25 Apr 2006 00:32:29 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: GMPLS dynamics vs. issues with optical amplifiers Thread-Index: AcZct0uhDoNv1DUrSRirfsZJqo242QLaJq7g From: "Zafar Ali \(zali\)" To: "Richard Rabbat" , "Don Fedyk" , "Filippo Cugini" , "Adrian Farrel" , "Marco Ruffini" Cc: X-OriginalArrivalTime: 25 Apr 2006 04:32:30.0764 (UTC) FILETIME=[43D156C0:01C66821] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Richard Rabbat > Sent: Monday, April 10, 2006 11:55 AM > To: 'Don Fedyk'; 'Filippo Cugini'; 'Adrian Farrel'; 'Marco Ruffini' > Cc: ccamp@ops.ietf.org > Subject: RE: GMPLS dynamics vs. issues with optical amplifiers >=20 > Hi, > There are pros and cons to advertising optical information=20 > including lambda availability and optical impairements. =20 > GMPLS is not supposed to replace advanced path computation=20 > tools. Actually, an entity such as the PCE would be a perfect=20 > piece in the architecture of a lambda network as it is=20 > expected to provide advanced computation capabilities beyond CSPF. Richard,=20 From flooding view point, PCE is just like another node in the network receiving flooding from peering nodes. So in any case extension to the IGP protocol will be needed if we want to convey more optical information (e.g., optical impairements).=20 Nonetheless, I am for exploring more in this area.=20 Thanks Regards... Zafar=20 > > Actually, we've been looking at some interop scenarii where=20 > we are clearly in need for standardization and mentioned one=20 > such scenario in > http://www.ietf.org/internet-drafts/draft-shiba-ccamp-gmpls-la mbda-labels-01 > .txt > > I think it's time to do a proper analysis of what support=20 > already exists, what is still needed and work on extensions=20 > (if needed) to support the new generation of ROADM and PXC=20 > devices where interop is required. > A few vendors who build ROADMs and PXCs, as well as SPs=20 > deploying them have expressed interest in this topic when we=20 > discussed the 1st version at CCAMP. > I think it's time to sit down and take a stab at it so we=20 > have an interesting draft to discuss in Montreal. > Send me email if you have some cycles to spare on this topic. > Richard. > =20 >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org=20 > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Don Fedyk > > Sent: Monday, April 10, 2006 8:05 AM > > To: Filippo Cugini; Adrian Farrel; Marco Ruffini > > Cc: ccamp@ops.ietf.org > > Subject: RE: GMPLS dynamics vs. issues with optical amplifiers > >=20 > >=20 > > Hi all > >=20 > > About a year ago we started to collect requirements for towards this > > area in a draft. Our current thinking is that the optical/photonic > > networks will have fairly proprietary ways of dealing with the > > non-linear properties but that the interface to GMPLS can be=20 > > summarized > > as a fairly generic network interface with a simple metric and a > > blocking capability. We only got as far a the requirements.=20 > The draft > > is in in need of a refresh I will try to do that shortly. I have to > > contact some other people who were interested in the area.=20 > >=20 > > If you cannot find a copy of the draft I will send it to you.=20 > >=20 > > draft-ashwood-ccamp-gmpls-constraint-reqts-00 > >=20 > > Regards, > > Don=20 > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org=20 > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Filippo Cugini > > >=20 > > >=20 > > > Hi all, > > >=20 > > > IMO the issue will have to be faced soon. Transparent network=20 > > > elements such=20 > > > as ROADM and PXC are beginning to be deployed in optical=20 > > > transport networks. However, the current GMPLS does not=20 > > > provide any functionality to keep track=20 > > > of the signal quality degradation. Thus, transparent mesh=20 > > > networks must be=20 > > > statically designed, during the network planning, to=20 > > > guarantee that even the=20 > > > most impaired connection (e.g., the longest path) is=20 > > > acceptable. Otherwise,=20 > > > because of the current GMPLS limits, connections can=20 > > > successfully be set up=20 > > > even if they do not comply with physical parameters=20 > > > constraints. However, the worst case design approach heavily=20 > > > limits the size of the=20 > > > transparent networks. > > >=20 > > > Filippo > > >=20 > > >=20 > > > ----- Original Message -----=20 > > > From: "Adrian Farrel" > > > > [..] > > > > - There *might* be a future requirement to signal certain > > > > constraints, but we would need to see the requirements clearly > > > > stated. > > > > - There is probably a need to enhance the advertisement of > > > > some key physical attributes of optical links and nodes in > > > > the IGPs. At the moment, however, this information > > > > appears to be gathered through inventory systems and > > > > there has been very little consideration of this requirement. > > >=20 > > >=20 > > >=20 > >=20 > >=20 >=20 From owner-ccamp@ops.ietf.org Tue Apr 25 00:51:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYFW7-00044h-3v for ccamp-archive@ietf.org; Tue, 25 Apr 2006 00:51:15 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYFW6-0008I5-IF for ccamp-archive@ietf.org; Tue, 25 Apr 2006 00:51:15 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYFPf-0003s6-2U for ccamp-data@psg.com; Tue, 25 Apr 2006 04:44:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [80.68.34.48] (helo=mail1.noc.data.net.uk) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYFPd-0003rq-HH for ccamp@ops.ietf.org; Tue, 25 Apr 2006 04:44:33 +0000 Received: from 57-99.dsl.data.net.uk ([80.68.57.99] helo=cortex.aria-networks.com) by mail1.noc.data.net.uk with esmtp (Exim 3.36 #2) id 1FYFPf-0004IA-00 for ccamp@ops.ietf.org; Tue, 25 Apr 2006 05:44:35 +0100 Received: from youref3aa80866 ([125.200.105.80] RDNS failed) by cortex.aria-networks.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 25 Apr 2006 05:45:08 +0100 Message-ID: <022b01c66823$e62b2890$0e11a8c0@youref3aa80866> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Zafar Ali \(zali\)" , "Richard Rabbat" , "Don Fedyk" , "Filippo Cugini" , "Marco Ruffini" Cc: References: Subject: Re: GMPLS dynamics vs. issues with optical amplifiers Date: Tue, 25 Apr 2006 05:51:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-OriginalArrivalTime: 25 Apr 2006 04:45:08.0406 (UTC) FILETIME=[07685560:01C66823] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 225414c974e0d6437992164e91287a51 Hi Zafar, While I agree with you as a likely deployment scenario, I must point out that PCE is architecturally not just like any other node in the network receiving flooding from peering nodes. The PCE architecture very clearly (and deliberately) states that the information on which the PCE operates may be limited to the IGP flooding information, may be enhanced from other sources (which could include configuration, inventory discovery, alarm management, network monitoring, etc.), or might be restricted to other sources (i.e. without listening to flooding). This is to say that the need to factor this information into the computations performed by PCE neither forces nor precludes the addition of the information to the flooding protocol. Cheers, Adrian ----- Original Message ----- From: "Zafar Ali (zali)" To: "Richard Rabbat" ; "Don Fedyk" ; "Filippo Cugini" ; "Adrian Farrel" ; "Marco Ruffini" Cc: Sent: Tuesday, April 25, 2006 5:32 AM Subject: RE: GMPLS dynamics vs. issues with optical amplifiers > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Richard Rabbat > Sent: Monday, April 10, 2006 11:55 AM > To: 'Don Fedyk'; 'Filippo Cugini'; 'Adrian Farrel'; 'Marco Ruffini' > Cc: ccamp@ops.ietf.org > Subject: RE: GMPLS dynamics vs. issues with optical amplifiers > > Hi, > There are pros and cons to advertising optical information > including lambda availability and optical impairements. > GMPLS is not supposed to replace advanced path computation > tools. Actually, an entity such as the PCE would be a perfect > piece in the architecture of a lambda network as it is > expected to provide advanced computation capabilities beyond CSPF. Richard, From flooding view point, PCE is just like another node in the network receiving flooding from peering nodes. So in any case extension to the IGP protocol will be needed if we want to convey more optical information (e.g., optical impairements). Nonetheless, I am for exploring more in this area. Thanks Regards... Zafar > > Actually, we've been looking at some interop scenarii where > we are clearly in need for standardization and mentioned one > such scenario in > http://www.ietf.org/internet-drafts/draft-shiba-ccamp-gmpls-la mbda-labels-01 > .txt > > I think it's time to do a proper analysis of what support > already exists, what is still needed and work on extensions > (if needed) to support the new generation of ROADM and PXC > devices where interop is required. > A few vendors who build ROADMs and PXCs, as well as SPs > deploying them have expressed interest in this topic when we > discussed the 1st version at CCAMP. > I think it's time to sit down and take a stab at it so we > have an interesting draft to discuss in Montreal. > Send me email if you have some cycles to spare on this topic. > Richard. > > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Don Fedyk > > Sent: Monday, April 10, 2006 8:05 AM > > To: Filippo Cugini; Adrian Farrel; Marco Ruffini > > Cc: ccamp@ops.ietf.org > > Subject: RE: GMPLS dynamics vs. issues with optical amplifiers > > > > > > Hi all > > > > About a year ago we started to collect requirements for towards this > > area in a draft. Our current thinking is that the optical/photonic > > networks will have fairly proprietary ways of dealing with the > > non-linear properties but that the interface to GMPLS can be > > summarized > > as a fairly generic network interface with a simple metric and a > > blocking capability. We only got as far a the requirements. > The draft > > is in in need of a refresh I will try to do that shortly. I have to > > contact some other people who were interested in the area. > > > > If you cannot find a copy of the draft I will send it to you. > > > > draft-ashwood-ccamp-gmpls-constraint-reqts-00 > > > > Regards, > > Don > > > > > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Filippo Cugini > > > > > > > > > Hi all, > > > > > > IMO the issue will have to be faced soon. Transparent network > > > elements such > > > as ROADM and PXC are beginning to be deployed in optical > > > transport networks. However, the current GMPLS does not > > > provide any functionality to keep track > > > of the signal quality degradation. Thus, transparent mesh > > > networks must be > > > statically designed, during the network planning, to > > > guarantee that even the > > > most impaired connection (e.g., the longest path) is > > > acceptable. Otherwise, > > > because of the current GMPLS limits, connections can > > > successfully be set up > > > even if they do not comply with physical parameters > > > constraints. However, the worst case design approach heavily > > > limits the size of the > > > transparent networks. > > > > > > Filippo > > > > > > > > > ----- Original Message ----- > > > From: "Adrian Farrel" > > > > [..] > > > > - There *might* be a future requirement to signal certain > > > > constraints, but we would need to see the requirements clearly > > > > stated. > > > > - There is probably a need to enhance the advertisement of > > > > some key physical attributes of optical links and nodes in > > > > the IGPs. At the moment, however, this information > > > > appears to be gathered through inventory systems and > > > > there has been very little consideration of this requirement. > > > > > > > > > > > > > > From transatlantic2@gmail.com Tue Apr 25 05:30:34 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYJsQ-0004mY-AM for ccamp-archive@ietf.org; Tue, 25 Apr 2006 05:30:34 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYJsO-0004nI-LC for ccamp-archive@ietf.org; Tue, 25 Apr 2006 05:30:34 -0400 Received: from [72.14.204.229] (helo=qproxy.gmail.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYJcg-000N5W-9G for ccamp-data@psg.com; Tue, 25 Apr 2006 09:14:18 +0000 Received: by qproxy.gmail.com with SMTP id e12so67587qbe for ; Tue, 25 Apr 2006 02:14:17 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:subject:mime-version:content-type; b=bfgaKoN38YNx8bKoPy8kc6dWeRlw2qx182jgHNHGDQGU0s2wOsKTppVTuyiO+U7Qlyf5cmt+YLsVmCZAgEgLBM1/pyTNwVLIdWSwN1+pnHmgrmeZWG4/k1NyPAiHBvXSpWbg4f16PZ37XbBrJTgRiD34xzVV6lSNvrCNp1WJ8yE= Received: by 10.37.22.42 with SMTP id z42mr3867965nzi; Tue, 25 Apr 2006 02:08:47 -0700 (PDT) Received: by 10.36.56.7 with HTTP; Mon, 24 Apr 2006 23:34:43 -0700 (PDT) Message-ID: Date: Tue, 25 Apr 2006 08:34:43 +0200 From: "shine west" Subject: HELLO!!!CONTACT US WINNER! MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_9876_16944524.1145946883903" X-Spam-Score: 4.3 (++++) X-Scan-Signature: 21be852dc93f0971708678c18d38c096 ------=_Part_9876_16944524.1145946883903 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline EURO MILLIONS INTERNATIONAL AWARD/PROMOTIONAL DEPARTMENT AMSTERDAM, THE NETHERLANDS. EMAIL:transatlanti@netscape.net http://www.loteria.com/euro.php REF NUMBER:[DF/04679/ST] We are happy to inform you that your email address has been selected as one of the lucky email addresses in the category "B" of the online lotto conducted by EURO MILLIONS INTERNATIONAL. CONGRATULATIONS!!!! The EURO MILLIONS ESPANA was conducted by an automated computer balloting system, where by email addresses(30,000 email addresses),were extracted fro= m all continents of the world.A draw was held in different categories and winners emerged from different parts of the world and they are entitled to various cash prizes depending on their different categories.Thus ,you are entitled to a prize money of 466.812,79 Euros(Four hundred and sixty-six thousand, eight hundred and twelve euro,seventy-nine cent)only. winning numbers:8-16-19-43-45-1-4 Reference number:[LM/04679/TN] Ticket number:[754/22/76] As a category B winner, you have been selected by computer balloting system where only email addresses are soughted,from a total number of 30,000 email addresses drawn from all over the globe.After an automated computer ballot of our International Promotions Program, only ten winners emerged in this category and therefore you are to receive payout of 466.812,79 Euros.This promotional program takes place every year, and is promoted and sponsored! by EURO MILLIONS INTERNATIONAL,and other corporate organisations. This is to encourage the use of the internet and computers worldwide. To immediately claim your prize, please contact our fiduciary agent: below are the contact information of your fiiduciary agent: TRANSATLANTIC FINANCE AGENCY S.L =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 Mr.PAKER WHITE KONINGSHOEF 265, 1156 HT,AMSTERDAM, THE NETHERLANDS. TEL:0031-624-677-205 TEL:0031-847-533-420 EMAIL:transatlanti@netscape.net =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 In your best interest(s),you must initiate contact within one week of receipt of this correspondence. You are to provide the below details,to enable the speedy evaluation and processing of your winnings. we advice that you adhere strictly to their procedures to avoid any disqualifications and subsequent cancellation. 1. your full names 2. your full home / office address 3. direct telephone/fax numbers and email 4. fax copy of your identity card/driver's license The beneficiary is responsible for the(VETT/APPROVAL CHARGES)of his fund to his/her country.Your winning prize is not deductable until your winnings has been processed,approved and transfered to you by your claim agent above= , For verification on your lucky winning prize,you are to visit our online site (http://www.loteria.com/euro.php ) and indicate the date this email lottery programme draw of the EURO MILLIONS was held (30th of december 2005)and there you will find your result winning number.the late release of this result wa= s due to difficulties encountered in sorting out mixed up numbers and email addresses. We congratulate you once again and it is our hope that you participate in any of our international programs in the nearest future. Thank you. Sincerely, Maria Jose. Promotions Manager EMAIL:transatlanti@netscape.net -------------- ----------------------------------- This e-mail transmission contains information that is confidential and may be privileged.It is intended only for the addressee(s) named above. ------=_Part_9876_16944524.1145946883903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
EURO MILLIONS INTERNATIONAL
AWARD/PROMOTIONAL DEPARTMENT
AMSTERDA= M, THE NETHERLANDS.
E= MAIL:transatlanti@netscape.net
http://www.loteria.com/euro.php
 
REF NUMBER:[DF/04679/ST]<= br> 
We are happy to inform you that your email address has been se= lected as
one of the lucky email addresses in the category "B"= ; of the online lotto=20
conducted by EURO MILLIONS INTERNATIONAL.
CONGRATULATIONS!!!!
Th= e EURO MILLIONS ESPANA was conducted by an automated computer balloting system, where by email addresses(30,000 email addresses),were extracted fr= om=20
all continents of the world.A draw was held in different categories and=
winners emerged from different parts of the world and they are entitle= d to
various cash prizes depending on their different categories.Thus ,you are entitled
to a prize money of 466.812,79 Euros(Four hundred an= d sixty-six thousand, eight
hundred and twelve euro,seventy-nine cent)o= nly.
winning numbers:8-16-19-43-45-1-4
Reference number:[LM/04679/TN= ]=20
Ticket number:[754/22/76]
 
As a category B winner, you hav= e been selected by computer balloting system where
only email addresses= are soughted,from a total number of 30,000 email addresses
drawn from = all over the=20 globe.After an automated computer ballot of our International
Promotion= s Program, only ten winners emerged in this category and therefore you are<= br>to receive payout of 466.812,79 Euros.This promotional program takes pla= ce every year,=20
and is promoted and sponsored! by EURO MILLIONS INTERNATIONAL,and other= corporate organisations.
This is to encourage the use of the internet a= nd computers worldwide.
To immediately claim your prize, please contact = our fiduciary agent:=20
below are the contact information of your fiiduciary agent:
TRANSATL= ANTIC FINANCE AGENCY S.L
=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
Mr.PAKER= WHITE
KONINGSHOEF 265,
1156 HT,AMSTERDAM,
THE NETHERLANDS.
TEL:0031-624-677-205
TEL:0031-847-533-420
EMAIL:transatlanti@netscape.net
=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
In your best interest(s),you must initiate contact= within one week of receipt=20
of this correspondence.
You are to provide the below details,to enab= le the speedy evaluation and
processing of your winnings. we advice that= you adhere strictly to their
procedures to avoid any disqualifications= and subsequent cancellation.=20
1. your full names
2. your full home / office address
3. direct= telephone/fax numbers and email
4. fax copy of your identity card/driv= er's license
The beneficiary is responsible for the(VETT/APPROVAL CHARGE= S)of his fund=20
to his/her country.Your winning prize is not deductable until your winn= ings
has been processed,approved and transfered to you by your claim age= nt above,
For verification on your lucky winning prize,you are to visit= our online site=20
(http://www.loteria.com/eur= o.php ) and indicate the date this email lottery
programme draw of = the EURO MILLIONS was held (30th of december 2005)and there
you will fi= nd your result winning=20 number.the late release of this result was due
to difficulties encounte= red in sorting out mixed up numbers and email addresses.
We congratulat= e you once again and it is our hope that you participate
in any of our = international programs in the nearest future.=20
Thank you.
Sincerely,
Maria Jose.
Promotions Manager
EMAIL:transatlanti@netscape.ne= t
-------------- -----------------------------------
This e-mail= transmission contains information that is confidential and may=20
be privileged.It is intended only for the addressee(s) named above.
------=_Part_9876_16944524.1145946883903-- From owner-ccamp@ops.ietf.org Tue Apr 25 09:16:04 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYNOe-0003dN-TZ for ccamp-archive@ietf.org; Tue, 25 Apr 2006 09:16:04 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYNOd-0007rn-9Z for ccamp-archive@ietf.org; Tue, 25 Apr 2006 09:16:04 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYN8j-000Arc-Sc for ccamp-data@psg.com; Tue, 25 Apr 2006 12:59:37 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.1 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYN8c-000Ar4-7C for ccamp@ops.ietf.org; Tue, 25 Apr 2006 12:59:33 +0000 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 25 Apr 2006 05:59:28 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,153,1144047600"; d="scan'208,217"; a="26623886:sNHT66162804" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3PCxSvF024543; Tue, 25 Apr 2006 08:59:28 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Apr 2006 08:59:27 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Apr 2006 08:59:25 -0400 In-Reply-To: <3C292CE901FC634693F24FB2DDC4D33201601C11@xmb-rtp-20d.amer.cisco.com> References: <3C292CE901FC634693F24FB2DDC4D33201601C11@xmb-rtp-20d.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: multipart/alternative; boundary=Apple-Mail-19-159039474 Message-Id: Cc: ccamp@ops.ietf.org, "Rich Bradford ((rbradfor))" , Adrian Farrel From: JP Vasseur Subject: Re: [Pce] Comparison of Encryption vs. Path Key Solutions for the CPSID. Date: Tue, 25 Apr 2006 08:59:23 -0400 To: LE ROUX Jean-Louis RD-CORE-LAN , pce@ietf.org X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 25 Apr 2006 12:59:25.0514 (UTC) FILETIME=[146BE2A0:01C66868] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 884d655656c6d298dae25b0122479d16 --Apple-Mail-19-159039474 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Hi, Thanks for your feed-back, suggesting to go ahead with one solution, =20 the PKS. Indeed, the proposed optimization could be specified in a =20 further revision (being optional). Others, any opinion ? Thanks. JP. On Apr 24, 2006, at 2:06 PM, Rich Bradford ((rbradfor)) wrote: > JL, > > Thanks for the reply. It=92s always difficult to choose between =20 > multiple solutions when there are so many tradeoffs between the =20 > solutions. > > > > Regarding the optimization where the PCE sends the LSR the =20 > unsolicited computed path segment. It was a difficult choice =20 > whether or not to include a description of this in the original =20 > draft, since it is more complex. Which aspect of the optimization =20 > seemed most important? Was it that it=92s more efficient during LSP =20= > setup or because it could be used to shift the burden of =20 > maintaining state from the PCE to the LSR? > > Thanks once again for your opinion. > > Best Regards, > > Rich > > > > From: LE ROUX Jean-Louis RD-CORE-LAN =20 > [mailto:jeanlouis.leroux@francetelecom.com] > Sent: Friday, April 21, 2006 12:51 PM > To: Jean Philippe Vasseur (jvasseur); Rich Bradford (rbradfor) > Cc: ccamp@ops.ietf.org; pce@ietf.org > Subject: RE: [Pce] Comparison of Encryption vs. Path Key Solutions =20 > for the CPSID. > > > > Hi JP, Richard > > > > Please see inline, > > > > De : JP Vasseur [mailto:jvasseur@cisco.com] > Envoy=E9 : jeudi 6 avril 2006 14:52 > =C0 : Rich Bradford > Cc : ccamp@ops.ietf.org; pce@ietf.org > Objet : Re: [Pce] Comparison of Encryption vs. Path Key Solutions =20 > for the CPSID. > > Hi, > > > > Thanks for the summary Rich. > > > > PCE WG members: thanks to provide your feedback on whether: > > (1) You think that there is a need for such solution, > > > > Yes definitely, confidentiality is a key requirements in an inter-=20 > provider context. > > > > (2) You would prefer one solution (which one and why ?) > > > > (3) You think that there is a need for both > > > > Answer to (2) and (3): > > It seems to me that we should end-up with a single solution so as =20 > to ease interworking. > > IMO in an inter-AS MPLS-TE environment without PCEs, the paths will =20= > be loose anyway, so there will not be any confidentiality issue. > > If have some concerns regarding the cost of encryption, =20 > particularly for large paths (we need to think about future P2MP =20 > applications with a large number of hops...). By the way, =20 > encryption approaches are really vulnerable to DoS attacks. > > Hence I would strongly favor the PKS solution. The optimization =20 > suggested, which consists of sending the computed path segment to =20 > the LSR in an unsolicited manner, just after the computation, =20 > sounds relevant and should be further investigated. > > > > Best Regards, > > > > JL > > > > > > > > > > Thanks. > > > > JP. > > > > On Apr 5, 2006, at 6:19 PM, Rich Bradford ((rbradfor)) wrote: > > > > > Hi, > > As suggested in Dallas, I=92ve described some of the tradeoffs =20 > between the two solutions described in draft-rbradfor-ccamp-=20 > confidential-segment-00.txt. > > -- Rich > > The Confidential Path Segment (CPS) ID provides two very different =20 > but equally valid solutions, the Path Key Subobject (PKS) solution =20 > and the Private Route Subobject (PRS) solution. This note examines =20 > a number of the advantages and disadvantages of each solution. > > In short: The PKS solution allows a PCE to hide the CPS for an AS =20 > by saving it in a database and replacing it with a key in the ERO. =20 > During the LSP setup, the ingress LSR for that AS must query the =20 > PCE for an expansion. > > The PRS solution allows a CPS for an AS to be hidden by encrypting =20 > it, which may be done by a PCE or by the Head-End LSR. During the =20 > LSP setup, the ingress LSR for that AS must use a decryption key to =20= > obtain the expansion (implying an earlier exchange or configuration). > > The major differences between the mechanisms involve (1) additional =20= > control messages, (2) performance issues expanding those objects, =20 > (3) the addition of state to the PCE, (4) the solution scope (i.e. =20 > applicability to various topologies of each solution.), and (5) the =20= > size of objects added to existing messages. > > (1) Additional Control Message Overhead: > > The PKS solution requires a mechanism to expand the Path Key upon =20 > receipt of the LSP setup request. Since the PCE which calculated =20 > the Path Key might not reside in the entry boundary LSR, the LSR =20 > must request the expansion from the PCE, requiring an additional =20 > message exchange before LSP setup can proceed. The Path Encryption =20 > solution does not require this extra exchange between the PCE and =20 > the ingress node for every LSP. Rather, the decryption key needs to =20= > be exchanged only when it is changed. The result is additional =20 > delay during every LSP setup for the PKS solution but no additional =20= > delay for the PRS solution. > > (2) PCE and LSR Performance: > > The PKS solution must maintain a (temporary) database of keys =20 > adding overhead to the PCE. The PRS solution requires the =20 > encryption of the CPS in the PCE and decryption of the CPS in the =20 > LSR, which could be CPU intensive. Note that in case of a burst of =20 > requests, encryption of large number of CPS may have an impact on =20 > the PCE response time. > > (3) Addition of State in the PCE: > > The PKS solution requires the addition of path-specific state and =20 > maintenance of a database in the PCE. The PRS solution requires no =20 > additional state. > > (4) Solution Scope: > > The PKS and PRS solutions both work well in conjunction with a PCE =20 > to encode and decode the CPS. However the PKS provides no direct =20 > solution without a PCE. This prevents the PKS solution for working =20 > in the case where A's network straddles B's network and where A =20 > wants to use an ERO for a segment of the LSP across the intervening =20= > network, e.g. (netA)-(netB)-(netA). In addition, the PRS could be =20 > used to record a CPS even if the path (and therefore the returned =20 > RRO) crosses multiple boundaries. Finally, a PRS solution could be =20 > adapted to return actual failure locations in PERRs and/or =20 > PATHTEARs, while keeping the failure location confidential from =20 > LSRs without a decryption key. Currently privacy of this source is =20 > maintained by returning the address of border nodes, which can be =20 > very misleading. > > (5) Message Object Overhead: > > The PKS solution provides a very compact key or token to identify a =20= > path segment, which generally allows for smaller EROs to be =20 > returned by the PCE and to be requested in the resulting PATH =20 > message. A PRS which contains a CPS must generally be at least as =20 > large as the unencrypted PATH through the AS and may be =20 > significantly larger if it is desirable to hide the number of hops =20 > within the network from external view by padding the PRS. The =20 > result is potentially larger PATH (and PCEP) messages for the PRS =20 > solution. > > Please note that the tradeoffs listed here are for the current I-D. =20= > Some of the shortcomings of each approach could be mitigated by =20 > implementation-specific optimizations. For example, a PCE could =20 > choose to signal the CPS expansion to the entry boundary LSR, =20 > shifting the burden of maintaining the PKS state to the LSR and =20 > eliminating the performance hit during LSP setup. A similar =20 > exchange could be performed for the PRS case, eliminating the need =20 > for a separate key exchange. These examples of extensions are =20 > beyond the scope of the ID, but might be useful when weighing the =20 > pros and cons of the two solutions. > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > > > --Apple-Mail-19-159039474 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 Hi,

Thanks for your feed-back, = suggesting to go ahead with one solution, the PKS. Indeed, the proposed = optimization could be specified in a further revision (being = optional).

Others, any opinion = ?

Thanks.

JP.

On = Apr 24, 2006, at 2:06 PM, Rich Bradford ((rbradfor)) wrote:

JL,Thanks for the reply. It=92s = always difficult to choose between multiple solutions when there are so = many tradeoffs between the solutions.=A0Regarding the optimization = where the PCE sends the LSR the unsolicited computed path segment. =A0It = was a difficult choice whether or not to include a description of this = in the original draft, since it is more complex. Which aspect of the = optimization seemed most important? Was it that it=92s more efficient = during LSP setup or because it could be used to shift the burden of = maintaining state from the PCE to the LSR?Thanks once again for your = opinion.

Best Regards,

=A0 Rich

From: LE ROUX Jean-Louis = RD-CORE-LAN [mailto:jeanlouis.leroux= @francetelecom.com]
Sent: Friday, April 21, 2006 12:51 PM
Jean Philippe = Vasseur (jvasseur); Rich Bradford (rbradfor)
ccamp@ops.ietf.org; pce@ietf.org
RE: [Pce] = Comparison of Encryption vs. Path Key Solutions for the = CPSID.

Hi JP, = Richard

=A0Please see = inline,

=

=A0

JP Vasseur [mailto:jvasseur@cisco.com] =
jeudi 6 avril = 2006 14:52
Rich = Bradford
ccamp@ops.ietf.org; pce@ietf.org
Re: [Pce] = Comparison of Encryption vs. Path Key Solutions for the = CPSID.

Hi,

=A0

Thanks for the summary Rich.=A0

PCE WG members: thanks to provide your = feedback on whether:

(1) You think that there is a need for such = solution,=A0=A0Yes definitely, = confidentiality is a key requirements in an inter-provider = context.

=A0

(2) You would prefer one solution (which one = and why ?)=A0=A0(3) You think that there is a need for = both=A0=A0Answer to (2) and = (3):

It seems to me that we = should end-up with a single solution so as to=A0ease = interworking.

IMO=A0in an inter-AS MPLS-TE environment without PCEs, the = paths will be loose anyway,=A0so there=A0will not be=A0any = confidentiality issue.

If have some concerns=A0regarding the cost of encryption, = particularly for large paths (we need to think about future P2MP = applications with a large number of hops...). By the way, encryption = approaches are really vulnerable to DoS = attacks.

Hence I=A0would = strongly favor the PKS solution. The optimization suggested,=A0which = consists of sending the computed path segment to the LSR in an = unsolicited manner, just after the computation,=A0sounds relevant and = should be further investigated.=A0Best = Regards,

=A0

JL

=A0

=A0

=A0

=A0

Thanks.

=A0

JP.

On Apr 5, 2006, at 6:19 PM, Rich Bradford = ((rbradfor)) wrote:


Hi,As suggested = in , I=92ve described some of the tradeoffs between the = two solutions described in = draft-rbradfor-ccamp-confidential-segment-00.txt.-- = RichThe = Confidential Path Segment (CPS) ID provides two very different but = equally valid solutions, the Path Key Subobject (PKS) solution and the = Private Route Subobject (PRS) solution. This note examines a number of = the advantages and disadvantages of each solution.In short: The = PKS solution allows a PCE to hide the CPS for an AS by saving it in a = database and replacing it with a key in the ERO. During the LSP setup, = the ingress LSR for that AS must query the PCE for an = expansion.

The PRS = solution allows a CPS for an AS to be hidden by encrypting it, which may = be done by a PCE or by the Head-End LSR. During the LSP setup, the = ingress LSR for that AS must use a decryption key to obtain the = expansion (implying an earlier exchange or configuration).The major = differences between the mechanisms involve (1) additional control = messages, (2) performance issues expanding those objects, (3) the = addition of state to the PCE, (4) the solution scope (i.e. applicability = to various topologies of each solution.), and (5) the size of objects = added to existing messages.

(1) Additional = Control Message Overhead:

The PKS = solution requires a mechanism to expand the Path Key upon receipt of the = LSP setup request. Since the PCE which calculated the Path Key might not = reside in the entry boundary LSR, the LSR must request the expansion = from the PCE, requiring an additional message exchange before LSP setup = can proceed. The Path Encryption solution does not require this extra = exchange between the PCE and the ingress node for every LSP. Rather, the = decryption key needs to be exchanged only when it is changed. The result = is additional delay during every LSP setup for the PKS solution but no = additional delay for the PRS solution.

(2) PCE and = LSR Performance:

The PKS = solution must maintain a (temporary) database of keys adding overhead to = the PCE. The PRS solution requires the encryption of the CPS in the PCE = and decryption of the CPS in the LSR, which could be CPU intensive. Note = that in case of a burst of requests, encryption of large number of CPS = may have an impact on the PCE response time.(3) Addition = of State in the PCE:

The PKS = solution requires the addition of path-specific state and maintenance of = a database in the PCE. The PRS solution requires no additional = state.

(4) Solution = Scope:

The PKS and = PRS solutions both work well in conjunction with a PCE to encode and = decode the CPS. However the PKS provides no direct solution without a = PCE. This prevents the PKS solution for working in the case where A's = network straddles B's network and where A wants to use an ERO for a = segment of the LSP across the intervening network, e.g. = (netA)-(netB)-(netA). In addition, the PRS could be used to record a CPS = even if the path (and therefore the returned RRO) crosses multiple = boundaries. Finally, a PRS solution could be adapted to return actual = failure locations in PERRs and/or PATHTEARs, while keeping the failure = location confidential from LSRs without a decryption key. Currently = privacy of this source is maintained by returning the address of border = nodes, which can be very misleading.

(5) Message = Object Overhead:

The PKS = solution provides a very compact key or token to identify a path = segment, which generally allows for smaller EROs to be returned by the = PCE and to be requested in the resulting PATH message. A PRS which = contains a CPS must generally be at least as large as the unencrypted = PATH through the AS and may be significantly larger if it is desirable = to hide the number of hops within the network from external view by = padding the PRS. The result is potentially larger PATH (and PCEP) = messages for the PRS solution.

Please note = that the tradeoffs listed here are for the current I-D. Some of the = shortcomings of each approach could be mitigated by = implementation-specific optimizations. For example, a PCE could choose = to signal the CPS expansion to the entry boundary LSR, shifting the = burden of maintaining the PKS state to the LSR and eliminating the = performance hit during LSP setup. A similar exchange could be performed = for the PRS case, eliminating the need for a separate key exchange. = These examples of extensions are beyond the scope of the ID, but might = be useful when weighing the pros and cons of the two = solutions.

Pce mailing list


= --Apple-Mail-19-159039474-- From owner-ccamp@ops.ietf.org Tue Apr 25 14:17:11 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYS63-0001dM-3I for ccamp-archive@ietf.org; Tue, 25 Apr 2006 14:17:11 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYS62-00071v-Kw for ccamp-archive@ietf.org; Tue, 25 Apr 2006 14:17:11 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYRy9-0004f9-Rc for ccamp-data@psg.com; Tue, 25 Apr 2006 18:09:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [64.102.122.149] (helo=rtp-iport-2.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYRy7-0004et-0b for ccamp@ops.ietf.org; Tue, 25 Apr 2006 18:08:59 +0000 Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 25 Apr 2006 14:08:59 -0400 X-IronPort-AV: i="4.04,154,1144036800"; d="scan'208"; a="87197619:sNHT35869836" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k3PI8vTL000233; Tue, 25 Apr 2006 14:08:57 -0400 (EDT) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Apr 2006 14:08:57 -0400 Received: from [161.44.71.206] ([161.44.71.206]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Apr 2006 14:08:57 -0400 In-Reply-To: <001901c664db$2e1ff6e0$0500a8c0@jlucianilaptop> References: <001901c664db$2e1ff6e0$0500a8c0@jlucianilaptop> Mime-Version: 1.0 (Apple Message framework v749.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6968853B-77E3-4A7C-A5EC-1655C05EA5B0@cisco.com> Cc: "Adrian Farrel" , , , , Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: MIB Dr. Review for draft-ietf-ccamp-gmpls-te-mib-14.txt Date: Tue, 25 Apr 2006 13:40:23 -0400 To: "" X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 25 Apr 2006 18:08:57.0249 (UTC) FILETIME=[5209C110:01C66893] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 25eb6223a37c19d53ede858176b14339 > Hello Tom and Adrian, > > Here are a few comments on > draft-ietf-ccamp-gmpls-te-mib-14.txt. > Thank you for the great updates. > > Thanks, > -Joan First, removed references to 4201, 4003 and 4420 that were added as per last email from Joan. Things are back to the original state WRT these. > Compiles with both smicngPRO and smilint. > > 1) There is a disconnect in the numbers under the > under gmplsTeGroup, was this intentional, if so, > please explain, otherwise, please correct it. > > 1.3.6.1.2.1.10.166.555.3.1 gmplsTeGroups [GMPLS-TE-STD-MIB]: > oid-value-assignment > 1.3.6.1.2.1.10.166.555.3.1.1 gmplsTunnelGroup [GMPLS-TE-STD-MIB]: > object-group > 1.3.6.1.2.1.10.166.555.3.1.2 gmplsTunnelSignaledGroup [GMPLS-TE- > STD-MIB]: > object-group > 1.3.6.1.2.1.10.166.555.3.1.3 gmplsTunnelScalarGroup [GMPLS-TE-STD- > MIB]: > object-group > 1.3.6.1.2.1.10.166.555.3.1.6 gmplsTunnelOptionalGroup [GMPLS-TE- > STD-MIB]: > object-group > 1.3.6.1.2.1.10.166.555.3.1.7 gmplsTeNotificationGroup [GMPLS-TE- > STD-MIB]: > notification-group > > > 2) Expiration date in the page header is incorrect > Nadeau and Farrel Expires April 2006 [Page 1] > > > 3) 1.1. Migration Strategy > "The gmplsTunnelLSPEncoding may be set to tunnelLspNotGmpls to > allow an > MPLS-TE LSP tunnel to benefit from the additional objects and > tables > of GMPLS-LSR-STD-MIB without supporting the GMPLS protocols. > > Think you mean, GMPLS-TE-STD-MIB in the latter part of the above > sentence. > > > 4) 1.1. Migration Strategy > "Textual conventions are defined in [RFC3811] and [GMPLSTCMIB]." > > There aren't any TCs from GMPLSTCMIB, but there are > from the IANA-GMPLS-TC-MIB, so perhaps adding IANA-GMPLS-TC-MIB to > this > statement would be appropriate. > > > 5) (NIT) 2. Terminology > > "These segment and cross-connect objects are defined in the MPLS > Label > Switch Router MIB (MPLS-LSR-STD-MIB) [RFC3813], but see also the > GMPLS Label Switch Router MIB (GMPLS-LSR-STD-MIB) [GMPLSLSRMIB] > for..." > > Please be sure to use "Label Switching Router" (and not Label Switch > Router). > > > 6) Typos: > gmplsTunnelLinkProtection > > This glag is set to indicate that the LSP should not use any > link layer protection. > > s/glag/flag > > shared > This flage is set to indicate that a shared link layer > > s/flage/flag > > > > 7) gmplsTunnelErrorEntry OBJECT-TYPE > > > The use of the term "discontinuity" implies that the counters > suffered a discontinuity,but the situation you are describing is > that another error occurred. Please rephrase this to something > like: > > "Note that systems which read the objects in this table one at > a time should read gmplsTunnelErrorLastTime prior to the first > object and after reading the last object of this table to > ensure that no additional errors occurred." > > > > 8) gmplsTunnelUnnumIf does not appear in the > ReadOnly Conformance. Fixed all of above. > > 9) I am still unclear about what objects can be supported within > MPLS only. Was expecting to see this clarified in the conformance > statements. There does seem to be more of a division here than > in the GMPLS-LSR-STD-MIB. > > Could some clarification be made to this point? I guess I am confused. I am not sure why we have to explain the reverse relationship. All of the objects herein are for GMPLS only; none apply to MPLS-only TE entries. So the objects that are supported by MPLS-only TE entries should have no corresponding objects in this MIB module. Tabular entries in this MIB represent GMPLS entries only, and they also have corresponding objects in say RFC3812. We also covered this reciprocal relationship in the conformance statement before as part of your previous comments RE: "should we explain each object or explain that they ALL apply." > 10) IANA-GMPLS-TC-MIB > > Would remove parts of the DESCRIPTION clauses which > refer to the GMPLS-TE-STD-MIB module. The reason is > that these TCs may eventually be used in other MIB modules > and since this particular module will be controlled by > IANA, these sort of statements don't appear in IANA > MIB Modules as far as I know. > > "This data type is used as the syntax of the > gmplsTunnelLSPEncoding object in the definition of > GMPLS-TE-STD-MIB's gmplsTunnelTable." > > "This data type is used as the syntax of the > gmplsTunnelSwitchingType object in the definition of > GMPLS-TE-STD-MIB's gmplsTunnelTable." > > "This data type is used as the syntax of the > gmplsTunnelGPid object in the definition of > GMPLS-TE-STD-MIB's gmplsTunnelTable." > > "This data type is used as the syntax of the > gmplsTunnelAdminStatusFlags object in the definition of > GMPLS-TE-STD-MIB's gmplsTunnelTable." > > > -- the end -- Done. I will re-compile/re-format the modules and post them to the ID repository now. Thanks Joan! --Tom From owner-ccamp@ops.ietf.org Tue Apr 25 15:54:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYTbm-0002LB-SW for ccamp-archive@ietf.org; Tue, 25 Apr 2006 15:54:03 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYTbl-0003Vm-Jw for ccamp-archive@ietf.org; Tue, 25 Apr 2006 15:54:02 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYTMR-000AQB-Ny for ccamp-data@psg.com; Tue, 25 Apr 2006 19:38:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.1 Received: from [209.173.53.84] (helo=willow.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYTMO-000APu-QM for ccamp@ops.ietf.org; Tue, 25 Apr 2006 19:38:09 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k3PJc69W018094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 25 Apr 2006 19:38:06 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FYTMM-0003Ru-HB; Tue, 25 Apr 2006 15:38:06 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Subject: Last Call: 'Link Management Protocol (LMP) Management Information Base (MIB)' to Proposed Standard (draft-ietf-ccamp-rfc4327bis) Reply-to: iesg@ietf.org CC: Message-Id: Date: Tue, 25 Apr 2006 15:38:06 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 The IESG has received a request from the Common Control and Measurement Plane WG to consider the following document: - 'Link Management Protocol (LMP) Management Information Base (MIB) ' 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 any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-05-09. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rfc4327bis-01.txt From ssanel@internetyachtclub.com Tue Apr 25 23:29:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYai7-0000VV-IP for ccamp-archive@ietf.org; Tue, 25 Apr 2006 23:29:03 -0400 Received: from [60.220.182.222] (helo=localhost) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FYai5-0004Q3-Fs for ccamp-archive@ietf.org; Tue, 25 Apr 2006 23:29:03 -0400 Message-ID: <000001c6690c$3c5eaf00$0100007f@localhost> From: "Troy Hernandez" To: Subject: Buy OEM Software Date: Wed, 26 Apr 2006 11:41:55 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C6690C.3C5EAF00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 4.2 (++++) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01C6690C.3C5EAF00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Special Offer Adobe Video Collection Adobe Premiere 1.5 Professional Adobe After Effects 6.5 Professional Adobe Audition 1.5 Adobe Encore DVD 1.5 $149.95 More Info >> Microsoft 2 in 1 MS Windows XP Pro MS Office 2003 Pro $99.95 More Info >> Microsoft + Adobe 3 in 1 MS Windows XP Pro MS Office 2003 Pro Adobe Acrobat 7.0 Professional $149.95 More Info >> Bestsellers Microsoft Office Professional Edition 2003 Rating: 6 reviews Retail price: $550.00 You save: $480.05 (87%) Our price: $69.95 [Add to cart] Microsoft Windows XP Professional Rating: 8 reviews Retail price: $200.00 You save: $150.05 (75%) Our price: $49.95 [Add to cart] Adobe Photoshop CS2 V 9.0 Rating: 3 reviews Retail price: $599.00 You save: $529.05 (88%) Our price: $69.95 [Add to cart] ------=_NextPart_000_0001_01C6690C.3C5EAF00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable DS
Special Offer
Adobe Video Collection
  • Adobe Premiere 1.5 Professional
  • Adobe After Effects 6.5 Professional
  • Adobe Audition 1.5
  • Adobe Encore DVD 1.5
$149.95    
More Info >>
Microsoft 2 in 1
  • MS Windows XP Pro
  • MS Office 2003 Pro




$99.95    
More Info >>
Microsoft + Adobe 3 in 1
  • MS Windows XP Pro
  • MS Office 2003 Pro
  • Adobe Acrobat 7.0 Professional


$149.95    
More Info >>
Bestsellers
3D"" Microsoft Office Professional Edition 2003
Rating: 6 reviews
Retail price: $550.00
You save: $480.05 (87%)
Our price: $69.95		  

Add to cart

3D"" Microsoft Windows XP Professional
Rating: 8 reviews
Retail price: $200.00
You save: $150.05 (75%)
Our price: $49.95		  

Add to cart

3D"" Adobe Photoshop CS2 V 9.0
Rating: 3 reviews
Retail price: $599.00
You save: $529.05 (88%)
Our price: $69.95		  

Add to cart

------=_NextPart_000_0001_01C6690C.3C5EAF00-- From owner-ccamp@ops.ietf.org Wed Apr 26 16:06:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYq7v-0008Ed-Gb for ccamp-archive@ietf.org; Wed, 26 Apr 2006 15:56:43 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYq7t-0001Id-TI for ccamp-archive@ietf.org; Wed, 26 Apr 2006 15:56:42 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYq1s-000Prp-1b for ccamp-data@psg.com; Wed, 26 Apr 2006 19:50:28 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO,MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.53.84] (helo=willow.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYq1T-000Pl5-DU for ccamp@ops.ietf.org; Wed, 26 Apr 2006 19:50:03 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by willow.neustar.com (8.12.8/8.12.8) with ESMTP id k3QJo19W003085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Apr 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FYq1R-00076y-Lt; Wed, 26 Apr 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-tc-mib-10.txt Message-Id: Date: Wed, 26 Apr 2006 15:50:01 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management Author(s) : T. Nadeau, A. Farrel Filename : draft-ietf-ccamp-gmpls-tc-mib-10.txt Pages : 9 Date : 2006-4-11 This document defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Generalized Multiprotocol Label Switching (GMPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in GMPLS related MIB modules that would otherwise define their own representations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-tc-mib-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-26120813.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-tc-mib-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-26120813.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Wed Apr 26 16:06:10 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYq7v-0005M7-PF for ccamp-archive@ietf.org; Wed, 26 Apr 2006 15:56:43 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYq7v-0001Ix-22 for ccamp-archive@ietf.org; Wed, 26 Apr 2006 15:56:43 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYq1e-000PoQ-Iz for ccamp-data@psg.com; Wed, 26 Apr 2006 19:50:14 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.57.84] (helo=cypress.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYq1T-000PlE-Vs for ccamp@ops.ietf.org; Wed, 26 Apr 2006 19:50:04 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by cypress.neustar.com (8.12.8/8.12.8) with ESMTP id k3QJo10e018915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Apr 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FYq1R-00077I-OV; Wed, 26 Apr 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-15.txt Message-Id: Date: Wed, 26 Apr 2006 15:50:01 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base Author(s) : T. Nadeau, A. Farrel Filename : draft-ietf-ccamp-gmpls-te-mib-15.txt Pages : 60 Date : 2006-4-26 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Generalized Multiprotocol Label Switching (GMPLS) based traffic engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib-15.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-te-mib-15.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-te-mib-15.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-26121809.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-te-mib-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-te-mib-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-26121809.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ccamp@ops.ietf.org Wed Apr 26 16:13:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYq8H-0001M8-3f for ccamp-archive@ietf.org; Wed, 26 Apr 2006 15:57:05 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYq8G-0001QQ-9F for ccamp-archive@ietf.org; Wed, 26 Apr 2006 15:57:04 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYq1V-000Pmm-LJ for ccamp-data@psg.com; Wed, 26 Apr 2006 19:50:05 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO, MIME_BOUND_NEXTPART,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.173.57.70] (helo=pine.neustar.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYq1U-000Plb-IW for ccamp@ops.ietf.org; Wed, 26 Apr 2006 19:50:04 +0000 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by pine.neustar.com (8.12.8/8.12.8) with ESMTP id k3QJo1vP023371 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 26 Apr 2006 19:50:01 GMT Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1FYq1R-000778-N7; Wed, 26 Apr 2006 15:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-lsr-mib-13.txt Message-Id: Date: Wed, 26 Apr 2006 15:50:01 -0400 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.3 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base Author(s) : T. Nadeau, A. Farrel Filename : draft-ietf-ccamp-gmpls-lsr-mib-13.txt Pages : 43 Date : 2006-4-26 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor a Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-13.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-lsr-mib-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-26121014.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-lsr-mib-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-26121014.I-D@ietf.org> --OtherAccess-- --NextPart-- From asd@yahoo.co.jp Wed Apr 26 23:15:47 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYwyp-0005jG-KR for ccamp-archive@ietf.org; Wed, 26 Apr 2006 23:15:47 -0400 Received: from [221.200.153.169] (helo=ietf.org) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FYwyo-0003oR-EU for ccamp-archive@ietf.org; Wed, 26 Apr 2006 23:15:47 -0400 To: From: =?iso-2022-jp?B?QVNE?= Subject: =?iso-2022-jp?B?GyRCQ2YkQCQ3Okc5YiRHJDkhKhsoQg==?= MIME-Version: 1.0 Reply-To: Content-Type:text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit X-Spam-Score: 2.3 (++) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea $B0BA4F|$OCf$@$7!"4m81F|$O:#EY@8$`!*(B http://golden-getter.com/discharge/ $BLd!K(B gonghexinnian@yahoo.com.cn From owner-ccamp@ops.ietf.org Thu Apr 27 01:45:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYzJl-0001l5-7t for ccamp-archive@ietf.org; Thu, 27 Apr 2006 01:45:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYzJk-0003OH-Sa for ccamp-archive@ietf.org; Thu, 27 Apr 2006 01:45:33 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYzCV-000DBJ-Ub for ccamp-data@psg.com; Thu, 27 Apr 2006 05:38:03 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,DNS_FROM_RFC_ABUSE,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.86.89.70] (helo=elasmtp-banded.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYzCV-000DAx-6Z for ccamp@ops.ietf.org; Thu, 27 Apr 2006 05:38:03 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Me7z6twCJKBRN2a71Lv5cwoO91hGNpl1Hog7k6+pSG4FVxaY3txQQN5XXRhjpFOA; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.238.16] (helo=jlucianilaptop) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1FYzCI-0002Nq-MF; Thu, 27 Apr 2006 01:37:51 -0400 Message-ID: <02e301c66993$ae436840$0500a8c0@jlucianilaptop> From: To: "Thomas D. Nadeau" Cc: "Adrian Farrel" , , , , References: <001901c664db$2e1ff6e0$0500a8c0@jlucianilaptop> <6968853B-77E3-4A7C-A5EC-1655C05EA5B0@cisco.com> Subject: Re: MIB Dr. Review for draft-ietf-ccamp-gmpls-te-mib-14.txt Date: Wed, 26 Apr 2006 20:44:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e265490b84ef470d300cf0a864b3d555d2459387f7b89c61deb1d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.238.16 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Hi Tom, ----- Original Message ----- From: Thomas D. Nadeau To: Cc: Adrian Farrel ; ; ; ; Sent: Tuesday, April 25, 2006 1:40 PM Subject: Re: MIB Dr. Review for draft-ietf-ccamp-gmpls-te-mib-14.txt > > 9) I am still unclear about what objects can be supported within > > MPLS only. Was expecting to see this clarified in the conformance > > statements. There does seem to be more of a division here than > > in the GMPLS-LSR-STD-MIB. > > > > Could some clarification be made to this point? > > I guess I am confused. I am not sure why we have > to explain the reverse relationship. All of the objects herein > are for GMPLS only; none apply to MPLS-only TE entries. > So the objects that are supported by > MPLS-only TE entries should have no corresponding > objects in this MIB module. Tabular entries in this > MIB represent GMPLS entries only, and they also have > corresponding objects in say RFC3812. We also covered this > reciprocal relationship in the conformance statement before > as part of your previous comments RE: "should we > explain each object or explain that they ALL apply." > I was also confused. If there are no MPLS objects then the MIB is fine as is. Thanks, Joan From owner-ccamp@ops.ietf.org Thu Apr 27 01:48:44 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYzMq-00038f-Fe for ccamp-archive@ietf.org; Thu, 27 Apr 2006 01:48:44 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYzMq-0003Th-Dy for ccamp-archive@ietf.org; Thu, 27 Apr 2006 01:48:44 -0400 Received: from psg.com ([147.28.0.62]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FYzLw-0007yY-F2 for ccamp-archive@ietf.org; Thu, 27 Apr 2006 01:47:48 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYzIY-000Di8-Af for ccamp-data@psg.com; Thu, 27 Apr 2006 05:44:18 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,DNS_FROM_RFC_ABUSE,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.86.89.70] (helo=elasmtp-banded.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYzIX-000Dhu-Sw for ccamp@ops.ietf.org; Thu, 27 Apr 2006 05:44:17 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=loWFEBEm50c6UvbYwCbs/wMWJVss3tPl7mWUyK4Zg4kKkgWBEJbhFxBzDEpAucLD; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.238.16] (helo=jlucianilaptop) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1FYzIM-0006H2-CV; Thu, 27 Apr 2006 01:44:06 -0400 Message-ID: <02f301c66994$8daadfe0$0500a8c0@jlucianilaptop> From: To: "Thomas D. Nadeau" Cc: "Adrian Farrel" , , , , References: <001901c664db$2e1ff6e0$0500a8c0@jlucianilaptop> <6968853B-77E3-4A7C-A5EC-1655C05EA5B0@cisco.com> Subject: MIB Dr. Review for draft-ietf-ccamp-gmpls-tc-mib-10.txt Date: Wed, 26 Apr 2006 20:50:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e265490b84ef470d300cf0a7f87e7619bd3d59072ae4777b98cc8350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.238.16 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Hi Tom, draft-ietf-ccamp-gmpls-tc-mib-10.txt same comment as before wrt the expiration date (this is the same draft that was there prior, so if you submit a new one, please bump the draft number -- if you prefer to leave the fix to the RFC editor that is fine also). Thanks, -Joan From owner-ccamp@ops.ietf.org Thu Apr 27 01:49:28 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYzNX-0003Bb-IG for ccamp-archive@ietf.org; Thu, 27 Apr 2006 01:49:28 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYzNX-0003WK-Ag for ccamp-archive@ietf.org; Thu, 27 Apr 2006 01:49:27 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYzGz-000DXj-RO for ccamp-data@psg.com; Thu, 27 Apr 2006 05:42:41 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,DNS_FROM_RFC_ABUSE,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.86.89.70] (helo=elasmtp-banded.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYzGz-000DXW-Ai for ccamp@ops.ietf.org; Thu, 27 Apr 2006 05:42:41 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=apYXK8Y9cNTsspSQJTXAG0bABANK2tMJyp1/0j0e5eGhcDqVTtbswu3YI+78zK2d; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.238.16] (helo=jlucianilaptop) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1FYzGp-0005Ke-6M; Thu, 27 Apr 2006 01:42:31 -0400 Message-ID: <02ef01c66994$5518c200$0500a8c0@jlucianilaptop> From: To: "Thomas D. Nadeau" Cc: "Adrian Farrel" , , , , References: <001901c664db$2e1ff6e0$0500a8c0@jlucianilaptop> <6968853B-77E3-4A7C-A5EC-1655C05EA5B0@cisco.com> Subject: MIB Dr. Review for draft-ietf-ccamp-gmpls-te-mib-15.txt Date: Wed, 26 Apr 2006 20:48:41 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e265490b84ef470d300cf38bc450f47817b7a0cdf93a589ab4c3c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.238.16 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Look great! Thanks, -Joan From owner-ccamp@ops.ietf.org Thu Apr 27 01:50:20 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FYzOO-0003Cm-ON for ccamp-archive@ietf.org; Thu, 27 Apr 2006 01:50:20 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FYzOO-0003a9-Fm for ccamp-archive@ietf.org; Thu, 27 Apr 2006 01:50:20 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYzFm-000DQ5-5k for ccamp-data@psg.com; Thu, 27 Apr 2006 05:41:26 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=AWL,BAYES_00, DATE_IN_PAST_03_06,DNS_FROM_RFC_ABUSE,NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.86.89.70] (helo=elasmtp-banded.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FYzFl-000DPr-Mn for ccamp@ops.ietf.org; Thu, 27 Apr 2006 05:41:25 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=fcCTFaeOVGRfbOvmmN1+x3NTxr1kYlNjqnIq1FKzYNwiFI2bamXvV/yhift7PlVu; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Received: from [68.166.238.16] (helo=jlucianilaptop) by elasmtp-banded.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1FYzFb-0004Sp-JM; Thu, 27 Apr 2006 01:41:15 -0400 Message-ID: <02e901c66994$282dbc00$0500a8c0@jlucianilaptop> From: To: "Thomas D. Nadeau" Cc: "Adrian Farrel" , , , , References: <001901c664db$2e1ff6e0$0500a8c0@jlucianilaptop> <6968853B-77E3-4A7C-A5EC-1655C05EA5B0@cisco.com> Subject: MIB Dr. review for draft-ietf-ccamp-gmpls-lsr-mib-13.txt Date: Wed, 26 Apr 2006 20:47:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e265490b84ef470d300cf96d5a6b8de2587955bff31af8927e75a350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 68.166.238.16 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Hello Tom and Adrian, All MIBs compile with smilint and smicngPRO. Here are my few comments: draft-ietf-ccamp-gmpls-lsr-mib-13.txt (#1 should be taken care of the others are NITs and could probably be fixed by RFC Editor if you so choose.) 1) Think this was probably a place holder...but please just remove this: OBJECT gmplsLabelRowStatus SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "TDN QUestion" 2) NIT January 2003; " Please change this to: January 2003." 3) Informative References NIT: Change the order so references are in ascending order: Current order is: [RFC3472] [RFC3468] change to: [RFC3468] [RFC3472] NIT: Fix reference: Current: [RFC3468] Andersson, L., Swallow, G., "The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols", RFC 3468, February 2003. Should be: [RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label -- end -- From owner-ccamp@ops.ietf.org Thu Apr 27 09:36:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ6fZ-0007es-J4 for ccamp-archive@ietf.org; Thu, 27 Apr 2006 09:36:33 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ6fY-0005Lo-23 for ccamp-archive@ietf.org; Thu, 27 Apr 2006 09:36:33 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FZ6Qv-0001wH-2c for ccamp-data@psg.com; Thu, 27 Apr 2006 13:21:25 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_MESSAGE autolearn=no version=3.1.1 Received: from [195.101.245.15] (helo=p-mail1.rd.francetelecom.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FZ6Qs-0001vw-5Z for ccamp@ops.ietf.org; Thu, 27 Apr 2006 13:21:23 +0000 Received: from ftrdmel1.rd.francetelecom.fr ([10.193.117.152]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Apr 2006 15:21:15 +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_01C669FD.758FF101" Subject: RE: [Pce] Comparison of Encryption vs. Path Key Solutions for the CPSID. Date: Thu, 27 Apr 2006 15:21:17 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Pce] Comparison of Encryption vs. Path Key Solutions for the CPSID. Thread-Index: AcZZeTyqrqoHE6qtR3mCIGZZDDyHhAL5DdwgAJosi6AAi6EtcA== From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Rich Bradford \(rbradfor\)" , "Jean Philippe Vasseur \(jvasseur\)" Cc: , X-OriginalArrivalTime: 27 Apr 2006 13:21:15.0187 (UTC) FILETIME=[75DFA030:01C669FD] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: d0fac514cb168268a385dddd1f66d312 This is a multi-part message in MIME format. ------_=_NextPart_001_01C669FD.758FF101 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Richard, =20 Please see inline, ________________________________ De : Rich Bradford (rbradfor) [mailto:rbradfor@cisco.com]=20 Envoy=E9 : lundi 24 avril 2006 20:06 =C0 : LE ROUX Jean-Louis RD-CORE-LAN; Jean Philippe Vasseur (jvasseur) Cc : ccamp@ops.ietf.org; pce@ietf.org Objet : RE: [Pce] Comparison of Encryption vs. Path Key Solutions for = the CPSID. =09 =09 JL, Thanks for the reply. It's always difficult to choose between multiple = solutions when there are so many tradeoffs between the solutions. =20 =20 Regarding the optimization where the PCE sends the LSR the unsolicited = computed path segment. It was a difficult choice whether or not to = include a description of this in the original draft, since it is more = complex. Which aspect of the optimization seemed most important? Was it = that it's more efficient during LSP setup or because it could be used to = shift the burden of maintaining state from the PCE to the LSR?=20 =20 IMO the most important optimization is the gain in LSP setup time, = which may be significant, and this is of particular =20 importance during end-to-end LSP restoration upon failure. Let's assume an inter-AS path computation with an AS-path length =3D N: -Without this optimization the LSP signaling time would be N* = Intra-AS-RSVP-sig + N* LSR-PCE exchanges. -With this optimization the LSP signaling time would be N* = Intra-AS-RSVP-sig Hence the gain in signaling time is N*LSR-PCE exchanges. And the good thing is that the path computation time would not be = impacted at all by this procedure as the PCE-LSR unsolicited = notification is done in // with the BRPC procedure. =20 There may be one minor con: During the BRPC you don't know a priori = which path segment will finally be selected, hence you need to send the = path segment to all ASBR LSRs connected to the upstream AS...but this is = a minor issue, because there are not so many ASBRs connected to the = upstream AS (two or three). You will have to remove the information on = the ASBR if no Path message is received after the expiration of a = timer... =20 Regards, =20 JL =20 =20 =20 =20 =20 =20 =20 =20 Thanks once again for your opinion.=20 Best Regards, Rich =20 =09 ________________________________ From: LE ROUX Jean-Louis RD-CORE-LAN = [mailto:jeanlouis.leroux@francetelecom.com]=20 Sent: Friday, April 21, 2006 12:51 PM To: Jean Philippe Vasseur (jvasseur); Rich Bradford (rbradfor) Cc: ccamp@ops.ietf.org; pce@ietf.org Subject: RE: [Pce] Comparison of Encryption vs. Path Key Solutions for = the CPSID. =20 Hi JP, Richard =20 Please see inline, =20 =09 ________________________________ De : JP Vasseur [mailto:jvasseur@cisco.com]=20 Envoy=E9 : jeudi 6 avril 2006 14:52 =C0 : Rich Bradford Cc : ccamp@ops.ietf.org; pce@ietf.org Objet : Re: [Pce] Comparison of Encryption vs. Path Key Solutions for = the CPSID. Hi,=20 =20 Thanks for the summary Rich. =20 PCE WG members: thanks to provide your feedback on whether: (1) You think that there is a need for such solution,=20 =20 Yes definitely, confidentiality is a key requirements in an = inter-provider context. =20 (2) You would prefer one solution (which one and why ?)=20 =20 (3) You think that there is a need for both=20 =20 Answer to (2) and (3): It seems to me that we should end-up with a single solution so as to = ease interworking. IMO in an inter-AS MPLS-TE environment without PCEs, the paths will be = loose anyway, so there will not be any confidentiality issue.=20 If have some concerns regarding the cost of encryption, particularly = for large paths (we need to think about future P2MP applications with a = large number of hops...). By the way, encryption approaches are really = vulnerable to DoS attacks. Hence I would strongly favor the PKS solution. The optimization = suggested, which consists of sending the computed path segment to the = LSR in an unsolicited manner, just after the computation, sounds = relevant and should be further investigated. =20 Best Regards, =20 JL =20 =20 =20 =20 Thanks. =20 JP. =20 On Apr 5, 2006, at 6:19 PM, Rich Bradford ((rbradfor)) wrote: =09 =09 =09 Hi, As suggested in Dallas, I've described some of the tradeoffs between = the two solutions described in = draft-rbradfor-ccamp-confidential-segment-00.txt. -- Rich The Confidential Path Segment (CPS) ID provides two very different but = equally valid solutions, the Path Key Subobject (PKS) solution and the = Private Route Subobject (PRS) solution. This note examines a number of = the advantages and disadvantages of each solution.=20 In short: The PKS solution allows a PCE to hide the CPS for an AS by = saving it in a database and replacing it with a key in the ERO. During = the LSP setup, the ingress LSR for that AS must query the PCE for an = expansion. The PRS solution allows a CPS for an AS to be hidden by encrypting it, = which may be done by a PCE or by the Head-End LSR. During the LSP setup, = the ingress LSR for that AS must use a decryption key to obtain the = expansion (implying an earlier exchange or configuration).=20 The major differences between the mechanisms involve (1) additional = control messages, (2) performance issues expanding those objects, (3) = the addition of state to the PCE, (4) the solution scope (i.e. = applicability to various topologies of each solution.), and (5) the size = of objects added to existing messages. (1) Additional Control Message Overhead: The PKS solution requires a mechanism to expand the Path Key upon = receipt of the LSP setup request. Since the PCE which calculated the = Path Key might not reside in the entry boundary LSR, the LSR must = request the expansion from the PCE, requiring an additional message = exchange before LSP setup can proceed. The Path Encryption solution does = not require this extra exchange between the PCE and the ingress node for = every LSP. Rather, the decryption key needs to be exchanged only when it = is changed. The result is additional delay during every LSP setup for = the PKS solution but no additional delay for the PRS solution. (2) PCE and LSR Performance: The PKS solution must maintain a (temporary) database of keys adding = overhead to the PCE. The PRS solution requires the encryption of the CPS = in the PCE and decryption of the CPS in the LSR, which could be CPU = intensive. Note that in case of a burst of requests, encryption of large = number of CPS may have an impact on the PCE response time. (3) Addition of State in the PCE: The PKS solution requires the addition of path-specific state and = maintenance of a database in the PCE. The PRS solution requires no = additional state. (4) Solution Scope: The PKS and PRS solutions both work well in conjunction with a PCE to = encode and decode the CPS. However the PKS provides no direct solution = without a PCE. This prevents the PKS solution for working in the case = where A's network straddles B's network and where A wants to use an ERO = for a segment of the LSP across the intervening network, e.g. = (netA)-(netB)-(netA). In addition, the PRS could be used to record a CPS = even if the path (and therefore the returned RRO) crosses multiple = boundaries. Finally, a PRS solution could be adapted to return actual = failure locations in PERRs and/or PATHTEARs, while keeping the failure = location confidential from LSRs without a decryption key. Currently = privacy of this source is maintained by returning the address of border = nodes, which can be very misleading. (5) Message Object Overhead: The PKS solution provides a very compact key or token to identify a = path segment, which generally allows for smaller EROs to be returned by = the PCE and to be requested in the resulting PATH message. A PRS which = contains a CPS must generally be at least as large as the unencrypted = PATH through the AS and may be significantly larger if it is desirable = to hide the number of hops within the network from external view by = padding the PRS. The result is potentially larger PATH (and PCEP) = messages for the PRS solution. Please note that the tradeoffs listed here are for the current I-D. = Some of the shortcomings of each approach could be mitigated by = implementation-specific optimizations. For example, a PCE could choose = to signal the CPS expansion to the entry boundary LSR, shifting the = burden of maintaining the PKS state to the LSR and eliminating the = performance hit during LSP setup. A similar exchange could be performed = for the PRS case, eliminating the need for a separate key exchange. = These examples of extensions are beyond the scope of the ID, but might = be useful when weighing the pros and cons of the two solutions. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce =20 ------_=_NextPart_001_01C669FD.758FF101 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Richard,
 
Please see inline,

De : Rich Bradford (rbradfor) = [mailto:rbradfor@cisco.com]
Envoy=E9 : lundi 24 avril = 2006=20 20:06
=C0 : LE ROUX Jean-Louis RD-CORE-LAN; Jean = Philippe Vasseur=20 (jvasseur)
Cc : ccamp@ops.ietf.org;=20 pce@ietf.org
Objet : RE: [Pce] Comparison of Encryption = vs.=20 Path Key Solutions for the CPSID.

JL,

Thanks=20 for the reply. It=92s always difficult to choose between multiple = solutions when=20 there are so many tradeoffs between the solutions. =20

 

Regarding = the=20 optimization where the PCE sends the LSR the unsolicited computed path = segment.  It was a difficult choice whether or not to include a=20 description of this in the original draft, since it is more complex. = Which=20 aspect of the optimization seemed most important? Was it that it=92s = more=20 efficient during LSP setup or because it could be used to shift the = burden of=20 maintaining state from the PCE to the LSR? 

 

IMO the most important = optimization=20 is the gain in LSP setup time, which may be significant, and = this is=20 of particular 

importance during end-to-end = LSP=20 restoration upon failure.

Let's assume an inter-AS = path=20 computation with an AS-path length =3D = N:

-Without this optimization = the LSP=20 signaling time would be N* Intra-AS-RSVP-sig + N* LSR-PCE=20 exchanges.

-With this optimization the = LSP=20 signaling time would be N* = Intra-AS-RSVP-sig

Hence the gain in signaling = time is=20 N*LSR-PCE exchanges.

And the good thing = is that the=20 path computation time would not be impacted at all by this = procedure as=20 the PCE-LSR unsolicited notification is done in // with the BRPC=20 procedure.

 

There may be one minor con:=20 During the BRPC you don't = know a priori=20 which path segment will finally be selected, hence you need to send = the path=20 segment to all ASBR LSRs connected to the upstream AS...but = this is=20 a minor issue, because there are not so many ASBRs connected to the = upstream=20 AS (two or three). You will have to remove the information = on the=20 ASBR if no Path message is received after the expiration of a=20 timer...

 

Regards,

 

JL

 

 

 

 

 

 

 

 <= /P>

Thanks=20 once again for your opinion.

Best=20 Regards,

 =20 Rich

 

From:=20 LE ROUX Jean-Louis=20 RD-CORE-LAN=20 [mailto:jeanlouis.leroux@francetelecom.com]
Sent: Friday, April 21, 2006 = 12:51=20 PM
To: Jean = Philippe Vasseur=20 (jvasseur); Rich Bradford (rbradfor)
Cc: ccamp@ops.ietf.org;=20 pce@ietf.org
Subject: RE:=20 [Pce] Comparison of Encryption vs. Path Key Solutions for the=20 CPSID.

 

Hi JP,=20 Richard

 

Please see=20 inline,

 

De : JP Vasseur=20 [mailto:jvasseur@cisco.com]
Envoy=E9 : jeudi 6 avril = 2006=20 14:52
=C0 : = Rich=20 Bradford
Cc :=20 ccamp@ops.ietf.org; pce@ietf.org
Objet : Re: [Pce] = Comparison of=20 Encryption vs. Path Key Solutions for the CPSID.

Hi,

 

Thanks for the summary=20 Rich.

 

PCE WG members: thanks to provide your = feedback on=20 whether:

(1) You think that there is a need for = such=20 solution, 

 

Yes = definitely,=20 confidentiality is a key requirements in an inter-provider=20 context.

 

(2) You would prefer one solution (which = one and why=20 ?) 

 

(3) You think that there is a need for=20 both 

 

Answer to = (2) and=20 (3):

It seems = to me that=20 we should end-up with a single solution so as to ease=20 interworking.

IMO in an=20 inter-AS MPLS-TE environment without PCEs, the paths will be loose=20 anyway, so there will not be any confidentiality = issue.=20

If have = some=20 concerns regarding the cost of encryption, particularly for = large paths=20 (we need to think about future P2MP applications with a large number = of=20 hops...). By the way, encryption approaches are really vulnerable to = DoS=20 attacks.

Hence = I would=20 strongly favor the PKS solution. The optimization = suggested, which=20 consists of sending the computed path segment to the LSR in an = unsolicited=20 manner, just after the computation, sounds relevant and should = be=20 further investigated.

 

Best=20 Regards,

 

JL

 

 

 

 

Thanks.

 

JP.

 

On Apr 5, 2006, at 6:19 PM, Rich Bradford=20 ((rbradfor)) wrote:



Hi,

As = suggested in=20 Dallas, = I=92ve=20 described some of the tradeoffs between the two solutions described = in=20 = draft-rbradfor-ccamp-confidential-segment-00.txt.

-- = Rich

The=20 Confidential Path Segment (CPS) ID provides two very different but = equally=20 valid solutions, the Path Key Subobject (PKS) solution and the = Private Route=20 Subobject (PRS) solution. This note examines a number of the = advantages and=20 disadvantages of each solution. =

In=20 short: The PKS solution allows a PCE to hide the CPS for an AS by = saving it=20 in a database and replacing it with a key in the ERO. During the LSP = setup,=20 the ingress LSR for that AS must query the PCE for an=20 expansion.

The PRS solution=20 allows a CPS for an AS to be hidden by encrypting it, which may be = done by a=20 PCE or by the Head-End LSR. During the LSP setup, the ingress LSR = for that=20 AS must use a decryption key to obtain the expansion (implying an = earlier=20 exchange or configuration).

The=20 major differences between the mechanisms involve (1) additional = control=20 messages, (2) performance issues expanding those objects, (3) the = addition=20 of state to the PCE, (4) the solution scope (i.e. applicability to = various=20 topologies of each solution.), and (5) the size of objects added to = existing=20 messages.

(1)=20 Additional Control Message = Overhead:

The PKS solution=20 requires a mechanism to expand the Path Key upon receipt of the LSP = setup=20 request. Since the PCE which calculated the Path Key might not = reside in the=20 entry boundary LSR, the LSR must request the expansion from the PCE, = requiring an additional message exchange before LSP setup can = proceed. The=20 Path Encryption solution does not require this extra exchange = between the=20 PCE and the ingress node for every LSP. Rather, the decryption key = needs to=20 be exchanged only when it is changed. The result is additional delay = during=20 every LSP setup for the PKS solution but no additional delay for the = PRS=20 solution.

(2) PCE and LSR=20 Performance:

The PKS solution=20 must maintain a (temporary) database of keys adding overhead to the = PCE. The=20 PRS solution requires the encryption of the CPS in the PCE and = decryption of=20 the CPS in the LSR, which could be CPU intensive. Note that in case = of a=20 burst of requests, encryption of large number of CPS may have an = impact on=20 the PCE response time.

(3)=20 Addition of State in the = PCE:

The PKS solution=20 requires the addition of path-specific state and maintenance of a = database=20 in the PCE. The PRS solution requires no additional=20 state.

(4) Solution=20 Scope:

The PKS and PRS=20 solutions both work well in conjunction with a PCE to encode and = decode the=20 CPS. However the PKS provides no direct solution without a PCE. This = prevents the PKS solution for working in the case where A's network=20 straddles B's network and where A wants to use an ERO for a segment = of the=20 LSP across the intervening network, e.g. (netA)-(netB)-(netA). In = addition,=20 the PRS could be used to record a CPS even if the path (and = therefore the=20 returned RRO) crosses multiple boundaries. Finally, a PRS solution = could be=20 adapted to return actual failure locations in PERRs and/or = PATHTEARs, while=20 keeping the failure location confidential from LSRs without a = decryption=20 key. Currently privacy of this source is maintained by returning the = address=20 of border nodes, which can be very=20 misleading.

(5)=20 Message Object Overhead:

The PKS solution=20 provides a very compact key or token to identify a path segment, = which=20 generally allows for smaller EROs to be returned by the PCE and to = be=20 requested in the resulting PATH message. A PRS which contains a CPS = must=20 generally be at least as large as the unencrypted PATH through the = AS and=20 may be significantly larger if it is desirable to hide the number of = hops=20 within the network from external view by padding the PRS. The result = is=20 potentially larger PATH (and PCEP) messages for the PRS=20 solution.

Please note that the = tradeoffs=20 listed here are for the current I-D. Some of the shortcomings of = each=20 approach could be mitigated by implementation-specific = optimizations. For=20 example, a PCE could choose to signal the CPS expansion to the entry = boundary LSR, shifting the burden of maintaining the PKS state to = the LSR=20 and eliminating the performance hit during LSP setup. A similar = exchange=20 could be performed for the PRS case, eliminating the need for a = separate key=20 exchange. These examples of extensions are beyond the scope of the = ID, but=20 might be useful when weighing the pros and cons of the two=20 solutions.

___________= ____________________________________

Pce mailing = list

Pce@lists.ietf.org

https://www1.ietf.org= /mailman/listinfo/pce

 

<= /BLOCKQUOTE> ------_=_NextPart_001_01C669FD.758FF101-- From owner-ccamp@ops.ietf.org Thu Apr 27 09:42:27 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ6lH-0001PG-6O for ccamp-archive@ietf.org; Thu, 27 Apr 2006 09:42:27 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ6lF-0005bJ-5T for ccamp-archive@ietf.org; Thu, 27 Apr 2006 09:42:27 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FZ6VX-0002Jp-V9 for ccamp-data@psg.com; Thu, 27 Apr 2006 13:26:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS autolearn=no version=3.1.1 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FZ6VS-0002JU-Hg for ccamp@ops.ietf.org; Thu, 27 Apr 2006 13:26:10 +0000 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 27 Apr 2006 06:26:05 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,161,1144047600"; d="scan'208,217"; a="26811744:sNHT74531850" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3RDQ3vF007607; Thu, 27 Apr 2006 09:26:04 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Apr 2006 09:26:04 -0400 Received: from [10.86.104.178] ([10.86.104.178]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Apr 2006 09:26:00 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: multipart/alternative; boundary=Apple-Mail-53-333433759 Message-Id: <4CA3EE07-6890-452C-AE6B-BD8EA4128412@cisco.com> Cc: "Rich Bradford \(rbradfor\)" , , From: JP Vasseur Subject: Re: [Pce] Comparison of Encryption vs. Path Key Solutions for the CPSID. Date: Thu, 27 Apr 2006 09:25:58 -0400 To: "LE ROUX Jean-Louis RD-CORE-LAN" X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 27 Apr 2006 13:26:00.0225 (UTC) FILETIME=[1FC4F910:01C669FE] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.1 (/) X-Scan-Signature: 3eec21359cc773323f0aab45cb0596af --Apple-Mail-53-333433759 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Hi Jean-Louis, On Apr 27, 2006, at 9:21 AM, LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi Richard, > > Please see inline, > > De : Rich Bradford (rbradfor) [mailto:rbradfor@cisco.com] > Envoy=E9 : lundi 24 avril 2006 20:06 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN; Jean Philippe Vasseur (jvasseur) > Cc : ccamp@ops.ietf.org; pce@ietf.org > Objet : RE: [Pce] Comparison of Encryption vs. Path Key Solutions =20 > for the CPSID. > > JL, > > Thanks for the reply. It=92s always difficult to choose between =20 > multiple solutions when there are so many tradeoffs between the =20 > solutions. > > > > Regarding the optimization where the PCE sends the LSR the =20 > unsolicited computed path segment. It was a difficult choice =20 > whether or not to include a description of this in the original =20 > draft, since it is more complex. Which aspect of the optimization =20 > seemed most important? Was it that it=92s more efficient during LSP =20= > setup or because it could be used to shift the burden of =20 > maintaining state from the PCE to the LSR? > > > IMO the most important optimization is the gain in LSP setup time, =20 > which may be significant, and this is of particular > > importance during end-to-end LSP restoration upon failure. > > Let's assume an inter-AS path computation with an AS-path length =3D = N: > > -Without this optimization the LSP signaling time would be N* Intra-=20= > AS-RSVP-sig + N* LSR-PCE exchanges. > > -With this optimization the LSP signaling time would be N* Intra-AS-=20= > RSVP-sig > > Hence the gain in signaling time is N*LSR-PCE exchanges. > > And the good thing is that the path computation time would not be =20 > impacted at all by this procedure as the PCE-LSR unsolicited =20 > notification is done in // with the BRPC procedure. > > > There may be one minor con: During the BRPC you don't know a priori =20= > which path segment will finally be selected, hence you need to send =20= > the path segment to all ASBR LSRs connected to the upstream =20 > AS...but this is a minor issue, because there are not so many ASBRs =20= > connected to the upstream AS (two or three). You will have to =20 > remove the information on the ASBR if no Path message is received =20 > after the expiration of a timer... Agree, this is a temporary state ... that would have been maintained =20 by the PCE anyway. Cheers. JP. > > Regards, > > > JL > > > > > > > > > > > Thanks once again for your opinion. > > Best Regards, > > Rich > > > > From: LE ROUX Jean-Louis RD-CORE-LAN =20 > [mailto:jeanlouis.leroux@francetelecom.com] > Sent: Friday, April 21, 2006 12:51 PM > To: Jean Philippe Vasseur (jvasseur); Rich Bradford (rbradfor) > Cc: ccamp@ops.ietf.org; pce@ietf.org > Subject: RE: [Pce] Comparison of Encryption vs. Path Key Solutions =20 > for the CPSID. > > > > Hi JP, Richard > > > > Please see inline, > > > > De : JP Vasseur [mailto:jvasseur@cisco.com] > Envoy=E9 : jeudi 6 avril 2006 14:52 > =C0 : Rich Bradford > Cc : ccamp@ops.ietf.org; pce@ietf.org > Objet : Re: [Pce] Comparison of Encryption vs. Path Key Solutions =20 > for the CPSID. > > Hi, > > > > Thanks for the summary Rich. > > > > PCE WG members: thanks to provide your feedback on whether: > > (1) You think that there is a need for such solution, > > > > Yes definitely, confidentiality is a key requirements in an inter-=20 > provider context. > > > > (2) You would prefer one solution (which one and why ?) > > > > (3) You think that there is a need for both > > > > Answer to (2) and (3): > > It seems to me that we should end-up with a single solution so as =20 > to ease interworking. > > IMO in an inter-AS MPLS-TE environment without PCEs, the paths will =20= > be loose anyway, so there will not be any confidentiality issue. > > If have some concerns regarding the cost of encryption, =20 > particularly for large paths (we need to think about future P2MP =20 > applications with a large number of hops...). By the way, =20 > encryption approaches are really vulnerable to DoS attacks. > > Hence I would strongly favor the PKS solution. The optimization =20 > suggested, which consists of sending the computed path segment to =20 > the LSR in an unsolicited manner, just after the computation, =20 > sounds relevant and should be further investigated. > > > > Best Regards, > > > > JL > > > > > > > > > > Thanks. > > > > JP. > > > > On Apr 5, 2006, at 6:19 PM, Rich Bradford ((rbradfor)) wrote: > > > > > Hi, > > As suggested in Dallas, I=92ve described some of the tradeoffs =20 > between the two solutions described in draft-rbradfor-ccamp-=20 > confidential-segment-00.txt. > > -- Rich > > The Confidential Path Segment (CPS) ID provides two very different =20 > but equally valid solutions, the Path Key Subobject (PKS) solution =20 > and the Private Route Subobject (PRS) solution. This note examines =20 > a number of the advantages and disadvantages of each solution. > > In short: The PKS solution allows a PCE to hide the CPS for an AS =20 > by saving it in a database and replacing it with a key in the ERO. =20 > During the LSP setup, the ingress LSR for that AS must query the =20 > PCE for an expansion. > > The PRS solution allows a CPS for an AS to be hidden by encrypting =20 > it, which may be done by a PCE or by the Head-End LSR. During the =20 > LSP setup, the ingress LSR for that AS must use a decryption key to =20= > obtain the expansion (implying an earlier exchange or configuration). > > The major differences between the mechanisms involve (1) additional =20= > control messages, (2) performance issues expanding those objects, =20 > (3) the addition of state to the PCE, (4) the solution scope (i.e. =20 > applicability to various topologies of each solution.), and (5) the =20= > size of objects added to existing messages. > > (1) Additional Control Message Overhead: > > The PKS solution requires a mechanism to expand the Path Key upon =20 > receipt of the LSP setup request. Since the PCE which calculated =20 > the Path Key might not reside in the entry boundary LSR, the LSR =20 > must request the expansion from the PCE, requiring an additional =20 > message exchange before LSP setup can proceed. The Path Encryption =20 > solution does not require this extra exchange between the PCE and =20 > the ingress node for every LSP. Rather, the decryption key needs to =20= > be exchanged only when it is changed. The result is additional =20 > delay during every LSP setup for the PKS solution but no additional =20= > delay for the PRS solution. > > (2) PCE and LSR Performance: > > The PKS solution must maintain a (temporary) database of keys =20 > adding overhead to the PCE. The PRS solution requires the =20 > encryption of the CPS in the PCE and decryption of the CPS in the =20 > LSR, which could be CPU intensive. Note that in case of a burst of =20 > requests, encryption of large number of CPS may have an impact on =20 > the PCE response time. > > (3) Addition of State in the PCE: > > The PKS solution requires the addition of path-specific state and =20 > maintenance of a database in the PCE. The PRS solution requires no =20 > additional state. > > (4) Solution Scope: > > The PKS and PRS solutions both work well in conjunction with a PCE =20 > to encode and decode the CPS. However the PKS provides no direct =20 > solution without a PCE. This prevents the PKS solution for working =20 > in the case where A's network straddles B's network and where A =20 > wants to use an ERO for a segment of the LSP across the intervening =20= > network, e.g. (netA)-(netB)-(netA). In addition, the PRS could be =20 > used to record a CPS even if the path (and therefore the returned =20 > RRO) crosses multiple boundaries. Finally, a PRS solution could be =20 > adapted to return actual failure locations in PERRs and/or =20 > PATHTEARs, while keeping the failure location confidential from =20 > LSRs without a decryption key. Currently privacy of this source is =20 > maintained by returning the address of border nodes, which can be =20 > very misleading. > > (5) Message Object Overhead: > > The PKS solution provides a very compact key or token to identify a =20= > path segment, which generally allows for smaller EROs to be =20 > returned by the PCE and to be requested in the resulting PATH =20 > message. A PRS which contains a CPS must generally be at least as =20 > large as the unencrypted PATH through the AS and may be =20 > significantly larger if it is desirable to hide the number of hops =20 > within the network from external view by padding the PRS. The =20 > result is potentially larger PATH (and PCEP) messages for the PRS =20 > solution. > > Please note that the tradeoffs listed here are for the current I-D. =20= > Some of the shortcomings of each approach could be mitigated by =20 > implementation-specific optimizations. For example, a PCE could =20 > choose to signal the CPS expansion to the entry boundary LSR, =20 > shifting the burden of maintaining the PKS state to the LSR and =20 > eliminating the performance hit during LSP setup. A similar =20 > exchange could be performed for the PRS case, eliminating the need =20 > for a separate key exchange. These examples of extensions are =20 > beyond the scope of the ID, but might be useful when weighing the =20 > pros and cons of the two solutions. > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > > > --Apple-Mail-53-333433759 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 Hi = Jean-Louis,

On Apr 27, 2006, at 9:21 AM, LE ROUX = Jean-Louis RD-CORE-LAN wrote:

Rich Bradford = (rbradfor) [mailto:rbradfor@cisco.com] =
lundi 24 avril 2006 20:06
=C0=A0: LE ROUX Jean-Louis RD-CORE-LAN; = Jean Philippe Vasseur (jvasseur)
ccamp@ops.ietf.org; pce@ietf.org
RE: [Pce] Comparison of Encryption vs. Path Key = Solutions for the CPSID.

JL,

Thanks for the = reply. It=92s always difficult to choose between multiple solutions when = there are so many tradeoffs between the solutions.=A0

=A0

IMO=A0the most important optimization is the gain in = LSP setup time, which=A0may be=A0significant, and this is of = particular=A0

importance during end-to-end LSP restoration upon = failure.

Let's assume an inter-AS path computation with an = AS-path length =3D N:

-Without this = optimization the LSP signaling time would be N* Intra-AS-RSVP-sig + N* = LSR-PCE exchanges.

-With this optimization = the LSP signaling time would be N* = Intra-AS-RSVP-sig

Hence the gain in = signaling time is N*LSR-PCE = exchanges.

And=A0the good thing is=A0that the path computation = time=A0would not be impacted at all by this procedure as the PCE-LSR = unsolicited notification is done in // with the BRPC = procedure.

=A0

There may be one minor con: = During the BRPC you don't = know a priori which path segment will finally be selected, hence you = need to send the path segment=A0to all ASBR LSRs=A0connected to the = upstream AS...but this is a minor issue, because there are not so many = ASBRs connected to the upstream AS (two or three).=A0You will have = to=A0remove the information on the ASBR=A0if no Path message is received = after the expiration of a = timer...

<= /BLOCKQUOTE>Agree, this is a temporary state ... that would have been = maintained by the PCE anyway.

Cheers.

JP.
=A0

Regards,

=A0

JL

=A0
=A0
=A0
=A0
=A0
=A0
=A0

=A0Thanks once again for your = opinion.

Best = Regards,

=A0 = Rich

LE ROUX Jean-Louis = RD-CORE-LAN [mailto:jeanlouis.leroux= @francetelecom.com]
Sent: Friday, April 21, 2006 12:51 PM
Jean Philippe = Vasseur (jvasseur); Rich Bradford (rbradfor)
ccamp@ops.ietf.org; pce@ietf.org
RE: [Pce] = Comparison of Encryption vs. Path Key Solutions for the = CPSID.

=A0

Hi JP, Richard

=A0

Please see inline,

=A0

De=A0: JP Vasseur [mailto:jvasseur@cisco.com] =
jeudi 6 avril = 2006 14:52
Rich = Bradford
ccamp@ops.ietf.org; pce@ietf.org
Re: [Pce] = Comparison of Encryption vs. Path Key Solutions for the = CPSID.

Hi,

=A0

Thanks for the summary Rich.=A0

PCE WG members: thanks to provide your = feedback on whether:

(1) You think that there is a need for such = solution,=A0=A0Yes definitely, = confidentiality is a key requirements in an inter-provider = context.

=A0

(2) You would prefer one solution (which one = and why ?)=A0=A0(3) You think that there is a need for = both=A0=A0Answer to (2) and = (3):

It seems to me that we = should end-up with a single solution so as to=A0ease = interworking.

IMO=A0in an inter-AS MPLS-TE environment without PCEs, the = paths will be loose anyway,=A0so there=A0will not be=A0any = confidentiality issue.

If have some concerns=A0regarding the cost of encryption, = particularly for large paths (we need to think about future P2MP = applications with a large number of hops...). By the way, encryption = approaches are really vulnerable to DoS = attacks.

Hence I=A0would = strongly favor the PKS solution. The optimization suggested,=A0which = consists of sending the computed path segment to the LSR in an = unsolicited manner, just after the computation,=A0sounds relevant and = should be further investigated.=A0Best = Regards,

=A0

JL

=A0

=A0

=A0

=A0

Thanks.

=A0

JP.

On Apr 5, 2006, at 6:19 PM, Rich Bradford = ((rbradfor)) wrote:


Hi,As suggested in , I=92ve described some of the tradeoffs between the = two solutions described in = draft-rbradfor-ccamp-confidential-segment-00.txt.-- = RichThe = Confidential Path Segment (CPS) ID provides two very different but = equally valid solutions, the Path Key Subobject (PKS) solution and the = Private Route Subobject (PRS) solution. This note examines a number of = the advantages and disadvantages of each solution.In short: The = PKS solution allows a PCE to hide the CPS for an AS by saving it in a = database and replacing it with a key in the ERO. During the LSP setup, = the ingress LSR for that AS must query the PCE for an = expansion.

The PRS = solution allows a CPS for an AS to be hidden by encrypting it, which may = be done by a PCE or by the Head-End LSR. During the LSP setup, the = ingress LSR for that AS must use a decryption key to obtain the = expansion (implying an earlier exchange or configuration).The major = differences between the mechanisms involve (1) additional control = messages, (2) performance issues expanding those objects, (3) the = addition of state to the PCE, (4) the solution scope (i.e. applicability = to various topologies of each solution.), and (5) the size of objects = added to existing messages.

(1) Additional = Control Message Overhead:

The PKS = solution requires a mechanism to expand the Path Key upon receipt of the = LSP setup request. Since the PCE which calculated the Path Key might not = reside in the entry boundary LSR, the LSR must request the expansion = from the PCE, requiring an additional message exchange before LSP setup = can proceed. The Path Encryption solution does not require this extra = exchange between the PCE and the ingress node for every LSP. Rather, the = decryption key needs to be exchanged only when it is changed. The result = is additional delay during every LSP setup for the PKS solution but no = additional delay for the PRS solution.

(2) PCE and LSR Performance:The PKS = solution must maintain a (temporary) database of keys adding overhead to = the PCE. The PRS solution requires the encryption of the CPS in the PCE = and decryption of the CPS in the LSR, which could be CPU intensive. Note = that in case of a burst of requests, encryption of large number of CPS = may have an impact on the PCE response time.(3) Addition = of State in the PCE:

The PKS = solution requires the addition of path-specific state and maintenance of = a database in the PCE. The PRS solution requires no additional = state.

(4) Solution = Scope:

The PKS and = PRS solutions both work well in conjunction with a PCE to encode and = decode the CPS. However the PKS provides no direct solution without a = PCE. This prevents the PKS solution for working in the case where A's = network straddles B's network and where A wants to use an ERO for a = segment of the LSP across the intervening network, e.g. = (netA)-(netB)-(netA). In addition, the PRS could be used to record a CPS = even if the path (and therefore the returned RRO) crosses multiple = boundaries. Finally, a PRS solution could be adapted to return actual = failure locations in PERRs and/or PATHTEARs, while keeping the failure = location confidential from LSRs without a decryption key. Currently = privacy of this source is maintained by returning the address of border = nodes, which can be very misleading.

(5) Message Object Overhead:The PKS = solution provides a very compact key or token to identify a path = segment, which generally allows for smaller EROs to be returned by the = PCE and to be requested in the resulting PATH message. A PRS which = contains a CPS must generally be at least as large as the unencrypted = PATH through the AS and may be significantly larger if it is desirable = to hide the number of hops within the network from external view by = padding the PRS. The result is potentially larger PATH (and PCEP) = messages for the PRS solution.

Please note = that the tradeoffs listed here are for the current I-D. Some of the = shortcomings of each approach could be mitigated by = implementation-specific optimizations. For example, a PCE could choose = to signal the CPS expansion to the entry boundary LSR, shifting the = burden of maintaining the PKS state to the LSR and eliminating the = performance hit during LSP setup. A similar exchange could be performed = for the PRS case, eliminating the need for a separate key exchange. = These examples of extensions are beyond the scope of the ID, but might = be useful when weighing the pros and cons of the two = solutions.

Pce mailing list


= --Apple-Mail-53-333433759-- From owner-ccamp@ops.ietf.org Thu Apr 27 10:57:21 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ7vl-0005pY-SQ for ccamp-archive@ietf.org; Thu, 27 Apr 2006 10:57:21 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ7vk-0001dy-JE for ccamp-archive@ietf.org; Thu, 27 Apr 2006 10:57:21 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FZ7rE-0009RZ-Uy for ccamp-data@psg.com; Thu, 27 Apr 2006 14:52:40 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FZ7rE-0009RL-Eo for ccamp@ops.ietf.org; Thu, 27 Apr 2006 14:52:40 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 27 Apr 2006 07:52:40 -0700 X-IronPort-AV: i="4.04,161,1144047600"; d="scan'208"; a="1799213805:sNHT30416124" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k3REqcVM023872; Thu, 27 Apr 2006 07:52:39 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Apr 2006 10:52:39 -0400 Received: from [10.83.15.51] ([10.83.15.51]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Apr 2006 10:52:38 -0400 In-Reply-To: <02f301c66994$8daadfe0$0500a8c0@jlucianilaptop> References: <001901c664db$2e1ff6e0$0500a8c0@jlucianilaptop> <6968853B-77E3-4A7C-A5EC-1655C05EA5B0@cisco.com> <02f301c66994$8daadfe0$0500a8c0@jlucianilaptop> Mime-Version: 1.0 (Apple Message framework v749.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Cc: "Adrian Farrel" , , , , Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: MIB Dr. Review for draft-ietf-ccamp-gmpls-tc-mib-10.txt Date: Thu, 27 Apr 2006 10:52:55 -0400 To: "" X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 27 Apr 2006 14:52:38.0747 (UTC) FILETIME=[3A547AB0:01C66A0A] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab If its okay, I will leave this. It is likely that I will have to spin another revision based on IESG revision(s), so I will fix this then. If there are none, I will keep a note to make sure this is fixed when the RFC editor reviews. --Tom > Hi Tom, > > draft-ietf-ccamp-gmpls-tc-mib-10.txt > same comment as before wrt the expiration date > (this is the same draft that was there prior, so > if you submit a new one, please bump the > draft number -- if you prefer to leave the fix > to the RFC editor that is fine also). > > Thanks, > -Joan From owner-ccamp@ops.ietf.org Thu Apr 27 10:58:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ7wn-0006XO-Dd for ccamp-archive@ietf.org; Thu, 27 Apr 2006 10:58:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ7wn-0001hp-0l for ccamp-archive@ietf.org; Thu, 27 Apr 2006 10:58:25 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FZ7op-0009EV-Ab for ccamp-data@psg.com; Thu, 27 Apr 2006 14:50:11 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [64.102.122.148] (helo=rtp-iport-1.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FZ7om-0009EE-Us for ccamp@ops.ietf.org; Thu, 27 Apr 2006 14:50:09 +0000 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 27 Apr 2006 07:50:08 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="4.04,161,1144047600"; d="scan'208"; a="26820685:sNHT25299280" Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k3REo7vF025887; Thu, 27 Apr 2006 10:50:07 -0400 (EDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Apr 2006 10:50:07 -0400 Received: from [10.83.15.51] ([10.83.15.51]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Apr 2006 10:50:07 -0400 In-Reply-To: <02e901c66994$282dbc00$0500a8c0@jlucianilaptop> References: <001901c664db$2e1ff6e0$0500a8c0@jlucianilaptop> <6968853B-77E3-4A7C-A5EC-1655C05EA5B0@cisco.com> <02e901c66994$282dbc00$0500a8c0@jlucianilaptop> Mime-Version: 1.0 (Apple Message framework v749.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Cc: "Adrian Farrel" , , , , Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: MIB Dr. review for draft-ietf-ccamp-gmpls-lsr-mib-13.txt Date: Thu, 27 Apr 2006 10:50:19 -0400 To: "" X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 27 Apr 2006 14:50:07.0309 (UTC) FILETIME=[E010DFD0:01C66A09] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 3a4bc66230659131057bb68ed51598f8 One question below. > Hello Tom and Adrian, > > > All MIBs compile with smilint and smicngPRO. > > Here are my few comments: > > draft-ietf-ccamp-gmpls-lsr-mib-13.txt > > (#1 should be taken care of the others are NITs and > could probably be fixed by RFC Editor if you so choose.) > > 1) Think this was probably a place holder...but > please just remove this: > > OBJECT gmplsLabelRowStatus > SYNTAX RowStatus { active(1), notInService(2) } > WRITE-SYNTAX RowStatus { active(1), notInService(2), > createAndGo(4), destroy(6) } > DESCRIPTION > "TDN QUestion" Thanks for catching this. I remember why I left this. I was confused by your comments on this, which were: >>>> 9) Full Compliance: >>>> >>>> OBJECT gmplsLabelRowStatus >>>> SYNTAX RowStatus { active(1), notInService(2) } >>>> WRITE-SYNTAX RowStatus { active(1), notInService(2), >>>> createAndGo(4), destroy(6) } >>>> DESCRIPTION >>>> "Support for createAndWait and notReady is not required." >>>> >>>> >>>> Would remove this. >>>> >>> >>> The description or the entire object? >>> >> >> Presumably the Description limitation based on the text below. >> >> >>>> Based on the >>>> gmplsLabelRowStatus object's DESCRIPTION >>>> believe you should allow createAndWait and also >>>> Agent could/should be able to report notReady. Based on what is listed in RFC3813, for example, we have the following: OBJECT mplsInSegmentRowStatus SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notReady is not required." I guess I am looking for some explicit instruction on what you would like to see in the DESCRIPTION for the gmplsLabelRowStatus in the FullCompliance statement. > 2) NIT > > January 2003; > " > > Please change this to: > > > January 2003." > > > 3) Informative References > > NIT: > > Change the order so references are in > ascending order: > > Current order is: > > [RFC3472] > > > [RFC3468] > > change to: > > [RFC3468] > > [RFC3472] > > > NIT: > Fix reference: > > Current: > [RFC3468] Andersson, L., Swallow, G., "The Multiprotocol Label > Switching (MPLS) Working Group decision on MPLS > signaling protocols", RFC 3468, February 2003. > > Should be: > > [RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label > > > -- end -- OK, fixed the above nits. --Tom From owner-ccamp@ops.ietf.org Thu Apr 27 11:03:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZ81d-00086I-7V for ccamp-archive@ietf.org; Thu, 27 Apr 2006 11:03:25 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZ81b-00025K-Tm for ccamp-archive@ietf.org; Thu, 27 Apr 2006 11:03:25 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FZ7rZ-0009Tl-AC for ccamp-data@psg.com; Thu, 27 Apr 2006 14:53:01 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, DNS_FROM_RFC_ABUSE,SPF_PASS autolearn=no version=3.1.1 Received: from [171.68.10.86] (helo=sj-iport-4.cisco.com) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FZ7rY-0009TZ-Sg for ccamp@ops.ietf.org; Thu, 27 Apr 2006 14:53:00 +0000 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 27 Apr 2006 07:53:01 -0700 X-IronPort-AV: i="4.04,161,1144047600"; d="scan'208"; a="1799213933:sNHT32559564" Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k3REqnVm023940; Thu, 27 Apr 2006 07:53:00 -0700 (PDT) Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Apr 2006 10:52:59 -0400 Received: from [10.83.15.51] ([10.83.15.51]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Apr 2006 10:52:59 -0400 In-Reply-To: <02e301c66993$ae436840$0500a8c0@jlucianilaptop> References: <001901c664db$2e1ff6e0$0500a8c0@jlucianilaptop> <6968853B-77E3-4A7C-A5EC-1655C05EA5B0@cisco.com> <02e301c66993$ae436840$0500a8c0@jlucianilaptop> Mime-Version: 1.0 (Apple Message framework v749.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7A259EDF-0161-4973-B328-460030927477@cisco.com> Cc: "Adrian Farrel" , , , , Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: MIB Dr. Review for draft-ietf-ccamp-gmpls-te-mib-14.txt Date: Thu, 27 Apr 2006 10:53:16 -0400 To: "" X-Mailer: Apple Mail (2.749.3) X-OriginalArrivalTime: 27 Apr 2006 14:52:59.0154 (UTC) FILETIME=[467E5720:01C66A0A] Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 On Apr 26, 2006, at 8:44 PM, wrote: > > Hi Tom, > > > > ----- Original Message ----- > From: Thomas D. Nadeau > To: > Cc: Adrian Farrel ; ; > ; ; > Sent: Tuesday, April 25, 2006 1:40 PM > Subject: Re: MIB Dr. Review for draft-ietf-ccamp-gmpls-te-mib-14.txt > > > > >>> 9) I am still unclear about what objects can be supported within >>> MPLS only. Was expecting to see this clarified in the conformance >>> statements. There does seem to be more of a division here than >>> in the GMPLS-LSR-STD-MIB. >>> >>> Could some clarification be made to this point? >> >> I guess I am confused. I am not sure why we have >> to explain the reverse relationship. All of the objects herein >> are for GMPLS only; none apply to MPLS-only TE entries. >> So the objects that are supported by >> MPLS-only TE entries should have no corresponding >> objects in this MIB module. Tabular entries in this >> MIB represent GMPLS entries only, and they also have >> corresponding objects in say RFC3812. We also covered this >> reciprocal relationship in the conformance statement before >> as part of your previous comments RE: "should we >> explain each object or explain that they ALL apply." >> > > I was also confused. If there are no MPLS objects then > the MIB is fine as is. Cool. Left as-is. --Tom From owner-ccamp@ops.ietf.org Thu Apr 27 14:05:36 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZArw-0005vA-88 for ccamp-archive@ietf.org; Thu, 27 Apr 2006 14:05:36 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZAru-00064Q-S6 for ccamp-archive@ietf.org; Thu, 27 Apr 2006 14:05:36 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FZAjT-000Pvm-H9 for ccamp-data@psg.com; Thu, 27 Apr 2006 17:56:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.1.1 Received: from [192.240.0.5] (helo=fujitsu0.fujitsu.com) by psg.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FZAjS-000PvV-J4; Thu, 27 Apr 2006 17:56:50 +0000 Received: from fujitsu0.fujitsu.com (localhost [127.0.0.1]) by fujitsu0.fujitsu.com (8.13.6/8.13.6) with ESMTP id k3RHuhNh004907; Thu, 27 Apr 2006 10:56:43 -0700 (PDT) Received: from fujitsui.fna.fujitsu.com ([133.164.253.1]) by fujitsu0.fujitsu.com (8.13.6/8.13.6) with ESMTP id k3RHuWkS004780; Thu, 27 Apr 2006 10:56:42 -0700 (PDT) Received: from mailserv.fla.fujitsu.com (localhost [127.0.0.1]) by fujitsui.fna.fujitsu.com (8.13.6/8.13.6) with ESMTP id k3RHuV4V026521; Thu, 27 Apr 2006 10:56:31 -0700 (PDT) Received: from [133.164.59.60] (localhost [127.0.0.1]) by mailserv.fla.fujitsu.com (8.11.6/8.11.6) with ESMTP id k3RHuUO08564; Thu, 27 Apr 2006 10:56:30 -0700 (PDT) Message-ID: <445105CC.9000405@us.fujitsu.com> Date: Thu, 27 Apr 2006 10:56:28 -0700 From: Richard Rabbat Organization: Fujitsu Labs of America User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Adrian Farrel , dimitri papadimitriou CC: ccamp@ops.ietf.org Subject: Question about carrying the call id Content-Type: multipart/mixed; boundary="------------020608030005040109080002" Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d This is a multi-part message in MIME format. --------------020608030005040109080002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Adrian, Dimitri, In your slides regarding ASON, you mentioned in slide 7 http://www3.ietf.org/proceedings/06mar/slides/ccamp-4/sld7.htm that the current proposal is to match the session object but that an alternative may be using the association object. has there been a decision either way and what was the rationale? thanks, Richard. --------------020608030005040109080002 Content-Type: text/x-vcard; charset=utf-8; name="richard.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="richard.vcf" begin:vcard fn:Richard Rabbat n:Rabbat;Richard org:Fujitsu adr:MS 345;;1240 East Arques Ave;Sunnyvale;CA;94085;USA email;internet:richard@us.fujitsu.com title:Senior Project Manager tel;work:1-408-530-4537 tel;fax:1-408-530-4515 tel;cell:1-650-714-7618 x-mozilla-html:TRUE version:2.1 end:vcard --------------020608030005040109080002-- From owner-ccamp@ops.ietf.org Fri Apr 28 17:02:03 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZa6F-0001pM-M5 for ccamp-archive@ietf.org; Fri, 28 Apr 2006 17:02:03 -0400 Received: from psg.com ([147.28.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZa6E-0003ns-6h for ccamp-archive@ietf.org; Fri, 28 Apr 2006 17:02:03 -0400 Received: from majordom by psg.com with local (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FZZzH-000Hn0-1p for ccamp-data@psg.com; Fri, 28 Apr 2006 20:54:51 +0000 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on psg.com X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DNS_FROM_RFC_ABUSE, NO_REAL_NAME autolearn=no version=3.1.1 Received: from [209.86.89.65] (helo=elasmtp-kukur.atl.sa.earthlink.net) by psg.com with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FZZzF-000Hle-Ua for ccamp@ops.ietf.org; Fri, 28 Apr 2006 20:54:50 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=aA3fYmNzhIqj8iOlIIvC0rZXjRxyX54IoXWKNL7AaNDv7tMotQ062bFQHFpC1pMG; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.50] (helo=mswamui-swiss.atl.sa.earthlink.net) by elasmtp-kukur.atl.sa.earthlink.net with asmtp (Exim 4.34) id 1FZZz9-0007QA-Gs; Fri, 28 Apr 2006 16:54:43 -0400 Received: from 68.81.55.22 by webmail.atl.earthlink.net with HTTP; Fri, 28 Apr 2006 16:54:43 -0400 Message-ID: <11791080.1146257683516.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> Date: Fri, 28 Apr 2006 16:54:43 -0400 (GMT-04:00) From: jcucchiara@mindspring.com Reply-To: jcucchiara@mindspring.com To: "Thomas D. Nadeau" Subject: Re: MIB Dr. review for draft-ietf-ccamp-gmpls-lsr-mib-13.txt Cc: Adrian Farrel , ccamp@ops.ietf.org, bwijnen@lucent.com, dromasca@avaya.com, kireeti@juniper.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4d68bbe9cb71969ea344cf2d1a8e60840a9da525759e265422766702b1594b362fbd59ac6d5b0c8d1a036a86675380a6350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.50 Sender: owner-ccamp@ops.ietf.org Precedence: bulk X-Spam-Score: 0.2 (/) X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593 -----Original Message----- >From: "Thomas D. Nadeau" >Sent: Apr 27, 2006 10:50 AM >To: "" >Cc: Adrian Farrel , ccamp@ops.ietf.org, bwijnen@lucent.com, dromasca@avaya.com, kireeti@juniper.net >Subject: Re: MIB Dr. review for draft-ietf-ccamp-gmpls-lsr-mib-13.txt > > > One question below. > >> Hello Tom and Adrian, >> >> >> All MIBs compile with smilint and smicngPRO. >> >> Here are my few comments: >> >> draft-ietf-ccamp-gmpls-lsr-mib-13.txt >> >> (#1 should be taken care of the others are NITs and >> could probably be fixed by RFC Editor if you so choose.) >> >> 1) Think this was probably a place holder...but >> please just remove this: >> >> OBJECT gmplsLabelRowStatus >> SYNTAX RowStatus { active(1), notInService(2) } >> WRITE-SYNTAX RowStatus { active(1), notInService(2), >> createAndGo(4), destroy(6) } >> DESCRIPTION >> "TDN QUestion" > > Thanks for catching this. I remember why I left this. >I was confused by your comments on this, which were: >>>>> 9) Full Compliance: >>>>> >>>>> OBJECT gmplsLabelRowStatus >>>>> SYNTAX RowStatus { active(1), notInService(2) } >>>>> WRITE-SYNTAX RowStatus { active(1), notInService(2), >>>>> createAndGo(4), destroy(6) } >>>>> DESCRIPTION >>>>> "Support for createAndWait and notReady is not required." >>>>> >>>>> >>>>> Would remove this. >>>>> >>>> >>>> The description or the entire object? >>>> >>> >>> Presumably the Description limitation based on the text below. >>> >>> >>>>> Based on the >>>>> gmplsLabelRowStatus object's DESCRIPTION >>>>> believe you should allow createAndWait and also >>>>> Agent could/should be able to report notReady. > > Based on what is listed in RFC3813, for example, >we have the following: > > OBJECT mplsInSegmentRowStatus > SYNTAX RowStatus { active(1), notInService(2) } > WRITE-SYNTAX RowStatus { active(1), notInService(2), > createAndGo(4), destroy(6) > } > DESCRIPTION "Support for createAndWait and notReady is > not required." > > I guess I am looking for some explicit instruction on >what you would like to see in the DESCRIPTION for the >gmplsLabelRowStatus in the FullCompliance statement. Hi Tom, The above DESCRIPTION is okay. Or (my preference) would be to remove the entire object because think that you need CreateAndWait based on how the object is used. -Joan > >> 2) NIT >> >> January 2003; >> " >> >> Please change this to: >> >> >> January 2003." >> >> >> 3) Informative References >> >> NIT: >> >> Change the order so references are in >> ascending order: >> >> Current order is: >> >> [RFC3472] >> >> >> [RFC3468] >> >> change to: >> >> [RFC3468] >> >> [RFC3472] >> >> >> NIT: >> Fix reference: >> >> Current: >> [RFC3468] Andersson, L., Swallow, G., "The Multiprotocol Label >> Switching (MPLS) Working Group decision on MPLS >> signaling protocols", RFC 3468, February 2003. >> >> Should be: >> >> [RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label >> >> >> -- end -- > > OK, fixed the above nits. > > --Tom > > From european.email.award@web.de Sat Apr 29 14:04:38 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FZto6-0007iX-35 for ccamp-archive@ietf.org; Sat, 29 Apr 2006 14:04:38 -0400 Received: from fmmailgate05.web.de ([217.72.192.243]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FZto5-0003DO-Fo for ccamp-archive@ietf.org; Sat, 29 Apr 2006 14:04:38 -0400 Received: by fmmailgate05.web.de (8.12.10/8.12.10/webde Linux 0.7) with SMTP id k3TI2GTb022342; Sat, 29 Apr 2006 20:03:24 +0200 Received: from [84.123.50.134] by freemailng2302.web.de with HTTP; Sat, 29 Apr 2006 20:03:23 +0200 Date: Sat, 29 Apr 2006 20:03:23 +0200 Message-Id: <49352617@web.de> MIME-Version: 1.0 From: euro milliones To: eurolottery10@web.de Subject: Your E-Mail Address Have Won A Lottery Prize !!! Precedence: fm-user Organization: http://freemail.web.de/ Content-Type: multipart/alternative; boundary="=-------------11463338046053875054" X-Spam-Score: 2.8 (++) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac This is a multi-part message in MIME format. --=-------------11463338046053875054 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit EURO MILLONES LOTTERY MADRID - SPAIN Dear Beneficiary We are please to announce you as one of the 10 lucky winners in the Euro Millones Lottery International Email Address draw on the 16th of January 2006 due to the mixture of names and address the result was released on the 19th March 2006. All 10 winning addresses were randomly selected from a batchof 50,000,000 international email addresses. Your email address emerged alongside 9 others as a category A winner in the Euro Millones Lottery Draw. Consequently, you have therefore been approved for a total pay out of US$950,000:00 (Nine Hundred And Fifty Thousand United States Dollars Only).The following particulars are attached to your lotto payment order: (I) Batch No: WNTO/7416/VA/ES (ii) Ticket No: TWMT/1800/806 (iii) Lucky No: 07-13-31.54-64 (iv) Ref No: EMLES/2006/M (V) Serial No: CNMMM/67000/MMC The Euro Millones Lottery Program internet draw is held once in a year and is so organized to encourage the use of the internet and computers worldwide. We are proud to say that over 200 Million Euros are won annually in more than 150 countries worldwide. To claim your winning prize you are to contact the appointed agent as soon as possible for the immediate release of your winnings: DON JOSE SAMMARACH ASSURANCE AGENTS SA E-mail:assuranceagents@netscape.net N.B:Steps to claiming your prize; 1.Please quote your Reference number in all correspondence with the claims officer. 2. You must contact the appointed agent with your Full Names, Contact Telephone Numbers (Home, Office and Mobile Number and also Fax Number) via email to process the immediate payment of your prize. 3. Be informed that the appointed agent will be required to swear an Affidavits of Lotto Claim and also obtain Approval Legal Clearance Certificate from the Court here in Spain which is in accordance with the European Union Financial Act 2004 on payment of International Lottery Winners. Please be aware that the PAYING BANK will Effect Payment Swiftly upon satisfactory Report, Verifications and validation provided by this fiduciaryagent. For security reasons, you are advised to keep your winning information confidential till your claims is processed and your money remitted to you. Be informed that the deadline to claim your winning prize money is 26th April 2006. Once again congratulations!!! Best regards, Ms.Anita Alicante. Euro Millones Lottery Board. SMS schreiben mit WEB.DE FreeMail - einfach, schnell und kostenguenstig. Jetzt gleich testen! *http://f.web.de/?mc=021192* [http://f.web.de/?mc=021192] --=-------------11463338046053875054 Content-Type: text/html; charset=iso-8859-15 Content-Transfer-Encoding: 7bit


EURO MILLONES LOTTERY
MADRID - SPAIN

 
Dear Beneficiary
 
We are please to announce you as one of the 10 lucky winners in the Euro Millones Lottery International
Email Address draw  on the 16th of January 2006 due to the mixture of names and address the result was released on the 19th March  2006. All 10 winning addresses were randomly selected from a batchof 50,000,000 international email addresses.

Your email address emerged alongside 9 others as a category A winner in the Euro Millones Lottery Draw.

Consequently, you have therefore been approved for a total pay out of US$950,000:00 (Nine Hundred And Fifty Thousand United States Dollars Only).The following particulars are attached to your lotto payment order:
 (I)   Batch No: WNTO/7416/VA/ES
(ii)  Ticket No: TWMT/1800/806
(iii) Lucky  No: 07-13-31.54-64
(iv)  Ref    No: EMLES/2006/M
(V)   Serial No: CNMMM/67000/MMC
 
The Euro Millones Lottery Program internet draw is held once in a year and is so organized to encourage
the use of the internet and computers worldwide. We are proud to say that over 200 Million Euros are won annually in more than 150 countries worldwide.

To claim your winning prize you are to contact the appointed agent as soon as possible for the immediate release of your winnings:
 
DON JOSE SAMMARACH
ASSURANCE AGENTS SA
E-mail:assuranceagents@netscape.net
 
N.B:Steps to claiming your prize;
 
1.Please quote your Reference number in all correspondence with the claims officer.
 
2. You must contact the appointed agent with your Full Names, Contact Telephone Numbers (Home, Office and M! obile Number and also Fax Number) via email to process the immediate p ayment of your prize.
 
3. Be informed that the appointed agent will be required to swear an Affidavits of Lotto Claim and
also obtain Approval Legal Clearance Certificate from the Court here in Spain which is in accordance with the European Union Financial Act 2004 on payment of International Lottery
Winners.

Please be aware that the PAYING BANK will Effect Payment Swiftly upon satisfactory Report,
Verifications and validation provided by this fiduciaryagent.

For security reasons, you are advised to keep your winning information confidential till your claims is
processed and your money remitted to you.
 
Be informed that the deadline to claim your winning prize money is 26th April 2006.
Once again congratulations!!!
 
Best regards,
Ms.Anita Alicante.
Euro Millones Lottery Board.



SMS schreiben mit WEB.DE FreeMail - einfach, schnell und   
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192  
--=-------------11463338046053875054-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 28 Apr 2006 20:56:20 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=aA3fYmNzhIqj8iOlIIvC0rZXjRxyX54IoXWKNL7AaNDv7tMotQ062bFQHFpC1pMG; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Message-ID: <11791080.1146257683516.JavaMail.root@mswamui-swiss.atl.sa.earthlink.net> Date: Fri, 28 Apr 2006 16:54:43 -0400 (GMT-04:00) From: jcucchiara@mindspring.com Reply-To: jcucchiara@mindspring.com To: "Thomas D. Nadeau" Subject: Re: MIB Dr. review for draft-ietf-ccamp-gmpls-lsr-mib-13.txt Cc: Adrian Farrel , ccamp@ops.ietf.org, bwijnen@lucent.com, dromasca@avaya.com, kireeti@juniper.net Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit -----Original Message----- >From: "Thomas D. Nadeau" >Sent: Apr 27, 2006 10:50 AM >To: "" >Cc: Adrian Farrel , ccamp@ops.ietf.org, bwijnen@lucent.com, dromasca@avaya.com, kireeti@juniper.net >Subject: Re: MIB Dr. review for draft-ietf-ccamp-gmpls-lsr-mib-13.txt > > > One question below. > >> Hello Tom and Adrian, >> >> >> All MIBs compile with smilint and smicngPRO. >> >> Here are my few comments: >> >> draft-ietf-ccamp-gmpls-lsr-mib-13.txt >> >> (#1 should be taken care of the others are NITs and >> could probably be fixed by RFC Editor if you so choose.) >> >> 1) Think this was probably a place holder...but >> please just remove this: >> >> OBJECT gmplsLabelRowStatus >> SYNTAX RowStatus { active(1), notInService(2) } >> WRITE-SYNTAX RowStatus { active(1), notInService(2), >> createAndGo(4), destroy(6) } >> DESCRIPTION >> "TDN QUestion" > > Thanks for catching this. I remember why I left this. >I was confused by your comments on this, which were: >>>>> 9) Full Compliance: >>>>> >>>>> OBJECT gmplsLabelRowStatus >>>>> SYNTAX RowStatus { active(1), notInService(2) } >>>>> WRITE-SYNTAX RowStatus { active(1), notInService(2), >>>>> createAndGo(4), destroy(6) } >>>>> DESCRIPTION >>>>> "Support for createAndWait and notReady is not required." >>>>> >>>>> >>>>> Would remove this. >>>>> >>>> >>>> The description or the entire object? >>>> >>> >>> Presumably the Description limitation based on the text below. >>> >>> >>>>> Based on the >>>>> gmplsLabelRowStatus object's DESCRIPTION >>>>> believe you should allow createAndWait and also >>>>> Agent could/should be able to report notReady. > > Based on what is listed in RFC3813, for example, >we have the following: > > OBJECT mplsInSegmentRowStatus > SYNTAX RowStatus { active(1), notInService(2) } > WRITE-SYNTAX RowStatus { active(1), notInService(2), > createAndGo(4), destroy(6) > } > DESCRIPTION "Support for createAndWait and notReady is > not required." > > I guess I am looking for some explicit instruction on >what you would like to see in the DESCRIPTION for the >gmplsLabelRowStatus in the FullCompliance statement. Hi Tom, The above DESCRIPTION is okay. Or (my preference) would be to remove the entire object because think that you need CreateAndWait based on how the object is used. -Joan > >> 2) NIT >> >> January 2003; >> " >> >> Please change this to: >> >> >> January 2003." >> >> >> 3) Informative References >> >> NIT: >> >> Change the order so references are in >> ascending order: >> >> Current order is: >> >> [RFC3472] >> >> >> [RFC3468] >> >> change to: >> >> [RFC3468] >> >> [RFC3472] >> >> >> NIT: >> Fix reference: >> >> Current: >> [RFC3468] Andersson, L., Swallow, G., "The Multiprotocol Label >> Switching (MPLS) Working Group decision on MPLS >> signaling protocols", RFC 3468, February 2003. >> >> Should be: >> >> [RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label >> >> >> -- end -- > > OK, fixed the above nits. > > --Tom > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Apr 2006 17:57:53 +0000 Message-ID: <445105CC.9000405@us.fujitsu.com> Date: Thu, 27 Apr 2006 10:56:28 -0700 From: Richard Rabbat Organization: Fujitsu Labs of America User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Adrian Farrel , dimitri papadimitriou CC: ccamp@ops.ietf.org Subject: Question about carrying the call id Content-Type: multipart/mixed; boundary="------------020608030005040109080002" This is a multi-part message in MIME format. --------------020608030005040109080002 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Adrian, Dimitri, In your slides regarding ASON, you mentioned in slide 7 http://www3.ietf.org/proceedings/06mar/slides/ccamp-4/sld7.htm that the current proposal is to match the session object but that an alternative may be using the association object. has there been a decision either way and what was the rationale? thanks, Richard. --------------020608030005040109080002 Content-Type: text/x-vcard; charset=utf-8; name="richard.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="richard.vcf" begin:vcard fn:Richard Rabbat n:Rabbat;Richard org:Fujitsu adr:MS 345;;1240 East Arques Ave;Sunnyvale;CA;94085;USA email;internet:richard@us.fujitsu.com title:Senior Project Manager tel;work:1-408-530-4537 tel;fax:1-408-530-4515 tel;cell:1-650-714-7618 x-mozilla-html:TRUE version:2.1 end:vcard --------------020608030005040109080002-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Apr 2006 14:53:03 +0000 Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7A259EDF-0161-4973-B328-460030927477@cisco.com> Cc: "Adrian Farrel" , , , , Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: MIB Dr. Review for draft-ietf-ccamp-gmpls-te-mib-14.txt Date: Thu, 27 Apr 2006 10:53:16 -0400 To: "" On Apr 26, 2006, at 8:44 PM, wrote: > > Hi Tom, > > > > ----- Original Message ----- > From: Thomas D. Nadeau > To: > Cc: Adrian Farrel ; ; > ; ; > Sent: Tuesday, April 25, 2006 1:40 PM > Subject: Re: MIB Dr. Review for draft-ietf-ccamp-gmpls-te-mib-14.txt > > > > >>> 9) I am still unclear about what objects can be supported within >>> MPLS only. Was expecting to see this clarified in the conformance >>> statements. There does seem to be more of a division here than >>> in the GMPLS-LSR-STD-MIB. >>> >>> Could some clarification be made to this point? >> >> I guess I am confused. I am not sure why we have >> to explain the reverse relationship. All of the objects herein >> are for GMPLS only; none apply to MPLS-only TE entries. >> So the objects that are supported by >> MPLS-only TE entries should have no corresponding >> objects in this MIB module. Tabular entries in this >> MIB represent GMPLS entries only, and they also have >> corresponding objects in say RFC3812. We also covered this >> reciprocal relationship in the conformance statement before >> as part of your previous comments RE: "should we >> explain each object or explain that they ALL apply." >> > > I was also confused. If there are no MPLS objects then > the MIB is fine as is. Cool. Left as-is. --Tom Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Apr 2006 14:52:45 +0000 Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Cc: "Adrian Farrel" , , , , Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: MIB Dr. Review for draft-ietf-ccamp-gmpls-tc-mib-10.txt Date: Thu, 27 Apr 2006 10:52:55 -0400 To: "" If its okay, I will leave this. It is likely that I will have to spin another revision based on IESG revision(s), so I will fix this then. If there are none, I will keep a note to make sure this is fixed when the RFC editor reviews. --Tom > Hi Tom, > > draft-ietf-ccamp-gmpls-tc-mib-10.txt > same comment as before wrt the expiration date > (this is the same draft that was there prior, so > if you submit a new one, please bump the > draft number -- if you prefer to leave the fix > to the RFC editor that is fine also). > > Thanks, > -Joan Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Apr 2006 14:51:01 +0000 Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Cc: "Adrian Farrel" , , , , Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: MIB Dr. review for draft-ietf-ccamp-gmpls-lsr-mib-13.txt Date: Thu, 27 Apr 2006 10:50:19 -0400 To: "" One question below. > Hello Tom and Adrian, > > > All MIBs compile with smilint and smicngPRO. > > Here are my few comments: > > draft-ietf-ccamp-gmpls-lsr-mib-13.txt > > (#1 should be taken care of the others are NITs and > could probably be fixed by RFC Editor if you so choose.) > > 1) Think this was probably a place holder...but > please just remove this: > > OBJECT gmplsLabelRowStatus > SYNTAX RowStatus { active(1), notInService(2) } > WRITE-SYNTAX RowStatus { active(1), notInService(2), > createAndGo(4), destroy(6) } > DESCRIPTION > "TDN QUestion" Thanks for catching this. I remember why I left this. I was confused by your comments on this, which were: >>>> 9) Full Compliance: >>>> >>>> OBJECT gmplsLabelRowStatus >>>> SYNTAX RowStatus { active(1), notInService(2) } >>>> WRITE-SYNTAX RowStatus { active(1), notInService(2), >>>> createAndGo(4), destroy(6) } >>>> DESCRIPTION >>>> "Support for createAndWait and notReady is not required." >>>> >>>> >>>> Would remove this. >>>> >>> >>> The description or the entire object? >>> >> >> Presumably the Description limitation based on the text below. >> >> >>>> Based on the >>>> gmplsLabelRowStatus object's DESCRIPTION >>>> believe you should allow createAndWait and also >>>> Agent could/should be able to report notReady. Based on what is listed in RFC3813, for example, we have the following: OBJECT mplsInSegmentRowStatus SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notReady is not required." I guess I am looking for some explicit instruction on what you would like to see in the DESCRIPTION for the gmplsLabelRowStatus in the FullCompliance statement. > 2) NIT > > January 2003; > " > > Please change this to: > > > January 2003." > > > 3) Informative References > > NIT: > > Change the order so references are in > ascending order: > > Current order is: > > [RFC3472] > > > [RFC3468] > > change to: > > [RFC3468] > > [RFC3472] > > > NIT: > Fix reference: > > Current: > [RFC3468] Andersson, L., Swallow, G., "The Multiprotocol Label > Switching (MPLS) Working Group decision on MPLS > signaling protocols", RFC 3468, February 2003. > > Should be: > > [RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label > > > -- end -- OK, fixed the above nits. --Tom Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Apr 2006 13:26:16 +0000 Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: multipart/alternative; boundary=Apple-Mail-53-333433759 Message-Id: <4CA3EE07-6890-452C-AE6B-BD8EA4128412@cisco.com> Cc: "Rich Bradford \(rbradfor\)" , , From: JP Vasseur Subject: Re: [Pce] Comparison of Encryption vs. Path Key Solutions for the CPSID. Date: Thu, 27 Apr 2006 09:25:58 -0400 To: "LE ROUX Jean-Louis RD-CORE-LAN" --Apple-Mail-53-333433759 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Hi Jean-Louis, On Apr 27, 2006, at 9:21 AM, LE ROUX Jean-Louis RD-CORE-LAN wrote: > Hi Richard, > > Please see inline, > > De : Rich Bradford (rbradfor) [mailto:rbradfor@cisco.com] > Envoy=E9 : lundi 24 avril 2006 20:06 > =C0 : LE ROUX Jean-Louis RD-CORE-LAN; Jean Philippe Vasseur (jvasseur) > Cc : ccamp@ops.ietf.org; pce@ietf.org > Objet : RE: [Pce] Comparison of Encryption vs. Path Key Solutions =20 > for the CPSID. > > JL, > > Thanks for the reply. It=92s always difficult to choose between =20 > multiple solutions when there are so many tradeoffs between the =20 > solutions. > > > > Regarding the optimization where the PCE sends the LSR the =20 > unsolicited computed path segment. It was a difficult choice =20 > whether or not to include a description of this in the original =20 > draft, since it is more complex. Which aspect of the optimization =20 > seemed most important? Was it that it=92s more efficient during LSP =20= > setup or because it could be used to shift the burden of =20 > maintaining state from the PCE to the LSR? > > > IMO the most important optimization is the gain in LSP setup time, =20 > which may be significant, and this is of particular > > importance during end-to-end LSP restoration upon failure. > > Let's assume an inter-AS path computation with an AS-path length =3D = N: > > -Without this optimization the LSP signaling time would be N* Intra-=20= > AS-RSVP-sig + N* LSR-PCE exchanges. > > -With this optimization the LSP signaling time would be N* Intra-AS-=20= > RSVP-sig > > Hence the gain in signaling time is N*LSR-PCE exchanges. > > And the good thing is that the path computation time would not be =20 > impacted at all by this procedure as the PCE-LSR unsolicited =20 > notification is done in // with the BRPC procedure. > > > There may be one minor con: During the BRPC you don't know a priori =20= > which path segment will finally be selected, hence you need to send =20= > the path segment to all ASBR LSRs connected to the upstream =20 > AS...but this is a minor issue, because there are not so many ASBRs =20= > connected to the upstream AS (two or three). You will have to =20 > remove the information on the ASBR if no Path message is received =20 > after the expiration of a timer... Agree, this is a temporary state ... that would have been maintained =20 by the PCE anyway. Cheers. JP. > > Regards, > > > JL > > > > > > > > > > > Thanks once again for your opinion. > > Best Regards, > > Rich > > > > From: LE ROUX Jean-Louis RD-CORE-LAN =20 > [mailto:jeanlouis.leroux@francetelecom.com] > Sent: Friday, April 21, 2006 12:51 PM > To: Jean Philippe Vasseur (jvasseur); Rich Bradford (rbradfor) > Cc: ccamp@ops.ietf.org; pce@ietf.org > Subject: RE: [Pce] Comparison of Encryption vs. Path Key Solutions =20 > for the CPSID. > > > > Hi JP, Richard > > > > Please see inline, > > > > De : JP Vasseur [mailto:jvasseur@cisco.com] > Envoy=E9 : jeudi 6 avril 2006 14:52 > =C0 : Rich Bradford > Cc : ccamp@ops.ietf.org; pce@ietf.org > Objet : Re: [Pce] Comparison of Encryption vs. Path Key Solutions =20 > for the CPSID. > > Hi, > > > > Thanks for the summary Rich. > > > > PCE WG members: thanks to provide your feedback on whether: > > (1) You think that there is a need for such solution, > > > > Yes definitely, confidentiality is a key requirements in an inter-=20 > provider context. > > > > (2) You would prefer one solution (which one and why ?) > > > > (3) You think that there is a need for both > > > > Answer to (2) and (3): > > It seems to me that we should end-up with a single solution so as =20 > to ease interworking. > > IMO in an inter-AS MPLS-TE environment without PCEs, the paths will =20= > be loose anyway, so there will not be any confidentiality issue. > > If have some concerns regarding the cost of encryption, =20 > particularly for large paths (we need to think about future P2MP =20 > applications with a large number of hops...). By the way, =20 > encryption approaches are really vulnerable to DoS attacks. > > Hence I would strongly favor the PKS solution. The optimization =20 > suggested, which consists of sending the computed path segment to =20 > the LSR in an unsolicited manner, just after the computation, =20 > sounds relevant and should be further investigated. > > > > Best Regards, > > > > JL > > > > > > > > > > Thanks. > > > > JP. > > > > On Apr 5, 2006, at 6:19 PM, Rich Bradford ((rbradfor)) wrote: > > > > > Hi, > > As suggested in Dallas, I=92ve described some of the tradeoffs =20 > between the two solutions described in draft-rbradfor-ccamp-=20 > confidential-segment-00.txt. > > -- Rich > > The Confidential Path Segment (CPS) ID provides two very different =20 > but equally valid solutions, the Path Key Subobject (PKS) solution =20 > and the Private Route Subobject (PRS) solution. This note examines =20 > a number of the advantages and disadvantages of each solution. > > In short: The PKS solution allows a PCE to hide the CPS for an AS =20 > by saving it in a database and replacing it with a key in the ERO. =20 > During the LSP setup, the ingress LSR for that AS must query the =20 > PCE for an expansion. > > The PRS solution allows a CPS for an AS to be hidden by encrypting =20 > it, which may be done by a PCE or by the Head-End LSR. During the =20 > LSP setup, the ingress LSR for that AS must use a decryption key to =20= > obtain the expansion (implying an earlier exchange or configuration). > > The major differences between the mechanisms involve (1) additional =20= > control messages, (2) performance issues expanding those objects, =20 > (3) the addition of state to the PCE, (4) the solution scope (i.e. =20 > applicability to various topologies of each solution.), and (5) the =20= > size of objects added to existing messages. > > (1) Additional Control Message Overhead: > > The PKS solution requires a mechanism to expand the Path Key upon =20 > receipt of the LSP setup request. Since the PCE which calculated =20 > the Path Key might not reside in the entry boundary LSR, the LSR =20 > must request the expansion from the PCE, requiring an additional =20 > message exchange before LSP setup can proceed. The Path Encryption =20 > solution does not require this extra exchange between the PCE and =20 > the ingress node for every LSP. Rather, the decryption key needs to =20= > be exchanged only when it is changed. The result is additional =20 > delay during every LSP setup for the PKS solution but no additional =20= > delay for the PRS solution. > > (2) PCE and LSR Performance: > > The PKS solution must maintain a (temporary) database of keys =20 > adding overhead to the PCE. The PRS solution requires the =20 > encryption of the CPS in the PCE and decryption of the CPS in the =20 > LSR, which could be CPU intensive. Note that in case of a burst of =20 > requests, encryption of large number of CPS may have an impact on =20 > the PCE response time. > > (3) Addition of State in the PCE: > > The PKS solution requires the addition of path-specific state and =20 > maintenance of a database in the PCE. The PRS solution requires no =20 > additional state. > > (4) Solution Scope: > > The PKS and PRS solutions both work well in conjunction with a PCE =20 > to encode and decode the CPS. However the PKS provides no direct =20 > solution without a PCE. This prevents the PKS solution for working =20 > in the case where A's network straddles B's network and where A =20 > wants to use an ERO for a segment of the LSP across the intervening =20= > network, e.g. (netA)-(netB)-(netA). In addition, the PRS could be =20 > used to record a CPS even if the path (and therefore the returned =20 > RRO) crosses multiple boundaries. Finally, a PRS solution could be =20 > adapted to return actual failure locations in PERRs and/or =20 > PATHTEARs, while keeping the failure location confidential from =20 > LSRs without a decryption key. Currently privacy of this source is =20 > maintained by returning the address of border nodes, which can be =20 > very misleading. > > (5) Message Object Overhead: > > The PKS solution provides a very compact key or token to identify a =20= > path segment, which generally allows for smaller EROs to be =20 > returned by the PCE and to be requested in the resulting PATH =20 > message. A PRS which contains a CPS must generally be at least as =20 > large as the unencrypted PATH through the AS and may be =20 > significantly larger if it is desirable to hide the number of hops =20 > within the network from external view by padding the PRS. The =20 > result is potentially larger PATH (and PCEP) messages for the PRS =20 > solution. > > Please note that the tradeoffs listed here are for the current I-D. =20= > Some of the shortcomings of each approach could be mitigated by =20 > implementation-specific optimizations. For example, a PCE could =20 > choose to signal the CPS expansion to the entry boundary LSR, =20 > shifting the burden of maintaining the PKS state to the LSR and =20 > eliminating the performance hit during LSP setup. A similar =20 > exchange could be performed for the PRS case, eliminating the need =20 > for a separate key exchange. These examples of extensions are =20 > beyond the scope of the ID, but might be useful when weighing the =20 > pros and cons of the two solutions. > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > > > --Apple-Mail-53-333433759 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 Hi = Jean-Louis,

On Apr 27, 2006, at 9:21 AM, LE ROUX = Jean-Louis RD-CORE-LAN wrote:

Rich Bradford = (rbradfor) [mailto:rbradfor@cisco.com] =
lundi 24 avril 2006 20:06
=C0=A0: LE ROUX Jean-Louis RD-CORE-LAN; = Jean Philippe Vasseur (jvasseur)
ccamp@ops.ietf.org; pce@ietf.org
RE: [Pce] Comparison of Encryption vs. Path Key = Solutions for the CPSID.

JL,

Thanks for the = reply. It=92s always difficult to choose between multiple solutions when = there are so many tradeoffs between the solutions.=A0

=A0

IMO=A0the most important optimization is the gain in = LSP setup time, which=A0may be=A0significant, and this is of = particular=A0

importance during end-to-end LSP restoration upon = failure.

Let's assume an inter-AS path computation with an = AS-path length =3D N:

-Without this = optimization the LSP signaling time would be N* Intra-AS-RSVP-sig + N* = LSR-PCE exchanges.

-With this optimization = the LSP signaling time would be N* = Intra-AS-RSVP-sig

Hence the gain in = signaling time is N*LSR-PCE = exchanges.

And=A0the good thing is=A0that the path computation = time=A0would not be impacted at all by this procedure as the PCE-LSR = unsolicited notification is done in // with the BRPC = procedure.

=A0

There may be one minor con: = During the BRPC you don't = know a priori which path segment will finally be selected, hence you = need to send the path segment=A0to all ASBR LSRs=A0connected to the = upstream AS...but this is a minor issue, because there are not so many = ASBRs connected to the upstream AS (two or three).=A0You will have = to=A0remove the information on the ASBR=A0if no Path message is received = after the expiration of a = timer...

<= /BLOCKQUOTE>Agree, this is a temporary state ... that would have been = maintained by the PCE anyway.

Cheers.

JP.
=A0

Regards,

=A0

JL

=A0
=A0
=A0
=A0
=A0
=A0
=A0

=A0Thanks once again for your = opinion.

Best = Regards,

=A0 = Rich

LE ROUX Jean-Louis = RD-CORE-LAN [mailto:jeanlouis.leroux= @francetelecom.com]
Sent: Friday, April 21, 2006 12:51 PM
Jean Philippe = Vasseur (jvasseur); Rich Bradford (rbradfor)
ccamp@ops.ietf.org; pce@ietf.org
RE: [Pce] = Comparison of Encryption vs. Path Key Solutions for the = CPSID.

=A0

Hi JP, Richard

=A0

Please see inline,

=A0

De=A0: JP Vasseur [mailto:jvasseur@cisco.com] =
jeudi 6 avril = 2006 14:52
Rich = Bradford
ccamp@ops.ietf.org; pce@ietf.org
Re: [Pce] = Comparison of Encryption vs. Path Key Solutions for the = CPSID.

Hi,

=A0

Thanks for the summary Rich.=A0

PCE WG members: thanks to provide your = feedback on whether:

(1) You think that there is a need for such = solution,=A0=A0Yes definitely, = confidentiality is a key requirements in an inter-provider = context.

=A0

(2) You would prefer one solution (which one = and why ?)=A0=A0(3) You think that there is a need for = both=A0=A0Answer to (2) and = (3):

It seems to me that we = should end-up with a single solution so as to=A0ease = interworking.

IMO=A0in an inter-AS MPLS-TE environment without PCEs, the = paths will be loose anyway,=A0so there=A0will not be=A0any = confidentiality issue.

If have some concerns=A0regarding the cost of encryption, = particularly for large paths (we need to think about future P2MP = applications with a large number of hops...). By the way, encryption = approaches are really vulnerable to DoS = attacks.

Hence I=A0would = strongly favor the PKS solution. The optimization suggested,=A0which = consists of sending the computed path segment to the LSR in an = unsolicited manner, just after the computation,=A0sounds relevant and = should be further investigated.=A0Best = Regards,

=A0

JL

=A0

=A0

=A0

=A0

Thanks.

=A0

JP.

On Apr 5, 2006, at 6:19 PM, Rich Bradford = ((rbradfor)) wrote:


Hi,As suggested in , I=92ve described some of the tradeoffs between the = two solutions described in = draft-rbradfor-ccamp-confidential-segment-00.txt.-- = RichThe = Confidential Path Segment (CPS) ID provides two very different but = equally valid solutions, the Path Key Subobject (PKS) solution and the = Private Route Subobject (PRS) solution. This note examines a number of = the advantages and disadvantages of each solution.In short: The = PKS solution allows a PCE to hide the CPS for an AS by saving it in a = database and replacing it with a key in the ERO. During the LSP setup, = the ingress LSR for that AS must query the PCE for an = expansion.

The PRS = solution allows a CPS for an AS to be hidden by encrypting it, which may = be done by a PCE or by the Head-End LSR. During the LSP setup, the = ingress LSR for that AS must use a decryption key to obtain the = expansion (implying an earlier exchange or configuration).The major = differences between the mechanisms involve (1) additional control = messages, (2) performance issues expanding those objects, (3) the = addition of state to the PCE, (4) the solution scope (i.e. applicability = to various topologies of each solution.), and (5) the size of objects = added to existing messages.

(1) Additional = Control Message Overhead:

The PKS = solution requires a mechanism to expand the Path Key upon receipt of the = LSP setup request. Since the PCE which calculated the Path Key might not = reside in the entry boundary LSR, the LSR must request the expansion = from the PCE, requiring an additional message exchange before LSP setup = can proceed. The Path Encryption solution does not require this extra = exchange between the PCE and the ingress node for every LSP. Rather, the = decryption key needs to be exchanged only when it is changed. The result = is additional delay during every LSP setup for the PKS solution but no = additional delay for the PRS solution.

(2) PCE and LSR Performance:The PKS = solution must maintain a (temporary) database of keys adding overhead to = the PCE. The PRS solution requires the encryption of the CPS in the PCE = and decryption of the CPS in the LSR, which could be CPU intensive. Note = that in case of a burst of requests, encryption of large number of CPS = may have an impact on the PCE response time.(3) Addition = of State in the PCE:

The PKS = solution requires the addition of path-specific state and maintenance of = a database in the PCE. The PRS solution requires no additional = state.

(4) Solution = Scope:

The PKS and = PRS solutions both work well in conjunction with a PCE to encode and = decode the CPS. However the PKS provides no direct solution without a = PCE. This prevents the PKS solution for working in the case where A's = network straddles B's network and where A wants to use an ERO for a = segment of the LSP across the intervening network, e.g. = (netA)-(netB)-(netA). In addition, the PRS could be used to record a CPS = even if the path (and therefore the returned RRO) crosses multiple = boundaries. Finally, a PRS solution could be adapted to return actual = failure locations in PERRs and/or PATHTEARs, while keeping the failure = location confidential from LSRs without a decryption key. Currently = privacy of this source is maintained by returning the address of border = nodes, which can be very misleading.

(5) Message Object Overhead:The PKS = solution provides a very compact key or token to identify a path = segment, which generally allows for smaller EROs to be returned by the = PCE and to be requested in the resulting PATH message. A PRS which = contains a CPS must generally be at least as large as the unencrypted = PATH through the AS and may be significantly larger if it is desirable = to hide the number of hops within the network from external view by = padding the PRS. The result is potentially larger PATH (and PCEP) = messages for the PRS solution.

Please note = that the tradeoffs listed here are for the current I-D. Some of the = shortcomings of each approach could be mitigated by = implementation-specific optimizations. For example, a PCE could choose = to signal the CPS expansion to the entry boundary LSR, shifting the = burden of maintaining the PKS state to the LSR and eliminating the = performance hit during LSP setup. A similar exchange could be performed = for the PRS case, eliminating the need for a separate key exchange. = These examples of extensions are beyond the scope of the ID, but might = be useful when weighing the pros and cons of the two = solutions.

Pce mailing list


= --Apple-Mail-53-333433759-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Apr 2006 13:23:01 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C669FD.758FF101" Subject: RE: [Pce] Comparison of Encryption vs. Path Key Solutions for the CPSID. Date: Thu, 27 Apr 2006 15:21:17 +0200 Message-ID: Thread-Topic: [Pce] Comparison of Encryption vs. Path Key Solutions for the CPSID. Thread-Index: AcZZeTyqrqoHE6qtR3mCIGZZDDyHhAL5DdwgAJosi6AAi6EtcA== From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Rich Bradford \(rbradfor\)" , "Jean Philippe Vasseur \(jvasseur\)" Cc: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C669FD.758FF101 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Richard, =20 Please see inline, ________________________________ De : Rich Bradford (rbradfor) [mailto:rbradfor@cisco.com]=20 Envoy=E9 : lundi 24 avril 2006 20:06 =C0 : LE ROUX Jean-Louis RD-CORE-LAN; Jean Philippe Vasseur (jvasseur) Cc : ccamp@ops.ietf.org; pce@ietf.org Objet : RE: [Pce] Comparison of Encryption vs. Path Key Solutions for = the CPSID. =09 =09 JL, Thanks for the reply. It's always difficult to choose between multiple = solutions when there are so many tradeoffs between the solutions. =20 =20 Regarding the optimization where the PCE sends the LSR the unsolicited = computed path segment. It was a difficult choice whether or not to = include a description of this in the original draft, since it is more = complex. Which aspect of the optimization seemed most important? Was it = that it's more efficient during LSP setup or because it could be used to = shift the burden of maintaining state from the PCE to the LSR?=20 =20 IMO the most important optimization is the gain in LSP setup time, = which may be significant, and this is of particular =20 importance during end-to-end LSP restoration upon failure. Let's assume an inter-AS path computation with an AS-path length =3D N: -Without this optimization the LSP signaling time would be N* = Intra-AS-RSVP-sig + N* LSR-PCE exchanges. -With this optimization the LSP signaling time would be N* = Intra-AS-RSVP-sig Hence the gain in signaling time is N*LSR-PCE exchanges. And the good thing is that the path computation time would not be = impacted at all by this procedure as the PCE-LSR unsolicited = notification is done in // with the BRPC procedure. =20 There may be one minor con: During the BRPC you don't know a priori = which path segment will finally be selected, hence you need to send the = path segment to all ASBR LSRs connected to the upstream AS...but this is = a minor issue, because there are not so many ASBRs connected to the = upstream AS (two or three). You will have to remove the information on = the ASBR if no Path message is received after the expiration of a = timer... =20 Regards, =20 JL =20 =20 =20 =20 =20 =20 =20 =20 Thanks once again for your opinion.=20 Best Regards, Rich =20 =09 ________________________________ From: LE ROUX Jean-Louis RD-CORE-LAN = [mailto:jeanlouis.leroux@francetelecom.com]=20 Sent: Friday, April 21, 2006 12:51 PM To: Jean Philippe Vasseur (jvasseur); Rich Bradford (rbradfor) Cc: ccamp@ops.ietf.org; pce@ietf.org Subject: RE: [Pce] Comparison of Encryption vs. Path Key Solutions for = the CPSID. =20 Hi JP, Richard =20 Please see inline, =20 =09 ________________________________ De : JP Vasseur [mailto:jvasseur@cisco.com]=20 Envoy=E9 : jeudi 6 avril 2006 14:52 =C0 : Rich Bradford Cc : ccamp@ops.ietf.org; pce@ietf.org Objet : Re: [Pce] Comparison of Encryption vs. Path Key Solutions for = the CPSID. Hi,=20 =20 Thanks for the summary Rich. =20 PCE WG members: thanks to provide your feedback on whether: (1) You think that there is a need for such solution,=20 =20 Yes definitely, confidentiality is a key requirements in an = inter-provider context. =20 (2) You would prefer one solution (which one and why ?)=20 =20 (3) You think that there is a need for both=20 =20 Answer to (2) and (3): It seems to me that we should end-up with a single solution so as to = ease interworking. IMO in an inter-AS MPLS-TE environment without PCEs, the paths will be = loose anyway, so there will not be any confidentiality issue.=20 If have some concerns regarding the cost of encryption, particularly = for large paths (we need to think about future P2MP applications with a = large number of hops...). By the way, encryption approaches are really = vulnerable to DoS attacks. Hence I would strongly favor the PKS solution. The optimization = suggested, which consists of sending the computed path segment to the = LSR in an unsolicited manner, just after the computation, sounds = relevant and should be further investigated. =20 Best Regards, =20 JL =20 =20 =20 =20 Thanks. =20 JP. =20 On Apr 5, 2006, at 6:19 PM, Rich Bradford ((rbradfor)) wrote: =09 =09 =09 Hi, As suggested in Dallas, I've described some of the tradeoffs between = the two solutions described in = draft-rbradfor-ccamp-confidential-segment-00.txt. -- Rich The Confidential Path Segment (CPS) ID provides two very different but = equally valid solutions, the Path Key Subobject (PKS) solution and the = Private Route Subobject (PRS) solution. This note examines a number of = the advantages and disadvantages of each solution.=20 In short: The PKS solution allows a PCE to hide the CPS for an AS by = saving it in a database and replacing it with a key in the ERO. During = the LSP setup, the ingress LSR for that AS must query the PCE for an = expansion. The PRS solution allows a CPS for an AS to be hidden by encrypting it, = which may be done by a PCE or by the Head-End LSR. During the LSP setup, = the ingress LSR for that AS must use a decryption key to obtain the = expansion (implying an earlier exchange or configuration).=20 The major differences between the mechanisms involve (1) additional = control messages, (2) performance issues expanding those objects, (3) = the addition of state to the PCE, (4) the solution scope (i.e. = applicability to various topologies of each solution.), and (5) the size = of objects added to existing messages. (1) Additional Control Message Overhead: The PKS solution requires a mechanism to expand the Path Key upon = receipt of the LSP setup request. Since the PCE which calculated the = Path Key might not reside in the entry boundary LSR, the LSR must = request the expansion from the PCE, requiring an additional message = exchange before LSP setup can proceed. The Path Encryption solution does = not require this extra exchange between the PCE and the ingress node for = every LSP. Rather, the decryption key needs to be exchanged only when it = is changed. The result is additional delay during every LSP setup for = the PKS solution but no additional delay for the PRS solution. (2) PCE and LSR Performance: The PKS solution must maintain a (temporary) database of keys adding = overhead to the PCE. The PRS solution requires the encryption of the CPS = in the PCE and decryption of the CPS in the LSR, which could be CPU = intensive. Note that in case of a burst of requests, encryption of large = number of CPS may have an impact on the PCE response time. (3) Addition of State in the PCE: The PKS solution requires the addition of path-specific state and = maintenance of a database in the PCE. The PRS solution requires no = additional state. (4) Solution Scope: The PKS and PRS solutions both work well in conjunction with a PCE to = encode and decode the CPS. However the PKS provides no direct solution = without a PCE. This prevents the PKS solution for working in the case = where A's network straddles B's network and where A wants to use an ERO = for a segment of the LSP across the intervening network, e.g. = (netA)-(netB)-(netA). In addition, the PRS could be used to record a CPS = even if the path (and therefore the returned RRO) crosses multiple = boundaries. Finally, a PRS solution could be adapted to return actual = failure locations in PERRs and/or PATHTEARs, while keeping the failure = location confidential from LSRs without a decryption key. Currently = privacy of this source is maintained by returning the address of border = nodes, which can be very misleading. (5) Message Object Overhead: The PKS solution provides a very compact key or token to identify a = path segment, which generally allows for smaller EROs to be returned by = the PCE and to be requested in the resulting PATH message. A PRS which = contains a CPS must generally be at least as large as the unencrypted = PATH through the AS and may be significantly larger if it is desirable = to hide the number of hops within the network from external view by = padding the PRS. The result is potentially larger PATH (and PCEP) = messages for the PRS solution. Please note that the tradeoffs listed here are for the current I-D. = Some of the shortcomings of each approach could be mitigated by = implementation-specific optimizations. For example, a PCE could choose = to signal the CPS expansion to the entry boundary LSR, shifting the = burden of maintaining the PKS state to the LSR and eliminating the = performance hit during LSP setup. A similar exchange could be performed = for the PRS case, eliminating the need for a separate key exchange. = These examples of extensions are beyond the scope of the ID, but might = be useful when weighing the pros and cons of the two solutions. _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce =20 ------_=_NextPart_001_01C669FD.758FF101 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Richard,
 
Please see inline,

De : Rich Bradford (rbradfor) = [mailto:rbradfor@cisco.com]
Envoy=E9 : lundi 24 avril = 2006=20 20:06
=C0 : LE ROUX Jean-Louis RD-CORE-LAN; Jean = Philippe Vasseur=20 (jvasseur)
Cc : ccamp@ops.ietf.org;=20 pce@ietf.org
Objet : RE: [Pce] Comparison of Encryption = vs.=20 Path Key Solutions for the CPSID.

JL,

Thanks=20 for the reply. It=92s always difficult to choose between multiple = solutions when=20 there are so many tradeoffs between the solutions. =20

 

Regarding = the=20 optimization where the PCE sends the LSR the unsolicited computed path = segment.  It was a difficult choice whether or not to include a=20 description of this in the original draft, since it is more complex. = Which=20 aspect of the optimization seemed most important? Was it that it=92s = more=20 efficient during LSP setup or because it could be used to shift the = burden of=20 maintaining state from the PCE to the LSR? 

 

IMO the most important = optimization=20 is the gain in LSP setup time, which may be significant, and = this is=20 of particular 

importance during end-to-end = LSP=20 restoration upon failure.

Let's assume an inter-AS = path=20 computation with an AS-path length =3D = N:

-Without this optimization = the LSP=20 signaling time would be N* Intra-AS-RSVP-sig + N* LSR-PCE=20 exchanges.

-With this optimization the = LSP=20 signaling time would be N* = Intra-AS-RSVP-sig

Hence the gain in signaling = time is=20 N*LSR-PCE exchanges.

And the good thing = is that the=20 path computation time would not be impacted at all by this = procedure as=20 the PCE-LSR unsolicited notification is done in // with the BRPC=20 procedure.

 

There may be one minor con:=20 During the BRPC you don't = know a priori=20 which path segment will finally be selected, hence you need to send = the path=20 segment to all ASBR LSRs connected to the upstream AS...but = this is=20 a minor issue, because there are not so many ASBRs connected to the = upstream=20 AS (two or three). You will have to remove the information = on the=20 ASBR if no Path message is received after the expiration of a=20 timer...

 

Regards,

 

JL

 

 

 

 

 

 

 

 <= /P>

Thanks=20 once again for your opinion.

Best=20 Regards,

 =20 Rich

 

From:=20 LE ROUX Jean-Louis=20 RD-CORE-LAN=20 [mailto:jeanlouis.leroux@francetelecom.com]
Sent: Friday, April 21, 2006 = 12:51=20 PM
To: Jean = Philippe Vasseur=20 (jvasseur); Rich Bradford (rbradfor)
Cc: ccamp@ops.ietf.org;=20 pce@ietf.org
Subject: RE:=20 [Pce] Comparison of Encryption vs. Path Key Solutions for the=20 CPSID.

 

Hi JP,=20 Richard

 

Please see=20 inline,

 

De : JP Vasseur=20 [mailto:jvasseur@cisco.com]
Envoy=E9 : jeudi 6 avril = 2006=20 14:52
=C0 : = Rich=20 Bradford
Cc :=20 ccamp@ops.ietf.org; pce@ietf.org
Objet : Re: [Pce] = Comparison of=20 Encryption vs. Path Key Solutions for the CPSID.

Hi,

 

Thanks for the summary=20 Rich.

 

PCE WG members: thanks to provide your = feedback on=20 whether:

(1) You think that there is a need for = such=20 solution, 

 

Yes = definitely,=20 confidentiality is a key requirements in an inter-provider=20 context.

 

(2) You would prefer one solution (which = one and why=20 ?) 

 

(3) You think that there is a need for=20 both 

 

Answer to = (2) and=20 (3):

It seems = to me that=20 we should end-up with a single solution so as to ease=20 interworking.

IMO in an=20 inter-AS MPLS-TE environment without PCEs, the paths will be loose=20 anyway, so there will not be any confidentiality = issue.=20

If have = some=20 concerns regarding the cost of encryption, particularly for = large paths=20 (we need to think about future P2MP applications with a large number = of=20 hops...). By the way, encryption approaches are really vulnerable to = DoS=20 attacks.

Hence = I would=20 strongly favor the PKS solution. The optimization = suggested, which=20 consists of sending the computed path segment to the LSR in an = unsolicited=20 manner, just after the computation, sounds relevant and should = be=20 further investigated.

 

Best=20 Regards,

 

JL

 

 

 

 

Thanks.

 

JP.

 

On Apr 5, 2006, at 6:19 PM, Rich Bradford=20 ((rbradfor)) wrote:



Hi,

As = suggested in=20 Dallas, = I=92ve=20 described some of the tradeoffs between the two solutions described = in=20 = draft-rbradfor-ccamp-confidential-segment-00.txt.

-- = Rich

The=20 Confidential Path Segment (CPS) ID provides two very different but = equally=20 valid solutions, the Path Key Subobject (PKS) solution and the = Private Route=20 Subobject (PRS) solution. This note examines a number of the = advantages and=20 disadvantages of each solution. =

In=20 short: The PKS solution allows a PCE to hide the CPS for an AS by = saving it=20 in a database and replacing it with a key in the ERO. During the LSP = setup,=20 the ingress LSR for that AS must query the PCE for an=20 expansion.

The PRS solution=20 allows a CPS for an AS to be hidden by encrypting it, which may be = done by a=20 PCE or by the Head-End LSR. During the LSP setup, the ingress LSR = for that=20 AS must use a decryption key to obtain the expansion (implying an = earlier=20 exchange or configuration).

The=20 major differences between the mechanisms involve (1) additional = control=20 messages, (2) performance issues expanding those objects, (3) the = addition=20 of state to the PCE, (4) the solution scope (i.e. applicability to = various=20 topologies of each solution.), and (5) the size of objects added to = existing=20 messages.

(1)=20 Additional Control Message = Overhead:

The PKS solution=20 requires a mechanism to expand the Path Key upon receipt of the LSP = setup=20 request. Since the PCE which calculated the Path Key might not = reside in the=20 entry boundary LSR, the LSR must request the expansion from the PCE, = requiring an additional message exchange before LSP setup can = proceed. The=20 Path Encryption solution does not require this extra exchange = between the=20 PCE and the ingress node for every LSP. Rather, the decryption key = needs to=20 be exchanged only when it is changed. The result is additional delay = during=20 every LSP setup for the PKS solution but no additional delay for the = PRS=20 solution.

(2) PCE and LSR=20 Performance:

The PKS solution=20 must maintain a (temporary) database of keys adding overhead to the = PCE. The=20 PRS solution requires the encryption of the CPS in the PCE and = decryption of=20 the CPS in the LSR, which could be CPU intensive. Note that in case = of a=20 burst of requests, encryption of large number of CPS may have an = impact on=20 the PCE response time.

(3)=20 Addition of State in the = PCE:

The PKS solution=20 requires the addition of path-specific state and maintenance of a = database=20 in the PCE. The PRS solution requires no additional=20 state.

(4) Solution=20 Scope:

The PKS and PRS=20 solutions both work well in conjunction with a PCE to encode and = decode the=20 CPS. However the PKS provides no direct solution without a PCE. This = prevents the PKS solution for working in the case where A's network=20 straddles B's network and where A wants to use an ERO for a segment = of the=20 LSP across the intervening network, e.g. (netA)-(netB)-(netA). In = addition,=20 the PRS could be used to record a CPS even if the path (and = therefore the=20 returned RRO) crosses multiple boundaries. Finally, a PRS solution = could be=20 adapted to return actual failure locations in PERRs and/or = PATHTEARs, while=20 keeping the failure location confidential from LSRs without a = decryption=20 key. Currently privacy of this source is maintained by returning the = address=20 of border nodes, which can be very=20 misleading.

(5)=20 Message Object Overhead:

The PKS solution=20 provides a very compact key or token to identify a path segment, = which=20 generally allows for smaller EROs to be returned by the PCE and to = be=20 requested in the resulting PATH message. A PRS which contains a CPS = must=20 generally be at least as large as the unencrypted PATH through the = AS and=20 may be significantly larger if it is desirable to hide the number of = hops=20 within the network from external view by padding the PRS. The result = is=20 potentially larger PATH (and PCEP) messages for the PRS=20 solution.

Please note that the = tradeoffs=20 listed here are for the current I-D. Some of the shortcomings of = each=20 approach could be mitigated by implementation-specific = optimizations. For=20 example, a PCE could choose to signal the CPS expansion to the entry = boundary LSR, shifting the burden of maintaining the PKS state to = the LSR=20 and eliminating the performance hit during LSP setup. A similar = exchange=20 could be performed for the PRS case, eliminating the need for a = separate key=20 exchange. These examples of extensions are beyond the scope of the = ID, but=20 might be useful when weighing the pros and cons of the two=20 solutions.

___________= ____________________________________

Pce mailing = list

Pce@lists.ietf.org

https://www1.ietf.org= /mailman/listinfo/pce

 

<= /BLOCKQUOTE> ------_=_NextPart_001_01C669FD.758FF101-- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Apr 2006 05:44:22 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=loWFEBEm50c6UvbYwCbs/wMWJVss3tPl7mWUyK4Zg4kKkgWBEJbhFxBzDEpAucLD; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Message-ID: <02f301c66994$8daadfe0$0500a8c0@jlucianilaptop> From: To: "Thomas D. Nadeau" Cc: "Adrian Farrel" , , , , Subject: MIB Dr. Review for draft-ietf-ccamp-gmpls-tc-mib-10.txt Date: Wed, 26 Apr 2006 20:50:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Tom, draft-ietf-ccamp-gmpls-tc-mib-10.txt same comment as before wrt the expiration date (this is the same draft that was there prior, so if you submit a new one, please bump the draft number -- if you prefer to leave the fix to the RFC editor that is fine also). Thanks, -Joan Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Apr 2006 05:42:44 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=apYXK8Y9cNTsspSQJTXAG0bABANK2tMJyp1/0j0e5eGhcDqVTtbswu3YI+78zK2d; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Message-ID: <02ef01c66994$5518c200$0500a8c0@jlucianilaptop> From: To: "Thomas D. Nadeau" Cc: "Adrian Farrel" , , , , Subject: MIB Dr. Review for draft-ietf-ccamp-gmpls-te-mib-15.txt Date: Wed, 26 Apr 2006 20:48:41 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Look great! Thanks, -Joan Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Apr 2006 05:41:30 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=fcCTFaeOVGRfbOvmmN1+x3NTxr1kYlNjqnIq1FKzYNwiFI2bamXvV/yhift7PlVu; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Message-ID: <02e901c66994$282dbc00$0500a8c0@jlucianilaptop> From: To: "Thomas D. Nadeau" Cc: "Adrian Farrel" , , , , Subject: MIB Dr. review for draft-ietf-ccamp-gmpls-lsr-mib-13.txt Date: Wed, 26 Apr 2006 20:47:25 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello Tom and Adrian, All MIBs compile with smilint and smicngPRO. Here are my few comments: draft-ietf-ccamp-gmpls-lsr-mib-13.txt (#1 should be taken care of the others are NITs and could probably be fixed by RFC Editor if you so choose.) 1) Think this was probably a place holder...but please just remove this: OBJECT gmplsLabelRowStatus SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "TDN QUestion" 2) NIT January 2003; " Please change this to: January 2003." 3) Informative References NIT: Change the order so references are in ascending order: Current order is: [RFC3472] [RFC3468] change to: [RFC3468] [RFC3472] NIT: Fix reference: Current: [RFC3468] Andersson, L., Swallow, G., "The Multiprotocol Label Switching (MPLS) Working Group decision on MPLS signaling protocols", RFC 3468, February 2003. Should be: [RFC3468] Andersson, L. and G. Swallow, "The Multiprotocol Label -- end -- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 27 Apr 2006 05:39:16 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Me7z6twCJKBRN2a71Lv5cwoO91hGNpl1Hog7k6+pSG4FVxaY3txQQN5XXRhjpFOA; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Message-ID: <02e301c66993$ae436840$0500a8c0@jlucianilaptop> From: To: "Thomas D. Nadeau" Cc: "Adrian Farrel" , , , , Subject: Re: MIB Dr. Review for draft-ietf-ccamp-gmpls-te-mib-14.txt Date: Wed, 26 Apr 2006 20:44:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi Tom, ----- Original Message ----- From: Thomas D. Nadeau To: Cc: Adrian Farrel ; ; ; ; Sent: Tuesday, April 25, 2006 1:40 PM Subject: Re: MIB Dr. Review for draft-ietf-ccamp-gmpls-te-mib-14.txt > > 9) I am still unclear about what objects can be supported within > > MPLS only. Was expecting to see this clarified in the conformance > > statements. There does seem to be more of a division here than > > in the GMPLS-LSR-STD-MIB. > > > > Could some clarification be made to this point? > > I guess I am confused. I am not sure why we have > to explain the reverse relationship. All of the objects herein > are for GMPLS only; none apply to MPLS-only TE entries. > So the objects that are supported by > MPLS-only TE entries should have no corresponding > objects in this MIB module. Tabular entries in this > MIB represent GMPLS entries only, and they also have > corresponding objects in say RFC3812. We also covered this > reciprocal relationship in the conformance statement before > as part of your previous comments RE: "should we > explain each object or explain that they ALL apply." > I was also confused. If there are no MPLS objects then the MIB is fine as is. Thanks, Joan Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 26 Apr 2006 19:52:05 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-15.txt Message-Id: Date: Wed, 26 Apr 2006 15:50:01 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base Author(s) : T. Nadeau, A. Farrel Filename : draft-ietf-ccamp-gmpls-te-mib-15.txt Pages : 60 Date : 2006-4-26 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Generalized Multiprotocol Label Switching (GMPLS) based traffic engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib-15.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-te-mib-15.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-te-mib-15.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-26121809.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-te-mib-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-te-mib-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-26121809.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 26 Apr 2006 19:51:58 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-lsr-mib-13.txt Message-Id: Date: Wed, 26 Apr 2006 15:50:01 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base Author(s) : T. Nadeau, A. Farrel Filename : draft-ietf-ccamp-gmpls-lsr-mib-13.txt Pages : 43 Date : 2006-4-26 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor a Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-13.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-lsr-mib-13.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-13.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-26121014.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-lsr-mib-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-26121014.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 26 Apr 2006 19:51:50 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-tc-mib-10.txt Message-Id: Date: Wed, 26 Apr 2006 15:50:01 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management Author(s) : T. Nadeau, A. Farrel Filename : draft-ietf-ccamp-gmpls-tc-mib-10.txt Pages : 9 Date : 2006-4-11 This document defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Generalized Multiprotocol Label Switching (GMPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in GMPLS related MIB modules that would otherwise define their own representations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-tc-mib-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-26120813.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-tc-mib-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-26120813.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Apr 2006 19:39:01 +0000 To: IETF-Announce From: The IESG Subject: Last Call: 'Link Management Protocol (LMP) Management Information Base (MIB)' to Proposed Standard (draft-ietf-ccamp-rfc4327bis) Reply-to: iesg@ietf.org CC: Message-Id: Date: Tue, 25 Apr 2006 15:38:06 -0400 The IESG has received a request from the Common Control and Measurement Plane WG to consider the following document: - 'Link Management Protocol (LMP) Management Information Base (MIB) ' 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 any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-05-09. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rfc4327bis-01.txt Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Apr 2006 18:10:51 +0000 Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6968853B-77E3-4A7C-A5EC-1655C05EA5B0@cisco.com> Cc: "Adrian Farrel" , , , , Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: MIB Dr. Review for draft-ietf-ccamp-gmpls-te-mib-14.txt Date: Tue, 25 Apr 2006 13:40:23 -0400 To: "" > Hello Tom and Adrian, > > Here are a few comments on > draft-ietf-ccamp-gmpls-te-mib-14.txt. > Thank you for the great updates. > > Thanks, > -Joan First, removed references to 4201, 4003 and 4420 that were added as per last email from Joan. Things are back to the original state WRT these. > Compiles with both smicngPRO and smilint. > > 1) There is a disconnect in the numbers under the > under gmplsTeGroup, was this intentional, if so, > please explain, otherwise, please correct it. > > 1.3.6.1.2.1.10.166.555.3.1 gmplsTeGroups [GMPLS-TE-STD-MIB]: > oid-value-assignment > 1.3.6.1.2.1.10.166.555.3.1.1 gmplsTunnelGroup [GMPLS-TE-STD-MIB]: > object-group > 1.3.6.1.2.1.10.166.555.3.1.2 gmplsTunnelSignaledGroup [GMPLS-TE- > STD-MIB]: > object-group > 1.3.6.1.2.1.10.166.555.3.1.3 gmplsTunnelScalarGroup [GMPLS-TE-STD- > MIB]: > object-group > 1.3.6.1.2.1.10.166.555.3.1.6 gmplsTunnelOptionalGroup [GMPLS-TE- > STD-MIB]: > object-group > 1.3.6.1.2.1.10.166.555.3.1.7 gmplsTeNotificationGroup [GMPLS-TE- > STD-MIB]: > notification-group > > > 2) Expiration date in the page header is incorrect > Nadeau and Farrel Expires April 2006 [Page 1] > > > 3) 1.1. Migration Strategy > "The gmplsTunnelLSPEncoding may be set to tunnelLspNotGmpls to > allow an > MPLS-TE LSP tunnel to benefit from the additional objects and > tables > of GMPLS-LSR-STD-MIB without supporting the GMPLS protocols. > > Think you mean, GMPLS-TE-STD-MIB in the latter part of the above > sentence. > > > 4) 1.1. Migration Strategy > "Textual conventions are defined in [RFC3811] and [GMPLSTCMIB]." > > There aren't any TCs from GMPLSTCMIB, but there are > from the IANA-GMPLS-TC-MIB, so perhaps adding IANA-GMPLS-TC-MIB to > this > statement would be appropriate. > > > 5) (NIT) 2. Terminology > > "These segment and cross-connect objects are defined in the MPLS > Label > Switch Router MIB (MPLS-LSR-STD-MIB) [RFC3813], but see also the > GMPLS Label Switch Router MIB (GMPLS-LSR-STD-MIB) [GMPLSLSRMIB] > for..." > > Please be sure to use "Label Switching Router" (and not Label Switch > Router). > > > 6) Typos: > gmplsTunnelLinkProtection > > This glag is set to indicate that the LSP should not use any > link layer protection. > > s/glag/flag > > shared > This flage is set to indicate that a shared link layer > > s/flage/flag > > > > 7) gmplsTunnelErrorEntry OBJECT-TYPE > > > The use of the term "discontinuity" implies that the counters > suffered a discontinuity,but the situation you are describing is > that another error occurred. Please rephrase this to something > like: > > "Note that systems which read the objects in this table one at > a time should read gmplsTunnelErrorLastTime prior to the first > object and after reading the last object of this table to > ensure that no additional errors occurred." > > > > 8) gmplsTunnelUnnumIf does not appear in the > ReadOnly Conformance. Fixed all of above. > > 9) I am still unclear about what objects can be supported within > MPLS only. Was expecting to see this clarified in the conformance > statements. There does seem to be more of a division here than > in the GMPLS-LSR-STD-MIB. > > Could some clarification be made to this point? I guess I am confused. I am not sure why we have to explain the reverse relationship. All of the objects herein are for GMPLS only; none apply to MPLS-only TE entries. So the objects that are supported by MPLS-only TE entries should have no corresponding objects in this MIB module. Tabular entries in this MIB represent GMPLS entries only, and they also have corresponding objects in say RFC3812. We also covered this reciprocal relationship in the conformance statement before as part of your previous comments RE: "should we explain each object or explain that they ALL apply." > 10) IANA-GMPLS-TC-MIB > > Would remove parts of the DESCRIPTION clauses which > refer to the GMPLS-TE-STD-MIB module. The reason is > that these TCs may eventually be used in other MIB modules > and since this particular module will be controlled by > IANA, these sort of statements don't appear in IANA > MIB Modules as far as I know. > > "This data type is used as the syntax of the > gmplsTunnelLSPEncoding object in the definition of > GMPLS-TE-STD-MIB's gmplsTunnelTable." > > "This data type is used as the syntax of the > gmplsTunnelSwitchingType object in the definition of > GMPLS-TE-STD-MIB's gmplsTunnelTable." > > "This data type is used as the syntax of the > gmplsTunnelGPid object in the definition of > GMPLS-TE-STD-MIB's gmplsTunnelTable." > > "This data type is used as the syntax of the > gmplsTunnelAdminStatusFlags object in the definition of > GMPLS-TE-STD-MIB's gmplsTunnelTable." > > > -- the end -- Done. I will re-compile/re-format the modules and post them to the ID repository now. Thanks Joan! --Tom Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Apr 2006 13:00:47 +0000 Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: multipart/alternative; boundary=Apple-Mail-19-159039474 Message-Id: Cc: ccamp@ops.ietf.org, "Rich Bradford ((rbradfor))" , Adrian Farrel From: JP Vasseur Subject: Re: [Pce] Comparison of Encryption vs. Path Key Solutions for the CPSID. Date: Tue, 25 Apr 2006 08:59:23 -0400 To: LE ROUX Jean-Louis RD-CORE-LAN , pce@ietf.org --Apple-Mail-19-159039474 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Hi, Thanks for your feed-back, suggesting to go ahead with one solution, =20 the PKS. Indeed, the proposed optimization could be specified in a =20 further revision (being optional). Others, any opinion ? Thanks. JP. On Apr 24, 2006, at 2:06 PM, Rich Bradford ((rbradfor)) wrote: > JL, > > Thanks for the reply. It=92s always difficult to choose between =20 > multiple solutions when there are so many tradeoffs between the =20 > solutions. > > > > Regarding the optimization where the PCE sends the LSR the =20 > unsolicited computed path segment. It was a difficult choice =20 > whether or not to include a description of this in the original =20 > draft, since it is more complex. Which aspect of the optimization =20 > seemed most important? Was it that it=92s more efficient during LSP =20= > setup or because it could be used to shift the burden of =20 > maintaining state from the PCE to the LSR? > > Thanks once again for your opinion. > > Best Regards, > > Rich > > > > From: LE ROUX Jean-Louis RD-CORE-LAN =20 > [mailto:jeanlouis.leroux@francetelecom.com] > Sent: Friday, April 21, 2006 12:51 PM > To: Jean Philippe Vasseur (jvasseur); Rich Bradford (rbradfor) > Cc: ccamp@ops.ietf.org; pce@ietf.org > Subject: RE: [Pce] Comparison of Encryption vs. Path Key Solutions =20 > for the CPSID. > > > > Hi JP, Richard > > > > Please see inline, > > > > De : JP Vasseur [mailto:jvasseur@cisco.com] > Envoy=E9 : jeudi 6 avril 2006 14:52 > =C0 : Rich Bradford > Cc : ccamp@ops.ietf.org; pce@ietf.org > Objet : Re: [Pce] Comparison of Encryption vs. Path Key Solutions =20 > for the CPSID. > > Hi, > > > > Thanks for the summary Rich. > > > > PCE WG members: thanks to provide your feedback on whether: > > (1) You think that there is a need for such solution, > > > > Yes definitely, confidentiality is a key requirements in an inter-=20 > provider context. > > > > (2) You would prefer one solution (which one and why ?) > > > > (3) You think that there is a need for both > > > > Answer to (2) and (3): > > It seems to me that we should end-up with a single solution so as =20 > to ease interworking. > > IMO in an inter-AS MPLS-TE environment without PCEs, the paths will =20= > be loose anyway, so there will not be any confidentiality issue. > > If have some concerns regarding the cost of encryption, =20 > particularly for large paths (we need to think about future P2MP =20 > applications with a large number of hops...). By the way, =20 > encryption approaches are really vulnerable to DoS attacks. > > Hence I would strongly favor the PKS solution. The optimization =20 > suggested, which consists of sending the computed path segment to =20 > the LSR in an unsolicited manner, just after the computation, =20 > sounds relevant and should be further investigated. > > > > Best Regards, > > > > JL > > > > > > > > > > Thanks. > > > > JP. > > > > On Apr 5, 2006, at 6:19 PM, Rich Bradford ((rbradfor)) wrote: > > > > > Hi, > > As suggested in Dallas, I=92ve described some of the tradeoffs =20 > between the two solutions described in draft-rbradfor-ccamp-=20 > confidential-segment-00.txt. > > -- Rich > > The Confidential Path Segment (CPS) ID provides two very different =20 > but equally valid solutions, the Path Key Subobject (PKS) solution =20 > and the Private Route Subobject (PRS) solution. This note examines =20 > a number of the advantages and disadvantages of each solution. > > In short: The PKS solution allows a PCE to hide the CPS for an AS =20 > by saving it in a database and replacing it with a key in the ERO. =20 > During the LSP setup, the ingress LSR for that AS must query the =20 > PCE for an expansion. > > The PRS solution allows a CPS for an AS to be hidden by encrypting =20 > it, which may be done by a PCE or by the Head-End LSR. During the =20 > LSP setup, the ingress LSR for that AS must use a decryption key to =20= > obtain the expansion (implying an earlier exchange or configuration). > > The major differences between the mechanisms involve (1) additional =20= > control messages, (2) performance issues expanding those objects, =20 > (3) the addition of state to the PCE, (4) the solution scope (i.e. =20 > applicability to various topologies of each solution.), and (5) the =20= > size of objects added to existing messages. > > (1) Additional Control Message Overhead: > > The PKS solution requires a mechanism to expand the Path Key upon =20 > receipt of the LSP setup request. Since the PCE which calculated =20 > the Path Key might not reside in the entry boundary LSR, the LSR =20 > must request the expansion from the PCE, requiring an additional =20 > message exchange before LSP setup can proceed. The Path Encryption =20 > solution does not require this extra exchange between the PCE and =20 > the ingress node for every LSP. Rather, the decryption key needs to =20= > be exchanged only when it is changed. The result is additional =20 > delay during every LSP setup for the PKS solution but no additional =20= > delay for the PRS solution. > > (2) PCE and LSR Performance: > > The PKS solution must maintain a (temporary) database of keys =20 > adding overhead to the PCE. The PRS solution requires the =20 > encryption of the CPS in the PCE and decryption of the CPS in the =20 > LSR, which could be CPU intensive. Note that in case of a burst of =20 > requests, encryption of large number of CPS may have an impact on =20 > the PCE response time. > > (3) Addition of State in the PCE: > > The PKS solution requires the addition of path-specific state and =20 > maintenance of a database in the PCE. The PRS solution requires no =20 > additional state. > > (4) Solution Scope: > > The PKS and PRS solutions both work well in conjunction with a PCE =20 > to encode and decode the CPS. However the PKS provides no direct =20 > solution without a PCE. This prevents the PKS solution for working =20 > in the case where A's network straddles B's network and where A =20 > wants to use an ERO for a segment of the LSP across the intervening =20= > network, e.g. (netA)-(netB)-(netA). In addition, the PRS could be =20 > used to record a CPS even if the path (and therefore the returned =20 > RRO) crosses multiple boundaries. Finally, a PRS solution could be =20 > adapted to return actual failure locations in PERRs and/or =20 > PATHTEARs, while keeping the failure location confidential from =20 > LSRs without a decryption key. Currently privacy of this source is =20 > maintained by returning the address of border nodes, which can be =20 > very misleading. > > (5) Message Object Overhead: > > The PKS solution provides a very compact key or token to identify a =20= > path segment, which generally allows for smaller EROs to be =20 > returned by the PCE and to be requested in the resulting PATH =20 > message. A PRS which contains a CPS must generally be at least as =20 > large as the unencrypted PATH through the AS and may be =20 > significantly larger if it is desirable to hide the number of hops =20 > within the network from external view by padding the PRS. The =20 > result is potentially larger PATH (and PCEP) messages for the PRS =20 > solution. > > Please note that the tradeoffs listed here are for the current I-D. =20= > Some of the shortcomings of each approach could be mitigated by =20 > implementation-specific optimizations. For example, a PCE could =20 > choose to signal the CPS expansion to the entry boundary LSR, =20 > shifting the burden of maintaining the PKS state to the LSR and =20 > eliminating the performance hit during LSP setup. A similar =20 > exchange could be performed for the PRS case, eliminating the need =20 > for a separate key exchange. These examples of extensions are =20 > beyond the scope of the ID, but might be useful when weighing the =20 > pros and cons of the two solutions. > > _______________________________________________ > > Pce mailing list > > Pce@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/pce > > > > --Apple-Mail-19-159039474 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 Hi,

Thanks for your feed-back, = suggesting to go ahead with one solution, the PKS. Indeed, the proposed = optimization could be specified in a further revision (being = optional).

Others, any opinion = ?

Thanks.

JP.

On = Apr 24, 2006, at 2:06 PM, Rich Bradford ((rbradfor)) wrote:

JL,Thanks for the reply. It=92s = always difficult to choose between multiple solutions when there are so = many tradeoffs between the solutions.=A0Regarding the optimization = where the PCE sends the LSR the unsolicited computed path segment. =A0It = was a difficult choice whether or not to include a description of this = in the original draft, since it is more complex. Which aspect of the = optimization seemed most important? Was it that it=92s more efficient = during LSP setup or because it could be used to shift the burden of = maintaining state from the PCE to the LSR?Thanks once again for your = opinion.

Best Regards,

=A0 Rich

From: LE ROUX Jean-Louis = RD-CORE-LAN [mailto:jeanlouis.leroux= @francetelecom.com]
Sent: Friday, April 21, 2006 12:51 PM
Jean Philippe = Vasseur (jvasseur); Rich Bradford (rbradfor)
ccamp@ops.ietf.org; pce@ietf.org
RE: [Pce] = Comparison of Encryption vs. Path Key Solutions for the = CPSID.

Hi JP, = Richard

=A0Please see = inline,

=

=A0

JP Vasseur [mailto:jvasseur@cisco.com] =
jeudi 6 avril = 2006 14:52
Rich = Bradford
ccamp@ops.ietf.org; pce@ietf.org
Re: [Pce] = Comparison of Encryption vs. Path Key Solutions for the = CPSID.

Hi,

=A0

Thanks for the summary Rich.=A0

PCE WG members: thanks to provide your = feedback on whether:

(1) You think that there is a need for such = solution,=A0=A0Yes definitely, = confidentiality is a key requirements in an inter-provider = context.

=A0

(2) You would prefer one solution (which one = and why ?)=A0=A0(3) You think that there is a need for = both=A0=A0Answer to (2) and = (3):

It seems to me that we = should end-up with a single solution so as to=A0ease = interworking.

IMO=A0in an inter-AS MPLS-TE environment without PCEs, the = paths will be loose anyway,=A0so there=A0will not be=A0any = confidentiality issue.

If have some concerns=A0regarding the cost of encryption, = particularly for large paths (we need to think about future P2MP = applications with a large number of hops...). By the way, encryption = approaches are really vulnerable to DoS = attacks.

Hence I=A0would = strongly favor the PKS solution. The optimization suggested,=A0which = consists of sending the computed path segment to the LSR in an = unsolicited manner, just after the computation,=A0sounds relevant and = should be further investigated.=A0Best = Regards,

=A0

JL

=A0

=A0

=A0

=A0

Thanks.

=A0

JP.

On Apr 5, 2006, at 6:19 PM, Rich Bradford = ((rbradfor)) wrote:


Hi,As suggested = in , I=92ve described some of the tradeoffs between the = two solutions described in = draft-rbradfor-ccamp-confidential-segment-00.txt.-- = RichThe = Confidential Path Segment (CPS) ID provides two very different but = equally valid solutions, the Path Key Subobject (PKS) solution and the = Private Route Subobject (PRS) solution. This note examines a number of = the advantages and disadvantages of each solution.In short: The = PKS solution allows a PCE to hide the CPS for an AS by saving it in a = database and replacing it with a key in the ERO. During the LSP setup, = the ingress LSR for that AS must query the PCE for an = expansion.

The PRS = solution allows a CPS for an AS to be hidden by encrypting it, which may = be done by a PCE or by the Head-End LSR. During the LSP setup, the = ingress LSR for that AS must use a decryption key to obtain the = expansion (implying an earlier exchange or configuration).The major = differences between the mechanisms involve (1) additional control = messages, (2) performance issues expanding those objects, (3) the = addition of state to the PCE, (4) the solution scope (i.e. applicability = to various topologies of each solution.), and (5) the size of objects = added to existing messages.

(1) Additional = Control Message Overhead:

The PKS = solution requires a mechanism to expand the Path Key upon receipt of the = LSP setup request. Since the PCE which calculated the Path Key might not = reside in the entry boundary LSR, the LSR must request the expansion = from the PCE, requiring an additional message exchange before LSP setup = can proceed. The Path Encryption solution does not require this extra = exchange between the PCE and the ingress node for every LSP. Rather, the = decryption key needs to be exchanged only when it is changed. The result = is additional delay during every LSP setup for the PKS solution but no = additional delay for the PRS solution.

(2) PCE and = LSR Performance:

The PKS = solution must maintain a (temporary) database of keys adding overhead to = the PCE. The PRS solution requires the encryption of the CPS in the PCE = and decryption of the CPS in the LSR, which could be CPU intensive. Note = that in case of a burst of requests, encryption of large number of CPS = may have an impact on the PCE response time.(3) Addition = of State in the PCE:

The PKS = solution requires the addition of path-specific state and maintenance of = a database in the PCE. The PRS solution requires no additional = state.

(4) Solution = Scope:

The PKS and = PRS solutions both work well in conjunction with a PCE to encode and = decode the CPS. However the PKS provides no direct solution without a = PCE. This prevents the PKS solution for working in the case where A's = network straddles B's network and where A wants to use an ERO for a = segment of the LSP across the intervening network, e.g. = (netA)-(netB)-(netA). In addition, the PRS could be used to record a CPS = even if the path (and therefore the returned RRO) crosses multiple = boundaries. Finally, a PRS solution could be adapted to return actual = failure locations in PERRs and/or PATHTEARs, while keeping the failure = location confidential from LSRs without a decryption key. Currently = privacy of this source is maintained by returning the address of border = nodes, which can be very misleading.

(5) Message = Object Overhead:

The PKS = solution provides a very compact key or token to identify a path = segment, which generally allows for smaller EROs to be returned by the = PCE and to be requested in the resulting PATH message. A PRS which = contains a CPS must generally be at least as large as the unencrypted = PATH through the AS and may be significantly larger if it is desirable = to hide the number of hops within the network from external view by = padding the PRS. The result is potentially larger PATH (and PCEP) = messages for the PRS solution.

Please note = that the tradeoffs listed here are for the current I-D. Some of the = shortcomings of each approach could be mitigated by = implementation-specific optimizations. For example, a PCE could choose = to signal the CPS expansion to the entry boundary LSR, shifting the = burden of maintaining the PKS state to the LSR and eliminating the = performance hit during LSP setup. A similar exchange could be performed = for the PRS case, eliminating the need for a separate key exchange. = These examples of extensions are beyond the scope of the ID, but might = be useful when weighing the pros and cons of the two = solutions.

Pce mailing list


= --Apple-Mail-19-159039474-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Apr 2006 09:15:27 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:subject:mime-version:content-type; b=bfgaKoN38YNx8bKoPy8kc6dWeRlw2qx182jgHNHGDQGU0s2wOsKTppVTuyiO+U7Qlyf5cmt+YLsVmCZAgEgLBM1/pyTNwVLIdWSwN1+pnHmgrmeZWG4/k1NyPAiHBvXSpWbg4f16PZ37XbBrJTgRiD34xzVV6lSNvrCNp1WJ8yE= Message-ID: Date: Tue, 25 Apr 2006 08:34:43 +0200 From: "shine west" Subject: HELLO!!!CONTACT US WINNER! MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_9876_16944524.1145946883903" ------=_Part_9876_16944524.1145946883903 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline EURO MILLIONS INTERNATIONAL AWARD/PROMOTIONAL DEPARTMENT AMSTERDAM, THE NETHERLANDS. EMAIL:transatlanti@netscape.net http://www.loteria.com/euro.php REF NUMBER:[DF/04679/ST] We are happy to inform you that your email address has been selected as one of the lucky email addresses in the category "B" of the online lotto conducted by EURO MILLIONS INTERNATIONAL. CONGRATULATIONS!!!! The EURO MILLIONS ESPANA was conducted by an automated computer balloting system, where by email addresses(30,000 email addresses),were extracted fro= m all continents of the world.A draw was held in different categories and winners emerged from different parts of the world and they are entitled to various cash prizes depending on their different categories.Thus ,you are entitled to a prize money of 466.812,79 Euros(Four hundred and sixty-six thousand, eight hundred and twelve euro,seventy-nine cent)only. winning numbers:8-16-19-43-45-1-4 Reference number:[LM/04679/TN] Ticket number:[754/22/76] As a category B winner, you have been selected by computer balloting system where only email addresses are soughted,from a total number of 30,000 email addresses drawn from all over the globe.After an automated computer ballot of our International Promotions Program, only ten winners emerged in this category and therefore you are to receive payout of 466.812,79 Euros.This promotional program takes place every year, and is promoted and sponsored! by EURO MILLIONS INTERNATIONAL,and other corporate organisations. This is to encourage the use of the internet and computers worldwide. To immediately claim your prize, please contact our fiduciary agent: below are the contact information of your fiiduciary agent: TRANSATLANTIC FINANCE AGENCY S.L =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 Mr.PAKER WHITE KONINGSHOEF 265, 1156 HT,AMSTERDAM, THE NETHERLANDS. TEL:0031-624-677-205 TEL:0031-847-533-420 EMAIL:transatlanti@netscape.net =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 In your best interest(s),you must initiate contact within one week of receipt of this correspondence. You are to provide the below details,to enable the speedy evaluation and processing of your winnings. we advice that you adhere strictly to their procedures to avoid any disqualifications and subsequent cancellation. 1. your full names 2. your full home / office address 3. direct telephone/fax numbers and email 4. fax copy of your identity card/driver's license The beneficiary is responsible for the(VETT/APPROVAL CHARGES)of his fund to his/her country.Your winning prize is not deductable until your winnings has been processed,approved and transfered to you by your claim agent above= , For verification on your lucky winning prize,you are to visit our online site (http://www.loteria.com/euro.php ) and indicate the date this email lottery programme draw of the EURO MILLIONS was held (30th of december 2005)and there you will find your result winning number.the late release of this result wa= s due to difficulties encountered in sorting out mixed up numbers and email addresses. We congratulate you once again and it is our hope that you participate in any of our international programs in the nearest future. Thank you. Sincerely, Maria Jose. Promotions Manager EMAIL:transatlanti@netscape.net -------------- ----------------------------------- This e-mail transmission contains information that is confidential and may be privileged.It is intended only for the addressee(s) named above. ------=_Part_9876_16944524.1145946883903 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
EURO MILLIONS INTERNATIONAL
AWARD/PROMOTIONAL DEPARTMENT
AMSTERDA= M, THE NETHERLANDS.
E= MAIL:transatlanti@netscape.net
http://www.loteria.com/euro.php
 
REF NUMBER:[DF/04679/ST]<= br> 
We are happy to inform you that your email address has been se= lected as
one of the lucky email addresses in the category "B"= ; of the online lotto=20
conducted by EURO MILLIONS INTERNATIONAL.
CONGRATULATIONS!!!!
Th= e EURO MILLIONS ESPANA was conducted by an automated computer balloting system, where by email addresses(30,000 email addresses),were extracted fr= om=20
all continents of the world.A draw was held in different categories and=
winners emerged from different parts of the world and they are entitle= d to
various cash prizes depending on their different categories.Thus ,you are entitled
to a prize money of 466.812,79 Euros(Four hundred an= d sixty-six thousand, eight
hundred and twelve euro,seventy-nine cent)o= nly.
winning numbers:8-16-19-43-45-1-4
Reference number:[LM/04679/TN= ]=20
Ticket number:[754/22/76]
 
As a category B winner, you hav= e been selected by computer balloting system where
only email addresses= are soughted,from a total number of 30,000 email addresses
drawn from = all over the=20 globe.After an automated computer ballot of our International
Promotion= s Program, only ten winners emerged in this category and therefore you are<= br>to receive payout of 466.812,79 Euros.This promotional program takes pla= ce every year,=20
and is promoted and sponsored! by EURO MILLIONS INTERNATIONAL,and other= corporate organisations.
This is to encourage the use of the internet a= nd computers worldwide.
To immediately claim your prize, please contact = our fiduciary agent:=20
below are the contact information of your fiiduciary agent:
TRANSATL= ANTIC FINANCE AGENCY S.L
=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
Mr.PAKER= WHITE
KONINGSHOEF 265,
1156 HT,AMSTERDAM,
THE NETHERLANDS.
TEL:0031-624-677-205
TEL:0031-847-533-420
EMAIL:transatlanti@netscape.net
=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
In your best interest(s),you must initiate contact= within one week of receipt=20
of this correspondence.
You are to provide the below details,to enab= le the speedy evaluation and
processing of your winnings. we advice that= you adhere strictly to their
procedures to avoid any disqualifications= and subsequent cancellation.=20
1. your full names
2. your full home / office address
3. direct= telephone/fax numbers and email
4. fax copy of your identity card/driv= er's license
The beneficiary is responsible for the(VETT/APPROVAL CHARGE= S)of his fund=20
to his/her country.Your winning prize is not deductable until your winn= ings
has been processed,approved and transfered to you by your claim age= nt above,
For verification on your lucky winning prize,you are to visit= our online site=20
(http://www.loteria.com/eur= o.php ) and indicate the date this email lottery
programme draw of = the EURO MILLIONS was held (30th of december 2005)and there
you will fi= nd your result winning=20 number.the late release of this result was due
to difficulties encounte= red in sorting out mixed up numbers and email addresses.
We congratulat= e you once again and it is our hope that you participate
in any of our = international programs in the nearest future.=20
Thank you.
Sincerely,
Maria Jose.
Promotions Manager
EMAIL:transatlanti@netscape.ne= t
-------------- -----------------------------------
This e-mail= transmission contains information that is confidential and may=20
be privileged.It is intended only for the addressee(s) named above.
------=_Part_9876_16944524.1145946883903-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Apr 2006 04:44:48 +0000 Message-ID: <022b01c66823$e62b2890$0e11a8c0@youref3aa80866> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Zafar Ali \(zali\)" , "Richard Rabbat" , "Don Fedyk" , "Filippo Cugini" , "Marco Ruffini" Cc: Subject: Re: GMPLS dynamics vs. issues with optical amplifiers Date: Tue, 25 Apr 2006 05:51:13 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi Zafar, While I agree with you as a likely deployment scenario, I must point out that PCE is architecturally not just like any other node in the network receiving flooding from peering nodes. The PCE architecture very clearly (and deliberately) states that the information on which the PCE operates may be limited to the IGP flooding information, may be enhanced from other sources (which could include configuration, inventory discovery, alarm management, network monitoring, etc.), or might be restricted to other sources (i.e. without listening to flooding). This is to say that the need to factor this information into the computations performed by PCE neither forces nor precludes the addition of the information to the flooding protocol. Cheers, Adrian ----- Original Message ----- From: "Zafar Ali (zali)" To: "Richard Rabbat" ; "Don Fedyk" ; "Filippo Cugini" ; "Adrian Farrel" ; "Marco Ruffini" Cc: Sent: Tuesday, April 25, 2006 5:32 AM Subject: RE: GMPLS dynamics vs. issues with optical amplifiers > -----Original Message----- > From: owner-ccamp@ops.ietf.org > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Richard Rabbat > Sent: Monday, April 10, 2006 11:55 AM > To: 'Don Fedyk'; 'Filippo Cugini'; 'Adrian Farrel'; 'Marco Ruffini' > Cc: ccamp@ops.ietf.org > Subject: RE: GMPLS dynamics vs. issues with optical amplifiers > > Hi, > There are pros and cons to advertising optical information > including lambda availability and optical impairements. > GMPLS is not supposed to replace advanced path computation > tools. Actually, an entity such as the PCE would be a perfect > piece in the architecture of a lambda network as it is > expected to provide advanced computation capabilities beyond CSPF. Richard, >From flooding view point, PCE is just like another node in the network receiving flooding from peering nodes. So in any case extension to the IGP protocol will be needed if we want to convey more optical information (e.g., optical impairements). Nonetheless, I am for exploring more in this area. Thanks Regards... Zafar > > Actually, we've been looking at some interop scenarii where > we are clearly in need for standardization and mentioned one > such scenario in > http://www.ietf.org/internet-drafts/draft-shiba-ccamp-gmpls-la mbda-labels-01 > .txt > > I think it's time to do a proper analysis of what support > already exists, what is still needed and work on extensions > (if needed) to support the new generation of ROADM and PXC > devices where interop is required. > A few vendors who build ROADMs and PXCs, as well as SPs > deploying them have expressed interest in this topic when we > discussed the 1st version at CCAMP. > I think it's time to sit down and take a stab at it so we > have an interesting draft to discuss in Montreal. > Send me email if you have some cycles to spare on this topic. > Richard. > > > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Don Fedyk > > Sent: Monday, April 10, 2006 8:05 AM > > To: Filippo Cugini; Adrian Farrel; Marco Ruffini > > Cc: ccamp@ops.ietf.org > > Subject: RE: GMPLS dynamics vs. issues with optical amplifiers > > > > > > Hi all > > > > About a year ago we started to collect requirements for towards this > > area in a draft. Our current thinking is that the optical/photonic > > networks will have fairly proprietary ways of dealing with the > > non-linear properties but that the interface to GMPLS can be > > summarized > > as a fairly generic network interface with a simple metric and a > > blocking capability. We only got as far a the requirements. > The draft > > is in in need of a refresh I will try to do that shortly. I have to > > contact some other people who were interested in the area. > > > > If you cannot find a copy of the draft I will send it to you. > > > > draft-ashwood-ccamp-gmpls-constraint-reqts-00 > > > > Regards, > > Don > > > > > > > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Filippo Cugini > > > > > > > > > Hi all, > > > > > > IMO the issue will have to be faced soon. Transparent network > > > elements such > > > as ROADM and PXC are beginning to be deployed in optical > > > transport networks. However, the current GMPLS does not > > > provide any functionality to keep track > > > of the signal quality degradation. Thus, transparent mesh > > > networks must be > > > statically designed, during the network planning, to > > > guarantee that even the > > > most impaired connection (e.g., the longest path) is > > > acceptable. Otherwise, > > > because of the current GMPLS limits, connections can > > > successfully be set up > > > even if they do not comply with physical parameters > > > constraints. However, the worst case design approach heavily > > > limits the size of the > > > transparent networks. > > > > > > Filippo > > > > > > > > > ----- Original Message ----- > > > From: "Adrian Farrel" > > > > [..] > > > > - There *might* be a future requirement to signal certain > > > > constraints, but we would need to see the requirements clearly > > > > stated. > > > > - There is probably a need to enhance the advertisement of > > > > some key physical attributes of optical links and nodes in > > > > the IGPs. At the moment, however, this information > > > > appears to be gathered through inventory systems and > > > > there has been very little consideration of this requirement. > > > > > > > > > > > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Apr 2006 04:34:11 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: GMPLS dynamics vs. issues with optical amplifiers Date: Tue, 25 Apr 2006 00:32:29 -0400 Message-ID: Thread-Topic: GMPLS dynamics vs. issues with optical amplifiers Thread-Index: AcZct0uhDoNv1DUrSRirfsZJqo242QLaJq7g From: "Zafar Ali \(zali\)" To: "Richard Rabbat" , "Don Fedyk" , "Filippo Cugini" , "Adrian Farrel" , "Marco Ruffini" Cc: > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Richard Rabbat > Sent: Monday, April 10, 2006 11:55 AM > To: 'Don Fedyk'; 'Filippo Cugini'; 'Adrian Farrel'; 'Marco Ruffini' > Cc: ccamp@ops.ietf.org > Subject: RE: GMPLS dynamics vs. issues with optical amplifiers >=20 > Hi, > There are pros and cons to advertising optical information=20 > including lambda availability and optical impairements. =20 > GMPLS is not supposed to replace advanced path computation=20 > tools. Actually, an entity such as the PCE would be a perfect=20 > piece in the architecture of a lambda network as it is=20 > expected to provide advanced computation capabilities beyond CSPF. Richard,=20 >From flooding view point, PCE is just like another node in the network receiving flooding from peering nodes. So in any case extension to the IGP protocol will be needed if we want to convey more optical information (e.g., optical impairements).=20 Nonetheless, I am for exploring more in this area.=20 Thanks Regards... Zafar=20 > > Actually, we've been looking at some interop scenarii where=20 > we are clearly in need for standardization and mentioned one=20 > such scenario in > http://www.ietf.org/internet-drafts/draft-shiba-ccamp-gmpls-la mbda-labels-01 > .txt > > I think it's time to do a proper analysis of what support=20 > already exists, what is still needed and work on extensions=20 > (if needed) to support the new generation of ROADM and PXC=20 > devices where interop is required. > A few vendors who build ROADMs and PXCs, as well as SPs=20 > deploying them have expressed interest in this topic when we=20 > discussed the 1st version at CCAMP. > I think it's time to sit down and take a stab at it so we=20 > have an interesting draft to discuss in Montreal. > Send me email if you have some cycles to spare on this topic. > Richard. > =20 >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org=20 > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Don Fedyk > > Sent: Monday, April 10, 2006 8:05 AM > > To: Filippo Cugini; Adrian Farrel; Marco Ruffini > > Cc: ccamp@ops.ietf.org > > Subject: RE: GMPLS dynamics vs. issues with optical amplifiers > >=20 > >=20 > > Hi all > >=20 > > About a year ago we started to collect requirements for towards this > > area in a draft. Our current thinking is that the optical/photonic > > networks will have fairly proprietary ways of dealing with the > > non-linear properties but that the interface to GMPLS can be=20 > > summarized > > as a fairly generic network interface with a simple metric and a > > blocking capability. We only got as far a the requirements.=20 > The draft > > is in in need of a refresh I will try to do that shortly. I have to > > contact some other people who were interested in the area.=20 > >=20 > > If you cannot find a copy of the draft I will send it to you.=20 > >=20 > > draft-ashwood-ccamp-gmpls-constraint-reqts-00 > >=20 > > Regards, > > Don=20 > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: owner-ccamp@ops.ietf.org=20 > > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Filippo Cugini > > >=20 > > >=20 > > > Hi all, > > >=20 > > > IMO the issue will have to be faced soon. Transparent network=20 > > > elements such=20 > > > as ROADM and PXC are beginning to be deployed in optical=20 > > > transport networks. However, the current GMPLS does not=20 > > > provide any functionality to keep track=20 > > > of the signal quality degradation. Thus, transparent mesh=20 > > > networks must be=20 > > > statically designed, during the network planning, to=20 > > > guarantee that even the=20 > > > most impaired connection (e.g., the longest path) is=20 > > > acceptable. Otherwise,=20 > > > because of the current GMPLS limits, connections can=20 > > > successfully be set up=20 > > > even if they do not comply with physical parameters=20 > > > constraints. However, the worst case design approach heavily=20 > > > limits the size of the=20 > > > transparent networks. > > >=20 > > > Filippo > > >=20 > > >=20 > > > ----- Original Message -----=20 > > > From: "Adrian Farrel" > > > > [..] > > > > - There *might* be a future requirement to signal certain > > > > constraints, but we would need to see the requirements clearly > > > > stated. > > > > - There is probably a need to enhance the advertisement of > > > > some key physical attributes of optical links and nodes in > > > > the IGPs. At the moment, however, this information > > > > appears to be gathered through inventory systems and > > > > there has been very little consideration of this requirement. > > >=20 > > >=20 > > >=20 > >=20 > >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 25 Apr 2006 00:25:41 +0000 To: "Fahad Dogar" Cc: ccamp@ops.ietf.org, gels@rtg.ietf.org Subject: Re: GMPLS support for Ethernet switching MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Tue, 25 Apr 2006 02:24:30 +0200 Content-Type: text/plain; charset="US-ASCII" hi - see in-line (i put gels mailing list in cc.) "Fahad Dogar" Sent by: owner-ccamp@ops.ietf.org 24/04/2006 16:36 To: ccamp@ops.ietf.org cc: Subject: GMPLS support for Ethernet switching Hi all, I have few questions related to the draft on GMPLS support for Ethernet switching by D.Papadimitriou et al.: i) The draft discusses that connection oriented ethernet is suitable for metro and core networks where ethernet is used for transport. I am not too clear on the architecture in which ethernet LSPs would be used. Are we considering point to point type ethernet connections between switches/routers i.e. where the bandwidth is not shared. Example: Two peer routers connected through an ethernet interface, so effectively complete bandwidth is available. [dp] this would be either a port based ethernet LSP, supported today in RFC 3473/3471 no specific issue or a frame based ethernet LSP this is where different labeling techniques have been proposed; Or are we talking about multiple switches in a GMPLS enabled cloud that are part of the SAME LAN and bandwidth is shared. I am not sure how bandwidth reservations would be done in this sceneario. [dp] we are not talking about LAN environments ii) Please correct me if I am wrong but it seems that the traffic engineering benefits of GMPLS support for Ethernet are also available in Ethernet over MPLS. (I am considering that connection oriented Ethernet is used in metro/core networks only). However, by providing GMPLS support for Ethernet we are able to do away with IP/MPLS layer and thus we can have an all Ethernet network (with only ethernet switches). Is this the primary reason for using GMPLS support for Ethernet rather than Ethernet over MPLS? Can someone comment on this? [dp] this approach intends to deliver source routed TE label switched path establishment (through control plane upgrade) for metro/aggregation and core Ethernet networks iii) The draft discusses various options for ethernet label, all of which seem to require modification in the forwarding plane of Ethernet? Is this something that can implemented easily i.e. change in forwarding plane? Why can't we consider MAC address or VLAN tag as the label? [dp] this question has been lengthily debated on the GELS mailing list, (i refer you there as well as to last meeting discussion material) [dp] in brief, and as of today, SVID labels (using SVID translation) and MAC+SVID label (using SVL switches) are two feasible techniques for the .1ad environments Thanks in advance, Fahad Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Apr 2006 23:25:00 +0000 Message-ID: <017201c667f7$1f6bcf60$0e11a8c0@youref3aa80866> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Fahad Dogar" , Subject: Re: GMPLS support for Ethernet switching Date: Mon, 24 Apr 2006 23:58:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit Hi, Thanks for raising these questions, and I hope Dimitri et al. will respond. However, the discussion should take place on the GELS mailing list. Thanks, Adrian ----- Original Message ----- From: "Fahad Dogar" To: Sent: Monday, April 24, 2006 3:36 PM Subject: GMPLS support for Ethernet switching Hi all, I have few questions related to the draft on GMPLS support for Ethernet switching by D.Papadimitriou et al.: i) The draft discusses that connection oriented ethernet is suitable for metro and core networks where ethernet is used for transport. I am not too clear on the architecture in which ethernet LSPs would be used. Are we considering point to point type ethernet connections between switches/routers i.e. where the bandwidth is not shared. Example: Two peer routers connected through an ethernet interface, so effectively complete bandwidth is available. Or are we talking about multiple switches in a GMPLS enabled cloud that are part of the SAME LAN and bandwidth is shared. I am not sure how bandwidth reservations would be done in this sceneario. ii) Please correct me if I am wrong but it seems that the traffic engineering benefits of GMPLS support for Ethernet are also available in Ethernet over MPLS. (I am considering that connection oriented Ethernet is used in metro/core networks only). However, by providing GMPLS support for Ethernet we are able to do away with IP/MPLS layer and thus we can have an all Ethernet network (with only ethernet switches). Is this the primary reason for using GMPLS support for Ethernet rather than Ethernet over MPLS? Can someone comment on this? iii) The draft discusses various options for ethernet label, all of which seem to require modification in the forwarding plane of Ethernet? Is this something that can implemented easily i.e. change in forwarding plane? Why can't we consider MAC address or VLAN tag as the label? Thanks in advance, Fahad Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Apr 2006 19:51:07 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-ethernet-traffic-parameters-00.txt Message-Id: Date: Mon, 24 Apr 2006 15:50:01 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : MEF Ethernet Traffic Parameters Author(s) : D. Papadimitriou Filename : draft-ietf-ccamp-ethernet-traffic-parameters-00.txt Pages : 9 Date : 2006-4-24 This document described the Metro Ethernet Forum (MEF) - specific Ethernet Traffic Parameters as described in MEF.10 when using Generalized Multi-Protocol Label Switching (GMPLS) Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-ethernet-traffic-parameters-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-ethernet-traffic-parameters-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-ethernet-traffic-parameters-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-24145011.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-ethernet-traffic-parameters-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-ethernet-traffic-parameters-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-24145011.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Apr 2006 18:07:34 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C667C9.BF3F36CD" Subject: RE: [Pce] Comparison of Encryption vs. Path Key Solutions for the CPSID. Date: Mon, 24 Apr 2006 14:06:01 -0400 Message-ID: <3C292CE901FC634693F24FB2DDC4D33201601C11@xmb-rtp-20d.amer.cisco.com> Thread-Topic: [Pce] Comparison of Encryption vs. Path Key Solutions for the CPSID. Thread-Index: AcZZeTyqrqoHE6qtR3mCIGZZDDyHhAL5DdwgAJosi6A= From: "Rich Bradford \(rbradfor\)" To: "LE ROUX Jean-Louis RD-CORE-LAN" , "Jean Philippe Vasseur \(jvasseur\)" Cc: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C667C9.BF3F36CD Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SkwsDQoNClRoYW5rcyBmb3IgdGhlIHJlcGx5LiBJdOKAmXMgYWx3YXlzIGRpZmZpY3VsdCB0byBj aG9vc2UgYmV0d2VlbiBtdWx0aXBsZSBzb2x1dGlvbnMgd2hlbiB0aGVyZSBhcmUgc28gbWFueSB0 cmFkZW9mZnMgYmV0d2VlbiB0aGUgc29sdXRpb25zLiAgDQoNCiANCg0KUmVnYXJkaW5nIHRoZSBv cHRpbWl6YXRpb24gd2hlcmUgdGhlIFBDRSBzZW5kcyB0aGUgTFNSIHRoZSB1bnNvbGljaXRlZCBj b21wdXRlZCBwYXRoIHNlZ21lbnQuICBJdCB3YXMgYSBkaWZmaWN1bHQgY2hvaWNlIHdoZXRoZXIg b3Igbm90IHRvIGluY2x1ZGUgYSBkZXNjcmlwdGlvbiBvZiB0aGlzIGluIHRoZSBvcmlnaW5hbCBk cmFmdCwgc2luY2UgaXQgaXMgbW9yZSBjb21wbGV4LiBXaGljaCBhc3BlY3Qgb2YgdGhlIG9wdGlt aXphdGlvbiBzZWVtZWQgbW9zdCBpbXBvcnRhbnQ/IFdhcyBpdCB0aGF0IGl04oCZcyBtb3JlIGVm ZmljaWVudCBkdXJpbmcgTFNQIHNldHVwIG9yIGJlY2F1c2UgaXQgY291bGQgYmUgdXNlZCB0byBz aGlmdCB0aGUgYnVyZGVuIG9mIG1haW50YWluaW5nIHN0YXRlIGZyb20gdGhlIFBDRSB0byB0aGUg TFNSPw0KDQpUaGFua3Mgb25jZSBhZ2FpbiBmb3IgeW91ciBvcGluaW9uLiANCg0KQmVzdCBSZWdh cmRzLA0KDQogIFJpY2gNCg0KIA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K DQpGcm9tOiBMRSBST1VYIEplYW4tTG91aXMgUkQtQ09SRS1MQU4gW21haWx0bzpqZWFubG91aXMu bGVyb3V4QGZyYW5jZXRlbGVjb20uY29tXSANClNlbnQ6IEZyaWRheSwgQXByaWwgMjEsIDIwMDYg MTI6NTEgUE0NClRvOiBKZWFuIFBoaWxpcHBlIFZhc3NldXIgKGp2YXNzZXVyKTsgUmljaCBCcmFk Zm9yZCAocmJyYWRmb3IpDQpDYzogY2NhbXBAb3BzLmlldGYub3JnOyBwY2VAaWV0Zi5vcmcNClN1 YmplY3Q6IFJFOiBbUGNlXSBDb21wYXJpc29uIG9mIEVuY3J5cHRpb24gdnMuIFBhdGggS2V5IFNv bHV0aW9ucyBmb3IgdGhlIENQU0lELg0KDQogDQoNCkhpIEpQLCBSaWNoYXJkDQoNCiANCg0KUGxl YXNlIHNlZSBpbmxpbmUsDQoNCgkgDQoNCgkNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQoNCg0KCURlIDogSlAgVmFzc2V1ciBbbWFpbHRvOmp2YXNzZXVyQGNpc2NvLmNvbV0gDQoJ RW52b3nDqSA6IGpldWRpIDYgYXZyaWwgMjAwNiAxNDo1Mg0KCcOAIDogUmljaCBCcmFkZm9yZA0K CUNjIDogY2NhbXBAb3BzLmlldGYub3JnOyBwY2VAaWV0Zi5vcmcNCglPYmpldCA6IFJlOiBbUGNl XSBDb21wYXJpc29uIG9mIEVuY3J5cHRpb24gdnMuIFBhdGggS2V5IFNvbHV0aW9ucyBmb3IgdGhl IENQU0lELg0KDQoJSGksIA0KDQoJIA0KDQoJVGhhbmtzIGZvciB0aGUgc3VtbWFyeSBSaWNoLg0K DQoJIA0KDQoJUENFIFdHIG1lbWJlcnM6IHRoYW5rcyB0byBwcm92aWRlIHlvdXIgZmVlZGJhY2sg b24gd2hldGhlcjoNCg0KCSgxKSBZb3UgdGhpbmsgdGhhdCB0aGVyZSBpcyBhIG5lZWQgZm9yIHN1 Y2ggc29sdXRpb24sIA0KDQoJIA0KDQoJWWVzIGRlZmluaXRlbHksIGNvbmZpZGVudGlhbGl0eSBp cyBhIGtleSByZXF1aXJlbWVudHMgaW4gYW4gaW50ZXItcHJvdmlkZXIgY29udGV4dC4NCg0KCSAN Cg0KCSgyKSBZb3Ugd291bGQgcHJlZmVyIG9uZSBzb2x1dGlvbiAod2hpY2ggb25lIGFuZCB3aHkg PykgDQoNCgkgDQoNCgkoMykgWW91IHRoaW5rIHRoYXQgdGhlcmUgaXMgYSBuZWVkIGZvciBib3Ro IA0KDQoJIA0KDQoJQW5zd2VyIHRvICgyKSBhbmQgKDMpOg0KDQoJSXQgc2VlbXMgdG8gbWUgdGhh dCB3ZSBzaG91bGQgZW5kLXVwIHdpdGggYSBzaW5nbGUgc29sdXRpb24gc28gYXMgdG8gZWFzZSBp bnRlcndvcmtpbmcuDQoNCglJTU8gaW4gYW4gaW50ZXItQVMgTVBMUy1URSBlbnZpcm9ubWVudCB3 aXRob3V0IFBDRXMsIHRoZSBwYXRocyB3aWxsIGJlIGxvb3NlIGFueXdheSwgc28gdGhlcmUgd2ls bCBub3QgYmUgYW55IGNvbmZpZGVudGlhbGl0eSBpc3N1ZS4gDQoNCglJZiBoYXZlIHNvbWUgY29u Y2VybnMgcmVnYXJkaW5nIHRoZSBjb3N0IG9mIGVuY3J5cHRpb24sIHBhcnRpY3VsYXJseSBmb3Ig bGFyZ2UgcGF0aHMgKHdlIG5lZWQgdG8gdGhpbmsgYWJvdXQgZnV0dXJlIFAyTVAgYXBwbGljYXRp b25zIHdpdGggYSBsYXJnZSBudW1iZXIgb2YgaG9wcy4uLikuIEJ5IHRoZSB3YXksIGVuY3J5cHRp b24gYXBwcm9hY2hlcyBhcmUgcmVhbGx5IHZ1bG5lcmFibGUgdG8gRG9TIGF0dGFja3MuDQoNCglI ZW5jZSBJIHdvdWxkIHN0cm9uZ2x5IGZhdm9yIHRoZSBQS1Mgc29sdXRpb24uIFRoZSBvcHRpbWl6 YXRpb24gc3VnZ2VzdGVkLCB3aGljaCBjb25zaXN0cyBvZiBzZW5kaW5nIHRoZSBjb21wdXRlZCBw YXRoIHNlZ21lbnQgdG8gdGhlIExTUiBpbiBhbiB1bnNvbGljaXRlZCBtYW5uZXIsIGp1c3QgYWZ0 ZXIgdGhlIGNvbXB1dGF0aW9uLCBzb3VuZHMgcmVsZXZhbnQgYW5kIHNob3VsZCBiZSBmdXJ0aGVy IGludmVzdGlnYXRlZC4NCg0KCSANCg0KCUJlc3QgUmVnYXJkcywNCg0KCSANCg0KCUpMDQoNCgkg DQoNCgkgDQoNCgkgDQoNCgkgDQoNCglUaGFua3MuDQoNCgkgDQoNCglKUC4NCg0KCSANCg0KCU9u IEFwciA1LCAyMDA2LCBhdCA2OjE5IFBNLCBSaWNoIEJyYWRmb3JkICgocmJyYWRmb3IpKSB3cm90 ZToNCg0KCQ0KCQ0KCQ0KDQoJSGksDQoNCglBcyBzdWdnZXN0ZWQgaW4gRGFsbGFzLCBJ4oCZdmUg ZGVzY3JpYmVkIHNvbWUgb2YgdGhlIHRyYWRlb2ZmcyBiZXR3ZWVuIHRoZSB0d28gc29sdXRpb25z IGRlc2NyaWJlZCBpbiBkcmFmdC1yYnJhZGZvci1jY2FtcC1jb25maWRlbnRpYWwtc2VnbWVudC0w MC50eHQuDQoNCgktLSBSaWNoDQoNCglUaGUgQ29uZmlkZW50aWFsIFBhdGggU2VnbWVudCAoQ1BT KSBJRCBwcm92aWRlcyB0d28gdmVyeSBkaWZmZXJlbnQgYnV0IGVxdWFsbHkgdmFsaWQgc29sdXRp b25zLCB0aGUgUGF0aCBLZXkgU3Vib2JqZWN0IChQS1MpIHNvbHV0aW9uIGFuZCB0aGUgUHJpdmF0 ZSBSb3V0ZSBTdWJvYmplY3QgKFBSUykgc29sdXRpb24uIFRoaXMgbm90ZSBleGFtaW5lcyBhIG51 bWJlciBvZiB0aGUgYWR2YW50YWdlcyBhbmQgZGlzYWR2YW50YWdlcyBvZiBlYWNoIHNvbHV0aW9u LiANCg0KCUluIHNob3J0OiBUaGUgUEtTIHNvbHV0aW9uIGFsbG93cyBhIFBDRSB0byBoaWRlIHRo ZSBDUFMgZm9yIGFuIEFTIGJ5IHNhdmluZyBpdCBpbiBhIGRhdGFiYXNlIGFuZCByZXBsYWNpbmcg aXQgd2l0aCBhIGtleSBpbiB0aGUgRVJPLiBEdXJpbmcgdGhlIExTUCBzZXR1cCwgdGhlIGluZ3Jl c3MgTFNSIGZvciB0aGF0IEFTIG11c3QgcXVlcnkgdGhlIFBDRSBmb3IgYW4gZXhwYW5zaW9uLg0K DQoJVGhlIFBSUyBzb2x1dGlvbiBhbGxvd3MgYSBDUFMgZm9yIGFuIEFTIHRvIGJlIGhpZGRlbiBi eSBlbmNyeXB0aW5nIGl0LCB3aGljaCBtYXkgYmUgZG9uZSBieSBhIFBDRSBvciBieSB0aGUgSGVh ZC1FbmQgTFNSLiBEdXJpbmcgdGhlIExTUCBzZXR1cCwgdGhlIGluZ3Jlc3MgTFNSIGZvciB0aGF0 IEFTIG11c3QgdXNlIGEgZGVjcnlwdGlvbiBrZXkgdG8gb2J0YWluIHRoZSBleHBhbnNpb24gKGlt cGx5aW5nIGFuIGVhcmxpZXIgZXhjaGFuZ2Ugb3IgY29uZmlndXJhdGlvbikuIA0KDQoJVGhlIG1h am9yIGRpZmZlcmVuY2VzIGJldHdlZW4gdGhlIG1lY2hhbmlzbXMgaW52b2x2ZSAoMSkgYWRkaXRp b25hbCBjb250cm9sIG1lc3NhZ2VzLCAoMikgcGVyZm9ybWFuY2UgaXNzdWVzIGV4cGFuZGluZyB0 aG9zZSBvYmplY3RzLCAoMykgdGhlIGFkZGl0aW9uIG9mIHN0YXRlIHRvIHRoZSBQQ0UsICg0KSB0 aGUgc29sdXRpb24gc2NvcGUgKGkuZS4gYXBwbGljYWJpbGl0eSB0byB2YXJpb3VzIHRvcG9sb2dp ZXMgb2YgZWFjaCBzb2x1dGlvbi4pLCBhbmQgKDUpIHRoZSBzaXplIG9mIG9iamVjdHMgYWRkZWQg dG8gZXhpc3RpbmcgbWVzc2FnZXMuDQoNCgkoMSkgQWRkaXRpb25hbCBDb250cm9sIE1lc3NhZ2Ug T3ZlcmhlYWQ6DQoNCglUaGUgUEtTIHNvbHV0aW9uIHJlcXVpcmVzIGEgbWVjaGFuaXNtIHRvIGV4 cGFuZCB0aGUgUGF0aCBLZXkgdXBvbiByZWNlaXB0IG9mIHRoZSBMU1Agc2V0dXAgcmVxdWVzdC4g U2luY2UgdGhlIFBDRSB3aGljaCBjYWxjdWxhdGVkIHRoZSBQYXRoIEtleSBtaWdodCBub3QgcmVz aWRlIGluIHRoZSBlbnRyeSBib3VuZGFyeSBMU1IsIHRoZSBMU1IgbXVzdCByZXF1ZXN0IHRoZSBl eHBhbnNpb24gZnJvbSB0aGUgUENFLCByZXF1aXJpbmcgYW4gYWRkaXRpb25hbCBtZXNzYWdlIGV4 Y2hhbmdlIGJlZm9yZSBMU1Agc2V0dXAgY2FuIHByb2NlZWQuIFRoZSBQYXRoIEVuY3J5cHRpb24g c29sdXRpb24gZG9lcyBub3QgcmVxdWlyZSB0aGlzIGV4dHJhIGV4Y2hhbmdlIGJldHdlZW4gdGhl IFBDRSBhbmQgdGhlIGluZ3Jlc3Mgbm9kZSBmb3IgZXZlcnkgTFNQLiBSYXRoZXIsIHRoZSBkZWNy eXB0aW9uIGtleSBuZWVkcyB0byBiZSBleGNoYW5nZWQgb25seSB3aGVuIGl0IGlzIGNoYW5nZWQu IFRoZSByZXN1bHQgaXMgYWRkaXRpb25hbCBkZWxheSBkdXJpbmcgZXZlcnkgTFNQIHNldHVwIGZv ciB0aGUgUEtTIHNvbHV0aW9uIGJ1dCBubyBhZGRpdGlvbmFsIGRlbGF5IGZvciB0aGUgUFJTIHNv bHV0aW9uLg0KDQoJKDIpIFBDRSBhbmQgTFNSIFBlcmZvcm1hbmNlOg0KDQoJVGhlIFBLUyBzb2x1 dGlvbiBtdXN0IG1haW50YWluIGEgKHRlbXBvcmFyeSkgZGF0YWJhc2Ugb2Yga2V5cyBhZGRpbmcg b3ZlcmhlYWQgdG8gdGhlIFBDRS4gVGhlIFBSUyBzb2x1dGlvbiByZXF1aXJlcyB0aGUgZW5jcnlw dGlvbiBvZiB0aGUgQ1BTIGluIHRoZSBQQ0UgYW5kIGRlY3J5cHRpb24gb2YgdGhlIENQUyBpbiB0 aGUgTFNSLCB3aGljaCBjb3VsZCBiZSBDUFUgaW50ZW5zaXZlLiBOb3RlIHRoYXQgaW4gY2FzZSBv ZiBhIGJ1cnN0IG9mIHJlcXVlc3RzLCBlbmNyeXB0aW9uIG9mIGxhcmdlIG51bWJlciBvZiBDUFMg bWF5IGhhdmUgYW4gaW1wYWN0IG9uIHRoZSBQQ0UgcmVzcG9uc2UgdGltZS4NCg0KCSgzKSBBZGRp dGlvbiBvZiBTdGF0ZSBpbiB0aGUgUENFOg0KDQoJVGhlIFBLUyBzb2x1dGlvbiByZXF1aXJlcyB0 aGUgYWRkaXRpb24gb2YgcGF0aC1zcGVjaWZpYyBzdGF0ZSBhbmQgbWFpbnRlbmFuY2Ugb2YgYSBk YXRhYmFzZSBpbiB0aGUgUENFLiBUaGUgUFJTIHNvbHV0aW9uIHJlcXVpcmVzIG5vIGFkZGl0aW9u YWwgc3RhdGUuDQoNCgkoNCkgU29sdXRpb24gU2NvcGU6DQoNCglUaGUgUEtTIGFuZCBQUlMgc29s dXRpb25zIGJvdGggd29yayB3ZWxsIGluIGNvbmp1bmN0aW9uIHdpdGggYSBQQ0UgdG8gZW5jb2Rl IGFuZCBkZWNvZGUgdGhlIENQUy4gSG93ZXZlciB0aGUgUEtTIHByb3ZpZGVzIG5vIGRpcmVjdCBz b2x1dGlvbiB3aXRob3V0IGEgUENFLiBUaGlzIHByZXZlbnRzIHRoZSBQS1Mgc29sdXRpb24gZm9y IHdvcmtpbmcgaW4gdGhlIGNhc2Ugd2hlcmUgQSdzIG5ldHdvcmsgc3RyYWRkbGVzIEIncyBuZXR3 b3JrIGFuZCB3aGVyZSBBIHdhbnRzIHRvIHVzZSBhbiBFUk8gZm9yIGEgc2VnbWVudCBvZiB0aGUg TFNQIGFjcm9zcyB0aGUgaW50ZXJ2ZW5pbmcgbmV0d29yaywgZS5nLiAobmV0QSktKG5ldEIpLShu ZXRBKS4gSW4gYWRkaXRpb24sIHRoZSBQUlMgY291bGQgYmUgdXNlZCB0byByZWNvcmQgYSBDUFMg ZXZlbiBpZiB0aGUgcGF0aCAoYW5kIHRoZXJlZm9yZSB0aGUgcmV0dXJuZWQgUlJPKSBjcm9zc2Vz IG11bHRpcGxlIGJvdW5kYXJpZXMuIEZpbmFsbHksIGEgUFJTIHNvbHV0aW9uIGNvdWxkIGJlIGFk YXB0ZWQgdG8gcmV0dXJuIGFjdHVhbCBmYWlsdXJlIGxvY2F0aW9ucyBpbiBQRVJScyBhbmQvb3Ig UEFUSFRFQVJzLCB3aGlsZSBrZWVwaW5nIHRoZSBmYWlsdXJlIGxvY2F0aW9uIGNvbmZpZGVudGlh bCBmcm9tIExTUnMgd2l0aG91dCBhIGRlY3J5cHRpb24ga2V5LiBDdXJyZW50bHkgcHJpdmFjeSBv ZiB0aGlzIHNvdXJjZSBpcyBtYWludGFpbmVkIGJ5IHJldHVybmluZyB0aGUgYWRkcmVzcyBvZiBi b3JkZXIgbm9kZXMsIHdoaWNoIGNhbiBiZSB2ZXJ5IG1pc2xlYWRpbmcuDQoNCgkoNSkgTWVzc2Fn ZSBPYmplY3QgT3ZlcmhlYWQ6DQoNCglUaGUgUEtTIHNvbHV0aW9uIHByb3ZpZGVzIGEgdmVyeSBj b21wYWN0IGtleSBvciB0b2tlbiB0byBpZGVudGlmeSBhIHBhdGggc2VnbWVudCwgd2hpY2ggZ2Vu ZXJhbGx5IGFsbG93cyBmb3Igc21hbGxlciBFUk9zIHRvIGJlIHJldHVybmVkIGJ5IHRoZSBQQ0Ug YW5kIHRvIGJlIHJlcXVlc3RlZCBpbiB0aGUgcmVzdWx0aW5nIFBBVEggbWVzc2FnZS4gQSBQUlMg d2hpY2ggY29udGFpbnMgYSBDUFMgbXVzdCBnZW5lcmFsbHkgYmUgYXQgbGVhc3QgYXMgbGFyZ2Ug YXMgdGhlIHVuZW5jcnlwdGVkIFBBVEggdGhyb3VnaCB0aGUgQVMgYW5kIG1heSBiZSBzaWduaWZp Y2FudGx5IGxhcmdlciBpZiBpdCBpcyBkZXNpcmFibGUgdG8gaGlkZSB0aGUgbnVtYmVyIG9mIGhv cHMgd2l0aGluIHRoZSBuZXR3b3JrIGZyb20gZXh0ZXJuYWwgdmlldyBieSBwYWRkaW5nIHRoZSBQ UlMuIFRoZSByZXN1bHQgaXMgcG90ZW50aWFsbHkgbGFyZ2VyIFBBVEggKGFuZCBQQ0VQKSBtZXNz YWdlcyBmb3IgdGhlIFBSUyBzb2x1dGlvbi4NCg0KCVBsZWFzZSBub3RlIHRoYXQgdGhlIHRyYWRl b2ZmcyBsaXN0ZWQgaGVyZSBhcmUgZm9yIHRoZSBjdXJyZW50IEktRC4gU29tZSBvZiB0aGUgc2hv cnRjb21pbmdzIG9mIGVhY2ggYXBwcm9hY2ggY291bGQgYmUgbWl0aWdhdGVkIGJ5IGltcGxlbWVu dGF0aW9uLXNwZWNpZmljIG9wdGltaXphdGlvbnMuIEZvciBleGFtcGxlLCBhIFBDRSBjb3VsZCBj aG9vc2UgdG8gc2lnbmFsIHRoZSBDUFMgZXhwYW5zaW9uIHRvIHRoZSBlbnRyeSBib3VuZGFyeSBM U1IsIHNoaWZ0aW5nIHRoZSBidXJkZW4gb2YgbWFpbnRhaW5pbmcgdGhlIFBLUyBzdGF0ZSB0byB0 aGUgTFNSIGFuZCBlbGltaW5hdGluZyB0aGUgcGVyZm9ybWFuY2UgaGl0IGR1cmluZyBMU1Agc2V0 dXAuIEEgc2ltaWxhciBleGNoYW5nZSBjb3VsZCBiZSBwZXJmb3JtZWQgZm9yIHRoZSBQUlMgY2Fz ZSwgZWxpbWluYXRpbmcgdGhlIG5lZWQgZm9yIGEgc2VwYXJhdGUga2V5IGV4Y2hhbmdlLiBUaGVz ZSBleGFtcGxlcyBvZiBleHRlbnNpb25zIGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoZSBJRCwg YnV0IG1pZ2h0IGJlIHVzZWZ1bCB3aGVuIHdlaWdoaW5nIHRoZSBwcm9zIGFuZCBjb25zIG9mIHRo ZSB0d28gc29sdXRpb25zLg0KDQoJX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCg0KCVBjZSBtYWlsaW5nIGxpc3QNCg0KCVBjZUBsaXN0cy5pZXRmLm9yZw0K DQoJaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcGNlDQoNCgkgDQoNCg== ------_=_NextPart_001_01C667C9.BF3F36CD Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6c3QxPSJ1cm46c2NoZW1hcy1taWNy b3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiIHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy9UUi9S RUMtaHRtbDQwIj4NCg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZSBjb250 ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT1HZW5lcmF0b3IgY29u dGVudD0iTWljcm9zb2Z0IFdvcmQgMTEgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtpZiAhbXNv XT4NCjxzdHlsZT4NCnZcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCm9cOioge2Jl aGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCndcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNW TUwpO30NCi5zaGFwZSB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHlsZT4NCjwh W2VuZGlmXS0tPjxvOlNtYXJ0VGFnVHlwZQ0KIG5hbWVzcGFjZXVyaT0idXJuOnNjaGVtYXMtbWlj cm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIiBuYW1lPSJhZGRyZXNzIi8+DQo8bzpTbWFydFRh Z1R5cGUgbmFtZXNwYWNldXJpPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFy dHRhZ3MiDQogbmFtZT0icGxhY2UiLz4NCjxvOlNtYXJ0VGFnVHlwZSBuYW1lc3BhY2V1cmk9InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncyINCiBuYW1lPSJDaXR5Ii8+ DQo8bzpTbWFydFRhZ1R5cGUgbmFtZXNwYWNldXJpPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29t Om9mZmljZTpzbWFydHRhZ3MiDQogbmFtZT0iU3RyZWV0Ii8+DQo8IS0tW2lmICFtc29dPg0KPHN0 eWxlPg0Kc3QxXDoqe2JlaGF2aW9yOnVybCgjZGVmYXVsdCNpZW9vdWkpIH0NCjwvc3R5bGU+DQo8 IVtlbmRpZl0tLT4NCjxzdHlsZT4NCjwhLS0NCiAvKiBGb250IERlZmluaXRpb25zICovDQogQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseToiTVMgTWluY2hvIjsNCglwYW5vc2UtMToyIDIgNiA5IDQg MiA1IDggMyA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0x OjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxATVMg TWluY2hvIjsNCglwYW5vc2UtMTowIDAgMCAwIDAgMCAwIDAgMCAwO30NCiAvKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpoMQ0KCXttYXJnaW4tdG9wOjEyLjBw dDsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206My4wcHQ7DQoJbWFyZ2luLWxl ZnQ6LjVpbjsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJcGFnZS1icmVhay1hZnRlcjphdm9pZDsN Cgltc28tbGlzdDpsMCBsZXZlbDEgbGZvMTsNCglmb250LXNpemU6MTYuMHB0Ow0KCWZvbnQtZmFt aWx5OkFyaWFsO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7Y29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5D aGFwdGVyLCBsaS5DaGFwdGVyLCBkaXYuQ2hhcHRlcg0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmNlbnRlcjsNCglwYWdlLWJyZWFrLWJlZm9yZTph bHdheXM7DQoJZm9udC1zaXplOjE2LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0K CWZvbnQtd2VpZ2h0OmJvbGQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6QXJpYWw7DQoJY29sb3I6Ymx1ZTsNCglmb250 LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5v bmUgbm9uZTt9DQpAcGFnZSBTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4yNWluIDEuMGluIDEuMjVpbjt9DQpkaXYuU2VjdGlvbjENCgl7cGFnZTpTZWN0aW9u MTt9DQogLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KIEBsaXN0IGwwDQoJe21zby1saXN0LWlkOjY4 ODk0MTQ2Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczox NDgzNDY2OCA1MDY0ODg2NjQgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2 OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21z by1sZXZlbC1zdHlsZS1saW5rOiJIZWFkaW5nIDEiOw0KCW1zby1sZXZlbC10YWItc3RvcDouNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0K LS0+DQo8L3N0eWxlPg0KDQo8L2hlYWQ+DQoNCjxib2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZs aW5rPWJsdWUgc3R5bGU9J1dPUkQtV1JBUDogYnJlYWstd29yZDtraHRtbC1uYnNwLW1vZGU6IHNw YWNlOw0Ka2h0bWwtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2UnPg0KDQo8ZGl2IGNsYXNz PVNlY3Rpb24xPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUg ZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0O2ZvbnQtZmFtaWx5OkFy aWFsO2NvbG9yOmJsdWUnPkpMLDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0ndGV4dC1pbmRlbnQ6Ni4wcHQnPjxmb250IHNpemU9MyBjb2xv cj1ibHVlDQpmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OkFyaWFsO2NvbG9yOmJsdWUnPlRoYW5rcw0KZm9yIHRoZSByZXBseS4gSXTigJlzIGFsd2F5 cyBkaWZmaWN1bHQgdG8gY2hvb3NlIGJldHdlZW4gbXVsdGlwbGUgc29sdXRpb25zIHdoZW4NCnRo ZXJlIGFyZSBzbyBtYW55IHRyYWRlb2ZmcyBiZXR3ZWVuIHRoZSBzb2x1dGlvbnMuwqAgPG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSd0ZXh0 LWluZGVudDo2LjBwdCc+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUNCmZhY2U9QXJpYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6Ymx1ZSc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0 eWxlPSd0ZXh0LWluZGVudDo2LjBwdCc+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUNCmZhY2U9QXJp YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6 Ymx1ZSc+UmVnYXJkaW5nDQp0aGUgb3B0aW1pemF0aW9uIHdoZXJlIHRoZSBQQ0Ugc2VuZHMgdGhl IExTUiB0aGUgdW5zb2xpY2l0ZWQgY29tcHV0ZWQgcGF0aA0Kc2VnbWVudC4gwqBJdCB3YXMgYSBk aWZmaWN1bHQgY2hvaWNlIHdoZXRoZXIgb3Igbm90IHRvIGluY2x1ZGUgYSBkZXNjcmlwdGlvbiBv Zg0KdGhpcyBpbiB0aGUgb3JpZ2luYWwgZHJhZnQsIHNpbmNlIGl0IGlzIG1vcmUgY29tcGxleC4g V2hpY2ggYXNwZWN0IG9mIHRoZQ0Kb3B0aW1pemF0aW9uIHNlZW1lZCBtb3N0IGltcG9ydGFudD8g V2FzIGl0IHRoYXQgaXTigJlzIG1vcmUgZWZmaWNpZW50IGR1cmluZyBMU1ANCnNldHVwIG9yIGJl Y2F1c2UgaXQgY291bGQgYmUgdXNlZCB0byBzaGlmdCB0aGUgYnVyZGVuIG9mIG1haW50YWluaW5n IHN0YXRlIGZyb20NCnRoZSBQQ0UgdG8gdGhlIExTUj88bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtaW5kZW50OjYuMHB0Jz48Zm9u dCBzaXplPTMgY29sb3I9Ymx1ZQ0KZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibHVlJz5UaGFua3MNCm9uY2UgYWdhaW4gZm9y IHlvdXIgb3Bpbmlvbi4gPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsIHN0eWxlPSd0ZXh0LWluZGVudDo2LjBwdCc+PGZvbnQgc2l6ZT0zIGNvbG9yPWJs dWUNCmZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 QXJpYWw7Y29sb3I6Ymx1ZSc+QmVzdA0KUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J3RleHQtaW5kZW50OjYuMHB0Jz48Zm9u dCBzaXplPTMgY29sb3I9Ymx1ZQ0KZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibHVlJz7CoCBSaWNoPG86cD48L286cD48L3Nw YW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBjb2xvcj1i bHVlIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdDtmb250LWZhbWls eTpBcmlhbDtjb2xvcjpibHVlJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K DQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQnPg0KDQo8ZGl2Pg0KDQo8ZGl2IGNsYXNzPU1zb05vcm1h bCBhbGlnbj1jZW50ZXIgc3R5bGU9J3RleHQtYWxpZ246Y2VudGVyJz48Zm9udCBzaXplPTMNCmZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPg0KDQo8 aHIgc2l6ZT0yIHdpZHRoPSIxMDAlIiBhbGlnbj1jZW50ZXIgdGFiaW5kZXg9LTE+DQoNCjwvc3Bh bj48L2ZvbnQ+PC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Yj48Zm9udCBzaXplPTIgZmFj ZT1UYWhvbWE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpUYWhv bWE7Zm9udC13ZWlnaHQ6Ym9sZCc+RnJvbTo8L3NwYW4+PC9mb250PjwvYj48Zm9udCBzaXplPTIN CmZhY2U9VGFob21hPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlRh aG9tYSc+IDxzdDE6U3RyZWV0DQp3OnN0PSJvbiI+PHN0MTphZGRyZXNzIHc6c3Q9Im9uIj5MRSBS T1VYIEplYW4tTG91aXMgUkQ8L3N0MTphZGRyZXNzPjwvc3QxOlN0cmVldD4tQ09SRS1MQU4NCltt YWlsdG86amVhbmxvdWlzLmxlcm91eEBmcmFuY2V0ZWxlY29tLmNvbV0gPGJyPg0KPGI+PHNwYW4g c3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPlNlbnQ6PC9zcGFuPjwvYj4gRnJpZGF5LCBBcHJpbCAy MSwgMjAwNiAxMjo1MQ0KUE08YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+ VG86PC9zcGFuPjwvYj4gSmVhbiBQaGlsaXBwZSBWYXNzZXVyDQooanZhc3NldXIpOyBSaWNoIEJy YWRmb3JkIChyYnJhZGZvcik8YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+ Q2M6PC9zcGFuPjwvYj4gY2NhbXBAb3BzLmlldGYub3JnOw0KcGNlQGlldGYub3JnPGJyPg0KPGI+ PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPlN1YmplY3Q6PC9zcGFuPjwvYj4gUkU6IFtQ Y2VdIENvbXBhcmlzb24gb2YNCkVuY3J5cHRpb24gdnMuIFBhdGggS2V5IFNvbHV0aW9ucyBmb3Ig dGhlIENQU0lELjwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250 PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9 QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtj b2xvcjpibHVlJz5IaSBKUCwgUmljaGFyZDwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUg ZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFy aWFsO2NvbG9yOmJsdWUnPlBsZWFzZSBzZWUgaW5saW5lLDwvc3Bhbj48L2ZvbnQ+PG86cD48L286 cD48L3A+DQoNCjxibG9ja3F1b3RlIHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQ7DQptYXJnaW4tbGVmdDozLjc1 cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQn Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9mb250PjwvcD4NCg0KPGRpdiBjbGFzcz1Nc29Ob3JtYWwgYWxpZ249Y2VudGVyIHN0eWxl PSd0ZXh0LWFsaWduOmNlbnRlcic+PGZvbnQgc2l6ZT0zDQpmYWNlPSJUaW1lcyBOZXcgUm9tYW4i PjxzcGFuIGxhbmc9RlIgc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPg0KDQo8aHIgc2l6ZT0yIHdp ZHRoPSIxMDAlIiBhbGlnbj1jZW50ZXIgdGFiSW5kZXg9LTE+DQoNCjwvc3Bhbj48L2ZvbnQ+PC9k aXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbWFyZ2luLWJvdHRvbToxMi4wcHQnPjxi Pjxmb250IHNpemU9MiBmYWNlPVRhaG9tYT48c3Bhbg0KbGFuZz1GUiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpUYWhvbWE7Zm9udC13ZWlnaHQ6Ym9sZCc+RGUmbmJzcDs6PC9z cGFuPjwvZm9udD48L2I+PGZvbnQNCnNpemU9MiBmYWNlPVRhaG9tYT48c3BhbiBsYW5nPUZSIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlRhaG9tYSc+DQpKUCBWYXNzZXVyIFtt YWlsdG86anZhc3NldXJAY2lzY28uY29tXSA8YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWln aHQ6Ym9sZCc+RW52b3nDqSZuYnNwOzo8L3NwYW4+PC9iPiBqZXVkaSA2IGF2cmlsIDIwMDYNCjE0 OjUyPGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPsOAJm5ic3A7Ojwvc3Bh bj48L2I+IFJpY2ggQnJhZGZvcmQ8YnI+DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9s ZCc+Q2MmbmJzcDs6PC9zcGFuPjwvYj4gY2NhbXBAb3BzLmlldGYub3JnOw0KcGNlQGlldGYub3Jn PGJyPg0KPGI+PHNwYW4gc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPk9iamV0Jm5ic3A7Ojwvc3Bh bj48L2I+IFJlOiBbUGNlXSBDb21wYXJpc29uDQpvZiBFbmNyeXB0aW9uIHZzLiBQYXRoIEtleSBT b2x1dGlvbnMgZm9yIHRoZSBDUFNJRC48L3NwYW4+PC9mb250PjxzcGFuIGxhbmc9RlI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+SGksIDxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1z aXplOg0KMTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rp dj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPlRoYW5rcyBmb3Ig dGhlIHN1bW1hcnkgUmljaC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4N Cg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToNCjEyLjBwdCc+UENFIFdHIG1lbWJlcnM6IHRoYW5rcyB0byBwcm92aWRlIHlvdXIg ZmVlZGJhY2sgb24gd2hldGhlcjo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rp dj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPigxKSBZb3UgdGhp bmsgdGhhdCB0aGVyZSBpcyBhIG5lZWQgZm9yIHN1Y2ggc29sdXRpb24sPC9zcGFuPjwvZm9udD48 Zm9udA0Kc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDsNCmNvbG9yOmJsdWUnPiZuYnNwOzwvc3Bhbj48L2Zv bnQ+PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToNCjEyLjBwdCc+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9k aXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1 ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6 QXJpYWw7Y29sb3I6Ymx1ZSc+WWVzIGRlZmluaXRlbHksIGNvbmZpZGVudGlhbGl0eSBpcyBhIGtl eQ0KcmVxdWlyZW1lbnRzIGluIGFuIGludGVyLXByb3ZpZGVyIGNvbnRleHQuPC9zcGFuPjwvZm9u dD48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1z aXplOg0KMTIuMHB0Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rp dj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPigyKSBZb3Ugd291 bGQgcHJlZmVyIG9uZSBzb2x1dGlvbiAod2hpY2ggb25lIGFuZCB3aHkgPyk8L3NwYW4+PC9mb250 Pjxmb250DQpzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsOw0KY29sb3I6Ymx1ZSc+Jm5ic3A7PC9zcGFuPjwv Zm9udD48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9u dC1zaXplOg0KMTIuMHB0Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8 L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPigzKSBZb3Ug dGhpbmsgdGhhdCB0aGVyZSBpcyBhIG5lZWQgZm9yIGJvdGg8L3NwYW4+PC9mb250Pjxmb250IHNp emU9Mg0KY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OkFyaWFsOw0KY29sb3I6Ymx1ZSc+Jm5ic3A7PC9zcGFuPjwvZm9udD48bzpw PjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9u dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0K MTIuMHB0Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0K PGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9 QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtj b2xvcjpibHVlJz5BbnN3ZXIgdG8gKDIpIGFuZCAoMyk6PC9zcGFuPjwvZm9udD48bzpwPjwvbzpw PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXpl PTIgY29sb3I9Ymx1ZSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7 Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6Ymx1ZSc+SXQgc2VlbXMgdG8gbWUgdGhhdCB3ZSBzaG91 bGQgZW5kLXVwIHdpdGgNCmEgc2luZ2xlIHNvbHV0aW9uIHNvIGFzIHRvJm5ic3A7ZWFzZSBpbnRl cndvcmtpbmcuPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+ DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBm YWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJp YWw7Y29sb3I6Ymx1ZSc+SU1PJm5ic3A7aW4gYW4gaW50ZXItQVMgTVBMUy1URQ0KZW52aXJvbm1l bnQgd2l0aG91dCBQQ0VzLCB0aGUgcGF0aHMgd2lsbCBiZSBsb29zZSBhbnl3YXksJm5ic3A7c28N CnRoZXJlJm5ic3A7d2lsbCBub3QgYmUmbmJzcDthbnkgY29uZmlkZW50aWFsaXR5IGlzc3VlLiA8 L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9QXJpYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibHVlJz5JZiBo YXZlIHNvbWUgY29uY2VybnMmbmJzcDtyZWdhcmRpbmcgdGhlDQpjb3N0IG9mIGVuY3J5cHRpb24s IHBhcnRpY3VsYXJseSBmb3IgbGFyZ2UgcGF0aHMgKHdlIG5lZWQgdG8gdGhpbmsgYWJvdXQgZnV0 dXJlDQpQMk1QIGFwcGxpY2F0aW9ucyB3aXRoIGEgbGFyZ2UgbnVtYmVyIG9mIGhvcHMuLi4pLiBC eSB0aGUgd2F5LCBlbmNyeXB0aW9uDQphcHByb2FjaGVzIGFyZSByZWFsbHkgdnVsbmVyYWJsZSB0 byBEb1MgYXR0YWNrcy48L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0K PGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1ibHVlIGZhY2U9 QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtj b2xvcjpibHVlJz5IZW5jZSBJJm5ic3A7d291bGQgc3Ryb25nbHkgZmF2b3IgdGhlIFBLUw0Kc29s dXRpb24uIFRoZSBvcHRpbWl6YXRpb24gc3VnZ2VzdGVkLCZuYnNwO3doaWNoIGNvbnNpc3RzIG9m IHNlbmRpbmcgdGhlDQpjb21wdXRlZCBwYXRoIHNlZ21lbnQgdG8gdGhlIExTUiBpbiBhbiB1bnNv bGljaXRlZCBtYW5uZXIsIGp1c3QgYWZ0ZXIgdGhlDQpjb21wdXRhdGlvbiwmbmJzcDtzb3VuZHMg cmVsZXZhbnQgYW5kIHNob3VsZCBiZSBmdXJ0aGVyIGludmVzdGlnYXRlZC48L3NwYW4+PC9mb250 PjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNp emU6DQoxMi4wcHQnPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2 Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUg ZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFy aWFsO2NvbG9yOmJsdWUnPkJlc3QgUmVnYXJkcyw8L3NwYW4+PC9mb250PjxvOnA+PC9vOnA+PC9w Pg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT1BcmlhbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOmJsdWUn PkpMPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8 ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1z aXplOg0KMTIuMHB0Jz4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rp dj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPiZuYnNwOzxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4N Cg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFj ZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz5UaGFu a3MuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNp emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4w cHQnPkpQLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxkaXY+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBz dHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz5PbiBBcHIgNSwgMjAwNiwgYXQgNjoxOSBQTSwgUmlj aCBCcmFkZm9yZCAoKHJicmFkZm9yKSkgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz48YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvJz48Zm9udA0Kc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMi4wcHQnPjxPOlNNQVJUVEFHVFlQRSBuYW1lPSJDaXR5IiBuYW1lc3BhY2V1 cmk9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncyI+PE86U01BUlRU QUdUWVBFIG5hbWU9InBsYWNlIiBuYW1lc3BhY2V1cmk9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1j b206b2ZmaWNlOnNtYXJ0dGFncyI+SGksPE86UD48L086UD48bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48Zm9udA0Kc2l6ZT0zIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPkFzIHN1Z2dlc3RlZCBp biA8U1QxOkNJVFkgdTE6c3Q9Im9uIj48U1QxOlBMQUNFIHUxOnN0PSJvbiI+PHN0MTpDaXR5DQp3 OnN0PSJvbiI+PHN0MTpwbGFjZSB3OnN0PSJvbiI+RGFsbGFzPC9TVDE6UExBQ0U+PC9TVDE6Q0lU WT48L3N0MTpwbGFjZT48L3N0MTpDaXR5PiwNCknigJl2ZSBkZXNjcmliZWQgc29tZSBvZiB0aGUg dHJhZGVvZmZzIGJldHdlZW4gdGhlIHR3byBzb2x1dGlvbnMgZGVzY3JpYmVkIGluDQpkcmFmdC1y YnJhZGZvci1jY2FtcC1jb25maWRlbnRpYWwtc2VnbWVudC0wMC50eHQuPE86UD48L086UD48bzpw PjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48Zm9udA0K c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4w cHQnPi0tIFJpY2g8TzpQPjwvTzpQPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8nPjxmb250DQpzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PE86UD48L086UD5UaGUNCkNvbmZpZGVudGlh bCBQYXRoIFNlZ21lbnQgKENQUykgSUQgcHJvdmlkZXMgdHdvIHZlcnkgZGlmZmVyZW50IGJ1dCBl cXVhbGx5DQp2YWxpZCBzb2x1dGlvbnMsIHRoZSBQYXRoIEtleSBTdWJvYmplY3QgKFBLUykgc29s dXRpb24gYW5kIHRoZSBQcml2YXRlIFJvdXRlDQpTdWJvYmplY3QgKFBSUykgc29sdXRpb24uIFRo aXMgbm90ZSBleGFtaW5lcyBhIG51bWJlciBvZiB0aGUgYWR2YW50YWdlcyBhbmQNCmRpc2FkdmFu dGFnZXMgb2YgZWFjaCBzb2x1dGlvbi4gPE86UD48L086UD48bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48Zm9udA0Kc2l6ZT0zIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxPOlA+PC9POlA+SW4N CnNob3J0OiBUaGUgUEtTIHNvbHV0aW9uIGFsbG93cyBhIFBDRSB0byBoaWRlIHRoZSBDUFMgZm9y IGFuIEFTIGJ5IHNhdmluZyBpdCBpbg0KYSBkYXRhYmFzZSBhbmQgcmVwbGFjaW5nIGl0IHdpdGgg YSBrZXkgaW4gdGhlIEVSTy4gRHVyaW5nIHRoZSBMU1Agc2V0dXAsIHRoZQ0KaW5ncmVzcyBMU1Ig Zm9yIHRoYXQgQVMgbXVzdCBxdWVyeSB0aGUgUENFIGZvciBhbiBleHBhbnNpb24uPE86UD48L086 UD48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5 bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48 Zm9udA0Kc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMi4wcHQnPlRoZSBQUlMgc29sdXRpb24NCmFsbG93cyBhIENQUyBmb3IgYW4gQVMgdG8gYmUg aGlkZGVuIGJ5IGVuY3J5cHRpbmcgaXQsIHdoaWNoIG1heSBiZSBkb25lIGJ5IGENClBDRSBvciBi eSB0aGUgSGVhZC1FbmQgTFNSLiBEdXJpbmcgdGhlIExTUCBzZXR1cCwgdGhlIGluZ3Jlc3MgTFNS IGZvciB0aGF0IEFTDQptdXN0IHVzZSBhIGRlY3J5cHRpb24ga2V5IHRvIG9idGFpbiB0aGUgZXhw YW5zaW9uIChpbXBseWluZyBhbiBlYXJsaWVyIGV4Y2hhbmdlDQpvciBjb25maWd1cmF0aW9uKS4g PE86UD48L086UD48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvJz48Zm9udA0Kc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMi4wcHQnPjxPOlA+PC9POlA+VGhlDQptYWpvciBkaWZmZXJlbmNlcyBiZXR3 ZWVuIHRoZSBtZWNoYW5pc21zIGludm9sdmUgKDEpIGFkZGl0aW9uYWwgY29udHJvbA0KbWVzc2Fn ZXMsICgyKSBwZXJmb3JtYW5jZSBpc3N1ZXMgZXhwYW5kaW5nIHRob3NlIG9iamVjdHMsICgzKSB0 aGUgYWRkaXRpb24gb2YNCnN0YXRlIHRvIHRoZSBQQ0UsICg0KSB0aGUgc29sdXRpb24gc2NvcGUg KGkuZS4gYXBwbGljYWJpbGl0eSB0byB2YXJpb3VzDQp0b3BvbG9naWVzIG9mIGVhY2ggc29sdXRp b24uKSwgYW5kICg1KSB0aGUgc2l6ZSBvZiBvYmplY3RzIGFkZGVkIHRvIGV4aXN0aW5nDQptZXNz YWdlcy48TzpQPjwvTzpQPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8nPjxmb250DQpzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEyLjBwdCc+PE86UD48L086UD4oMSkNCkFkZGl0aW9uYWwgQ29udHJv bCBNZXNzYWdlIE92ZXJoZWFkOjxPOlA+PC9POlA+PG86cD48L286cD48L3NwYW4+PC9mb250Pjwv cD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PGZvbnQNCnNpemU9MyBmYWNlPSJUaW1lcyBOZXcg Um9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz5UaGUgUEtTIHNvbHV0aW9uDQpy ZXF1aXJlcyBhIG1lY2hhbmlzbSB0byBleHBhbmQgdGhlIFBhdGggS2V5IHVwb24gcmVjZWlwdCBv ZiB0aGUgTFNQIHNldHVwDQpyZXF1ZXN0LiBTaW5jZSB0aGUgUENFIHdoaWNoIGNhbGN1bGF0ZWQg dGhlIFBhdGggS2V5IG1pZ2h0IG5vdCByZXNpZGUgaW4gdGhlDQplbnRyeSBib3VuZGFyeSBMU1Is IHRoZSBMU1IgbXVzdCByZXF1ZXN0IHRoZSBleHBhbnNpb24gZnJvbSB0aGUgUENFLCByZXF1aXJp bmcNCmFuIGFkZGl0aW9uYWwgbWVzc2FnZSBleGNoYW5nZSBiZWZvcmUgTFNQIHNldHVwIGNhbiBw cm9jZWVkLiBUaGUgUGF0aA0KRW5jcnlwdGlvbiBzb2x1dGlvbiBkb2VzIG5vdCByZXF1aXJlIHRo aXMgZXh0cmEgZXhjaGFuZ2UgYmV0d2VlbiB0aGUgUENFIGFuZA0KdGhlIGluZ3Jlc3Mgbm9kZSBm b3IgZXZlcnkgTFNQLiBSYXRoZXIsIHRoZSBkZWNyeXB0aW9uIGtleSBuZWVkcyB0byBiZQ0KZXhj aGFuZ2VkIG9ubHkgd2hlbiBpdCBpcyBjaGFuZ2VkLiBUaGUgcmVzdWx0IGlzIGFkZGl0aW9uYWwg ZGVsYXkgZHVyaW5nIGV2ZXJ5DQpMU1Agc2V0dXAgZm9yIHRoZSBQS1Mgc29sdXRpb24gYnV0IG5v IGFkZGl0aW9uYWwgZGVsYXkgZm9yIHRoZSBQUlMgc29sdXRpb24uPE86UD48L086UD48bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48Zm9udA0Kc2l6 ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQn PjxPOlA+PC9POlA+PE86UD48L086UD4oMikNClBDRSBhbmQgTFNSIFBlcmZvcm1hbmNlOjxPOlA+ PC9POlA+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byc+PGZvbnQNCnNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTIuMHB0Jz5UaGUgUEtTIHNvbHV0aW9uDQptdXN0IG1haW50YWluIGEgKHRlbXBvcmFy eSkgZGF0YWJhc2Ugb2Yga2V5cyBhZGRpbmcgb3ZlcmhlYWQgdG8gdGhlIFBDRS4gVGhlDQpQUlMg c29sdXRpb24gcmVxdWlyZXMgdGhlIGVuY3J5cHRpb24gb2YgdGhlIENQUyBpbiB0aGUgUENFIGFu ZCBkZWNyeXB0aW9uIG9mDQp0aGUgQ1BTIGluIHRoZSBMU1IsIHdoaWNoIGNvdWxkIGJlIENQVSBp bnRlbnNpdmUuIE5vdGUgdGhhdCBpbiBjYXNlIG9mIGEgYnVyc3QNCm9mIHJlcXVlc3RzLCBlbmNy eXB0aW9uIG9mIGxhcmdlIG51bWJlciBvZiBDUFMgbWF5IGhhdmUgYW4gaW1wYWN0IG9uIHRoZSBQ Q0UNCnJlc3BvbnNlIHRpbWUuPE86UD48L086UD48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvJz48Zm9udA0Kc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBS b21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxPOlA+PC9POlA+KDMpDQpBZGRp dGlvbiBvZiBTdGF0ZSBpbiB0aGUgUENFOjxPOlA+PC9POlA+PG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PGZvbnQNCnNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz5UaGUgUEtTIHNvbHV0 aW9uDQpyZXF1aXJlcyB0aGUgYWRkaXRpb24gb2YgcGF0aC1zcGVjaWZpYyBzdGF0ZSBhbmQgbWFp bnRlbmFuY2Ugb2YgYSBkYXRhYmFzZSBpbg0KdGhlIFBDRS4gVGhlIFBSUyBzb2x1dGlvbiByZXF1 aXJlcyBubyBhZGRpdGlvbmFsIHN0YXRlLjxPOlA+PC9POlA+PG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PGZvbnQNCnNpemU9MyBmYWNlPSJUaW1l cyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48TzpQPjwvTzpQPjxP OlA+PC9POlA+KDQpDQpTb2x1dGlvbiBTY29wZTo8TzpQPjwvTzpQPjxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8nPjxmb250DQpzaXplPTMgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+VGhlIFBLUyBh bmQgUFJTDQpzb2x1dGlvbnMgYm90aCB3b3JrIHdlbGwgaW4gY29uanVuY3Rpb24gd2l0aCBhIFBD RSB0byBlbmNvZGUgYW5kIGRlY29kZSB0aGUNCkNQUy4gSG93ZXZlciB0aGUgUEtTIHByb3ZpZGVz IG5vIGRpcmVjdCBzb2x1dGlvbiB3aXRob3V0IGEgUENFLiBUaGlzIHByZXZlbnRzDQp0aGUgUEtT IHNvbHV0aW9uIGZvciB3b3JraW5nIGluIHRoZSBjYXNlIHdoZXJlIEEncyBuZXR3b3JrIHN0cmFk ZGxlcyBCJ3MNCm5ldHdvcmsgYW5kIHdoZXJlIEEgd2FudHMgdG8gdXNlIGFuIEVSTyBmb3IgYSBz ZWdtZW50IG9mIHRoZSBMU1AgYWNyb3NzIHRoZQ0KaW50ZXJ2ZW5pbmcgbmV0d29yaywgZS5nLiAo bmV0QSktKG5ldEIpLShuZXRBKS4gSW4gYWRkaXRpb24sIHRoZSBQUlMgY291bGQgYmUNCnVzZWQg dG8gcmVjb3JkIGEgQ1BTIGV2ZW4gaWYgdGhlIHBhdGggKGFuZCB0aGVyZWZvcmUgdGhlIHJldHVy bmVkIFJSTykgY3Jvc3Nlcw0KbXVsdGlwbGUgYm91bmRhcmllcy4gRmluYWxseSwgYSBQUlMgc29s dXRpb24gY291bGQgYmUgYWRhcHRlZCB0byByZXR1cm4gYWN0dWFsDQpmYWlsdXJlIGxvY2F0aW9u cyBpbiBQRVJScyBhbmQvb3IgUEFUSFRFQVJzLCB3aGlsZSBrZWVwaW5nIHRoZSBmYWlsdXJlIGxv Y2F0aW9uDQpjb25maWRlbnRpYWwgZnJvbSBMU1JzIHdpdGhvdXQgYSBkZWNyeXB0aW9uIGtleS4g Q3VycmVudGx5IHByaXZhY3kgb2YgdGhpcw0Kc291cmNlIGlzIG1haW50YWluZWQgYnkgcmV0dXJu aW5nIHRoZSBhZGRyZXNzIG9mIGJvcmRlciBub2Rlcywgd2hpY2ggY2FuIGJlDQp2ZXJ5IG1pc2xl YWRpbmcuPE86UD48L086UD48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWwgc3R5bGU9J21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvJz48Zm9udA0Kc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQnPjxPOlA+PC9POlA+KDUpDQpNZXNzYWdlIE9iamVjdCBP dmVyaGVhZDo8TzpQPjwvTzpQPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbCBzdHlsZT0nbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8nPjxmb250DQpzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+VGhlIFBLUyBzb2x1dGlvbg0KcHJvdmlkZXMgYSB2 ZXJ5IGNvbXBhY3Qga2V5IG9yIHRva2VuIHRvIGlkZW50aWZ5IGEgcGF0aCBzZWdtZW50LCB3aGlj aA0KZ2VuZXJhbGx5IGFsbG93cyBmb3Igc21hbGxlciBFUk9zIHRvIGJlIHJldHVybmVkIGJ5IHRo ZSBQQ0UgYW5kIHRvIGJlIHJlcXVlc3RlZA0KaW4gdGhlIHJlc3VsdGluZyBQQVRIIG1lc3NhZ2Uu IEEgUFJTIHdoaWNoIGNvbnRhaW5zIGEgQ1BTIG11c3QgZ2VuZXJhbGx5IGJlIGF0DQpsZWFzdCBh cyBsYXJnZSBhcyB0aGUgdW5lbmNyeXB0ZWQgUEFUSCB0aHJvdWdoIHRoZSBBUyBhbmQgbWF5IGJl IHNpZ25pZmljYW50bHkNCmxhcmdlciBpZiBpdCBpcyBkZXNpcmFibGUgdG8gaGlkZSB0aGUgbnVt YmVyIG9mIGhvcHMgd2l0aGluIHRoZSBuZXR3b3JrIGZyb20NCmV4dGVybmFsIHZpZXcgYnkgcGFk ZGluZyB0aGUgUFJTLiBUaGUgcmVzdWx0IGlzIHBvdGVudGlhbGx5IGxhcmdlciBQQVRIIChhbmQN ClBDRVApIG1lc3NhZ2VzIGZvciB0aGUgUFJTIHNvbHV0aW9uLjxPOlA+PC9POlA+PG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byc+PGZvbnQNCnNpemU9 MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTIuMHB0Jz48 TzpQPjwvTzpQPjxPOlA+PC9POlA+UGxlYXNlDQpub3RlIHRoYXQgdGhlIHRyYWRlb2ZmcyBsaXN0 ZWQgaGVyZSBhcmUgZm9yIHRoZSBjdXJyZW50IEktRC4gU29tZSBvZiB0aGUNCnNob3J0Y29taW5n cyBvZiBlYWNoIGFwcHJvYWNoIGNvdWxkIGJlIG1pdGlnYXRlZCBieSBpbXBsZW1lbnRhdGlvbi1z cGVjaWZpYw0Kb3B0aW1pemF0aW9ucy4gRm9yIGV4YW1wbGUsIGEgUENFIGNvdWxkIGNob29zZSB0 byBzaWduYWwgdGhlIENQUyBleHBhbnNpb24gdG8NCnRoZSBlbnRyeSBib3VuZGFyeSBMU1IsIHNo aWZ0aW5nIHRoZSBidXJkZW4gb2YgbWFpbnRhaW5pbmcgdGhlIFBLUyBzdGF0ZSB0byB0aGUNCkxT UiBhbmQgZWxpbWluYXRpbmcgdGhlIHBlcmZvcm1hbmNlIGhpdCBkdXJpbmcgTFNQIHNldHVwLiBB IHNpbWlsYXIgZXhjaGFuZ2UNCmNvdWxkIGJlIHBlcmZvcm1lZCBmb3IgdGhlIFBSUyBjYXNlLCBl bGltaW5hdGluZyB0aGUgbmVlZCBmb3IgYSBzZXBhcmF0ZSBrZXkNCmV4Y2hhbmdlLiBUaGVzZSBl eGFtcGxlcyBvZiBleHRlbnNpb25zIGFyZSBiZXlvbmQgdGhlIHNjb3BlIG9mIHRoZSBJRCwgYnV0 DQptaWdodCBiZSB1c2VmdWwgd2hlbiB3ZWlnaGluZyB0aGUgcHJvcyBhbmQgY29ucyBvZiB0aGUg dHdvIHNvbHV0aW9ucy48TzpQPjwvTzpQPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoN CjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PE86UD48 L086UD48TzpQPjwvTzpQPjwvTzpTTUFSVFRBR1RZUEU+PC9POlNNQVJUVEFHVFlQRT5fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZv bnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToN CjEyLjBwdCc+UGNlIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoN CjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PGEgaHJl Zj0ibWFpbHRvOlBjZUBsaXN0cy5pZXRmLm9yZyI+UGNlQGxpc3RzLmlldGYub3JnPC9hPjxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PGEgaHJlZj0iaHR0cHM6Ly93d3cxLmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vcGNlIj5odHRwczovL3d3dzEuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9w Y2U8L2E+PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9mb250PjwvcD4NCg0KPC9kaXY+DQoNCjwvYmxvY2txdW90ZT4NCg0KPC9kaXY+DQoNCjwvZGl2 Pg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4NCg== ------_=_NextPart_001_01C667C9.BF3F36CD-- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 24 Apr 2006 14:38:42 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=OHn99AIwXYjns7oalXBAwLADWQrMg7WzyqtsxLLMfU0/5pYvuPWy6hZiTX9aM3ych3IUcdOKWv5CmN3wBXEXkwSAp5d7//ePOqvF1E3Y8byDS+24lfdoCpfReKhyun+wY5Mpsg4mfXk0F5PSdnqZpg5myP3dc3K+vm+xt5dDUhE= Message-ID: Date: Mon, 24 Apr 2006 19:36:41 +0500 From: "Fahad Dogar" To: ccamp@ops.ietf.org Subject: GMPLS support for Ethernet switching MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi all, I have few questions related to the draft on GMPLS support for Ethernet switching by D.Papadimitriou et al.: i) The draft discusses that connection oriented ethernet is suitable for metro and core networks where ethernet is used for transport. I am not too clear on the architecture in which ethernet LSPs would be used. Are we considering point to point type ethernet connections between switches/routers i.e. where the bandwidth is not shared. Example: Two peer routers connected through an ethernet interface, so effectively complete bandwidth is available. Or are we talking about multiple switches in a GMPLS enabled cloud that are part of the SAME LAN and bandwidth is shared. I am not sure how bandwidth reservations would be done in this sceneario. ii) Please correct me if I am wrong but it seems that the traffic engineering benefits of GMPLS support for Ethernet are also available in Ethernet over MPLS. (I am considering that connection oriented Ethernet is used in metro/core networks only). However, by providing GMPLS support for Ethernet we are able to do away with IP/MPLS layer and thus we can have an all Ethernet network (with only ethernet switches). Is this the primary reason for using GMPLS support for Ethernet rather than Ethernet over MPLS? Can someone comment on this? iii) The draft discusses various options for ethernet label, all of which seem to require modification in the forwarding plane of Ethernet? Is this something that can implemented easily i.e. change in forwarding plane? Why can't we consider MAC address or VLAN tag as the label? Thanks in advance, Fahad Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Apr 2006 22:52:27 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-lsp-hierarchy-bis-00.txt Message-Id: Date: Fri, 21 Apr 2006 18:50:01 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Procedures for Dynamically Signaled Hierarchical Label Switched Paths Author(s) : K. Shiomoto, et al. Filename : draft-ietf-ccamp-lsp-hierarchy-bis-00.txt Pages : 17 Date : 2006-4-21 This document addresses topics related to hierarchical and stitched Generalized Multiprotocol Label Switching (GMPLS) Label Switched Paths (LSPs). It describes extensions to allow an egress to identify that a bi-directional LSP will be used as a dynamically signaled Forwarding Adjacency LSP (FA-LSP) or Routing Adjacency (RA). In addition, the document also addresses the issue of how to indicate that an LSP should be advertised as a traffic engineering (TE) link into a different instance of the IGP and how to identify the instance that should be used. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-lsp-hierarchy-bis-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-lsp-hierarchy-bis-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-lsp-hierarchy-bis-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-21150234.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-lsp-hierarchy-bis-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-lsp-hierarchy-bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-21150234.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Apr 2006 22:52:19 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-00.txt Message-Id: Date: Fri, 21 Apr 2006 18:50:01 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Framework for IP/MPLS-GMPLS interworking in support of IP/MPLS to GMPLS migration Author(s) : K. Shiomoto, et al. Filename : draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-00.txt Pages : 24 Date : 2006-4-21 The migration from Multiprotocol Label Switching (MPLS) to Generalized MPLS (GMPLS) is the process of evolving an MPLS traffic engineered (TE) control plane to a GMPLS control plane. An appropriate migration strategy can be selected based on various factors including the service provider's network deployment plan, customer demand, available network equipment implementation, operational policy, etc. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-21150533.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-21150533.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Apr 2006 16:52:33 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C66563.C8AC21C9" Subject: RE: [Pce] Comparison of Encryption vs. Path Key Solutions for the CPSID. Date: Fri, 21 Apr 2006 18:51:05 +0200 Message-ID: Thread-Topic: [Pce] Comparison of Encryption vs. Path Key Solutions for the CPSID. Thread-Index: AcZZeTyqrqoHE6qtR3mCIGZZDDyHhAL5Ddwg From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "JP Vasseur" , "Rich Bradford" Cc: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C66563.C8AC21C9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi JP, Richard =20 Please see inline, ________________________________ De : JP Vasseur [mailto:jvasseur@cisco.com]=20 Envoy=E9 : jeudi 6 avril 2006 14:52 =C0 : Rich Bradford Cc : ccamp@ops.ietf.org; pce@ietf.org Objet : Re: [Pce] Comparison of Encryption vs. Path Key Solutions for = the CPSID. =09 =09 Hi,=20 Thanks for the summary Rich. PCE WG members: thanks to provide your feedback on whether: (1) You think that there is a need for such solution,=20 =20 Yes definitely, confidentiality is a key requirements in an = inter-provider context. =20 (2) You would prefer one solution (which one and why ?)=20 =20 (3) You think that there is a need for both=20 =20 Answer to (2) and (3): It seems to me that we should end-up with a single solution so as to = ease interworking. =09 IMO in an inter-AS MPLS-TE environment without PCEs, the paths will be = loose anyway, so there will not be any confidentiality issue.=20 If have some concerns regarding the cost of encryption, particularly = for large paths (we need to think about future P2MP applications with a = large number of hops...). By the way, encryption approaches are really = vulnerable to DoS attacks. Hence I would strongly favor the PKS solution. The optimization = suggested, which consists of sending the computed path segment to the = LSR in an unsolicited manner, just after the computation, sounds = relevant and should be further investigated. =20 Best Regards, =20 JL =20 =20 =20 =09 =09 Thanks. JP. On Apr 5, 2006, at 6:19 PM, Rich Bradford ((rbradfor)) wrote: Hi, As suggested in Dallas, I've described some of the tradeoffs between = the two solutions described in = draft-rbradfor-ccamp-confidential-segment-00.txt. -- Rich =09 The Confidential Path Segment (CPS) ID provides two very different but = equally valid solutions, the Path Key Subobject (PKS) solution and the = Private Route Subobject (PRS) solution. This note examines a number of = the advantages and disadvantages of each solution.=20 =09 In short: The PKS solution allows a PCE to hide the CPS for an AS by = saving it in a database and replacing it with a key in the ERO. During = the LSP setup, the ingress LSR for that AS must query the PCE for an = expansion. The PRS solution allows a CPS for an AS to be hidden by encrypting it, = which may be done by a PCE or by the Head-End LSR. During the LSP setup, = the ingress LSR for that AS must use a decryption key to obtain the = expansion (implying an earlier exchange or configuration).=20 =09 The major differences between the mechanisms involve (1) additional = control messages, (2) performance issues expanding those objects, (3) = the addition of state to the PCE, (4) the solution scope (i.e. = applicability to various topologies of each solution.), and (5) the size = of objects added to existing messages. =09 (1) Additional Control Message Overhead: The PKS solution requires a mechanism to expand the Path Key upon = receipt of the LSP setup request. Since the PCE which calculated the = Path Key might not reside in the entry boundary LSR, the LSR must = request the expansion from the PCE, requiring an additional message = exchange before LSP setup can proceed. The Path Encryption solution does = not require this extra exchange between the PCE and the ingress node for = every LSP. Rather, the decryption key needs to be exchanged only when it = is changed. The result is additional delay during every LSP setup for = the PKS solution but no additional delay for the PRS solution. =09 =09 (2) PCE and LSR Performance: The PKS solution must maintain a (temporary) database of keys adding = overhead to the PCE. The PRS solution requires the encryption of the CPS = in the PCE and decryption of the CPS in the LSR, which could be CPU = intensive. Note that in case of a burst of requests, encryption of large = number of CPS may have an impact on the PCE response time. =09 (3) Addition of State in the PCE: The PKS solution requires the addition of path-specific state and = maintenance of a database in the PCE. The PRS solution requires no = additional state. =09 =09 (4) Solution Scope: The PKS and PRS solutions both work well in conjunction with a PCE to = encode and decode the CPS. However the PKS provides no direct solution = without a PCE. This prevents the PKS solution for working in the case = where A's network straddles B's network and where A wants to use an ERO = for a segment of the LSP across the intervening network, e.g. = (netA)-(netB)-(netA). In addition, the PRS could be used to record a CPS = even if the path (and therefore the returned RRO) crosses multiple = boundaries. Finally, a PRS solution could be adapted to return actual = failure locations in PERRs and/or PATHTEARs, while keeping the failure = location confidential from LSRs without a decryption key. Currently = privacy of this source is maintained by returning the address of border = nodes, which can be very misleading. =09 (5) Message Object Overhead: The PKS solution provides a very compact key or token to identify a = path segment, which generally allows for smaller EROs to be returned by = the PCE and to be requested in the resulting PATH message. A PRS which = contains a CPS must generally be at least as large as the unencrypted = PATH through the AS and may be significantly larger if it is desirable = to hide the number of hops within the network from external view by = padding the PRS. The result is potentially larger PATH (and PCEP) = messages for the PRS solution. =09 =09 Please note that the tradeoffs listed here are for the current I-D. = Some of the shortcomings of each approach could be mitigated by = implementation-specific optimizations. For example, a PCE could choose = to signal the CPS expansion to the entry boundary LSR, shifting the = burden of maintaining the PKS state to the LSR and eliminating the = performance hit during LSP setup. A similar exchange could be performed = for the PRS case, eliminating the need for a separate key exchange. = These examples of extensions are beyond the scope of the ID, but might = be useful when weighing the pros and cons of the two solutions. =09 =09 _______________________________________________ Pce mailing list Pce@lists.ietf.org https://www1.ietf.org/mailman/listinfo/pce ------_=_NextPart_001_01C66563.C8AC21C9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi JP, Richard
 
Please see inline,

De : JP Vasseur=20 [mailto:jvasseur@cisco.com]
Envoy=E9 : jeudi 6 avril = 2006=20 14:52
=C0 : Rich Bradford
Cc : = ccamp@ops.ietf.org;=20 pce@ietf.org
Objet : Re: [Pce] Comparison of Encryption = vs.=20 Path Key Solutions for the CPSID.

Hi,

Thanks for the summary Rich.

PCE WG members: thanks to provide your feedback on whether:
(1) You think=20 that there is a need for such solution, 
 
Yes=20 definitely, confidentiality is a key requirements in an inter-provider = context.
 
(2) You would=20 prefer one solution (which one and why ?) 
 
(3) You think=20 that there is a need for both 
 
Answer to (2) and=20 (3):
It seems to me=20 that we should end-up with a single solution so as to ease=20 interworking.
IMO in an inter-AS MPLS-TE environment without PCEs, the = paths=20 will be loose anyway, so there will not be any = confidentiality=20 issue.
If have some=20 concerns regarding the cost of encryption, particularly for large = paths=20 (we need to think about future P2MP applications with a large number = of=20 hops...). By the way, encryption approaches are really vulnerable to = DoS=20 attacks.
Hence I would strongly favor the PKS solution. The = optimization=20 suggested, which consists of sending the computed path segment to = the LSR=20 in an unsolicited manner, just after the computation, sounds = relevant and=20 should be further investigated.
 
Best=20 Regards,
 
JL
 
 
 
Thanks.

JP.

On Apr 5, 2006, at 6:19 PM, Rich Bradford ((rbradfor)) = wrote:

Hi,

As suggested in Dallas, I=92ve described some of = the=20 tradeoffs between the two solutions described in=20 = draft-rbradfor-ccamp-confidential-segment-00.txt.

-- Rich

The Confidential Path Segment (CPS) ID = provides two=20 very different but equally valid solutions, the Path Key Subobject = (PKS)=20 solution and the Private Route Subobject (PRS) solution. This note = examines=20 a number of the advantages and disadvantages of each solution.=20

In short: The PKS solution allows a PCE to = hide the=20 CPS for an AS by saving it in a database and replacing it with a key = in the=20 ERO. During the LSP setup, the ingress LSR for that AS must query = the PCE=20 for an expansion.

The PRS solution allows a CPS for an AS to = be hidden=20 by encrypting it, which may be done by a PCE or by the Head-End LSR. = During=20 the LSP setup, the ingress LSR for that AS must use a decryption key = to=20 obtain the expansion (implying an earlier exchange or = configuration).=20

The major differences between the = mechanisms involve=20 (1) additional control messages, (2) performance issues expanding = those=20 objects, (3) the addition of state to the PCE, (4) the solution = scope (i.e.=20 applicability to various topologies of each solution.), and (5) the = size of=20 objects added to existing messages.

(1) Additional Control Message=20 Overhead:

The PKS solution requires a mechanism to = expand the=20 Path Key upon receipt of the LSP setup request. Since the PCE which=20 calculated the Path Key might not reside in the entry boundary LSR, = the LSR=20 must request the expansion from the PCE, requiring an additional = message=20 exchange before LSP setup can proceed. The Path Encryption solution = does not=20 require this extra exchange between the PCE and the ingress node for = every=20 LSP. Rather, the decryption key needs to be exchanged only when it = is=20 changed. The result is additional delay during every LSP setup for = the PKS=20 solution but no additional delay for the PRS=20 solution.

(2) PCE and LSR=20 Performance:

The PKS solution must maintain a = (temporary)=20 database of keys adding overhead to the PCE. The PRS solution = requires the=20 encryption of the CPS in the PCE and decryption of the CPS in the = LSR, which=20 could be CPU intensive. Note that in case of a burst of requests, = encryption=20 of large number of CPS may have an impact on the PCE response=20 time.

(3) Addition of State in the=20 PCE:

The PKS solution requires the addition of=20 path-specific state and maintenance of a database in the PCE. The = PRS=20 solution requires no additional state.

(4) Solution = Scope:

The PKS and PRS solutions both work well = in=20 conjunction with a PCE to encode and decode the CPS. However the PKS = provides no direct solution without a PCE. This prevents the PKS = solution=20 for working in the case where A's network straddles B's network and = where A=20 wants to use an ERO for a segment of the LSP across the intervening = network,=20 e.g. (netA)-(netB)-(netA). In addition, the PRS could be used to = record a=20 CPS even if the path (and therefore the returned RRO) crosses = multiple=20 boundaries. Finally, a PRS solution could be adapted to return = actual=20 failure locations in PERRs and/or PATHTEARs, while keeping the = failure=20 location confidential from LSRs without a decryption key. Currently = privacy=20 of this source is maintained by returning the address of border = nodes, which=20 can be very misleading.

(5) Message Object=20 Overhead:

The PKS solution provides a very compact = key or=20 token to identify a path segment, which generally allows for smaller = EROs to=20 be returned by the PCE and to be requested in the resulting PATH = message. A=20 PRS which contains a CPS must generally be at least as large as the=20 unencrypted PATH through the AS and may be significantly larger if = it is=20 desirable to hide the number of hops within the network from = external view=20 by padding the PRS. The result is potentially larger PATH (and PCEP) = messages for the PRS solution.

Please note that the tradeoffs listed here = are for=20 the current I-D. Some of the shortcomings of each approach could be=20 mitigated by implementation-specific optimizations. For example, a = PCE could=20 choose to signal the CPS expansion to the entry boundary LSR, = shifting the=20 burden of maintaining the PKS state to the LSR and eliminating the=20 performance hit during LSP setup. A similar exchange could be = performed for=20 the PRS case, eliminating the need for a separate key exchange. = These=20 examples of extensions are beyond the scope of the ID, but might be = useful=20 when weighing the pros and cons of the two=20 solutions.

 _______________________________________________
Pce mailing list
Pce@lists.ietf.org
https://www1.ietf.org= /mailman/listinfo/pce

= ------_=_NextPart_001_01C66563.C8AC21C9-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Apr 2006 14:44:11 +0000 Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Cc: "Adrian Farrel" , , , , Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-10.txt Date: Fri, 21 Apr 2006 10:42:50 -0400 To: "" Cool. I have updated this based on your review of the GMPLS LSR MIB yesterday. --Tom > Tom and Adrian, > > One minor comments, which is the > expiration date in the header needs > updating. Otherwise, this document > looks good. > > -Joan Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Apr 2006 05:43:29 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=lfp+zGkZPVJm0iSmPowYU8stgp1mhNIVihkvr9btzbgDa7k8MWvdIOU0yTWcczF/; h=Received:Message-ID:From:To:Cc:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Message-ID: <005101c664de$0c8b2240$0500a8c0@jlucianilaptop> From: To: , "Adrian Farrel" , Cc: , , Subject: MIB Dr. review of draft-ietf-ccamp-gmpls-tc-mib-10.txt Date: Thu, 20 Apr 2006 20:53:46 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Tom and Adrian, One minor comments, which is the expiration date in the header needs updating. Otherwise, this document looks good. -Joan Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 21 Apr 2006 05:24:32 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=T2txv7wXsIJRgYWXU8Bi+RLjpqs/xrFOIpkNMR/cBFDpXaSzBmXojwdAq5cc4YNq; h=Received:Message-ID:From:To:Cc:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Message-ID: <001901c664db$2e1ff6e0$0500a8c0@jlucianilaptop> From: To: , "Adrian Farrel" , Cc: , , Subject: MIB Dr. Review for draft-ietf-ccamp-gmpls-te-mib-14.txt Date: Thu, 20 Apr 2006 20:33:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hello Tom and Adrian, Here are a few comments on draft-ietf-ccamp-gmpls-te-mib-14.txt. Thank you for the great updates. Thanks, -Joan Compiles with both smicngPRO and smilint. 1) There is a disconnect in the numbers under the under gmplsTeGroup, was this intentional, if so, please explain, otherwise, please correct it. 1.3.6.1.2.1.10.166.555.3.1 gmplsTeGroups [GMPLS-TE-STD-MIB]: oid-value-assignment 1.3.6.1.2.1.10.166.555.3.1.1 gmplsTunnelGroup [GMPLS-TE-STD-MIB]: object-group 1.3.6.1.2.1.10.166.555.3.1.2 gmplsTunnelSignaledGroup [GMPLS-TE-STD-MIB]: object-group 1.3.6.1.2.1.10.166.555.3.1.3 gmplsTunnelScalarGroup [GMPLS-TE-STD-MIB]: object-group 1.3.6.1.2.1.10.166.555.3.1.6 gmplsTunnelOptionalGroup [GMPLS-TE-STD-MIB]: object-group 1.3.6.1.2.1.10.166.555.3.1.7 gmplsTeNotificationGroup [GMPLS-TE-STD-MIB]: notification-group 2) Expiration date in the page header is incorrect Nadeau and Farrel Expires April 2006 [Page 1] 3) 1.1. Migration Strategy "The gmplsTunnelLSPEncoding may be set to tunnelLspNotGmpls to allow an MPLS-TE LSP tunnel to benefit from the additional objects and tables of GMPLS-LSR-STD-MIB without supporting the GMPLS protocols. Think you mean, GMPLS-TE-STD-MIB in the latter part of the above sentence. 4) 1.1. Migration Strategy "Textual conventions are defined in [RFC3811] and [GMPLSTCMIB]." There aren't any TCs from GMPLSTCMIB, but there are from the IANA-GMPLS-TC-MIB, so perhaps adding IANA-GMPLS-TC-MIB to this statement would be appropriate. 5) (NIT) 2. Terminology "These segment and cross-connect objects are defined in the MPLS Label Switch Router MIB (MPLS-LSR-STD-MIB) [RFC3813], but see also the GMPLS Label Switch Router MIB (GMPLS-LSR-STD-MIB) [GMPLSLSRMIB] for..." Please be sure to use "Label Switching Router" (and not Label Switch Router). 6) Typos: gmplsTunnelLinkProtection This glag is set to indicate that the LSP should not use any link layer protection. s/glag/flag shared This flage is set to indicate that a shared link layer s/flage/flag 7) gmplsTunnelErrorEntry OBJECT-TYPE The use of the term "discontinuity" implies that the counters suffered a discontinuity,but the situation you are describing is that another error occurred. Please rephrase this to something like: "Note that systems which read the objects in this table one at a time should read gmplsTunnelErrorLastTime prior to the first object and after reading the last object of this table to ensure that no additional errors occurred." 8) gmplsTunnelUnnumIf does not appear in the ReadOnly Conformance. 9) I am still unclear about what objects can be supported within MPLS only. Was expecting to see this clarified in the conformance statements. There does seem to be more of a division here than in the GMPLS-LSR-STD-MIB. Could some clarification be made to this point? 10) IANA-GMPLS-TC-MIB Would remove parts of the DESCRIPTION clauses which refer to the GMPLS-TE-STD-MIB module. The reason is that these TCs may eventually be used in other MIB modules and since this particular module will be controlled by IANA, these sort of statements don't appear in IANA MIB Modules as far as I know. "This data type is used as the syntax of the gmplsTunnelLSPEncoding object in the definition of GMPLS-TE-STD-MIB's gmplsTunnelTable." "This data type is used as the syntax of the gmplsTunnelSwitchingType object in the definition of GMPLS-TE-STD-MIB's gmplsTunnelTable." "This data type is used as the syntax of the gmplsTunnelGPid object in the definition of GMPLS-TE-STD-MIB's gmplsTunnelTable." "This data type is used as the syntax of the gmplsTunnelAdminStatusFlags object in the definition of GMPLS-TE-STD-MIB's gmplsTunnelTable." -- the end -- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 20 Apr 2006 23:10:02 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=hUT5XTjIzxxxB2jfn00hwGW0NForheW8lJo5gpXIv3mFZ5LwoDmhox7D4Mvb4Iva; h=Received:Message-ID:From:To:Cc:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Message-ID: <00e101c664a6$fa27d120$0500a8c0@jlucianilaptop> From: To: "Thomas D. Nadeau" Cc: "Adrian Farrel" , , "Wijnen Bert" , "Dan Romascanu (E-mail)" , "Kireeti Kompella" Subject: Re: MIB Dr. Review for draft-ietf-ccamp-gmpls-lsr-mib-12.txt Date: Thu, 20 Apr 2006 14:19:34 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Replies inline. ----- Original Message ----- From: Thomas D. Nadeau To: Cucchiara Joan Cc: Adrian Farrel ; ; Wijnen Bert ; Dan Romascanu (E-mail) ; Kireeti Kompella Sent: Thursday, April 20, 2006 5:15 PM Subject: Re: MIB Dr. Review for draft-ietf-ccamp-gmpls-lsr-mib-12.txt > > Thanks again. Really just 2 quick questions below > for clarification and we can ship this one. > > --Tom > > > > > Tom and Adrian, > > > > Thanks for the great update. A few minor comments. > > > > Thanks, > > Joan > > > > > > *Compiles cleanly with smicngPRO and smilint. > > Yes! > > > 1) The expiration Date which appears as a page > > header is incorrect: > > > > Nadeau and Farrel Expires April 2006 [Page 2] > > Fixed. > > > 2) gmplsInterfaceSignalingCaps OBJECT-TYPE > > > > REFERENCE > > "1. Generalized MPLS Signaling - CR-LDP Extensions, RFC 3472. > > 2. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473." > > DEFVAL { { rsvpGmpls } } > > > > The above references have updates (e.g. see ccamp Charter page) > > and so think these updating RFCs should also be included > > here and in the Normative Reference section: > > > > RFC 3472 is updated by RFC 4201 > > RFC 3473 is updated by RFC 4003,RFC 4201, and RFC 4420 > > > > Please be sure to update these RFCs in other REFERENCE > > clauses also. > > Fixed remainder in this module and in the gmpls-te mib > too. There were no references in the tc mib. > > > 3) The DESCRIPTION clause of gmplsInterfaceEntry > > says"...A conceptual row in this table may also be created via SNMP > > SET commands or automatically by the LSR to supplement a > > conceptual row in the mplsInterfaceTable where the interface > > is not capable of GMPLS but where the other objects carried > > in this row provide useful additional information for an > > MPLS interface." > > > > As I mentioned previously, I think you need to call out > > these MPLS objects (i.e. the objects which do not require > > GMPLS but are in the GMPLS-LSR-STD-MIB module) > > in a separate conformance group, but as I look at this > > MIB, it appears that all the objects seem to apply to > > MPLS, if this is accurate, then please update the > > DESCRIPTION clauses of the ALL conformance groups to > > indicate that these objects also apply to MPLS. > > > > As an example: > > > > gmplsInterfaceGroup OBJECT-GROUP > > OBJECTS { > > gmplsInterfaceSignalingCaps, > > gmplsInterfaceRsvpHelloPeriod > > } > > STATUS current > > DESCRIPTION > > "Collection of objects needed for GMPLS interface configuration > > and performance information." > > ::= { gmplsLsrGroups 1 } > > > > Should be changed to: > > > > "Collection of objects which provide additional information for > > an MPLS interface and are needed for GMPLS interface configuration > > and performance information." > > Yes, they are all required. So do you think this statement > that calls out all objects is sufficient? A similar change then > can be made for the in/out-segment tables: > Yes, adding these statements is sufficient, because it now clarifies that all these objects apply to MPLS. As we discussed early in the review process, believe that email needs to be sent to the MPLS working group to notify them of these objects since they apply to MPLS also. I realize email was sent to MPLS wg on earlier versions but would be good notify the MPLS wg again so they can see the final version of these MIB docs. > gmplsInSegmentGroup OBJECT-GROUP > OBJECTS { > gmplsInSegmentDirection, > gmplsInSegmentExtraParamsPtr > } > STATUS current > DESCRIPTION > "Collection of objects which provide additional > information for an MPLS in-segment and are needed > for GMPLS in-segment configuration and performance > information." > ::= { gmplsLsrGroups 2 } > > gmplsOutSegmentGroup OBJECT-GROUP > OBJECTS { > gmplsOutSegmentDirection, > gmplsOutSegmentTTLDecrement, > gmplsOutSegmentExtraParamsPtr > } > STATUS current > DESCRIPTION > "Collection of objects which provide additional > information for an MPLS out-segment and are needed > for GMPLS out-segment configuration and performance > information." > ::= { gmplsLsrGroups 3 } > > > > 4) Typo: > > > > gmplsLsrModuleReadOnlyCompliance MODULE-COMPLIANCE > > STATUS current > > DESCRIPTION > > "Compliance requirement for implementations that only provide > > read-only support for GMPLS-LSR-STD-MIB. Such devices can then > > be monitored but cannot be configured using this MIB modules." > > > > Last part of the last sentence: > > > > "...configured using this MIB module." > > Got it. > > > 5) GMPLS-LABEL-STD-MIB > > > > DESCRIPTION: > > "... > > This MIB module contains managed object definitions for labels > > within GMPLS systems as defined in: > > Generalized Multi-Protocol Label Switching (GMPLS) Signaling > > Functional Description, Berger, L. (Editor), RFC 3471, > > January 2003." > > > > > > RFC 3471 is updated by RFC 4201,RFC 4328 > > > > Please add these other RFCs and be sure to add them > > to the Normative Reference Section. > > Done. > > > 6) Typo: > > > > gmplsLabelTable > > DESCRIPTION: > > > > "... Labels in the tables in other MIB modules may be referred > > to using row pointer into this table." > > > > Should be "using a row pointer" > > > > 7) Typo: > > > > gmplsLabelTable > > DESCRIPTION: > > > > > > "...a set of resources in the data plane. Practial examples are" > > > > s/Practial/Practical > > > Done. > > > 8) ReadOnly Compliance: > > > > OBJECT gmplsLabelRowStatus > > SYNTAX RowStatus { active(1) } > > MIN-ACCESS read-only > > DESCRIPTION > > "Support for notInService, createAndWait and notReady is not > > required." > > > > > > Would change the DESCRIPTION to: > > "Write access is not required, and active is the only status > > that > > needs to be supported." > > One minor change: > > "Write access is not required, and active(1) is > the only status that needs to be supported." > > > 9) Full Compliance: > > > > OBJECT gmplsLabelRowStatus > > SYNTAX RowStatus { active(1), notInService(2) } > > WRITE-SYNTAX RowStatus { active(1), notInService(2), > > createAndGo(4), destroy(6) } > > DESCRIPTION > > "Support for createAndWait and notReady is not required." > > > > > > Would remove this. > > The description or the entire object? The entire object. If you allow createAndWait and notReady then there is no need to special case this object in the conformance statements. Thanks, -Joan > > > Based on the > > gmplsLabelRowStatus object's DESCRIPTION > > believe you should allow createAndWait and also > > Agent could/should be able to report notReady. > > > > > > 10) NIT: > > > > Would remove the (for example, wavelength labels) because > > I was expecting to see the example carried though and list > > the groups for wavelength labels. > > > > > > Also, need to add gmplsLabelWavebandGroup to the > > list of groups. > > > > Updates appear below: > > > > DESCRIPTION > > "Necessary, but not sufficient, set of objects to implement > > label > > table support. In addition, depending on the type of labels > > supported, the following other > > groups defined below are mandatory: > > gmplsLabelPacketGroup and/or > > gmplsLabelPortWavelengthGroup and/or > > gmplsLabelFreeformGroup and/or > > gmplsLabelSonetSdhGroup and/or > > gmplsLabelWavebandGroup." > > > > OK. > > > 11) Just a reminder to update Normative References > > as discussed above: > > RFC 3471 is updated by RFC 4201,RFC 4328 > > RFC 3472 is updated by RFC 4201 > > RFC 3473 is updated by RFC 4003,RFC 4201, and RFC 4420 > > > > end. > > Done. > > --Tom > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 20 Apr 2006 21:17:22 +0000 Mime-Version: 1.0 (Apple Message framework v749.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: Adrian Farrel , ccamp@ops.ietf.org, Wijnen Bert , "Dan Romascanu (E-mail)" , Kireeti Kompella Content-Transfer-Encoding: 7bit From: "Thomas D. Nadeau" Subject: Re: MIB Dr. Review for draft-ietf-ccamp-gmpls-lsr-mib-12.txt Date: Thu, 20 Apr 2006 17:15:31 -0400 To: Cucchiara Joan Thanks again. Really just 2 quick questions below for clarification and we can ship this one. --Tom > > Tom and Adrian, > > Thanks for the great update. A few minor comments. > > Thanks, > Joan > > > *Compiles cleanly with smicngPRO and smilint. Yes! > 1) The expiration Date which appears as a page > header is incorrect: > > Nadeau and Farrel Expires April 2006 [Page 2] Fixed. > 2) gmplsInterfaceSignalingCaps OBJECT-TYPE > > REFERENCE > "1. Generalized MPLS Signaling - CR-LDP Extensions, RFC 3472. > 2. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473." > DEFVAL { { rsvpGmpls } } > > The above references have updates (e.g. see ccamp Charter page) > and so think these updating RFCs should also be included > here and in the Normative Reference section: > > RFC 3472 is updated by RFC 4201 > RFC 3473 is updated by RFC 4003,RFC 4201, and RFC 4420 > > Please be sure to update these RFCs in other REFERENCE > clauses also. Fixed remainder in this module and in the gmpls-te mib too. There were no references in the tc mib. > 3) The DESCRIPTION clause of gmplsInterfaceEntry > says"...A conceptual row in this table may also be created via SNMP > SET commands or automatically by the LSR to supplement a > conceptual row in the mplsInterfaceTable where the interface > is not capable of GMPLS but where the other objects carried > in this row provide useful additional information for an > MPLS interface." > > As I mentioned previously, I think you need to call out > these MPLS objects (i.e. the objects which do not require > GMPLS but are in the GMPLS-LSR-STD-MIB module) > in a separate conformance group, but as I look at this > MIB, it appears that all the objects seem to apply to > MPLS, if this is accurate, then please update the > DESCRIPTION clauses of the ALL conformance groups to > indicate that these objects also apply to MPLS. > > As an example: > > gmplsInterfaceGroup OBJECT-GROUP > OBJECTS { > gmplsInterfaceSignalingCaps, > gmplsInterfaceRsvpHelloPeriod > } > STATUS current > DESCRIPTION > "Collection of objects needed for GMPLS interface configuration > and performance information." > ::= { gmplsLsrGroups 1 } > > Should be changed to: > > "Collection of objects which provide additional information for > an MPLS interface and are needed for GMPLS interface configuration > and performance information." Yes, they are all required. So do you think this statement that calls out all objects is sufficient? A similar change then can be made for the in/out-segment tables: gmplsInSegmentGroup OBJECT-GROUP OBJECTS { gmplsInSegmentDirection, gmplsInSegmentExtraParamsPtr } STATUS current DESCRIPTION "Collection of objects which provide additional information for an MPLS in-segment and are needed for GMPLS in-segment configuration and performance information." ::= { gmplsLsrGroups 2 } gmplsOutSegmentGroup OBJECT-GROUP OBJECTS { gmplsOutSegmentDirection, gmplsOutSegmentTTLDecrement, gmplsOutSegmentExtraParamsPtr } STATUS current DESCRIPTION "Collection of objects which provide additional information for an MPLS out-segment and are needed for GMPLS out-segment configuration and performance information." ::= { gmplsLsrGroups 3 } > 4) Typo: > > gmplsLsrModuleReadOnlyCompliance MODULE-COMPLIANCE > STATUS current > DESCRIPTION > "Compliance requirement for implementations that only provide > read-only support for GMPLS-LSR-STD-MIB. Such devices can then > be monitored but cannot be configured using this MIB modules." > > Last part of the last sentence: > > "...configured using this MIB module." Got it. > 5) GMPLS-LABEL-STD-MIB > > DESCRIPTION: > "... > This MIB module contains managed object definitions for labels > within GMPLS systems as defined in: > Generalized Multi-Protocol Label Switching (GMPLS) Signaling > Functional Description, Berger, L. (Editor), RFC 3471, > January 2003." > > > RFC 3471 is updated by RFC 4201,RFC 4328 > > Please add these other RFCs and be sure to add them > to the Normative Reference Section. Done. > 6) Typo: > > gmplsLabelTable > DESCRIPTION: > > "... Labels in the tables in other MIB modules may be referred > to using row pointer into this table." > > Should be "using a row pointer" > > 7) Typo: > > gmplsLabelTable > DESCRIPTION: > > > "...a set of resources in the data plane. Practial examples are" > > s/Practial/Practical Done. > 8) ReadOnly Compliance: > > OBJECT gmplsLabelRowStatus > SYNTAX RowStatus { active(1) } > MIN-ACCESS read-only > DESCRIPTION > "Support for notInService, createAndWait and notReady is not > required." > > > Would change the DESCRIPTION to: > "Write access is not required, and active is the only status > that > needs to be supported." One minor change: "Write access is not required, and active(1) is the only status that needs to be supported." > 9) Full Compliance: > > OBJECT gmplsLabelRowStatus > SYNTAX RowStatus { active(1), notInService(2) } > WRITE-SYNTAX RowStatus { active(1), notInService(2), > createAndGo(4), destroy(6) } > DESCRIPTION > "Support for createAndWait and notReady is not required." > > > Would remove this. The description or the entire object? > Based on the > gmplsLabelRowStatus object's DESCRIPTION > believe you should allow createAndWait and also > Agent could/should be able to report notReady. > > > 10) NIT: > > Would remove the (for example, wavelength labels) because > I was expecting to see the example carried though and list > the groups for wavelength labels. > > > Also, need to add gmplsLabelWavebandGroup to the > list of groups. > > Updates appear below: > > DESCRIPTION > "Necessary, but not sufficient, set of objects to implement > label > table support. In addition, depending on the type of labels > supported, the following other > groups defined below are mandatory: > gmplsLabelPacketGroup and/or > gmplsLabelPortWavelengthGroup and/or > gmplsLabelFreeformGroup and/or > gmplsLabelSonetSdhGroup and/or > gmplsLabelWavebandGroup." > OK. > 11) Just a reminder to update Normative References > as discussed above: > RFC 3471 is updated by RFC 4201,RFC 4328 > RFC 3472 is updated by RFC 4201 > RFC 3473 is updated by RFC 4003,RFC 4201, and RFC 4420 > > end. Done. --Tom Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 20 Apr 2006 15:21:20 +0000 To: IETF-Announce From: The IESG Subject: Last Call: 'Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control' to Proposed Standard (draft-ietf-ccamp-rfc3946bis) Reply-to: iesg@ietf.org CC: Message-Id: Date: Thu, 20 Apr 2006 11:19:36 -0400 The IESG has received a request from the Common Control and Measurement Plane WG to consider the following document: - 'Generalized Multi-Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control ' 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 any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-05-04. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ccamp-rfc3946bis-01.txt Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 20 Apr 2006 05:23:19 +0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=dfeW4A+f6OwpgyuxF6NLRzGEPMxhxcQ4JrUiSuHlRuZ5RdETfY4SlojUW2mCBhmf; h=Received:Message-ID:From:To:Cc:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP; Message-ID: <008101c66411$ed40b3e0$0500a8c0@jlucianilaptop> From: To: , "Adrian Farrel" , Cc: , , Subject: MIB Dr. Review for draft-ietf-ccamp-gmpls-lsr-mib-12.txt Date: Wed, 19 Apr 2006 20:32:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Tom and Adrian, Thanks for the great update. A few minor comments. Thanks, Joan *Compiles cleanly with smicngPRO and smilint. 1) The expiration Date which appears as a page header is incorrect: Nadeau and Farrel Expires April 2006 [Page 2] 2) gmplsInterfaceSignalingCaps OBJECT-TYPE REFERENCE "1. Generalized MPLS Signaling - CR-LDP Extensions, RFC 3472. 2. Generalized MPLS Signaling - RSVP-TE Extensions, RFC 3473." DEFVAL { { rsvpGmpls } } The above references have updates (e.g. see ccamp Charter page) and so think these updating RFCs should also be included here and in the Normative Reference section: RFC 3472 is updated by RFC 4201 RFC 3473 is updated by RFC 4003,RFC 4201, and RFC 4420 Please be sure to update these RFCs in other REFERENCE clauses also. 3) The DESCRIPTION clause of gmplsInterfaceEntry says"...A conceptual row in this table may also be created via SNMP SET commands or automatically by the LSR to supplement a conceptual row in the mplsInterfaceTable where the interface is not capable of GMPLS but where the other objects carried in this row provide useful additional information for an MPLS interface." As I mentioned previously, I think you need to call out these MPLS objects (i.e. the objects which do not require GMPLS but are in the GMPLS-LSR-STD-MIB module) in a separate conformance group, but as I look at this MIB, it appears that all the objects seem to apply to MPLS, if this is accurate, then please update the DESCRIPTION clauses of the ALL conformance groups to indicate that these objects also apply to MPLS. As an example: gmplsInterfaceGroup OBJECT-GROUP OBJECTS { gmplsInterfaceSignalingCaps, gmplsInterfaceRsvpHelloPeriod } STATUS current DESCRIPTION "Collection of objects needed for GMPLS interface configuration and performance information." ::= { gmplsLsrGroups 1 } Should be changed to: "Collection of objects which provide additional information for an MPLS interface and are needed for GMPLS interface configuration and performance information." 4) Typo: gmplsLsrModuleReadOnlyCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "Compliance requirement for implementations that only provide read-only support for GMPLS-LSR-STD-MIB. Such devices can then be monitored but cannot be configured using this MIB modules." Last part of the last sentence: "...configured using this MIB module." 5) GMPLS-LABEL-STD-MIB DESCRIPTION: "... This MIB module contains managed object definitions for labels within GMPLS systems as defined in: Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description, Berger, L. (Editor), RFC 3471, January 2003." RFC 3471 is updated by RFC 4201,RFC 4328 Please add these other RFCs and be sure to add them to the Normative Reference Section. 6) Typo: gmplsLabelTable DESCRIPTION: "... Labels in the tables in other MIB modules may be referred to using row pointer into this table." Should be "using a row pointer" 7) Typo: gmplsLabelTable DESCRIPTION: "...a set of resources in the data plane. Practial examples are" s/Practial/Practical 8) ReadOnly Compliance: OBJECT gmplsLabelRowStatus SYNTAX RowStatus { active(1) } MIN-ACCESS read-only DESCRIPTION "Support for notInService, createAndWait and notReady is not required." Would change the DESCRIPTION to: "Write access is not required, and active is the only status that needs to be supported." 9) Full Compliance: OBJECT gmplsLabelRowStatus SYNTAX RowStatus { active(1), notInService(2) } WRITE-SYNTAX RowStatus { active(1), notInService(2), createAndGo(4), destroy(6) } DESCRIPTION "Support for createAndWait and notReady is not required." Would remove this. Based on the gmplsLabelRowStatus object's DESCRIPTION believe you should allow createAndWait and also Agent could/should be able to report notReady. 10) NIT: Would remove the (for example, wavelength labels) because I was expecting to see the example carried though and list the groups for wavelength labels. Also, need to add gmplsLabelWavebandGroup to the list of groups. Updates appear below: DESCRIPTION "Necessary, but not sufficient, set of objects to implement label table support. In addition, depending on the type of labels supported, the following other groups defined below are mandatory: gmplsLabelPacketGroup and/or gmplsLabelPortWavelengthGroup and/or gmplsLabelFreeformGroup and/or gmplsLabelSonetSdhGroup and/or gmplsLabelWavebandGroup." 11) Just a reminder to update Normative References as discussed above: RFC 3471 is updated by RFC 4201,RFC 4328 RFC 3472 is updated by RFC 4201 RFC 3473 is updated by RFC 4003,RFC 4201, and RFC 4420 end. Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 20 Apr 2006 00:22:51 +0000 Message-ID: <064b01c66410$559a7cc0$2101fe0a@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Fw: IESG Statement: Normative and Informative References Date: Thu, 20 Apr 2006 01:18:05 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Hi, Good advice from the IESG on how to classify your references in I-Ds. Adrian ----- Original Message ----- From: "IESG Secretary" To: "IETF Announcement list" Sent: Wednesday, April 19, 2006 2:50 PM Subject: IESG Statement: Normative and Informative References > Normative and Informative References > > Nearly all RFCs contain citations to other documents, and these are > listed in a References section near the end of the RFC. There are many > styles for references, and the RFCs have one of their own. Please > follow the reference style used in recent RFCs. Please note that for > documents that have been assigned an STD or BCP number, the number must > be included in the reference. > > Within an RFC, references to other documents fall into two general > categories: "normative" and "informative". Normative references specify > documents that must be read to understand or implement the technology > in the new RFC, or whose technology must be present for the technology > in the new RFC to work. An informative reference is not normative; > rather, it only provides additional information. For example, an > informative reference might provide background or historical > information. Informative references are not required to implement the > technology in the RFC. > > Note 1: Even references that are relevant only for optional features > must be classified as normative if they meet the above conditions for > normative references. > > Note 2: It is not considered necessary to cite basic specifications > that may be safely assumed to be known to practitioners (for example, > RFC 791 need not be cited in every specification that mentions IPv4). > > Note 3: The normative/informative distinction is relevant in > any document that amounts to a technical specification, even > if its intended status is Experimental or Informational. > > Note 4: Normative references in RFCs cannot be to "work in progress" > documents such as Internet Drafts. Drafts with such references will > not be published as RFCs until the references are also published. > > The distinction between normative and informative references is often > important. The IETF standards process according to RFC 2026 and RFC 3967, > and the RFC Editor publication process, both need to know whether a > reference to a work in progress is normative. An RFC cannot be published > until all of the documents that it lists as normative references have been > published. In practice, this often results in the simultaneous publication > of a group of interrelated RFCs. > > For these reasons, the IESG and the RFC Editor have established > guidelines that will request separate reference lists for normative > and informative references in Internet Drafts and RFCs. For example, > if both types are present, there would be two reference subsections, > numbered s.1 and s.2 for example: > > s.1. Normative References > > xxx > ... > xxx > > s.2. Informative References > > xxx > ... > xxx > > Of course, if there is only one type of reference, only one > section is needed. > > The IESG > > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf-announce > > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 18 Apr 2006 08:04:38 +0000 Message-ID: <44449CE2.8040104@pi.se> Date: Tue, 18 Apr 2006 10:01:38 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) MIME-Version: 1.0 To: mpls@ietf.org, ccamp Subject: mpls wg comments on T-MPLS - schedule Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Working Group(s), (after agreement with the ccamp co-chairs this is sent to the ccamp list also) after discussion with representatives for SG15 and Q12/15 we've some tentative procedure to get our comments on Transport-MPLS into the ITU process. EoB today (Tuesday April 18th) we will give them a list of areas where we have concerns (copy to the mpls mailing list). "End of Business day" will be understood as 11.59PM here in Stockholm (corresponds to approx. 6PM in Boston). We will abstract the list from comments sent to the mpls mailling list. On Friday (April 21st) we will send them a more consolidated list, they have a meeting in Kobe the following week. However, the formal working group comments will be sent to them May 17th. Please send (furthher) comments on G.8110.1 (https://datatracker.ietf.org/documents/LIAISON/file288.zip) G.8112 (https://datatracker.ietf.org/documents/LIAISON/file289.zip) G.8121 (https://datatracker.ietf.org/documents/LIAISON/file290.zip) to the mpls working group mailing list. /Loa and George -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 17 Apr 2006 22:51:50 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt Message-Id: Date: Mon, 17 Apr 2006 18:50:02 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized MPLS (GMPLS) RSVP-TE Signaling Extensions in support of Calls Author(s) : D. Papadimitriou, A. Farrel Filename : draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt Pages : 27 Date : 2006-4-17 In certain networking topologies it may be advantageous to maintain associations between endpoints and key transit points to support an instance of a service. Such associations are known as Calls. A Call does not provide the actual connectivity for transmitting user traffic, but only builds a relationship by which subsequent connections may be made. In Generalized MPLS (GMPLS) such connections are known as Label Switched Paths (LSPs). This document specifies how GMPLS RSVP-TE signaling may be used and extended to support Calls. These mechanisms provide full and logical Call/Connection separation. The mechanisms proposed in this document are applicable to any environment (including multi-area), and for any type of interface: packet, layer-2, time-division multiplexed, lambda or fiber switching. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-17155457.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-17155457.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Apr 2006 22:15:01 +0000 Message-ID: <15a101c66010$e75e2d90$bf849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: , "Tomohiro Otani" , "Thomas D. Nadeau" , "'Kireeti Kompella'" , "Acee Lindem" , Subject: New OSPF MIB module for TE and GMPLS Date: Fri, 14 Apr 2006 23:14:52 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, As originators of the GMPLS extensions for OSPF (RFC4203) the CCAMP working group has a responsibility to develop a MIB module for the management and modelling of these extensions. At the same time, we observed that there is currently no MIB module for the TE extensions described in RFC3630. We have started a work item in draft-ietf-ccamp-gmpls-ospf-mib-00.txt to provide this support and we would welcome ongoing review and input from the OSPF working group. Comments on the CCAMP mailing list or direct to the authors or chairs. If there is a strong feeling that the work should be in the OSPF working group we are open to negotiation. In particular, I notice that draft-ietf-ospf-mib-update-10.txt is still in progress, Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Apr 2006 22:05:54 +0000 Message-ID: <157101c6600f$87b1f300$bf849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "Thomas D. Nadeau" Subject: GMPLS MIB updates Date: Fri, 14 Apr 2006 23:03:48 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, The three recent updates posted by Tom complete (we believe) the revisions from MIB Doctor review. the changes were many, but completely editorial. You may want to have a skim to see what you think, but we do not see the need for a further WG last call. Thanks, Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 14 Apr 2006 19:51:35 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-ospf-mib-00.txt Message-Id: Date: Fri, 14 Apr 2006 15:50:01 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Extensions to the OSPF Management Information Base in support of GMPLS Author(s) : T. Otani, et al. Filename : draft-ietf-ccamp-gmpls-ospf-mib-00.txt Pages : Date : 2006-4-14 This memo defines the Management Information Base (MIB) objects in order to manage OSPF routing information with extension in support of Multi-protocol label switching (MPLS) as well as Generalized MPLS (GMPLS) for use with network management protocols. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-ospf-mib-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-ospf-mib-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-ospf-mib-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-14144538.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-ospf-mib-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-ospf-mib-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-14144538.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Apr 2006 19:51:22 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-te-mib-14.txt Message-Id: Date: Wed, 12 Apr 2006 15:50:02 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multiprotocol Label Switching (GMPLS) Traffic Engineering Management Information Base Author(s) : T. Nadeau, A. Farrel Filename : draft-ietf-ccamp-gmpls-te-mib-14.txt Pages : 60 Date : 2006-4-12 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Generalized Multiprotocol Label Switching (GMPLS) based traffic engineering. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-te-mib-14.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-te-mib-14.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-te-mib-14.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-12112455.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-te-mib-14.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-te-mib-14.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-12112455.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Apr 2006 16:14:00 +0000 Message-ID: <103d01c65e4c$0a2992e0$bf849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Draft minutes uploaded Date: Wed, 12 Apr 2006 17:05:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Minutes from Dallas are at http://www3.ietf.org/proceedings/06mar/minutes/ccamp.html Please review and comment. Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Apr 2006 14:58:53 +0000 Message-ID: <443D1523.1050400@pi.se> Date: Wed, 12 Apr 2006 16:56:35 +0200 From: Loa Andersson Organization: Acreo AB User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) MIME-Version: 1.0 To: Greg Jones CC: statements@ietf.org, Stephen Trowbridge , Ghani Abbas , Mark Jones , Malcolm Betts , Yoichi Maeda , Ross Callon , Bill Fenner , Scott Bradner , George Swallow , MPLS mailing list , CCAMP mailing list Subject: Response to your liaison on T-MPLS Consented Recommendations Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit To: ITU-T Study Group 15 Greg Jones greg.jones@itu.int Cc: IETF statements@ietf.org Stephen Trowbridge sjtrowbridge@lucent.com Ghani Abbas Ghani.Abbas@marconi.com Mark Jones mark.jones@sprint.com Malcolm Betts betts01@nortel.com Yoichi Maeda maeda@ansl.ntt.co.jp Ross Callon rcallon@juniper.net Bill Fenner fenner@research.att.com Scott Bradner sob@harvard.edu George Swallow swallow@cisco.com MPLS mailing list mpls@lists.ietf.org CCAMP mailing list ccamp@ops.ietf.org From: IETF MPLS Working Group Response contact: Loa Andersson loa@pi.se Technical contact: Loa Andersson loa@pi.se Purpose: Response Subject: Response to your liaison on T-MPLS Consented Recommendations Thank you for liaising G.8110.1, G.8112 and G.8121 on April 2, and requesting a response by April 17. It will not be possible for the MPLS Working Group to do a comprehensive review in this short time. Our mode of operation normally gives a two week period to review (working group last call) for well-known and well-discussed documents. Since this topic is mostly new to the working group, it is our estimate that we will need a four week period. We, therefore, intend to send our comments to SG15 by May 17. We sincerely hope that it will be possible for you to accommodate this late response, and take our comments into your process. Loa Andersson and George Swallow IETF MPLS Working Group Co-Chairs -- Loa Andersson Principal Networking Architect Acreo AB phone: +46 8 632 77 14 Isafjordsgatan 22 mobile: +46 739 81 21 64 Kista, Sweden email: loa.andersson@acreo.se loa@pi.se Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Apr 2006 09:51:40 +0000 Sensitivity: Subject: T-MPLS comments To: ccamp@ops.ietf.org Message-ID: From: "Diego Caviglia" Date: Wed, 12 Apr 2006 11:50:44 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii A couple of quick comment to the T-MPLS specs. G.8110.1 "Bidirectional LSPs are supported by associating two unidirectional LSPs in the data plane" [dc] This sentence seems to exclude the possibility to have a simmetric bi-directional LSP. If GMPLS is used as a control plane for T-MPLS should be good to include the possibility to have simmetric bidirectional LSPs given that GMPLS support the set-up of that kind of circuits. Moreover having a single 5-tuple identifiyng a bidirectional LSP simplify the maintenence of bi-dicectional circuits. "Both global and per interface label space are supported" [dc] RFC 3031 defines the two kind of label scope as: 1 per-interface label space 2 per-platform label space. I think that the definition of 3031 should be also used in G.8110.1, given that the term global is misleading. Regards Diego Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 12 Apr 2006 09:33:24 +0000 Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 To: Greg Jones Cc: Kam Lam , Malcolm Betts , Stephen Trowbridge , Scott Bradner , Ross Callon , Bill Fenner , Kireeti Kompella , CCAMP Mailing List , Adrian Farrel , Adrian Farrel , statements@ietf.org From: Adrian Farrel(IETF CCAMP WG) Subject: New Liaison Statement, "Recently published IETF RFCs relevant to GMPLS, Optical Transport Networks, and Packet Transport Networks" Message-Id: Date: Wed, 12 Apr 2006 05:29:59 -0400 Title: Recently published IETF RFCs relevant to GMPLS, Optical Transport Networks, and Packet Transport Networks Submission Date: 2006-04-12 URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=213 From: Adrian Farrel(IETF CCAMP WG) To: ITU-T SG15(Greg Jones ) Cc: Kam Lam Malcolm Betts Stephen Trowbridge Scott Bradner Ross Callon Bill Fenner Kireeti Kompella CCAMP Mailing List Reponse Contact: Adrian Farrel Technical Contact: Adrian Farrel Purpose: For information Body: Recently published IETF RFCs relevant to GMPLS, Optical Transport Networks, and Packet Transport Networks The IETF's CCAMP working group is pleased to inform Study Group 15 of the ITU-T of the publication of several new RFCs that are relevant to the work that you are doing with optical and packet transport networks. Several of these RFCs received useful review and input from Study Group 15 participants for which CCAMP would like to express its thanks. RFC 4257 http://www.ietf.org/rfc/rfc4257.txt Title Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks Abstract Generalized Multi-Protocol Label Switching (GMPLS) is a suite of protocol extensions to MPLS to make it generally applicable, to include, for example, control of non packet-based switching, and particularly, optical switching. One consideration is to use GMPLS protocols to upgrade the control plane of optical transport networks. This document illustrates this process by describing those extensions to GMPLS protocols that are aimed at controlling Synchronous Digital Hierarchy (SDH) or Synchronous Optical Networking (SONET) networks. SDH/SONET networks make good examples of this process for a variety of reasons. This document highlights extensions to GMPLS-related routing protocols to disseminate information needed in transport path computation and network operations, together with (G)MPLS protocol extensions required for the provisioning of transport circuits. New capabilities that an GMPLS control plane would bring to SDH/SONET networks, such as new restoration methods and multi-layer circuit establishment, are also discussed. RFC 4258 http://www.ietf.org/rfc/rfc4258.txt Title Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON) Abstract The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting Time Division Multiplexing (TDM) connections including Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) and Optical Transport Networks (OTNs). This document concentrates on the routing requirements placed on the GMPLS suite of protocols in order to support the capabilities and functionalities of an Automatically Switched Optical Network (ASON) as defined by the ITU-T. RFC 4327 http://www.ietf.org/rfc/rfc4327.txt Title Link Management Protocol (LMP) Management Information Base (MIB) Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling the Link Management Protocol (LMP). RFC 4328 http://www.ietf.org/rfc/rfc4328.txt Title Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control Abstract This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling documents. It describes the technology- specific information needed to extend GMPLS signaling to control Optical Transport Networks (OTN); it also includes the so-called pre-OTN developments. RFC 4394 http://www.ietf.org/rfc/rfc4394.txt Title A Transport Network View of the Link Management Protocol (LMP) Abstract The Link Management Protocol (LMP) has been developed as part of the Generalized MPLS (GMPLS) protocol suite to manage Traffic Engineering (TE) resources and links. The GMPLS control plane (routing and signaling) uses TE links for establishing Label Switched Paths (LSPs). This memo describes the relationship of the LMP procedures to 'discovery' as defined in the International Telecommunication Union (ITU-T), and ongoing ITU-T work. This document provides an overview of LMP in the context of the ITU-T Automatically Switched Optical Networks (ASON) and transport network terminology and relates it to the ITU-T discovery work to promote a common understanding for progressing the work of IETF and ITU-T. RFC 4397 http://www.ietf.org/rfc/rfc4397.txt Title A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture Abstract Generalized Multiprotocol Label Switching (GMPLS) has been developed by the IETF to facilitate the establishment of Label Switched Paths (LSPs) in a variety of data plane technologies and across several architectural models. The ITU-T has specified an architecture for the control of Automatically Switched Optical Networks (ASON). This document provides a lexicography for the interpretation of GMPLS terminology within the context of the ASON architecture. It is important to note that GMPLS is applicable in a wider set of contexts than just ASON. The definitions presented in this document do not provide exclusive or complete interpretations of GMPLS concepts. This document simply allows the GMPLS terms to be applied within the ASON context. RFC 4426 http://www.ietf.org/rfc/rfc4426.txt Title Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification Abstract This document presents a functional description of the protocol extensions needed to support Generalized Multi-Protocol Label Switching (GMPLS)-based recovery (i.e., protection and restoration). Protocol specific formats and mechanisms will be described in companion documents. RFC 4427 http://www.ietf.org/rfc/rfc4427.txt Title Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) Abstract This document defines a common terminology for Generalized Multi- Protocol Label Switching (GMPLS)-based recovery mechanisms (i.e., protection and restoration). The terminology is independent of the underlying transport technologies covered by GMPLS. RFC 4428 http://www.ietf.org/rfc/rfc4428.txt Title Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) Abstract This document provides an analysis grid to evaluate, compare, and contrast the Generalized Multi-Protocol Label Switching (GMPLS) protocol suite capabilities with the recovery mechanisms currently proposed at the IETF CCAMP Working Group. A detailed analysis of each of the recovery phases is provided using the terminology defined in RFC 4427. This document focuses on transport plane survivability and recovery issues and not on control plane resilience and related aspects. All IETF RFCs can be downloaded for free from http://www.ietf.org/rfc.html The current work plan and progress status of the CCAMP working group can be viewed at http://www.ietf.org/html.charters/ccamp-charter.html The CCAMP working group welcomes questions and discussion about all of its work from individuals or organisations. The CCAMP mailing list is open to anyone. Details of subscription can be found on the CCAMP charter page. Regards, Adrian Farrel and Kireeti Kompella CCAMP working group chairs Attachment(s): No document has been attached Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Apr 2006 22:51:10 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-tc-mib-10.txt Message-Id: Date: Tue, 11 Apr 2006 18:50:01 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Definitions of Textual Conventions for Generalized Multiprotocol Label Switching (GMPLS) Management Author(s) : T. Nadeau, A. Farrel Filename : draft-ietf-ccamp-gmpls-tc-mib-10.txt Pages : 9 Date : 2006-4-11 This document defines a Management Information Base (MIB) module which contains Textual Conventions to represent commonly used Generalized Multiprotocol Label Switching (GMPLS) management information. The intent is that these TEXTUAL CONVENTIONS (TCs) will be imported and used in GMPLS related MIB modules that would otherwise define their own representations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-tc-mib-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-11154635.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-tc-mib-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-tc-mib-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-11154635.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Apr 2006 22:51:01 +0000 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org Cc: ccamp@ops.ietf.org From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ccamp-gmpls-lsr-mib-12.txt Message-Id: Date: Tue, 11 Apr 2006 18:50:01 -0400 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Control and Measurement Plane Working Group of the IETF. Title : Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR) Management Information Base Author(s) : T. Nadeau, A. Farrel Filename : draft-ietf-ccamp-gmpls-lsr-mib-12.txt Pages : 42 Date : 2006-4-11 This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor a Generalized Multiprotocol Label Switching (GMPLS) Label Switching Router (LSR). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-12.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ccamp-gmpls-lsr-mib-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-4-11155238.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ccamp-gmpls-lsr-mib-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ccamp-gmpls-lsr-mib-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-4-11155238.I-D@ietf.org> --OtherAccess-- --NextPart-- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 11 Apr 2006 20:37:03 +0000 Message-ID: <0dcd01c65da7$771a6d20$bf849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: MPLS WG has a liaison on T-MPLS Date: Tue, 11 Apr 2006 21:35:15 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Hi, It's been pointed out to me that some folk in CCAMP might not be following the MPLS mailing list too closely. The MPLS working group has received the liaison below from the ITU-T with respect to three Recommendations that have been produced on "Transport MPLS" known as T-MPLS. T-MPLS appears to be the use of some of the facilities of an MPLS data plane in order to construct a packet-based transport network. Although no work on the control plane has been started, we may see this a prime candidate for GMPLS since the GMPLS protocol family is tuned for transport networks and supports MPLS packet data planes. Your review input on these documents is welcomed and should, in the first instance, be sent to the MPLS working group who are putting together a coordinated response. Cheers, Adrian ----- Original Message ----- From: "Greg Jones (ITU-T SG 15)" To: "George Swallow" ; "Loa Andersson" Cc: ; ; ; ; ; ; ; ; ; ; Sent: Sunday, April 02, 2006 8:59 PM Subject: [mpls] New Liaison Statement, "T-MPLS Consented Recommendations" > > Title: T-MPLS Consented Recommendations > Submission Date: 2006-04-02 > URL of the IETF Web page: https://datatracker.ietf.org/public/liaison_detail.cgi?detail_id=207 > Please reply by 2006-04-17 > > From: Greg Jones(ITU-T SG 15) > To: IETF MPLS WG, CC: MFA Forum(George Swallow , Loa Andersson ) > Cc: info@mfaforum.org > maeda@ansl.ntt.co.jp > sjtrowbridge@lucent.com > rcallon@juniper.net > fenner@research.att.com > sob@harvard.edu > sbrim@cisco.com > mpls@lists.ietf.org > Reponse Contact: tsbsg15@itu.int > Technical Contact: Ghani.Abbas@marconi.com > mark.jones@sprint.com > betts01@nortel.com > Purpose: For action > Body: We apologize for not having sent a liaison regarding three consented Recommendations related to > T-MPLS. The intent of these Recommendations is not to change MPLS but rather to identify a > subset of existing MPLS necessary and sufficient to provide connection-oriented packet transport. > The approach to the work was to make a profile of the MPLS data plane functionalities defined in > IETF RFCs using the description of MPLS provided in G.8110 (which was approved last year). > The intended application of this profile is to provide a connection-oriented packet transport > network. > The focus of the three new recommendations is on the data plane aspects of T-MPLS. Control plane > aspects are currently for further study and the work on this subject is starting. > According to our work methodology the T-MPLS definitions are split into the three main > Recommendations that have been consented in February 2006: > * G.8110.1 dealing with the T-MPLS Architecture > * G.8112 dealing with T-MPLS interface specification > * G.8121 dealing with T-MPLS equipment functional specification > A brief high-level introduction of the essential features and selected options for Transport MPLS > can be found in section 6/G.8110.1. > The objective of the work done by ITU-T SG15 was to define a way to use MPLS as a connection- > oriented packet-based transport solution for packet aware transport networks that can support both > packet and circuit (e.g. SDH, OTH or WDM) switching technologies under a common operation, > control and management paradigm. For this purpose T-MPLS deploys the MPLS frame format, > Client to MPLS mapping and MPLS to MPLS multiplexing and complements this with transport > network OAM (Y.1711), nested connection monitoring requiring the labels to be present up to the > final node in the network, protection switching (Y.1720/G.8131), transport network based control > and management planes, maintaining frame ordering and a restricted number of classes of > service/queues. > * MPLS has many applications and it is desirable to identify a subset of MPLS technology that > provides the necessary and sufficient functionality for transport applications. > We have indicated below some of the options we have selected :- > * In IETF RFCs the usage of PHP is optional. We decided not to use it in order to simplify OAM > procedures > * In IETF RFCs the usage of merging is optional. We decided not to use it in order to simplify > OAM procedures and also because the relative lower number of LSPs to be supported is not > considered a major scaling issue > * The usage of ECMP is optional. We decided not to use it in order to simplify OAM procedures > * Leaving labels 16-31 for further study was seen as a no change because the label allocation on a > link is defined in IETF RFCs as a local matter for any MPLS device. > We are not expecting that the current version of the specification is going to create any > interoperability issue. We envisage two possible cases of interoperability: > 1. Interoperability between a T-MPLS box and an existing full-featured and fully configurable > MPLS box can be solved by configuring the MPLS box to use the same options selected by T- > MPLS (T-MPLS being a profile of MPLS this should be possible). In this case the link between > the two boxes is a T-MPLS link and in the scope of our Recommendations. > 2. Interoperability between a transport platform supporting T-MPLS and an existing MPLS box > that uses a different option selection than T-MPLS, should be solved by the transport platform. > In this case the link between the transport platform and the MPLS box is not a T-MPLS link and > therefore it is outside the scope of T-MPLS recommendations. We are looking for cooperation > with IETF to develop the detailed specification of this case. > Please find attached the text of the consented Recommendations. Please note that some minor > modifications may be made to these draft Recommendations as a result of comments made during > the approval process > We will appreciate your comments and suggestions in relation to the initial scope of T-MPLS as a > packet transport network technology. > We are planning to review your comments during the next meeting that is planned in Kobe (Japan) > on 22-27 April 2006. Results of the comments will be included into our future work (e.g. corrigenda > or amendments) on T-MPLS Recommendations. Amendments of T-MPLS Recommendations are > already in our plan for the next SG15 plenary meeting in November 2006.We are looking forward > for future cooperation with you in T-MPLS data plane and control plane evolution. > > Attachments: Consented Text of G.8110.1, G.8112, G.8121 > Attachment(s): > Consented Text of G.8110.1 (https://datatracker.ietf.org/documents/LIAISON/file288.zip) > Consented Text of G.8112 (https://datatracker.ietf.org/documents/LIAISON/file289.zip) > Consented Text of G.8121 (https://datatracker.ietf.org/documents/LIAISON/file290.zip) > > > > > _______________________________________________ > mpls mailing list > mpls@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/mpls > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Apr 2006 16:12:58 +0000 From: "Marco Ruffini" To: "'Kireeti Kompella'" Cc: Subject: RE: GMPLS dynamics vs. issues with optical amplifiers Date: Mon, 10 Apr 2006 17:12:20 +0100 Message-ID: <002701c65cb9$8b38abd0$1737e286@PC> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, My understanding is that supposing that the optical path can be = physically allocated (e.g. none of the optical trails included in the path get = blocked for physical constraint reasons), there must be an adaptation in the operative parameters of the optical amplifiers to avoid that the setup = of a new wavelength could disturb the signals brought by the other = wavelengths in the same fiber. So on one hand GMPLS should consider if there is any blocking physical constraint that may impair the allocating of a new wavelength on a = specified path. On the other hand it should be considered how long it would take to the transport layer to adapt all the physical parameter in the path to = include a new wavelength on the fiber without disturbing the existing signals (I imagine this could be quite a lengthy process if more amplifiers are cascaded, like in a long haul system for example). This issue I think = would put a lower limit to the reconfiguration-time of new optical paths. =20 Marco -----Original Message----- From: Kireeti Kompella [mailto:kireeti@juniper.net]=20 Sent: 10 April 2006 16:31 To: Marco Ruffini Cc: ccamp@ops.ietf.org Subject: Re: GMPLS dynamics vs. issues with optical amplifiers=20 Hi Marco, On Mon, 10 Apr 2006, Marco Ruffini wrote: > I'm a PhD student on optical network and I'm following the development = of > the GMPLS work. > > I had a recent discussion with people working on the optical transport > network who where telling me their concern about creating dynamical = path > over trails including optical amplifiers. > > They say that cross-talk and gain fluctuation effects may limit the > capability of fast allocating new wavelengths over those trials. We've talked on and off about these in CCAMP, and there have been=20 drafts to describe some of the various optical impairments to consider. In the GMPLS structure defined so far, there are link attributes (such=20 as metrics and bandwidth), and typically, these can be combined simply=20 to get a functioning path. Thus, for metrics, the combining function=20 is summation, and for bandwidth, the function is "min". To accommodate attributes that are not carried as TE extensions today,=20 we may have to add node attributes (say for dB loss across a mirror=20 complex). We may also have to linearize impairments, or define how=20 they are composed across links and nodes; this is not always easy to do. You say "fast allocating new wavelengths". I would have thought that=20 the issue is not how fast the allocation is, but whether the=20 allocation and ultimately, the optical LSP setup, is successful taking=20 into account optics and physics. Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Apr 2006 15:55:56 +0000 From: "Richard Rabbat" To: "'Don Fedyk'" , "'Filippo Cugini'" , "'Adrian Farrel'" , "'Marco Ruffini'" Cc: Subject: RE: GMPLS dynamics vs. issues with optical amplifiers Date: Mon, 10 Apr 2006 08:55:00 -0700 Message-ID: <012b01c65cb7$1f907810$353ba485@PHOENIX> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, There are pros and cons to advertising optical information including = lambda availability and optical impairements. GMPLS is not supposed to replace advanced path computation tools. Actually, an entity such as the PCE = would be a perfect piece in the architecture of a lambda network as it is = expected to provide advanced computation capabilities beyond CSPF. Actually, we've been looking at some interop scenarii where we are = clearly in need for standardization and mentioned one such scenario in=20 http://www.ietf.org/internet-drafts/draft-shiba-ccamp-gmpls-lambda-labels= -01 .txt I think it's time to do a proper analysis of what support already = exists, what is still needed and work on extensions (if needed) to support the = new generation of ROADM and PXC devices where interop is required. A few vendors who build ROADMs and PXCs, as well as SPs deploying them = have expressed interest in this topic when we discussed the 1st version at = CCAMP. I think it's time to sit down and take a stab at it so we have an interesting draft to discuss in Montreal. Send me email if you have some cycles to spare on this topic. Richard. =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Don Fedyk > Sent: Monday, April 10, 2006 8:05 AM > To: Filippo Cugini; Adrian Farrel; Marco Ruffini > Cc: ccamp@ops.ietf.org > Subject: RE: GMPLS dynamics vs. issues with optical amplifiers >=20 >=20 > Hi all >=20 > About a year ago we started to collect requirements for towards this > area in a draft. Our current thinking is that the optical/photonic > networks will have fairly proprietary ways of dealing with the > non-linear properties but that the interface to GMPLS can be=20 > summarized > as a fairly generic network interface with a simple metric and a > blocking capability. We only got as far a the requirements. The draft > is in in need of a refresh I will try to do that shortly. I have to > contact some other people who were interested in the area.=20 >=20 > If you cannot find a copy of the draft I will send it to you.=20 >=20 > draft-ashwood-ccamp-gmpls-constraint-reqts-00 >=20 > Regards, > Don=20 >=20 > =20 >=20 > > -----Original Message----- > > From: owner-ccamp@ops.ietf.org=20 > > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Filippo Cugini > >=20 > >=20 > > Hi all, > >=20 > > IMO the issue will have to be faced soon. Transparent network=20 > > elements such=20 > > as ROADM and PXC are beginning to be deployed in optical=20 > > transport networks. However, the current GMPLS does not=20 > > provide any functionality to keep track=20 > > of the signal quality degradation. Thus, transparent mesh=20 > > networks must be=20 > > statically designed, during the network planning, to=20 > > guarantee that even the=20 > > most impaired connection (e.g., the longest path) is=20 > > acceptable. Otherwise,=20 > > because of the current GMPLS limits, connections can=20 > > successfully be set up=20 > > even if they do not comply with physical parameters=20 > > constraints. However, the worst case design approach heavily=20 > > limits the size of the=20 > > transparent networks. > >=20 > > Filippo > >=20 > >=20 > > ----- Original Message -----=20 > > From: "Adrian Farrel" > > > [..] > > > - There *might* be a future requirement to signal certain > > > constraints, but we would need to see the requirements clearly > > > stated. > > > - There is probably a need to enhance the advertisement of > > > some key physical attributes of optical links and nodes in > > > the IGPs. At the moment, however, this information > > > appears to be gathered through inventory systems and > > > there has been very little consideration of this requirement. > >=20 > >=20 > >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Apr 2006 15:55:48 +0000 To: "Huub van Helvoort" , "Marco Ruffini" Cc: ccamp@ops.ietf.org Subject: Re: GMPLS dynamics vs. issues with optical amplifiers Message-ID: Date: Mon, 10 Apr 2006 17:55:37 +0200 From: "Americo F. Muchanga" Organization: KTH Content-Type: text/plain; format=flowed; delsp=yes; charset=utf-8 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit User-Agent: Opera M2/8.51 (Win32, build 7712) Huub, It is true that GMPLS addresses bandwidth management as one of the primary concerns but GMPLS as such thus include information that is aimed at enabling end notes to establish and end-to-end light path. This being the case, the constraints regarding the quality of that path from physical properties perspective is crucial to be taken in consideration. Otherwise we might need to maintain a secondary system just to deal with these effects. So it is justified to start this discussion to see if GMPLS could be extended to also carry that information. rgds, americo./ On Mon, 10 Apr 2006 10:07:46 +0200, Huub van Helvoort wrote: > Hello Marco, > > You wrote: > >> I’m a PhD student on optical network and I’m following the >> development of the GMPLS work. >> I had a recent discussion with people working on the optical >> transport network who where telling me their concern about creating >> dynamical path over trails including optical amplifiers. >> They say that cross-talk and gain fluctuation effects may limit the >> capability of fast allocating new wavelengths over those trials. > > Cross-talk and gain are physical properties and not related > to bandwidth management like GMPLS. > > IMO the concern is unjustified. > >> I just wanted to know what is your opinion about this and if is there >> some working group within the IETF already trying to challenge this >> problem. > > IMO for the physical properties you should turn to the ITU-T. > > Cheers, Huub. > -- Americo F. Muchanga Telecommunications Systems Lab (TSLAB/KTH) School of Information and Communication Technology The Royal Institute of Technology KTH Stockholm, Sweden Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Apr 2006 15:31:27 +0000 Date: Mon, 10 Apr 2006 08:31:00 -0700 (PDT) From: Kireeti Kompella To: Marco Ruffini cc: ccamp@ops.ietf.org Subject: Re: GMPLS dynamics vs. issues with optical amplifiers Message-ID: <20060410081618.F68964@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Hi Marco, On Mon, 10 Apr 2006, Marco Ruffini wrote: > I'm a PhD student on optical network and I'm following the development of > the GMPLS work. > > I had a recent discussion with people working on the optical transport > network who where telling me their concern about creating dynamical path > over trails including optical amplifiers. > > They say that cross-talk and gain fluctuation effects may limit the > capability of fast allocating new wavelengths over those trials. We've talked on and off about these in CCAMP, and there have been drafts to describe some of the various optical impairments to consider. In the GMPLS structure defined so far, there are link attributes (such as metrics and bandwidth), and typically, these can be combined simply to get a functioning path. Thus, for metrics, the combining function is summation, and for bandwidth, the function is "min". To accommodate attributes that are not carried as TE extensions today, we may have to add node attributes (say for dB loss across a mirror complex). We may also have to linearize impairments, or define how they are composed across links and nodes; this is not always easy to do. You say "fast allocating new wavelengths". I would have thought that the issue is not how fast the allocation is, but whether the allocation and ultimately, the optical LSP setup, is successful taking into account optics and physics. Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Apr 2006 15:16:25 +0000 Date: Mon, 10 Apr 2006 08:15:42 -0700 (PDT) From: Kireeti Kompella To: ccamp@ops.ietf.org Subject: Re: Progressing docs Message-ID: <20060410081007.G68964@kummer.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Fri, 31 Mar 2006, Kireeti Kompella wrote: > This is to double-check support *on the list* for the following I-Ds to go to > WG docs: > > a) MPLS-GMPLS interworking > draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt > b) "hierarchy bis" > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > c) Call Support > draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt > d) Ethernet TSpec > draft-dimitri-mef-ethernet-traffic-parameters-00.txt > e) OSPF-TE MIB > draft-otani-ccamp-gmpls-ospf-mib-02.txt > > Please say for each if you think it should/should not become a WG doc. Thanks, all, for your responses. All of the above have support. Authors/editors, please resubmit your docs as WG docs: draft-ietf-ccamp-mpls-gmpls-interwork-fmwk-00.txt draft-ietf-ccamp-lsp-hierarchy-bis-00.txt draft-ietf-ccamp-gmpls-rsvp-te-call-00.txt draft-ietf-mef-ethernet-traffic-parameters-00.txt draft-ietf-ccamp-gmpls-ospf-mib-00.txt Please make sure that the formating complies and that there are no non-ascii characters in your doc. Hierarchy-bis: please change the title as agreed. Thanks again, Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Apr 2006 15:05:52 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: GMPLS dynamics vs. issues with optical amplifiers Date: Mon, 10 Apr 2006 11:05:17 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA407BBCFCB@zrtphxm2> Thread-Topic: GMPLS dynamics vs. issues with optical amplifiers Thread-Index: AcZcrrWGBTlG3fKmS2qryqs/nS+5JQAABLvg From: "Don Fedyk" To: "Filippo Cugini" , "Adrian Farrel" , "Marco Ruffini" Cc: Hi all About a year ago we started to collect requirements for towards this area in a draft. Our current thinking is that the optical/photonic networks will have fairly proprietary ways of dealing with the non-linear properties but that the interface to GMPLS can be summarized as a fairly generic network interface with a simple metric and a blocking capability. We only got as far a the requirements. The draft is in in need of a refresh I will try to do that shortly. I have to contact some other people who were interested in the area.=20 If you cannot find a copy of the draft I will send it to you.=20 draft-ashwood-ccamp-gmpls-constraint-reqts-00 Regards, Don=20 =20 > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Filippo Cugini >=20 >=20 > Hi all, >=20 > IMO the issue will have to be faced soon. Transparent network=20 > elements such=20 > as ROADM and PXC are beginning to be deployed in optical=20 > transport networks. However, the current GMPLS does not=20 > provide any functionality to keep track=20 > of the signal quality degradation. Thus, transparent mesh=20 > networks must be=20 > statically designed, during the network planning, to=20 > guarantee that even the=20 > most impaired connection (e.g., the longest path) is=20 > acceptable. Otherwise,=20 > because of the current GMPLS limits, connections can=20 > successfully be set up=20 > even if they do not comply with physical parameters=20 > constraints. However, the worst case design approach heavily=20 > limits the size of the=20 > transparent networks. >=20 > Filippo >=20 >=20 > ----- Original Message -----=20 > From: "Adrian Farrel" > > [..] > > - There *might* be a future requirement to signal certain > > constraints, but we would need to see the requirements clearly > > stated. > > - There is probably a need to enhance the advertisement of > > some key physical attributes of optical links and nodes in > > the IGPs. At the moment, however, this information > > appears to be gathered through inventory systems and > > there has been very little consideration of this requirement. >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Apr 2006 14:54:37 +0000 Message-ID: <014001c65cae$a0075da0$ad021e0a@Platini> From: "Filippo Cugini" To: "Adrian Farrel" , "Marco Ruffini" Cc: Subject: Re: GMPLS dynamics vs. issues with optical amplifiers Date: Mon, 10 Apr 2006 16:54:10 +0200 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit Hi all, IMO the issue will have to be faced soon. Transparent network elements such as ROADM and PXC are beginning to be deployed in optical transport networks. However, the current GMPLS does not provide any functionality to keep track of the signal quality degradation. Thus, transparent mesh networks must be statically designed, during the network planning, to guarantee that even the most impaired connection (e.g., the longest path) is acceptable. Otherwise, because of the current GMPLS limits, connections can successfully be set up even if they do not comply with physical parameters constraints. However, the worst case design approach heavily limits the size of the transparent networks. Filippo ----- Original Message ----- From: "Adrian Farrel" > [..] > - There *might* be a future requirement to signal certain > constraints, but we would need to see the requirements clearly > stated. > - There is probably a need to enhance the advertisement of > some key physical attributes of optical links and nodes in > the IGPs. At the moment, however, this information > appears to be gathered through inventory systems and > there has been very little consideration of this requirement. Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Apr 2006 14:13:51 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: GMPLS dynamics vs. issues with optical amplifiers Date: Mon, 10 Apr 2006 09:13:39 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC7618@KCCLUST06EVS1.ugd.att.com> Thread-Topic: GMPLS dynamics vs. issues with optical amplifiers Thread-Index: AcZcqHp/UC+zxd5rSHG8jGIgWWRt0gAAFftQ From: "Ash, Gerald R \(Jerry\), ALABS" To: "Adrian Farrel" , "Huub van Helvoort" , "Marco Ruffini" Cc: "Ash, Gerald R \(Jerry\), ALABS" , Furthermore RFC 4054 http://www.ietf.org/rfc/rfc4054.txt deals with some of these issues. -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Monday, April 10, 2006 10:08 AM To: Huub van Helvoort; Marco Ruffini Cc: ccamp@ops.ietf.org Subject: Re: GMPLS dynamics vs. issues with optical amplifiers Hi Marco, I think that Huub may over-simplify the question with his response. The issues of cross-talk, amplification, etc. do impact on the selection of lambdas to carry services of different lengths through the network, and can become extremely important where transparent optical devices (for example, PXCs) are used. Suitable planning tools are available to make such decisions in real time, but provisioning may be slower than "instant" because of the need to tune power levels etc. We should note that in lambda networks we are probably talking about building transport connections. In general, such connections do not need to be provisioned instantly and have relatively high latency. So a lot depends on what you mean by "fast allocating." With respect to what the IETF would or would not work on, we should observe the following: - The IETF does not generally do algorithms So the mechanism of computing suitable paths and choosing lambdas is out of scope. You would need to contact a specialist computation / NMS company for this sort of thing. - There is (as far as I can see) no immediate impact on signaling. Once a path and a lambda have been selected, we already have the tools to establish the connections. - There *might* be a future requirement to signal certain constraints, but we would need to see the requirements clearly stated. - There is probably a need to enhance the advertisement of some key physical attributes of optical links and nodes in the IGPs. At the moment, however, this information appears to be gathered through inventory systems and there has been very little consideration of this requirement. - As Huub says, the IETF does not work on defining physical properties of optical links, nor on specifying the interactions between such properties. Regards, Adrian ----- Original Message -----=20 From: "Huub van Helvoort" To: "Marco Ruffini" Cc: Sent: Monday, April 10, 2006 9:07 AM Subject: Re: GMPLS dynamics vs. issues with optical amplifiers > Hello Marco, > > You wrote: > > > I'm a PhD student on optical network and I'm following the > > development of the GMPLS work. > > > > I had a recent discussion with people working on the optical > > transport network who where telling me their concern about creating > > dynamical path over trails including optical amplifiers. > > > > They say that cross-talk and gain fluctuation effects may limit the > > capability of fast allocating new wavelengths over those trials. > > Cross-talk and gain are physical properties and not related > to bandwidth management like GMPLS. > > IMO the concern is unjustified. > > > I just wanted to know what is your opinion about this and if is there > > some working group within the IETF already trying to challenge this > > problem. > > IMO for the physical properties you should turn to the ITU-T. > > Cheers, Huub. > > --=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > http://members.chello.nl/hhelvoort/ > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Always remember that you are unique...just like everyone else... > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Apr 2006 14:09:41 +0000 Message-ID: <07b301c65ca8$2c46b3d0$bf849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: "Huub van Helvoort" , "Marco Ruffini" Cc: Subject: Re: GMPLS dynamics vs. issues with optical amplifiers Date: Mon, 10 Apr 2006 15:07:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 8bit Hi Marco, I think that Huub may over-simplify the question with his response. The issues of cross-talk, amplification, etc. do impact on the selection of lambdas to carry services of different lengths through the network, and can become extremely important where transparent optical devices (for example, PXCs) are used. Suitable planning tools are available to make such decisions in real time, but provisioning may be slower than "instant" because of the need to tune power levels etc. We should note that in lambda networks we are probably talking about building transport connections. In general, such connections do not need to be provisioned instantly and have relatively high latency. So a lot depends on what you mean by "fast allocating." With respect to what the IETF would or would not work on, we should observe the following: - The IETF does not generally do algorithms So the mechanism of computing suitable paths and choosing lambdas is out of scope. You would need to contact a specialist computation / NMS company for this sort of thing. - There is (as far as I can see) no immediate impact on signaling. Once a path and a lambda have been selected, we already have the tools to establish the connections. - There *might* be a future requirement to signal certain constraints, but we would need to see the requirements clearly stated. - There is probably a need to enhance the advertisement of some key physical attributes of optical links and nodes in the IGPs. At the moment, however, this information appears to be gathered through inventory systems and there has been very little consideration of this requirement. - As Huub says, the IETF does not work on defining physical properties of optical links, nor on specifying the interactions between such properties. Regards, Adrian ----- Original Message ----- From: "Huub van Helvoort" To: "Marco Ruffini" Cc: Sent: Monday, April 10, 2006 9:07 AM Subject: Re: GMPLS dynamics vs. issues with optical amplifiers > Hello Marco, > > You wrote: > > > I’m a PhD student on optical network and I’m following the > > development of the GMPLS work. > > > > I had a recent discussion with people working on the optical > > transport network who where telling me their concern about creating > > dynamical path over trails including optical amplifiers. > > > > They say that cross-talk and gain fluctuation effects may limit the > > capability of fast allocating new wavelengths over those trials. > > Cross-talk and gain are physical properties and not related > to bandwidth management like GMPLS. > > IMO the concern is unjustified. > > > I just wanted to know what is your opinion about this and if is there > > some working group within the IETF already trying to challenge this > > problem. > > IMO for the physical properties you should turn to the ITU-T. > > Cheers, Huub. > > -- > ================================================================ > http://members.chello.nl/hhelvoort/ > ================================================================ > Always remember that you are unique...just like everyone else... > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Apr 2006 08:08:14 +0000 Message-ID: <443A1252.5040903@chello.nl> Date: Mon, 10 Apr 2006 10:07:46 +0200 From: Huub van Helvoort User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Marco Ruffini CC: ccamp@ops.ietf.org Subject: Re: GMPLS dynamics vs. issues with optical amplifiers Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Hello Marco, You wrote: > I’m a PhD student on optical network and I’m following the > development of the GMPLS work. > > I had a recent discussion with people working on the optical > transport network who where telling me their concern about creating > dynamical path over trails including optical amplifiers. > > They say that cross-talk and gain fluctuation effects may limit the > capability of fast allocating new wavelengths over those trials. Cross-talk and gain are physical properties and not related to bandwidth management like GMPLS. IMO the concern is unjustified. > I just wanted to know what is your opinion about this and if is there > some working group within the IETF already trying to challenge this > problem. IMO for the physical properties you should turn to the ITU-T. Cheers, Huub. -- ================================================================ http://members.chello.nl/hhelvoort/ ================================================================ Always remember that you are unique...just like everyone else... Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 10 Apr 2006 07:46:19 +0000 From: "Marco Ruffini" To: Subject: GMPLS dynamics vs. issues with optical amplifiers Date: Mon, 10 Apr 2006 08:43:45 +0100 Message-ID: <000801c65c72$81d7f9c0$1737e286@PC> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01C65C7A.E39C61C0" This is a multi-part message in MIME format. ------=_NextPart_000_0009_01C65C7A.E39C61C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi all, I'm a PhD student on optical network and I'm following the development of the GMPLS work. I had a recent discussion with people working on the optical transport network who where telling me their concern about creating dynamical path over trails including optical amplifiers. They say that cross-talk and gain fluctuation effects may limit the capability of fast allocating new wavelengths over those trials. I just wanted to know what is your opinion about this and if is there some working group within the IETF already trying to challenge this problem. Thank you for your attention Best Regards, Marco Ruffini. CTVR, University of Dublin, Trinity College, Dublin 2, Ireland. Phone: +353-1-608 8441 ------=_NextPart_000_0009_01C65C7A.E39C61C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

I’m a PhD student on optical network and = I’m following the development of the GMPLS work.

I had a recent discussion with people working = on the optical transport network who where telling me their concern about = creating dynamical path over trails including optical = amplifiers.

They say that cross-talk and gain fluctuation = effects may limit the capability of fast allocating new wavelengths over those = trials.

 

I just wanted to know what is your opinion = about this and if is there some working group within the IETF already trying to = challenge this problem.

 

Thank you for your attention

 

Best Regards,

Marco Ruffini.

 

CTVR,

University of = Dublin, Trinity = College,

Dublin = 2,

Ireland.

Phone: +353-1-608 8441

 

------=_NextPart_000_0009_01C65C7A.E39C61C0-- Envelope-to: ccamp-data@psg.com Delivery-date: Fri, 07 Apr 2006 15:21:49 +0000 Message-ID: <04c701c65a56$c73e8b50$bf849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Calling implementors: ERO implementation survey Date: Fri, 7 Apr 2006 16:17:49 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, I have had some responses to this request. In case the information so far is unrepresentative, I'd really appreciate it if you could take 5 minutes to send me a private response. Thanks. Adrian ----- Original Message ----- From: "Adrian Farrel" To: Sent: Tuesday, March 28, 2006 8:12 PM Subject: ERO implementation survey > In Dallas, during discussion of draft-ietf-ccamp-gmpls-addressing-03, we > determined that implementations must support any form of ERO that is > legitimately sent by any other implementation. At the same time there is a > desire to reduce the number of options if this is possible. Lastly, there > was some confusion about what the RFCs actually allow you to do, and > rather than debate this as though we were lawyers, it may be more > profitable to look at what current implementations do. > > Obviously we can do further work on this if/when RFCs 3209, 3471 and 3473 > go to Draft Standard. > > To move things forward, I would like to do an informal and *confidential* > survey of current implementations. > > Please respond to each question below with, Yes / No / NA > NA would largely apply where the implementation is found on a NE where the > technology makes the ERO option inappropriate. > > Send your responses to me and not to the mailing lists (unless you fancy > the publicity). > > Thanks, > Adrian > > 1. EROs built for use on Path messages > For each hop in the path, which of the following options does your > implementation utilise? > This question applies to EROs that your implementations construct, NOT to > EROs that you forward. > > a. IP Address with non-full prefix length specifying a group of nodes > > b. AS number > > c. TE Router ID > > d. Incoming TE link ID > > e. Outgoing TE link ID > > f. Outgoing TE link ID followed by one or two Label subobjects > > g. Outgoing TE link ID followed by Component Interface ID subobject > > h. Outgoing TE link ID followed by Component Interface ID subobject > and one or two Label subobjects > > i. TE Router ID and Outgoing TE link ID > > j. TE Router ID and Outgoing TE link ID followed by one or two > Label subobjects > > k. TE Router ID and Outgoing TE link ID followed by Component > Interface ID subobject > > l. TE Router ID and Outgoing TE link ID followed by Component > Interface ID subobject and one or two Label subobjects > > m. Incoming TE link ID and Outgoing TE link ID > > n. Incoming TE link ID and Outgoing TE link ID followed by one or two > Label subobjects > > o. Incoming TE link ID and Outgoing TE link ID followed by Component > Interface ID subobject > > p. Incoming TE link ID and Outgoing TE link ID followed by Component > Interface ID subobject and one or two Label subobjects > > q. Incoming TE link ID, TE Router ID, and Outgoing TE link ID > > r. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by one or two Label subobjects > > s. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by Component Interface ID subobject > > t. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by Component Interface ID subobject and one or two Label subobjects > > 2. EROs received from the previous hop on Path messages > Which *top* subobjects in the ERO does your implementation support > receiving? > This question applies to ERO subobjects that your implementations must > handle, NOT to ERO subobjects that you forward. > > a. IP Address with non-full prefix length specifying a group of nodes > > b. AS number > > c. TE Router ID > > d. Incoming TE link ID > > e. Outgoing TE link ID > > f. Outgoing TE link ID followed by one or two Label subobjects > > g. Outgoing TE link ID followed by Component Interface ID subobject > > h. Outgoing TE link ID followed by Component Interface ID subobject > and one or two Label subobjects > > i. TE Router ID and Outgoing TE link ID > > j. TE Router ID and Outgoing TE link ID followed by one or two > Label subobjects > > k. TE Router ID and Outgoing TE link ID followed by Component > Interface ID subobject > > l. TE Router ID and Outgoing TE link ID followed by Component > Interface ID subobject and one or two Label subobjects > > m. Incoming TE link ID and Outgoing TE link ID > > n. Incoming TE link ID and Outgoing TE link ID followed by one or two > Label subobjects > > o. Incoming TE link ID and Outgoing TE link ID followed by Component > Interface ID subobject > > p. Incoming TE link ID and Outgoing TE link ID followed by Component > Interface ID subobject and one or two Label subobjects > > q. Incoming TE link ID, TE Router ID, and Outgoing TE link ID > > r. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by one or two Label subobjects > > s. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by Component Interface ID subobject > > t. Incoming TE link ID, TE Router ID, and Outgoing TE link ID followed > by Component Interface ID subobject and one or two Label subobjects > > > > Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Apr 2006 13:02:39 +0000 Date: Thu, 06 Apr 2006 22:02:27 +0900 From: "Yuichi Ikejiri" Subject: Re: Progressing docs To: "Kireeti Kompella" Cc: ccamp@ops.ietf.org Message-id: <20060406200558.58D0.Y.IKEJIRI@ntt.com> MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit Hi, Yes to all to facilitate further discussion of each draft. Thanks, Yuichi On Fri, 31 Mar 2006 10:12:31 -0800 (PST) "Kireeti Kompella" wrote: > Hi All, > > This is to double-check support *on the list* for the following I-Ds > to go to WG docs: > > a) MPLS-GMPLS interworking > draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt > b) "hierarchy bis" > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > c) Call Support > draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt > d) Ethernet TSpec > draft-dimitri-mef-ethernet-traffic-parameters-00.txt > e) OSPF-TE MIB > draft-otani-ccamp-gmpls-ospf-mib-02.txt > > Please say for each if you think it should/should not become a WG doc. > > My previous email was in error: the "excellent" support was for the > migration doc. Just to be clear, we'll double-check all these docs. > > Kireeti. > ------- Envelope-to: ccamp-data@psg.com Delivery-date: Thu, 06 Apr 2006 12:53:47 +0000 Mime-Version: 1.0 (Apple Message framework v746.3) Content-Type: multipart/alternative; boundary=Apple-Mail-121-664462459 Message-Id: Cc: , From: JP Vasseur Subject: Re: [Pce] Comparison of Encryption vs. Path Key Solutions for the CPS ID. Date: Thu, 6 Apr 2006 08:51:43 -0400 To: Rich Bradford ((rbradfor)) --Apple-Mail-121-664462459 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Hi, Thanks for the summary Rich. PCE WG members: thanks to provide your feedback on whether: (1) You think that there is a need for such solution, (2) You would prefer one solution (which one and why ?) (3) You think that there is a need for both Thanks. JP. On Apr 5, 2006, at 6:19 PM, Rich Bradford ((rbradfor)) wrote: > Hi, > > As suggested in Dallas, I=92ve described some of the tradeoffs =20 > between the two solutions described in draft-rbradfor-ccamp-=20 > confidential-segment-00.txt. > > -- Rich > > > > The Confidential Path Segment (CPS) ID provides two very different =20 > but equally valid solutions, the Path Key Subobject (PKS) solution =20 > and the Private Route Subobject (PRS) solution. This note examines =20 > a number of the advantages and disadvantages of each solution. > > > > In short: The PKS solution allows a PCE to hide the CPS for an AS =20 > by saving it in a database and replacing it with a key in the ERO. =20 > During the LSP setup, the ingress LSR for that AS must query the =20 > PCE for an expansion. > > The PRS solution allows a CPS for an AS to be hidden by encrypting =20 > it, which may be done by a PCE or by the Head-End LSR. During the =20 > LSP setup, the ingress LSR for that AS must use a decryption key to =20= > obtain the expansion (implying an earlier exchange or configuration). > > > > The major differences between the mechanisms involve (1) additional =20= > control messages, (2) performance issues expanding those objects, =20 > (3) the addition of state to the PCE, (4) the solution scope (i.e. =20 > applicability to various topologies of each solution.), and (5) the =20= > size of objects added to existing messages. > > > > (1) Additional Control Message Overhead: > > The PKS solution requires a mechanism to expand the Path Key upon =20 > receipt of the LSP setup request. Since the PCE which calculated =20 > the Path Key might not reside in the entry boundary LSR, the LSR =20 > must request the expansion from the PCE, requiring an additional =20 > message exchange before LSP setup can proceed. The Path Encryption =20 > solution does not require this extra exchange between the PCE and =20 > the ingress node for every LSP. Rather, the decryption key needs to =20= > be exchanged only when it is changed. The result is additional =20 > delay during every LSP setup for the PKS solution but no additional =20= > delay for the PRS solution. > > > > > > (2) PCE and LSR Performance: > > The PKS solution must maintain a (temporary) database of keys =20 > adding overhead to the PCE. The PRS solution requires the =20 > encryption of the CPS in the PCE and decryption of the CPS in the =20 > LSR, which could be CPU intensive. Note that in case of a burst of =20 > requests, encryption of large number of CPS may have an impact on =20 > the PCE response time. > > > > (3) Addition of State in the PCE: > > The PKS solution requires the addition of path-specific state and =20 > maintenance of a database in the PCE. The PRS solution requires no =20 > additional state. > > > > > > (4) Solution Scope: > > The PKS and PRS solutions both work well in conjunction with a PCE =20 > to encode and decode the CPS. However the PKS provides no direct =20 > solution without a PCE. This prevents the PKS solution for working =20 > in the case where A's network straddles B's network and where A =20 > wants to use an ERO for a segment of the LSP across the intervening =20= > network, e.g. (netA)-(netB)-(netA). In addition, the PRS could be =20 > used to record a CPS even if the path (and therefore the returned =20 > RRO) crosses multiple boundaries. Finally, a PRS solution could be =20 > adapted to return actual failure locations in PERRs and/or =20 > PATHTEARs, while keeping the failure location confidential from =20 > LSRs without a decryption key. Currently privacy of this source is =20 > maintained by returning the address of border nodes, which can be =20 > very misleading. > > > > (5) Message Object Overhead: > > The PKS solution provides a very compact key or token to identify a =20= > path segment, which generally allows for smaller EROs to be =20 > returned by the PCE and to be requested in the resulting PATH =20 > message. A PRS which contains a CPS must generally be at least as =20 > large as the unencrypted PATH through the AS and may be =20 > significantly larger if it is desirable to hide the number of hops =20 > within the network from external view by padding the PRS. The =20 > result is potentially larger PATH (and PCEP) messages for the PRS =20 > solution. > > > > > > Please note that the tradeoffs listed here are for the current I-D. =20= > Some of the shortcomings of each approach could be mitigated by =20 > implementation-specific optimizations. For example, a PCE could =20 > choose to signal the CPS expansion to the entry boundary LSR, =20 > shifting the burden of maintaining the PKS state to the LSR and =20 > eliminating the performance hit during LSP setup. A similar =20 > exchange could be performed for the PRS case, eliminating the need =20 > for a separate key exchange. These examples of extensions are =20 > beyond the scope of the ID, but might be useful when weighing the =20 > pros and cons of the two solutions. > > > > > > _______________________________________________ > Pce mailing list > Pce@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/pce --Apple-Mail-121-664462459 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=WINDOWS-1252 Hi,

Thanks for the summary = Rich.

PCE WG = members: thanks to provide your feedback on whether:
(1) You = think that there is a need for such solution,
(2) You = would prefer one solution (which one and why ?)
(3) You = think that there is a need for both

Thanks.

JP.

On Apr 5, 2006, = at 6:19 PM, Rich Bradford ((rbradfor)) wrote:

=

Hi,

As = suggested in Dallas, I=92ve described some of the = tradeoffs between the two solutions described in = draft-rbradfor-ccamp-confidential-segment-00.txt.=

-- = Rich

=A0

The Confidential Path Segment (CPS) ID provides two very = different but equally valid solutions, the Path Key Subobject (PKS) = solution and the Private Route Subobject (PRS) solution. This note = examines a number of the advantages and disadvantages of each solution. =

=A0

In = short: The PKS solution allows a PCE to hide the CPS for an AS by saving = it in a database and replacing it with a key in the ERO. During the LSP = setup, the ingress LSR for that AS must query the PCE for an = expansion.

The PRS solution allows a CPS for an AS to be hidden by = encrypting it, which may be done by a PCE or by the Head-End LSR. During = the LSP setup, the ingress LSR for that AS must use a decryption key to = obtain the expansion (implying an earlier exchange or configuration). =

=A0

The major differences between the mechanisms involve (1) = additional control messages, (2) performance issues expanding those = objects, (3) the addition of state to the PCE, (4) the solution scope = (i.e. applicability to various topologies of each solution.), and (5) = the size of objects added to existing = messages.

=A0

(1) Additional Control Message = Overhead:

The PKS solution requires a mechanism to expand the Path Key = upon receipt of the LSP setup request. Since the PCE which calculated = the Path Key might not reside in the entry boundary LSR, the LSR must = request the expansion from the PCE, requiring an additional message = exchange before LSP setup can proceed. The Path Encryption solution does = not require this extra exchange between the PCE and the ingress node for = every LSP. Rather, the decryption key needs to be exchanged only when it = is changed. The result is additional delay during every LSP setup for = the PKS solution but no additional delay for the PRS = solution.

=A0

=A0

(2) PCE and LSR Performance:

The PKS solution must maintain a (temporary) = database of keys adding overhead to the PCE. The PRS solution requires = the encryption of the CPS in the PCE and decryption of the CPS in the = LSR, which could be CPU intensive. Note that in case of a burst of = requests, encryption of large number of CPS may have an impact on the = PCE response time.

=A0

(3) Addition of State in the = PCE:

The PKS = solution requires the addition of path-specific state and maintenance of = a database in the PCE. The PRS solution requires no additional = state.

=A0

=A0

(4) Solution Scope:

The PKS and PRS solutions both work well in = conjunction with a PCE to encode and decode the CPS. However the PKS = provides no direct solution without a PCE. This prevents the PKS = solution for working in the case where A's network straddles B's network = and where A wants to use an ERO for a segment of the LSP across the = intervening network, e.g. (netA)-(netB)-(netA). In addition, the PRS = could be used to record a CPS even if the path (and therefore the = returned RRO) crosses multiple boundaries. Finally, a PRS solution could = be adapted to return actual failure locations in PERRs and/or PATHTEARs, = while keeping the failure location confidential from LSRs without a = decryption key. Currently privacy of this source is maintained by = returning the address of border nodes, which can be very = misleading.

=A0

(5) Message Object Overhead:

The PKS solution provides a very compact key = or token to identify a path segment, which generally allows for smaller = EROs to be returned by the PCE and to be requested in the resulting PATH = message. A PRS which contains a CPS must generally be at least as large = as the unencrypted PATH through the AS and may be significantly larger = if it is desirable to hide the number of hops within the network from = external view by padding the PRS. The result is potentially larger PATH = (and PCEP) messages for the PRS solution.

=A0

=A0

Please note that the tradeoffs listed here = are for the current I-D. Some of the shortcomings of each approach could = be mitigated by implementation-specific optimizations. For example, a = PCE could choose to signal the CPS expansion to the entry boundary LSR, = shifting the burden of maintaining the PKS state to the LSR and = eliminating the performance hit during LSP setup. A similar exchange = could be performed for the PRS case, eliminating the need for a separate = key exchange. These examples of extensions are beyond the scope of the = ID, but might be useful when weighing the pros and cons of the two = solutions.

=A0

=A0

=
Pce mailing list
=

= --Apple-Mail-121-664462459-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Apr 2006 22:21:03 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C658FF.1571E0A3" Subject: Comparison of Encryption vs. Path Key Solutions for the CPS ID. Date: Wed, 5 Apr 2006 18:19:54 -0400 Message-ID: <3C292CE901FC634693F24FB2DDC4D332014EF5CB@xmb-rtp-20d.amer.cisco.com> Thread-Topic: Comparison of Encryption vs. Path Key Solutions for the CPS ID. Thread-Index: AcZYoa17yPX/wRg0S0Wcwz2H4PidHgAXKKKQ From: "Rich Bradford \(rbradfor\)" To: , This is a multi-part message in MIME format. ------_=_NextPart_001_01C658FF.1571E0A3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGksDQoNCkFzIHN1Z2dlc3RlZCBpbiBEYWxsYXMsIEnigJl2ZSBkZXNjcmliZWQgc29tZSBvZiB0 aGUgdHJhZGVvZmZzIGJldHdlZW4gdGhlIHR3byBzb2x1dGlvbnMgZGVzY3JpYmVkIGluIGRyYWZ0 LXJicmFkZm9yLWNjYW1wLWNvbmZpZGVudGlhbC1zZWdtZW50LTAwLnR4dC4NCg0KLS0gUmljaA0K DQogDQoNClRoZSBDb25maWRlbnRpYWwgUGF0aCBTZWdtZW50IChDUFMpIElEIHByb3ZpZGVzIHR3 byB2ZXJ5IGRpZmZlcmVudCBidXQgZXF1YWxseSB2YWxpZCBzb2x1dGlvbnMsIHRoZSBQYXRoIEtl eSBTdWJvYmplY3QgKFBLUykgc29sdXRpb24gYW5kIHRoZSBQcml2YXRlIFJvdXRlIFN1Ym9iamVj dCAoUFJTKSBzb2x1dGlvbi4gVGhpcyBub3RlIGV4YW1pbmVzIGEgbnVtYmVyIG9mIHRoZSBhZHZh bnRhZ2VzIGFuZCBkaXNhZHZhbnRhZ2VzIG9mIGVhY2ggc29sdXRpb24uIA0KDQogDQoNCkluIHNo b3J0OiBUaGUgUEtTIHNvbHV0aW9uIGFsbG93cyBhIFBDRSB0byBoaWRlIHRoZSBDUFMgZm9yIGFu IEFTIGJ5IHNhdmluZyBpdCBpbiBhIGRhdGFiYXNlIGFuZCByZXBsYWNpbmcgaXQgd2l0aCBhIGtl eSBpbiB0aGUgRVJPLiBEdXJpbmcgdGhlIExTUCBzZXR1cCwgdGhlIGluZ3Jlc3MgTFNSIGZvciB0 aGF0IEFTIG11c3QgcXVlcnkgdGhlIFBDRSBmb3IgYW4gZXhwYW5zaW9uLg0KDQpUaGUgUFJTIHNv bHV0aW9uIGFsbG93cyBhIENQUyBmb3IgYW4gQVMgdG8gYmUgaGlkZGVuIGJ5IGVuY3J5cHRpbmcg aXQsIHdoaWNoIG1heSBiZSBkb25lIGJ5IGEgUENFIG9yIGJ5IHRoZSBIZWFkLUVuZCBMU1IuIER1 cmluZyB0aGUgTFNQIHNldHVwLCB0aGUgaW5ncmVzcyBMU1IgZm9yIHRoYXQgQVMgbXVzdCB1c2Ug YSBkZWNyeXB0aW9uIGtleSB0byBvYnRhaW4gdGhlIGV4cGFuc2lvbiAoaW1wbHlpbmcgYW4gZWFy bGllciBleGNoYW5nZSBvciBjb25maWd1cmF0aW9uKS4gDQoNCiANCg0KVGhlIG1ham9yIGRpZmZl cmVuY2VzIGJldHdlZW4gdGhlIG1lY2hhbmlzbXMgaW52b2x2ZSAoMSkgYWRkaXRpb25hbCBjb250 cm9sIG1lc3NhZ2VzLCAoMikgcGVyZm9ybWFuY2UgaXNzdWVzIGV4cGFuZGluZyB0aG9zZSBvYmpl Y3RzLCAoMykgdGhlIGFkZGl0aW9uIG9mIHN0YXRlIHRvIHRoZSBQQ0UsICg0KSB0aGUgc29sdXRp b24gc2NvcGUgKGkuZS4gYXBwbGljYWJpbGl0eSB0byB2YXJpb3VzIHRvcG9sb2dpZXMgb2YgZWFj aCBzb2x1dGlvbi4pLCBhbmQgKDUpIHRoZSBzaXplIG9mIG9iamVjdHMgYWRkZWQgdG8gZXhpc3Rp bmcgbWVzc2FnZXMuDQoNCiANCg0KKDEpIEFkZGl0aW9uYWwgQ29udHJvbCBNZXNzYWdlIE92ZXJo ZWFkOg0KDQpUaGUgUEtTIHNvbHV0aW9uIHJlcXVpcmVzIGEgbWVjaGFuaXNtIHRvIGV4cGFuZCB0 aGUgUGF0aCBLZXkgdXBvbiByZWNlaXB0IG9mIHRoZSBMU1Agc2V0dXAgcmVxdWVzdC4gU2luY2Ug dGhlIFBDRSB3aGljaCBjYWxjdWxhdGVkIHRoZSBQYXRoIEtleSBtaWdodCBub3QgcmVzaWRlIGlu IHRoZSBlbnRyeSBib3VuZGFyeSBMU1IsIHRoZSBMU1IgbXVzdCByZXF1ZXN0IHRoZSBleHBhbnNp b24gZnJvbSB0aGUgUENFLCByZXF1aXJpbmcgYW4gYWRkaXRpb25hbCBtZXNzYWdlIGV4Y2hhbmdl IGJlZm9yZSBMU1Agc2V0dXAgY2FuIHByb2NlZWQuIFRoZSBQYXRoIEVuY3J5cHRpb24gc29sdXRp b24gZG9lcyBub3QgcmVxdWlyZSB0aGlzIGV4dHJhIGV4Y2hhbmdlIGJldHdlZW4gdGhlIFBDRSBh bmQgdGhlIGluZ3Jlc3Mgbm9kZSBmb3IgZXZlcnkgTFNQLiBSYXRoZXIsIHRoZSBkZWNyeXB0aW9u IGtleSBuZWVkcyB0byBiZSBleGNoYW5nZWQgb25seSB3aGVuIGl0IGlzIGNoYW5nZWQuIFRoZSBy ZXN1bHQgaXMgYWRkaXRpb25hbCBkZWxheSBkdXJpbmcgZXZlcnkgTFNQIHNldHVwIGZvciB0aGUg UEtTIHNvbHV0aW9uIGJ1dCBubyBhZGRpdGlvbmFsIGRlbGF5IGZvciB0aGUgUFJTIHNvbHV0aW9u Lg0KDQogDQoNCiANCg0KKDIpIFBDRSBhbmQgTFNSIFBlcmZvcm1hbmNlOg0KDQpUaGUgUEtTIHNv bHV0aW9uIG11c3QgbWFpbnRhaW4gYSAodGVtcG9yYXJ5KSBkYXRhYmFzZSBvZiBrZXlzIGFkZGlu ZyBvdmVyaGVhZCB0byB0aGUgUENFLiBUaGUgUFJTIHNvbHV0aW9uIHJlcXVpcmVzIHRoZSBlbmNy eXB0aW9uIG9mIHRoZSBDUFMgaW4gdGhlIFBDRSBhbmQgZGVjcnlwdGlvbiBvZiB0aGUgQ1BTIGlu IHRoZSBMU1IsIHdoaWNoIGNvdWxkIGJlIENQVSBpbnRlbnNpdmUuIE5vdGUgdGhhdCBpbiBjYXNl IG9mIGEgYnVyc3Qgb2YgcmVxdWVzdHMsIGVuY3J5cHRpb24gb2YgbGFyZ2UgbnVtYmVyIG9mIENQ UyBtYXkgaGF2ZSBhbiBpbXBhY3Qgb24gdGhlIFBDRSByZXNwb25zZSB0aW1lLg0KDQogDQoNCigz KSBBZGRpdGlvbiBvZiBTdGF0ZSBpbiB0aGUgUENFOg0KDQpUaGUgUEtTIHNvbHV0aW9uIHJlcXVp cmVzIHRoZSBhZGRpdGlvbiBvZiBwYXRoLXNwZWNpZmljIHN0YXRlIGFuZCBtYWludGVuYW5jZSBv ZiBhIGRhdGFiYXNlIGluIHRoZSBQQ0UuIFRoZSBQUlMgc29sdXRpb24gcmVxdWlyZXMgbm8gYWRk aXRpb25hbCBzdGF0ZS4NCg0KIA0KDQogDQoNCig0KSBTb2x1dGlvbiBTY29wZToNCg0KVGhlIFBL UyBhbmQgUFJTIHNvbHV0aW9ucyBib3RoIHdvcmsgd2VsbCBpbiBjb25qdW5jdGlvbiB3aXRoIGEg UENFIHRvIGVuY29kZSBhbmQgZGVjb2RlIHRoZSBDUFMuIEhvd2V2ZXIgdGhlIFBLUyBwcm92aWRl cyBubyBkaXJlY3Qgc29sdXRpb24gd2l0aG91dCBhIFBDRS4gVGhpcyBwcmV2ZW50cyB0aGUgUEtT IHNvbHV0aW9uIGZvciB3b3JraW5nIGluIHRoZSBjYXNlIHdoZXJlIEEncyBuZXR3b3JrIHN0cmFk ZGxlcyBCJ3MgbmV0d29yayBhbmQgd2hlcmUgQSB3YW50cyB0byB1c2UgYW4gRVJPIGZvciBhIHNl Z21lbnQgb2YgdGhlIExTUCBhY3Jvc3MgdGhlIGludGVydmVuaW5nIG5ldHdvcmssIGUuZy4gKG5l dEEpLShuZXRCKS0obmV0QSkuIEluIGFkZGl0aW9uLCB0aGUgUFJTIGNvdWxkIGJlIHVzZWQgdG8g cmVjb3JkIGEgQ1BTIGV2ZW4gaWYgdGhlIHBhdGggKGFuZCB0aGVyZWZvcmUgdGhlIHJldHVybmVk IFJSTykgY3Jvc3NlcyBtdWx0aXBsZSBib3VuZGFyaWVzLiBGaW5hbGx5LCBhIFBSUyBzb2x1dGlv biBjb3VsZCBiZSBhZGFwdGVkIHRvIHJldHVybiBhY3R1YWwgZmFpbHVyZSBsb2NhdGlvbnMgaW4g UEVSUnMgYW5kL29yIFBBVEhURUFScywgd2hpbGUga2VlcGluZyB0aGUgZmFpbHVyZSBsb2NhdGlv biBjb25maWRlbnRpYWwgZnJvbSBMU1JzIHdpdGhvdXQgYSBkZWNyeXB0aW9uIGtleS4gQ3VycmVu dGx5IHByaXZhY3kgb2YgdGhpcyBzb3VyY2UgaXMgbWFpbnRhaW5lZCBieSByZXR1cm5pbmcgdGhl IGFkZHJlc3Mgb2YgYm9yZGVyIG5vZGVzLCB3aGljaCBjYW4gYmUgdmVyeSBtaXNsZWFkaW5nLg0K DQogDQoNCig1KSBNZXNzYWdlIE9iamVjdCBPdmVyaGVhZDoNCg0KVGhlIFBLUyBzb2x1dGlvbiBw cm92aWRlcyBhIHZlcnkgY29tcGFjdCBrZXkgb3IgdG9rZW4gdG8gaWRlbnRpZnkgYSBwYXRoIHNl Z21lbnQsIHdoaWNoIGdlbmVyYWxseSBhbGxvd3MgZm9yIHNtYWxsZXIgRVJPcyB0byBiZSByZXR1 cm5lZCBieSB0aGUgUENFIGFuZCB0byBiZSByZXF1ZXN0ZWQgaW4gdGhlIHJlc3VsdGluZyBQQVRI IG1lc3NhZ2UuIEEgUFJTIHdoaWNoIGNvbnRhaW5zIGEgQ1BTIG11c3QgZ2VuZXJhbGx5IGJlIGF0 IGxlYXN0IGFzIGxhcmdlIGFzIHRoZSB1bmVuY3J5cHRlZCBQQVRIIHRocm91Z2ggdGhlIEFTIGFu ZCBtYXkgYmUgc2lnbmlmaWNhbnRseSBsYXJnZXIgaWYgaXQgaXMgZGVzaXJhYmxlIHRvIGhpZGUg dGhlIG51bWJlciBvZiBob3BzIHdpdGhpbiB0aGUgbmV0d29yayBmcm9tIGV4dGVybmFsIHZpZXcg YnkgcGFkZGluZyB0aGUgUFJTLiBUaGUgcmVzdWx0IGlzIHBvdGVudGlhbGx5IGxhcmdlciBQQVRI IChhbmQgUENFUCkgbWVzc2FnZXMgZm9yIHRoZSBQUlMgc29sdXRpb24uDQoNCiANCg0KIA0KDQpQ bGVhc2Ugbm90ZSB0aGF0IHRoZSB0cmFkZW9mZnMgbGlzdGVkIGhlcmUgYXJlIGZvciB0aGUgY3Vy cmVudCBJLUQuIFNvbWUgb2YgdGhlIHNob3J0Y29taW5ncyBvZiBlYWNoIGFwcHJvYWNoIGNvdWxk IGJlIG1pdGlnYXRlZCBieSBpbXBsZW1lbnRhdGlvbi1zcGVjaWZpYyBvcHRpbWl6YXRpb25zLiBG b3IgZXhhbXBsZSwgYSBQQ0UgY291bGQgY2hvb3NlIHRvIHNpZ25hbCB0aGUgQ1BTIGV4cGFuc2lv biB0byB0aGUgZW50cnkgYm91bmRhcnkgTFNSLCBzaGlmdGluZyB0aGUgYnVyZGVuIG9mIG1haW50 YWluaW5nIHRoZSBQS1Mgc3RhdGUgdG8gdGhlIExTUiBhbmQgZWxpbWluYXRpbmcgdGhlIHBlcmZv cm1hbmNlIGhpdCBkdXJpbmcgTFNQIHNldHVwLiBBIHNpbWlsYXIgZXhjaGFuZ2UgY291bGQgYmUg cGVyZm9ybWVkIGZvciB0aGUgUFJTIGNhc2UsIGVsaW1pbmF0aW5nIHRoZSBuZWVkIGZvciBhIHNl cGFyYXRlIGtleSBleGNoYW5nZS4gVGhlc2UgZXhhbXBsZXMgb2YgZXh0ZW5zaW9ucyBhcmUgYmV5 b25kIHRoZSBzY29wZSBvZiB0aGUgSUQsIGJ1dCBtaWdodCBiZSB1c2VmdWwgd2hlbiB3ZWlnaGlu ZyB0aGUgcHJvcyBhbmQgY29ucyBvZiB0aGUgdHdvIHNvbHV0aW9ucy4NCg0KIA0KDQogDQoNCg== ------_=_NextPart_001_01C658FF.1571E0A3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9dXRmLTgiPg0KPGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZp Y2U6b2ZmaWNlIiB4bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3Jk IiB4bWxuczpzdDE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncyIg eG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KDQo8aGVhZD4NCg0KPG1l dGEgbmFtZT1HZW5lcmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTEgKGZpbHRlcmVkIG1l ZGl1bSkiPg0KPG86U21hcnRUYWdUeXBlIG5hbWVzcGFjZXVyaT0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIg0KIG5hbWU9IkNpdHkiLz4NCjxvOlNtYXJ0VGFnVHlw ZSBuYW1lc3BhY2V1cmk9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFn cyINCiBuYW1lPSJwbGFjZSIvPg0KPCEtLVtpZiAhbXNvXT4NCjxzdHlsZT4NCnN0MVw6KntiZWhh dmlvcjp1cmwoI2RlZmF1bHQjaWVvb3VpKSB9DQo8L3N0eWxlPg0KPCFbZW5kaWZdLS0+DQo8c3R5 bGU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6Ik1TIE1pbmNobyI7DQoJcGFub3NlLTE6MiAyIDYgOSA0IDIgNSA4IDMgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIE1pbmNobyI7DQoJcGFub3NlLTE6MCAwIDAgMCAw IDAgMCAwIDAgMDt9DQogLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGku TXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biI7fQ0KaDENCgl7bWFyZ2luLXRvcDoxMi4wcHQ7DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJn aW4tYm90dG9tOjMuMHB0Ow0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCXBhZ2UtYnJlYWstYWZ0ZXI6YXZvaWQ7DQoJbXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzE7DQoJ Zm9udC1zaXplOjE2LjBwdDsNCglmb250LWZhbWlseTpBcmlhbDt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe2NvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7Y29sb3I6cHVycGxlOw0KCXRl eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29QbGFpblRleHQsIGxpLk1zb1BsYWluVGV4 dCwgZGl2Lk1zb1BsYWluVGV4dA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5D aGFwdGVyLCBsaS5DaGFwdGVyLCBkaXYuQ2hhcHRlcg0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCgl0ZXh0LWFsaWduOmNlbnRlcjsNCglwYWdlLWJyZWFrLWJlZm9yZTph bHdheXM7DQoJZm9udC1zaXplOjE2LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0K CWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMjVpbiAxLjBpbiAxLjI1aW47fQ0KZGl2LlNlY3Rpb24xDQoJe3Bh Z2U6U2VjdGlvbjE7fQ0KIC8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCiBAbGlzdCBsMA0KCXttc28t bGlzdC1pZDo2ODg5NDE0NjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1w bGF0ZS1pZHM6MTQ4MzQ2NjggNTA2NDg4NjY0IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3 Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxl dmVsMQ0KCXttc28tbGV2ZWwtc3R5bGUtbGluazoiSGVhZGluZyAxIjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0 b206MGluO30NCi0tPg0KPC9zdHlsZT4NCg0KPC9oZWFkPg0KDQo8Ym9keSBsYW5nPUVOLVVTIGxp bms9Ymx1ZSB2bGluaz1wdXJwbGU+DQoNCjxkaXYgY2xhc3M9U2VjdGlvbjE+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHls ZT0nZm9udC1zaXplOg0KMTIuMHB0Jz5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+QXMgc3VnZ2VzdGVkIGluIDxzdDE6Q2l0 eSB3OnN0PSJvbiI+PHN0MTpwbGFjZSB3OnN0PSJvbiI+RGFsbGFzPC9zdDE6cGxhY2U+PC9zdDE6 Q2l0eT4sDQpJ4oCZdmUgZGVzY3JpYmVkIHNvbWUgb2YgdGhlIHRyYWRlb2ZmcyBiZXR3ZWVuIHRo ZSB0d28gc29sdXRpb25zIGRlc2NyaWJlZA0KaW4gZHJhZnQtcmJyYWRmb3ItY2NhbXAtY29uZmlk ZW50aWFsLXNlZ21lbnQtMDAudHh0LjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4tLSBSaWNoPG86cD48L286cD48L3NwYW4+PC9m b250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBO ZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMg ZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz5U aGUgQ29uZmlkZW50aWFsIFBhdGggU2VnbWVudCAoQ1BTKSBJRCBwcm92aWRlcyB0d28gdmVyeSBk aWZmZXJlbnQgYnV0DQplcXVhbGx5IHZhbGlkIHNvbHV0aW9ucywgdGhlIFBhdGggS2V5IFN1Ym9i amVjdCAoUEtTKSBzb2x1dGlvbiBhbmQgdGhlIFByaXZhdGUNClJvdXRlIFN1Ym9iamVjdCAoUFJT KSBzb2x1dGlvbi4gVGhpcyBub3RlIGV4YW1pbmVzIGEgbnVtYmVyIG9mIHRoZSBhZHZhbnRhZ2Vz DQphbmQgZGlzYWR2YW50YWdlcyBvZiBlYWNoIHNvbHV0aW9uLiA8bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVz IE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9 MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQn PkluIHNob3J0OiBUaGUgUEtTIHNvbHV0aW9uIGFsbG93cyBhIFBDRSB0byBoaWRlIHRoZSBDUFMg Zm9yIGFuIEFTIGJ5DQpzYXZpbmcgaXQgaW4gYSBkYXRhYmFzZSBhbmQgcmVwbGFjaW5nIGl0IHdp dGggYSBrZXkgaW4gdGhlIEVSTy4gRHVyaW5nIHRoZSBMU1ANCnNldHVwLCB0aGUgaW5ncmVzcyBM U1IgZm9yIHRoYXQgQVMgbXVzdCBxdWVyeSB0aGUgUENFIGZvciBhbiBleHBhbnNpb24uPG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9 MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQn PlRoZSBQUlMgc29sdXRpb24gYWxsb3dzIGEgQ1BTIGZvciBhbiBBUyB0byBiZSBoaWRkZW4gYnkg ZW5jcnlwdGluZyBpdCwNCndoaWNoIG1heSBiZSBkb25lIGJ5IGEgUENFIG9yIGJ5IHRoZSBIZWFk LUVuZCBMU1IuIER1cmluZyB0aGUgTFNQIHNldHVwLCB0aGUNCmluZ3Jlc3MgTFNSIGZvciB0aGF0 IEFTIG11c3QgdXNlIGEgZGVjcnlwdGlvbiBrZXkgdG8gb2J0YWluIHRoZSBleHBhbnNpb24NCihp bXBseWluZyBhbiBlYXJsaWVyIGV4Y2hhbmdlIG9yIGNvbmZpZ3VyYXRpb24pLiA8bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZh Y2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxm b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 DQoxMi4wcHQnPlRoZSBtYWpvciBkaWZmZXJlbmNlcyBiZXR3ZWVuIHRoZSBtZWNoYW5pc21zIGlu dm9sdmUgKDEpIGFkZGl0aW9uYWwNCmNvbnRyb2wgbWVzc2FnZXMsICgyKSBwZXJmb3JtYW5jZSBp c3N1ZXMgZXhwYW5kaW5nIHRob3NlIG9iamVjdHMsICgzKSB0aGUNCmFkZGl0aW9uIG9mIHN0YXRl IHRvIHRoZSBQQ0UsICg0KSB0aGUgc29sdXRpb24gc2NvcGUgKGkuZS4gYXBwbGljYWJpbGl0eSB0 bw0KdmFyaW91cyB0b3BvbG9naWVzIG9mIGVhY2ggc29sdXRpb24uKSwgYW5kICg1KSB0aGUgc2l6 ZSBvZiBvYmplY3RzIGFkZGVkIHRvDQpleGlzdGluZyBtZXNzYWdlcy48bzpwPjwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRp bWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNp emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4w cHQnPigxKSBBZGRpdGlvbmFsIENvbnRyb2wgTWVzc2FnZSBPdmVyaGVhZDo8bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9 IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+VGhlIFBL UyBzb2x1dGlvbiByZXF1aXJlcyBhIG1lY2hhbmlzbSB0byBleHBhbmQgdGhlIFBhdGggS2V5IHVw b24NCnJlY2VpcHQgb2YgdGhlIExTUCBzZXR1cCByZXF1ZXN0LiBTaW5jZSB0aGUgUENFIHdoaWNo IGNhbGN1bGF0ZWQgdGhlIFBhdGggS2V5DQptaWdodCBub3QgcmVzaWRlIGluIHRoZSBlbnRyeSBi b3VuZGFyeSBMU1IsIHRoZSBMU1IgbXVzdCByZXF1ZXN0IHRoZSBleHBhbnNpb24NCmZyb20gdGhl IFBDRSwgcmVxdWlyaW5nIGFuIGFkZGl0aW9uYWwgbWVzc2FnZSBleGNoYW5nZSBiZWZvcmUgTFNQ IHNldHVwIGNhbg0KcHJvY2VlZC4gVGhlIFBhdGggRW5jcnlwdGlvbiBzb2x1dGlvbiBkb2VzIG5v dCByZXF1aXJlIHRoaXMgZXh0cmEgZXhjaGFuZ2UNCmJldHdlZW4gdGhlIFBDRSBhbmQgdGhlIGlu Z3Jlc3Mgbm9kZSBmb3IgZXZlcnkgTFNQLiBSYXRoZXIsIHRoZSBkZWNyeXB0aW9uIGtleQ0KbmVl ZHMgdG8gYmUgZXhjaGFuZ2VkIG9ubHkgd2hlbiBpdCBpcyBjaGFuZ2VkLiBUaGUgcmVzdWx0IGlz IGFkZGl0aW9uYWwgZGVsYXkNCmR1cmluZyBldmVyeSBMU1Agc2V0dXAgZm9yIHRoZSBQS1Mgc29s dXRpb24gYnV0IG5vIGFkZGl0aW9uYWwgZGVsYXkgZm9yIHRoZSBQUlMNCnNvbHV0aW9uLjxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXpl PTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0 Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFu IHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPigyKSBQQ0UgYW5kIExTUiBQZXJmb3JtYW5jZTo8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQg c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEy LjBwdCc+VGhlIFBLUyBzb2x1dGlvbiBtdXN0IG1haW50YWluIGEgKHRlbXBvcmFyeSkgZGF0YWJh c2Ugb2Yga2V5cyBhZGRpbmcNCm92ZXJoZWFkIHRvIHRoZSBQQ0UuIFRoZSBQUlMgc29sdXRpb24g cmVxdWlyZXMgdGhlIGVuY3J5cHRpb24gb2YgdGhlIENQUyBpbiB0aGUNClBDRSBhbmQgZGVjcnlw dGlvbiBvZiB0aGUgQ1BTIGluIHRoZSBMU1IsIHdoaWNoIGNvdWxkIGJlIENQVSBpbnRlbnNpdmUu IE5vdGUNCnRoYXQgaW4gY2FzZSBvZiBhIGJ1cnN0IG9mIHJlcXVlc3RzLCBlbmNyeXB0aW9uIG9m IGxhcmdlIG51bWJlciBvZiBDUFMgbWF5IGhhdmUNCmFuIGltcGFjdCBvbiB0aGUgUENFIHJlc3Bv bnNlIHRpbWUuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6DQoxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4oMykgQWRkaXRpb24gb2YgU3RhdGUgaW4gdGhl IFBDRTo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToNCjEyLjBwdCc+VGhlIFBLUyBzb2x1dGlvbiByZXF1aXJlcyB0aGUgYWRkaXRpb24gb2YgcGF0 aC1zcGVjaWZpYyBzdGF0ZSBhbmQNCm1haW50ZW5hbmNlIG9mIGEgZGF0YWJhc2UgaW4gdGhlIFBD RS4gVGhlIFBSUyBzb2x1dGlvbiByZXF1aXJlcyBubyBhZGRpdGlvbmFsDQpzdGF0ZS48bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0z IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNp emU6DQoxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBz dHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4oNCkgU29sdXRpb24gU2NvcGU6PG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNl PSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPlRoZSBQ S1MgYW5kIFBSUyBzb2x1dGlvbnMgYm90aCB3b3JrIHdlbGwgaW4gY29uanVuY3Rpb24gd2l0aCBh IFBDRSB0bw0KZW5jb2RlIGFuZCBkZWNvZGUgdGhlIENQUy4gSG93ZXZlciB0aGUgUEtTIHByb3Zp ZGVzIG5vIGRpcmVjdCBzb2x1dGlvbiB3aXRob3V0DQphIFBDRS4gVGhpcyBwcmV2ZW50cyB0aGUg UEtTIHNvbHV0aW9uIGZvciB3b3JraW5nIGluIHRoZSBjYXNlIHdoZXJlIEEncyBuZXR3b3JrDQpz dHJhZGRsZXMgQidzIG5ldHdvcmsgYW5kIHdoZXJlIEEgd2FudHMgdG8gdXNlIGFuIEVSTyBmb3Ig YSBzZWdtZW50IG9mIHRoZSBMU1ANCmFjcm9zcyB0aGUgaW50ZXJ2ZW5pbmcgbmV0d29yaywgZS5n LiAobmV0QSktKG5ldEIpLShuZXRBKS4gSW4gYWRkaXRpb24sIHRoZSBQUlMNCmNvdWxkIGJlIHVz ZWQgdG8gcmVjb3JkIGEgQ1BTIGV2ZW4gaWYgdGhlIHBhdGggKGFuZCB0aGVyZWZvcmUgdGhlIHJl dHVybmVkIFJSTykNCmNyb3NzZXMgbXVsdGlwbGUgYm91bmRhcmllcy4gRmluYWxseSwgYSBQUlMg c29sdXRpb24gY291bGQgYmUgYWRhcHRlZCB0byByZXR1cm4NCmFjdHVhbCBmYWlsdXJlIGxvY2F0 aW9ucyBpbiBQRVJScyBhbmQvb3IgUEFUSFRFQVJzLCB3aGlsZSBrZWVwaW5nIHRoZSBmYWlsdXJl DQpsb2NhdGlvbiBjb25maWRlbnRpYWwgZnJvbSBMU1JzIHdpdGhvdXQgYSBkZWNyeXB0aW9uIGtl eS4gQ3VycmVudGx5IHByaXZhY3kgb2YNCnRoaXMgc291cmNlIGlzIG1haW50YWluZWQgYnkgcmV0 dXJuaW5nIHRoZSBhZGRyZXNzIG9mIGJvcmRlciBub2Rlcywgd2hpY2ggY2FuDQpiZSB2ZXJ5IG1p c2xlYWRpbmcuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6DQoxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3Bh biBzdHlsZT0nZm9udC1zaXplOg0KMTIuMHB0Jz4oNSkgTWVzc2FnZSBPYmplY3QgT3ZlcmhlYWQ6 PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250 IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQox Mi4wcHQnPlRoZSBQS1Mgc29sdXRpb24gcHJvdmlkZXMgYSB2ZXJ5IGNvbXBhY3Qga2V5IG9yIHRv a2VuIHRvIGlkZW50aWZ5IGENCnBhdGggc2VnbWVudCwgd2hpY2ggZ2VuZXJhbGx5IGFsbG93cyBm b3Igc21hbGxlciBFUk9zIHRvIGJlIHJldHVybmVkIGJ5IHRoZSBQQ0UNCmFuZCB0byBiZSByZXF1 ZXN0ZWQgaW4gdGhlIHJlc3VsdGluZyBQQVRIIG1lc3NhZ2UuIEEgUFJTIHdoaWNoIGNvbnRhaW5z IGEgQ1BTDQptdXN0IGdlbmVyYWxseSBiZSBhdCBsZWFzdCBhcyBsYXJnZSBhcyB0aGUgdW5lbmNy eXB0ZWQgUEFUSCB0aHJvdWdoIHRoZSBBUyBhbmQgbWF5DQpiZSBzaWduaWZpY2FudGx5IGxhcmdl ciBpZiBpdCBpcyBkZXNpcmFibGUgdG8gaGlkZSB0aGUgbnVtYmVyIG9mIGhvcHMgd2l0aGluDQp0 aGUgbmV0d29yayBmcm9tIGV4dGVybmFsIHZpZXcgYnkgcGFkZGluZyB0aGUgUFJTLiBUaGUgcmVz dWx0IGlzIHBvdGVudGlhbGx5DQpsYXJnZXIgUEFUSCAoYW5kIFBDRVApIG1lc3NhZ2VzIGZvciB0 aGUgUFJTIHNvbHV0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHls ZT0nZm9udC1zaXplOg0KMTIuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPlBsZWFzZSBu b3RlIHRoYXQgdGhlIHRyYWRlb2ZmcyBsaXN0ZWQgaGVyZSBhcmUgZm9yIHRoZSBjdXJyZW50IEkt RC4NClNvbWUgb2YgdGhlIHNob3J0Y29taW5ncyBvZiBlYWNoIGFwcHJvYWNoIGNvdWxkIGJlIG1p dGlnYXRlZCBieQ0KaW1wbGVtZW50YXRpb24tc3BlY2lmaWMgb3B0aW1pemF0aW9ucy4gRm9yIGV4 YW1wbGUsIGEgUENFIGNvdWxkIGNob29zZSB0bw0Kc2lnbmFsIHRoZSBDUFMgZXhwYW5zaW9uIHRv IHRoZSBlbnRyeSBib3VuZGFyeSBMU1IsIHNoaWZ0aW5nIHRoZSBidXJkZW4gb2YNCm1haW50YWlu aW5nIHRoZSBQS1Mgc3RhdGUgdG8gdGhlIExTUiBhbmQgZWxpbWluYXRpbmcgdGhlIHBlcmZvcm1h bmNlIGhpdCBkdXJpbmcNCkxTUCBzZXR1cC4gQSBzaW1pbGFyIGV4Y2hhbmdlIGNvdWxkIGJlIHBl cmZvcm1lZCBmb3IgdGhlIFBSUyBjYXNlLCBlbGltaW5hdGluZw0KdGhlIG5lZWQgZm9yIGEgc2Vw YXJhdGUga2V5IGV4Y2hhbmdlLiBUaGVzZSBleGFtcGxlcyBvZiBleHRlbnNpb25zIGFyZSBiZXlv bmQNCnRoZSBzY29wZSBvZiB0aGUgSUQsIGJ1dCBtaWdodCBiZSB1c2VmdWwgd2hlbiB3ZWlnaGlu ZyB0aGUgcHJvcyBhbmQgY29ucyBvZiB0aGUNCnR3byBzb2x1dGlvbnMuPG86cD48L286cD48L3Nw YW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPsKgPG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9 MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8L2JvZHk+ DQoNCjwvaHRtbD4NCg== ------_=_NextPart_001_01C658FF.1571E0A3-- Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Apr 2006 13:47:20 +0000 Message-Id: <5.1.1.9.2.20060405224611.04286a88@mailsv4.y.ecl.ntt.co.jp> Date: Wed, 05 Apr 2006 22:47:12 +0900 To: Kireeti Kompella , ccamp@ops.ietf.org From: Wataru Imajuku Subject: Re: Progressing docs Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit Hi, Kiretti and Adrian Yes to all Wataru >Hi All, > >This is to double-check support *on the list* for the following I-Ds to go >to WG docs: > >a) MPLS-GMPLS interworking > draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt >b) "hierarchy bis" > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt >c) Call Support > draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt >d) Ethernet TSpec > draft-dimitri-mef-ethernet-traffic-parameters-00.txt >e) OSPF-TE MIB > draft-otani-ccamp-gmpls-ospf-mib-02.txt > >Please say for each if you think it should/should not become a WG doc. > >My previous email was in error: the "excellent" support was for the >migration doc. Just to be clear, we'll double-check all these docs. > >Kireeti. >------- > --------------------------------- Wataru Imajuku @NTT Network Innovation Labs. TEL +81-46-859-4315 FAX +81-46-859-5541 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Apr 2006 13:42:25 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: draft-ietf-ccamp-crankback-05.txt ready for AD review Date: Wed, 5 Apr 2006 08:41:11 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC75FF@KCCLUST06EVS1.ugd.att.com> Thread-Topic: draft-ietf-ccamp-crankback-05.txt ready for AD review Thread-Index: AcVg+ChMB9VbsGXTR6ieEfHbAVxUvT3vXWXQ From: "Ash, Gerald R \(Jerry\), ALABS" To: , Cc: "Ash, Gerald R \(Jerry\), ALABS" , , The crankback draft http://www.ietf.org/internet-drafts/draft-ietf-ccamp-crankback-05.txt has been in AD review (publication requested) for more than 10 months. Can we have a status? 6 other drafts are in the CCAMP AD-review queue also, but not as long: https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dsearch_list&= s earch_job_owner=3D0&search_group_acronym=3Dccamp&search_status_id=3D&sear= ch_cu r_state=3D&sub_state_id=3D6&search_filename=3D&search_rfcnumber=3D&search= _area_a cronym=3D&search_button=3DSEARCH. Thanks, Jerry -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Wednesday, May 25, 2005 3:04 AM To: zinin@psg.com Cc: ccamp@ops.ietf.org; iesg-secretary@ietf.org; fenner@research.att.com; adrian@olddog.co.uk Subject: draft-ietf-ccamp-crankback-05.txt ready for AD review Hi Alex,=20 draft-ietf-ccamp-crankback-05.txt is ready for AD review and progression through the process.=20 It is targeted at Standards Track.=20 The I-D has been through WG last call and has been liaised to ITU-T SG15.=20 Updates have been made in response to comments made in both forums.=20 I am happy with these updates, but note that I am also the editor of this=20 document.=20 Cheers,=20 Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Apr 2006 11:33:15 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: Proposed liaison to ITU-T on new RFCs Date: Wed, 5 Apr 2006 06:33:09 -0500 Message-ID: <9473683187ADC049A855ED2DA739ABCA0DDC75FE@KCCLUST06EVS1.ugd.att.com> Thread-Topic: Proposed liaison to ITU-T on new RFCs Thread-Index: AcZYoa6irtEFpxN7RfmnjUbfVL5dcwAAr8Hg From: "Ash, Gerald R \(Jerry\), ALABS" To: "Adrian Farrel" , Cc: "Ash, Gerald R \(Jerry\), ALABS" , "Kireeti Kompella" , "Bill Fenner" , "Ross Callon" , "Scott Bradner" I like your subtle (hint, hint) approach. Jerry=20 -----Original Message----- From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Adrian Farrel Sent: Wednesday, April 05, 2006 7:11 AM To: ccamp@ops.ietf.org Cc: 'Kireeti Kompella'; Bill Fenner; Ross Callon; Scott Bradner Subject: Proposed liaison to ITU-T on new RFCs In the spirit of continued communication with Study Group 15 of the ITU-T we need to send information about our recently published RFCs. The following is a draft liaison that I would like to send in time for their interim meeting in Kobe, Japan later this month. Comments please. Thanks, Adrian =3D=3D=3D=3D=3D To: ITU-T Study Group 15 From: IETF CCAMP working group Cc: IETF Routing Area Directors For: Information Subject: Recently published IETF RFCs relevant to GMPLS, Optical Transport Networks, and Packet Transport Networks The IETF's CCAMP working group is pleased to inform Study Group 15 of the ITU-T of the publication of several new RFCs that are relevant to the work that you are doing with optical and packet transport networks. Several of these RFCs received useful review and input from Study Group 15 participants for which CCAMP would like to express its thanks. RFC 4257 http://www.ietf.org/rfc/rfc4257.txt Title Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks Abstract Generalized Multi-Protocol Label Switching (GMPLS) is a suite of protocol extensions to MPLS to make it generally applicable, to include, for example, control of non packet-based switching, and particularly, optical switching. One consideration is to use GMPLS protocols to upgrade the control plane of optical transport networks. This document illustrates this process by describing those extensions to GMPLS protocols that are aimed at controlling Synchronous Digital Hierarchy (SDH) or Synchronous Optical Networking (SONET) networks. SDH/SONET networks make good examples of this process for a variety of reasons. This document highlights extensions to GMPLS-related routing protocols to disseminate information needed in transport path computation and network operations, together with (G)MPLS protocol extensions required for the provisioning of transport circuits. New capabilities that an GMPLS control plane would bring to SDH/SONET networks, such as new restoration methods and multi-layer circuit establishment, are also discussed. RFC 4258 http://www.ietf.org/rfc/rfc4258.txt Title Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON) Abstract The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting Time Division Multiplexing (TDM) connections including Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) and Optical Transport Networks (OTNs). This document concentrates on the routing requirements placed on the GMPLS suite of protocols in order to support the capabilities and functionalities of an Automatically Switched Optical Network (ASON) as defined by the ITU-T. RFC 4327 http://www.ietf.org/rfc/rfc4327.txt Title Link Management Protocol (LMP) Management Information Base (MIB) Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling the Link Management Protocol (LMP). RFC 4328 http://www.ietf.org/rfc/rfc4328.txt Title Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control Abstract This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling documents. It describes the technology- specific information needed to extend GMPLS signaling to control Optical Transport Networks (OTN); it also includes the so-called pre-OTN developments. RFC 4394 http://www.ietf.org/rfc/rfc4394.txt Title A Transport Network View of the Link Management Protocol (LMP) Abstract The Link Management Protocol (LMP) has been developed as part of the Generalized MPLS (GMPLS) protocol suite to manage Traffic Engineering (TE) resources and links. The GMPLS control plane (routing and signaling) uses TE links for establishing Label Switched Paths (LSPs). This memo describes the relationship of the LMP procedures to 'discovery' as defined in the International Telecommunication Union (ITU-T), and ongoing ITU-T work. This document provides an overview of LMP in the context of the ITU-T Automatically Switched Optical Networks (ASON) and transport network terminology and relates it to the ITU-T discovery work to promote a common understanding for progressing the work of IETF and ITU-T. RFC 4397 http://www.ietf.org/rfc/rfc4397.txt Title A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture Abstract Generalized Multiprotocol Label Switching (GMPLS) has been developed by the IETF to facilitate the establishment of Label Switched Paths (LSPs) in a variety of data plane technologies and across several architectural models. The ITU-T has specified an architecture for the control of Automatically Switched Optical Networks (ASON). This document provides a lexicography for the interpretation of GMPLS terminology within the context of the ASON architecture. It is important to note that GMPLS is applicable in a wider set of contexts than just ASON. The definitions presented in this document do not provide exclusive or complete interpretations of GMPLS concepts. This document simply allows the GMPLS terms to be applied within the ASON context. RFC 4426 http://www.ietf.org/rfc/rfc4426.txt Title Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification Abstract This document presents a functional description of the protocol extensions needed to support Generalized Multi-Protocol Label Switching (GMPLS)-based recovery (i.e., protection and restoration). Protocol specific formats and mechanisms will be described in companion documents. RFC 4427 http://www.ietf.org/rfc/rfc4427.txt Title Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) Abstract This document defines a common terminology for Generalized Multi- Protocol Label Switching (GMPLS)-based recovery mechanisms (i.e., protection and restoration). The terminology is independent of the underlying transport technologies covered by GMPLS. RFC 4428 http://www.ietf.org/rfc/rfc4428.txt Title Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) Abstract This document provides an analysis grid to evaluate, compare, and contrast the Generalized Multi-Protocol Label Switching (GMPLS) protocol suite capabilities with the recovery mechanisms currently proposed at the IETF CCAMP Working Group. A detailed analysis of each of the recovery phases is provided using the terminology defined in RFC 4427. This document focuses on transport plane survivability and recovery issues and not on control plane resilience and related aspects. All IETF RFCs can be downloaded for free from http://www.ietf.org/rfc.html The current work plan and progress status of the CCAMP working group can be viewed at http://www.ietf.org/html.charters/ccamp-charter.html The CCAMP working group welcomes questions and discussion about all of its work from individuals or organisations. The CCAMP mailing list is open to anyone. Details of subscription can be found on the CCAMP charter page. Regards, Adrian Farrel and Kireeti Kompella CCAMP working group chairs Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Apr 2006 11:30:43 +0000 Date: Wed, 05 Apr 2006 18:29:40 +0800 From: Dan Li Subject: Re: Progressing docs To: Kireeti Kompella , ccamp@ops.ietf.org Message-id: <00f001c6589b$d89f6de0$d04c460a@china.huawei.com> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT See below. - Dan ----- Original Message ----- From: "Kireeti Kompella" To: Sent: Saturday, April 01, 2006 2:12 AM Subject: Progressing docs > Hi All, > > This is to double-check support *on the list* for the following I-Ds > to go to WG docs: > > a) MPLS-GMPLS interworking > draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt Yes > b) "hierarchy bis" > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt Yes > c) Call Support > draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt Yes > d) Ethernet TSpec > draft-dimitri-mef-ethernet-traffic-parameters-00.txt Yes > e) OSPF-TE MIB > draft-otani-ccamp-gmpls-ospf-mib-02.txt Yes > > Please say for each if you think it should/should not become a WG doc. > > My previous email was in error: the "excellent" support was for the > migration doc. Just to be clear, we'll double-check all these docs. > > Kireeti. > ------- > Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Apr 2006 11:10:57 +0000 Message-ID: <000e01c658a1$933f0e80$d9849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Cc: "'Kireeti Kompella'" , "Bill Fenner" , "Ross Callon" , "Scott Bradner" Subject: Proposed liaison to ITU-T on new RFCs Date: Wed, 5 Apr 2006 12:10:31 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit In the spirit of continued communication with Study Group 15 of the ITU-T we need to send information about our recently published RFCs. The following is a draft liaison that I would like to send in time for their interim meeting in Kobe, Japan later this month. Comments please. Thanks, Adrian ===== To: ITU-T Study Group 15 From: IETF CCAMP working group Cc: IETF Routing Area Directors For: Information Subject: Recently published IETF RFCs relevant to GMPLS, Optical Transport Networks, and Packet Transport Networks The IETF's CCAMP working group is pleased to inform Study Group 15 of the ITU-T of the publication of several new RFCs that are relevant to the work that you are doing with optical and packet transport networks. Several of these RFCs received useful review and input from Study Group 15 participants for which CCAMP would like to express its thanks. RFC 4257 http://www.ietf.org/rfc/rfc4257.txt Title Framework for Generalized Multi-Protocol Label Switching (GMPLS)-based Control of Synchronous Digital Hierarchy/Synchronous Optical Networking (SDH/SONET) Networks Abstract Generalized Multi-Protocol Label Switching (GMPLS) is a suite of protocol extensions to MPLS to make it generally applicable, to include, for example, control of non packet-based switching, and particularly, optical switching. One consideration is to use GMPLS protocols to upgrade the control plane of optical transport networks. This document illustrates this process by describing those extensions to GMPLS protocols that are aimed at controlling Synchronous Digital Hierarchy (SDH) or Synchronous Optical Networking (SONET) networks. SDH/SONET networks make good examples of this process for a variety of reasons. This document highlights extensions to GMPLS-related routing protocols to disseminate information needed in transport path computation and network operations, together with (G)MPLS protocol extensions required for the provisioning of transport circuits. New capabilities that an GMPLS control plane would bring to SDH/SONET networks, such as new restoration methods and multi-layer circuit establishment, are also discussed. RFC 4258 http://www.ietf.org/rfc/rfc4258.txt Title Requirements for Generalized Multi-Protocol Label Switching (GMPLS) Routing for the Automatically Switched Optical Network (ASON) Abstract The Generalized Multi-Protocol Label Switching (GMPLS) suite of protocols has been defined to control different switching technologies as well as different applications. These include support for requesting Time Division Multiplexing (TDM) connections including Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) and Optical Transport Networks (OTNs). This document concentrates on the routing requirements placed on the GMPLS suite of protocols in order to support the capabilities and functionalities of an Automatically Switched Optical Network (ASON) as defined by the ITU-T. RFC 4327 http://www.ietf.org/rfc/rfc4327.txt Title Link Management Protocol (LMP) Management Information Base (MIB) Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling the Link Management Protocol (LMP). RFC 4328 http://www.ietf.org/rfc/rfc4328.txt Title Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control Abstract This document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling documents. It describes the technology- specific information needed to extend GMPLS signaling to control Optical Transport Networks (OTN); it also includes the so-called pre-OTN developments. RFC 4394 http://www.ietf.org/rfc/rfc4394.txt Title A Transport Network View of the Link Management Protocol (LMP) Abstract The Link Management Protocol (LMP) has been developed as part of the Generalized MPLS (GMPLS) protocol suite to manage Traffic Engineering (TE) resources and links. The GMPLS control plane (routing and signaling) uses TE links for establishing Label Switched Paths (LSPs). This memo describes the relationship of the LMP procedures to 'discovery' as defined in the International Telecommunication Union (ITU-T), and ongoing ITU-T work. This document provides an overview of LMP in the context of the ITU-T Automatically Switched Optical Networks (ASON) and transport network terminology and relates it to the ITU-T discovery work to promote a common understanding for progressing the work of IETF and ITU-T. RFC 4397 http://www.ietf.org/rfc/rfc4397.txt Title A Lexicography for the Interpretation of Generalized Multiprotocol Label Switching (GMPLS) Terminology within the Context of the ITU-T's Automatically Switched Optical Network (ASON) Architecture Abstract Generalized Multiprotocol Label Switching (GMPLS) has been developed by the IETF to facilitate the establishment of Label Switched Paths (LSPs) in a variety of data plane technologies and across several architectural models. The ITU-T has specified an architecture for the control of Automatically Switched Optical Networks (ASON). This document provides a lexicography for the interpretation of GMPLS terminology within the context of the ASON architecture. It is important to note that GMPLS is applicable in a wider set of contexts than just ASON. The definitions presented in this document do not provide exclusive or complete interpretations of GMPLS concepts. This document simply allows the GMPLS terms to be applied within the ASON context. RFC 4426 http://www.ietf.org/rfc/rfc4426.txt Title Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification Abstract This document presents a functional description of the protocol extensions needed to support Generalized Multi-Protocol Label Switching (GMPLS)-based recovery (i.e., protection and restoration). Protocol specific formats and mechanisms will be described in companion documents. RFC 4427 http://www.ietf.org/rfc/rfc4427.txt Title Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) Abstract This document defines a common terminology for Generalized Multi- Protocol Label Switching (GMPLS)-based recovery mechanisms (i.e., protection and restoration). The terminology is independent of the underlying transport technologies covered by GMPLS. RFC 4428 http://www.ietf.org/rfc/rfc4428.txt Title Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) Abstract This document provides an analysis grid to evaluate, compare, and contrast the Generalized Multi-Protocol Label Switching (GMPLS) protocol suite capabilities with the recovery mechanisms currently proposed at the IETF CCAMP Working Group. A detailed analysis of each of the recovery phases is provided using the terminology defined in RFC 4427. This document focuses on transport plane survivability and recovery issues and not on control plane resilience and related aspects. All IETF RFCs can be downloaded for free from http://www.ietf.org/rfc.html The current work plan and progress status of the CCAMP working group can be viewed at http://www.ietf.org/html.charters/ccamp-charter.html The CCAMP working group welcomes questions and discussion about all of its work from individuals or organisations. The CCAMP mailing list is open to anyone. Details of subscription can be found on the CCAMP charter page. Regards, Adrian Farrel and Kireeti Kompella CCAMP working group chairs Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Apr 2006 10:46:03 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: Progressing docs Date: Wed, 5 Apr 2006 12:44:48 +0200 Message-ID: Thread-Topic: Progressing docs Thread-Index: AcZU7zIwfdowxGaTSAOns2lu7cJQOQDrpqBw From: "LE ROUX Jean-Louis RD-CORE-LAN" To: "Kireeti Kompella" , Hi Kireeti, I support these 5 Ids as WG docs. Regards, JL=20 > -----Message d'origine----- > De : owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] De la part de Kireeti Kompella > Envoy=E9 : vendredi 31 mars 2006 20:13 > =C0 : ccamp@ops.ietf.org > Objet : Progressing docs >=20 > Hi All, >=20 > This is to double-check support *on the list* for the=20 > following I-Ds to go to WG docs: >=20 > a) MPLS-GMPLS interworking > draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt > b) "hierarchy bis" > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > c) Call Support > draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt > d) Ethernet TSpec > draft-dimitri-mef-ethernet-traffic-parameters-00.txt > e) OSPF-TE MIB > draft-otani-ccamp-gmpls-ospf-mib-02.txt >=20 > Please say for each if you think it should/should not become a WG doc. >=20 > My previous email was in error: the "excellent" support was=20 > for the migration doc. Just to be clear, we'll double-check=20 > all these docs. >=20 > Kireeti. > ------- >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Wed, 05 Apr 2006 06:12:44 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Subject: RE: Progressing docs Date: Wed, 5 Apr 2006 14:10:34 +0800 Message-ID: Thread-Topic: Progressing docs Thread-Index: AcZU7tT8tShOz/PcRSWdm7b+2VC2bADiNFBW From: "Hidet Sugiyama" To: "Kireeti Kompella" , Yes to all. -hidet ________________________________ From: owner-ccamp@ops.ietf.org $BBeM}(J Kireeti Kompella Sent: 2006/04/01 ($BEZ(J) 3:12 To: ccamp@ops.ietf.org Subject: Progressing docs Hi All, This is to double-check support *on the list* for the following I-Ds to go to WG docs: a) MPLS-GMPLS interworking draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt b) "hierarchy bis" draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt c) Call Support draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt d) Ethernet TSpec draft-dimitri-mef-ethernet-traffic-parameters-00.txt e) OSPF-TE MIB draft-otani-ccamp-gmpls-ospf-mib-02.txt Please say for each if you think it should/should not become a WG doc. My previous email was in error: the "excellent" support was for the migration doc. Just to be clear, we'll double-check all these docs. Kireeti. ------- Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 04 Apr 2006 21:37:42 +0000 Date: Tue, 4 Apr 2006 14:36:32 -0700 (PDT) From: Arthi Ayyangar To: Kireeti Kompella cc: ccamp@ops.ietf.org Subject: Re: Progressing docs Message-ID: <20060404143421.M63242@zircon.juniper.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > a) MPLS-GMPLS interworking > draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt ----> yes. > b) "hierarchy bis" > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt ----> yes. > c) Call Support > draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt ----> yes. > d) Ethernet TSpec > draft-dimitri-mef-ethernet-traffic-parameters-00.txt ---> yes. > e) OSPF-TE MIB > draft-otani-ccamp-gmpls-ospf-mib-02.txt -----> yes. thanks, -arthi > Please say for each if you think it should/should not become a WG doc. > > My previous email was in error: the "excellent" support was for the migration > doc. Just to be clear, we'll double-check all these docs. > > Kireeti. > ------- > Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 04 Apr 2006 13:36:31 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Progressing docs Date: Tue, 4 Apr 2006 09:35:43 -0400 Message-ID: <34B3EAA5B3066A42914D28C5ECF5FEA407A42F61@zrtphxm2> Thread-Topic: Progressing docs Thread-Index: AcZU75e7R3rhRC1UQqS2ltsAJSecCQC/PwIA From: "Don Fedyk" To: Hi Kireeti Yes to all, Don=20 > -----Original Message----- > Hi All, >=20 > This is to double-check support *on the list* for the following I-Ds=20 > to go to WG docs: >=20 > a) MPLS-GMPLS interworking > draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt > b) "hierarchy bis" > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > c) Call Support > draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt > d) Ethernet TSpec > draft-dimitri-mef-ethernet-traffic-parameters-00.txt > e) OSPF-TE MIB > draft-otani-ccamp-gmpls-ospf-mib-02.txt >=20 > Please say for each if you think it should/should not become a WG doc. >=20 > My previous email was in error: the "excellent" support was for the=20 > migration doc. Just to be clear, we'll double-check all these docs. >=20 > Kireeti. > ------- >=20 >=20 >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Tue, 04 Apr 2006 13:22:57 +0000 Date: Tue, 04 Apr 2006 22:20:39 +0900 From: Eiji Oki To: Kireeti Kompella Subject: Re: Progressing docs Cc: ccamp@ops.ietf.org Message-Id: <20060404222015.061E.OKI.EIJI@lab.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi, Yes to all. Eiji On Fri, 31 Mar 2006 10:12:31 -0800 (PST) Kireeti Kompella wrote: > Hi All, > > This is to double-check support *on the list* for the following I-Ds > to go to WG docs: > > a) MPLS-GMPLS interworking > draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt > b) "hierarchy bis" > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > c) Call Support > draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt > d) Ethernet TSpec > draft-dimitri-mef-ethernet-traffic-parameters-00.txt > e) OSPF-TE MIB > draft-otani-ccamp-gmpls-ospf-mib-02.txt > > Please say for each if you think it should/should not become a WG doc. > > My previous email was in error: the "excellent" support was for the > migration doc. Just to be clear, we'll double-check all these docs. > > Kireeti. > ------- Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 03 Apr 2006 22:16:14 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Subject: RE: Progressing docs Date: Mon, 3 Apr 2006 18:15:25 -0400 Message-ID: <3C292CE901FC634693F24FB2DDC4D332014EEE6C@xmb-rtp-20d.amer.cisco.com> Thread-Topic: Progressing docs Thread-Index: AcZU7s+Ny4wVPvycRI+YwaQ5yqkm/gCfRsZQ From: "Rich Bradford \(rbradfor\)" To: "Kireeti Kompella" , PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBvd25lci1jY2FtcEBvcHMuaWV0 Zi5vcmcgW21haWx0bzpvd25lci1jY2FtcEBvcHMuaWV0Zi5vcmddIE9uIEJlaGFsZiBPZg0KPiBL aXJlZXRpIEtvbXBlbGxhDQo+IFNlbnQ6IEZyaWRheSwgTWFyY2ggMzEsIDIwMDYgMToxMyBQTQ0K PiBUbzogY2NhbXBAb3BzLmlldGYub3JnDQo+IFN1YmplY3Q6IFByb2dyZXNzaW5nIGRvY3MNCj4g DQo+IEhpIEFsbCwNCj4gDQo+IFRoaXMgaXMgdG8gZG91YmxlLWNoZWNrIHN1cHBvcnQgKm9uIHRo ZSBsaXN0KiBmb3IgdGhlIGZvbGxvd2luZyBJLURzDQo+IHRvIGdvIHRvIFdHIGRvY3M6DQo+IA0K PiBhKSBNUExTLUdNUExTIGludGVyd29ya2luZw0KPiAgCWRyYWZ0LXNoaW9tb3RvLWNjYW1wLW1w bHMtZ21wbHMtaW50ZXJ3b3JrLWZtd2stMDEudHh0DQpZZXMuDQo+IGIpICJoaWVyYXJjaHkgYmlz Ig0KPiAgCWRyYWZ0LXNoaW9tb3RvLWNjYW1wLWxzcC1oaWVyYXJjaHktYmlzLTAxLnR4dA0KQWJz dGFpbi4NCj4gYykgQ2FsbCBTdXBwb3J0DQo+ICAJZHJhZnQtcGFwYWRpbWl0cmlvdS1jY2FtcC1n bXBscy1yc3ZwLXRlLWNhbGwtMDAudHh0DQpZZXMNCj4gZCkgRXRoZXJuZXQgVFNwZWMNCj4gIAlk cmFmdC1kaW1pdHJpLW1lZi1ldGhlcm5ldC10cmFmZmljLXBhcmFtZXRlcnMtMDAudHh0DQpZZXMN Cj4gZSkgT1NQRi1URSBNSUINCj4gIAlkcmFmdC1vdGFuaS1jY2FtcC1nbXBscy1vc3BmLW1pYi0w Mi50eHQNClllcw0KPiANCj4gUGxlYXNlIHNheSBmb3IgZWFjaCBpZiB5b3UgdGhpbmsgaXQgc2hv dWxkL3Nob3VsZCBub3QgYmVjb21lIGEgV0cgZG9jLg0KPiANCj4gTXkgcHJldmlvdXMgZW1haWwg d2FzIGluIGVycm9yOiB0aGUgImV4Y2VsbGVudCIgc3VwcG9ydCB3YXMgZm9yIHRoZQ0KPiBtaWdy YXRpb24gZG9jLiAgSnVzdCB0byBiZSBjbGVhciwgd2UnbGwgZG91YmxlLWNoZWNrIGFsbCB0aGVz ZSBkb2NzLg0KPiANCj4gS2lyZWV0aS4NCj4gLS0tLS0tLQ0K Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 03 Apr 2006 21:42:26 +0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: Progressing docs Date: Mon, 3 Apr 2006 17:41:20 -0400 Message-ID: Thread-Topic: Progressing docs Thread-Index: AcZU7s/GVDIPvcfVRnq3QcZV/BCHrgCT61Vg From: "Zafar Ali \(zali\)" To: "Kireeti Kompella" , > -----Original Message----- > From: owner-ccamp@ops.ietf.org=20 > [mailto:owner-ccamp@ops.ietf.org] On Behalf Of Kireeti Kompella > Sent: Friday, March 31, 2006 1:13 PM > To: ccamp@ops.ietf.org > Subject: Progressing docs >=20 > Hi All, >=20 > This is to double-check support *on the list* for the=20 > following I-Ds to go to WG docs: >=20 > a) MPLS-GMPLS interworking > draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt Yes, but I have some comments about the ID merger, that I am discussing w/ Authors off-line.=20 > b) "hierarchy bis" > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt Yes,=20 > c) Call Support > draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt Yes,=20 > d) Ethernet TSpec > draft-dimitri-mef-ethernet-traffic-parameters-00.txt Yes,=20 > e) OSPF-TE MIB > draft-otani-ccamp-gmpls-ospf-mib-02.txt >=20 Yes,=20 > Please say for each if you think it should/should not become a WG doc. >=20 > My previous email was in error: the "excellent" support was=20 > for the migration doc. Just to be clear, we'll double-check=20 > all these docs. >=20 > Kireeti. > ------- >=20 Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 03 Apr 2006 15:29:15 +0000 Date: Mon, 03 Apr 2006 23:28:31 +0800 From: Tina TSOU Subject: Re: Progressing docs To: ccamp@ops.ietf.org Message-id: <00a901c65733$43f9c9b0$d074a7d9@IBM4307EA0CEF3> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT Hi, Yes to all. Tina ----- Original Message ----- From: To: Sent: Monday, April 03, 2006 11:23 PM Subject: Re: Progressing docs > Hi, > > Yes to all. > > Ichiro > > At 23:15 06/04/03, Igor Bryskin wrote: > >Yes to all. > > > >Igor > > > >----- Original Message ----- > >From: "Kireeti Kompella" > >To: > >Sent: Friday, March 31, 2006 2:12 PM > >Subject: Progressing docs > > > > > >> Hi All, > >> > >> This is to double-check support *on the list* for the following I-Ds > >> to go to WG docs: > >> > >> a) MPLS-GMPLS interworking > >> draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt > >> b) "hierarchy bis" > >> draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > >> c) Call Support > >> draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt > >> d) Ethernet TSpec > >> draft-dimitri-mef-ethernet-traffic-parameters-00.txt > >> e) OSPF-TE MIB > >> draft-otani-ccamp-gmpls-ospf-mib-02.txt > >> > >> Please say for each if you think it should/should not become a WG doc. > >> > >> My previous email was in error: the "excellent" support was for the > >> migration doc. Just to be clear, we'll double-check all these docs. > >> > >> Kireeti. > >> ------- > >> > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 03 Apr 2006 15:16:55 +0000 Message-Id: <6.0.0.20.2.20060404002315.04ba56a0@imb.m.ecl.ntt.co.jp> Date: Tue, 04 Apr 2006 00:23:43 +0900 To: From: "inoue.ichiro@lab.ntt.co.jp" Subject: Re: Progressing docs Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit Hi, Yes to all. Ichiro At 23:15 06/04/03, Igor Bryskin wrote: >Yes to all. > >Igor > >----- Original Message ----- >From: "Kireeti Kompella" >To: >Sent: Friday, March 31, 2006 2:12 PM >Subject: Progressing docs > > >> Hi All, >> >> This is to double-check support *on the list* for the following I-Ds >> to go to WG docs: >> >> a) MPLS-GMPLS interworking >> draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt >> b) "hierarchy bis" >> draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt >> c) Call Support >> draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt >> d) Ethernet TSpec >> draft-dimitri-mef-ethernet-traffic-parameters-00.txt >> e) OSPF-TE MIB >> draft-otani-ccamp-gmpls-ospf-mib-02.txt >> >> Please say for each if you think it should/should not become a WG doc. >> >> My previous email was in error: the "excellent" support was for the >> migration doc. Just to be clear, we'll double-check all these docs. >> >> Kireeti. >> ------- >> Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 03 Apr 2006 14:16:42 +0000 Message-ID: <00a501c65729$202e78f0$7d1810ac@movaz.com> From: "Igor Bryskin" To: "Kireeti Kompella" , Subject: Re: Progressing docs Date: Mon, 3 Apr 2006 10:15:56 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Yes to all. Igor ----- Original Message ----- From: "Kireeti Kompella" To: Sent: Friday, March 31, 2006 2:12 PM Subject: Progressing docs > Hi All, > > This is to double-check support *on the list* for the following I-Ds > to go to WG docs: > > a) MPLS-GMPLS interworking > draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt > b) "hierarchy bis" > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > c) Call Support > draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt > d) Ethernet TSpec > draft-dimitri-mef-ethernet-traffic-parameters-00.txt > e) OSPF-TE MIB > draft-otani-ccamp-gmpls-ospf-mib-02.txt > > Please say for each if you think it should/should not become a WG doc. > > My previous email was in error: the "excellent" support was for the > migration doc. Just to be clear, we'll double-check all these docs. > > Kireeti. > ------- > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 03 Apr 2006 14:08:10 +0000 From: "Rajiv Papneja" To: "'Kireeti Kompella'" , Subject: RE: Progressing docs Date: Mon, 3 Apr 2006 10:06:51 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Thread-Index: AcZU72LpaYMR3/UUQMaHCfxQYT0+PACOGiKg Message-Id: Yes to all. /R > -----Original Message----- > From: Kireeti Kompella [mailto:kireeti@juniper.net] > Sent: Friday, March 31, 2006 1:13 PM > To: ccamp@ops.ietf.org > Subject: Progressing docs > > Hi All, > > This is to double-check support *on the list* for the following I-Ds > to go to WG docs: > > a) MPLS-GMPLS interworking > draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt > b) "hierarchy bis" > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > c) Call Support > draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt > d) Ethernet TSpec > draft-dimitri-mef-ethernet-traffic-parameters-00.txt > e) OSPF-TE MIB > draft-otani-ccamp-gmpls-ospf-mib-02.txt > > Please say for each if you think it should/should not become a WG doc. > > My previous email was in error: the "excellent" support was for the > migration doc. Just to be clear, we'll double-check all these docs. > > Kireeti. > ------- > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 03 Apr 2006 09:45:22 +0000 Message-ID: <4430EE57.7030709@lab.ntt.co.jp> Date: Mon, 03 Apr 2006 18:43:51 +0900 From: Kohei Shiomoto User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ja-JP; rv:1.7.11) Gecko/20050728 MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: Progressing docs Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Yes to all Kohei Kireeti Kompella wrote: > Hi All, > > This is to double-check support *on the list* for the following I-Ds to > go to WG docs: > > a) MPLS-GMPLS interworking > draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt > b) "hierarchy bis" > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > c) Call Support > draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt > d) Ethernet TSpec > draft-dimitri-mef-ethernet-traffic-parameters-00.txt > e) OSPF-TE MIB > draft-otani-ccamp-gmpls-ospf-mib-02.txt > > Please say for each if you think it should/should not become a WG doc. > > My previous email was in error: the "excellent" support was for the > migration doc. Just to be clear, we'll double-check all these docs. > > Kireeti. > ------- > > > Envelope-to: ccamp-data@psg.com Delivery-date: Mon, 03 Apr 2006 04:13:00 +0000 Message-Id: <5.1.1.9.2.20060403130841.06acfe88@imf.m.ecl.ntt.co.jp> Date: Mon, 03 Apr 2006 13:10:37 +0900 To: Kireeti Kompella , ccamp@ops.ietf.org From: Tomonori TAKEDA Subject: Re: Progressing docs Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP"; format=flowed Content-Transfer-Encoding: 7bit Yes to all Tomonori At 10:12 06/03/31 -0800, Kireeti Kompella wrote: >Hi All, > >This is to double-check support *on the list* for the following I-Ds to go >to WG docs: > >a) MPLS-GMPLS interworking > draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt >b) "hierarchy bis" > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt >c) Call Support > draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt >d) Ethernet TSpec > draft-dimitri-mef-ethernet-traffic-parameters-00.txt >e) OSPF-TE MIB > draft-otani-ccamp-gmpls-ospf-mib-02.txt > >Please say for each if you think it should/should not become a WG doc. > >My previous email was in error: the "excellent" support was for the >migration doc. Just to be clear, we'll double-check all these docs. > >Kireeti. >------- Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 02 Apr 2006 22:06:19 +0000 Message-ID: <045201c656a1$930ddb00$1e849ed9@Puppy> Reply-To: "Adrian Farrel" From: "Adrian Farrel" To: Subject: Document status of draft-ietf-ccamp-gmpls-addressing Date: Sun, 2 Apr 2006 22:56:35 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Hi, Having spoken to the ADs, we are agreed that this draft is Standards Track. We will move forward on that basis. Thanks. Adrian Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 02 Apr 2006 19:39:31 +0000 To: Kireeti Kompella Cc: ccamp@ops.ietf.org Subject: Re: Progressing docs MIME-Version: 1.0 Message-ID: From: Dimitri.Papadimitriou@alcatel.be Date: Sun, 2 Apr 2006 21:37:53 +0200 Content-Type: text/plain; charset="US-ASCII" > Hi All, > > This is to double-check support *on the list* for the following I-Ds > to go to WG docs: > > a) MPLS-GMPLS interworking > draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt yes > b) "hierarchy bis" > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt abstain > c) Call Support > draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt yes > d) Ethernet TSpec > draft-dimitri-mef-ethernet-traffic-parameters-00.txt yes > e) OSPF-TE MIB > draft-otani-ccamp-gmpls-ospf-mib-02.txt yes > Please say for each if you think it should/should not become a WG doc. > > My previous email was in error: the "excellent" support was for the > migration doc. Just to be clear, we'll double-check all these docs. Envelope-to: ccamp-data@psg.com Delivery-date: Sun, 02 Apr 2006 03:14:26 +0000 Message-ID: <442F40E4.3090709@alcatel.fr> Date: Sun, 02 Apr 2006 05:11:32 +0200 From: Emmanuel.Dotaro@alcatel.fr Reply-To: Emmanuel.Dotaro@alcatel.fr Organization: Alcatel CTO/R&I User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: Progressing docs Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=ISO-8859-1; format=flowed yes to all Kireeti Kompella wrote: > Hi All, > > This is to double-check support *on the list* for the following I-Ds > to go to WG docs: > > a) MPLS-GMPLS interworking > draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt > b) "hierarchy bis" > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > c) Call Support > draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt > d) Ethernet TSpec > draft-dimitri-mef-ethernet-traffic-parameters-00.txt > e) OSPF-TE MIB > draft-otani-ccamp-gmpls-ospf-mib-02.txt > > Please say for each if you think it should/should not become a WG doc. > > My previous email was in error: the "excellent" support was for the > migration doc. Just to be clear, we'll double-check all these docs. > > Kireeti. > ------- > > Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 01 Apr 2006 02:57:44 +0000 Message-ID: <442DEBE3.5010207@us.fujitsu.com> Date: Fri, 31 Mar 2006 21:56:35 -0500 From: Richard Rabbat Organization: Fujitsu Labs of America User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Kireeti Kompella CC: ccamp@ops.ietf.org Subject: Re: Progressing docs Content-Type: multipart/mixed; boundary="------------040706060407060407040909" This is a multi-part message in MIME format. --------------040706060407060407040909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Kireeti, yes to all Kireeti Kompella wrote: > Hi All, > > This is to double-check support *on the list* for the following I-Ds > to go to WG docs: > > a) MPLS-GMPLS interworking > draft-shiomoto-ccamp-mpls-gmpls-interwork-fmwk-01.txt > b) "hierarchy bis" > draft-shiomoto-ccamp-lsp-hierarchy-bis-01.txt > c) Call Support > draft-papadimitriou-ccamp-gmpls-rsvp-te-call-00.txt > d) Ethernet TSpec > draft-dimitri-mef-ethernet-traffic-parameters-00.txt > e) OSPF-TE MIB > draft-otani-ccamp-gmpls-ospf-mib-02.txt > > Please say for each if you think it should/should not become a WG doc. > > My previous email was in error: the "excellent" support was for the > migration doc. Just to be clear, we'll double-check all these docs. > > Kireeti. > ------- > --------------040706060407060407040909 Content-Type: text/x-vcard; charset=utf-8; name="richard.vcf" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="richard.vcf" begin:vcard fn:Richard Rabbat n:Rabbat;Richard org:Fujitsu adr:MS 345;;1240 East Arques Ave;Sunnyvale;CA;94085;USA email;internet:richard@us.fujitsu.com title:Senior Project Manager tel;work:1-408-530-4537 tel;fax:1-408-530-4515 tel;cell:1-650-714-7618 x-mozilla-html:TRUE version:2.1 end:vcard --------------040706060407060407040909-- Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 01 Apr 2006 00:28:47 +0000 Date: Fri, 31 Mar 2006 16:27:58 -0800 Message-Id: <200604010027.k310Rw5b030636@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 4427 on Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4427 Title: Recovery (Protection and Restoration) Terminology for Generalized Multi-Protocol Label Switching (GMPLS) Author: E. Mannie, Ed., D. Papadimitriou, Ed. Status: Informational Date: March 2006 Mailbox: eric.mannie@perceval.net, dimitri.papadimitriou@alcatel.be Pages: 22 Characters: 43842 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ccamp-gmpls-recovery-terminology-06.txt URL: http://www.rfc-editor.org/rfc/rfc4427.txt This document defines a common terminology for Generalized Multi-Protocol Label Switching (GMPLS)-based recovery mechanisms (i.e., protection and restoration). The terminology is independent of the underlying transport technologies covered by GMPLS. This memo provides information for the Internet community. 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 01 Apr 2006 00:28:39 +0000 Date: Fri, 31 Mar 2006 16:28:15 -0800 Message-Id: <200604010028.k310SFsc030641@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 4428 on Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4428 Title: Analysis of Generalized Multi-Protocol Label Switching (GMPLS)-based Recovery Mechanisms (including Protection and Restoration) Author: D. Papadimitriou, Ed., E. Mannie, Ed. Status: Informational Date: March 2006 Mailbox: dimitri.papadimitriou@alcatel.be, eric.mannie@perceval.net Pages: 47 Characters: 118749 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ccamp-gmpls-recovery-analysis-05.txt URL: http://www.rfc-editor.org/rfc/rfc4428.txt This document provides an analysis grid to evaluate, compare, and contrast the Generalized Multi-Protocol Label Switching (GMPLS) protocol suite capabilities with the recovery mechanisms currently proposed at the IETF CCAMP Working Group. A detailed analysis of each of the recovery phases is provided using the terminology defined in RFC 4427. This document focuses on transport plane survivability and recovery issues and not on control plane resilience and related aspects. This memo provides information for the Internet community. 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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Envelope-to: ccamp-data@psg.com Delivery-date: Sat, 01 Apr 2006 00:28:31 +0000 Date: Fri, 31 Mar 2006 16:27:46 -0800 Message-Id: <200604010027.k310RkPL030630@nit.isi.edu> To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org Subject: RFC 4426 on Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, ccamp@ops.ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4426 Title: Generalized Multi-Protocol Label Switching (GMPLS) Recovery Functional Specification Author: J. Lang, Ed., B. Rajagopalan, Ed., D. Papadimitriou, Ed. Status: Standards Track Date: March 2006 Mailbox: jplang@ieee.org, balar@microsoft.com, dimitri.papadimitriou@alcatel.be Pages: 23 Characters: 55820 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-ccamp-gmpls-recovery-functional-04.txt URL: http://www.rfc-editor.org/rfc/rfc4426.txt This document presents a functional description of the protocol extensions needed to support Generalized Multi-Protocol Label Switching (GMPLS)-based recovery (i.e., protection and restoration). Protocol specific formats and mechanisms will be described in companion documents. [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 list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ...